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:
- When internal clients access HTTP objects
(HTML pages and graphics, or other data that can be transferred
using the HTTP protocol) on another network (usually the Internet)
through the Forefront TMG computer, access is controlled by
Forefront TMG access rules. An HTTP policy can be applied to each
access rule using the HTTP filter.
- When external clients access HTTP objects on
a Web server that is published through the Forefront TMG server,
access is controlled by Forefront TMG Web publishing rules. An HTTP
policy can be applied to each Web publishing rule using the HTTP
filter.
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:
- Setting a maximum number of bytes for a
header, payload, URL, or query, as well as blocking requests with
URLs that contain specific characters. See HTTP
filtering settings overview for a description of some of the
settings required for configuring headers and URL blocking in an
HTTP policy.
- Blocking specific HTTP methods (verbs). HTTP
methods (also known as HTTP verbs) are instructions sent in a
request message that notifies an HTTP server of the action to
perform on the specified resource. An example of this would be to
block POST, so that internal clients cannot post data to an
external Web page. This is useful in a secure network scenario
where you want to prevent sensitive information from being posted
on a web site. This can also be useful in Web publishing, to
prevent hackers from posting malicious material to your web
site.
- Blocking specific extensions—You can allow
all extensions or only specific ones. For secure configuration, it
is recommended that you only allow selected extensions. For
example, if you are publishing a web site, the web site designer or
Web server administrator can define a list of extensions that are
required for site functionality. A typical use of extension
blocking is to block executable (.exe) files.
- Blocking specific HTTP headers.
- Blocking specific signatures in the headers
or body.
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. |