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.
Isolate Administrative Directories
I'm surprised by how frequently I see Web sites that have administrative directories with easy-to-guess names such as admin, backup, logs, or stats. Such directories have no place on a public Web site. They are attractive targets for malicious hackers, and it doesn't take long to guess their location.
Instead, place this sensitive content on its own site and use host headers and nonstandard ports (i.e., high-number ports or ports of other application protocols) to hide its existence. Host headers let you place multiple Web sites on the same IP address, distinguished by the host name. For example, you could have http://www.example.com as the main Web site for an IP address but set up another site on the same IP address for admin.example.com. For a detailed explanation of host headers, see "Using Host Headers to Set Up a Multihomed Server," October 1999, InstantDoc ID 7176. Implement IP address restrictions and authentication controls to limit access to this site. If you must leave a sensitive directory on your public Web site, at least change the directory name to something obscure and implement user access controls and IP restrictions, such as requiring client-side Secure Sockets Layer (SSL) certificates, to limit access. It's important to note that obscurity does nothing to restrict access to the site, but it does limit visibility so that the site is a less obvious target.
Keep the Webroot Tidy
Do you have a file on your Web site with a name like test.asp? If so, you might have a problem with junk collecting in your Web content directories. Test scripts, backups, old file versions, obsolete content, and temporary files can lead to a seriously compromised server. Even the most meaningless files might provide a bit of information that an attacker can use to break in. If you don't leave these files on your Web site, an attacker can't use them against you.
Establish a policy for your organization to discourage people from creating these files in Web-content directories. If a policy doesn't solve the problem, consider running batch processes to automatically clean up these extra files. Removing such files also simplifies site management and reduces clutter—if your Web site is clean, you can more easily spot unauthorized files.
Here's another tip: When you publish any new revision of your Web site, set the date and timestamp on all files to the same time. Doing so will help you see when an intruder modifies or creates a file.
Fine-Tune IIS Settings
IIS uses various settings that aren't directly available from IIS Manager. These settings can help you stop or limit attacks. For example, buffer overflow attacks flood a Web site with large amounts of data. IIS 6.0 lets you use the MaxRequestEntityAllowed and AspMaxRequestEntityAllowed metabase settings to limit the entity body size of a request or an Active Server Pages (ASP) request, respectively. These settings let you set the maximum size, in bytes, for the body of a request, as specified in the HTTP content-length header. You can use the IIS Metabase Explorer tool to edit the metabase, as Figure 2 shows. Metabase Explorer is included in the Microsoft IIS 6.0 Resource Kit Tools, which you can download from http://www.microsoft.com/downloads/details.aspx?familyid=56fc92ee-a71a-4c73-b628-ade629c89499&displaylang=en. Table 1 shows some metabase settings that you should consider changing. Web Table 1 (http://www.windowsitpro.com/windowssecurity, InstantDoc ID 44646) shows some registry settings that you might want to change.
Follow Microsoft's Philosophy
The most notable difference between default installations of IIS 6.0 and IIS 5.0 is that the former reflects Microsoft's new secure-by-default strategy. To accomplish this new strategy, Microsoft installs no feature by default and sets the strictest security settings that will still let you operate a basic Web site. But too few administrators carry that philosophy through; they install features that they don't use or relax security settings so much that the server is vulnerable to attack.
Use caution with every feature you add and carefully consider the effect of every security change you make. Even if you think you might use a feature in the future, don't install it now; install it when you actually need it.
Ultimately, the best way to keep your server secure is to establish a security policy and stick to it. Your policy needs to define data locations, access controls, file cleanup parameters such as frequency, IIS settings, and which components you should or shouldn't install. Hardening is much easier with IIS 6.0, but it's still a necessary and ongoing process.
