Other checklist recommendations are excellent as written, including the following:

  • Executable Content Validated for Trustworthiness
  • Disable or Remove All Sample Applications
  • Check
    and Querystring Input in Your ASP Code
  • Disable Parent Paths
  • Disable IP Address in Content-Location

However, you should take a few other steps as well.

Place your Web content on a drive other than your system drive. Placing your Web content on a drive other than your system drive helps mitigate the damage that an intruder who breaks out of the Web content tree can do. If you use this widely accepted technique, an intruder who tries a directory-traversal exploit must move from the Web content drive to your system drive (Where you would have additional protections) to look for useful utilities such as tftp.exe and cmd.exe in known locations.

Run the IIS Lockdown tool. IIS Lockdown is an important addition to the security of your Web servers. Running this tool implements several best practices:

  • removes IISHelp, IISAdmin, Scripts and other virtual directories installed by default
  • secures unused script mappings
  • disables anonymous Web users' write capability to Web content
  • disables execute permissions on administrative tools
  • backs up the metabase

Install and configure URLScan. The IIS Lockdown tool optionally installs the URLScan Internet Server API (ISAPI) filter (or you can install URLScan manually). You should install URLScan on all your IIS servers, even those that have host-based intrusion-detection software systems installed. URLScan inspects incoming URLs and rejects all requests that don't conform to your standards. To configure URLScan, you use the urlscan.ini file, which controls all aspects of the tool's behavior.

The current version of URLScan, 2.5, adds an important enhancement to this already valuable security tool—it lets you reject URLs whose length exceeds your specified standard. In addition to defining a restriction on the entire URL length, you can limit the portion of the URL string that precedes or follows a question mark (?). The portion of a URL that follows a ? contains information, usually form input fields, that the browser sends to request a Web page. Intruders can use this portion to send bogus information to the server to invoke a buffer overflow or to induce a software failure (e.g., by sending a megabyte of data in a name or address field). You can also limit the length of the URL that precedes the ?.

Limiting the length of the URL is a strong defense because you can seriously constrain an intruder's ability to upload executable content. If you don't use URLScan to limit URL length, IIS 5.0 accepts a client request of up to 512KB and IIS 4.0 permits a length of up to 2MB. For more information about URLScan and version 2.5, see Randy Franklin Smith, "Protect Your IIS Server with URLScan," July 2002, InstantDoc ID 25230, and "Deploy URLScan to Protect Your IIS Server," August 2002, InstantDoc ID 25581. Also see the Microsoft article "INFO: Availability of URLScan Version 2.5 Security Tool".

Run the Microsoft Baseline Security Analyzer. MBSA is a relatively new tool with a good UI (which Web Figure 1 shows) that reports on the missing hotfixes and security vulnerabilities of a computer or set of computers. MBSA reports vulnerabilities such as weak password policies or accounts named Administrator, and IIS risks such as enabled parent paths or the presence of an Msadc virtual directory (as Web Figure 2 shows). MBSA uses the Hfnetchk engine to report on hotfixes missing from the server, and it lets you click a link that takes you directly to their related security bulletin. You can run MBSA for a single computer or subnet and capture the report to a file for analysis. For more information about MBSA, click here.

Obviously, you can do much more to secure your IIS server. I haven't addressed auditing, authentication details, and tuning the urlscan.ini file to work in your circumstances. Nevertheless, implementing this improved checklist will protect your server from most common attacks and present a strong defense for unknown future vulnerabilities. Just removing or disabling application mappings prevents both the CodeRed and Nimda worms from infecting a server through IIS vector.

For more information about securing your IIS server, I recommend that you review the National Security Agency (NSA) white paper "Guide to the Secure Configuration and Administration of Microsoft Internet Information Services 5.0" and SystemExperts' Hardening Windows 2000 Guide. In addition, Michael Howard’s book that I referenced at the beginning of this article is excellent, as is Stuart McClure, Joel Scambray, and George Kurtz's Hacking Exposed: Network Security Secrets & Solutions, 3rd edition (Osborne McGraw-Hill, 2001), which you can learn more about at http://www.hackingexposed.com. All these resources are required reading.