لطفا منتظر باشید ...
Securing Server Clusters
Security considerations must be present in all aspects of your cluster design. After your clustering infrastructure is in place, you need to consider a number of recommended policies and configurations to ensure that your server clusters are secure. Figure 7.24 shows an overview of security deployment considerations.
Figure 7.24: Securing Your Server Clusters
Before beginning your security design, see "Best practices for securing server clusters" in Help and Support Center for Windows Server 2003.
| Note | Do not weaken the default security settings for clustering objects in the operating system. This includes registry keys, files, and devices. |
Ensuring the Physical Security of Server Clusters
For servers that must maintain high availability, it is recommended that you restrict physical access to a small number of essential, designated individuals. Locate server clusters and their storage in physically secure locations.When you review your policies for keeping your computer room secure, be sure to include the following:
Restrict access to the instruction sheets that you create, such as the directions for server recovery.
Review your administration practices to ensure that only trusted, authorized personnel have access to restricted data, such as logs and backup and restore media.
Ensuring a Secure Networking Infrastructure
Standard security devices — such as firewalls, network probes, and management tools to detect irregular traffic — must be in place before you put sensitive data on server clusters (or any other servers).
| Note | Although you can use IP security (IPSec) with server clusters, IPSec was not designed for use in failover situations. You can, however, use IPSec if your business need for secure connectivity outweighs your need for continuous client access during failover. For more information about IPSec and clusters, see article Q306677, "IPSec Is Not Designed for Failover," in the Microsoft Knowledge Base. To find this article, click the Microsoft Knowledge Base link on the Web Resources page at http://www.mmicrosoft.com/windows/reskits/webresources. |
In order to create a secure environment for your server clusters, begin with the following basic network precautions:
Secure your network with firewalls and management tools that can detect irregular network traffic.
Restrict physical access to network hardware (routers, hubs, and switches) to protect them from unauthorized individuals.
Make sure administrative permissions are adhered to, and that logs and other resources are protected by access control lists (ACLs).
Ensure that network services such as the Active Directory, DNS, and DHCP, and Windows Internet Name Service (WINS) are protected from compromise. Any compromise of these infrastructure services can lead to a compromise of the Cluster service itself.
Protecting Server Clusters from Network Flooding
The Cluster service uses User Data Protocol (UDP) port 3343 for intracluster communication. This communication includes heartbeat traffic, which detects node failure, and cluster control operations. Some of this communication (such as heartbeats) is time sensitive. If there is a significant load on the ports due to network flood attacks, the result can be false node-failure detection, which can cause unnecessary failover operations, leading to application downtime. To ensure that node-failure detection cannot be compromised in this way, secure the private network or networks between cluster nodes so that only trusted nodes can send data.
Protecting Server Clusters from Unauthorized Access
The Cluster service provides remote management capabilities through the Cluster API so that you can manage the cluster from a management workstation. If you are administrating clusters remotely, be sure to use only trusted computers. The Cluster API uses the NTLM authentication protocol to authenticate the administrator on the cluster. This allows the cluster to verify that the administrator has sufficient administrative credentials to manage the cluster; however, it does not provide mutual authentication. In other words, the client has no guarantee that the node or cluster it is connected to is the real cluster.If an unauthorized computer appears on the network with the same IP address or network name assigned to the cluster (assuming DNS information was compromised), the unauthorized computer can masquerade as the cluster. If that unauthorized computer also appears to implement the Cluster API, the unauthorized computer can intercept any management commands sent to the cluster. In many cases, this might not represent a threat because the administrator simply receives a false positive or negative that an action was performed. However, there are some sensitive operations (such as changing the cluster configuration) during which an unauthorized recipient could potentially collect cluster configuration data that might help to extend the attack surface.This type of masquerade attack cannot occur until a number of conditions are met:
The unauthorized computer must be visible on the same subnet as the target cluster and respond to traffic to the cluster IP address (this can be the IP address of the physical computers or the IP address of virtual servers hosted by the computer).
In a typical environment, the unauthorized computer can take over the IP address only if the cluster node or virtual server is not running.
The unauthorized computer must appear to implement the Cluster API.
The administrator or an operational procedure must change the configuration that includes the sensitive data (for example, the administrator must change the Cluster service account password).
To protect against such attacks, the subnets on which the server clusters reside must be protected in the following ways:
The subnet used by the cluster nodes must not extend beyond the set of nodes that can be physically secured or trusted. You must ensure that unauthorized or potentially compromised computers cannot attach to the subnet that contains the clusters. Because this network typically contains domain controllers, DNS servers, WINS servers, DHCP servers, and other network infrastructure, you must take steps to ensure that these infrastructure servers are also secure.
Make sure that only nodes in the cluster are visible on a private network (multiple clusters can use the same private network). Make sure that no other network infrastructure servers or other application servers exist on the private subnet. This can be achieved by physically constraining the network itself (for example, ensuring that the private network is a LAN that is only connected to the cluster nodes), or by isolating the private networks by using VLAN-capable switches.
Protecting the Cluster Disks
Windows Clustering supports only NTFS on cluster disks. This ensures that file protection can be used to safeguard data on the cluster disks. Because the cluster disks can fail over between nodes, you must use only domain user accounts (or Local System, Network Service, or Local Service) to protect files. Local user accounts on one computer have no meaning on other computers in the cluster.Cluster disks are periodically checked for health. The Cluster service account must have Write access to the top-level directory of all cluster disks. If the Cluster service account does not have Write access, the disk might be mistakenly declared as failed.
Evaluating Upgrade Risks
On the Microsoft Windows 2000 Server and Microsoft Windows NT version 4.0 operating systems, the default security attributes of the cluster log files in the windir\Cluster directory and the default security attributes of the quorum directory allow any authenticated user to read the contents. The security of these directories has been tightened in Windows Server 2003 to stop nonadministrator access altogether, ensuring that unauthorized users cannot gain information about the cluster configuration. However, these security attributes are not modified when you upgrade to Windows Server 2003, so on an upgraded Windows Server 2003 cluster node, all authenticated users might have Read access to these directories. Be sure to manually set the permissions to conform to the minimum access requirements.
| Note | Be aware that if you install any service packs in the future, the service packs might reset permissions that have been configured manually. |
Protecting the Quorum Disk
Never store other application data on the quorum disk. The quorum disk should contain only quorum data.The quorum disk health determines the health of the entire cluster. If the quorum disk fails, the Cluster service becomes unavailable on all cluster nodes. The Cluster service checks the health of the quorum disk and negotiates for exclusive access to the physical drive by using standard I/O operations. These operations are queued to the device along with any other I/O operations to that device. If extremely heavy traffic delays the Cluster service I/O operations, the Cluster service declares the quorum disk as failed and forces a regroup event to bring the quorum back online somewhere else in the cluster.To protect against malicious applications that could fill up the quorum disk, or flood the quorum disk with I/O operations, restrict access to the quorum disk to the local Administrators group on the local computer and the Cluster service account. If the quorum disk fills up, the Cluster service might be unable to log required data. In this case, the Cluster service fails, potentially on all cluster nodes.
Protecting the Server Cluster Data Disks
As it does with the quorum disk, the Cluster service periodically checks the health of the cluster data disks. If malicious applications flood the cluster data disks with I/O operations, the Cluster service health check can fail, thereby causing the disk (and any applications that depend on the disk) to fail over to another cluster node, which can result in a denial-of-service attack. To avoid this possibility, restrict access to the cluster data disks to only those applications that store data on the specific disks.
Creating Secure Administrative Policies for Server Clusters
To provide adequate and manageable security for sever clusters, you need to implement appropriate administrative practices and policies. The most important secure administrative policy is to permit only trusted, specially designated workstations to access the Cluster service. Any compromise on computers used to administer the cluster can compromise the cluster. For example, if a workstation from which administrative tools are run can be accessed by unauthorized users, these users can run unreliable or malicious code on the cluster without the knowledge of the cluster administrator. For this reason, it is important to audit both administrative access to the server cluster and changes to the Cluster service account.The following sections describe best practices for securely administrating a server cluster.
| Note | To change the password of the Cluster service account without taking any nodes offline, it is essential that each node in the cluster have the same Cluster service account. |
Verifying Permissions for the Cluster Service Account
The nodes in a server cluster use authenticated communication mechanisms to ensure that only valid members of the cluster can participate in intra-cluster protocols. Authentication of the communication is based on the Cluster service account. The Cluster service creates and maintains files, devices, registry keys, and other objects in the operating system. The default security setting of these objects ensures that unauthorized users cannot impact the cluster configuration or the applications running on the cluster. Making these security settings less restrictive can lead to the cluster being compromised and application data being corrupted.For the server cluster to function properly, the Cluster service account must have certain permissions associated with it. During cluster installation, some of these rights are granted directly to the Cluster service account while others are inherited when the Cluster service account is made a member of the local Administrators group. The Cluster service account must have rights that allow it to perform the following actions:
Act as part of the operating system.
Back up files and directories.
Adjust memory quotas for a process.
Increase scheduling priority.
Log on as a service.
Restore files and directories.
Debug programs.
Manage auditing and security logs.
Impersonate a client after authentication.
In Windows Server 2003, the Cluster service can publish virtual servers as computer objects in Active Directory. To ensure correct operation, the Cluster service account needs appropriate permissions to manipulate these objects in the Active Directory Computers container.
| Note | Although the Network Name resource publishes a computer object in Active Directory, that computer object must not be used for administrative tasks such as applying Group Policy settings. The only roles for the virtual server computer object are to support Kerberos authentication, and for cluster-aware services that can use Active Directory (such as Message Queuing) to publish service provider information. |
Administering Clusters
Cluster administrators can grant permissions to groups or individuals to manage the cluster. There is no fine granularity of control: Either a user has credentials to administer the cluster, or the user does not. Because of the high degree of impact administrators can have on your system's security, granting administrative credentials to a user must be done with careful consideration.The security descriptor for the Cluster service contains the accounts that are authorized to administrate the cluster. By default, a cluster node's local Administrators group is added to the Cluster service security descriptor. The service accounts LocalSystem and NetworkService are also added to the security descriptor. The local Administrators group and the two accounts cannot be removed from the security descriptor. Be aware that adding a domain user or global group to the local Administrators group gives cluster administrator permissions to that group or account. If a node is evicted from a cluster, or if the last node is removed, the Cluster service account is not removed from the local Administrators group. When you remove a node from the cluster, you must manually remove the Cluster service account from the local Administrators group.Cluster administrators can manage all aspects of the cluster configuration, including:
Taking resources offline and bringing resources online.
Adding and removing nodes from the cluster.
Adding and removing resources from the cluster.
In addition, cluster administrators are able to shut down the Cluster service on nodes, provided they are also member of the local Administrators group. Apart from the local Administrators group on a node, all other members of the cluster security descriptor must be either domain user accounts, built-in local accounts such as System or NetworkService, or global groups. This ensures that the account is an identical, well-defined, and authorized account on all nodes in the cluster.The Cluster service account does not need to be a member of the Domain Admins group, because the Cluster service account does not need domain administrator permissions. As a general security guideline, give all accounts the minimal possible permissions.If you are deploying multiple clusters in a single domain, you can make administration easier by using the same Cluster service account on all nodes. However, you must balance ease of management against the potential security risks associated with using a single account for many clusters. If the account is compromised, the scope of the impact might exceed the benefits you gain by increasing the ease of management. With Windows Server 2003, the Cluster service account password on multiple clusters can be changed at the same time, as long as every node in the cluster is using the same Cluster service account.
Cluster administrators and the Cluster service need to use different accounts to administer the cluster. This allows finer granularity of auditing and allows policy settings (such as password expiration) to be applied to the Cluster service account and the accounts used to administer the cluster.If you plan to deploy multiple clusters that have different Cluster service accounts, create a global group or universal group that implements all the policy settings described earlier in this section. Then place each Cluster service account into the group. This eases management of the Cluster service accounts by providing a single container for all Cluster service accounts, and a single point of management for changing account policy settings. For example, you could put all cluster nodes and the Cluster service accounts into a single organizational unit (OU) in Active Directory.Your OU model depends on your Active Directory implementation. If your Windows Server 2003 clusters reside in a Windows NT 4.0 domain, OUs and universal groups are not available.Follow these guidelines for ease of use and best security:
If there are multiple clusters in a single domain, use the same Cluster service account on all nodes to make administration easier.
If you have password expiration policy settings on your Cluster service account, do not use this account for other services.
Do not use the Cluster service account for SQL Server or Exchange 2000 if you have password expiration policy settings. When multiple services use the same account, coordinating the password change across the Cluster service and other services is complex and can cause the entire cluster or service to become unavailable during a password rotation. It is recommended that you use a dedicated account, which can be maintained independently, for each service.
With Windows Server 2003, the Cluster service account password can be changed online without taking down the cluster, but only if the Cluster service account is not used by other services.
| Caution | Be sure to change the Cluster service account password before it expires. The cluster will stop functioning when the password expires, because intra-cluster communication can no longer be successfully authenticated. |
Applying Kerberos Authentication in a Clustered Environment
Carefully plan your use of Kerberos authentication in a server cluster. By default, Kerberos authentication support for the network name resource is turned off. When Kerberos authentication support is enabled, the Cluster service account must be able to create a virtual computer object in Active Directory.By default, all users have Add workstations to the domain permissions, which allows the creation of computer objects in Active Directory.
| Note | By default, authenticated users can join up to ten machine accounts to the domain. This limit does not apply to members of the Administrators or Domain Admins groups, and to those users who have delegated permissions on containers in Active Directory to create and delete computer accounts. |
If the Add workstations to the domain permission has been removed from the Cluster service account, before enabling Kerberos authentication, a member of the Domain Administrators group must perform one of the following actions:
Grant the Cluster service account the Create Computer Objects permission on the Computers organizational unit in Active Directory.
Create the computer object manually in Active Directory before enabling Kerberos authentication. If the object is manually created, the Cluster service account must have Write all properties access permission to allow it to manipulate the computer object.
| Caution | Although the Network Name resource supports the changing of its Name property, many services, such as Message Queuing and Microsoft SQL Server™ 2000, do not support changing the Network Name resource Name property. Do not change this property unless you fully understand the implications of doing so. In some cases, changing the Network Name resource Name property can lead to loss of data or service failure. |
Before you allow clients to access a server cluster, or before failing over the resources to another node, ensure that the domain controllers have replicated newly created computer objects associated with Network Name resources. Until replication is complete, clients might fail to authenticate, or they could authenticate with the default NTLM authentication protocol and not with Kerberos authentication. One way to avoid replication issues with your clients is to not notify clients that the service is available until you are sure replication is complete. The amount of time it takes your directory to replicate information depends on many factors, such as the topology and the amount of network traffic. If you are not sure of the time necessary to allow for replication, replication can be forced with tools such as Ntdsutil.exe. For more information about Ntdsutil.exe, see "Using Ntdsutil" in Help and Support Center for Windows Server 2003.After you enable Kerberos authentication on a server cluster, do not disable Kerberos authentication on a virtual server without knowing the effects the disabling will have on other services that use that virtual server. Microsoft Message Queuing (MSMQ), for example, relies on the presence of a virtual computer object and ceases to function if its dependent Network Name resource has Kerberos authentication support disabled.Use extreme care when you remove Kerberos authentication from a Network Name resource. When you disable Kerberos authentication from a Network Name resource, the computer object is disabled, leaving the system administrator with an explicit decision to delete the computer object. If the object remains in Active Directory, the Network Name resource does not go online. If the computer object is deleted, properties attached by applications that can use Active Directory are also deleted, and the applications might no longer function correctly.For more information about enabling Kerberos authentication on a virtual server, see "Enable Kerberos authentication for virtual servers" in Help and Support Center for Windows Server 2003, or see articles Q302389, "Description of the Properties of the Cluster Network Name Resource in Windows Server 2003," and Q307532, "How to Troubleshoot the Cluster Service Account When It Modifies Computer Objects," in the Microsoft Knowledge Base. To find these articles, see the Microsoft Knowledge Base link on the Web Resources page at http://www.microsoft.com/windows/reskits/webresources.
