Chapter 6: The Infrastructure Server Role
Published: December 31, 2003 | Updated: April 26, 2006 OverviewThis chapter explains the policy settings you can use to harden infrastructure servers that run Microsoft® Windows Server™ 2003 with Service Pack 1 (SP1) in the three environments that are defined in this guide. For the purposes of this guide, an infrastructure server is one that provides DHCP services or Microsoft WINS functionality. Most of the settings in this chapter are configured and applied through Group Policy. A Group Policy object (GPO) that complements the Member Server Baseline Policy (MSBP) can be linked to the appropriate organizational units (OUs) that contain the infrastructure servers to provide additional security for the servers. This chapter only discusses those policy settings that vary from the MSBP. Where possible, these policy settings are gathered in an incremental Group Policy object that will be applied to the Infrastructure Servers OU. Some of the settings in this chapter cannot be applied through Group Policy. Detailed information about how to configure these settings manually is provided. The following table shows the names of the infrastructure server security templates for the three environments that are defined in this guide. These templates provide the policy settings for the incremental Infrastructure Server template, which in turn is used to create a new GPO that is linked to the Infrastructure Servers OU in the appropriate environment. Step-by-step instructions are provided in Chapter 2, "Windows Server 2003 Hardening Mechanisms" to help you create the OUs and Group Policies and then import the appropriate security template into each GPO. Table 6.1 Infrastructure Server Security Templates and Policies
For information about policy settings in the MSBP, see Chapter 4, “The Member Server Baseline Policy.” For information on all default policy settings, see the companion guide, Threats and Countermeasures: Security Settings in Windows Server 2003 and Windows XP, which is available at https://go.microsoft.com/fwlink/?LinkId=15159. Audit Policy SettingsThe Audit policy settings for infrastructure servers in the three environments that are defined in this guide are configured through the MSBP. For more information about the MSBP, see Chapter 4, "The Member Server Baseline Policy." The MSBP settings turn on logging for the relevant security audit information on infrastructure servers. User Rights Assignment SettingsThe user rights assignments for infrastructure servers in the three environments that are defined in this guide are configured through the MSBP. For more information about the MSBP, see Chapter 4, "The Member Server Baseline Policy." The MSBP settings configure user rights assignments uniformly on all infrastructure servers. Security OptionsThe security options settings for infrastructure servers in the three environments that are defined in this guide are configured through the MSBP. For more information about the MSBP, see Chapter 4, "The Member Server Baseline Policy." The MSBP settings configure relevant security options settings uniformly on all infrastructure servers. Event Log SettingsThe event log settings for infrastructure servers in the three environments that are defined in this guide are configured through the MSBP. For more information about the MSBP, see Chapter 4, "The Member Server Baseline Policy." Additional Security SettingsThe security settings that the MSBP applies significantly enhance the security of infrastructure servers. This section discusses some additional settings for consideration. You cannot configure the settings in this section through Group Policy; you need to configure them manually on all infrastructure servers. Configure DHCP LoggingBy default, the DHCP service only logs startup and shutdown events in the event log. Complete the following steps to enable a more detailed log on the DHCP server:
When you complete these steps, the DHCP server creates a log file in the following location: %systemroot%\system32\dhcp\ DHCP client information is often difficult to locate in log files because the only information that is stored in most logs are computer names, not IP addresses. The DHCP audit logs provide an additional tool to help locate the sources of internal attacks or inadvertent activities. However, the information in these logs is not foolproof, because both host names and media access control (MAC) addresses can be forged or spoofed. (Spoofing makes a transmission appear to come from a user other than the user who performed the action.) However, the benefits that this information provides outweigh any costs that are incurred when logging is enabled on a DHCP server. It can be very helpful to have more than just an IP address and a computer name when you need to determine how a particular IP address was used on a network. By default, the Server Operators and Authenticated Users groups have read permissions to the DHCP log files. To best preserve the integrity of the information logged by a DHCP server, it is recommended that access to these logs be limited to server administrators. The Server Operators and Authenticated Users groups should be removed from the Access Control List (ACL) of the %systemroot%\system32\dhcp\ folder. In theory, the DHCP audit logs could fill the disk on which they are stored. However, the default configuration for the DHCP Audit Logging setting ensures that logging will stop if there is less than 20 MB of free disk space available on the server. This default configuration is adequate for servers in most environments, but you can modify it to ensure sufficient free disk space is available for other applications on a server. For information about how to modify this configuration, refer to the DhcpLogMinSpaceOnDisk page in the Windows Server 2003 Tech Center at https://technet2.microsoft.com/WindowsServer/en/Library/f7802dce-3ff9-406a-b3e6-c0c6b3ed49411033.mspx. Protect Against DHCP Denial of Service AttacksBecause DHCP servers are critical resources that provide client access to the network, they could be prime targets for a DoS attack. If a DHCP server is attacked and unable to service DHCP requests, DHCP clients will eventually be unable to acquire leases. Those clients will then lose their existing IP leases and the ability to access network resources. It would not be very difficult to write an attack tool script that requests all available addresses on a DHCP server. Such a script would exhaust the pool of available IP addresses for subsequent, legitimate requests from DHCP clients. It is also possible for a malicious user to configure all DHCP IP addresses on the network adapter of a computer they administer, which would cause the DHCP server to detect IP address conflicts for all addresses in its scope and to refuse to allocate DHCP leases. Also, as with all other network services, a DoS attack—for example, CPU exhaustion or filling the request buffer of the DHCP listener—that exhausts the DHCP server's ability to respond to legitimate traffic could make it impossible for clients to request leases and renewals. This type of problem can be avoided by proper design of DHCP services. You can configure DHCP servers in pairs and follow the best practice 80/20 rule—split DHCP server scopes between servers so that 80 percent of the addresses are distributed by one DHCP server and 20 percent by another—to help mitigate the impact of these types of attacks. These configuration suggestions help ensure that clients can continue to receive IP address configuration despite server failure. For more information about the 80/20 rule and the DHCP protocol, see the Dynamic Host Configuration Protocol page in the Windows 2000 Server Resource Kit at www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/cnet/cncb_dhc_klom.mspx. Note: The 80/20 Rule described in the Windows 2000 Server Resource Kit also applies to DHCP services in Windows Server 2003 with SP1. Securing Well-Known AccountsWindows Server 2003 with SP1 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 infrastructure servers
Note: The built-in Administrator account can be renamed through Group Policy. This policy 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 all three environments that are defined in this guide. This policy setting is a part of the Security Options settings of a GPO. Securing Service AccountsNever 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 SCWTo 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 policy 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 install the operating system 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. During the server policy creation steps you will probably remove the File server role from the list of detected roles. This role is commonly configured on servers that do not require it and could be considered a security risk. To enable the File server role for servers that require it, you can apply a second policy later in this process. To create the infrastructure server policy
Test the Policy Using SCWAfter 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 PolicyAfter you thoroughly test the policy, complete the following steps to convert it into a GPO and deploy it:
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 policy settings. To complete this procedure, confirm that the appropriate policy settings were made and that functionality is not affected. SummaryThis chapter explained the policy settings that can be used for DHCP and WINS servers that run Windows Server 2003 with SP1 in the three environments that are defined in this guide. Most of the settings for these roles are applied through the MSBP. The primary goal of creating an Infrastructure Policy object for the DHCP and WINS servers is to enable the necessary services for these roles to fully function and keep them well secured. Although the MSBP provides a great level of security, this chapter also discussed other considerations for the infrastructure server roles. Primarily, these considerations included the generation of log files. More InformationThe following links provide additional information about topics that relate to hardening infrastructure servers that run Windows Server 2003 with SP1.
|
|
.jpg)