Introduction
The Forefront Threat Management Gateway (TMG) 2010 firewall is commonly deployed as a forward proxy server. Many organizations use the TMG firewall configured in this scenario to aggregate public Internet access for the purpose of authenticating and logging outbound Internet traffic, blocking access to known malicious web sites and botnet command and control servers, and to enforce corporate acceptable use policies. The challenge facing many security administrators today is that occasionally, determined users will seek to circumvent in place access control in an effort to access restricted public web sites and/or services. Typically this involves connecting to publicly available anonymous proxy services such as Tor, Kproxy, Zend2, Anonymouse, and countless others. Preventing access to these sites and services will allow for the most effective enforcement of access policies and greatly improve the overall security posture of the organization. This is much easier said than done, however. There are a variety of ways in which we can prevent access to anonymous public proxies, and in this article we’ll explore a few ways to accomplish this using the Forefront TMG 2010 firewall.
Access Policy
The first step in preventing access to anonymous public proxy services is to ensure that your firewall policy conforms to the principle of least privilege. All too often I see TMG firewalls configured with open, or any-any access rules allowing all outbound Internet access.
Figure 1
If your firewall is configured in this manner, you’re just asking for trouble! In fact, if you have this type of access rule configured on your TMG firewall, it’s not really a firewall at this point – just a router. Of course, if you have configured your TMG firewall with an open access rule like this, perhaps you’re not interested in restricting access to anonymous public proxy services either! If you are, however, get rid of the any-any rule and grant only the access required, for which most web browsing activities is outbound TCP ports 80 and 443. Doing this will prevent access to anonymous public proxy services that use non web-based protocols or that use HTTP over non-standard ports. However, many anonymous public proxy services simply tunnel traffic using HTTP with SSL/TLS, so additional steps will be required to prevent that access. More details on how to accomplish that are provided later in this article.
URL Filtering
Any secure web gateway worth its salt will have some sort of integrated URL filtering mechanism, and Forefront TMG is no exception. Configuring TMG’s native URL filtering is simple and straightforward. First, ensure that URL filtering is enabled by opening the TMG management console, highlighting Web Access Policy, and verifying that the feature is enabled. If it is not, click on the link and choose the option to enable it. Remember that TMG’s URL filtering feature requires the Web Protection Services (WPS) subscription license after the initial trial period ends. Unfortunately, WPS is no longer for sale from Microsoft or any of their OEM partners. If you have not already purchased WPS licenses, or do not have an Enterprise CAL (eCAL) which includes the WPS, you will not be able to use this feature. In this case you’ll have to purchase a third-party integration to perform this functionality.
Figure 2
Once you have enabled URL filtering, create an access rule that denies HTTP and HTTPS access from the Internal network to the Anonymizers category for all users. Be sure to place this rule before any other rules that allow outbound web access. DO NOT specify All Outbound Traffic here, as it will cause TMG to perform reverse DNS looks for every single packet that it receives in an effort to determine if the request matches the category. For more information about this and other common configuration mistakes made by Forefront TMG firewall administrators, click here.
Figure 3
HTTPS Inspection
Enabling outbound HTTPS inspection on the TMG firewall is a very effective method to prevent access to anonymous public proxy access. HTTPS inspection almost immediately halts communication to anonymous public proxies by virtue of the fact that TMG’s HTTP filter ensures that only valid, RFC-compliant HTTP communication takes place. Commonly the HTTP communication to anonymous public proxies does not conform to this, and TMG dutifully rejects this traffic. A word of caution, however. HTTPS inspection can also break legitimate applications. Frequently application developers assume that their SSL/TLS encrypted communication will not be subject to traffic inspection and often they take liberties with the HTTPS protocol, performing non-standard and non-compliant operations. TMG of course objects to this, and blocks the request. In addition, there may be legal, privacy, and compliance considerations that have to be made when inspecting encrypted communication. Before enabling HTTPS inspection on the Forefront TMG firewall, I would encourage you to engage both your legal and human resource teams to inform them of your intent to inspect encrypted traffic. Corporate security policy should be updated to reflect this and it should be communicated to all employees clearly. Also, to address some of these concerns, TMG does provide the ability to bypass HTTPS inspection for certain individual web sites, domains, and categories. Also, when used in conjunction with the TMG firewall client, TMG can provide a visible notification to end users when their HTTPS encrypted traffic is being inspected.
Third-Party Security Filter Integration
As I mentioned earlier, TMG does include native URL filtering capabilities. However, with TMG being formally end-of-life, Microsoft no longer sells the license required to enable this feature. If you find yourself in this situation, then you’ll need to consider using a third-party security integration that provides this capability. There are a number of excellent solutions on the market today, including on-premises and cloud-based solutions. I would encourage you to use your favorite Internet search engine to research those alternatives.
Geographical IP Address Restriction
Often anonymous public proxies can be found in regions of the world that could effectively be restricted using firewall policy. If you’re confident that your users don’t have any valid business reasons to visit sites in certain countries that have a long history and track record of hosting malicious web sites as well as anonymous proxies, you might do well to simply block access to the IP address blocks assigned to that region. This can be accomplished using a number of different methods. The first method involves using freely (or cheaply) available IP address geolocation databases and creating your own TMG network objects to be used in an access rule that denies HTTP and HTTPS traffic to those destinations. Another alternative is to use pre-configured ISA and TMG network objects as I described recently in this article. In addition, there are third-party tools that integrate with Forefront TMG that provide this capability. The advantage of using third-party tools is that they are dynamic and are kept up-to-date as changes to IP network block assignments occur.
Conclusion
Implementing effective security controls using the Forefront TMG 2010 firewall is relatively painless. Ensuring that users aren’t’ successful in circumventing those access controls can be challenging. Using a combination of the techniques described in this article can assist security administrators in preventing access to anonymous public proxies that are a common tool used by end users in their effort to evade policy enforcement. It’s important to understand that these techniques alone may not be 100% effective in all cases. It’s a good idea to diligently monitor and review your access logs for suspicious behavior and update your access control rules accordingly. In addition, the best deterrent for preventing access to anonymous public proxies is your corporate security policy. If the penalty for accessing anonymous public proxies is termination, users will understand quickly that attempting to skirt company acceptable use policy ultimately isn’t worth the risking of losing their job.
