Protecting XenServer Hosts

Isolating Sensitive VMs

When designing your virtual environment and determining what servers will host what workloads, consider which virtual machines are particularly sensitive.

Recommendation:

• We recommend that if you have VMs that are particularly sensitive, you consider putting them in a pool that is limited to specific administrators.

• We also recommend using VLANs to isolate traffic for systems hosting sensitive data.

• We recommend that, in environments with Workload Balancing enabled, if you have a host in a pool that has a different (even if higher) physical security level, you exclude such a host from Workload Balancing optimization and placement recommendations by using the Workload Balancing Exclude Hosts feature. When enabled, the Exclude Hosts feature excludes physical hosts from Workload Balancing optimization and placement recommendations, including Start On placement recommendations.

Securing the Control Domain

Each host in a pool has a control domain. The control domain is a privileged VM that provides low-level services to other VMs, such as providing access to physical devices. It also runs the management tool stack.

The control domain contains the minimal functionality necessary to manage the host and is designed specifically for that purpose.

Recommendation:

• We strongly recommend that, to maintain the security, integrity and supportability of the control domain, you do not make any alterations to the control domain that we do not specifically recommend.

• We recommend configuring a strong password for your control domain, track who has these passwords, and have a policy for changing both the pool secret and the root account passwords on control domains when individuals with access leave the organization.

For more information, see the product documentation for Managing your administrator password and Rotating your pool secret.

Designing Environments for Auditing

Recommendation:

We recommend designing your environment with auditing in mind, including planning to enable Role Based Access Control (RBAC).

Enabling RBAC makes audit log data more meaningful since the transactions are logged with the associated user names.

Even if you do not wish your administrators to have different levels of access, RBAC allows you to audit which administrator performed which operation.

Recommendation:

We recommend that you configure individual RBAC user accounts for each administrator to provide accountability.

XenServer provides support for running reports on administrative changes. These reports can be helpful for detecting changes made to your XenServer environment by administrators for either troubleshooting, or possibly auditing and compliance reasons.

Support for auditing is provided through the Workload Balancing component and its workload reports. Configuring support for auditing reports requires Active Directory and the following relatively simple tasks:

1. Adding the Active Directory accounts of the XenServer administrators to XenServer.

2. Configuring the XenServer Role Based Access Control (RBAC) feature and assigning roles to the XenServer user accounts. For information about RBAC, see the product documentation.

3. Deploying Workload Balancing, as described in the product documentation, so that you can run the Audit Trail History report. For more information about this report and what it contains, see the “Pool Audit Trail” information in the product documentation.

Depending on your need to demonstrate the compliance of your environment, you might want to take additional steps to secure the Workload Balancing database, which is where the audit-trail data is stored. Such steps might include limiting the access to the password or documenting procedures to show how the access is controlled.

Tracking Possibly Unauthorized Changes to Your Environment

When you need to track down the entry point of malware or another threat, it is essential to be able to review the sources of changes to your environment.

Recommendation:

• We recommend you require administrators to use their individual user accounts since it is easier to isolate the source of unauthorized administrative changes. Not providing the root account password to administrators may assist in encouraging use of individual accounts.

• We recommend enabling RBAC and Workload Balancing so you can use Workload Balancing to run the Audit Trail History Report.

  The Audit Trail History Report lists administrative changes. For more information, see the product documentation.

• We recommend setting all systems in a geographic region to use the same time source (for example, by using an NTP server).

  When searching for events and changes across systems, it is extremely helpful if all of the systems through which you are searching are set to the same time. This makes it easier to use logs to correlate events across logs from different systems.

  When reviewing changes, be aware of time zones and whether the particular log entry reflects local time or Coordinated Universal Time (UTC)/Greenwich Mean Time (GMT).

Enabling Audit Logging

Audit logging, which is the recording of specific administrative changes, is enabled by default in XenServer.

The XenServer audit log records any operation with side effects (successful or unsuccessful). This record includes the server name targeted by the action and the success or failure of the action. The audit log also records associated user names or, if RBAC is not enabled, the type of account association with the action.

Recommendation:

• To increase the security and availability of the contents of the audit log and reduce the risk of an attacker changing its contents, consider sending your audit log to a remote server, ideally one inaccessible to XenServer administrators.

• We recommend both of the following:

  • Remote servers for storing logs be managed by somebody with different operational role (for example, by somebody on a team that does not manage the XenServer hosts)
  • Administrators with access to XenServer should not be granted permissions to modify or delete logs on the remote server

• We recommend retaining audit logs in accordance with your organizational security policy.

To configure remote storage of system logs using XenCenter

1. In the XenCenter Resource pane, select the host, and click the General tab.

2. On the General tab, click the Properties button.

3. On the Log Destination page, select Also store the system logs on a remote server and enter the remote server where you want to save the logs.

   

Disabling Remote SSH Access

Recommendation:

We recommend that customers who do not intend to use SSH access to the control domain disable SSH. Note that the console will still be available locally or through XenCenter.

To disable remote SSH access

1. In XenCenter, click the Console tab. Alternatively, you can go to the physical console.

2. At the command prompt, type xsconsole.

3. In the shell menu, scroll down to the Remote Service Configuration option and press Enter.

4. Select Enable/Disable Remote Shell and press Enter.

5. Enter your credentials and press Enter.

6. In the Configure Remote Shell options, select Disable and press Enter.

7. After a message appears stating configuration was successful, click OK.

Note: If you need to re-enable remote SSH access, repeat this procedure but select Enable in the Configure Remote Shell options.

XenCenter Security

If your version of XenCenter is not up to date, it will notify you that an update is available unless you have disabled that notification.

Recommendation:

We recommend that you ensure that you are using the latest version of XenCenter.

XenCenter can store credentials for all the hosts it controls. (This option is configured in Tools > Options > Save and Restore.)

Recommendation:

We recommend that you ensure that users only use the Save and Restore Service Connection State on Startup option if permitted by their organizational security policy. In particular, We do not recommend storing Active Directory credentials.

You can protect credentials stored by XenCenter by creating a main password. When enabled, XenCenter prompts users for a password to see any managed servers.

Recommendation:

• Where your organizational security policy permits XenCenter to store credentials, We recommend creating a main password for XenCenter to prevent unauthorized users from obtaining the credentials of managed XenServer hosts, for example if a laptop used to manage XenServer is stolen.

• We recommend restricting physical access to XenCenter. For example, do not leave unauthorized people unattended with access to a logged in XenCenter console.

To set a main password

1. From the XenCenter Tools menu, click Options and then click the Save and Restore tab.

2. Ensure that the Save and restore server connection state on startup check box is selected.

3. Under Main password, select the Require a main password check box, then enter and confirm the password, and click OK. Remember that passwords are case-sensitive.

Naming Hosts Clearly

Recommendation:

• We recommend using meaningful naming conventions when assigning host names to prevent inadvertently configuring hosts in the same pool that should not be connected for security reasons.

  • Choose a naming convention that has names that indicate physical security constraints (for example, the physical location).

• We recommend that you ensure your host names have significance to your organization so as to avoid moving a VM to the wrong host.

Securing Physical Hosts

This section provides recommendations about limiting physical access to hosts and securing out-of band (“lights-out”) management cards.

Limiting Physical Host Access

Recommendation:

We recommend that you take steps to limit physical access to systems. In particular, as a number of different functions may be running in a virtual environment at a specific physical location, you should consider the number of functions that may be simultaneously compromised.

Securing Out-of-band Management Cards (Lights-out Management)

Recommendation:

• If you require support for hardware features that enable remote administration on the host (for example, Dell DRAC or HP iLO), ensure that access is secured in accordance with your organization’s security policy for these features. Otherwise, disable these features.

• We recommend that you consider the type of traffic (for example, untrusted guest VM traffic) on a network when considering enabling remote administration on an interface on that network.