Deploy URLScan to Protect Your IIS Server

[DenyUrlSequences]
The [DenyUrlSequences] section lets you scan a URL for certain dangerous character sequences that intruders often use to trick IIS into running malicious commands. The default sequences that Web Listing 3 shows catch character sequences known to be dangerous to both IIS and Windows 2000, but you might want to add other sequences that can pose a danger to applications to which you forward form input. For example, Web sites often incorporate form input into SQL queries without checking for malicious input that can fool the SQL server into running commands that an attacker selects.

You can also use [DenyUrlSequences] to block requests that attempt to access commands or executables you want to protect (e.g., cmd.exe, explorer.exe) or that use any other suspicious strings (e.g., winnt, system32). The Beyond-Security SecuriTeam article "Combining URLScan With FrontPage (HOWTO)" at http://www.securiteam.com/windowsntfocus/6Z0010U2UU.html includes a urlscan.ini file that blocks Nimba attacks that target IIS. Of course, be aware that blocking these requests can inadvertently block legitimate client requests. For example, if your Web site hosts a discussion forum about Windows NT, blocking the winnt string will prevent anyone from discussing files in that folder. [DenyUrlSequences] can also break Microsoft Outlook Web Access (OWA) sites. If you use OWA and want to implement URLScan, read the Microsoft articles "XCCC: IIS Lockdown and URLScan Configurations in an Exchange Environment" (http://support.microsoft.com/default.aspx?scid=kb;en-us;q309508) and "XADM: Known Issues and Fine Tuning When You Use the IIS Lockdown Wizard in an Exchange 2000 Environment" (http://support.microsoft.com/default.aspx?scid=kb;en-us;q309677).

[RequestLimits]
The [RequestLimits] section, which is new in URLScan 2.5, lets you use three settings—MaxAllowedContentLength, MaxUrl, and MaxQueryString—to control the maximum length of three parts of the URL requests that clients send to IIS. This section is important for defeating buffer-overflow attacks that depend on sending large amounts of data in the request. URLScan 2.5 defaults are usually adequate; all values entered should be in bytes.

MaxAllowedContentLength. MaxAllowedContentLength controls the maximum permitted value for the content-length request header. For example, when you set MaxAllowedContentLength to 1024 bytes, URLScan rejects any request with a content length that exceeds 1024 bytes. When you POST or PUT a file to a Web server, content length specifies how long the attached data can be. Thus, MaxAllowedContentLength lets you limit how much data someone can PUT or POST to your server. When you install URLScan 2.5 automatically, it sets this value at about 3GB (about 3,000,000,000 bytes).

MaxUrl. MaxUrl specifies the maximum permitted length for the portion of a URL request that precedes the query string. (The query string is the part of the URL request that follows a question mark and contains the information, usually form input fields, that the browser sends to request a Web page.) If you install urlscan.dll manually and don't update urlscan.ini, the default is 260 bytes. However, when you install URLScan 2.5 automatically, it sets this value to 16KB (16,384 bytes).

MaxQueryString. MaxQueryString specifies the maximum length permitted for a query string. When you don't set a value for this setting, URLScan uses a default length of 4KB (4096 bytes). When you install URLScan 2.5 automatically, it sets the same value: 4KB (4096 bytes).

Setting limits on other request headers. You can also limit the byte size of other request headers. To do so, add a setting for the header by using "Max-" to prefix the header name. (See the URLScan 2.5 documentation at http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/tools/tools/urlscan.asp.) Note that if you specify 0 as the header length, you actually instruct URLScan to forgo checking the length. Unless you're familiar with request headers, I recommend that you wait to use these options until Microsoft suggests specific settings.

Filtering Questionable URLs
The [options] section contains additional settings that you can use to tell URLScan how to interpret other urlscan.ini sections: NormalizeUrlBeforeScan, VerifyNormalization, AllowHighBitCharacters, AllowDotInPath, RemoveServerHeader, and AlternateServerName. Again, you can set these settings to 1 (true) or 0 (false). NormalizeUrlBeforeScan and VerifyNormalization control the normalization of URLs. Normalization is the process of standardizing capitalization and converting encoded characters to regular characters—for example, changing %2e to a period (.), which [DenyUrlSequences] would then catch. AllowHighBitCharacters and AllowDotInPath help you filter URLs to prevent some common attacks. You can use RemoveServerHeader and AlternateServerName to keep IIS from identifying itself to the client.

NormalizeUrlBeforeScan. NormalizeUrlBeforeScan controls whether URLScan normalizes an incoming URL before or after scanning it. I recommend that you leave NormalizeUrlBeforeScan set to 1, which is the default. If you set NormalizeUrlBeforeScan to 0, URLScan might mistakenly approve malicious URLs that the normalization process reveals.

VerifyNormalization. If you set VerifyNormalization to 1, URLScan further normalizes URLs before the program proceeds. This setting is valuable because it can catch double-encoding techniques. For example, an attacker who hides an ampersand (&) in a URL might send %2526, which one normalization pass translates to %26. However, if you set VerifyNormalization to 1, URLScan recognizes that normalization isn't complete and resolves %26 to the ampersand character, which [DenyUrlSequences] then catches.

AllowHighBitCharacters. If you set AllowHighBitCharacters to 0 (the default is 1), URLScan rejects non-ASCII characters, which helps defend against attacks encoded with UTF-8 and Unicode. UTF-8 is an encoding scheme that lets you send Unicode in an ASCII stream, but UTF-8 is also another way to hide attacks in URLs. I recommend setting AllowHighBitCharacters to 0 unless you use Unicode to support another language.