The Microsoft IIS security world has been quiet for some time. Nearly 2 years have passed since Microsoft released the last Internet Information Services (IIS) 5.0 hotfix, and the company hasn't yet released a hotfix that directly affects IIS 6.0. The security changes that Microsoft made with Windows Server 2003 let administrators get an IIS 6.0 server up and running securely with little effort. Even IIS 5.0, after a quick hardening with the IIS Lockdown Tool, provides relatively good security.
But don't let this lack of security problems make you complacent. Although Microsoft's efforts have dramatically reduced the attack surface of IIS servers, intruders still break in. But because of a lack of published vulnerabilities, the focus of attacks has shifted from exploiting the platform to exploiting applications and server configuration. I've compiled some tips and best practices that you can implement to make your IIS server even more resistant to attack.
Use Granular Access Controls
The key to hardening an IIS Web site is to use the available access controls. IIS lets you restrict access by limiting the allowed file types and HTTP verbs used with each file type; setting IP restrictions for certain content; and allowing or disallowing read, write, and directory access. You can configure these settings through IIS 6.0's IIS Manager UI or through the Microsoft Management Console (MMC) IIS snap-in in IIS 6.0 and earlier. (For more information about IIS access controls, see "The Truth About Web-Based Permissions," January 2002, InstantDoc ID 23280, and "Web and FTP Permissions in IIS 5.0," March 2001, InstantDoc ID 19773.) Also take advantage of the granularity of NTFS file permissions and set individual permissions for each content type and area on your Web site. (For information about setting NTFS permissions, see "NTFS Permissions for IIS Web Servers," October 2002, InstantDoc ID 26358.)
Take the time to set permissions on individual files. For example, few people realize you don't need to allow read access to .asp files, so use the IIS Manager console to clear the Read option for all .asp files, as Figure 1 shows.
NTFS lets you set an ACL on a folder with distinct permissions for the folder, any child objects (e.g., files), and any child containers (e.g., subdirectories). Consequently, you could set tight permissions on a directory to prevent access to all child objects, then explicitly change the permissions on individual files in that directory to allow whatever access users require. Users then would have access to individual files, but whenever someone creates a new file in that directory, the file would automatically inherit the strict permissions you set on the directory.
The IUSR account handles anonymous requests for Web resources. When you set the NTFS permissions, allow Read access for the IUSR account for anonymous access and Read access for specific users or groups for authenticated access. If you deny the IUSR account Read access to, for example, index.html, anonymous Web users won't be able to access that file. For more information about IUSR accounts, see "Using Null Session Shares," May 2002, InstantDoc ID 24541.
Install URLScan
Many administrators install URLScan on their IIS 5.0 Web sites as an additional layer of protection against attacks. URLScan is an Internet Server API (ISAPI) filter that intercepts requests that your Web server receives from the Internet and scans them for anything unusual. You can download the tool from http://www.microsoft.com/technet/security/tools/urlscan.mspx. (To learn more about URLScan, see "Deploy URLScan to Protect Your IIS Server," August 2002, InstantDoc ID 25581.)
Although many of URLScan's features are built into IIS 6.0 or are irrelevant because of the new IIS 6.0 architecture, URLScan is still useful for protecting IIS 6.0, and I recommend that you install it. URLScan provides flexible filtering options for combating new attacks as they surface and provides more granular control over Web requests through its DenyUrlSequences feature. For example, IIS 6.0 lets you set length restrictions on certain portions of a request, but URLScan lets you set length restrictions on individual HTTP request headers. Length restrictions offer protection against attackers who send long strings in an attempt to execute a buffer-overflow attack. Perhaps the best reason to use URLScan is that it provides an additional layer of protection in case a flaw surfaces in the built-in IIS 6.0 protections.
Create a Place for Non-Web Data
Web administrators often ask me where to store sensitive data such as databases, application logs, or customer data files. The answer is simple: Place them in a directory that's separate from your Web content. Your server-side scripts can access data anywhere on the file system, so you have no reason to store such data in public-content directories. Create a directory separate from your webroot for database, XML, or sensitive text files.