Hardening IIS 6.0

Install and Configure IIS 6.0
IIS was installed with its normal defaults, which disable all Web extensions and Internet Server API (ISAPI) filters, among other things. Here are the other steps I took (most are recommended in the Microsoft IIS 6.0 resources listed in the Learning Path box):

1. Changed the IP address of the Web site in the IIS Manager console to be a static private address instead of All Unassigned.
2. Renamed the Default Web site in the IIS Manager console.
3. On the renamed Web site, I required the host header to match the appropriate URL name. This action prevents many automated hacking tools and worms, which typically use only IP addresses. When users access Web sites, they almost always use the Web site name rather than the IP address (see http://www.iisanswers.com/hinders_rant.htm for more details).
4. Set Execute Permissions of the Web site to None in the IIS Manager console.
5. Disabled the IWAM and default IIS anonymous accounts in the User Manager tool.
6. Created a new IIS anonymous account. This is an optional step but allowed me to better control what access the IIS anonymous user has to the Web server.
7. Created an Anonymous Web Users group, added the new IIS anonymous user account to the group, and removed the original IIS anonymous account from it.
8. Using Windows Explorer, I set Full Control permission to Deny on the Windows and System32 folders for the Anonymous Web Users group.
9. Created a new IIS Web server directory on the E drive.
10. In the IIS Manager console, changed the Web server directory from C:\Inetpub to the new directory on the E drive. Moving the Web site off the boot volume disables many directory transversal attacks.
11. Gave the new Anonymous Web Users group read-only permission to the new Web site folder to prevent anonymous users from writing to or creating files on the Web site.
12. Installed URLScan 2.5. URLScan loads as an ISAPI program. After it was successfully installed, I made the following changes:

• Set UseAllowExtensions to 1.
• Set MaxURL to 50.
• Set MaxAllowContent Length to 1000.
• Set MaxQueryString to 0.
• Set AllowVerbs to GET and HEAD.
• Added a period (.) to AllowExtension.

These URLScan settings—in particular, the short URL length and zero length for queries—make the site resistant to known and future buffer overflow attacks via the URL. Although these values aren't realistic for all e-commerce sites, any site will see significant improvements in security by rejecting overly long queries and URLs.

Note: IIS 6.0 is installed with much of URLScan's functionality built in, but I chose to install the standalone version of URLScan. It adds even more functionality and allows more configuration control versus having to accept IIS 6.0's hard-wired URLScan settings.

I then stopped and restarted IIS to let new changes take effect. I reran MBSA to check for missing patches, and it reported no missing patches.

Configure Log Files
Originally, I considered using Microsoft's Network Monitor application or a third-party Intrusion Detection System (IDS) to document hacking activity, but I later decided to use server monitoring tools and log files that would typically be associated with a default install of IIS. Here's a summary of the logging setup steps:

1. Made C:\IISLogfiles the central location for storing all log files.
2. Enabled hourly IIS log files, enabled all fields, and configured log files to be saved in C:\IISLogfiles.
3. Configured URLScan to save its log files to C:\IISLogfiles. Note that IIS 6.0's built-in http.sys security functionality creates a log file called HTTPERR (for more information, see "Error logging in HTTP API" at http://support.microsoft.com/?id=820729). I wasn't sure how to move this log file, so I just placed a shortcut to it in C:\IISLogfiles.
4. Configured Windows Firewall to monitor all successful and dropped packets and save the log file to C:\IISLogfiles. I learned that the maximum Windows Firewall log size is 32MB (woefully inadequate) and that you must stop Windows Firewall to copy the log files. When I wanted to copy the firewall logs to an external computer for analysis, I used IPsec to protect the server.
5. Created an IPsec policy between the Web server and the remote management computer that would be using RDP to connect.
6. Enabled success and failure auditing for all audit events. Note that a high-volume Web site would probably experience a significant performance hit over time with all auditing enabled. After you've troubleshot any resulting error messages, you can enable the auditing categories recommended in the IIS 6.0 Resource Kit.

Last, I emptied the Recycle Bin to make sure no old files were hanging around. The server was rebooted and the router and firewall opened to allow TCP port 80 traffic.

Results?
My heavily-trafficked Web site has been up for several months without a successful exploit. Does that mean that IIS 6.0 is unhackable? No, all software is hackable, and all Web servers have vulnerabilities, known and unknown. Often, Web servers are exploited because of faulty applications running on them. By minimizing the potential application problems, I minimized the overall vulnerability risk.

What my Web site shows is that Windows 2003 and IIS 6.0 properly secured can provide a high level of security. Most of the hardening steps listed above are taken right from Microsoft's IIS hardening guides. You can follow them and have a secure Web site.