Updating the IIS Security Checklist

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.

   Previous  [1]  2  3  Next