HTTP Policy Walk-through Procedure 2: Configure HTTP Policy
The HTTP policy properties are accessed through the five tabs on the properties dialog box. General information about configuring the policy is provided in this topic. We recommend that if you are not going to develop a specific HTTP policy for Web publishing and Exchange Web Client Access publishing, you should, at a minimum, configure HTTP policy as described in Typical HTTP Policies for Web and Outlook Web Access Publishing Rules.
After you make changes to the HTTP policy, you must click Apply in the ISA Server details pane to apply the changes.
The figure shows the default settings on the General tab of the HTTP policy properties.
To configure HTTP policy, follow this procedure.
In Request Headers, in Maximum headers length (bytes), specify the maximum number of bytes that a request can have in its headers (URL and headers) before it is blocked. This setting applies to all rules, so 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. If you set the maximum headers length too low, it could impact some legitimate applications that use long headers. We recommend that you start with a limit of 10,000 bytes, and increase it only if you find that needed applications are being blocked.
In Request Payload, if you want to block requests exceeding a specified maximum payload length, clear the Allow any payload length (bytes) check box. Then, in Maximum payload length (bytes), specify the maximum number of bytes.
By limiting the request payload, you can restrict the amount of data a user can POST into your website 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.
In URL Protection, in Maximum URL length (bytes), type the maximum URL length allowed. Requests with URLs exceeding this value will be blocked.
In Maximum query length (bytes), type the maximum query length allowed in a request. Requests with queries exceeding this value will be blocked.
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.
Select Verify normalization if you want to block requests with URLs containing escaped characters after normalization.
Web servers receive requests that are URL encoded. This means that certain characters may be replaced with a percent sign (%) followed by a particular number. For example, %20 corresponds to a space, so a request for https://myserver/My%20Dir/My%20File.htm is the same as a request for https://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, Internet Information Services (IIS) may accept a request that it would otherwise reject as not valid. When you select Verify Normalization, the HTTP filter normalizes the URL two times. If the URL after the first normalization is different from the URL after the second normalization, the filter rejects the request. This prevents attacks that rely on double-encoded requests.
Note that while we recommend that you use the Verify Normalization function, it may also block legitimate requests that contain a %.
Select Block high bit characters to specify that URLs with high-bit characters will be blocked. This can help block some attacks on Web servers running Internet Information Services (IIS), but may also block requests and responses that contain characters from one of several languages that require high-bit characters.
In executables, select Block responses containing Windows executable content to specify that responses containing Windows executable content (responses that begin with MZ) will be blocked.
The figure shows the Methods tab of the HTTP policy properties, and the Method dialog box that appears when you click Add to add a method. An HTTP method (also known as an HTTP verb) is an instruction sent in a request message that notifies an HTTP server of the action to perform on the specified resource. For example, GET specifies that a resource is being retrieved from the server.
On this tab, you can specify whether the rule will block HTTP requests based on the request method, such as POST, GET, or HEAD.
To configure HTTP methods, follow this procedure.
In Specify the action taken for HTTP methods, select one of the following:
- Allow all methods. No blocking according to method will be applied.
- Allow selected methods. All requests will be blocked except those with specified methods. We recommend that you only allow selected methods, because this is the most secure configuration. For examples of this approach, see Typical HTTP Policies for Web and Outlook Web Access Publishing Rules.
- Block specified methods (allow all others). All requests will be allowed, except those with methods specified in the list.
Click Add to add a method to the list, Edit to edit the selected method, or Remove to delete the selected method. When you click Add, the Method dialog box opens as shown. Provide the method (case-sensitive) and a description, and then click OK.
An example of blocking by method 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 website. This can also be useful in Web publishing, to prevent hackers from posting malicious material to your website. For other examples of method blocking, see Typical HTTP Policies for Web and Outlook Web Access Publishing Rules.
The figure shows the Extensions tab of the HTTP policy properties, and the Extension dialog box that appears when you click Add to add a method. On this tab, you can specify whether the rule will block HTTP requests based on as requested file extension, such as .exe or .asp.
To specify file extensions, follow this procedure.
In Specify the action taken for file extensions, select one of the following:
- Allow all extensions. No blocking according to requested file extensions will be applied.
- Allow selected extensions. All requests will be blocked except those with specified requested file extensions. We recommend that you only allow selected extensions, because this is the most secure configuration. For example, if you are publishing a website, the website designer or Web server administrator will be able to define a list of extensions that are required for site functionality.
- Block specified extensions (allow all others). All requests will be allowed, except those with requested file extensions specified in the list.
Click Add to add an extension to the list, Edit to edit the selected extension, or Remove to delete the selected extension. When you click Add, the Extension dialog box opens as shown. Provide the extension (case-sensitive) and a description, and then click OK.
A typical use of extension blocking is to block executable (.exe) files. For other extension blocking examples, see Typical HTTP Policies for Web and Outlook Web Access Publishing Rules.
The figure shows the Headers tab of the HTTP policy properties. On this tab you can specify whether requests or responses will be blocked based on the presence of specific headers.
To specify headers, follow this procedure.
In Headers, list the headers that will be blocked.
Click Add to add a header to the list, Edit to edit the selected header, or Remove to delete the selected header. When you click Add, the Header dialog box opens as shown. Specify whether the response or request header will be checked, provide the header, and then click OK.
In Server Header, specify how the server header will be returned in the response. The Server header is a response header that contains information such as the name of the server application and software version information, for example, HTTP: Server = Microsoft-IIS/6.0. The possible settings are:
- Send original header. The original header will be returned in the response.
- Strip header from response. No header will be returned in the response.
- Modify. A modified header will be returned in the response. If you select this option, in Change to, type the value that will appear in the response. We recommend that you modify the server header. The value that will appear in the response can be any value, because the server header is rarely used by clients.
In Via Header, specify how the Via header will be forwarded in the request or returned in the response. Via headers provide a way for proxy servers 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 ISA Server computer name in a response. The possible settings are:
- Send default. The default header will be used.
- Modify header in request and response. The Via header will be replaced with a modified header. If you select this option, in the Change to box, type the header that will appear instead of the Via header.
The figure shows the Signatures tab of the HTTP policy properties. On this tab, you can specify whether requests or responses will be blocked based on the presence of specific signatures in the headers or body.
A signature can be any string in the header or body. We recommend that you choose strings that are specific enough to block only those requests and responses that you want to block. For example, if you add the letter "a" as a signature, any request or response containing "a" will be blocked, which would include many requests and responses. Similarly, including "Mozilla" in a signature would block most Web browsers. A more typical example signature would be User-Agent: adatum-software-abc. Signature examples are provided in Common Application Signatures.
The signatures list lists the signatures that will be blocked. To configure signatures, follow this procedure.
- Click Add to add a signature to the list, Edit to edit the selected signature, or Remove to remove the selected signature. When you have added signatures to the list, you can enable or disable specific signatures using the check boxes next to the signature names. If you select the Show only enabled search strings check box below the list, only the enabled signatures will be displayed in the list.
Information about how to determine a signature is provided in HTTP Policy Walk-through Procedure 3: Determine a Signature.