The figure shows the default settings on the General tab of the HTTP policy properties.

To configure HTTP policy, follow this procedure.

1. 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.
   

   Note:

   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.

2. 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.
   

   Note:
   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.

3. In URL Protection, in Maximum URL length (bytes), type the maximum URL length allowed. Requests with URLs exceeding this value will be blocked.
   
4. In Maximum query length (bytes), type the maximum query length allowed in a request. Requests with queries exceeding this value will be blocked.
   

   Note:
   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.

5. Select Verify normalization, if you want to block requests with URLs containing escaped characters after normalization.
   

   Note:

   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 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, 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 %.

6. 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.
   
7. 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.

1. 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.
     
2. 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.

1. 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.
     
   • Block requests containing ambiguous extensions. Requests whose file extension cannot be determined will be blocked.
     
2. 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.

1. In Headers, list the headers that will be blocked.
   
2. 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. Specify whether the response or request header will be checked, provide the header, and then click OK.
   
3. 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.
     
4. 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 (http://go.microsoft.com/fwlink/?linkid=31422).

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.

To install network monitor tools, follow this procedure.

1. On the ISA Server computer, click Start, point to Control Panel, and select Add or Remove Programs.
   
2. Click Add/Remove Windows Components to start the Windows Components Wizard.
   
3. Double-click Management and Monitoring Tools. Select Network Monitor Tools, click OK, and then click Next.
   
4. When the Windows Components Wizard completes, click Finish.
   

To search for a signature, follow this procedure.

1. On the ISA Server computer, open Network Monitor. Click Start, point to Administrative Tools, and select Network Monitor.
   
2. A Network Monitor message will remind you to select a network. Click OK to close the message.
   
3. In the Select a Network dialog box, expand Local Computer. Select Internal to trace for signatures used by clients. This will allow you to use those signatures to block client access to specific Internet services.
   
4. Network Monitor will capture all of the packets from the Internal network. You can filter the results after the capture has taken place, or create a filter before you start the capture, which is the approach used here. From the menu, click Capture and select Filter (or press F8). In the Capture Filter dialog box, select the entry INCLUDE *ANY < - > *ANY, and then click Edit.
   
   
5. Click Edit Addresses, and under Add click Address. In the Address Expression dialog box, click Edit Addresses.
   
6. In the Address Database dialog box, click Add to open the Address Information dialog box.
   
   
7. In the Address Information dialog box, provide the name of the client computer. Provide the IP address of the client computer in Address, and from the Type drop-down list select IP, and then click OK.
   
   
8. In the Address Database dialog box, click Close.
   
   
9. In Address Expression, verify that the Include option is selected. In the Station 2 column, select the client that you just created. Leave Direction as default (both directions), choose the destination in the Station 1 column to be the ISA Server computer, and then click OK.
   
   
10. Click OK to close the Capture Filter dialog box.
    
11. If there is a large amount of traffic between those two computers, you may need to increase the capture buffer. From the menu, click Capture and select Buffer Settings. In the Capture Buffer Settings dialog box, increase the Buffer Size. Click OK.
    
12. On the client, close all of the applications except for the one for which you are interested in capturing a signature to use in the HTTP policy.
    
13. From the Network Monitor menu, click Capture and select Start (or press F10).
    
14. On the client computer, start the application. For example, sign in to MSN Instant Messenger or AOL Instant Messenger.
    
15. From the Network Monitor menu, click Capture and select Stop and View (or press SHIFT+F11). Inspect the packets that were captured. Typically, the fourth packet (after the handshake packets SYN SYNACK and ACK) will be an HTTP request packet from the client computer, which will contain the information you are looking for, although you may have to look in later packets.
    
    
16. Double-click the packet to view its details. Look for a unique signature related to the application you want to block. If the packet has been parsed properly by Network Monitor, you can view and click all of the headers separately in the details pane (the center pane), and see the full signature in the Hex pane (the bottom pane). Otherwise, you may have to search for the signature in the Hex pane.
    

After you have determined the signature, you can follow the steps in HTTP Policy Walk-through Procedure 2: Configuring HTTP Policy to use the signature in your HTTP policy.

You can also edit the log filter so that only access denied by a specific rule is displayed in the log. To do so, follow these steps.

1. In the Microsoft ISA Server Management console tree, select Monitoring.
   
2. In the Monitoring details pane, select the Logging tab.
   
3. In the task pane, on the Tasks tab, click Edit Filter to open the Edit Filter dialog box. In Filter by, select Rule from the drop-down list box. In Condition, select Equals, and in Value, select the name of the rule you want to include in the filter.
   
   
4. Click Add To List and then click Start Query.
   

Note:
Changes to the log filter expressions, and new expressions that you create, are not saved until you click Start Query in the Edit Filter dialog box.