Protecting VMs
Securing Virtual Machines
Recommendation:
We recommend that you use the same practices that you would use to secure virtual machines that you would use to secure a physical server: in many ways, their security needs are comparable. This includes taking the same steps to secure the guest operating system as you would to secure the operating system on a physical machine.
We recommend enabling all of the standard methods of protection on the virtual machines, including virus, spyware, and malware protection and operating-system level firewalls, if appropriate.
We recommend checking that any virtual machines you start after a long period of dormancy have the latest updates to their anti-virus definitions and apply any relevant security patches.
We recommend disabling any unnecessary system components at the guest level, including in the operating system that may provide an attack surface. For example, follow the operating system vendor’s security guidance document.
We recommend, to reduce the risk of omitting to set a secure configuration, using templates with the guest operating system installed and configured with security settings whenever you create a VM.
We recommend creating a variety of templates that include not only the secured operating system but also any frequently deployed applications, such as Citrix Virtual Apps and Desktops (if applicable), that also have their security settings configured.
XenServer VM Tools
Recommendation:
We recommend that customers have the latest version of XenServer VM Tools running on their guest virtual machines to ensure the best manageability. However, as the tools are running in the guest virtual machines and not in the control domain or the hypervisor, they do not present an additional threat to the XenServer installation. Information on applying updates for XenServer VM Tools can be found at Update XenServer VM Tools for Windows.
Secure boot
XenServer supports UEFI Secure Boot for Windows VMs. This blocks incorrect binaries from being executed within the guest as the OS is loaded and so helps to protect the guest VM.
Recommendation:
We recommend that you consider enabling secure boot for your more sensitive VMs, taking into account whether VM OS has secure boot support.
Avoiding Resource Exhaustion During Abnormal System Load
Denial-of-service attacks (DoS attacks) are attempts to saturate a system’s resources to suspend services of a host connected to the Internet. Often this is done by attempting to saturate the target system with external communication requests to the extent that the target cannot respond and becomes unavailable. Typical targets may include web sites associated with financial transactions, including banks, credit card, and ecommerce sites.
Recommendation:
We recommend configuring sufficient CPU and memory resources to support the expected load of business critical VMs. There are two key principles to consider:
Ensure that a VM is provisioned with sufficient virtual resources to carry out its expected workloads.
Ensure that a VM is not overprovisioned so that in abnormal conditions it is not capable of consuming an unreasonable proportion of the host resources.
We recommend that you do not assign so much resource to one VM that, under its maximum load, it precludes other business-critical VMs from running.
We recommend that your configuration is sufficient to avoid the “domino” effect where the unavailability of one host or VM puts sufficient load on others that they in turn fail to be sufficiently responsive.
You can allocate CPU and initial memory resources to the new VM during VM creation or after the new VM is installed, if required. Specifically, you can allocate a number of virtual CPUs to a VM and set a priority for the VMs access to physical CPU resources on the host.
You can adjust the memory allocation either when a VM is created in the XenCenter New VM wizard, by changing it from the default, or after the new VM is created on the VM’s Memory tab.
Naming and tagging VMs
Recommendation:
If your organization does not have a policy on naming, we recommend naming VMs clearly using meaningful names.
For example, indicate specific properties of significant VMs (for example, “-HR-server” or “- finance-server”).
We recommend tagging VMs to group VMs with similar characteristics. For example, tags of “migrateable” or “missioncritical” can then be used in XenCenter searches to reduce the risk of accidentally operating on the wrong VM.
Securing Resource Pools
When multiple hosts are grouped together in resource pools, the pool has a pool coordinator host that controls the other hosts. All management communication between pooled hosts is done over TLS; hosts authenticate using a randomly generated secret that is created when you form the pool.
Recommendation:
We recommend physically isolating the management traffic and segregating it from other non management traffic.
However, if this is not possible, We recommend logically isolating the management traffic from other non-management traffic.
One method of logically isolating this management traffic is to use VLANs. You can configure your routers to tag all traffic from the management interfaces in the pool with a VLAN tag dedicated to this purpose.
If you decide to configure a VLAN for management traffic, be aware that remote clients such as XenCenter will need to connect to the management network VLAN.
Creating Pools
Consider the security requirements of the workloads you want to run on the pool.
Recommendation:
We recommend, if workloads must be run on hosts that require a specific level of physical security, you consider creating pools that contain hosts in one physical location only. That is, do not design a pool that has hosts in one physical location that is less secure than another physical location.
Using Live Migration Features
When using live migration features, such as Workload Balancing and High Availability, it is important to be aware of the sensitivity of the data on the virtual machines. Live migration can potentially change:
-
The host on which a VM resides
-
The groupings of VMs on hosts
For example, if you enable automation in Workload Balancing so that it applies optimization recommendations automatically, it is possible for a VM to move to a host without you being aware of it. (In fact, this is the expected and desirable behavior of the feature.)
As a result of automation, if pools contain hosts in multiple physical locations, Workload Balancing could move a VM containing highly sensitive data to a host in a server room that is not physically secured to the required level.
Recommendation:
We recommend, if you want to enable any live migration (for example, caused by Workload Balancing, High Availability or Rolling Pool Upgrade) features in the pool, ensure that all workloads can be run securely on hosts in all of the physical locations the pool encompasses, including the physical security of the premises in which the hosts are located. See also Using Live Migration Features.
Also, be aware that features, such as Workload Balancing and High Availability, can change the host on which a VM resides.
We recommend using any of the following to address live-migration requirements:
Designing pools from hosts that meet a common level of logical and physical security requirements
Not enabling automation features in Workload Balancing
Enabling automation in Workload Balancing, but excluding hosts from live migration
We recommend that, if you want to enable any live migration (Workload Balancing, High Availability) features in the pool, ensure that all workloads can be run securely on hosts on all of the physical locations the pool encompasses, including the physical security of the room in which the hosts are located.
We recommend, in some cases, excluding specific hosts from Workload Balancing if you want to ensure that specific workloads are never run on the same system. Likewise, you could run those workloads in different pools.
Features, such as Workload Balancing and High Availability, can change the host on which a VM resides.