Deploying XenServer Hosts

Preparing the host server

It is important to ensure that, prior to installing XenServer, your hardware has been updated in accordance with your hardware vendor’s recommendations.

Recommendation:

• We recommend that you apply all firmware (BIOS/UEFI) updates recommended by your hardware vendor prior to installing XenServer.

• We recommend that you ascertain how your hardware vendor will inform you of future security and stability updates to their firmware.

Installing XenServer

When installing XenServer, it is important to be aware of best practices that can help ensure your deployment remains secure. These practices include:

• Checking the integrity of downloaded installation files.

• Waiting to connect (cable) hosts to physical networks until all hosts are configured. All of these considerations are described in more detail in the sections that follow.

Installation Media

It is important to ensure that the XenServer installation media you are using is a genuine copy from the XenServer downloads page.

Recommendation:

We recommend the following for customers downloading XenServer installation media:

1. Downloading the XenServer installation files only from the secured xenserver.com site.

2. Before installing XenServer, check the integrity of the downloaded installation files. Verify the download against the secure checksum information on the XenServer download page. The checksum information lets you verify that the image you downloaded or obtained has not changed from the way in which we packaged it.

Checking the Integrity of Downloaded ISO Files

Recommendation:

We recommend verifying the integrity of downloaded ISO files.

This section provides examples of how you can verify the integrity of downloaded ISO files for Windows and Linux. There are several different ways of accomplishing this task. The instructions are provided as an example.

To verify the integrity of the ISOs on Windows

1. At a Windows command line, type the following command:

   certutil \-hashfile XenServer8\_YYYY-MM-DD.iso SHA256
   

2. Compare the checksum output to the checksum information on the XenServer download page.

Note: It is important to compare the full length of the checksum and not just a few characters.

To verify the integrity of the ISOs on Linux

1. Log in, or open a console, to display a shell prompt.

2. At the prompt, type the following command:

    % sha256sum XenServer8\_YYYY-MM-DD.iso
   

3. Compare the checksum output to the checksum information on the XenServer download page.

Note: It is important to compare the full length of the checksum and not just a few characters.

Network installation

Recommendation:

We recommend that if you are installing from a PXE boot server, you use a server that you trust.

In practice, this means that you should make sure that you connect to the PXE boot server over the management network and not the guest network. As previously discussed, this is to prevent a tenant PXE server with malicious XenServer installations from impersonating your PXE server.

Before Deploying Hosts

Before deploying a XenServer host or pool, we recommend performing both of the following:

• Verifying you configured your physical networks and VLANs as you expected

• Verifying the identity of a host

Recommendation:

• We recommend that before you put a pool into production, you double-check that your networks are configured and isolated as you expect. If you separated the different types of traffic from each other, check to make sure that you successfully isolated each traffic type.

  For example, you might consider monitoring network traffic, examining network port activity lights (if present) and, if your network numbering and masking permits, trying to ping a device across networks.

  You should check for isolation for each guest network, the management network and any IP-based storage networks.

• We recommend that you do not cable the host, when installing XenServer, beyond connecting it to the management network – until you have all the host networks configured and the correct security policies in place.

• We recommend that you ensure you have physically and logically isolated the management network through cabling and configuration before physically plugging the host in to the guest network where it may be exposed to potentially hostile traffic. This is particularly true in environments where the users and administrators of the guest VMs are unknown and may have malicious intent.

• We recommend that, if you have a bare metal machine and you are booting it off the network using a boot server (for example, a PXE installation), take steps to validate the identity of the installation server before proceeding with installation.

  This is particularly true in environments where a malicious guest VM could have a PXE server that you unwittingly connect to when performing installation.

  • We recommend that you configure your host’s BIOS to only use trusted network interfaces for PXE boot.

Adding Hosts to Pools

Recommendation:

We recommend that you follow the previous advice when adding new hosts to an existing pool, with the following difference:

When adding hosts to a pool, do not connect to the guest networks until after:

1. You add the host to the pool

2. The pool coordinator is finished replicating the pool networks on the new host

Creating Secure Templates

A template that was created with only one use case in mind might be re-used for many other VMs with differing security requirements.

Recommendation:

• We recommend that you take extra care when creating VMs for replication (as templates) to ensure that the configurations are suitable for all potential uses of the VM.

• We recommend that you ensure that when you create templates, you do not unintentionally include data such as user accounts and data, in particular secrets such as SSH keys.

• We recommend that templates are named so as to indicate their intended purpose (for example, to avoid using an experimental template for a production VM, specify “-test” as part of their name).

• We recommend that if you are going to create VMs from a template, when you build your templates, you should make sure the template does not include any unnecessary or undesirable networks.

• We recommend that you do not assign unnecessary network ports to each guest.

For example, when initially making the VM from which you want to generate the template, verify you do not create virtual network interfaces for all of the networks (NICs) available on your host.

The following image shows the screen where you can delete unnecessary network ports from VMs.

In the Create New VM wizard, when you are creating a new VM for use as a template, delete any unused networks to prevent the wizard from creating virtual network interfaces for them.

Recommendation:

We recommend that you ensure that VM templates are considered as part of your organization’s patching schedule.

Accessing XenServer Hosts and Using Certificates

Each XenServer host generates a set of random cryptographic key-pairs when it is installed. Each key-pair is split into two portions: a public key that is displayed to clients, and a private key that is only known to the host and can be used to prove that it is the owner of the public key.

The XenServer host generates two classes of keys: one for the Secure Shell (SSH) protocol and a second for the management API TLS network service. SSH is only used for advanced configuration of the control domain and should not be needed in normal use. The management API TLS communication path is used much more often (for example, by XenCenter).

The main use of these keys is to confirm that you are connecting to the correct host.

Adding Hosts to XenCenter Securely

Recommendation:

We recommend verifying that, when you add a host to XenCenter, the host you are adding is not being impersonated. Perform the steps in the procedure that follows to make sure you are not under a man-in-the-middle attack by an attacker trying to impersonate a XenServer host.

To verify you are not connecting to an impersonated host, obtain the TLS key for the host before adding the host to XenCenter. After noting the key, when you add the host to XenCenter, you can compare it to the key XenCenter displays when you add the host. After XenCenter connects to a host for the first time, XenCenter stores the TLS key and associates it with the host record. If the host key changes (for example, the host is upgraded or reinstalled), a warning appears showing the new host key.

Note: The terms thumbprint and fingerprint are used interchangeably throughout this section.

To obtain the TLS key fingerprint for a host

1. At the physical host, open the xsconsole by typing xsconsole at the command prompt.

2. Open the Status Display. Note the SSL Key Fingerprint for https that appears in the console.

To verify the host’s identity when you add it to XenCenter

1. Add the host to XenCenter (Server > Add).

2. In the New Security Certificate dialog that appears, click View Certificate.

3. In the Certificate dialog that appears, click Details.

4. Scroll down to the Thumbprint field and select it.

1. If desired, click Copy to File to copy the thumbprint to the clipboard.

2. If you copied the thumbprint, click OK to exit the dialog. The New Security Certificate dialog appears.

3. Compare the TLS key fingerprint XenCenter displays to the one you noted at the host console. If the two fingerprints do not match, click Cancel in the dialog box and investigate why the host XenCenter is connecting to is not the same host as the one you believe were adding.

Note: It is important to compare the full length of the fingerprint and not just a few characters.

To verify the TLS key fingerprint

1. In the Security Certificate Changed dialog, click View Certificate.

2. In the Certificate dialog box, click the Details tab.

3. Scroll down towards the bottom of the fields list and select the Thumbprint field.

1. If desired, click Copy to File to copy the thumbprint to your clipboard.

To display a warning for new or modified TLS certificates on hosts

1. In XenCenter, in the Tools menu, select Options.

2. In the left-hand pane, select Security.

3. Select Warn me when a new certificate is found and Warn me when a certificate changes.

When a certificate changes, you see the following message:

Configuring Trusted Certificates for XenServer Hosts

Recommendation:

• We recommend replacing self-signed certificates with certificates from a trusted certificate authority to reduce the risk of malicious servers impersonating your hosts.

• We recommend, for XenServer customers running Citrix Virtual Desktops workloads, using HTTPS to secure communication between Desktop Delivery Controller and XenServer. To use HTTPS, you must replace the default TLS certificate installed with XenServer with one from a trusted certificate authority that is also trusted by the Desktop Delivery Controller.

  For information about configuring XenServer certificates see the topic Install a TLS certificate on your server in the product documentation.

Decommissioning Systems

Decommissioned hosts may contain sensitive data on VMs.

Recommendation:

• We recommend completely erasing all data on local disks when decommissioning hosts containing sensitive data or that are part of highly secured environments.

• We recommend that, when removing hosts, you also remove any access that has been granted by switches, storage backends etc. based on the removed host’s MAC addresses or HBA identifiers.

Reusing Physical Servers

Recommendation:

We recommend that you completely wipe and reimage hosts before reusing them in your environment; hosts may contain traces of sensitive data, passwords, or viruses.