IIS 6.0 Makes URLScan Almost Obsolete

Security minded IIS administrators are aware of URLScan ( http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/tools/tools/urlscan.asp ) as a staple of IIS 5.0 and IIS 4.0 security. This Internet Server API (ISAPI) filter lets you configure your server to quickly reject client requests that don't meet criteria you define in the urlscan.ini file. IIS 6.0 has many significant security improvements, which is one reason I frequently hear the question "Do I need to run URLScan with IIS 6.0?"

The general answer to this question is "probably not." Of course, that's not a very satisfying answer, so let's see if I can help clarify things for your particular circumstances by mapping URLScan features to IIS 6 features.

IIS 5.0 and IIS 4.0 have HTTP parsing systems that aren't quite as strong as they should be. URLScan features such as NormalizeURLBeforeScan, VerifyNormalization, and AllowDotInPath help bolster the IIS 5.0 and IIS 4.0 parsing engines to prevent specific exploits from succeeding. IIS 6.0's http.sys parsing engine is completely rewritten and much tighter about enforcing standards. Consequently, you don't need to use URLScan to secure IIS 6.0 server from double-decode, directory traversal, and other attacks that leverage weaknesses in the IIS 5.0 and IIS 4.0 HTTP parsing engines.

AllowHighBitCharacters is a URLScan setting that prevents or allows URLs that contain UTF8-encoded non-ASCII characters. UTF8 lets you represent characters of many languages in an encoded form such as %2e for a period and %20 for a space. A period and a space are ASCII characters, but UTF8 also can represent non-ASCII characters. Hackers can use this capability to submit content in a URL that can execute in the CPU by means of a buffer overflow. The IIS 6.0 registry subkey HKEY_LOCAL_MACHINESystemCurrentControlSetServicesHTTPParametersEnableNonUTF8 permits or denies UTF8. Thus, you don't need URLScan to control this capability in IIS 6.0. See the Microsoft article "INF: Http.sys Registry Settings for IIS" ( http://support.microsoft.com/?kbid=820129 ) for the complete set of registry entries that Microsoft has released for http.sys.

The Allow/Deny Extensions sections of the urlscan.ini file let you specify file extensions to permit or reject. IIS 6.0, using Web Service Extensions, goes one better by denying all executables that aren't specifically allowed by path and filename. For example, using URLScan, even if you want to permit only one .dll file to run, you have to allow all files ending in .dll to run. In IIS 6.0, you can specify that only d:webcontentshoppingcartcart.dll should be able to run. Permitting only specified executables to run is a very strong defense because it means that even if a hacker can get an executable onto the server, it can't be launched from a URL.

The DenyUrlSequences setting in URLScan has no matching component in IIS 6.0. The DenyUrlSequences option lets you reject a URL that contains a sequence of characters that you specify. For example, you can reject any URL that contains "_vti" to prevent attacks on FrontPage directories or "scripts" to prevent attacks on the commonly targeted Scripts folder (which isn't present on IIS 6.0). After you review IIS 6.0's security features, if you find you need to reject specific character sequences, you'll need to use URLScan.

URLScan also provides the only supported method for removing the server banner from IIS servers. Some security-minded folks are passionate about removing the server banner, but fingerprinting an IIS server is easy for anyone who really wants to know its identity. Thus, I wouldn't implement URLScan simply for this capability because the security benefit is minimal.

Deny/Allow Verbs is another feature that's available only in URLScan. This feature permits you to list HTTP verbs that the IIS server should deny or allow. The most common use of this feature is to reject WebDAV requests in IIS 5.0 and IIS 4.0. IIS 6.0 with Web Service Extensions prevents WebDAV by default. Consequently, if all you want to do is disable WebDAV on IIS 6.0, URLScan isn't required. However, I sometimes use URLScan with IIS 6.0 to reject all HTTP verbs that I don't specifically allow. This practice protects the server from standard WebDAV and HTTP verbs such as PUT, from any problems that might arise from changes to HTTP specifications, and from custom applications attempting to use (or abuse) nonstandard verbs.

The "Max" URLScan settings--MaxHeader, MaxURL, MaxAllowedContentLength, and so on--are among the most powerful of the URLScan settings because they restrict the number of characters that can be sent to the Web server in a portion of the client request. Thus, the settings greatly constrain hackers' ability to craft buffer overflow attacks. IIS 6.0's http.sys registry settings let you specify MaxRequestsBytes (the maximum value for all client request headers plus the URL) and MaxFieldLength (the maximum size of any individual client request).

As you can see, URLScan capabilities are for the most part incorporated into IIS 6.0. Thus, you probably don't need URLScan with IIS 6.0 (unless you want to filter out certain URL character sequences or verbs, remove the server banner, or specify different maximum lengths for each element of the HTTP client request header).