VCP6.5-DCV Objective 1.4 - Secure vSphere Virtual Machines

Today's objective is VCP6.5-DCV Objective 1.4 – Secure vSphere Virtual Machines. We continue to prepare a new VCP6.5-DCV Study Guide page because there aren't many resources organized around the Exam Preparation Guide (previously Exam Blueprint) for that exam.

Many candidates might hesitate to still study towards the VCP6-DCV – Exam Number: 2V0-621, ( it has 28 Objectives) or going for the VCP6.5-DCV (Exam Code: 2V0-622) which is few chapters longer (it has 32 Objectives). Both exams are valid for two years, then you have to renew. You can also go further and pass VCAP exam (not expiring).

Exam Price: $250 USD, there are 70 Questions (single and multiple answers), passing score 300, and you have 105 min to complete the test.

Tip: Check our How-to, tutorials, videos on a dedicated vSphere 6.5 Page.

Check our VCP6.5-DCV Study Guide Page.

You can download your free copy via this link – Download Free VCP6.5-DCV Study Guide at Nakivo.

VCP6.5-DCV Objective 1.4 – Secure vSphere Virtual Machines

Enable/Disable Virtual Machine Encryption
Describe Secure Boot
Harden virtual machine access
- Control VMware Tools installation
- Control VM data access
- Configure virtual machine security policies
Harden virtual machine against Denial-of-Service attacks
- Control VM-VM communications
- Control VM device connections
- Configure network security policies
Configure encrypted vMotion

Enable/Disable Virtual Machine Encryption

VM encryption will work by applying a new Storage policy to a VM. It is Policy driven. It will be per-VM policy application model.

There is no modification within the guest OS. It does not matter which OS you’re running (Linux, Windows, DOS, iOS). The encryption is happening outside of the Guest OS. So the guest does not have an access to the keys.

VM encryption allows protection against data theft. VMware VM encryption encrypts VMDKs, virtual machine files, and core dump files. It does not encrypt log files, VM config files. You might ask why? It's because there are no sensitive data within those files.

If someone who is not authorized tries to extract some data, it gets only meaningless data. The VM owns the VMDK, has the necessary key to decrypt the data whenever read and then fed to the guest operating system. It's done by using industry-standard encryption algorithms to secure this traffic with minimal overhead. But yes, there is a slight overhead.

VMware does not recommend to encrypt vCenter server appliance VMs.

The components:

Key Management Server (KMS) – not provided by VMware, but rather by VMware partners.
vCenter Server – keeps credentials for logging into the KMS. It “pushes” keys to the ESXi host when the host needs a key.
ESXi Hosts – The host must have encryption mode enabled. The keys that the ESXi host generates are called internal keys. These keys typically act as data encryption keys (DEKs). ESXi host makes sure that the guest data for encrypted VMs is encrypted when stored on disk. Also, the ESXi make sure that the guest data for encrypted VMs are not sent over the network without encryption.

The workflow:

vSphere Web client > Right Click VM > VM Policies > Edit VM storage policies > Drop down select policy > Apply to All

To decrypt > select storage policy > Apply to all.

Key Management Server – vCenter Server requests keys from an external KMS. The KMS generates and stores the keys, and passes them to vCenter Server for distribution. You can use the vSphere Web Client or the vSphere API to add a cluster of KMS instances to the vCenter Server system. If you use multiple KMS instances in a cluster, all instances must be from the same vendor and must replicate keys.

vCenter server – required privilege is “Cryptographic operations.Decrypt“.

ESXi Hosts – ESXi hosts are responsible for several aspects of the encryption workflow. vCenter Server pushes keys to an ESXi host when the host needs a key. The host must have encryption mode enabled. The current user's role must include cryptographic operation privileges.

The keys that the ESXi host generates are called internal keys in this document. These keys typically act as data encryption keys (DEKs).

How does it work?

When you power On the VM which has the Encryption Storage policy applied to, vCenter retrieves the key from the Key Manager and sends the key down to the VM encryption Module and unlocks that key in the ESXi hypervisor.

All IO coming out from the virtual SCSI device goes through the encryption module before it hits the storage module within the ESXi hypervisor. All IO coming directly from a VM is encrypted.

Describe Secure Boot

Secure boot, also called UEFI Secure Boot, is a security standard that makes sure that your PC boots using only software that is trusted by the PC manufacturer. For certain VMs hardware versions and operating systems, you can enable secure boot just as you can for a physical machine.

In an OS supports UEFI secure boot it means that all the bits and pieces participating in the boot process, use software which is signed, including the bootloader, the operating system kernel, and operating system drivers. The VM’s default configuration includes several code signing certificates:

Microsoft cert that is used only for booting Windows.
Microsoft cert that is used for third-party code that is signed by Microsoft, such as Linux bootloaders.
VMware certificate that is used only for booting ESXi inside a VM.

The VM’s default config has a cert for authenticating requests to modify the secure boot configuration including the secure boot revocation list, from inside the virtual machine, which is a Microsoft KEK (Key Exchange Key) certificate.

UEFI Secure Boot Requirements:

VMware Tools version 10.1 or later is required for virtual machines that use UEFI secure boot. You can upgrade those virtual machines to a later version of VMware Tools when it becomes available.
For Linux virtual machines, VMware Host-Guest Filesystem is not supported in secure boot mode. Remove VMware Host-Guest Filesystem from VMware Tools before you enable secure boot.
Check the VM's OS and Firmware supports UEFI boot.
EFI firmware
Virtual hardware version 13 or later. (VMX-13)

If requirements are not met, the checkbox is grayed out:

The workflow:

Gracefully shut down your VM. If the VM is running, the checkbox is grayed out.
Privileges – “VirtualMachine.Config.Settings” privileges to enable or disable UEFI secure boot for the virtual machine.

vSphere Web Client > select VM > Edit Settings > Boot Options> firmware is set to EFI > Enable secure boot check box > click OK.

When the virtual machine boots, only components with valid signatures are allowed. The boot process stops with an error if it encounters a component with a missing or invalid signature.

Harden virtual machine access

Use templates as much as you can. A template allows you to save your security settings to have uniformized configuration for all future deployments for your VMs. For further configuration, you should consider using scripting, PowerCLI, allowing you to perform mass modification on VMs, grouped by folder structure within your datacenter.

The guest OS should be protected with anti-spyware and anti-malware software. You should patch the template VM on regular basis in order to keep the patches up-to-date.

Disable unnecessary functions within the VM. You can optimize further by disabling unnecessary services

Disable unused services in the OS. For example, if the system runs a file server, turn off any Web services.
Disconnect unused physical devices, such as CD/DVD drives, floppy drives, and USB adapters.
Disable unused functionality, such as unused display features or HGFS (Host Guest File System)
Turn off screen savers.
Do not run the X Window system on top of Linux, BSD, or Solaris guest operating systems unless it is necessary.
Users with access to the virtual machine console have access to virtual machine power management and removable device connectivity controls. Console access might, therefore, allow a malicious attack on a virtual machine.

Control VMware Tools installation

Required privilege: Interaction .VMware Tools install (allows to mount or unmount VMware tools ISO)

Control VM data access

HGFS stands for Host guest file system. Certain operations such as automated VMware Tools upgrades use a component in the hypervisor called host guest file system (HGFS). In high-security environments, you can disable this component to minimize the risk that an aĴacker can use HGFS to transfer files inside the guest operating system.

vSphere Web Client > Select VM > Right-click > Edit Settings > VM Options > Click Advanced > Edit configuration > Check the isolation.tools.hgfsServerSet.disable is set to TRUE.

After that change, the VMX process no longer responds to commands from the tools process. APIs that use HGFS to transfer files to and from the guest operating system, such as some VIX commands or the VMware Tools auto-upgrade utility, no longer work.

Disable Copy and Paste Operations Between Guest Operating System and Remote Console – by default, this setting is disabled.

There are 3 advanced values to check within the same section as on the image above:

isolation.tools.copy.disable         true
isolation.tools.paste.disable        true
isolation.tools.setGUIOptions.enable      false

If those settings are enabled then the following could happen:

As soon as the console window gains focus, nonprivileged users and processes running in the virtual machine can access the clipboard for the virtual machine console. If a user copies sensitive information to the clipboard before using the console, the user— perhaps unknowingly—exposes sensitive data to the virtual machine.

Configure virtual machine security policies)

Check the Security policy information on pages 113 and 121 of the vSphere ESXi and vCenter Server 6.5 Security Guide PDF.

Harden virtual machine against Denial-of-Service attacks

VMware recommends disabling virtual disk shrinking, which can be used by non-administrative users which has an access to the guest OS. Shrinking of virtual disk allows reclaiming unused space. If you shrink repeatedly, you can cause a disk unavailability and cause a denial of service.

Select VM > Edit Settings > Click Advanced > VM Options > Edit Configuration.

isolation.tools.diskWiper.disable TRUE
isolation.tools.diskShrink.disable TRUE

When you disable this feature, you cannot shrink virtual machine disks when a datastore runs out of space.

Control VM-VM communications

This was previously done via VMCI. (Since vSphere 6.5 this is disabled).

The Virtual Machine Communication Interface (VMCI) is an infrastructure that provides fast and efficient communication between a virtual machine and the host operating system and between two or more virtual machines on the same host.

Control VM device connections

Check Remove Unnecessary Hardware Devices section, but basically, Any enabled or connected device represents a potential attack channel. Users and processes with privileges
on a virtual machine can connect or disconnect hardware devices, such as network adapters and CD-ROM drives. Attackers can use this capability to breach virtual machine security. Removing unnecessary hardware devices can help prevent attacks.

Configure network security policies

Securing Standard Switch Ports With Security Policies – VM NIC can send frames that appear to be from a different machine or impersonate another machine so that it can receive network frames that are intended for that machine. Also, like physical network adapters, a VM NIC can be configured so that it receives frames targeted for other machines. Both scenarios present a security risk.

When you create a standard switch for your network, you add port groups in the vSphere Web Client to impose a policy for the virtual machines and VMkernel adapters for system traffic attached to the switch.

As part of adding a VMkernel port group or virtual machine port group to a standard switch, ESXi configures a security policy for the ports in the group. You can use this security policy to ensure that the host prevents the guest operating systems of its virtual machines from impersonating other machines on the network. This security feature is implemented so that the guest operating system responsible for the impersonation does not detect that the impersonation was prevented.

The security policy determines how strongly you enforce protection against impersonation and interception attacks on virtual machines. To correctly use the settings in the security profiles you must understand how virtual machine network adapters control transmissions and how attacks are staged at this level.

Configure encrypted vMotion

There are 3 settings which are possible on the per-VM basis:

Disabled – do not use encrypted vMotion
Opportunistic – use encrypted vMotion if the source and destination hosts support it. If not it will do a normal vMotion.
Required – allow only encrypted vMotion. If the source or destination does not support encrypted vMotion, then the vMotion fails.

It is one-time generated random key, which is generated by vCenter (not the KMS).

Starting with vSphere 6.5, vSphere vMotion always uses encryption when migrating encrypted virtual machines. For virtual machines that are not encrypted, you can select one of the encrypted vSphere vMotion options.

Encrypted vSphere vMotion secures confidentiality integrity and authenticity of data that is transferred with vSphere vMotion. Encrypted vSphere vMotion supports all variants of vSphere vMotion for unencrypted virtual machines, including migration across vCenter Server systems. Migration across vCenter Server systems is not supported for encrypted virtual machines.

When you encrypt a virtual machine, the virtual machine keeps a record of the current encrypted vSphere vMotion setting If you later disable encryption for the virtual machine, the encrypted vMotion setting remains at Required until you change the setting explicitly. You can change the settings using Edit Settings.

Check the Full VCP6.5-DCV Study Page for all documentation, tips, and tricks. Stay tuned for other VCP6.5-DCV topics -:).

More from ESX Virtualization:

Stay tuned through RSS, and social media channels (Twitter, FB, YouTube)

Vote !

VCP6.5-DCV Objective 1.4 – Secure vSphere Virtual Machines

VCP6.5-DCV Objective 1.4 – Secure vSphere Virtual Machines