This topic is designed to help you plan for HTTP filtering, which enables you to protect against Web browsing threats by inspecting the content that passes through Forefront TMG.

Note:
This topic also provides a description of the settings required for configuring headers and URL blocking in an HTTP policy for a rule. See HTTP filtering settings overview below.

Forefront TMG provides granular control over HTTP traffic in the form of an HTTP filter. The HTTP application-layer filter examines HTTP commands and data that pass through the Forefront TMG computer, allowing through only compliant requests. By ensuring that servers respond only to valid requests, the security of your Web servers is significantly enhanced, and you can control client Internet access.

HTTP filtering can be applied in the following scenarios:

HTTP filtering is rule specific, and different criteria can be set on each rule. For example, you can use HTTP filtering to block the use of a particular peer-to-peer file sharing service for one set of users, but allow it for another set. When content is blocked by an HTTP filter setting on a rule, users receive a 502 Proxy Error with the message "The request was rejected by the HTTP filter".

Configuring an HTTP filtering policy for a rule requires:

HTTP filtering settings overview

The following table provides information about the more complex settings required for configuring headers and URL blocking in an HTTP policy for a rule.

Setting Description

Maximum headers length (bytes)

This setting applies to all rules; if you change it in one rule, it is changed in all rules. Reducing the allowed header size mitigates the risk of attacks that require complex and long headers, such as, buffer overflow attacks and some denial of service attacks. However, setting the maximum headers length too low could impact some legitimate applications that use long headers. It is recommended that you start with a limit of 10,000 bytes, and increase it only if you find that required applications are being blocked.

Allow any payload length

By limiting the request payload, you can restrict the amount of data a user can POST into your Web site in a Web publishing scenario. To determine what limit to set, estimate the maximum size of a file that would constitute a legitimate POST based on your site usage, and use that as the allowed payload length. This assumes that any POST larger than the limit you defined is a potential attack.

Maximum query length (bytes)

A query is the part of URL that follows the question mark (?). You may want to limit the query length if you learn of an attack based on a long query string. By default, the maximum query length is set to 10240. Long queries and URLs are a known attack vector for Internet worms. These worms send a long GET request and use the URL to embed their payload.

Verify normalization

Web servers receive requests that are URL encoded. This means that certain characters may be replaced with a percent sign (%) followed by a number. For example, %20 corresponds to a space, so a request for http://myserver/My%20Dir/My%20File.htm is the same as a request for http://myserver/My Dir/My File.htm. Normalization is the process of decoding URL-encoded requests. Because the % can be URL encoded, an attacker can submit a carefully crafted request to a server that is basically double-encoded. If this occurs, the Web server may accept a request that it would otherwise reject as not valid. When you select Verify Normalization, the HTTP filter normalizes the URL twice. If, after the second normalization, the URL is different to the URL from the first normalization, the filter rejects the request. This prevents attacks that rely on double-encoded requests.

Block high bit characters

These are typically characters from languages that require more than 8 bits to represent the characters of the language, and therefore use 16 bits. For example, URLs that contain a double-byte character set (DBCS) or Latin 1 characters will be blocked. While this can help block some attacks, it may also block requests and responses that contain characters from one of several languages that require high-bit characters. When you select Block high bit characters, this can impact scenarios such as, Outlook Web Access publishing, Microsoft Windows SharePoint Portal Server publishing, and any scenario in which a GET request passes a parameter that includes a character from a DBCS.

Via Header

Via headers provide a way for proxy servers that are in the path of a request to ensure that they are also included in the path of the response. Each server along the request's path can add its own Via header. Each sender along the response path removes its own Via header, and forwards the response to the server specified in the next Via header on the stack. For example, you can use this feature to avoid disclosing your Forefront TMG server name in a response.

Related Topics