Hardening an IIS 4.0 Web Server

Peel off the extra service layers to create an impenetrable public Internet server

Running any service on a computer attached to the Internet requires careful planning. While providing the required service, you need to ensure that you aren't providing other services that crackers can use as entry points into your network. Furthermore, you need to take steps to lockdown the required service as much as possible. This guide helps you perform both of these hardening tasks on a Windows NT 4.0 server running IIS 4.0. I show you how to turn your Web server into a bastion host—a host computer that you make directly available to the public network and that's designed to screen the rest of the network from security exposures.

(Don't use hardening techniques on an internal file and print server or domain controller—DC; the techniques remove some services that these servers need to function.)

To build a UNIX Web server, you usually start with a base installation of the OS and add only the necessary services, thereby limiting the server's functionality and complexity to the minimum required. For an NT Web server, you work backwards from a complete installation to remove all but what you need. In other words, you peel away the outer layers of software and services until you're left with nothing but a hard inner core of NT and IIS. By removing or locking down all unnecessary functions on your Web server, you protect your server not only from today's known attacks but also from attacks that will be developed in the future. For example, if someone manages to use a new type of attack, or exploit, to somehow make the IUSR_computername account execute a file that isn't in the server's wwwroot directory, that attempt won't compromise your machine because you'll have explicitly locked down permissions on that account.

Install NT
Start with a fresh installation of the English-language version of NT Server 4.0. (Microsoft is notoriously slow to release patches for foreign-language versions.) Don't attempt to harden an existing production Web server; unpredictable results will occur. If you want to harden an existing Web site, set up a new server and migrate the Web site's application and data to the new box after you've completed the steps in this guide.

Use NTFS on all partitions. Install only one copy of the OS on the server. If you ever need another copy of the OS on the server for troubleshooting, install it only when necessary and remove it afterward to limit the server's exposure to attacks. Choose the standalone server role, not the PDC or BDC role. Install the server as a workgroup member, not a domain member. You want only local accounts on this machine to limit exposure to your production NT domain. You'll remove most of the functionality that would let this server communicate in a domain infrastructure. You won't be able to use normal NT drive mapping or other trusted host-type features that are commonly used in NT domains.

After installing the OS, download NT 4.0 Service Pack 6a (SP6a) at http://www.microsoft.com/ntserver/nts/downloads/recommended/sp6/allsp6.asp and install it. Then, download Microsoft Internet Explorer (IE) 5.01 SP2 at http://www.microsoft.com/ windows/ie/download/ie501sp2.htm and install it. Don't install Active Desktop—you're trying to keep the installation as simple as possible by limiting it to the software necessary for Web functionality.

Install the NT 4.0 Option Pack, and choose custom installation. Install only the items that Figure 1 shows. (Clear all other items.)

After you install the Option Pack, install applicable updates. Keeping up-to-date with service packs and hotfixes is a full-time job. Microsoft has withdrawn some hotfixes a few days after releasing them because the fixes introduced bigger security holes than they fixed. Other hotfixes have been known to break a server. When a new fix becomes available, you must assess your level of exposure and decide how soon to implement the fix. A lab with a similarly configured Web server on which you can test the fix is extremely helpful in making such calls. However, unless you're facing a clear and present danger, I suggest waiting a few days after Microsoft releases a hotfix and monitoring the security mailing lists and newsgroups to see what results others have with the fix. Figure 2 lists the service packs and hotfixes I had installed as of August 2000. For more complete information, see http://www.microsoft.com/technet/treeview/default.asp?url=/technet/itsolutions/security/current.asp? productid=16&servicepackid=7.

Move your wwwroot directory to a separate partition or disk from the OS. Choose the default setting, local administration, for Microsoft Transaction Server (MTS). Microsoft Data Access Components (MDAC) has created holes that have given crackers access to many IIS servers. Later, I show you how to edit the registry to close these holes. For now, install the latest compatible version of MDAC (release to manufacturing—RTM—version 2.6 as of this writing) at http://www.microsoft.com/data/download.htm?rld=377.

Configure NT
Now that you've installed most of the necessary software, you can start configuring it. First, on all partitions, change the default setting that gives everyone full control. Use File Manager to recursively set permissions on each partition's root directory to give administrators full control and the system full control. You'll further refine the NTFS permissions later.

To protect the server console, set up the screen saver for the administrator's profile. Open the Control Panel Display applet, click the Screen Saver tab, and select the Password protection check box.

Now, remove all services that aren't integral to running your Web server. Your goal is to remove services that you know are vulnerable to attack and services that aren't necessary and might provide points of ingress for future attacks. If you're trying out a new configuration or Web application, I suggest disabling the services one by one and testing between each change. I've had good luck disabling these Control Panel Services applet services, but you might need to adjust this list for your situation: Alerter, ClipBook Server, Computer Browser, DHCP Client, Directory Replicator, FTP Publishing Service, License Logging Service, Messenger, Net Logon, Network DDE, Network DDE DSDM, Network Monitor, Plug and Play (disable after all hardware configuration), Remote Access Server, Remote Procedure Call (RPC) Locator, Schedule, Server, Simple Services, Spooler, TCP/IP NetBIOS Helper, and Telephony Service.

If you don't use these services, disable them as well: SNMP Service, SNMP Trap, and UPS. These services are required: EventLog, MSDTC, NTLM Support Security Provider, Protected Storage, Remote Procedure Call (RPC) Service, Workstation (you'll disable this service later), and WWW.

I strongly urge you not to use the FTP server that comes with IIS but rather to install SSH Communications Security's SSH Secure Shell to provide encrypted file transfers. (I discuss SSH more later.)

If you're using SNMP, perform these steps to set a strong password in the community string:

To turn on the functionality for locking out the Administrator account over the network, use the Microsoft Windows NT Server 4.0 Resource Kit's Passprop utility to run the command

passprop /adminlockout /complex

This command stops intruders from brute forcing the password over the network.

Configure IIS
Many recent reconnaissance techniques and other exploits use sample files that default installations leave, so remove all the IIS and related sample directories that Table 1 lists. Also remove all the IIS extension mappings listed in Table 2 that you aren't using. To remove the extension mappings, follow these steps:

If you aren't sure whether you'll use an extension, remove it, then add it later if you need to.

For the remaining extensions, consider limiting the HTTP verbs that the extension will accept. Instead of using all the verbs (i.e., DELETE, GET, HEAD, PUT, and TRACE), use only GET for static Web pages and PUT if you have forms on your site. You want to explicitly allow only the minimum actions needed per extension and hopefully remove dangerous verbs such as DELETE.

Disable rather than delete the Default Web Site—it might be useful for upgrading the server, and applications might point to the Default Web Site. In ISM, right-click Default Web Site, then select Properties. Select Directories, Security, then click Anonymous Access & Authentication Control. Click Edit, then clear all the check boxes, as Figure 3 shows. The system will warn you that you're shutting off all access; click Yes to continue. Perform the same steps for the Administrative Web Site.

Configure the Network
To allow only needed TCP/IP ports, open the Control Panel Network applet and double-click Protocols. Select TCP/IP Protocol, click Properties, then click Advanced. Select the Enable Security option, then click Configure. In the TCP Ports section of the resulting TCP/IP Security dialog box, select the Permit Only option, then add port 80 for HTTP, port 443 for Secure Sockets Layer (SSL), and port 22 for SSH. In the UDP Ports section of the dialog box, select the Permit Only option, then add port 161 and port 162, both for SNMP. In the IP Protocols section of the dialog box, select the Permit Only option, then add protocol 6 and protocol 8. Click OK to accept the additions. If for some reason you need to Web surf from the box (which I strongly discourage), you must also add port 53 in the UDP Ports section.

In addition to restricting the allowed ports, you need to make sure that the server is using only TCP/IP protocols—specifically, only those needed for client Web requests and remote administration through SSH. In the Control Panel Network applet, click Protocols, then remove all the protocols except TCP/IP. You also need to unbind NetBIOS from TCP/IP. In the Control Panel Network applet, click the Bindings tab, right-click NetBIOS Interface, then click Disable.

Remove Commonly Exploited Files from Path
To prevent crackers from using any new attack to execute files on your Web server, you need to ensure that intruders can't easily access on your server those files that would let them copy their cracking toolkits. To safeguard your files, you can move them and set their ACLs to allow only Administrator access.

Create a directory on the server's C drive, then move these files from the system32 directory to the new directory: arp.exe, at.exe, atsvc.exe, cacls .exe, cmd.exe, command.com, cscript .exe, debug.exe, edit.com, edlin.exe, finger.exe, ftp.exe, ipconfig.exe, nbtstat .exe, net.exe, netstat.exe, nslookup.exe, ping.exe, posix.exe, qbasic.exe, rcp.exe, rdisk.exe, regedt32.exe, regedit.exe, rexec.exe, route.exe, rsh.exe, runonce .exe, secfixup.exe, syskey.exe, telnet.exe, tftp.exe, tracert.exe, wscript.exe, and xcopy.exe. Then, restrict access to the new directory to Administrator Full Control. This example is a classic technique for reducing the damage crackers can do, even if they somehow get a foothold into your system.

Run the Hisecweb.inf Hardening Script
The next step is to run hisecweb.inf, a slightly modified version of Microsoft's high-security Web server .inf file for NT 4.0 and IIS 4.0. Download hisecweb .zip from the Code Library on the IIS Administrator Web site (http://www .iisadministrator.com), and unzip the file to a Temp directory.

Web-exclusive Figure 1 summarizes the changes that hisecweb.inf makes to your server. For a detailed look at the changes, open the hisecweb.inf file in the Microsoft Management Console (MMC) Security Configuration Editor snap-in. To implement the hisecweb .inf changes, type the command

secedit /configure  /cfg hisecweb.inf /db  %temp%secedit.sdb /verbose  /log %temp%seclog.txt

at the command prompt. Hisecweb .inf renames the Administrator account to root. Set a strong password on the Administrator account, then change root to a name that's unique in your environment.

Edit the Registry
Hisecweb.inf can't perform all the necessary registry edits; you must do some manually (e.g., you must delete some registry keys). So fire up regedt32, and start hacking away at the registry. (The standard disclaimers apply, of course.) First, remove the OS/2 and POSIX subsystems. To do so, remove the HKEY_LOCAL_MACHINESOFT WARE MicrosoftOS/2 Subsystem for NT registry subkey. Then remove the HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSessionManagerEnvironmentOs2LibPath registry subkey. Finally, remove these registry subkeys: HKEY_LOCAL _MACHI NESYSTEMCurrentControl SetControlSession ManagerSub-SystemsOptional, HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSessionManagerSubSystemsPosix, and HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSessionManagerSubSystemsOs2. Open Windows Explorer, and delete the C:winntsystem32os2 directory and all its subdirectories.

One of the most devastating IIS attacks of recent years is an exploit in which a cracker uses the MDAC Remote Data Services (RDS) Data Factory component to gain unauthorized access to an IIS machine. After Rain .Forest.Puppy discovered the vulnerability, crackers ran autoscripts that searched the Web for IIS servers that had the component installed. When the crackers found an exploitable copy of MDAC, they copied root kits that contained remote-access programs such as Virtual Network Computing (VNC) to the Web server or they defaced the server's Web sites. No level of hotfix or service pack can protect your server against MDAC attacks—you must remove the RDS Data Factory object. If you aren't using the Data Factory object—and chances are that you aren't on a bastion Web server—remove its functionality. To do so, delete these registry subkeys: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesW3SVCParametersADCLaunchRDSServer.DataFactory, HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesW3SVCParametersADCLaunchAdvancedDataFactory, and HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesW3SVCParametersADCLaunchVbBusObj.VbBusObjCls. Then, reboot your server. You can read more about the MDAC vulnerability at http://www.wiretrip.net/rfp/p/doc.asp?id=5&iface=7.

Remove Network Services
The next step is to remove unnecessary network services. In the Control Panel Network applet, click Services. Remove NetBIOS Interface, Computer Browser, Server, and Workstation. Keep RPC Configuration, and keep SNMP if necessary. Note that when you remove the Workstation service, you receive the message Windows NT Networking is not installed. Do you want to install it now? each time you open the Control Panel Network applet. Just click No in the message box when this happens.

Set Permissions
Now you can further lockdown permissions to peel off another few layers of security vulnerability. First, secure the IUSR_computername account. Open User Manager. Under Username, rename the IUSR_computername account to an obscure name. Set a strong password, and ensure that the renamed IUSR_computername account is disabled.

Remove the renamed IUSR_computername account from the Guest group. Set permission for the renamed IUSR_computername account on all volumes to No Access. To let the Web server function properly, change the renamed IUSR_computername account permission to Read Only for the directories that Table 3 shows. (Don't use recursive permissions for these directories.)

I recommend that you also reset some user rights. In User Manager, select Policies, User Rights, then set the rights that Table 4 specifies.

Set the Firewall Access List
Even these steps aren't enough to ensure the security of your bastion server. You must also have a perimeter firewall that limits access to the box. You want to let in HTTP and allow a few management protocols in to a select few subnets. Web-exclusive Figure 2 shows a sample ACL for a router acting as a firewall that permits only HTTP (port 80), SSL (port 443), SSH, and SNMP. If you need to Web surf from the box, you must also add UDP port 53 as an allowed port in the firewall.

Administer the Server with SSH
You've disabled all the normal methods for updating your Web server (i.e., Microsoft FrontPage Server Extensions, FTP, and Filesharing), but you still need to be able to administer the box, and your Web developers need to be able to upload new content in a secure way. The best tool for securely updating and administering the server is SSH, which provides strong user authentication and end-to-end encryption. SSH encrypts all communication between client and server, unlike FTP, which passes data (including passwords) in plaintext.

I currently install a commercial version of SSH, SSH Secure Shell for Windows Servers, on my bastion-host Web servers, and I highly recommend that all commercial installations do the same. You can download SSH Secure Shell for Windows Servers (which comes with support updates and a graphical file-transfer program and costs $565) from http://www.ssh .com/products/ssh.

You can download free versions of SSH for Windows from various Web sites. For your convenience, I've included sshdnt.zip, an old SSH for NT port that I formerly used. You can download sshdnt.zip from the Code Library on the IIS Administrator Web site. Use this port with caution—if you have more than one user simultaneously accessing the server, one user could run code in another user's context, thereby elevating the first user's privilege level.

Download sshdnt.zip to a Temp directory on your bastion-host Web server, then decompress it. From the same directory, run install.bat, which creates a server key, installs SSH as a service, and starts the SSH service. Edit the Passwd file (in C:etc) to add users in the format username:x:user ID:group ID:full name:home directory:. For example, you could add the user administrator:x:1:10:Local Administrator:/bin:.

To transfer files between computers running SSH, you use the Secure Copy (scp) command. For example, to push the net.txt file from a UNIX host named host.com to the bin directory on an NT host with IP address 10.0.0.20, you log on to host.com and type

scp net.txt  [email protected]:/bin

To pull the test.exe file from the same NT host to your user directory on host.com, log on to host.com and type

scp [email protected]:  test.exe /home/user

You now have a secure, remotely manageable Web server. You might think that your quest for a secure Web server is over, but nothing could be further from the truth. You've made a good start, but you need to stay current with what's happening in both the NT and the security world and make sure that you implement a process for testing and deploying hotfixes and patches before a critical event occurs.