Introduction
With more than a decade of experience working with Forefront Threat Management Gateway (TMG) 2010 and its predecessors ISA Server 2006/2004/2000 and Proxy Server, I’ve noticed that many new (and even some veteran!) ISA and TMG administrators commonly make the same mistakes. Some of these mistakes can be serious, often resulting in reduced security or performance. Some are violations of implementation or security best practices, while others could be categorized as simply an annoyance. Regardless, I am compelled to share them with you here in the hopes that you’ll avoid making some of these same mistakes.
Ten Common Mistakes
1. Improper Network Configuration – By far, this is the single most common mistake TMG administrators make, especially when two or more network adapters are installed on the firewall. When the TMG firewall contains only a single network interface, the configuration is simple and straightforward. The interface is assigned an IP address, subnet mask, default gateway, and DNS server(s) as required. However, things change when multiple network interfaces are configured. IP addresses and subnet masks are configured as usual. The default gateway can only be installed on one interface though, and it should only be configured on the External interface. Frequently I see TMG administrator’s mistakenly configuring default gateways on all network interfaces, which of course is incorrect. In a related note, DNS configuration is all too frequently misconfigured as well. On TMG firewalls with multiple network interfaces, DNS servers should be configured only on the Internal network interface. These servers should be capable of resolving public hostnames. For more information on correct DNS configuration for Forefront TMG firewalls, click here. In addition, incorrect network interface binding order, incorrect or missing routing table entries, and TMG network definition are also common configuration errors.
2. Creating Any/Any Access Rules – This one is one of my personal pet peeves. I can’t think of any valid reason to configure an open access rule (other than perhaps for testing) on the TMG firewall. Creating an access rule, even for an individual system, defeats the security provided by TMG. Creating any/any access rules essentially converts the powerful TMG firewall in to a simple router. I would encourage all TMG firewall administrator to do their homework and configure the appropriate level of access required for the communication instead of opening up access to all protocols and ports. Sometimes this is a simple as consulting documentation to determine firewall configuration requirements, but I will concede that this is the exception rather than the rule. Often it requires profiling network traffic for the system or systems involved. Take the time to use a protocol analyzer to observe network traffic and analyze the communication flow to determine which protocols and ports are required. Once you’ve done this, monitor the TMG firewall’s access logs carefully for indications of blocked traffic, as you many need to add additional protocols and ports to the access rule to ensure full functionality.
3. Disabling Flood Mitigation – Flood mitigation is an essential protection mechanism employed by the TMG firewall to defend itself against direct attack and to ensure availability if a worm floods a protected network with traffic. However, there are times when legitimate network traffic from some hosts will trigger the flood mitigation mechanism. I realize this can be frustrating, but resist the urge to disable flood mitigation completely! Sadly, I see this in the field more than I can tell you. If you encounter this scenario, and if you have DNS servers or SMTP servers behind your TMG firewall, you almost certainly will create a flood mitigation exception policy for the host that is exceeding the default flood mitigation thresholds. For more information on flood mitigation configuration, click here.
4. Requiring Authentication on Web Proxy Listener – This common configuration mistake can result in some unexpected behavior on the TMG firewall. This is an odd setting, because if you attempt to enable this configuration the TMG firewall actually complains about it! TMG warns the administrator that the best way to require authentication is on the access rule itself. To accomplish this, simply configure the access rule to use something other than “all users”. At a minimum, specify the “all authenticated users” group and TMG will require authentication for those requests. Configuring authentication on the TMG firewall in this manner allows the administrator to also configure specific access rules for anonymous access, if required. Often anonymous access is required for access to sites like Windows Update, because systems will check for updates without requiring a user to be logged on.
5. Creating Deny Rules for All Traffic to Domain Name Set – This is a pretty serious configuration error that can drastically impede the performance of your TMG firewall. The goal of using such a rule is an admirable one – preventing access to a specific set of resources, often because they are malicious. However, you have to take in to consideration how the TMG firewall processes requests against firewall policy. In the case of a domain name set, TMG is looking to match the request to the configured domain name set. If, for example, we are blocking access to evil.example.com, a web proxy request will include evil.example.com in the HTTP host header. TMG evaluates this field and compares it to the name included in the domain name set. The challenge is matching this for requests that are from Firewall Client or SecureNAT clients. In these cases, the client sends only an IP address to the TMG firewall. In order to determine if this request matches an entry in a domain name set, the TMG firewall performs a reverse DNS lookup on the IP address to obtain a host name. If there’s a match, traffic is allowed. How often does the reverse lookup result in the same name as the initial request? Hardly ever! Too often PTR records (used to map IP addresses to names and used in reverse DNS lookups) are missing or incorrectly configured. More commonly they map to a different name completely because the original request is simply an alias for a group of servers. The real problem with this configuration error is in specifying all protocols. This means that for each and every packet the TMG firewall processes it will have to make a reverse DNS lookup to make sure it doesn’t match the domain name set specified in the deny rule. When that happens, performance can be severely degraded, especially on very busy TMG firewalls. Also, DNS servers can be overwhelmed which further contributes to performance degradation on the firewall. If you need to establish an explicit deny rule, don’t specify all protocols. Specify only the protocols for which the TMG firewall would otherwise allow.
6. Failing to Configure Connectivity Verifiers – If you aren’t using connectivity verifiers on your TMG firewall you are missing out on some valuable information! This is a frequently overlooked configuration option that can yield important information about the availability and health of services that the TMG firewall relies on. For more information about connectivity verifiers, click here.
7. Ignoring Alerts – Too many administrators view the TMG alerts only when they encounter a problem! The alert page provides a wealth of information about the status of the TMG firewall, and I recommend that you review this on a daily basis. In addition, configure e-mail notification for serious or important alerts that you want to be notified about immediately.
8. Not Participating in the CEIP – Ok, this is really more of an annoyance than a configuration error, but I strongly encourage everyone to join the Customer Experience Improvement Program (CEIP). When TMG is first installed, you’ll see a prompt at the top of the management console. All too often this goes ignored or unnoticed! Participating in CEIP allows Microsoft to collect valuable information about the operation and performance of your TMG firewall that, ultimately, is beneficial to everyone. Microsoft collects only anonymous information about your configuration to identify trends and usage patterns. More information about CEIP can be found here.
9. Not Joining the Domain – Joining the TMG firewall to a domain enables the full functionality and protection that the TMG firewall was designed to provide. This includes providing transparent authentication for domain users in forward proxy scenarios and leveraging user certificates or smart cards for web publishing and remote access VPN. Configuration and deployment for TMG Enterprise arrays is much more difficult without being domain-joined. Certificates are required when the TMG firewall is not a member of the domain, and only one Enterprise Management Server (EMS) can be used which introduces a single point of failure. If you cannot join the TMG firewall to your existing resource domain, consider creating a subdomain dedicated to the TMG firewalls and leveraging read-only domain controllers (RODC). You could even go so far as to create a separate forest to support domain-joined TMG firewalls and establish a one-way trust with your existing forest.
10. Installing Host-based Antivirus on the TMG Firewall – Although installing host-based antivirus software on the TMG firewall is supported, it is not generally recommended. If you follow the administrative best practices that I laid out here, the exposure of the system is extremely limited and the risk of virus infection is very low. If your corporate security policy dictates that you absolutely must have host-based antivirus installed on the TMG firewall, be sure to follow the implementations guidelines set forth by Microsoft here.
+1. Blaming the TMG Firewall for Everything – I’ll agree that this is a very broad statement, but nevertheless it is true. Often the TMG firewall gets blamed for the ills of our networks and computing infrastructure when TMG itself isn’t to blame, it’s merely the victim. As I’ve outlined before, TMG relies heavily on supporting services such as DNS and Active Directory. Any issues in these core services can adversely affect the TMG firewall. Frequently operational or performance-related issues can be attributed to problems in one of these underlying services. Also, don’t forget that the TMG firewall provides additional protection that other firewalls do not. If you can’t access a resource through TMG but you can through another firewall, it doesn’t necessarily mean that TMG is broken. It might just be an instance where TMG’s advanced protection mechanisms are blocking traffic that a simpler firewall would allow.
Summary
So there you have it. Ten common mistakes made by Forefront TMG firewall administrators, based on my extensive experience working with ISA and TMG administrators around the world. This list is not conclusive either. There are many more common mistakes that TMG administrators make, I’m sure. It is my hope that by reviewing this article it will help you to avoid these common mistakes and ultimately make your TMG deployment more secure, higher performing, and easier to manage.
