HTTP Filtering in ISA Server 2004

Microsoft ISA Server 2004

Introduction

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:

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:

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:

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

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

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

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

HTTP Policy Walk-through Procedure 2: Configure HTTP Policy

General Tab

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

To configure HTTP policy, follow this procedure.

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.

To configure HTTP methods, follow this procedure.

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.

To specify file extensions, follow this procedure.

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.

To specify headers, follow this procedure.

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.

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.

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. The ISA Server Preventative Measures website (http://www.microsoft.com) will periodically provide signatures that you can use to block specific attacks. You can also 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.

Searching for a Signature

To search for a signature, follow this procedure.

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.

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.

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:

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.

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.

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

Note 2
Blocking .dll file extensions for Outlook Web Access will block access to the online spelling checker that is built into Outlook Web Access.

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

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.

\ScriptDirectory\HTTPFilterConfig.vbs import RuleName  
\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>