Introduction
If you’ve read any of the Microsoft marketing materials for Forefront Threat Management Gateway (TMG) 2010, or any of Tom Shinder’s articles here on ISAserver.org, undoubtedly you have heard the term “deep application layer inspection”. In this article I’ll explain what this means and demonstrate how the TMG firewall uses it to provide granular control over HTTP communication.
Deep Application Layer Inspection
Many years ago, most firewalls performed only stateful network filtering, controlling access mainly by evaluating information at layers three and four of the OSI networking model – source and destination IP addresses, protocols, and ports. By contrast, the TMG firewall is capable of inspecting network communication up to layer seven – the application layer. Fundamentally the TMG firewall understands how applications communicate; more precisely, how they are supposed to communicate. Application layer inspection takes place after the firewall has processed the low-level communication (source, destination, protocol, and port). Once the initial evaluation is complete and authorized, the request is further analyzed by application filters and web filters. Application layer inspection allows the TMG firewall to control communication with much more granularity than simple stateful networking filtering. Access control can be enforced by deeply analyzing application-layer protocol information. For example, using application layer inspection, it is possible to allow certain SMTP commands and block others, or to selectively allow or deny specific headers in an HTTP request or response.
HTTP Filtering
The most common application layer protocol inspected by the TMG firewall is HTTP. HTTP protocol inspection is handled by the TMG firewall’s HTTP web filter. By default, when the TMG firewall receives a request on TCP port 80 (the well-known port for HTTP), the HTTP filter will inspect the application layer protocol data to ensure that it is valid, RFC compliant HTTP communication. If it is valid, the request is allowed. If it is not valid, the request is denied. The HTTP filter serves as a valuable protection mechanism as it prevents abuses of the HTTP protocol, which are quite often malicious. The HTTP filter also prevents non-HTTP protocols from being transmitted over TCP port 80. When a devious user discovers that their application’s native ports are blocked by firewall policy, often they will attempt to circumvent these access controls by configuring their application to use TCP port 80, which is commonly allowed. The HTTP filter effectively closes this loophole by preventing this non-RFC compliant communication while still allowing normal web-based requests.
The HTTP filter is highly configurable and quite powerful. In addition to limiting the length and size of request and response headers, entity bodies, and URLs, it can also selectively allow or disallow specific HTTP methods, headers, and file extensions. The HTTP filter also allows the administrator to search for patterns anywhere in the URL, request and/or response headers, and even the body itself and can block requests that match those signatures. The HTTP filter can even prevent Windows executable content from being downloaded.
HTTP Filter Configuration
The HTTP filter is configured on a per-rule basis, and applies to any access rule that allows HTTP. It also applies to access rules that allow HTTPS when HTTPS inspection is enabled, or any publishing rule that allows either HTTP or HTTPS. To configure the HTTP filter, right-click on a rule that includes HTTP or HTTPS (where applicable) and choose Configure HTTP.
Figure 1
There are five tabs on the HTTP filter configuration dialog box – General, Methods, Extensions, Headers, and Signatures.
General – The HTTP filter can limit the length of request headers, control payload length, and restrict the maximum length of URLs and query strings for requests. The default HTTP policy limits the maximum headers length to 32Kb and the maximum length of the URL and the length of the query string to 10Kb. Requests that exceed these parameters will be blocked. In addition, you have the option to verify normalization and block high bit characters, as well as block responses that contain Windows executable content.
Figure 2
Methods – The HTTP filter can allow all HTTP methods, allow only specific methods, or block specific methods and allow all others. If, for example, this is a web publishing rule and your published web application does not accept uploads, you can configure the HTTP filter to allow only GET and HEAD requests. Alternatively you can simply block POST requests. If this is an access rule and you want to prevent the use of WebDAV through the gateway, you can choose to block those methods used by WebDAV.
Figure 3
Extensions – The HTTP filter can be configured to allow all file extensions, allow only specified extensions, or block specific extensions and allow all others. If, for example, this is a web publishing rule and you know that your published web application only uses .html and .aspx files, you can configure the HTTP filter to allow only these extensions. If this is an access rule and you want to block the download of .MP3 files, you can configure the HTTP filter to block files with this specific extension and allow all others. Additionally you can instruct the HTTP filter to block requests that include files with ambiguous extensions.
Figure 4
Headers – The HTTP filter can be configured to block specific HTTP request or response headers. For published web servers, the Server Header can be sent as is or it can be modified or removed. The Server header identifies the type of web server that served the request (e.g. Microsoft-IIS/7.5 or Apache/2.2.1.2) so changing or removing this header prevents this information from being disclosed. The Via Header can be sent as is or modified. The Via header identifies the hostname of the web proxy server that handled the request. Changing this header is recommended to prevent the disclosure of this information. Since this header is required by RFC, it cannot be removed.
Figure 5
Signatures – This is where the true power and flexibility of the HTTP filter comes through. The HTTP filter can be configured to block content anywhere in the application data stream, including the request URL, request headers and body, and response headers and body. The HTTP filter can inspect both text and binary content. Frequently this feature is used to prevent specific applications, most often instant messaging and peer-to-peer applications, from communicating over TCP port 80. You can search online for application signatures (a good resource can be found here) or you can profile the application using tools such as HTTPWatch or Fiddler. You can also use a protocol analyzer to capture and inspect the communication in order to identify unique application signatures.
Figure 6
HTTPS Inspection
HTTPS (HTTP over SSL) has often been referred to as the universal firewall bypass protocol. With HTTPS, all of the application layer data is encrypted using SSL, preventing even the most advanced application layer firewalls from inspecting this communication. For many years malicious users and malware authors have used the secure channel provided by HTTPS to bypass gateway inspection and circumvent access controls. As we’ve demonstrated here, the ability to enforce HTTP policy with the TMG firewall’s HTTP filter provides a significantly improved protection and much more granular control of HTTP communication. By enabling TMG’s outbound HTTPS inspection feature, all of the benefits illustrated above can be recognized even when the application layer data is encrypted using SSL.
Summary
The HTTP filter illustrates one of the more powerful and compelling features of the TMG firewall. No longer is controlling access by source IP address, destination IP address, protocol or port an effective means of controlling network access. By inspecting application layer communication, the TMG firewall provides significantly enhanced protection and much more granular access control by enforcing administrator-defined HTTP policy. The HTTP filter not only ensures that communication is valid and complies with the RFC, it prevents potentially malicious abuses of the HTTP protocol and allows the administrator to apply fine-grained access control based on application-layer communication. With outbound HTTPS inspection enabled, the benefits provided by the HTTP filter can also be recognized with SSL-encrypted communication. In this article we discussed the HTTP filter exclusively, however, the TMG firewall is also capable of providing the same level of protection by inspecting DNS, FTP, H.323, HTTP, POP, PPTP, RPC, RTP, SIP, SMTP, TFTP, and many streaming media protocols.
