Updating the IIS Security Checklist

Take some additional steps to really lock down IIS 5.0

The Secure Internet Information Services 5 Checklist, adapted from Michael Howard's widely used book Designing Secure Web-Based Applications for Microsoft Windows 2000 (Microsoft Press, 2000), describes the basic actions required to secure an IIS 5.0 server. But 2 years have passed since Microsoft made the checklist available, and it's time to review the checklist's recommendations and, in some cases, update them. To get the most from this article, refer to the checklist (http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/tools/chklist/iis5chk.asp) as you read my suggestions.

Checklist Item: Review, Update, and Deploy the Provided Hisecweb.inf Security Template
The hisecweb.inf template is designed for use with the Security Configuration and Analysis tool. Describing how to use the Security Configuration and Analysis tool to deploy security templates is well beyond the scope of this article, but I strongly encourage you to become familiar with this tool if you aren't already. (For more information about the tool, see Ken Spencer, "Resource Kit Security Templates," April 2001, InstantDoc ID 20062.) I think Hisecweb is too relaxed to qualify for a "high-security" rating. The template doesn't apply any NTFS permissions, and it doesn't disable many features and services that you should disable because you don't need them to run an IIS server. In general, Hisecweb is permissive because it's designed to let IIS participate in a domain environment as a member server.

Although Hisecweb doesn't rise to the level of creating a bastion host for Internet access, the template can be useful, particularly if you don't want to compromise functionality in a Microsoft networking environment. But for a more secure server, consider SystemExperts' web_secure.inf template, which you can download from http://www.systemexperts.com/win2k/HardenWin2K.html. The web_secure.inf template assigns NTFS permissions to many administrative tools, sets ACLs on registry keys, and disables services not required for IIS, providing a much more secure server environment than Hisecweb.

My point is that security templates are a useful tool for deploying security settings on servers because they let you implement a complex set of assignments in a quick and uniform manner. Additionally, you can use Group Policy to deploy templates to the servers on your network.

Checklist Item: Configure IPSec Policy
The checklist suggests implementing IP Security (IPSec) for port filtering, which I think is an excellent suggestion. However, don't overlook an important detail about IPSec port filtering that wasn't widely known at the time Howard created the checklist. As the Microsoft article "IPSec Does Not Secure Kerberos Traffic Between Domain Controllers" (http://support.microsoft.com/default.aspx?scid=kb;enus;q254728) details, IPSec port filtering permits all traffic originating from or going to port 88, even if port 88 is specifically not allowed. (Port 88 is the port that Kerberos traffic uses.) IPSec's Kerberos exception ensures that Kerberos works, regardless of whether IPSec filtering is enabled. However, the exception makes IPSec port filtering all but useless unless you apply the registry setting that the Microsoft article explains. (Although the article refers to traffic between domain controllers—DCs—it applies to standalone servers and member servers as well.)

Checklist Item: Disable NetBIOS over TCP/IP
The checklist details steps for disabling NetBIOS over TCP/IP (NetBT), which you should perform if possible. If the checklist suggests disabling NetBT, Hisecweb should also disable more NetBT-related services (e.g., TCP/IP NetBIOS Helper Service) that you won't require if you disable NetBT.

You should also unbind file-and-print sharing if possible. Right-click My Network Places and select Properties to open the Open Network and Dialup Connections dialog box. Select Advanced Settings from the Advanced menu, and clear the File and Printer Sharing check box. This action prevents your server from using a Universal Naming Convention (UNC) path to serve files and might interfere with remote backup and administration. However, a Web server doesn't need to offer files through shares and UNC paths.

Checklist Item: Set Appropriate ACLs on Virtual Directories
Although this checklist topic is titled "Set Appropriate ACLs on Virtual Directories," you should apply the suggested NTFS permissions to the Web site root and regular folders as well as to virtual directories. Table 1, page 14, shows the more restrictive permissions that I recommend.

Table 1 differs from the checklist table in two ways. Instead of using the Everyone group, Table 1 uses Authenticated Users. Authenticated Users includes the IUSR anonymous Web user account but omits null connections and users who are members of the Guests group only. The second difference reflects a modification that the IIS Lockdown tool automatically makes when you run it. The IIS Lockdown tool makes the IUSR anonymous Web user account a member of the Web Anonymous Users local group. Optionally, you can assign the Web Anonymous Users local group the Deny Write permission to Web content and the Deny Execute permission to administrative tools. The Lockdown Tool's use of the Web Anonymous Users local group ensures that permissions are tightened without interfering with other NTFS permissions. You can easily add other groups to give them the same permissions as the Web Anonymous Users or remove the IUSR account from the local group to quickly nullify the effects of the Deny permissions. Managing permissions through group membership can be useful when you troubleshoot—to ensure that the Deny strategy doesn't interfere with proper server functioning.

Checklist Item: Set Appropriate IIS Log File ACLs
The checklist recommends the following permissions for the IIS log files:

One problem with these settings is that Win2K has no C permission. Windows NT 4.0 has a C for Change permission and Win2K has a Create Files/Write Data special permission, but I don't know whether C refers to either of those permissions. (The Change permission in NT 4.0 is equivalent to the Modify permission in Win2K.) To make matters more confusing, the checklist includes the illogical statement that these permissions "help prevent malicious users deleting the files to cover their tracks."

The recommended permissions give users Read and Execute capabilities on the Logfiles folder. Thus, the IUSR account or any user on the Web server has the ability to change the log files. My research shows that users don't need to write to the log files, and I don't know why Microsoft suggests granting these permissions. I suggest that the only permissions you grant to the log files are to give the local Administrators group and the System group Full Control.

Checklist Item: Set IP Address/DNS Address Restrictions
The checklist suggests that although few people set IP address restrictions, you could do so to prevent specific users from accessing the server. However, you can also use this feature to configure IIS to accept connections only from the firewall, a Network Address Translation (NAT) device, a proxy server, or other network devices and servers that you intend to access the server. IIS then refuses all packets except those from the specified addresses. Some firewalls and application proxies forward the source address of the original request (otherwise, Web logs show the firewall's address for all requests), so the effectiveness of this recommendation depends on the firewall or proxy server and how you configure it.

In addition to using IP address restrictions in IIS, you can implement the same restrictions in IPSec when you implement port filtering. Then, if an intruder defeats IPSec, the IIS rules still apply.

Using DNS address restrictions is a bad idea. Performing a reverse DNS lookup on each Get request is unworkable because not all IP addresses are resolved by using reverse DNS lookups, and a reverse DNS lookup isn't feasible for performance reasons.

Checklist Item: Remove Unused Script Mappings
Removing unused script mappings is widely regarded as a best practice in IIS. However, the IIS Lockdown tool has an even better approach. Instead of removing unrequired application mappings, the tool maps them to 404.dll (a DLL that the IIS Lockdown tool provides for this purpose), as Figure 1 shows. The IIS Lockdown tool's approach is an improvement over simply removing the application mappings because, in some circumstances, absent application mappings are reinstalled on the server without your knowledge. For example, if you enable the Web Based Printing Group Policy, Win2K will reinstall the printer mapping, even after you've explicitly removed it. Additionally, if you install Index Services on the server, the Index Services installation program will install related extensions (e.g., .idc, .htx) if they're absent.

So, although leaving the application mappings in place to better secure the server (i.e., if you plan to use the IIS Lockdown tool) might seem counterintuitive, it's a good strategy. You can extend this technique to further secure the server by mapping extensions such as .inc (include files) and .mdb (Microsoft Access database files) to 404.dll. Then, if an attacker attempts to download a file with those extensions, they receive a 404 File Not Found error, but your applications can still access such files. If you don't plan to use the IIS Lockdown tool or don't plan to manually implement the dead-end strategy, you certainly should remove the extensions.

Other Security Steps
Other checklist recommendations are excellent as written, including the following:

However, you should take a few other steps as well.

Place your Web content on a drive other than your system drive. Placing your Web content on a drive other than your system drive helps mitigate the damage that an intruder who breaks out of the Web content tree can do. If you use this widely accepted technique, an intruder who tries a directory-traversal exploit must move from the Web content drive to your system drive (where you would have additional protections) to look for useful utilities such as tftp.exe and cmd.exe in known locations.

Run the IIS Lockdown tool. IIS Lockdown is an important addition to the security of your Web servers. Running this tool implements several best practices:

Install and configure URLScan. The IIS Lockdown tool optionally installs the URLScan Internet Server API (ISAPI) filter (or you can install URLScan manually). You should install URLScan on all your IIS servers, even those that have host-based intrusion-detection software systems installed. URLScan inspects incoming URLs and rejects all requests that don't conform to your standards. To configure URLScan, you use the urlscan.ini file, which controls all aspects of the tool's behavior.

The current version of URLScan, 2.5, adds an important enhancement to this already valuable security tool—it lets you reject URLs whose length exceeds your specified standard. In addition to defining a restriction on the entire URL length, you can limit the portion of the URL string that precedes or follows a question mark (?). The portion of a URL that follows a question mark contains information, usually form input fields, that the browser sends to request a Web page. Intruders can use this portion to send bogus information to the server to invoke a buffer overflow or to induce a software failure (e.g., by sending a megabyte of data in a name or address field). You can also limit the length of the URL that precedes the question mark.

Limiting the length of the URL is a strong defense because you can seriously constrain an intruder's ability to upload executable content. If you don't use URLScan to limit URL length, IIS 5.0 accepts a client request of up to 512KB and IIS 4.0 permits a length of up to 2MB. For more information about URLScan and version 2.5, see Randy Franklin Smith, "Protect Your IIS Server with URLScan," July 2002, InstantDoc ID 25230, and "Deploy URLScan to Protect Your IIS Server," August 2002, InstantDoc ID 25581. Also see the Microsoft article "INFO: Availability of URLScan Version 2.5 Security Tool" (http://support.microsoft.com/default.aspx?scid=kb;en-us;q307608).

Run the Microsoft Baseline Security Analyzer. MBSA is a relatively new tool with a good UI (which Figure 2, page 16, shows) that reports on the missing hotfixes and security vulnerabilities of a computer or set of computers. MBSA reports vulnerabilities such as weak password policies or accounts named Administrator, and IIS risks such as enabled parent paths or the presence of an Msadc virtual directory (as Figure 3, page 16, shows). MBSA uses the Hfnetchk engine to report on hotfixes missing from the server, and it lets you click a link that takes you directly to their related security bulletin. You can run MBSA for a single computer or subnet and capture the report to a file for analysis. For more information about MBSA, see http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/tools/tools/mbsahome.asp.

Obviously, you can do much more to secure your IIS server. I haven't addressed auditing, authentication details, and tuning the urlscan.ini file to work in your circumstances. Nevertheless, implementing this improved checklist will protect your server from most common attacks and present a strong defense for unknown future vulnerabilities. Just removing or disabling application mappings prevents both the CodeRed and Nimda worms from infecting a server through an IIS vector. Nimda has multiple vectors; CodeRed does not.

For more information about securing your IIS server, I recommend that you review the National Security Agency (NSA) white paper "Guide to the Secure Configuration and Administration of Microsoft Internet Information Services 5.0" (http://nsa1.www.conxion.com/win2k/guides/w2k-14.pdf) and SystemExperts' Hardening Windows 2000 Guide (http://www.systemexperts.com/win2k/HardenWin2K.html). In addition, Michael Howard's book that I referenced at the beginning of this article is excellent, as is Stuart McClure, Joel Scambray, and George Kurtz's Hacking Exposed: Network Security Secrets & Solutions, 3rd edition (Osborne McGraw-Hill, 2001), which you can learn more about at http://www.hackingexposed.com. All these resources are required reading.