Partilhar via

Best practices for securing server clusters

  • Artigo

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

Best practices for securing server clusters

Use the following guidelines to help keep your server cluster from being adversely affected by denial of service attacks, data tampering, and other malicious attacks:

Apply the latest software updates.

Apply the latest software updates, including security updates and service packs. Windows Server 2003 Service Pack 1 (SP1) contains a large number of improvements to security. We highly recommend that the version of Windows Server 2003 that you run is no earlier than Windows Server 2003 with SP1.

Obtain the latest information about security.

Review the Microsoft Web site from time to time for information about security. For example, review one or more of the following:

Only allow authorized personnel to have physical access to the server cluster nodes and related infrastructure components (for example, the network and storage components). For more information about standard best practices for securing servers, see Best practices for security.

Secure your cluster networks.

For public or mixed networks: Ensure that all servers (for example, infrastructure servers such as DNS or WINS servers) that are attached to the cluster subnet (or any other subnet) are secure and trusted. Also, use a firewall to protect your cluster from unauthorized client access.

For private networks: Physically disjoint the private network(s) from other networks. Specifically, do not use a router, switch, or bridge to join a private cluster network to any other network. Do not include other network infrastructure or application servers on the private network subnet.

If heartbeat messages that are carried by private or mixed networks are disrupted (for example, by unauthorized users flooding the cluster networks), the cluster's reaction to these false failures may affect not only groups with IP address resources, but also the health of the cluster nodes. Repeated failover of critical cluster resources (for example, resources associated with Microsoft Exchange Server) may cause clients to lose access to the cluster.

If you use Windows Firewall, use the Security Configuration Wizard to configure it.

The Security Configuration Wizard simplifies the process of configuring Windows Firewall for cluster nodes. For more information, see Using Windows Firewall with a server cluster.

Administer cluster nodes remotely only from trusted, secure computers.

If the remote computers are compromised, untrustworthy or malicious code can be started unknowingly by the cluster administration tools and adversely affect the cluster itself.

Make the Cluster service account a member of the local Administrators group on all nodes, but do not make it a member of the domain administrator group.

By giving the minimal possible administration rights and permissions to the Cluster service account, you avoid potential security issues if that account is compromised. For more information about the administration rights and permissions required by the Cluster service account, see Change the account under which the Cluster service runs.

Take steps to protect the Cluster service account, and do not use the Cluster service account to administer the cluster.

The Cluster service account has elevated administration rights and permissions. Limit the use of the account, restrict the number of people who know the account name and password, and from time to time, change the password.

For more information about using another user account to administer a cluster, see Give a user permissions to administer a cluster.

For detailed information about the rights and permissions required for the Cluster service account, see Change the account under which the Cluster service runs.

For information about changing the password of the Cluster service account, which you can do without any downtime, see Change the Cluster service account password.

Use different accounts for the Cluster service and applications in the cluster.

This will limit exposure to the application and not the cluster account if an application account is compromised. In addition, if you use cluster.exe to change the password for the Cluster service account and one or more applications also use that account, your cluster applications may not function correctly. For more information, see Change the Cluster service account password.

Use different Cluster service accounts for multiple clusters.

This will limit exposure to one cluster only if a Cluster service account is compromised.

Remove the Cluster service account after evicting all the nodes in your cluster.

The cluster administration tools will not automatically delete the Cluster service account when all nodes have been evicted from the cluster. The Cluster service account has a high level of administration rights and permissions, and that can present potential security issues if it is compromised; it is highly recommended that you remove this account from the local Administrators group if you no longer have use for it. However, because the administrative rights and permissions for the Cluster service account are granted locally on each cluster node and not domain wide, the impact of a compromised account is limited to just the cluster nodes. For more information about deleting user accounts, see Delete a local user account.

For clusters in an Active Directory domain, enable Kerberos authentication for Network Name resources.

Kerberos authentication is much more secure than the alternative, NTLM authentication. Note that when you enable Kerberos authentication, you must add certain rights and permissions to the account that the Cluster service creates for the Network Name resource, and possibly to the Cluster service account itself. For more information, see Knowledge Base article 307532, "How to troubleshoot the Cluster service account when it modifies computer objects," on the Microsoft Support Web site (https://go.microsoft.com/fwlink/?LinkId=59994).

To ensure that only trusted personnel have user rights and permissions to administer the cluster and to track additions of unauthorized user accounts, audit changes to the local Administrators group. Note that, by default, when you create a server cluster or add nodes, the Cluster service account is added to the local Administrators group on each node. For more information about auditing security events, see Auditing Security Events.

Limit and audit access to shared data (for example, files and folders on cluster disks).

If you want to audit access to shared data, enable auditing on all cluster nodes. For more information, see Securing shared data in a cluster.

Limit client access to cluster resources.

Use Windows Server 2003 family security features to control client access to cluster resources as described in Limiting client access to cluster resources. Note that when you create user and group accounts through which you control access to cluster resources, you must use domain-level accounts, not local accounts, so that appropriate access is available regardless of which node currently owns a clustered resource.

Limit access to the quorum disk and ensure that the quorum disk always has sufficient free space.

To help reduce the risk of unauthorized reads and writes to the quorum disk, it is highly recommended that you give access to the quorum disk only to the Cluster service account and members of the local Administrators group. For the Cluster service to start and continue to write to the quorum log, the quorum disk must have sufficient free space. It is recommended that the quorum disk be at least 500 megabytes (MB) in size. For more information, see Checklist: Planning and creating a server cluster and Disk resource security.

Ensure that all applications running in the cluster are from a trusted source and that access to the cluster disks is restricted only to applications that are managed as a cluster resource.

For more information, see Disk resource security.

Secure script files called by Generic Script resources.

Use NTFS file-level security for execute permissions on script files and permissions for APIs called in those scripts. For more information, see Limiting client access to cluster resources.

Ensure that applications called by Generic Application resources are from a trusted source and that files, registry checkpoints, and other resources needed for those applications are in a secure location.

Applications launched as a Generic Application resource will run under the context of the Cluster service account, with its elevated administration rights and permissions. Therefore, ensure that such applications are from a trusted source. In addition, we recommend that in Cluster Administrator, when configuring the parameters for a Generic Application resource, you do not select Allow application to interact with desktop unless it is necessary. For more information, see Limiting client access to cluster resources.

Secure the cluster configuration log files created when remotely administering a cluster.

After using the New Server Cluster Wizard and the Add Nodes Wizard from a remote computer, the cluster configuration log file generated by those wizards is saved to the remote computer (at %systemroot%\system32\LogFiles\Cluster\ClCfgSrv.log). This log file contains important information about the cluster. Restrict access to that file to cluster administrators and the Cluster service account. For more information, see Set, view, change, or remove permissions on files and folders.

Note

If you do not have administrative rights and permissions on the node on which you are using the New Server Cluster Wizard or Add Nodes Wizard, the log file will be written to the local %Temp% directory.

Do not copy files to the local cluster directories in a majority node set cluster.

When using the majority node set model, each node maintains a copy of the quorum database in the cluster directories located at %systemroot%\Cluster\MNS.%ResourceGUID%$\%ResourceGUID%$\MSCS. If you put files in the directories below the \Cluster directory, and then delete the Majority Node Set resource, those files will be deleted by the Cluster service.

Do not change the default security settings on the HKEY_LOCAL_MACHINE system registry subtree.

By default, only members of the Administrators group in the Builtin folder and the local system account have Full Control of the HKEY_LOCAL_MACHINE system registry subtree. If this registry subtree is compromised, some resources (for example, the Generic Script resource) may fail to start. For more information about securing the system registry, see Maintain Registry Security.

For more information about security in a server cluster, see Managing Security in a Cluster.