Detecting Common Attacks using TMG Intrusion Detection

Apart from those complicated and advanced-level attacks that are targeted against every network every once in a while, there are common attacks that could be really troublesome. A lot of time this happens when people believe that their network does not contain any important data to even go under attack and when the attack occurs, they panic because they don’t expect it and in fact they have nothing to even stop this type of attacks.

Forefront Threat Management Gateway 2010 has an IDS (Intrusion Detection System) inside as one of its features that can detect many of these attacks. To access and configure this feature in TMG you need to go to Intrusion Prevention System and then click on Behavioral Intrusion Detection and first click on Configure Detection Settings for Common Network Attacks:

Here you can see a list of different types of attacks that if checked will be detected and a log will be created for them in the Monitoring section of the TMG. For instance if you check the Port Scan, you can specify the number of ports to be scanned before the TMG considers the traffic as a port scanning attack and can log it.

In the other tab, we can also detect different types of attacks against the DNS service:

Coming back to the Behavioral Intrusion Detection tab in TMG, you can also click on Configure IP Options Filtering to filter specific IP options that may be included in the IP packet’s header. Most IP options in the packer header are harmless but there are some of them that could indicate malicious traffic and must be checked. They are shown below in the picture. If there is any traffic containing these options in the packet header, they will be dropped if you select Deny packets with the selected IP options.

Under the other tab called IP Fragment, you can block IP fragments to block the type of traffic generated from those applications that fragment the packets so that they will not be detected by the firewall but you have to keep in mind that if you enable blocking of IP fragments, you may also block other types of traffic such as L2TP which is pretty common in every network having remote users.

Again under Behavioral Intrusion Detection in TMG, if you click on Configure Flood Mitigation Settings, you will be able to detect and block flood attacks towards the TMG and facing the network. Using this feature you will be able to specify the number of allowed different types of connections to a host and if there are more requests than that, it will be detected as a flood attack and will be denied. You can click on Edit to configure the settings for any of the connection types:

After all this configuration, if there is any traffic detected as attack, it will be logged under the Monitoring section in TMG and will be visible under Alerts. After knowing the source of the attack you will be able to easily block it using the firewall feature if it is not by default blocked.

You want to learn more? Check out my new book below and have access to great and practical tutorials and step-by-step guides all in one book:

To get more information about the book click on the book below:

1

Cheers

Joining Forefront TMG to a Domain or Workgroup…

It’s been always a big question whether the firewall protecting the network should be joined to the Active Directory domain or not? There are so many arguments going on around this topic. In this post, I am focusing more on Forefront Threat Management Gateway 2010 as our firewall and we are going to discuss the pros and cons of adding it to a domain or workgroup.

Type of Installation

PROS

CONS

Domain-Member
  • More control for user access in forward and reverse proxy scenario.
  • Applying Group Policy settings on the TMG server from the central DC and therefore hardening the server running our firewall.
  • Using Kerberos authentication when publishing different servers and therefore increasing the security.
  • Support for authentication using client certificates as the main method of authentication.
  • In case the TMG server is in the perimeter network separated from the internal network by another firewall, there should be more ports open on that firewall to allow the communication between the DC and the TMG.
Workgroup-member
  • If the firewall is compromised, the directory services might not be affected.
  • Even if Active Directory is compromised, the firewall might not be compromised because it isn’t part of the domain.
  • Doesn’t give you the ability to use the domain users and accounts to be used in integration with the TMG.
  • Client certificates can not be used as the main method of authentication.
  • User accounts are created on the firewall itself to allow intra-server communication.
  • Doesn’t support Active Directory Group Policy.
  • TMG client authentication requires account mirroring on TMG

What mentioned above was just a pretty simple comparison which can be found everywhere. But now I want to extend this discussion by first clarifying whether the domain controller and our AD environment will be at risk if we add the TMG to the domain and make it a domain member server. I personally believe in a simple configuration, joining a TMG server to the domain could expose the network to some sort of security risks and depending on the knowledge of the attacker, there could be further attacks on the domain controller and also the other services.

This type of attack usually happens when there is only one layer of TMG firewall between the outside network and the internal network. In a two-level TMG firewall design, we will have more flexibility playing around with the rules inside TMG. In a two-level firewall or what we call as a back-to-back firewall design we can join the front-end TMG firewall to the domain so that we can make use of all the domain features for the clients connecting to the front-end TMG. We also can join our back-end TMG firewall to a workgroup. In this case even if the front-end TMG is owned by an attacker, there still will be a back-end TMG a head of the attacker to get to the main network and the DC.

The question that might come up here is that the back-end TMG still has some ports open so that the front-end TMG can communicate with the DC in the network and you might wonder whether having that back-end TMG is useful at all? And the answer is YES, it is useful since just opening a port on a firewall to let the authentication traffic through doesn’t expose any security risk to the network. A firewall can stop a lot of different types of attacks and therefore that back-end TMG can protect the whole network environment even if the front-end domain-member TMG is owned by the attacker.

In this post I just tried to give you some insights. I suggest whenever you are thinking of integrating any service or software or product with Active Directory, do not panic because of potential security risks but try to analyze the situation and what you want to implement and take every step very carefully and consider even very small risks, then maybe you will realize that the integration of services and products with AD is not that scary…

You want to learn more? Check out my new book below and have access to great and practical tutorials and step-by-step guides all in one book. 

To get more information about the book click on the book below:

1

Cheers