Chapter 9: The Web Server Role

IIS examines Web site permissions to determine the types of action that can occur within a Web site, such as script source access or directory browsing. You should assign Web site permissions to provide additional security for Web sites on IIS servers in the three environments that are defined in this guide.

Web site permissions can be used in conjunction with NTFS permissions, and can be configured for specific sites, directories, and files. Unlike NTFS permissions, Web site permissions affect everyone who tries to access a Web site that runs on an IIS server. Web site permissions can be applied with the MMC IIS Manager snap-in.

The following table lists the Web site permissions that are supported by IIS 6.0, and provides brief explanations of when to assign any given permission to a Web site.

Table 9.9 IIS 6.0 Web Site Permissions

Configuring IIS Logging

Microsoft recommends that IIS logging be enabled on IIS servers in the three environments that are defined in this guide.

Separate logs can be created for each Web site or application. IIS logs more information than the event logs and performance monitoring features that are provided by the Windows operating system. The IIS logs can include information such as who has visited a site, what the visitor viewed, and when the information was last viewed. IIS logs can be used to assess content popularity, identify information bottlenecks, or as resources to help investigate attacks.

The MMC IIS Manager snap-in can be used to configure the log file format, the log schedule, and the exact information to be logged. To limit the size of the logs, you should use a careful planning process to determine which fields to log.

When IIS logging is enabled, IIS uses the W3C Extended Log File Format to create daily activity logs in the directory that is specified for the Web site in IIS Manager. To improve server performance, you should store logs on a non-system striped or striped/mirrored disk volume.

Logs can also be written to a remote share over a network by using a full, Universal Naming Convention (UNC) path. Remote logging allows administrators to set up centralized log file storage and backup. However, server performance could be negatively affected when log files are written over the network.

IIS logging can be configured to use several other ASCII or Open Database Connectivity (ODBC) log file formats. ODBC logs can store activity information in a SQL database. However, note that when ODBC logging is enabled, IIS disables the kernel-mode cache, which can degrade overall server performance.

IIS servers that host hundreds of sites can enable centralized binary logging to improve logging performance. Centralized binary logging enables all Web sites on an IIS server to write activity information to a single log file. This method can greatly increase the manageability and scalability of the IIS logging process because it reduces the number of logs that need to be individually stored and analyzed. For more information about centralized binary logging, see the IIS Centralized Binary Logging (IIS6.0) page at www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/13a4c0b5-686b-4766-8729-a3402da835f1.mspx.

When IIS logs are stored on IIS servers, only server administrators have permission to access them by default. If a log file directory or file owner is not in the Local Administrators group, the HTTP.sys file (the kernel-mode driver in IIS 6.0) publishes an error to the NT event log. This error indicates that the owner of the directory or file is not in the Local Administrators group, and that logging has been suspended for that site until the owner is added to the Local Administrators group, or the existing directory or log file is deleted.

Manually Adding Unique Security Groups to User Rights Assignments

Most user rights assignments that are applied through the MSBP have the proper security groups specified in the security templates that accompany this guide. However, there are a few accounts and security groups that cannot be included in the templates because their security identifiers (SIDs) are specific to individual Windows 2003 domains. User rights assignments that must be configured manually are specified in the following table.

Warning: The following table contains values for the built-in Administrator account. Do not confuse the Administrator account with the built-in Administrators security group. If you add the Administrators security group to any of the listed deny access user rights, you will need to log on locally to correct the mistake. Also, you may have renamed the built-in Administrator account in accordance with the recommendation in Chapter 4, "The Member Server Baseline Policy." When you add the Administrator account to any user rights, ensure that the renamed account is specified.

Table 9.10 Manually Added User Rights Assignments

Important: “All non-operating system service accounts” includes service accounts that are used for specific applications across an enterprise, but does NOT include LOCAL SYSTEM, LOCAL SERVICE or the NETWORK SERVICE accounts (the built-in accounts that the operating system uses).

Securing Well-Known Accounts

Windows Server 2003 has a number of built-in user accounts that cannot be deleted but can be renamed. Two of the most well-known built-in accounts in Windows Server 2003 are Guest and Administrator.

By default, the Guest account is disabled on member servers and domain controllers. This configuration should not be changed. Many variations of malicious code use the built-in Administrator account in an initial attempt to compromise a server. Therefore, you should rename the built-in Administrator account and alter its description to help prevent compromise of remote servers by attackers who try to use this well-known account.

The value of this configuration change has diminished over the past few years since the release of attack tools that specify the security identifier (SID) of the built-in Administrator account to determine its true name and then break into the server. A SID is the value that uniquely identifies each user, group, computer account, and logon session on a network. It is not possible to change the SID of this built-in account. However, your operations groups can easily monitor attempted attacks against this Administrator account if you rename it with a unique name.

To secure well known accounts on IIS servers

• Rename the Administrator and Guest accounts, and change their passwords to long and complex values on every domain and server.
• Use different names and passwords on each server. If the same account names and passwords are used on all domains and servers, an attacker who gains access to one member server will be able to gain access to all others.
• Change the account descriptions to something other than the defaults to help prevent easy identification of the accounts.
• Record any changes you make in a secure location.

Note: You can rename the built-in administrator account through Group Policy. This setting was not implemented in any of the security templates that are provided with this guide because every organization should choose a unique name for this account. However, you can configure the Accounts: Rename administrator account setting to rename administrator accounts in the three environments that are defined in this guide. This policy setting is a part of the Security Options settings of a GPO.

Securing Service Accounts

Never configure a service to run under the security context of a domain account unless it is unavoidable. If the server is physically compromised, domain account passwords could be easily obtained by dumping LSA secrets. For more information about how to secure service accounts, see The Services and Service Accounts Security Planning Guide at https://go.microsoft.com/fwlink/?LinkId=41311.

Creating the Policy Using SCW

To deploy the necessary security settings, you must use both the Security Configuration Wizard (SCW) and the security templates that are included with the downloadable version of this guide to create a server policy.

When you create your own policy, be sure to skip the "Registry Settings" and “Audit Policy” sections. These settings are provided by the security templates for your chosen environment. This approach is necessary to ensure that the policy elements that are provided by the templates take precedence over those that would be configured by SCW.

You should use a new installation of the operating system to begin your configuration work, which helps ensure that there are no legacy settings or software from previous configurations. If possible, you should use on hardware that is similar to the hardware that is used in your deployment to help ensure as much compatibility as possible. The new installation is called a reference computer.

To create the IIS server policy

1. Create a new installation of Windows Server 2003 with SP1 on a new reference computer.
2. Install the Security Configuration Wizard component on the computer through Control Panel, Add/Remove Programs, Add/Remove Windows Components.
3. Join the computer to the domain, which will apply all security settings from parent OUs.
4. Install and configure only the mandatory applications that will be on every server that shares this role. Examples include role-specific services, software and management agents, tape backup agents, and antivirus or antispyware utilities.
5. Launch the SCW GUI, select Create new policy, and point it to the reference computer.
6. Ensure that the detected server roles are appropriate for your environment—for example the Application server and Web server roles.
7. Ensure that the detected client features are appropriate for your environment.
8. Ensure that the detected administrative options are appropriate for your environment.
9. Ensure that any additional services that are required by your baseline, such as backup agents or antivirus software, are detected.
10. Decide how to handle unspecified services in your environment. For extra security, you may wish to configure this policy setting to Disable. You should test this configuration before you deploy it to your production network because it may cause problems if your production servers run additional services that are not duplicated on your reference computer.
11. Ensure the Skip this section checkbox is unchecked in the "Network Security" section, and then click Next. The appropriate ports and applications identified earlier are configured as exceptions for Windows Firewall.
12. In the "Registry Settings" section, click the Skip this section checkbox and then click Next. These policy settings are imported from the supplied INF file.
13. In the "Audit Policy" section, click the Skip this section checkbox and then click Next. These policy settings are imported from the supplied INF file.
14. Include the appropriate security template (for example, EC-IIS Server.inf).
15. Save the policy with an appropriate name (for example, IIS Server.xml).

Note: The MSBP disables several other IIS-related services, including FTP, SMTP, and NNTP. The Web Server policy must be modified if any of these services are to be enabled on IIS servers in any of the three environments that are defined in this guide.

Test the Policy Using SCW

After you create and save the policy, Microsoft strongly recommends that you deploy it to your test environment. Ideally, your test servers will have the same hardware and software configuration as your production servers. This approach will allow you to find and fix potential problems, such as the presence of unexpected services that are required by specific hardware devices.

Two options are available to test the policy. You can use the native SCW deployment facilities, or deploy the policies through a GPO.

When you start to author your policies, you should consider using the native SCW deployment facilities. You can use SCW to push a policy to a single server at a time, or use Scwcmd to push the policy to a group of servers. The native deployment method allows you to easily roll back deployed policies from within SCW. This capability can be very useful when you make multiple changes to your policies during the test process.

The policy is tested to ensure that the application of this policy to the target servers will not adversely affect their critical functions. After you apply the configuration changes, you should begin to verify the core functionality of the computer. For example, if the server is configured as a certification authority (CA), ensure that clients can request and obtain certificates, download a certificate revocation list, and so on.

When you are confident in your policy configurations, you can use Scwcmd as shown in the following procedure to convert the policies to GPOs.

For more details about how to test SCW policies, see the Deployment Guide for the Security Configuration Wizard at https://technet2.microsoft.com/WindowsServer/en/Library/5254f8cd-143e-4559-a299-9c723b3669461033.mspx and the Security Configuration Wizard Documentation at https://go.microsoft.com/fwlink/?linkid=43450.

Convert and Deploy the Policy

After you thoroughly test the policy, complete the following steps to convert it into a GPO and deploy it:

1. At the command prompt, type the following command:

   scwcmd transform /p:<i><PathToPolicy.xml> </i>/g:<i><GPODisplayName></i>
   

   and then press ENTER. For example:Note: The line has been split into multiple lines for readability. However, while trying it out on a system you must enter it as one line without breaks.

   scwcmd transform /p:"C:\Windows\Security\msscw\Policies\
   IIS Server.xml" /g:"IIS Policy"
   

   Note: The information to be entered at the command prompt shows on more than one line here because of display limitations. This information should all be entered on one line.

2. Use the Group Policy Management Console to link the newly created GPO to the appropriate OU.

Note that if the SCW security policy file contains Windows Firewall settings, Windows Firewall must be active on the local computer for this procedure to complete successfully. To verify that Windows Firewall is active, open Control Panel and then double-click Windows Firewall.

You should now perform a final test to ensure that the GPO applies the desired settings. To complete this procedure, confirm that the appropriate settings were made and that functionality is not affected.

Summary

This chapter explained the policy settings that can be used to harden IIS servers that run Windows Server 2003 with SP1 in the three environments that are defined in this guide. Most of the settings are applied through a Group Policy object (GPO) that was designed to complement the MSBP. GPOs can be linked to the appropriate organizational units (OUs) that contain the IIS servers to provide additional security.

Some of the settings that were discussed cannot be applied through Group Policy. For these settings, manual configuration details were provided.

More Information

The following links provide additional information about topics that relate to hardening IIS–based Web servers that run Windows Server 2003 with SP1.

• For information about how to enable logging in IIS, see the Microsoft Knowledge Base article "How to enable logging in Internet Information Services (IIS)" at https://support.microsoft.com/?kbid=313437.
• Additional information about logging is available on the Enable Logging (IIS 6.0) page at www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/d29207e8-5274-4f4b-9a00-9433b73252d6.mspx.
• For information about how to log site activity, see the Logging Site Activity (IIS 6.0) page at www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/ab7e4070-e185-4110-b2b1-1bcac4b168e0.mspx.
• For information about extended logging, see the Customizing W3C Extended Logging (IIS 6.0) page at www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/96af216b-e2c0-428e-9880-95cbd85d90a1.mspx.
• For information about centralized binary logging, see the Centralized Binary Logging in IIS 6.0 (IIS 6.0) page on Microsoft.com at www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/b9cdc076-403d-463e-9a36-5a14811d34c7.mspx.
• For information about remote logging, see the Remote Logging (IIS 6.0) page at www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/a6347ae3-39d1-4434-97c9-5756e5862c61.mspx.
• For additional information about IIS 6.0, see the Internet Information Services page at www.microsoft.com/WindowsServer2003/iis/default.mspx.