Microsoft Internet Security and Acceleration Server 2004

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

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.

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.

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.

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.

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

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

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.

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.

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 Block content containing these signatures

(Request URL) ..
./
\
:
%
&
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.

Exchang
Outlook e
Setting Mobile ActiveSy
and rule Outlook Web Access Access nc RPC over HTTP
General
tab

Maximum 32768 32768 32768 32768

headers
length

Maximum 10485760 1048576 65536 Any

payload 0
length

Maximum 16384 319 1024 16384

URL
length

Maximum 4096 13 512 4096

query
length

Verify Yes Yes Yes Yes

normaliza
tion

Block No Yes Yes Yes

high bit
character
s

Block Yes (Note 1) Yes Yes Yes

responses
containin
g
Windows
executabl
e content

Methods
tab

Allow BCOPYBDELETEBMOVEBPROPPATCHDELETEGETMKCOLM GETHEA OPTIONS RPC_IN_DATARP

only OVEPOLLPOSTPROPFINDPROPPATCHSEARCHSUBSCRIBE DPOST POST C_OUT_DATA
specified
methods

Extension
s tab

Action Block specified extensions (allow all others) Allow Allow Allow only
taken for only only specified
file specified specified extensions
extension extensio extensio
s ns ns

Extension .asax.ascs.bat.cmd.config.cs.csproj.dat.dll (Note 2).exe . . (dot) .dll

list (Note (dot).asp
1).htr.htw.ida.idc.idq.ini.licx.log.pdb.pol.printer.resource x
s.resx.shtm.shtml.stm.vb.vbproj.vsdisco.webinfo.xsd.xsx

Block No Yes Yes Yes

requests
containin
g
ambiguou
s
extension
s
Headers
Tab

Blocked None None None None

headers

Signature
s Tab

Blocked ./\.. (Note 3)% (Note 3)& (Note 3) ./\..%&: ./\..%: ./\..%&
signature
s:Request
URL

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>
© 2010 Microsoft Corporation. All rights reserved. Terms of Use | Trademarks | Privacy Statement