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:

• Specifically denied the anonymous user access to Remote Desktop
• Set encryption to High
• Disabled the use of remote control on Remote Assistance connections
• Forced a user to close a session after disconnecting
• Prevented a program from starting at logon so that the desktop was always shown immediately after a successful Remote Desktop connection
• Disabled all mappings except clipboard

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

• Delete temporary folders on exit
• Use temporary folders per session
• Active Desktop is disabled
• Permission capability: full security
• Restrict each user to 1 session: yes

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:

1. On the Server Roles wizard screen, I chose only the Web Server role; I deselected Application Server, File Server, and Middle-tier Application Server (COM+/DTC).
2. On the Client Features wizard screen, I deselected all features.
3. On the Installed Options wizard screen, I selected: Backup (NT or 3rd Party), Backup to local hardware, Local application installation, Remote desktop administration, Remote SCW configuration and analysis, Remote Windows administration, Windows Firewall, and Windows user mode driver framework. I cleared the Time Synchronization and WPAD options.
4. I disabled Upload Manager.
5. I configured Windows Firewall to include the necessary RDP port.
6. I configured the LAN Manager (LM), NTLM, and NTLMv2 authentication protocols to be disabled.
7. I configured auditing to include all successes and failures.

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

• Application Experience Lookup Service
• Automatic Updates
• BITS
• Computer Browser
• DHCP Client
• Error Reporting Service
• Help and Support
• Network Location Awareness
• Print Spooler
• Remote Registry
• Secondary Logon
• Server
• Smartcard
• TCP/IP NetBIOS Helper
• Workstation
• Windows Audio
• Windows Time
• Wireless Configuration

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

1. Set minimum password size equal to 12.
2. Enabled Password Complexity requirements.
3. Set Account Lockout threshold to five bad passwords in 1 minute—results in a 1-minute lockout.
4. Enabled Success/Failure auditing for all audit categories except Directory Service Access and Process Tracking.
5. Removed Everyone group from Access this computer from the network user right.
6. Under User Rights Assignment, removed Power Users and Backup Operators as members of the Access this computer from the network user right.
7. Changed Unsigned Driver behavior from Warn to Don't Allow
8. Enabled Message Text for Interactive Logon (just to defeat any brute-force logon-guessing tools). Didn't select the normal Unauthorized access not allowed setting.
9. Disabled Logon caching (which should have no effect on the server).
10. Enabled the Do not allow the anonymous access of SAM accounts and shares option.
11. Enabled the Do not allow the storage of credentials or Passports for network authentication option.
12. Enabled the Do not store Lan Man hash value on next password change option.
13. Changed LM Authentication Level to NTLMv2—refuse LM and NTLM.
14. Enabled the Clear virtual memory page file option.
15. Removed Posix as an optional Windows subsystem.
16. Enabled the Do not allow Windows Messenger to be run option.
17. Enabled the Do not allow Windows DRM to be run option.
18. Enabled the Do not allow Windows Movie Maker to be run option.
19. Disabled Automatic Updates.
20. Turned off Slow Link Detection for GPOs.
21. Enabled WFP Scanning during startup.
22. Restricted CD-ROM and floppy drive use to local logged-on users only.
23. Denied Log On Locally right to IIS anonymous users.
24. Enabled the Interactive Logon: Do not display user info option.
25. Removed DFS$ and COMCFG from file shares that allow anonymous logon.
26. Disabled Active Desktop.

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.

   Previous  [1]  2  Next