Introduction
With the new year comes new TMG firewall admins. While I know there is a large contingent of dyed in the wool ISA and TMG firewall admins who visit this site on a regular basis, it’s the new TMG firewall admin who needs the most help. For that reason, and in the spirit of our on-going “Back to Basics” series, I thought I’d try to give you a leg up on some of the more important “do’s and don’ts” of TMG firewall deployment and administration.
Of course, you don’t have to be a new firewall admin to benefit from these “five things you shouldn’t do with the TMG firewall”. You might have just switched jobs and inherited a TMG firewall at your new place of employment, and you’re not sure whether you inherited a fortune or a lump of coal. You might have been using “the other guys’ products” and now someone upstream in the food chain that makes purchasing decisions has decided to gift you with one or more TMG firewalls. However you came to TMG, these do’s and don’ts can benefit you, too.
Like most things related to firewall administration, best practices, do’s and don’ts, and similar nuggets of advice represent a personal opinion. My opinion comes from working with ISA and TMG firewalls, testing the products, researching them for the books and articles I’ve written, and using them on my own production network for over a decade, along with my husband, and this article is based on that experience. However, other experienced TMG firewall admins may have differing opinions. That’s why it’s a good idea to keep an eye on my blog on this site, where I point you to additional resources from the leading minds in the world of TMG firewalls.
Now for the list of five things that, in my opinion, you shouldn’t do with your TMG firewall:
- Create an Anywhere to Anywhere Rule
- Deploy the TMG firewall in “Hork” Mode
- Use IPsec Tunnel Mode for TMG to TMG/ISA Site to Site VPN
- Put the TMG firewall between two firewalls
- Fail to deploy the TMG (Firewall) client
Why you shouldn’t create an Anywhere to Anywhere Rule
“Of all sad words of tongue or pen, the saddest are these ‘I created an anywhere to anywhere rule.’” (OK, the John Greenleaf Whittier poem doesn’t go exactly like that, but that’s the spirit of the original). I can’t count the number of times I’ve gone into a new ISA or TMG deployment and found a rule that allows access from “Anywhere” to “Anywhere” for all protocols. When I ask why such a rule was created, I’m usually told that they needed to create such a rule in order to allow application “X” to work.
The problem with such a rule is that it turns your firewall into a wide open target that anyone in the world, including both internal and external (and DMZ) hosts can attack at will. Sure, the Network Inspection System (NIS) will slow those attacks down a bit, but such a rule essentially turns off the firewall and makes it a target for every piece of malware you can imagine.
Rule number one for smart TMG admins, then, is this: Never, ever create an Anywhere to Anywhere rule. If you ever see a TMG firewall that has such a rule, assume that the firewall has been compromised and crater the box and start over.
Figure 1
Why you shouldn’t deploy the TMG firewall in “Hork” Mode
The TMG firewall can be deployed in a number of different roles. The most popular roles are the front-end and back-end firewall roles. However, there is another role that has earned the moniker among TMG experts of “hork mode”. A hork mode TMG firewall is one that is deployed with a single NIC – so it’s often more diplomatically referred to as the “single-NIC” configuration.
When hork mode is enabled, all IP addresses are tossed into the default Internal Network. The hork mode TMG firewall can’t be placed in the request/response path – or more accurately, it can’t be forced into the request/response path. If a user decides not to configure his/her web browser as a web proxy client, then “poof!”– no more security.
When you deploy the hork mode TMG firewall, you essentially gut it of most of its firewall functionality. A hork mode TMG firewall can only be used as a forward and reverse proxy server (with some support for remote access VPN server). That’s it – nothing else. It’s like buying a Ferrari and then taking three of the wheels off. What’s the point?
Even worse, many hork-mode TMG firewalls are deployed in “workgroup mode” – which is a nice way of saying that the TMG firewall is not a domain member. Not making the TMG firewall a domain member also strips out key security functionality. When you combine the hork mode single NIC deployment with the lack of domain membership, you have something that I’ll christen today as “ultra-hork mode”.
The figure below shows the Network configuration of a TMG machine that’s been horked.
Figure 2
While there are some very specific deployment scenarios related to reverse proxy where hork mode might make sense, you should seriously question any deployment based on a hork mode TMG firewall. Odds are that you can create a more secure configuration using the front-end or back-end firewall configuration.
Why you shouldn’t use IPsec Tunnel Mode for TMG to TMG/ISA Site to Site VPN
The TMG firewall can be configured as an endpoint for a site to site VPN configuration. When you configure the TMG firewall as such an endpoint, you can use one of three VPN protocols for the site to site VPN connection:
- PPTP
- L2TP/IPsec
- IPsec tunnel mode
If the endpoint to which you’re connecting your TMG firewall is a non-TMG/ISA firewall, then you will probably have to use IPsec tunnel mode. The reason for this is that most non-TMG/ISA firewalls don’t support PPTP or L2TP/IPsec. But if the endpoint to which you’re connecting is an ISA or TMG firewall, you should always use PPTP or L2TP/IPsec.
The figure below shows the VPN Protocol page of the Create Site-to-Site Connection Wizard. Notice the comment under the IP Security protocol (IPsec) tunnel mode option: “Provides high security and interoperability with third party VPN vendors”. That’s why IPsec tunnel mode support was included: to support connections to non-ISA/TMG firewalls.
There are a number of reasons why you wouldn’t want to use IPsec tunnel mode when connecting to ISA or TMG firewalls. For example, routing IPsec connections is somewhat problematic, and it doesn’t leverage the routing functionality enabled by RRAS. Also, IPsec tunnel mode is slower and doesn’t allow for header compression.
Figure 3
If you need to connect the TMG firewall to an ISA or TMG firewall for a site to site VPN connection, use L2TP/IPsec. That’s the most secure option and it’s relatively easy to deploy. You can start with a pre-shared key, and when you are confident that everything is working right, you can move to certificates.
Why you shouldn’t put the TMG firewall between two firewalls
This is one that really drives some of us insane – seeing the TMG firewall put between two other firewalls. You have to wonder about this. Why put one of the most secure firewalls on the market today between two other firewalls of unknown or lower security?
I can’t tell you the number of times I’ve seen this done – most often deployed in what Tom calls a “hork mode sandwich” (there is also the “hork mode sandwich on a stick,” which is even more egregious). While there might be some deployment scenarios when you need to put the TMG firewall between two other firewalls, those scenarios are very rare, and almost always driven by non-technical considerations and the FUD (“fear, uncertainty and doubt”) of the “network guys” who believe that so-called hardware firewalls are somehow invulnerable, in spite of the constant barrage of security alerts issued by security firms and hardware firewall vendors about these supposedly perfect devices.
The fact is that the TMG firewall was designed as a network firewall and to be a front-end, Internet facing firewall. You could argue that you can reduce the processing pressure on the TMG firewall by putting a packet filtering NAT device (firewall) in front of it – but putting the TMG firewall behind or in between firewalls is just a waste of money, and can lead to configuration complexity and ultimately to a security incident due to firewall misconfiguration.
If you find that you’re asked to deploy the TMG firewall in this manner, or have inherited such a configuration, review the design and think again – the security incident you prevent might just be your own!
Figure 4
Why you shouldn’t fail to deploy the TMG (Firewall) client
The TMG client (better known as the Firewall client) is a Winsock proxy application that can control remote connections from Winsock applications to the TMG firewall. You can use the Firewall client to make your routing infrastructure transparent to the client system. What that means in practice is that it doesn’t matter what your default gateway is on the client system. As long as the client system has access to the IP address on the internal interface of the TMG firewall, it will be able to connect the client system to the Internet.
In addition to routing transparency, you also get application and user names in your firewall logs. The TMG client will forward both the application name that’s being used to access the Internet and the name of the user who is using that application. This is a very cool feature. When you deploy the Firewall client, your logs and reports can include both the names of the users (and you can deploy user/group based access controls) and the applications they used.
The new TMG 2010 client can even perform automatic discovery using records that reside in the Active Directory, using an LDAP query, in addition to the traditional methods (DNS and DHCP).
Last but not least, the Firewall client will support complex protocols without requiring the assistance of an Application Filter. Since Application Filter development can be complex, this is a tremendous boon for the TMG firewall admin and can significantly reduce the support desk calls for applications that “don’t work”.
Summary
In this article, we took a (sometimes lighthearted) look at five things that you shouldn’t do with your TMG firewall. While doing these things might not be “dumb” in every single instance, most of the time they don’t constitute best practices and there’s a better alternative. If you follow these guidelines, you will insure that you’ve deployed the TMG firewall more securely than you would have otherwise. Of course, there are many other things that you should and shouldn’t do with the TMG firewall, but this is a good start. If you have your own favorite things that you shouldn’t do with the TMG firewall, then let me know! I’ll include those in an upcoming ISAserver.org newsletter. Email me at [email protected].
