Corporate networks are under constant attack from hackers. Attackers use increasingly sophisticated methods to steal data and disable network services. Application layer exploits using the HTTP protocol are popular among network attackers. Hackers leverage weaknesses in traditional packet filtering firewalls. The popular traditional packet filtering firewall can not perform sophisticated application layer filtering to block HTTP based attacks. ISA Server 2000 firewalls perform deep HTTP stateful inspection to protect Web and Outlook Web Access servers on the corporate network. Deep HTTP stateful inspection enables ISA Server 2000 firewalls to stop attacks at the network perimeter and prevent attackers from reaching the Web or OWA server.

This document discusses the problem of HTTP based attacks and how ISA Server 2000 deep HTTP stateful inspection blocks them using URLScan 2.5 for ISA Server 2000. Detailed information on how URLScan works and how to customize URLScan to protect Web and OWA servers on the corporate network is also included. Step by step information on how to install and configure URLScan completes the ISA Server 2000 stateful application layer filtering solution.

The Problem: Hackers Send Abnormal Requests to Attack IIS and OWA Web Sites

Corporate networks are under constant attack from hackers. Network attackers use a variety of techniques to compromise network firewalls and access servers and services on the corporate network. Web servers are the most common targets for malicious attacks. Companies may have one or more Web servers providing product information to partners and to the public at large. Hackers use network reconnaissance methods to find these servers and begin their attacks.

Hackers use sophisticated methods to steal and destroy data on corporate Web servers. Attackers now leverage inherent weaknesses in traditional packet filtering firewalls. These firewalls allow attackers to send abnormal commands and data to the Web server located on the corporate or perimeter network under corporate control. Packet filtering firewalls only see that the incoming connection is for TCP port 80 or TCP port 443 and allow the connection based on that assessment. Since the packet filtering firewall only evaluates the source and destination port and IP address, it passes the hacker’s exploits quickly to the corporate Web server.

Figure A depicts how the attack works through the traditional packet filtering firewall.

Traditional packet filter based firewalls move communications very quickly from the Internet edge into the corporate network and perimeter networks under corporate control. These firewalls are useful in that they provide:

Fast transfer of information to and from the corporate network
Simple access control based on source and destination port and IP address and simple stateful filtering (as opposed to stateful inspection, which they can’t perform)
Sophisticated IP routing features because of their IP router heritage
Peace of mind for organizations that do not fully understand the danger of application layer attacks

Internet intruders continue to refine their application layer attacks against Web servers. The traditional fast packet filtering firewall can not adequately protect against them. The solution is to either replace the traditional packet filtering firewall with an application layer aware firewall or keep the current firewall and place a powerful application aware firewall behind the current traditional firewall.

Figure B shows how an application layer firewall can correct for the weaknesses of the packet filter based firewall in front of it.

The Solution: URLScan 2.5 for ISA Server 2000

The solution to the problem of hackers hiding attacks inside the HTTP application layer commands and data is ISA Server 2000 URLScan 2.5. URLScan 2.5 is a powerful tool for protecting Web sites from invalid or deliberately malformed HTTP requests that can exploit potential weaknesses on Web sites. This document discusses how to install and configure URLScan 2.5 on ISA Server 2000 to protect web sites published via Web Publishing Rules.

Because the configuration of URLScan will be unique to each environment, this document attempts to provide guidelines for implementing URLScan configurations rather than providing a step by step set of configurations for all possible environments.

URLScan 2.5 for ISA Server installs as a Web application filter that inspects HTTP traffic for invalid or suspicious requests and allows or denies these requests on the basis of configurable settings. The advantage of using URLScan 2.5 on ISA Server 2000 is that all HTTP traffic can be statefully inspected at the application layer and suspicious traffic can be blocked before it reaches the protected network. ISA Server 2000 stops the malicious traffic at the perimeter.

For example, imagine an attacker who sends an HTTP request that appends a number of period (“..”) characters in combination with “\” or “/” characters to a request for a virtual directory. The requested virtual directory is likely to contain executable files, or permit files to be executed. Such an exploit is illustrated by the following log entry of an attempted Nimda attack:

GET /scripts/..\xc1\x9c../winnt/system32/cmd.exe?/c+dir

This invalid request represents a directory traversal attack. When Web servers are protected against directory traversal attacks by disallowing HTTP requests that have too many dots or slashes, attackers may attempt to get around this protection by substituting Unicode characters for the slashes (this vulnerability is known as the Unicode translation vulnerability).

Attackers can also send long URLs in order to exploit potential vulnerabilities in unchecked buffers (this is a buffer overflow attack). Hackers may also attempt attacks that exploit functionality of HTTP 1.1 verbs (also known as HTTP methods or commands), such as PUT or DELETE, to alter files in virtual directories.

To defend against these and similar attacks, you should minimize the IIS attack surface by applying the most recent security patches. You should also implement the suggestions and procedures outlined in the security configuration guidelines document, and/or upgrade to Windows 2003 and IIS 6.0, which provides significantly enhanced default security over previous versions of IIS.

You can significantly increase the level of security for your published Web sites by installing URLScan 2.5 on an ISA Server 2000 firewall. URLScan prevents invalid or suspect URLs from being forwarded to internal Web servers. This is true even when those servers are using IIS 6.0 and have been hardened against HTTP-request exploits using the IIS version of URLScan and other methods. Please see the TechNet document on URLScan 2.5 for IIS for a comparison of the features of URLScan 2.5 and the built-in security features of IIS 6.0.

Note:
Some entries in the URLScan.ini file have no effect on URLScan processing on ISA Server 2000. For example, URLScan 2.5 for ISA Server installs as a Web application filter that causes processing to occur immediately in the order specified in ISA Management console. Therefore, enabling the Allowlatescanning option in the URLScan.ini has no effect. Also, because ISA Server 2000 Destination Sets used in Web Publishing rules already eliminate the risk of directory traversal attacks, some options in the URLScan.ini will be superfluous. Nevertheless, these options should be configured as part of a comprehensive defense-in-depth strategy.

URLScan 2.5 is configured through entries in the URLScan.ini file. Two different versions of the URLScan.ini are included in URLScan 2.5 for ISA Server 2000: URLScan_owa.ini and URLScan_iis.ini. These files are used as templates for the URLScan.ini file settings applied to publishing Outlook Web Access and Web sites respectively. The main difference between these two template files is their level of protection.

Settings in the URLScan_iis.ini file are more restrictive than the settings in the URLScan_owa.ini file. In particular, the URLScan_owa.ini allows a greater range of HTTP 1.1 verbs (methods) to support WebDav methods required for Outlook Web Access. Using the URLScan_iis.ini file as the template for the URLScan.ini file causes remote access to Outlook Web Access to behalf erratically.

Note:
There can be only one URLScan 2.5 configuration for all the published Web servers on the ISA Server. If different published Web sites have different security requirements, you will have to use a more general and relaxed URLScan configuration on the ISA Server and install more specific configurations of URLScan on the Web servers themselves. This provides defense in depth and offloads some URLScan processing from the Web servers.

Placing ISA Server 2000 on Your Network

The ISA Server 2000 firewall can be the only firewall on your network, or you can integrate ISA Server 2000’s powerful application layer filtering protection with your existing firewall infrastructure. Some of the common ISA Server 2000 network topologies are:

ISA Server 2000 acting as front-end firewall
ISA Server 2000 acting as back-end firewall
ISA Server 2000 acting as front-end and back-end firewalls
ISA Server 2000 acting as application layer filtering gateway in a perimeter network

ISA Server 2000 Front-end Firewall Topology

Smaller organizations or organizations that do not already have a large investment in a current firewall infrastructure may prefer to make the ISA Server 2000 firewall a front-end firewall. The front-end firewall has a network interface on the corporate network and a network interface directly connected to the Internet. All communications into and out of the corporate network are exposed to ISA Server 2000’s deep application layer inspection.

The advantages of this configuration include:

All communications into and out of the corporate network are exposed to firewall policy
You only need to learn how to configure the ISA Server 2000 firewall software; this avoids the potential for firewall misconfiguration when multiple vendor firewalls are used
All inbound and outbound access can be controlled on a granular, user or group basis. Users only access the content and servers you want them to access, based on the rules you configure
This configuration is easy to set up and maintain

Figure D shows the network topology for the ISA Server 2000 front-end firewall placement.

ISA Server 2000 Back-end Firewall Topology

Organizations that already have an existing firewall infrastructure may prefer to leave the current firewalls in place and put the ISA Server 2000 firewall behind the current firewalls. This topology allows third party firewalls to provide high speed packet filtering (stateful filtering) before forwarding the remaining packets to the application aware ISA Server 2004 firewall. The network between the third party front-end firewalls is a perimeter network where publicly accessible services can be placed.

The third-party packet filtering firewalls have an interface directly connected to the Internet and an interface connected to a perimeter network between the third-party packet filtering firewalls and the ISA Server 2000 application layer aware firewall. The ISA Server 2000 firewall has an interface on the perimeter network and an interface on the protected, corporate LAN.

Advantages of this configuration include:

Organizations do not need to perform a major redesign of their current firewall infrastructures
Third party hardware-based firewalls can perform high-speed packet filtering. This offloads packet filtering overhead from the ISA Server 2000 firewall and increases the resources available on the ISA Server 2000 firewall to perform deep application layer inspection
Resources located on the corporate network are protected by the ISA Server 2000 firewall’s enhanced application layer inspection mechanisms
Granular inbound and outbound access control can be done on a user/group basis

ISA Server 2000 Front-end and Back-end Firewalls

The ISA Server 2000 front-end and back-end firewall configuration uses two ISA Server 2000 machines, one as the Internet edge firewall and the other as the corporate LAN edge firewall. The front-end ISA Server 2000 firewall has an interface directly connected to the Internet and an interface on the perimeter network between the firewalls. The back-end ISA Server 2000 firewall has an interface on the perimeter network and an interface on the protected, corporate LAN.

The advantages of this configuration include:

A single firewall system; this reduces the training overhead and the probability of a configuration error
Sophisticated application layer filtering protects hosts on the perimeter network and the corporate network
You can leverage Web Proxy chaining and firewall chaining to significantly increase access control to and from perimeter network servers and users on the internal network. This prevents attackers from using compromised servers on the perimeter network as a launch point for outbound attacks from the perimeter network
Granular outbound user/group based access control for hosts on both the corporate network and the perimeter network
Excellent support for highly secure VPN passthrough, allowing access to protected resources on the corporate network

ISA Server 2000 Application Layer Filtering Web Proxy in the Perimeter Network

Some organizations already have an existing firewall infrastructure that includes front-end and back-end firewalls. These organizations have a large investment in their current firewall infrastructures and prefer to leave them intact. You can still leverage ISA Server 2000’s application layer filtering features by making the ISA Server an application layer filtering proxy. This ISA Server 2000 proxy can be placed on the perimeter network between the front-end and back-end third party packet filtering firewalls or you can place the ISA Server 2000 application layer proxy on the corporate network.

Advantages of the application layer filtering proxy configuration include:

The ability to leave the current firewall infrastructure intact; you can “drop in” the ISA Server 2000 application layer filtering proxy virtually anywhere
The third party front-end and back-end packet filtering firewalls can pass packets at high speed while allowing the ISA Server 2000 to provide a very high level of security for communications passed through its application layer inspection mechanisms
A hardened ISA Server 2000 proxy can be placed on the perimeter network segment to reduce the attack surface
In reverse Web Proxy scenarios, the ISA Server 2000 application layer filtering proxy can forward user credentials across the back-end firewall to pre-authenticate remote users

Configuring URLScan 2.5 on ISA Server 2000

The URLScan.ini file contains a number of sections where various settings are configured. These sections and the various settings appropriate to each are summarized below. It should be noted that a number of these settings have no effect when used in combination with the built-in security of IIS 6.0. That is, the built-in security of IIS 6.0 already protects against many of the same attacks as URLScan 2.5. However, the goal here is to prevent invalid HTTP requests from being forwarded to the internal network in the first place.

Note:
Improper settings in the URLScan.ini file will cause problems with published Web sites. It is therefore important that you configure and verify appropriate URLScan.ini settings in a test lab before deploying URLScan on a production ISA Server.

The following is a detailed description and explanation of the URLscan.ini file settings.

[Options] Section

This [Options] section contains most of the primary settings for URLScan functionality. Entries in this section have the format OptionName=OptionValue. Below are the various URLScan options and their default values:

· AllowDotInPath=0
When this setting is 0, URLs containing more than one period (.) are not allowed. This protects against certain HTTP-request exploits that attempt to fool the Web server into processing a request for an otherwise blocked file extension. For example, the HTTP header contains a request for something like /NotAllowedExtension.asp/AllowedExtension.htm. This might be interpreted as a request for a file with an allowed .htm extension, which is passed to the PATH_INFO variable, when in fact it is a request for a blocked file extension (in this case, a .config extension). If URLScan is configured to block .asp files and allow .htm files, this URL will be allowed if AllowDotInPath is set to 1. If this value is set to 0, directory names in the request path must not contain any periods, and the URL must not contain more than one period. It should be noted that URLScan always recognizes the first .exe, .dll, or .com extensions it sees in the request path.

· AllowHighBitCharacters=0
When this setting is 0, characters outside of the standard ASCII character set are not allowed. This mitigates weaknesses such as the Unicode translation vulnerability whereby hackers substitute Unicode characters for slashes in order to initiate a directory traversal attack. Disallowing high bit characters will limit request paths to those that use only ASCII characters and will consequently limit the number of allowable language-specific character sets.

· AlternateServerName=(not specified by default)
This setting is used as a masquerading/obscurity technique of somewhat limited value to impersonate another Web server type in the HTTP Server header responses. For example, the setting could be used to give the impression that the IIS Web server is an Apache Web server. The functionality of this setting depends on the setting for the RemoveServerHeader option.

· RemoveServerHeader=0
When this setting is 1, URLScan will remove the HTTP Server header from outgoing responses.

· EnableLogging=1
When this setting is 1, URLScan will log rejected URLs along with the reason for rejection in a file named URLScan.log that is created in the directory containing the URLScan.dll file.

· LoggingDirectory=(not specified by default)
Specifies an alternate directory for the collection of log files. By default, URLScan log files are created in the directory where the URLScan.dll is located.

· LogLongURLs=0
When this setting is 0, only the first 1024 bits of a URL are logged. When set to 1, a maximum of 128 kilobytes for each URL are logged.

· PerDayLogging=1
When set to 1, URLScan creates a new log file each day.

· PerProcessLogging=0
When set to 1, URLScan creates a separate log file for each process, appending the process ID to the log file name.

· NormalizeURLBeforeScan=1
A raw URL request may contain numbers preceded by a % sign to encode special characters, such as “%20” to indicate a space. When this setting is 1, which is the more secure setting, URLScan decodes (normalizes) the raw URL before processing it.

· VerifyNormalization=1
When this setting is 1, URLScan performs a second normalization on the decoded URL to mitigate double-encoding attacks that work by encoding the % sign.

· RejectResponseURL=(not specified by default)
Use of this setting allows the redirection of a rejected URL to an alternate location to create a customized message that is sent to the client providing the reason the URL was blocked. When no path is specified, the default location for the response is /<Rejected-By-URLScan>, which causes a 404 error to be sent to the client and which shows up on the IIS/ISA logs as failed request for /<Rejected-By-URLScan>. A key advantage of this setting is that it allows IIS or the Web Proxy Logs to record more detailed information. A useful feature of URLScan is that you can specify a path to an ASP file that generates the custom response, such as /path/customresponse.asp, even when URLScan is configure to otherwise block ASP files. When the path is set to a special value of /~*, URLScan will allow the requests to be processed, but will log them in the URLScan.log file. This is useful for testing purposes.

URLScan provides a number of server variables that can be used to create the custom response for the client:

HTTP_URLSCAN_STATUS_HEADER.
Provides the reason for rejection.

HTTP_URLSCAN_ORIGINAL_VERB.
Specifies the HTTP verb (PUT, POST, DELETE, GET, OPTIONS, CONNECT, etc.,) that caused the rejection

HTTP_URLSCAN_ORIGINAL_URL.
Specifies the rejected URL.

· UseAllowVerbs=1
When set to 1, URLScan will allow only URLs that contain verbs explicitly permitted in the [AllowVerbs] section of the file. When set to 0, URLScan will deny URLs on the basis of verbs explicitly denied in the [DenyVerbs] section.

· UseAllowExtensions=0
Works like the UseAllowVerbs section. Used to allow or deny URLs on the basis of extensions of requested files listed in the [AllowExtensions] or [DenyExtensions] sections.

· UseFastPathReject=1
When set to 1, URLScan ignores the setting of RejectResponseURL and immediately sends an error message to the client browser without any further processing. The requested URL is still recorded in the Web Proxy log and the reason for the rejection is recorded in the URLScan.log on the ISA Server. The advantage of this setting is faster processing of rejected URLs.

[AllowVerbs] and [DenyVerbs] Sections

These sections are used to accept or deny HTTP traffic on the basis of verbs (methods) specified in the HTTP header. When UseAllowVerbs is set to 1, URLScan will accept traffic that contains only the verbs explicitly listed in the [AllowVerbs] sections. When UseAllowVerbs is set to 0, URL scan will reject traffic on the basis of the presence of verbs specified in [DenyVerbs] section.

Depending on the Web applications you wish to publish, the URLScan.ini file may have to allow both HTTP 1.1 and WebDAV verbs. HTTP 1.1 verbs include GET, POST, PUT, HEAD, DELETE, and OPTIONS. WebDAV verbs are an extension of HTTP 1.1 verbs. Some of these verbs are COPY, LOCK, MOVE, PROPFIND, PROPPATCH, SEARCH, and others. Consequently, administrators need to take care when configuring settings in either the [AllowVerbs] or [DenyVerbs] section to ensure URLScan is not configured so restrictively that it interferes with the functionality of the Web application.

[AllowExtensions] and [DenyExtensions] Sections

These sections are used to accept or deny HTTP requests on the basis of requests for files that have particular extensions. When UseAllowExtensions is set to 1, URLScan will accept requests for files that correspond to explicit settings in the [AllowExtensions] section.

SharePoint Portal Server 2003 is based on the .NET Framework. One consequence of this is that there is a greater range of file extensions that have to be taken into consideration when configuring URLScan. For example, an [AllowExtensions] section, if used, should include .aspx and .ashx extensions. The [DenyExtensions] section, if used, should possibly include .asax, .ascx, .config, .dll, .resx, xsd, xsx, and other extensions. The Microsoft Knowledge Base article 815155, HOW TO: Configure URLScan to Protect ASP.NET Web Applications, provides a good starting point for learning more about this topic.

[DenyHeaders] Section

This section is used to deny specific HTTP headers in the request. This section is used primarily to prevent HTTP headers that could potentially invoke WebDAV from being forwarded to the Web server. For example, the URLScan_iis.ini template prevents the Translate, If, and Lock-Token headers from being forwarded to the internal network. However, this section can be used to deny any header, including non-standard headers.

[DenyURLSequence] Section

This section is used to deny URLs that contain specific strings. A primary use of this section is to prevent directory traversal attacks by specifying strings such as “..”, “\”, “/.”, “%”, and “&”. Note that entries in this section are processed after normalization so that URLs containing a % character will be allowed as long as they do not contain the % character after normalization.

[RequestLimits] Section

This section is used to set maximum lengths for specific parts of incoming requests. There are three settings that can be assigned values:

· MaxAllowedContentLength
Specifies the maximum value for the Content-Length. The default value is approximately 30 MBs, as reported by the URLScan initialization log file, and can be reduced significantly depending on the size of files that are uploaded to the Web server. It should be noted that a value specified here is not effective in limiting content sizes of a chunked-transfer encoded POST request. Chunked-transfer encoding can be disabled through URLScan by denying the Transfer-Encoding header in the [DenyHeaders] section.

· MaxURL
Specifies the maximum allowable length of the URL, excluding query strings that may be present. This value should be set to a value representing the longest possible URL on the site.

· MaxQueryString.
Specifies the maximum allowable length of a query string in the URL.

A useful feature of this section is that it can also be used to restrict the length of any header by prepending the “Max-“ setting to the header name plus a value that represents the maximum number of characters. For example, specifying “Max-Content-Type=100” and “Max-Referrer=100” will limit the length of both the Content-Type and Referrer headers to 100 characters. A value of 0 will cause URLScan not to enforce any limits on the header size. (To deny headers completely, use the [DenyHeaders] section.)Header sizes have to be explicitly listed here in order for URLScan to enforce size limits on them.

Installing and Configuring URLScan 2.5 for ISA Server 2000

Download the feature pack from http://www.microsoft.com/downloads/details.aspx?FamilyID=2f92b02c-ac49-44df-af6c-5be084b345f9&DisplayLang=en to a machine on the internal network and scan it for viruses. Next, copy the file to the ISA Server and perform the following steps:

Double click on the isafp1.exe file. Type a path for the extracted files in the Choose Directory For Extracted Files dialog box (figure 1).

Figure 1

Click I Agree in the Feature Pack 1 EULA dialog box.
Click OK in the Microsoft ISA Server 2000 Feature Pack 1 dialog box. Leave the checkmark in the Read about ISA Server Feature Pack 1 checkbox to learn more about what you get with Feature Pack 1.

Perform the following steps to install and configure the ISA Server version of URLScan:

1. Go to the ISA Server Feature Pack 1 Web site and download the isafp1ur.exe file to a machine that is not the ISA Server. Scan the file to confirm that it is safe, and then copy it to the caching-only ISA Server. Double click the isafp1ur.exe file and enter a local path in the Choose Directory For Extracted File dialog box (figure 2) and click OK.

Figure 2

2. Read the EULA on the URLScan Web filter for ISA Server Feature Pack 1 dialog box and click I Agree (figure 3).

Figure 3

3. Click Yes on the Microsoft ISA Server 2000 Update Setup dialog box (figure 4) that warns you that some Web sites may be inaccessible to users.

Figure 4

4. Click Yes on the Microsoft ISA Server 2000 Update Setup dialog box that asks if you want to use the urlscan.ini file that has been customized to support OWA site publishing (figure 5).

Figure 5

5. The installation routine updates the ISA Server configuration (figure 6).

Figure 6

6. Remove the checkmark from the Read about the URLScan Web Filter (figure 7) in the Microsoft ISA Server 2000 Update dialog box and click OK.

Figure 7

7. Open the ISA Management console and expand the Extensions node (figure 8). Click on the Web Filters node. The URLScan Filter appears with a green up pointing arrow on its icon. The green arrow indicates that the filter is enabled.

Figure 8

URLScan is now protecting your published OWA Web site.

Summary

URLScan 2.5 on ISA Server 2000 enhances the firewall’s defensive capabilities. Installing URLScan on ISA Server 2000 prevents many application layer attacks from being successfully mounted against Web servers published on the internal network. URLScan is highly configurable through the URLScan.ini file, which can be easily customized to meet a wide range of Web site security and accessibility requirements. URLScan on ISA Server 2000 plays a crucial role in a providing the comprehensive defense-in-depth strategy required to protect mission-critical Web applications.