When companies establish a security policy, a key goal is to enable employees to more safely browse the Internet. Of course, this encompasses a very broad area and covers a number of requirements, such as:
Fortunately, taking advantage of the secure Web gateway capabilities in Microsoft Forefront Threat Management Gateway (TMG) 2010 can help you meet these goals. Figure 1 shows the main Forefront TMG 2010 features you can use to implement a secure Web access gateway:
Figure 1 Core Forefront TMG 2010 Features for Secure Web Gateway Scenario
As you can see, Forefront TMG uses three main cloud components: Microsoft Update, Telemetry Service and Microsoft Reputation Service (MRS). Microsoft Update keeps anti-malware and Network Inspection System (NIS) signatures updated. The Microsoft malware response team uses telemetry reports provided by TMG to learn what attacks are being seen and thus enhance signature quality. MRS maintains a huge database of categorized URLs that Forefront TMG 2010 can query.
In this article we’ll focus on URL filtering and HTTPS inspection. We covered malware inspection in-depth in our previous TechNet Magazine February 2009 article, and the feature hasn’t changed in Forefront TMG 2010.
URL filtering can be viewed as the Forefront TMG first line of defense for helping to secure your organization’s Web access. By using URL filtering to block requests for undesirable Web sites, Forefront TMG can spend less time scanning for malware and more time delivering useful content.
URL filtering consists of two main parts—the Web proxy filter that evaluates Web requests, and MRS, which provides the category definitions from which the filter determines how a request is to be categorized. Here’s a simplified form of the process that occurs for a Web request:
Because users tend to be statistically habitual in their Web usage, the URL category cache will become more relevant to your organization over time as Forefront TMG processes user requests. In this way, the ratio of MRS queries to user requests will eventually decrease. Because URL categories are likely to change, MRS assigns a time-to-live for each entry. As such, the number of MRS requests will never completely reach zero, even if your users always go to the same sites.
To fully understand how URL filtering works, you have to also understand how Web applications create connections and issue requests. Web applications generally fall into two categories: those that are configured to act as Web proxy clients, and those that aren’t.
METHOD http://website.contoso.com/path/page.aspx?querystring HTTP/1.x
METHOD http://18.104.22.168/path/page.aspx?querystring HTTP/1.x
In this case, Forefront TMG, and thus URL filtering, has the complete URL available for comparison with the URL filtering database.
Note: METHOD may be any valid HTTP method, such as GET, POST and so forth.
CONNECT website.contoso.com:443 HTTP/1.x
CONNECT 22.214.171.124:666 HTTP/1.x
For these requests, Forefront TMG and URL filtering have only the hostname or IP address (depending on how the client issues the request) and port for comparison with the URL filtering database.
METHOD /path/page.aspx?querystring HTTP/1.x
In this case, the ability of URL filtering to evaluate the request is dependent on two criteria:
What may not seem obvious is that URL filtering in and of itself does not provide any form of blocking mechanism—it merely responds to the Web proxy with the categories associated with the requested URL as the Web proxy (and thus URL filtering) understands it. In all cases, when URL filtering receives a client request, it functions as illustrated in Figure 2.
Figure 2 Basic Flow of URL Filtering
If Forefront TMG needs to query MRS, a request is made using a single Web Services call to the MRS Web services portal. MRS processes the data presented by Forefront TMG and responds with the current URL categories that apply to the data MRS received. Forefront TMG 2010 has a predefined domain set that includes the portal destinations in effect when Forefront TMG shipped (see Figure 3).
Figure 3 MRS Domain Set
If the URL categories returned by URL filtering are found in a “deny” rule, Forefront TMG sends a rejection response (HTTP result-code 502) to the client. Depending on whether the client is a browser or other Web application, the user may see the Forefront TMG response page; in the case of a non-browser application (such as Windows Media Player or a CERN-proxy FTP application), the user may simply see an error message from the application itself.
Because the most expensive task Forefront TMG has to perform in order to determine the URL category is to query MRS, this process is much cheaper in terms of CPU, memory and network resources than allowing the user to reach the Web site, then having to perform malware scanning on all of the content they request.
Users have been advised for many years that to perform a secure online transaction, they have to use HTTP with SSL (HTTPS). However, this secure channel has also been used for malicious purposes. When users start a transaction using HTTPS, this traffic is normally encrypted end-to-end (from user to destination server), making the content being exchanged between them unreadable to any device in between. While this is a desirable behavior, because you don’t want anybody looking at your online credit-card transaction, the drawback is that any malicious operation within this channel can’t be evaluated. Figure 4 highlights the main parts of this operation using ISA Server 2006 as the firewall.
Figure 4 Traditional HTTPS Scenario
Figure 4 illustrates a full proxy scenario in which the client is accessing an HTTPS site. The summarized steps are divided in two main phases, as outlined here:
Phase 1 – SSL Tunnel
Phase 2 – Encrypted conversation
The potential risk in this scenario is that as of phase 2, the edge firewall has no knowledge of what really is being transmitted on that channel. In a scenario where the destination server is hijacked and malicious code inserted, there’s a potential risk that the destination server will send malware through this encrypted channel that the client will receive without hesitation because it comes through a supposedly trusted connection.
Forefront TMG HTTPS Inspection reduces this threat by inspecting the traffic and maintaining separate encrypted channels with the user and server. Figure 5 shows how Forefront TMG accomplishes that.
Figure 5 HTTPS Inspection in Action
The summarized steps are still divided in two main phases; however, the process now includes inspection:
Phase 1 – Client Request
Phase 2 – Encrypted conversation with Inspection
a) TMG receives and decrypts the encrypted traffic from the destination server.
c) If the malware and NIS filters allow, TMG will encrypt the results and send it to the client workstation.
To establish the SSL handshake with the client, Forefront TMG needs a server certificate. In order to create it, Forefront TMG creates a spoof certificate based on the original server certificate data and signs it with the HTTPS inspection CA certificate. To ensure maximum performance, Forefront TMG maintains a cache of duplicate server certificates. TMG will search for a duplicate server certificate in the local cache and if one is not found, it will duplicate the upstream server certificate and place it in the cache. The cache is stored only in memory. Thus, the spoof certificate cache is empty after the Firewall service is restarted.
Note: The size of cache (number of certificates) is controlled by the LowLevelSettings.ClonedCertificatesCacheSize COM property.
Before configuring HTTPS inspection, it is important to understand the full feature set and options that comprise this feature. Figure 6 shows the areas where HTTPS Inspection can be configured.
Figure 6 HTTPS Inspection Feature Set
When planning your HTTPS inspection implementation, you need to first consider the certificate settings, to decide whether you will use a self-signed certificate or a certificate issued by an internal CA. When importing an existing trusted certificate authority, you need a PFX file that contains the certificate of the authority along with its private key. You need this private key in order to sign the spoof certificate issued by TMG. You must also make sure the certificate’s key usage is set for certificate signing. This CA certificate must then be deployed on the client computers (under “Trusted Root Certification Authorities” of the local computer certificates store); otherwise, the client won’t trust the server certificate received from TMG.
On Forefront TMG, HTTPS inspection can be enabled through the Web Access Policy. Follow these steps to enable this feature:
Figure 7 Enabling HTTPS Inspection
For this example, we’ll use a Forefront TMG self-signed certificate. Click Generate and a page similar to the one in Figure 8 will appear.
Figure 8 Generate Certificate Window
Figure 9 Choosing How to Deploy the Certificate
Important: Besides satisfying your organization’s security policies, you also need to evaluate any legal and compliance regulations before you enable HTTPS inspection. Any sites where HTTPS inspection is deemed inappropriate can be added to the exception list.
HTTPS inspection and URL filtering in Forefront TMG not only help provide a protected surfing environment for end users, they also include features that enhance the end-user experience through informational messages and by providing custom or precise error messages the end user can directly relate to.
To remain in compliance with corporate privacy policies, you can turn on client-side notification, which alerts the end user when an SSL site is being inspected and gives him the option to leave the site in order to protect information he deems personal or classified. Figure 10 illustrates this behavior.
Figure 10 HTTPS Inspection Client-Side Notification
For the user to receive HTTPS inspection notification, the client computer must have Forefront TMG Client installed, and it must have the HTTPS inspection trusted root certification authority installed in the local computer Trusted Root Certification Authorities certificate store. Remember that if you have upstream and downstream TMG configuration, HTTPS notifications need to be enabled on the downstream proxy rather than the upstream proxy.
To implement HTTPS inspection client-side notification, you must enable it on both the Forefront TMG server and client. To enable HTTPS inspection notifications on the server:
To enable notifications on Forefront TMG Client:
An administrator can allow or deny Web access to end users based on URL categories. If a user tries to go to a site that has been denied, she will get an error page like the one in Figure 11, showing that access to the site was denied because it had been categorized as such by the Forefront TMG administrator.
Figure 11 Access Denied Web Page
The error message can be customized by the TMG administrator. To do so:
Figure 12 Customizing a URL Filtering Error Message
You can add any custom message to the Display denial notification to user text box. You can even use HTML content as long as the HTML is valid within the context of an HTML <body> element, but you can’t include any scripts.
You can also choose to show the category under which access to the site was denied. To do so, click the checkbox for Add denied request category to notification. This is particularly useful if a site is categorized incorrectly so the end user can let you know. You, in turn, can send this feedback to Microsoft through telemetry and at the same time set up an override category to rectify the categorization till it is fixed.
If you’d like to change the look and feel of the entire URL filtering error message page, you’ll need to edit the 12232.htm HTML page. You’ll find information about this on the Deny Page Customization on Forefront TMG 2010 page of the Forefront TMG (ISA Server) Product Team Blog.
Jim Harrison joined the ISA Server Sustained Engineering team as a QFE tester in January 2003. He is now a program manager with Forefront Edge CS and an avid ISA server supporter and systems implementer, as well as the coauthor of the Forefront Community Page called “Tales from the Edge.”
Yuri Diogenes works for Microsoft as a senior security support escalation engineer on the ISA Server/IAG Team. Diogenes is a coauthor of the Forefront Community Page called “Tales from the Edge.”
Mohit Saxena is the technical lead for the Microsoft ISA Server Support Team, a group of Support and Escalation engineers that works with customers on break fix issues, bugs and design change requests.