Unable to block access for a web site using URL Filtering Override option on TMG 2010

1. Introduction

The new URL Filtering option on Forefront TMG 2010 allows you to manually add web sites to a specific category; such feature is called URL Category Override. This can be a good approach when you want to force a specific site to be categorized in such way that it fits into a category that currently you have on your block rule. This post will describe a scenario where the TMG Administrator added a web site to the “dubious” category as shown below:

 The goal was to block access to this web site due company security policy. To test if this configuration was working fine, TMG administrator used the Category Query feature and there it was possible to see that the new categorization was working fine as shown below:

When the client was trying to access this URL from his workstation he was getting the expected error message.

2. The Problem

The problem on this case is that users figured out a way to bypass this by typing https:// in front of the URL, in order words if they type https://www.facebook.com they were able to access the web site. You might be thinking: how is that possible? Well, that was my question when I first heard the TMG Administrator explaining his problem to me, but then after reviewing the environment and client configuration it was possible to understand why such behavior was happening.

The problem is that client workstation was configured as Secure NAT client, no web proxy configuration. You need to remember that URL Filtering doesn’t do HTTPS categorization for Secure NAT requests, therefore such behavior was expected. On the article that me, Jim and Mohit wrote for TechNet Magazine (March 2010 issue) we say:

“…the ability of URL filtering to evaluate the request is dependent on two criteria:

- Is the connection directed to the default HTTP port? If so, the Web proxy may be able to intercept this request and pass it to URL filtering for comparison. If not, the request will not be seen by URL filtering and thus cannot be compared to the database.

- If the connection is directed at the default HTTPS port, is HTTPS inspection enabled? If so, HTTPS inspection can bridge the connection, and URL filtering will have an opportunity to compare the request to the database.”

Based on that you can imagine how to fix this problem, correct? Let’s take a look on the options that we have here.

3. The Solution

In scenarios like this there are a couple of solutions:

- Enable HTTPS Inspection: with HTTPS Inspection enabled, it will be possible to enforce the URL Filtering for requests that use HTTPS and are coming from SecureNAT clients.
- Use Web Proxy Client: by using web proxy client, URL Filtering will work regardless of the protocol.

For this particular scenario the administrator preferred to use Web Proxy Client and deploy a GPO to force all IE users to go out to the Internet using this particular TMG. For that the following AD policies were used:

Policy 1 – Used to force the proxy server setting:  

Policy 2 – Used to disallow users to change their proxy settings

 

4. Conclusion

It is always important to analyze all the possible options and which one will best fit on your environment. Sometimes concentrate all the policy enforcement on the edge it is good, however there are many times on which you will need to make sure that your infrastructure as a whole is enforcing the company security policy. By leveraging Windows security capabilities to enforce policies you can facilitate the overall administration overhead and have multiple layers of policy enforcement in place.

Sometimes I receive questions like: I don’t want that user’s use the application XYZ to grab content on the Internet. How can TMG block this application on my Web Proxy Client? This is a classical question and it can be done on TMG if you have TMG Client installed, but if this is just a web proxy client, then the approach should be different. It comes back to the subject of enforcing company’s security policy end to end. Ask yourself the questions below and you will realize that there are much more to be concern about:

- Why this client is running a non approved application on company’s desktop in first place?
- Why not use software restriction policy via GPO for the company workstations?
- Even if you block on the edge, who guarantees that this non approved application is not trying to harm other internal clients?

As you can see there are many questions that need to be answered on this area before try to fix a particular non compliance concern by solely use a fix on the edge.