Safeguarding IIS from Attack

Microsoft IIS holds an unusual position in a networking infrastructure: As code running in user mode that's deeply integrated with the OS, IIS uses Internet protocols to deliver applications and content to remote users. To secure IIS, you need to consider every aspect of the installation, including the network, application, server, and OS. And speaking as someone who has been there, you'll have a new appreciation for the word defense when you're finished with the process.

You'd be surprised at how much money companies spend to secure their servers only to fail to protect those same systems from someone gaining physical access and using a 3.5" disk to boot the machine. For the sake of this article, I assume you don't need a refresher on physical access, unpatched systems, password complexity, and changing default passwords on administrative systems (e.g., system monitors, shopping carts). Still, someone isn't getting the message because these items continue to rank among the most common methods of gaining unauthorized access to servers; for more details, see The SysAdmin, Audit, Network, Security (SANS) Institute's article "The Twenty Most Critical Internet Security Vulnerabilities (Updated) — The Experts' Consensus" (http://www.sans.org/top20). However, if you want more information about the basics of IIS security, I suggest you read "Best Practices for Secure Web Servers," December 2001, http://www.windowswebsolutions.com, InstantDoc ID 22972.

After you've established a good understanding of basic IIS security, you're ready to move on to more advanced topics such as controlling the process identity, port filtering, disabling Web Distributed Authoring and Versioning (WebDAV), and using the URLScan security tool. Let's clarify a few persistent myths about IIS security and examine some of the most useful Microsoft-based tools and techniques for hardening your Web servers.

IIS Security Folklore
One of the first things you need to learn about IIS security is that not everything you read is true. In fact, one of the reasons I began sharing my IIS expertise was the significant amount of misinformation available from various sources, including Microsoft. Let's examine a few examples of this misinformation.

Anonymous user requires log-on-locally privilege. Perhaps you've read that the IUSR_<servername> account that IIS uses for anonymous authentication requires the right to log on locally. This information is available in the IIS Help files and on the Microsoft Web site, including the Microsoft article "HOW TO: Set Basic NTFS Permissions for IIS 5.0" (http://support.microsoft.com/?kbid=271071). Users often advise their colleagues about this requirement in support groups and on bulletin boards. However, unless the IIS server resides on a domain controller (DC), this requirement isn't true. The type of authentication that occurs by default with an anonymous user results in a network logon that doesn't require the log-on-locally privilege (for a detailed explanation about this network logon, see "IIS Informant: Clarifying Inaccurate Information About Anonymous Authentication," http://www.windowswebsolutions.com, InstantDoc ID 24845).

From a security perspective, denying an anonymous user the right to log on locally is a good practice because it prevents someone from using the anonymous user account to obtain a local logon, which would let the user have more privileges on the network than a network logon. For example, a hacker who uses the IUSR account to log on through Windows 2000 Server Terminal Services would be in an interactive logon session and, therefore, able to access other network resources. Understanding the differences between a local logon and a network logon can take a while to learn but is well worth the study for IIS administrators and is essential for a solid understanding of server security. For a brief authentication overview, see http://www.microsoft.com/technet/prodtechnol/winxppro/reskit/prdp_log_csky.asp and Michael Howard's Designing Secure Web-Based Applications for Microsoft Windows 2000 (Microsoft Press), page 107.

Users need Change permissions on log files. The Secure Internet Information Services 5 Checklist at http://www.microsoft.com/technet/security/tools/chklist/iis5chk.asp contains some excellent suggestions and one really bad idea, namely to allow the Everyone group Read, Write, and Change permissions on the IIS-generated log files (\%systemroot%\system32\logfiles). I studied this suggestion for some time to make sure I wasn't missing the point, but allowing these permissions to the Everyone group won't prevent malicious users from deleting log files to cover their tracks, as the checklist implies. The correct advice is to allow only Full Control permissions on the log files to the Administrators and System groups. The only exception to this rule is if you use a custom logging object that writes IIS log files. In that rare circumstance, you might need to allow Change permissions.

Active Server Pages (ASP) requires the NTFS Execute permission. Many Microsoft and non-Microsoft documents include suggested NTFS permissions for IIS content. Most of these documents state that scripts require the NTFS Execute permission. This advice violates the important security best practice known as the principle of least privilege. In general, any script mapped to a script engine requires only the NTFS Read permission.

IIS administrators face a challenging task of weeding out the truths from the half-truths. Knowing that some misinformation comes from Microsoft doesn't make this task any easier. Still, being aware of the steps you need to take to secure your Web servers will help. Let's examine a few truths.