Objective 1.4 – Secure vSphere Virtual Machines

The hardening guide describes a lot of specific VM options, but, starting with ESXi 6.0 Patch 5, many of the advanced VM settings are now set to be Secure By Default.

This means that the desired values in the Security Configuration Guide are the default values for all new VMs, and you don't have to manually set them anymore.

For more information, see the blog post at https://blogs.vmware.com/vsphere/2017/06/secure-default-vm-disable-unexposed-features.html.

For virtual networking, NSX can provide a micro-segmentation capability, to enforce network security directly at the VM virtual NIC level.

Also, at VMworld 2017, a new product was announced: VMware AppDefense, a data center endpoint security product that protects applications running in virtualized environments. AppDefense works inside of the VM (compared to NSX, which only works at the network level), and understands how applications are normally supposed to work, monitoring any changes that could indicate a threat.

Objective 1.4 is totally new for VCP65-DCV, but it contains some parts of Objective 1.2, from the VCP6-DCV exam preparation guide.

Enable/disable VM encryption

VMware vSphere 6.5 added the possibility to encrypt VM files (such as .vmx and swap files) and virtual disks (VMDK), making the stored VM data more secure. For example, they are inaccessible with a simple data store browsing operation.

To allow VM encryption, the following components are needed:

• KMS: Generates and stores the keys needed to encrypt and decrypt the VMs. The KMS provides vCenter and ESXi with the necessary keys by using the KMIP protocol. Multiple KMS vendors are compatible, including HyTrust, Gemalto (SafeNet), Thales e-Security, CloudLink, and Vormetric. For a complete list, see the VMware Compatibility Guide (https://www.vmware.com/resources/compatibility/search.php?deviceCategory=kms&details=1&releases=354&page=1&display_interval=10&sortColumn=Partner&sortOrder=Asc). KMS configuration was described in Objective 1.3.
• vCenter Server: The only component that can log in to the KMS to obtain the keys and pass them to ESXi hosts is vCenter Server. The different KMS keys are not stored in the vCenter; it only keeps a list of key IDs.

No additional or specific hardware is required for the encryption/decryption operations, but processors with support of the AES-NI instruction set are recommended, in order to improve the performance. AES-NI should be enabled in the host BIOS.

VM encryption is controlled by VM storage policies (see Chapter 3, Configure and Administer vSphere 6.x Storage, for more information). To change the storage policy of a VM, follow this procedure:

1. From the vSphere Web Client, right-click on the VM to encrypt. Navigate to VM Storage Policies | Edit VM Storage Policies.

2. From the VM storage policy drop-down menu, select the VM Encryption Policy option to encrypt the VM:

Figure 1.29: Encrypting a VM

3. When the encryption process has completed, the VM Hardware area in the VMs Summary tab will display the Encryption field that indicates which components are encrypted.

There are different recommendations when using encrypted VMs, but the most important are as follows:

• If PSC or vCenter are implemented as VMs, don't encrypt them.
• Never edit the .vmx files or .vmdk descriptor files of encrypted VMs; otherwise, the VMs will become unrecoverable.

To perform the preceding operations, you will need the required privileges, as follows:

• Cryptographic operations.Encrypt new
• Cryptographic operations.Decrypt
• Cryptographic operations.Register host (if the host encryption mode is not enabled)

Note that encrypted VMs can be a challenge for native backup programs, but there is a way to permit backup of the encrypted files in a clear format, to allow for indexing and granular restore. Several backup products already support this feature.

For more information, see the vSphere 6.5 Security Guide (https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.security.doc/GUID-5E2C3F74-38C1-44C3-ABC5-C2C9353B9DC4.html).

Describe VM Secure Boot

As described in Objectve 1.2, Unified Extensible Firmware Interface (UEFI) is a replacement for the traditional BIOS firmware, and secure boot uses the UEFI firmware to validate the digital signature of the operating system and its bootloader.

With vSphere ESXi 6.5, you can use secure boot with both ESXi and VM. For ESXi secure boot description, see Objective 1.2.

VM secure boot has some important requirements, as follows:

• Virtual hardware version 13 or later
• EFI firmware in the VM boot options
• VMware Tools version 10.1 or later
• A guest operating system that supports UEFI secure boot:
  • Some examples of supported operating systems are Windows 8 and Windows Server 2012 or newer, VMware ESXi 6.5 and Photon OS, RHEL/Centos 7.0, and Ubuntu 14.04

You can enable secure boot on a VM by using the vSphere Web Client, in the VM options of the desired VM, as follows:

Figure 1.30: VM secure boot

You cannot upgrade a VM that uses BIOS boot to a VM that uses UEFI boot. If a VM already uses UEFI boot and the operating system supports UEFI secure boot, you can simply enable secure boot.

You will need VirtualMachine.Config.Settings privileges to enable or disable UEFI secure boot for the VM.

For more information, see the vSphere 6.5 Security Guide (https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.security.doc/GUID-898217D4-689D-4EB5-866C-888353FE241C.html).

Harden virtual machine access

As described in Objective 1.2, VMware has provided some Security Hardening Guides (https://www.vmware.com/security/hardening-guides.html) to provide guidance on how to increase security in a vSphere environment.

VMware suggests some security best practices to increase the security of VMs running in a vSphere environment, as follows:

• Use templates: Instead of manually installing guest operating systems and applications, prefer templates or other provisioning systems to enforce security baselines.
• Limit console access: Be sure to protect and limit access to the VM console, for the confidentiality of data (by default, more users can see the same VM console sessions).
• Limit remote access: Remote protocols used for management (such as SSH or RDP) must be secured, controlled, and limited.
• Limit resources: Without proper resource management (such as resource pools), more VMs can consume most of the host resources, with a possible denial-of-service (DoS) scenario.
• Minimize services: Any service that is running in a VM is a potential target for attacks. Be sure to disable services or system components that are not necessary.
• Minimize hardware: Disconnect or remove unused devices, such as CD/DVD drives, floppy drives, and USB adapters. This also helps with VM migration. Note that CD/DVD drives may be needed for VMware Tools installation/upgrade.
• Limit VMware Tools functions: Disable unused functionality, such as unused display features or host guest file systems (HGFSs). Some of those functions will be discussed in the next section.

Because a VM is almost equivalent to a physical server, it is possible (in most cases) to apply the same security approaches and solutions.

For more information, see the vSphere 6.5 Security Guide (https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.security.doc/GUID-CF45F448-2036-4BE3-8829-4A9335072349.html).

Control VMware Tools installation

VMware Tools installation and upgrade is performed by using the virtual CD/DVD drive. This means that, without it, you cannot perform those operations from the vSphere Web Client.

Another option for disabling VMware Tools installation is to change the role and remove the privilege required to install VMware Tools (Virtual machine .Interaction.VMware Tools install).

Note that both tricks do not work with standalone VMware Tools if they are installed from the binaries files in the guest OS.

Control VM data access

VMware provides some functions to permit data access inside of the VM:

• HGFS: This is used to transfer files between the host and the VMs. Note that this capability is actually only leveraged on Workstation/Player/Fusion, and it's not implemented in ESXi.
• Copy and paste between the guest OS and remote console: By default, this feature is disabled, as recommended for a secure environment. If copy and paste is enabled and the VM has VMware Tools installed, you can copy and paste between the guest operating system and the remote console.

You can control those features by using the vSphere Web Client: select a VM, right-click on the VM, and click on Edit Settings. In the VM Options tab, click on Advanced, and click on Edit Configuration.

At this point, check the specific rows (if they exist) or create new rows. The following table summarizes some possible parameters:

VM advanced parameter	Recommended value	Result
isolation.tools.hgfsServerSet.disable	TRUE	Disable HGFS file transfer
isolation.tools.copy.disable	TRUE	Disable copy operations
isolation.tools.paste.disable	TRUE	Disable paste operations
isolation.tools.setGUIOptions.enable	FALSE	Disable VMware Tools options from the guest

Table 1.8: Hardening VM advanced settings

If you make changes to the preceding configuration parameters, restart the VM to load the changes.

Note that all of those four settings are disabled by default starting ESXi 6.5 update 1, in ESXi 6.0 Patch 5 and 5.5 Update 3 Patch 11.

The vSphere 6.5 Security Guide (https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.security.doc/GUID-60E83710-8295-41A2-9C9D-83DEBB6872C2.html) reports other settings that are not exposed in vSphere, but could cause vulnerabilities, as follows:

VM advanced parameter	Recommended value
isolation.tools.unity.push.update.disable	TRUE
isolation.tools.ghi.launchmenu.change	TRUE
isolation.tools.memSchedFakeSampleStats.disable	TRUE
isolation.tools.getCreds.disable	TRUE
isolation.tools.ghi.autologon.disable	TRUE
isolation.bios.bbs.disable	TRUE

Table 1.9: Other hardening VM advanced settings

Configure virtual machine security policies

Some VM security policies have already been discussed; others, related to DoS attacks, will be discussed in the next section.

Harden a virtual machine against DoS attacks

One or more VMs may consume too many resources on a single host, causing a possible DoS scenario. To minimize this possibility, a proper configuration of the VM resource management is needed; also, remember that each VM has implicit limits, due to resources configured in the VM settings.

Other possible DoS situations are as follows:

• Virtual disk shrinking: Shrinking a virtual disk reclaims the disk's unused space. This operation can be performed by a non-administrative user in the guest operating system, and multiple operations can cause a DoS on the virtual disk. To disable the ability to shrink virtual disks, you must use two VM advanced settings, isolation.tools.diskWiper.disable and isolation.tools.diskShrink.disable, as described in KB 1002019 (https://kb.vmware.com/s/article/1002019)—Growing, thinning, and shrinking virtual disks for VMware ESX and ESXi.

This operation is not supported in ESXi, but it is supported in Workstation/Player/Fusion.

• Informational messages from VM to VMX files: A DoS can happen if you do not control the size of a VMs VMX file, and the amount of information in it exceeds the data store capacity. By default, the file limit is 1 MB, and you can change it with the tools.setInfo.sizeLimit VM advanced option. For more information, see the vSphere 6.5 Security Guide (https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.security.doc/GUID-9610FE65-3A78-4982-8C28-5B34FEB264B6.html).
• Unnecessary hardware devices: Any connected device represents a potential attack channel. As described previously, it's a good practice to remove or disable all unneeded or unused devices. Note that, by default, users and processes with local privileges on a guest OS can connect or disconnect some hot-plug hardware devices (such as the virtual NIC).

Control VM-VM communications

The Virtual Machine Communication Interface (VMCI) provides a communication channel between a VM and the host, or between two or more VMs on the same host. In vSphere 6.5, VMCI is disabled by default.

Of course, each VM can talk to others by using the virtual network, so be sure to enforce network segregation with VLAN at the portgroup level, or, if possible, micro-segmentation with NSX.

Control VM device connections

As described previously, any device can represent a potential attack channel, and a good practice is to remove or disable unnecessary devices.

Using VMware Tools, it's possible to connect or disconnect devices, potentially causing a DoS, but this feature is disabled by default. For more information, see the vSphere 6.5 Security Guide (https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.security.doc/GUID-F88A5FED-552B-44F9-A168-C62D9306DBD6.html).

Note that VMware provides some devices that are hot-pluggable (such as the virtual NIC). In this case, users and processes with local guest OS privileges (root or administrator) can disconnect those types of devices from the OS. For more information, see KB 1012225 (https://kb.vmware.com/s/article/1012225)—Disabling the HotAdd/HotPlug capability in ESXi 6.x, 5.x and ESXi/ESX 4.x VMs.

The following table summarizes some parameters for controlling the VM device connections:

VM advanced parameter	Recommended value	Result
isolation.device.connectable.disable	TRUE	Disable the connection of devices
isolation.device.edit.disable	TRUE	Disable copy operations
devices.hotplug	FALSE	Disable device hotplug

Table 1.10: Hardening VM advanced settings

Configure network security policies

Standard and distributed virtual switches (described in Chapter 2, Configure and Administer vSphere 6.x Networking) both have specific security policies:

• Promiscuous mode: Promiscuous mode permits a virtual NIC to capture all frames on the virtual switch portgroup. Of course, it can represent a security risk for the confidentiality of the data.
• MAC address changes: The guest OS can change the MAC address of the virtual NIC, and this can be used by a spoofing attack.
• Forged transmits: Any outgoing frame with a source MAC address that is different from the one currently set on the VMX file.

By default, on distributed virtual switches, all of the previous policies are rejected. On standard virtual switches, only the promiscuous mode is rejected; in that case, you can change the settings with the vSphere Web Client, by selecting the Configure tab on the desired host, and then the Virtual switches menu. Then, select the desired virtual switch, click the Edit settings icon, and choose the Security menu:

Figure 1.31: Network security policies

For more information, see the vSphere 6.5 Security Guide (https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.security.doc/GUID-9782B9AA-CB4C-40FF-AD1F-359180545D6E.html).

Configure VM encrypted vMotion

Protecting stored data is only one element of security; you also need to encrypt the network connections. For the infrastructure part, all of the communication between vCenter and the hosts is usually encrypted. However, some other infrastructural network traffic usually is not protected; for example, iSCSI or NFS traffic (and also vMotion, until vSphere 6.5).

As described in Objective 1.2, there is now a new feature to encrypt vMotion traffic.

Encryption of vMotion traffic is per-VM; when the VM is migrated, a one-time 256-bit key is randomly generated by vCenter Server (note that it does not use the KMS).

Settings are per-VM, but only for VMs with virtual hardware 13. You can view or change the settings by right-clicking on the VM and selecting Edit Settings..., then selecting the VM Options tab in the Encrypted vMotion section:

Figure 1.32: Encrypted vMotion settings

The different options are as follows:

• Disabled: Do not use encrypted vMotion for this VM.
• Opportunistic (default): Use encrypted vSphere vMotion only if the source and destination hosts can support it (ESXi versions 6.5 and later).
• Required: Force the use of encrypted vMotion. If the source or destination host does not support encrypted vMotion, then the migration will not be possible.

You can disable vMotion encryption, unless the VM is encrypted; in that case, it is always enforced.

In vSphere 6.5, migration across vCenter Server systems is not supported for encrypted VMs.

For storage vMotion or vMotion without shared storage, the disks are transmitted as they are, as follows:

• For encrypted disks, the data is transmitted encrypted.
• For disks that are not encrypted, Storage vMotion encryption is not supported.

For more information, see the vSphere 6.5 Security Guide (https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.security.doc/GUID-E6C5CE29-CD1D-4555-859C-A0492E7CB45D.html).