Chapter 1: Implementing a Security Baseline
Published: February 27, 2008
Windows Server® 2008 is the most secure operating system that Microsoft has produced to date. However, every organization needs to consider what level of security and functionality is required. Therefore, you may need to make specific configuration changes to meet the requirements of your environment. This chapter demonstrates how relatively easy it is to configure security settings to harden computers that perform different server roles. Each server is running Windows Server 2008 in the default configuration and is joined to a domain using Active Directory® Domain Services (AD DS). You can now harden the default operating system using only Group Policy objects (GPOs). Previous guidance from Microsoft required importing Security Template .inf files and extensive manual modification of the Administrative Templates portion of several GPOs. Working with these files and templates is no longer necessary. However, the Security Template .inf files are included with the GPOAccelerator tool so that you can use them to harden stand-alone servers. A "stand-alone" server is not a member of an AD DS domain. All of the recommended Group Policy settings are documented in Appendix A, "Security Group Policy Settings." To deploy this guidance, you need to:
Caution It is essential to thoroughly test your OU and GPO designs before deploying them in a production environment. For procedural details about how to accomplish this, see How to Use the GPOAccelerator. Use this guidance to create and deploy the OU structure and security GPOs during both the test and production phases of the implementation. The security baseline GPOs for this guide provide a combination of tested settings that enhance security for computers running Windows Server 2008 in the following two distinct environments:
Enterprise Client EnvironmentThe Enterprise Client (EC) environment referred to in this chapter consists of a domain using AD DS in which computers running Windows Server 2008 with Active Directory manage client computers that can run either Windows Vista® or Windows XP® with Service Pack 2 (SP2) or later, and member servers running Windows Server 2008 or Windows Server 2003 with SP2 or later. The client computers and member servers are managed in this environment through Group Policy, which is applied to sites, domains, and OUs. Group Policy provides a centralized infrastructure within AD DS that enables directory-based change and configuration management of user and computer settings, including security and user data. Note The Enterprise Client (EC) security baseline this guide prescribes helps to provide enhanced security that allows sufficient functionality of the operating system and applications for the majority of organizations. Specialized Security – Limited Functionality EnvironmentThe Specialized Security – Limited Functionality (SSLF) environment referred to in this chapter consists of a domain using AD DS in which computers running Windows Server 2008 with Active Directory manage client computers that can run either Windows Vista® or Windows XP® with Service Pack 2 (SP2) or later, and member servers running Windows Server 2008. The Specialized Security – Limited Functionality (SSLF) baseline for this guide addresses the demand to help create highly secure environments for computers running Windows Server 2008. Concern for security is so great in these environments that a significant loss of functionality and manageability is acceptable. These setting recommendations have been developed in cooperation with several government agencies from around the world. Caution The SSLF security settings are not intended for the majority of enterprise organizations. The configuration for these settings has been developed for organizations where security is more important than functionality. If you decide to test and deploy the SSLF configuration settings to servers in your environment, the IT resources in your organization may experience an increase in help desk calls related to the limited functionality that the settings impose. Although the configuration for this environment provides a higher level of security for data and the network, it also prevents some services from running that your organization may require. Examples of this include Terminal Services, which allows users to connect interactively to desktops and applications on remote servers. It is important to note that the SSLF baseline is not an addition to the EC baseline: the SSLF baseline provides a distinctly different level of security. For this reason, do not attempt to apply the SSLF baseline and the EC baseline to the same computers. Rather, for the purposes of this guide, it is imperative to first identify the level of security that your environment requires, and then decide to apply either the EC baseline or the SSLF baseline. To compare the setting differences between the EC baseline and the SSLF baseline, see Appendix A, "Security Group Policy Settings." The Windows Server 2008 Security Guide Settings workbook that also accompanies this guide provides another resource that you can use to compare setting values. Important If you are considering whether to use the SSLF baseline for your environment, be prepared to exhaustively test the computers in your environment after you apply the SSLF security settings to ensure that they do not prohibit required functionality for the computers in your environment. Specialized SecurityOrganizations that use computers and networks, especially if they connect to external resources such as the Internet, must address security issues in system and network design, and how they configure and deploy their computers. Capabilities that include process automation, remote management, remote access, availability 24 hours a day, worldwide access, and software device independence enable businesses to become more streamlined and productive in a competitive marketplace. However, these capabilities also expose the computers of these organizations to potential compromise. In general, administrators take reasonable care to prevent unauthorized access to data, service disruption, and computer misuse. Some specialized organizations, such as those in the military, government, and finance are required to protect some or all of the services, systems, and data that they use with a specialized security level. The SSLF baseline is designed to provide this level of security for these organizations. To preview the SSLF settings, see Appendix A, "Security Group Policy Settings." Limited FunctionalityThe specialized security the SSLF baseline implements may reduce functionality in your environment. This is because the SSLF baseline limits users to only the specific functions that they require to complete necessary tasks. Access is limited to approved applications, services, and infrastructure environments. There is a reduction in configuration functionality because the baseline disables many property pages with which users may be familiar. The following sections in this chapter describe the areas of higher security and limited functionality that the SSLF baseline enforces:
Restricted Services and Data AccessSpecific settings in the SSLF baseline can prevent valid users from accessing services and data by requiring strong passwords that users can more easily forget or misspell. In addition, these settings may lead to an increase in help desk calls. However, the security benefits that the settings provide help make it harder for malicious users to attack computers running Windows Server 2008 in this environment. Setting options in the SSLF baseline that could potentially prevent users from accessing services and data include those that:
Note Setting details for both the EC and the SSLF baselines are available in Appendix A, "Security Group Policy Settings." The Windows Server 2008 Security Guide Settings workbook that also accompanies this guide provides another resource that you can use to compare setting values. Group Policy can either restrict or enforce the default setting values of many user rights and security options. This can cause some applications that require specific user rights on a computer to not function properly. For this reason, it is important to closely review user right and security option setting requirements for applications that are outside the realm of those that are installed for different server roles. These can include but are not limited to applications developed specifically for your environment or tools used to perform diagnostics or updates for your computers. Restricted Network AccessNetwork reliability and system connectivity is paramount for successful business. Microsoft operating systems provide advanced networking capabilities that help to connect systems, maintain connectivity, and repair broken connections. Although this capability is beneficial to maintaining network connectivity, attackers can use it to disrupt or compromise the computers on your network. Administrators generally welcome features that help to support network communications. However, in special cases, the primary concern is the security of data and services. In such specialized environments, some loss of connectivity is tolerated to help ensure data protection. Setting options in the SSLF baseline that increase network security but could potentially prevent users from network access include those that:
Strong Network ProtectionA common strategy to attack network services is to use a denial of service (DoS) attack. Such an attack prevents connectivity to data or services or over-extends system resources and degrades performance. The SSLF baseline provides additional protections to system objects and the assignment of resources to help guard against this type of attack. Setting options in the SSLF baseline that help to prevent DoS attacks include those that control:
All of these security considerations contribute to the possibility that the security settings in the SSLF baseline may prevent applications in your environment from running or users from accessing services and data as expected. For these reasons, it is important to extensively test the SSLF baseline after you implement it and before you deploy it in a production environment. Security DesignThe security design that this chapter recommends forms the starting point for the scenarios in this guide, as well as the mitigation suggestions for the scenarios. The remaining sections in this chapter provides design details about the core security structure for the guide:
OU Design for Security PoliciesAn OU is a container within an AD DS domain. An OU may contain users, groups, computers, and other OUs. If an OU contains other OUs, it is called a parent OU, and an OU within a parent OU is called a child OU. You can link a GPO to an OU, which will then apply the GPO's settings to the users and computers that are contained in that OU and its child OUs. And to facilitate administration, you can delegate administrative authority for each OU to specific administrators or groups. OUs provide an effective way to segment administrative boundaries for users and computers. Microsoft recommends that organizations assign users and computers to separate OUs, because some settings only apply to users and other settings only apply to computers. You can delegate control over an individual OU by using the Delegation Wizard in the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in tool. See the "More Information" section at the end of this chapter for links to documentation about how to delegate authority. One of the primary goals of an OU design for any environment is to provide a foundation for a Group Policy implementation that can apply to all computers in the AD DS domain. This helps ensure that the computers meet the security standards set by your organization. The OU design must also provide an adequate structure to accommodate security settings for specific types of server roles, role services, and users in an organization. For example, developers may require access to their computers that average users do not. The following figure illustrates a simple OU structure that is sufficient for the Group Policy discussion in this chapter. The OU structure may differ from the requirements for your organization's environment.
Figure 1.1. Example OU structure for computers running Windows Server 2008 Domain RootYou should apply some security settings throughout the domain to control how the domain, as a whole, is configured. These settings are contained in GPOs that apply to the domain. Computers and Users are not managed in this container. Domain Controllers OUDomain controllers hold some of the most sensitive data in your organization — data that controls the security configuration itself. You apply GPOs at this level in the OU structure to configure and protect the domain controllers. Member Servers OUThis OU contains child OUs as described below. You should include settings that apply to all servers, but not to workstations, in the GPOs that you apply to this OU. Server Role OUsMicrosoft recommends creating an OU for each server role that your organization uses. Each OU should contain only one type of server computer. You can then configure GPO settings and apply them to OUs that are specific to each role. You can also choose to combine certain roles on the same server, if your organization requires it. For example, you may choose to combine the File and Print server roles. In this case, you can create an OU for these combined server roles called "File and Print Server," and then link the two role-specific GPO policies to that OU. Important Combining server roles on the same computer requires careful planning and testing to ensure that you do not negatively affect the overall security of the server roles that you combine. GPO Design for Security PoliciesA GPO is a collection of Group Policy settings. GPOs are stored at the domain level and affect users and computers contained in sites, domains, and OUs. You can use GPOs to ensure that specific policy settings, user rights, and computer behavior apply to computers or users in an OU. Using Group Policy instead of a manual configuration process makes it simple to manage and update changes for many computers and users. Manual configuration is not only inefficient, because it requires a technician to visit each workstation, but it is also potentially ineffective. This is primarily because if the policy settings in domain-based GPOs are different than those applied locally, the domain-based GPO policy settings will overwrite the locally applied policy settings.
Figure 1.2. GPO order of precedence The previous figure shows the order of precedence in which GPOs are applied to a computer that is a member of the Child OU, from the lowest priority (1) to the highest priority (5). Group Policy is applied first from the local security policy of each workstation. After the local security policy is applied, GPOs are next applied at the site level, and then at the domain level. For computers running Windows Server 2008, Windows Server 2003 SP2 or later, and Windows Vista or Windows XP with SP2 or later that are nested in several OU layers, GPOs are applied in order from the parent OU level in the hierarchy to the lowest child OU level. The final GPO is applied from the OU that contains the computer account. This order of GPO processing for Group Policy—local security policy, site, domain, parent OU, and child OU—is significant because settings in GPOs that are applied later in the process will overwrite settings applied earlier. Different values for the same setting configured in different GPOs are never combined. User GPOs are applied in the same manner. The following considerations apply when you design Group Policy:
Recommended GPOsTo implement the OU design described above requires a minimum of the following GPOs:
Note Additional GPOs are required to implement security for client computers and users in your organization. For more information, see the Windows Vista Security Guide. The following figure expands on the preliminary OU structure to show the linkage between these GPOs and the OU design.
Figure 1.3. Example OU structure and GPO links for computers running Windows Server 2008 In the example in Figure 1.3, a File server is a member of the File Server OU. The first policy that is applied to the server is the local security policy. However, in general, little if any configuration of the servers is done by local policy. Security policies and settings should always be enforced by Group Policy. Because there is only one File server in this example, no GPOs are applied at this level, which leaves the Domain GPO as the next policy that is applied to the servers. The Windows Server 2008 EC Baseline Policy is then applied to the Member Servers OU. Finally, any specific polices for the Web servers in the environment are applied to the Web Server OU. As a precedence example, consider a scenario in which the policy setting for Allow logon through Terminal Services is set to apply to the following OUs and user groups:
In this example, logon through Terminal Services has been restricted to the Administrators group for servers in the Member Servers OU. However, a user whose account is in the Remote Desktop Users group can log on to a File server through Terminal Services because the File Servers OU is a child of the Member Servers OU and the child policy takes precedence. If you enable the Enforced policy option in the GPO for the Member Servers OU, only users with accounts in the Administrators group can log on to the File server computer through Terminal Services. This is because the Enforced option prevents the child OU policy from overwriting the policy applied earlier in the process. More InformationThe following resources provide additional information about Windows Server 2008 security-related topics on Microsoft.com:
|
|
.gif)
.gif)
.gif)
.jpg)