Customize urlscan.ini as strictly as possible without crippling your Web site
In "Protect Your IIS Server with URLScan," July 2002, InstantDoc ID 25230, I offer an overview of Microsoft's URLScan tool and discuss how to download and test URLScan on a nonproduction server that contains a copy of your Web site. URLScan, which is bundled as part of the IIS Lockdown Tool (available for download at http://www.microsoft.com/downloads/release.asp?releaseid=33961), is an Internet Server API (ISAPI) filter that intercepts every request your Web server receives from the Internet and scans each request for anything unusual. The current version is URLScan 2.5, which you install over URLScan 2.0. (URLScan 2.5's new features let you change the log-file directory, log long URLs, and restrict the size of requests.) When you download URLScan 2.5, the new version adds entries to urlscan.ini but doesn't overwrite current settings.
Now let's delve into the process of customizing the tool for your environment. I take you step by step through urlscan.ini's sections (i.e., [options], [AllowVerbs], [DenyVerbs], [AllowExtensions], [DenyExtensions], [DenyHeaders], [DenyUrlSequences], and [RequestLimits]) and explain the tool's configuration options.
[options]
In addition to containing the majority of URLScan's options, the [options] section contains 16 settings that URLScan uses to interpret other urlscan.ini sections: UseAllowVerbs, UseAllowExtensions, NormalizeUrlBeforeScan, VerifyNormalization, AllowHighBitCharacters, AllowDotInPath, RemoveServerHeader, AlternateServerName, EnableLogging, PerProcessLogging, PerDayLogging, LogLongUrls, LoggingDirectory, AllowLateScanning, RejectResponseUrl, UseFastPathReject. You set most of these settings to 1 (true) or 0 (false).
[AllowVerbs] and [DenyVerbs]
Verbs (also called methods) are the commands that a browser uses at the beginning of a URL to communicate with a server. GET and HEAD are the most common verbs that Web browsers use for simple browsing. For example, when a browser requests contactus.html, it sends, in part, GET /articles/contactus.html. Browsers use other verbs, such as PUT, POST, and REPLY, to modify Web site content. Microsoft FrontPage Server Extensions, for example, use POST and OPTIONS (in addition to GET and HEAD) to maintain Web content.
To control which HTTP verbs URLScan permits or rejects in incoming requests, you can use urlscan.ini's UseAllowVerbs setting. This setting lets you use either the [AllowVerbs] section to specify a list of verbs to accept or the [DenyVerbs] section to specify a list of verbs to reject. To tell URLScan which section to use, you set UseAllowVerbs to 0 or 1. When you set UseAllowVerbs to 1, URLScan examines only [AllowVerbs] and ignores [DenyVerbs]—even when you list verbs under the latter section. In fact, if you set UseAllowVerbs to 1 and specify GET in both [AllowVerbs] and [DenyVerbs], users will be able to GET files from your Web site. When you set UseAllowVerbs to 0, URLScan looks at [DenyVerbs] and ignores [AllowVerbs]. Conceptually, IIS is most secure when you deny all verbs by default, then list exceptions. Therefore, I suggest you use the [AllowVerbs] section to list specific permitted verbs.
[AllowExtensions] and [DenyExtensions]
URLScan's [AllowExtensions] and [DenyExtensions] sections work similarly to [Allow Verbs] and [Deny Verbs] but control which file extensions incoming requests can access. You probably want users to be able to request common Web files (e.g., .html, .jpeg, Active Server Pages—.asp) but not executable files (e.g., .exe, .cmd, .bat), log files, or configuration files.
The urlscan_static.ini file contains a good sample list of file extensions that you can safely permit on most Web sites—and a long list of potentially dangerous extensions. After you determine which extensions you want users to be able to access through your Web site, set UseAllowExtensions to 1 and list the permitted extensions in the [AllowExtensions] section. That way, you block all other extensions. I recommend using [DenyExtensions] instead of [AllowExtensions] only if you must let users upload various types of files to your Web site and share the files with others. In that case, set UseAllowExtensions to 0, list the file extensions you consider to be dangerous in the [DenyExtensions] section, and notify your users that they can't use files of those types.
Be aware that [DenyExtensions] can break script mappings that you've configured in IIS. For example, if you deny .asp files in urlscan.ini, users can't access .asp pages even when you configure IIS to service .asp files under App Mappings in the Microsoft Management Console (MMC) Internet Information Server snap-in.
[DenyHeaders]
The [DenyHeaders] section lets you specify which client request headers that URLScan should permit or deny. For example, you can include Translate: as a denied header to prevent clients from requesting the source code of your Web site pages. (Note that not all settings offer both an [Allow] and [Deny] section.)
You'll find [DenyHeaders] especially valuable because you can use this section to disable WWW Distributed Authoring and Versioning (WebDAV). Because of WebDAV's vulnerabilities, you should disable it unless you use it to publish to your Web site. To prevent your servers from servicing WebDAV clients, include Translate:, If:, and Lock-Token: under [DenyHeaders] and include the verbs PROPFIND, PROPPATCH, MKCOL, DELETE, PUT, COPY, MOVE, LOCK, UNLOCK, OPTIONS, and SEARCH under [DenyVerbs], as Listing 1 shows. (Web Listing 1, http://www.windowswebsolutions.com, InstantDoc ID 25581, contains the entire sample urlscan.ini file configured to support FrontPage Server Extensions but to disable WebDAV.) Also, as Web Listing 2 shows, you should include Transfer-Encoding: as a denied header to disable chunked-encoding transfers. (By default, the URLScan-SRP variant makes transfer-encoding a denied header in urlscan.ini.)
Previous
Register
