I want to use the IIS Lockdown Tool 2.0 as one step toward securing my company's IIS servers, but none of the existing server roles fit my needs. Can I modify the server roles?
The IIS Lockdown Tool is excellent for applying a security baseline to Web servers. When Microsoft first released it, the IIS Lockdown Tool didn't integrate well with all the roles that IIS can serve. IIS is a crucial component in a dozen or more Microsoft products, each potentially requiring a unique configuration. Consequently, IIS Lockdown Tool 2.0 lets you specify the role that IIS serves by advising the tool which security features to apply or not to apply. Begin by selecting one of the templates in lockdown_templates.tif. If necessary, you can customize the templates to create a server type to suit your needs.
The key to customizing the IIS Lockdown Tool is the iislockd.ini file. You can locate this file inside the iislockd.exe file that you use to run the IIS Lockdown Wizard. The iislockd.ini file and the other contents of the iislockd.exe file are installed to \%systemroot%\inetsrv\system32\lockdown when you first run the wizard.
This iislockd.ini file's structure is simple. An \[info\] section at the top of the iislockd.ini file lists the server types for Windows NT 4.0 as "ServerTypesNT4=sbs4.5, exchange5.5, frontpage ..." and server types for Windows 2000 as "ServerTypes=sbs2000, exchange5.5, exchange2k ...". Use Notepad or another text editor to add the server name you'll use to reference the configuration settings in the list that Figure 1 shows to the appropriate line of the \[info\] section. If you want to, remove all other entries so that only one choice appears.
The second part of iislockd.ini consists of configuration settings for each server. Refer to Figure 1 for the configuration settings for a static Web server.
To customize these settings for your own template, copy the complete set of options under one of the server settings (e.g., the static Web server that begins with \[staticweb\]) and paste it to the end of the file. Change the identifying label in brackets from \[staticweb\] to \[newservername\]. Be sure that the name you add between the brackets exactly matches the name you entered in the \[info\] section.
Next, change the entry line that reads label="Static Web server" to reference the way you want to describe the template in the IIS Lockdown Wizard, which Figure 2, page 6, shows. Doing so lets you customize the entry for your company or specific purpose.
Continue to configure the settings according to your needs. Many entries (e.g., Remove_iishelp_virtual_directory=TRUE) are self-explanatory. Others, however, could use a little explanation.
The Enable_iis_http=TRUE, Enable_iis_ftp=FALSE, Enable_iis_smtp=FALSE, and Enable_iis_nntp=FALSE settings cause these associated services to be set to Automatic or Disabled in the Microsoft Management Console (MMC) Services snap-in. The IIS Lockdown Tool takes this capability a step further by letting you actually uninstall the selected services instead of simply disabling them. This occurs when UninstallServices=TRUE appears in the .ini file.
When you set Enable_asp , Enable_index_server_web_interface, Enable_server_side_includes, Enable_internet_data_connector, Enable_internet_printing, and Enable_HTR_scripting to FALSE, you don't remove the script mappings for these various Web-based applications. Instead, you map the associated file extensions to a provided file (404.dll). I call this a "deadend" configuration. When IIS receives a request for an extension configured in this way, a File not found message is returned. For example, by default, when IIS receives a request for file extensions .asp, .asa, and .cer, IIS invokes asp.dll. If you set Enable_asp=FALSE in the .ini file, then .asp, .asa, and .cer are set to invoke 404.dll.
The practice of mapping extensions to a dead end is an excellent practice that's more secure than removing the application extensions completely because in some cases, the application mappings can mysteriously reappear. (Certain application installations, or even Group Policy, can affect these mappings.)
The settings labeled Disable_Anonymous_user_system_utility_execute_rights and Disable_Anonymous_user_content_directory_write_rights are particularly useful. When these settings are enabled, the IUSR and IWAM accounts are denied Execute permissions on system utilities that reside in the \winnt folder and other locations. The IUSR and IWAM accounts are also denied Write permissions to Web-site content.
I like the mechanics of the feature that Disable_Anonymous_user_system_utility_execute_rights and Disable_Anonymous_user_content_directory_write_rights enable because Microsoft chose to create new local groups called Web Anonymous Users and Web Application Users and make the IUSR and IWAM accounts members of those groups, respectively. Therefore, when you assign permissions, the Deny Execute and Deny Write permissions are assigned to the local groups instead of directly to user accounts.
MCSEs might recognize this technique of creating a local group, assigning a user to the group, and assigning permissions to the group as a key best-practices technique that many Microsoft courses teach. Sound reasoning supports this technique. If you want to treat another user or group as if they were anonymous Web users, you need only to make them a member of the Web Anonymous Users group and you have an authenticated user who has the same rights as the IUSR account. In addition, because the IIS Lockdown Tool adds only these Deny permissions, your existing permissions are unmodified. The IIS Lockdown Tool doesn't meddle with your carefully crafted settings.
Finally, two settings refer to URLScan. You'll undoubtedly need to install and refer to a correctly configured urlscan.ini file. After you've configured the iislockd.ini file the way you want, run the IIS Lockdown Tool to display the templates, which will include your customized template.
