If you would like to read the other parts in this article please go to:
- Considerations for Replacing your TMG Firewall (Part 1)
- Considerations for Replacing your TMG Firewall (Part 2)
- Considerations for Replacing your TMG Firewall (Part 3)
- Considerations for Replacing your TMG Firewall (Part 5)
Introduction
In this multi-part series discussing the features that you should consider when evaluating new firewalls to replace the TMG firewall in the future, we have thus far talked about inbound and outbound SSL bridging, pre-authentication and delegation at the web proxy server, and the remote access VPN server and site to site VPN gateway functionalities. In each of these articles, I went over what the key capabilities are for the particular feature and what you need to ask about the firewall replacements that you’ll be considering.
As a reminder, here is the list of TMG firewall capabilities we started with in the first article of this series:
- Inbound SSL Bridging
- Outbound SSL Bridging – SSL inspection
- Pre-authenticating and delegating Web Proxy
- SSTP VPN Server – remote access client VPN server
- Site to Site VPN server
- Winsock Proxy
- URL Filtering
- Web Antimalware
- Multi-ISP connectivity
- Network Load Balancing – HA support
This time, let’s take a look at one of my favorite features in the TMG firewall – the Firewall Client (which was renamed in TMG as the “TMG Client”).
The Firewall Client
The Firewall client is an optional component that you can install on any supported Windows operating system. The Firewall client software provides the following enhancements to Windows clients on which it is installed:
- It allows you to enable strong user/group based authentication for all Winsock applications using the TCP and UDP protocols (won’t work with ICMP, for example).
- It allows you to obtain and record user and application information in the TMG firewall’s log files.
- It provides you with enhanced support for network applications that use complex protocols that require secondary connections (for example, RPC and media protocols that require port negotiations).
- It provides you with “proxy” DNS support for Firewall client machines, so that the TMG firewall will perform name resolution on behalf of the client.
- It makes it possible for you to publish servers that require complex protocols without having to code your own application filter.
- It enables you to separate your routing infrastructure from Internet access so that the gateway of last resort doesn’t have to be exposed to the client systems.
Okay, now let’s examine each of those functions in a little more detail.
The Firewall client provides strong user/group based authentication for Winsock applications that use the TCP and UDP protocols
The Firewall client sends user information to the TMG firewall. This allows you to create Access Rules that apply to users and groups, which in turn allows you to allow or deny access to any protocol, site or content based on a user account or user group membership. User/group based outbound access control is very useful because not all users require the same level of access. Users should only be allowed access to the protocols, sites and content that they actually need in order to complete their work.
While I know that this philosophy might seem a bit antiquated in today’s BYOD world, it is my strong contention as a security specialist that if users want to be able to access sites that are not related to work, they ought to be required to use alternate means to do so (such as going through a guest network using their personal devices, rather than connecting to the corporate network). Of course, this doesn’t address all of the security issues that you run into in the burgeoning BYOD era, but a BYOD free-for-all is likely to bring a host of major security issues that I’d rather not be on the record as supporting.
Note:
The concept of allowing users access to only the protocols, sites and content they require is based on the principle of least privilege. Least privilege applies to both inbound and outbound access. For inbound access scenarios, you can use Server and Web Publishing rules to allow traffic from external hosts to internal network resources in a highly controlled and monitored fashion. The same should be true for outbound access. In traditional network environments, inbound access is extremely limited while users are allowed outbound access to virtually any resource they desire. This weak approach to outbound access control is one of the most common reasons that internal networks become compromised. It’s probably second only to machines that become infected when outside the network and are then brought onto the corporate network.
Another thing the Firewall client does is automatically send user credentials to the TMG firewall. The user must be logged on with a domain user account or the user account must be mirrored on the TMG firewall.
For example, if you have an Active Directory domain, then users should log on to the domain on their local computers and the TMG firewall must be a member of the domain or a member of a trusting domain. The TMG firewall will be able to authenticate the user and allow or deny access based on the user’s domain credentials.
If you do not have an Active Directory domain, you can still use the Firewall client software to control outbound access based on user/group. In this case, you must mirror the accounts that the users log on to on their workstations to user accounts that are stored in the local account database on the TMG firewall.
An example of such a configuration might be found in a small business that does not use Active Directory, but in which they do want strong outbound access control based on user/group membership. Users log on to their machines with local user accounts that are configured on each of the machines (yes, small businesses actually do stuff like this). You can then enter the same user names and passwords on the TMG firewall and the TMG firewall will be able to authenticate the users based on the same account information they use when they log on to their local machines.
The Firewall client allows user and application information to be recorded in the TMG firewall’s log files
A key benefit of using the Firewall client is that when the user name is sent to the TMG firewall, the user name is included in the TMG firewall’s log files. This allows you to query the log files for the user name of interest and obtain information on that user’s Internet activity. This is very helpful when you need to carry out a forensics examination on user activity, and it’s also a feature that can be leveraged by third party applications that enhance the TMG firewall’s reporting capabilities.
The TMG Firewall client provides not only a great deal of security by allowing you to control outbound access based on user/group accounts, but also provides a high level of accountability. If you let your users know that you can and do keep track of what they’re doing, those same users are likely to be less than enthusiastic about sharing their account information with other users because they will know that their Internet activity is being tracked based on their account names and that they will be held responsible for that activity.
The Firewall Client provides support for network applications that use complex protocols requiring secondary connections
Unlike the SecureNAT client (which is a machine that is configured with a default gateway that provides it with access to a path to the Internet), which requires an application filter to support complex protocols (which are protocols that require secondary connections), the Firewall client can support almost any Winsock application that uses the TCP or UDP protocols, regardless of the number of primary or secondary connections that may be required by the protocol. It does this without requiring an application filter to support the protocol.
The TMG firewall makes it easy for you to configure protocol definitions that reflect multiple primary or secondary connections and then create Access Rules that are based on your custom protocol definitions. This really lowers the administrative overhead and bottom line cost because you do not need to purchase applications that are SOCKS proxy aware, you do not need to stand up a separate SOCKS proxy and you do not need to waste the time and money that are involved in creating custom application filters to support “off-label” Internet applications.
The Firewall client provides DNS name resolution support for Firewall client machines
In contrast to the SecureNAT client, whereby the client has to resolve names on its own by using the DNS server that’s configured on the SecureNAT client, the Firewall client does not need to be configured with a DNS server that can resolve Internet host names. The TMG firewall can perform a “proxy” DNS name resolution for Firewall client systems.
For example, suppose a Firewall client sends a connection request for www.isaserver.org. The connection request is “remoted” directly to the TMG firewall. The TMG firewall resolves the name for the Firewall client system based on the DNS server settings on the TMG firewall’s network interface cards (typically, the TMG firewall is configured to use DNS servers configured only on its internal interface). The TMG firewall then returns the IP address to the Firewall client machine and then the Firewall client machine sends an HTTP request to the IP address for www.isaserver.org. The TMG Firewall also caches the results of the DNS queries it makes for its Firewall clients (as well as the queries it makes for the web proxy clients). This DNS caching speeds up name resolution for subsequent Firewall and web proxy client requests.
The Firewall client enables you to publish servers that require complex protocols without the aid of an application filter
In general, you should not install the Firewall client on server systems. There are many good reasons for this rule of thumb, but suffice it to say that installing the firewall client on a server is a considered a “worst practice”. However, there may be some unusual circumstances in which you need to publish a server that requires support for publishing complex protocols. One option would be to create your own application filter. However, in order to do that, you must be very knowledgeable about application filter programming, and you aren’t going to get the support from the TMG firewall team for it, either.
Assuming that you’re not a C or C++ programmer and you would like some support if things should go haywire, one thing you can try to do is installing the firewall client on the server and then configuring some configuration settings files on the server so that connections are remoted properly to the server. The configuration isn’t simple, and it’s probably something that only a few people in the world (such as Jim Harrison) could do, but it does work and the instructions are on the Microsoft web site if you should find yourself in this unusual situation.
The Firewall client simplifies the routing infrastructure for Firewall clients
The final major benefit conferred by the Firewall client is that the routing infrastructure does not require that you define a gateway address on the client that allows access to the Internet. In contrast to the SecureNAT client, which depends on its default gateway and the default gateway settings on routers throughout the corporate network to point it to the egress point to the Internet, the Firewall client system only has to be configured with a gateway address that will lead it to the internal interface of the TMG firewall. The Firewall client machine “remotes” connection to the internal IP address of the TMG firewall. Since your routers are typically aware of all the routes on your network, there is no need to make changes to the routing infrastructure to support client side connections to Internet located sites.
Summary
In this article, have we continued our series on the features and capabilities that you’ll want to have available to you when you finally make the move from the TMG firewall to an alternate firewall solution. Our discussion this time was about the TMG firewall client and it’s likely that this will be the most difficult feature for you to replace when you search for an alternate firewall. In fact, I’m not aware of any other firewall that provides such a useful feature. That might mean that you’ll need to revisit a SOCKS gateway, or more likely, you will just move all your applications to HTTP based applications that can be run through a web proxy server. If you are aware of any firewalls that provide similar features to the TMG firewall client and TMG winsock proxy server, let me know! See you next week –Deb.
If you would like to read the other parts in this article please go to:
