Hardening IIS 6.0

Microsoft might have taken a few years to get IIS right, but IIS 6.0 can be a solid and secure Web server. More than half the 2005 Fortune 1000 companies use IIS 6.0 to host their main Web sites, according to a study done by Port80 Software. And since its release in March 2003, IIS 6.0 has had only three vulnerability advisories versus Apache 2.0's 24 advisories, as reported by the Secunia IT security services company. This evidence suggests that Microsoft has delivered on the promise of better Web server security.

Nevertheless, being charged with hardening a Microsoft IIS server that will be connected to the Internet can be intimidating. It helps to start with Windows Server 2003 and IIS 6.0—they're secure out of the box. But in the real world, you must install and configure Web sites and applications. Attaching any Web server to the Internet invites a multitude of hackers and malicious scanning bots to scour your site looking for any opportunity to exploit a misconfiguration. With that in mind, I installed Windows Server 2003, hardened it against attack, and then downloaded and followed Microsoft's IIS 6.0 installation and deployment security guides. Here's a summary of the steps I took.

Install Windows 2003
The first step was to install Windows 2003 and fully patch it without connecting it to the Internet. I wanted the underlying Windows 2003 system to be a secure base system before I installed IIS. The very first step was to make sure all the hardware and BIOS had up-to-date firmware. I wouldn't want to be hacked due to an outdated SCSI driver.

I enforced booting from only the C drive to help prevent local attacks that use boot-around OSs such as Knoppix or NTFSDOS. Preventing unauthorized booting from the CD-ROM or floppy drive can help stop many password-resetting or -cracking programs and make copying the local SAM to removable media more challenging. I also disabled unused COM, LPT1, IDE, and USB ports in the BIOS, then protected the BIOS by using a complex password. I set up a router and firewall in front of the server computer and blocked all the router's TCP ports except for one RDP port to use for remote installation and configuration. When the site went live, I would also open TCP port 80.

Next, I installed Windows 2003, Standard Edition and used the default settings for a server in standalone-workgroup mode (a domain isn't needed for a standalone public-facing Internet server). I created two local drives, C and D, on the server's hard drive, which was RAID protected. Microsoft recommends installing the OS on one volume and the IIS Web site on another to prevent many directory-transversal attacks.

I renamed the Administrator and Guest accounts to some random-sounding user names and gave both complex passwords longer than 10 characters to decrease the chances of a brute-force password-guessing attack. Although an attacker can discover the Administrator account through SID enumeration, anonymous SID enumeration is turned off by default on systems that aren't domain controllers (DCs) in Windows 2003 and Windows XP.

I enabled Remote Desktop as the only way to remotely administer the server. I chose Remote Desktop because it's installed (although not enabled) by default, performs well, allows remote drive mapping so that I could install software, and has default RC4 encryption. I changed the related RDP port to something other than the default TCP port 3389 following the instructions in the Microsoft article "How to Change Terminal Server's Listening Port" (http://support.microsoft.com/?kbid=187623). The port was changed to slow down any hacker attempts to discover the Remote Desktop service and the brute-force logon-guessing attacks a discovered RDP port might invite.

I toyed with the idea of requiring IPsec to access the Remote Desktop connection but decided against this extra precaution until after I knew the server was stable. IPsec can prevent man-in-the-middle attacks against Remote Desktop, but I didn't want to troubleshoot Remote Desktop and IPsec at the same time during the initial configuration. The renamed Administrator and Guest accounts and their complex passwords would make remote password guessing unlikely to succeed against the server.

In addition, I made the following changes to the Remote Desktop setup by using Group Policy:

On the server's Remote Desktop settings, I enabled:

I copied Windows 2003 Service Pack 1 (SP1) to the server, installed it, and rebooted the server. Then I ran Microsoft Baseline Security Analyzer (MBSA) to see whether anymore patches were needed, which was more difficult than it sounds. I needed to run it without accessing the Internet and exposing the possibly unpatched server to maliciousness. In order to do that, I downloaded MBSA's XML database, called mssecure.xml, to my local machine, then copied it to the server. I then ran MBSA, which revealed no missing patches or noted vulnerabilities. (I ran MBSA again after installing IIS because MBSA doesn't scan for IIS patches or vulnerabilities until IIS is installed and running.)

Note: A default installation of Windows 2003 SP1 is simpler than the steps I just described of patching the machine prior to attaching the server to the Internet. SP1 prevents all access to the server until after patching has been accomplished, so the risk of malicious exploit prior to all patches being applied is minimized. However, physically disconnecting all Internet access and patching manually is always more secure.

Next, I ran the Windows 2003 SP1 Security Configuration Wizard (SCW), choosing the server's role of a standalone IIS box and disabling all other unnecessary functions and services. Microsoft's cool new wizard did most of the work and guided me along, but it didn't disable enough services to satisfy me, so I had to disable a few services manually. Here's a recap of my SCW experience:

I then manually disabled even more services in the Services console:

I opened the server's Local Computer Policy (gpedit.msc) and made the following changes/selections:

I also disabled File and Printer Sharing in the Network Configuration dialog box and hardened the TCP stack with the registry edits recommended at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/secmod/html/secmod109.asp. I then rebooted the server to make sure all the changes took effect and to make sure the server was responding normally. Now, it was time to install the Web server software.

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):

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:

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.