HTTP Filtering in ISA Server 2004

Microsoft® Internet Security and Acceleration (ISA) Server 2004 provides granular control over Hypertext Transfer Protocol (HTTP) communication. This control is provided in the form of an HTTP filter, an application-layer filter that examines HTTP commands and data, through which you set HTTP policy. The HTTP filter screens all HTTP traffic that passes through the ISA Server computer, and only allows compliant requests to pass through. This significantly improves the security of your Web servers, by helping ensure that they only respond to valid requests. It also enables you to control the specifics of ISA Server client Internet access.

HTTP filtering can be applied in two general scenarios:

  • Clients on a source network accessing HTTP objects (HTML pages and graphics, or other data that can be transferred using the HTTP protocol) on another network through the ISA Server computer. This access is controlled by ISA Server access rules, to which an HTTP policy can be applied using the HTTP filter.
  • Clients on the Internet accessing HTTP objects on a Web server that is published through the ISA Server computer. This access is controlled by ISA Server Web publishing rules, to which an HTTP policy can be applied using the HTTP filter.

HTTP filtering in ISA Server is rule specific, so that you can apply different levels and types of filtering depending on the specific requirements of your firewall policy. 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.

This document describes HTTP filtering in general terms and how to configure the HTTP filter. It provides examples of HTTP policies for Web publishing and Outlook® Web Access publishing. It also describes how to use the HttpFilterConfig.vbs script to import the example policies.

Note

Comparing the HTTP filter and URLScan
ISA Server 2000 Feature Pack 1 included the URLScan tool, which provided similar functionality as the HTTP filter. The main difference between URLScan and the HTTP filter is that URLScan applied to all HTTP traffic, whereas the HTTP filter can be configured on a per-rule basis. This gives you greater control over your HTTP policy.
Another difference is that the HTTP filter does not include this functionality from the URLScan tool:
EnableLogging
PerProcessLogging
AllowLateScanning
PerDayLogging
RejectResponseUrL
UseFastPathReject
DenyUrlSequences
Logging is incorporated as a separate field (FilterAction) in ISA Server logging.
RejectResponseURL is a mechanism used by URLScan to redirect the requesting client to a different page. ISA Server includes error response pages.
UseFastPathReject was an option to simply drop the request, rather than using the RejectResponseURL
DenyUrlSequences is replaced by the Signatures tab of the HTTP filter properties.

Access Rules

Access rules determine how clients on a source network access resources on a destination network.

You can configure access rules to apply to all IP traffic, to a specific set of protocol definitions, or to all IP traffic except selected protocols.

ISA Server includes a list of preconfigured, well-known protocol definitions, including the Internet protocols that are most widely used. You can also add or modify additional protocols.

When a client requests an object, ISA Server checks the access rules. A request is processed only if an access rule specifically allows the client to communicate using the specific protocol and also allows access to the requested object.

Controlling Internet access depends primarily on the design and order of access rules.

After you create an access rule, you can view and edit all of its properties by double-clicking the rule in the Firewall Policy details pane. One of these properties is HTTP policy, in which you can configure HTTP settings for requests that match a specific allow access rule. You can also access HTTP policy settings by right-clicking a rule and selecting Configure HTTP.

ISA Server is an application-layer firewall, and applies an application filter to HTTP traffic. Because ISA Server can examine HTTP requests, applications that are tunneled through HTTP can be blocked, depending on how you configure the HTTP application filter. The HTTP application filter provides granular control over the HTTP requests allowed by your firewall policy.

Note

HTTP filtering applies to allow rules, to limit what is allowed. It cannot be applied to deny rules.

Web Publishing Rules

ISA Server uses Web publishing rules to relieve the concerns associated with publishing Web content without compromising network security. Web publishing rules determine how ISA Server will intercept incoming requests for HTTP objects on a Web server, and how ISA Server will respond on behalf of the Web server. Requests are forwarded to the Web server, located behind the ISA Server computer. If possible, the request is serviced from the ISA Server cache.

Web publishing rules essentially map incoming requests to the appropriate Web servers. Web publishing rules also enable you to configure advanced filtering functionality, thereby publicizing your Web-based information while securing it from malicious access.

HTTP Policy Settings

HTTP policy encompasses the following settings:

  • Request header maximum length
  • Request payload length
  • URL protection
  • Executable blocking
  • Denied methods
  • Specified actions for specific file extensions
  • Deny specific headers
  • Modify Server and Via headers
  • Block high bit characters
    When you select Block high bit characters, URLs that contain a double-byte character set (DBCS) or Latin 1 characters will be blocked. These are typically characters from languages that require more than 8 bits to represent the characters of the language, and therefore use 16 bits. This can impact scenarios such as Outlook Web Access publishing, SharePoint™ Portal Server publishing, and any scenario in which a GET request passes a parameter that includes a character from a DBCS.
  • Deny specific signatures
    When you block specific signatures, you are blocking applications that tunnel traffic over HTTP and can be characterized by specific patterns in request headers, response headers, and body (for example, Windows Messenger). HTTP signature blocking will not block applications that use different types of content encoding or range requests.
    Signature examples are provided in Common Application Signatures (https://go.microsoft.com/fwlink/?linkid=31422).
    About Range Requests
    Range requests are requests that specify ranges of data requested for the response. They provide control over continuing downloads that were interrupted, downloading materials sequentially as the user pages through them, or downloading sections of materials as needed.
    It is assumed that all HTTP requests and responses are Uniform Transformation Format-8 (UTF-8, a transformation of Unicode character encoding) encoded. If a different encoding scheme is used, signature blocking cannot be performed.
    About HTTP Request and Response Headers
    HTTP requests and responses use headers to send information about the HTTP messages. A header is a series of lines, with each line containing a name followed by a colon and a space, and then a value.

HTTP policy can be applied to client Internet access, and to Web publishing:

  • In client Internet access, you may want to limit client access to specific services available on the Internet. For example, you may want to block a peer-to-peer file sharing service.
  • In Web publishing, you want to use HTTP filtering to block requests that may contain malicious code. Attacks are often known to carry specific signatures and extensions. For example, the Code Red virus made use of the extension .ida. If you block those signatures and extensions, the attacks will not reach your Web servers.

Solutions

You can configure the HTTP policy to address a variety of client access and Web publishing scenarios. This section provides a walk-through on how to configure HTTP policy in general, and then provides policy examples for several scenarios. Specifically, this section includes the following topics:

  • HTTP Policy—Walk-through
  • Blocking Examples
  • Typical HTTP Policies for Web and Outlook Web Access Publishing Rules
  • HTTP Policy and SSL Connections

HTTP Policy—Walk-through

This walk-through guides you through the steps necessary to configure HTTP policy.

HTTP Policy Walk-through Procedure 1: Access the HTTP Policy Properties

  1. HTTP policy is applied on a per-rule basis. You access the policy through each rule for which you want to apply an HTTP policy.

    Important

    The Maximum headers length setting on the General tab of the Configure HTTP policy for rule dialog box is applied to all rules globally. This setting configures the number of bytes allowed in a request header before a request is blocked.
    The remaining settings on the General tab and on the other tabs are applied on a per-rule basis.
    To access the dialog box to configure HTTP policy for an access rule or a Web publishing rule, follow this procedure.

  2. Open Microsoft ISA Server Management, expand the ISA Server computer node, and click Firewall Policy.

  3. In the details pane, right-click the rule and select Configure HTTP.

HTTP Policy Walk-through Procedure 2: Configure HTTP Policy

  1. 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 Outlook Web Access publishing, you should, at a minimum, configure HTTP policy as described in Typical HTTP Policies for Web and Outlook Web Access Publishing Rules.
  2. After you make changes to the HTTP policy, you must click Apply in the ISA Server details pane to apply the changes.
General Tab

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

Cc302627.62dbec40-0afb-41a2-8ebd-c55053f1bfc9(en-us,TechNet.10).gif

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

  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.

Methods Tab

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.

Cc302627.bb0bd6d5-0fda-4077-b749-2af195bfbe2c(en-us,TechNet.10).gif

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.

Extensions Tab

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.

Cc302627.dfc59ae5-31ff-4591-8983-29489e5de81a(en-us,TechNet.10).gif

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.

Headers Tab

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.

Cc302627.c99c8139-f616-4bdb-af86-f65863a07236(en-us,TechNet.10).gif

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.
Signatures Tab

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.

Cc302627.e6719c29-1d28-4aed-8556-24a7fe6c5b3b(en-us,TechNet.10).gif

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 (https://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.

HTTP Policy Walk-through Procedure 3: Determine a Signature

To block specific traffic based on a signature, you must know the signature for that traffic so that you can add it to the HTTP policy. You can determine a signature by monitoring network traffic. You can use any network traffic monitoring software to determine a signature. This example uses Microsoft Network Monitor.

Important

Because some network traffic monitoring tools may introduce a security risk, we recommend that you use these tools only in a laboratory environment, and never in a production environment.

Follow these steps to determine a signature. This procedure takes place primarily on the ISA Server computer, and also requires a client that accesses the Internet through the ISA Server computer.

Installing Network Monitor Tools

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.
Searching for a Signature

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.
    Cc302627.e89cb6a4-b910-4980-8e96-f1dab0504f7b(en-us,TechNet.10).gif
  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.
    Cc302627.fbbb5969-2e4e-46e6-9753-68d0477f9810(en-us,TechNet.10).gif
  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.
    Cc302627.4692ec61-950e-4bd7-8d29-58a2baf88549(en-us,TechNet.10).gif
  8. In the Address Database dialog box, click Close.
    Cc302627.fe1e46ae-8ee9-4610-a312-043eca514ace(en-us,TechNet.10).gif
  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.
    Cc302627.f74b20c8-0400-4224-bdf7-dbd15e5e97d2(en-us,TechNet.10).gif
  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.
    Cc302627.0526ed77-9ef1-4788-aaf9-8f920fdc527d(en-us,TechNet.10).gif
  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.

HTTP Policy Walk-through Procedure 4: Test the HTTP Policy

After you have configured your HTTP policy, you should test it to determine if you are blocking what you intended to block. This is an important step, because you could have inadvertently blocked important applications that you want to remain unblocked.

On the client computer, run the application you are trying to block, such as an instant messaging program. If the application fails to connect, you have succeeded in blocking it. In browser-based applications, you will receive a Web page that indicates the application was blocked by the HTTP filter. To check how other applications were blocked, you can run Network Monitor before attempting to run the application. The Response to Client packet will indicate that the application was blocked by the HTTP filter.

You can also view the ISA Server log to see what has been blocked by the HTTP policy.

To view the information in the log, perform the following 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 the list of filter conditions, select Log Time. From the Condition drop-down list box, select the time period you are interested in (for example, Last Hour), click Update, 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.

  1. In the log that appears, right-click any column heading, and click Add/Remove Columns.
    Cc302627.148a4200-8f31-46cb-8b3b-d05d6fc414e7(en-us,TechNet.10).gif
  2. In the Add/Remove Columns dialog box, select the column HTTP Status Code, click Add, and then click OK.
  3. In the HTTP Status Code column for a denied request, you will see an entry that the request was rejected by the HTTP filter. Note that you can sort by any column’s data by clicking the column heading.

Next, run a variety of other applications on the client computer, to verify that they still work. If they do not, and if the ISA Server log shows that the HTTP filter has blocked them, you will have to modify your HTTP policy accordingly. Specifically, you should verify that the signatures you are using in the HTTP policy are specific enough.

Filtering the Log by Rule

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.
    Cc302627.ef16201f-71b0-43dc-9a86-591f47c044a2(en-us,TechNet.10).gif
  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.

Blocking Examples

This topic provides some examples of blocking approaches. Blocking Access to Websites Containing Malicious Code

You can block access to sites that might contain malicious code, if you are aware of common malicious code. For example, a Web page containing this code will cause Internet Explorer to use up CPU resources in an infinitely nested iframe element:

<iframe src="?"/>

To prevent access to Web pages containing this code, use a signature that searches in the response body for the text <iframe src="?"/>. You may use the default setting that limits the byte range of the search to the first 100 bytes, so as not to impact performance.

Blocking RPC Over HTTP

To block RPC over HTTP, block these methods:

  • RPC_IN_DATA
  • RPC_OUT_DATA

This will not apply to Outlook 2003, because it uses RPC over HTTPS.

Typical HTTP Policies for Web and Outlook Web Access Publishing Rules

If you do not want to create your own HTTP policy, start with these baseline HTTP policies for Web and mail server publishing, and modify them to match your corporate policy.

If you do not want to configure these policies through the ISA Server user interface (UI), the Extensible Markup Language (XML) document and instructions for importing each of the policies are provided in Appendix A: Importing Typical HTTP Policies for Web and Outlook Web Access Publishing Rules.

Baseline Web Publishing HTTP Policy

For Web publishing, create an HTTP policy with the parameters shown in this table.

Tab Parameter

General

Maximum headers length is 32768.

Allow any payload length is selected.

Maximum URL length is 260.

Maximum query length is 4096.

Verify normalization is selected.

Block high bit characters is not selected.

Methods

Allow only specified methods:

GET

HEAD

POST

Extensions

Block specified extensions (allow all others):

.exe

.bat

.cmd

.com

.htw

.ida

.idq

.htr

.idc

.shtm

.shtml

.stm

.printer

.ini

.log

.pol

.dat

Headers

No changes from the default.

Signatures

(Request URL)

Block content containing these signatures

..

./

\

:

%

&

Baseline Mail Server Publishing HTTP policy

You should create an HTTP policy based on your corporate policy and security needs. The policies provided here are baseline, example HTTP policies for Outlook Web Access, Outlook Mobile Access, Exchange ActiveSync, and RPC over HTTP.

Setting and rule Outlook Web Access Outlook Mobile Access Exchange ActiveSync RPC over HTTP

General tab

 

 

 

 

Maximum headers length

32768

32768

32768

32768

Maximum payload length

10485760

10485760

65536

Any

Maximum URL length

16384

319

1024

16384

Maximum query length

4096

13

512

4096

Verify normalization

Yes

Yes

Yes

Yes

Block high bit characters

No

Yes

Yes

Yes

Block responses containing Windows executable content

Yes (Note 1)

Yes

Yes

Yes

Methods tab

 

 

 

 

Allow only specified methods

BCOPYBDELETEBMOVEBPROPPATCHDELETEGETMKCOLMOVEPOLLPOSTPROPFINDPROPPATCHSEARCHSUBSCRIBE

GETHEADPOST

OPTIONSPOST

RPC_IN_DATARPC_OUT_DATA

Extensions tab

 

 

 

 

Action taken for file extensions

Block specified extensions (allow all others)

Allow only specified extensions

Allow only specified extensions

Allow only specified extensions

Extension list

.asax.ascs.bat.cmd.config.cs.csproj.dat.dll (Note 2).exe (Note 1).htr.htw.ida.idc.idq.ini.licx.log.pdb.pol.printer.resources.resx.shtm.shtml.stm.vb.vbproj.vsdisco.webinfo.xsd.xsx

. (dot).aspx

. (dot)

.dll

Block requests containing ambiguous extensions

No

Yes

Yes

Yes

Headers Tab

 

 

 

 

Blocked headers

None

None

None

None

Signatures Tab

 

 

 

 

Blocked signatures:Request URL

./\.. (Note 3)% (Note 3)& (Note 3)

./\..%&:

./\..%:

./\..%&

Note

Blocking .exe file extensions and enabling Block responses containing Windows executable content for Outlook Web Access will block access to the S/MIME control. If the S/MIME control is required for Outlook Web Access on Exchange Server 2003, do not include .exe in the blocked extensions list or enable Block responses containing Windows executable content.
Blocking .dll file extensions for Outlook Web Access will block access to the online spelling checker that is built into Outlook Web Access.
Including the strings "..", "%", and "&" can prevent certain types of potential attacks but it will also reduce access to certain e-mail messages. An e-mail message subject line forms part of the URL to access the message and thus any e-mail message containing one of these characters will be blocked. A balance must be found between extra security and functionality. Do not include the ":" character in this list because this will block access to the majority of e-mail messages. Many message subject lines contains RE: and FW: if they are replies or forwards. Including the string "" can prevent access to the Outlook Web Access Add to contacts feature. The URL to create the contact represents "[", which appears in some e-mail addresses, as "[", which is blocked by the HTTP filter.

HTTP Policy and SSL Connections

If you allow HTTPS traffic to any destination, HTTP policy can be bypassed. Some applications establish a Secure Sockets Layer (SSL) tunnel between an internal client and an Internet server, and then allow the client application to communicate with the server over that tunnel, thus overriding your HTTP policy. To prevent this, either create an access rule allowing HTTPS access only to specific, trusted sites, or a deny access rule, denying access to sites which are known to provide a tunneling service. These access rules will be from the client network, typically the Internal network, to a specific URL set (the set of URLs that are allowed or denied, depending on the approach you take). For more information about access rules and URL sets, see the ISA Server product documentation.

You could try to block access to the HTTP tunneling site using the signature for the site. However, these signatures may be frequently changed by the tunneling sites to defeat HTTP filtering. For this reason, limiting HTTPS access using access rules is a more reliable approach to blocking HTTPS tunneling, and will require less maintenance.

Appendix A: Importing Typical HTTP Policies for Web and Outlook Web Access Publishing Rules

In this section, the XML documents for the HTTP policies described in Typical HTTP Policies for Web and Outlook Web Access Publishing Rules are provided. You can import these policies into ISA Server using the following procedure.

  1. Copy the XML document to Notepad, and save it as an .xml file with a descriptive name, such as HTTP Policy for Web Publishing.xml.
  2. On the ISA Server CD, browse to the folder \sdk\samples\admin. Locate the script HttpFilterConfig.vbs.
  3. From a command prompt, run the script HttpFilterConfig.vbs using the following syntax:

Note

The line has been split into multiple lines for readability. However, while trying it out on a system you must enter it as one line without breaks.

  1. \ScriptDirectory\HTTPFilterConfig.vbs import RuleName
  2. \somedirectory\HTTPPollicyXmlFileName

ScriptDirectory is the location where the script is, either the \sdk\samples\admin folder on the CD, or a location on the local hard drive, if you choose to copy the script there. RuleName is the name of the Web publishing or Outlook Web Access publishing rule to which you want to import the HTTP policy configuration, and somedirectory is the location where the HTTP policy .xml file is stored. HTTPPolicyXmlFileName is the name of the .xml file, such as HTTP Policy for Web Publishing.xml. For example, you might type the following at a command prompt:

Note

The line has been split into multiple lines for readability. However, while trying it out on a system you must enter it as one line without breaks.

F:\sdk\samples\admin\HTTPFilterConfig.vbs import My Web Publishing Rule

c:\ISAServerXml\HTTPPolicyXmlFileName

The script automatically applies the changes.

Note

The Maximum Headers Length parameter, which is applied globally to all rules, is not imported or exported by the HttpFilterConfig.vbs script. You should configure that setting through ISA Server Management.You can use the HttpFilterConfig.vbs script to export an existing HTTP policy configuration. The syntax is as shown in the import example, but using the word export rather than import.

XML Document for Baseline Web Publishing HTTP Policy

Following is the XML document for HTTP policy described in Baseline Web Publishing HTTP Policy.

Note

The line has been split into multiple lines for readability. However, while trying it out on a system you must enter it as one line without breaks.

<Configuration BlockExecutables="false" ViaHeaderAction="0"

NewViaHeaderValue="" ServerHeaderAction="0"

NewServerHeaderValue=""

MaxRequestBodyLen="-1"><UrlValidation NormalizeBeforeScan="true"

VerifyNormalization="true" AllowHighBitCharacters="true"

BlockDotInPath="false" MaxLength="260" MaxQueryLength="4096">

<Extensions AllowCondition="2">

<Extension Value=".exe" Description=""/>

<Extension Value=".bat" Description=""/>

<Extension Value=".cmd" Description=""/>

<Extension Value=".com" Description=""/>

<Extension Value=".htw" Description=""/>

<Extension Value=".ida" Description=""/>

<Extension Value=".idq" Description=""/>

<Extension Value=".htr" Description=""/>

<Extension Value=".idc" Description=""/>

<Extension Value=".shtm" Description=""/>

<Extension Value=".shtml" Description=""/>

<Extension Value=".stm" Description=""/>

<Extension Value=".printer" Description=""/>

<Extension Value=".ini" Description=""/>

<Extension Value=".log" Description=""/>

<Extension Value=".pol" Description=""/>

<Extension Value=".dat" Description=""/>

</Extensions>

</UrlValidation>

<Verbs AllowCondition="1">

<Verb Value="GET" Description=""/>

<Verb Value="HEAD" Description=""/>

<Verb Value="POST" Description=""/>

</Verbs>

<RequestHeaders/>

<ResponseHeaders/>

<DeniedSignatures>

<Signature Name=".." Description="" SearchInType="0" SearchInHeader=""

From="1" To="100" Pattern="[..]" FormatIsText="true" Enabled="true"/>

<Signature Name="./" Description="" SearchInType="0" SearchInHeader=""

From="1" To="100" Pattern="[./]" FormatIsText="true" Enabled="true"/>

<Signature Name="\" Description="" SearchInType="0" SearchInHeader=""

From="1" To="100" Pattern="[\]" FormatIsText="true" Enabled="true"/>

<Signature Name=":" Description="" SearchInType="0" SearchInHeader=""

From="1" To="100" Pattern="[:]" FormatIsText="true" Enabled="true"/>

<Signature Name="%" Description="" SearchInType="0" SearchInHeader=""

From="1" To="100" Pattern="[%]" FormatIsText="true" Enabled="true"/>

<Signature Name="&" Description="" SearchInType="0" SearchInHeader=""

From="1" To="100" Pattern="[&]" FormatIsText="true" Enabled="true"/>

</DeniedSignatures>

</Configuration>

XML Document for Baseline Outlook Web Access HTTP Policy

Following is the XML document for the Outlook Web Access HTTP policy described in Baseline Mail Server Publishing HTTP policy.

Note

Use this code without line breaks.

<Configuration BlockExecutables="true" ViaHeaderAction="0"

NewViaHeaderValue="" ServerHeaderAction="0"

NewServerHeaderValue="" MaxRequestBodyLen="10485760">

<UrlValidation NormalizeBeforeScan="true" VerifyNormalization="true"

AllowHighBitCharacters="true" BlockDotInPath="false"

MaxLength="16384" MaxQueryLength="4096">

<Extensions AllowCondition="2">

<Extension Value=".asax" Description=""/>

<Extension Value=".ascs" Description=""/>

<Extension Value=".bat" Description=""/>

<Extension Value=".cmd" Description=""/>

<Extension Value=".com" Description=""/>

<Extension Value=".config" Description=""/>

<Extension Value=".cs" Description=""/>

<Extension Value=".csproj" Description=""/>

<Extension Value=".dat" Description=""/>

<Extension Value=".dll" Description=""/>

<Extension Value=".exe" Description=""/>

<Extension Value=".htr" Description=""/>

<Extension Value=".htw" Description=""/>

<Extension Value=".ida" Description=""/>

<Extension Value=".idc" Description=""/>

<Extension Value=".idq" Description=""/>

<Extension Value=".ini" Description=""/>

<Extension Value=".licx" Description=""/>

<Extension Value=".log" Description=""/>

<Extension Value=".pdb" Description=""/>

<Extension Value=".pol" Description=""/>

<Extension Value=".printer" Description=""/>

<Extension Value=".resources" Description=""/>

<Extension Value=".resx" Description=""/>

<Extension Value=".shtm" Description=""/>

<Extension Value=".stm" Description=""/>

<Extension Value=".vb" Description=""/>

<Extension Value=".vbproj" Description=""/>

<Extension Value=".vsdisco" Description=""/>

<Extension Value=".webinfo" Description=""/>

<Extension Value=".xsd" Description=""/>

<Extension Value=".xsx" Description=""/>

</Extensions></UrlValidation><Verbs AllowCondition="1">

<Verb Value="BCOPY" Description=""/><Verb Value="BDELETE" Description=""/>

<Verb Value="BMOVE" Description=""/><Verb Value="BPROPPATCH" Description=""/>

<Verb Value="DELETE" Description=""/>

<Verb Value="GET" Description=""/><Verb Value="MKCOL" Description=""/>

<Verb Value="MOVE" Description=""/>

<Verb Value="POLL" Description=""/><Verb Value="POST" Description=""/>

<Verb Value="PROPFIND" Description=""/>

<Verb Value="PROPPATCH" Description=""/><Verb Value="SEARCH" Description=""/>

<Verb Value="SUBSCRIBE" Description=""/>

</Verbs><RequestHeaders/><ResponseHeaders/><DeniedSignatures>

<Signature Name="./" Description="" SearchInType="0" SearchInHeader="HTTP_"

From="1" To="100" Pattern="[./]" FormatIsText="true" Enabled="true"/>

<Signature Name="\" Description="" SearchInType="0" SearchInHeader="HTTP_"

From="1" To="100" Pattern="[\]" FormatIsText="true" Enabled="true"/>

<Signature Name=".." Description="" SearchInType="0" SearchInHeader="HTTP_"

From="1" To="100" Pattern="[..]" FormatIsText="true" Enabled="true"/>

<Signature Name="%" Description="" SearchInType="0" SearchInHeader="HTTP_"

From="1" To="100" Pattern="[%]" FormatIsText="true" Enabled="true"/>

<Signature Name="&" Description="" SearchInType="0" SearchInHeader="HTTP_"

From="1" To="100" Pattern="[&]" FormatIsText="true" Enabled="true"/>

</DeniedSignatures></Configuration>