Objective 1.4 – Secure vSphere Virtual Machines
Continuing on and completing the list of items in objective 1, here is Objective 1.4 – Secure vSphere Virtual Machines
Happy Revision!
Simon
VCP6.5 Certification Blueprint
Objective 1.4 – Secure vSphere Virtual Machines
Enable/Disable Virtual Machine Encryption
Encrypt an Existing Virtual Machine or Virtual Disk
You can encrypt an existing virtual machine or virtual disk by changing its storage policy. You can encrypt virtual disks only for encrypted virtual machines. You cannot encrypt a virtual machine by using the Edit Settings menu. You can encrypt virtual disks of an encrypted virtual machine by using the Edit Settings menu.
Prerequisites
- Establish a trusted connection with the KMS and select a default KMS.
- Create an encryption storage policy.
- Ensure that the virtual machine is powered off.
- Verify that you have the required privileges:
- Cryptographic operations.Encrypt new
- If the host encryption mode is not Enabled, you also need Cryptographic operations.Register host.
- Connect to vCenter Server by using the vSphere Web Client.
- Right-click the virtual machine that you want to change and select VM Policies > Edit VM Storage Policies.
- You can set the storage policy for the virtual machine files represented by VM home, and the storage policy for virtual disks.
- Select the storage policy that you want to use from the drop-down menu.
- To encrypt the VM and its hard disks, select an encryption storage policy and click Apply to all.
- To encrypt the VM but not the virtual disks, select the encryption storage policy for VM Home and
- other storage policies for the virtual disks, and click Apply.
- You cannot encrypt the virtual disk of an unencrypted VM.
- If you prefer, you can encrypt virtual disks from the Edit Settings menu.
- Right-click the virtual machine and select Edit Settings
- Leave Virtual Hardware selected.
- Open the virtual disk for which you want to change the storage policy and make a selection from
- the VM Storage Policy pull-down menu.
- Click OK.
Decrypt an Encrypted Virtual Machine or Virtual Disk
You can decrypt a virtual machine by changing its storage policy. All encrypted virtual machines require encrypted vMotion. During virtual machine decryption, the Encrypted vMotion setting remains. To change this setting so that Encrypted VMotion is no longer used, change the setting explicitly. This task explains how to perform decryption using storage policies. For virtual disks, you can also perform decryption using the Edit Settings menu.
Prerequisites
- The virtual machine must be encrypted.
- The virtual machine must be powered off or in maintenance mode.
- Required privileges: Cryptographic operations.Decrypt
- Connect to vCenter Server by using the vSphere Web Client.
- Right-click the virtual machine that you want to change and select VM Policies > Edit VM Storage Policies.
- You can set the storage policy for the virtual machine files represented by VM home, and the storage
- policy for virtual disks.
- Select a storage policy from the drop-down menu.
- To decrypt the virtual machine and its hard disks, click Apply to all.
- To decrypt a virtual disk but not the virtual machine, select a storage policy for the virtual disk
- from the drop-down menu in the table. Do not change the policy for VM Home.
- You cannot decrypt the virtual machine and leave the disk encrypted.
- Click OK.
- You can now change the Encrypted VMotion settings
- Right-click the virtual machine and click Edit Settings.
- Click VM Options, and open Encryption.
- Set the Encrypted vMotion value.
Describe Secure Boot
UEFI Secure Boot is a security standard that helps ensure that your PC boots using only software that is trusted by the PC manufacturer. For certain virtual machine hardware versions and operating systems, you can enable secure boot just as you can for a physical machine.
In an operating system that supports UEFI secure boot, each piece of boot software is signed, including the bootloader, the operating system kernel, and operating system drivers. The virtual machine’s default configuration includes several code signing certificates
- A Microsoft certificate that is used only for booting Windows.
- A Microsoft certificate that is used for third-party code that is signed by Microsoft, such as Linux bootloaders.
- A VMware certificate that is used only for booting ESXi inside a virtual machine.
The virtual machine’s default configuration includes one certificate 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
In almost all cases, it is not necessary to replace the existing certificates If you do want to replace the Certificates. 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.
Prerequisites
You can enable secure boot only if all prerequisites are met. If prerequisites are not met, the check box is not visible in the vSphere Web Client.
- Verify that the virtual machine operating system and firmware support UEFI boot.
- EFI firmware
- Virtual hardware version 13 or later.
- Operating system that supports UEFI secure boot.
- Turn off the virtual machine. If the virtual machine is running, the check box is dimmed.
- You need VirtualMachine.Config.Settings privileges to enable or disable UEFI secure boot for the virtual machine.
- Log in to the vSphere Web Client and select the virtual machine.
- In the Edit Settings dialog, open Boot Options, and ensure that firmware is set to EFI.
- Click the Enable secure boot check box and click OK.
- If you later want to disable secure boot, you can click the check box again.
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
Following virtual machine security best practices helps ensure the integrity of your vSphere deployment. A virtual machine is, in most respects, the equivalent of a physical server. Employ the same security measures in virtual machines that you do for physical systems.
- When you manually install guest operating systems and applications on a virtual machine, you introduce a risk of misconfigurations. By using a template to capture a hardened base operating system image with no applications installed, you can ensure that all virtual machines are created with a known baseline level of security.
- The virtual machine console provides the same function for a virtual machine that a monitor provides on a physical server. 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.
- When one virtual machine consumes so much of the host resources that other virtual machines on the host cannot perform their intended functions, a Denial of Service (DoS) might occur. To prevent a virtual machine from causing a DDoS, use host resource management features such as setting Shares and using resource pools.
- Any service that is running in a virtual machine provides the potential for attacks. By disabling system components that are not necessary to support the application or service that is running on the system, you reduce the potential.
Control VMware Tools installation
The following privilege is required to install VMware Tools Virtual machine .Interaction .VMware Tools install, this allows mounting and unmounting the VMware Tools CD installer as a CDROM for the guest operating system.
Control VM data access
Disable HGFS File Transfers
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 attacker can use HGFS to transfer files inside the guest operating system.
- Log in to a vCenter Server system using the vSphere Web Client and find the virtual machine.
- In the Navigator, select VMs and Templates.
- Find the virtual machine in the hierarchy.
- Right-click the virtual machine and click Edit Settings.
- Select VM Options.
- Click Advanced and click Edit Configuration.
- Verify that the isolation.tools.hgfsServerSet.disable parameter is set to TRUE.
When you make this 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
Copy and paste operations between the guest operating system and remote console are disabled by default. For a secure environment, retain the default settings If you require copy and paste operations, you must enable them using the vSphere Web Client.
These options are set to the recommended value by default. However, you must set them to true explicitly if you want to enable audit tools to check that the seĴing is correct.
Prerequisites
- Turn off the virtual machine.
- Log into a vCenter Server system using the vSphere Web Client.
- Right-click the virtual machine and click Edit Settings.
- Click VM Options, and click Edit configuration.
- Ensure that the following values are in the Name and Value columns, or click Add Row to add them.
- isolation.tools.copy.disable true
- isolation.tools.paste.disable true
- isolation.tools.setGUIOptions.enable false
- These options override any settings made in the guest operating system’s VMware Tools control panel.
- Click OK.
If you made changes to the configuration parameters, restart the virtual machine.
Limiting Exposure of Sensitive Data Copied to the Clipboard
Copy and paste operations are disabled by default for hosts to prevent exposing sensitive data that has been copied to the clipboard.
When copy and paste is enabled on a virtual machine running VMware Tools, you can copy and paste between the guest operating system and remote console. 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. To prevent this problem, copy and paste operations for the guest operating system are disabled by default.
It is possible to enable copy and paste operations for virtual machines if necessary.
Configure virtual machine security policies
Further Security policy information can be found between pages 113 and 121 of the vsphere-esxi-vcenter-server-65-security-guide.
Harden a virtual machine against Denial-of-Service attacks
Prevent Virtual Disk Shrinking
Nonadministrative users in the guest operating system are able to shrink virtual disks. Shrinking a virtual disk reclaims the disk’s unused space. However, if you shrink a virtual disk repeatedly, the disk can become unavailable and cause a denial of service. To prevent this, disable the ability to shrink virtual disks.
Prerequisites
- Turn off the virtual machine.
- Verify that you have root or administrator privileges on the virtual machine.
- Log in to a vCenter Server system using the vSphere Web Client and find the virtual machine.
- In the Navigator, select VMs and Templates.
- Find the virtual machine in the hierarchy.
- Right-click the virtual machine and click Edit Settings.
- Select VM Options.
- Click Advanced and click Edit configuration.
- Add or edit the following parameters.
- isolation.tools.diskWiper.disable TRUE
- isolation.tools.diskShrink.disable TRUE
- Click OK.
When you disable this feature, you cannot shrink virtual machine disks when a datastore runs out of space.
Limit Informational Messages From Virtual Machines to VMX Files
Limit informational messages from the virtual machine to the VMX file to avoid filling the datastore and causing a Denial of Service (DoS). A DoS can occur when you do not control the size of a virtual machine’s VMX file and the amount of information exceeds datastore capacity.
The virtual machine configuration file (VMX file limit is 1 MB by default. This capacity is usually sufficient but you can change this value if necessary. For example, you might increase the limit if you store large amounts of custom information in the files. The default limit of 1 MB is applied even when the tools.setInfo.sizeLimit parameter is not listed in the advanced options.
Log in to a vCenter Server system using the vSphere Web Client and find the virtual machine.
- In the Navigator, select VMs and Templates.
- Find the virtual machine in the hierarchy.
- Right-click the virtual machine and click Edit Settings.
- Select VM Options.
- Click Advanced and click Edit configuration
Prevent Virtual Machines from Taking Over Resources
When one virtual machine consumes so much of the host resources that other virtual machines on the host cannot perform their intended functions, a Denial of Service (DoS) might occur. To prevent a virtual machine from causing a DoS, use host resource management features such as seĴing Shares and using resource pools.
By default, all virtual machines on an ESXi host share resources equally. You can use Shares and resource pools to prevent a denial of service aĴack that causes one virtual machine to consume so much of the host’s resources that other virtual machines on the same host cannot perform their intended functions.
Do not use Limits unless you fully understand the impact.
- Provision each virtual machine with just enough resources (CPU and memory) to function properly.
- Use Shares to guarantee resources to critical virtual machines.
- Group virtual machines with similar requirements into resource pools.
- In each resource pool, leave Shares set to the default to ensure that each virtual machine in the pool receives approximately the same resource priority.
With this setting a single virtual machine cannot use more than other virtual machines in the resource pool.
Remove Unnecessary Hardware Devices
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
An attacker with access to a virtual machine can connect a disconnected hardware device and access sensitive information on any media that is left in a hardware device. The attacker can potentially disconnect a network adapter to isolate the virtual machine from its network, resulting in a denial of service.
Do not connect unauthorized devices to the virtual machine.
Remove unneeded or unused hardware devices and disable unnecessary virtual devices from within a virtual machine.
Ensure that only required devices are connected to a virtual machine. Virtual machines rarely use serial or parallel ports. CD/DVD drives are usually connected only temporarily during software installation.
- Log into a vCenter Server system using the vSphere Web Client.
- Right-click the virtual machine and click Edit Settings.
- Disable hardware devices that are not required.
- Include checks for the following devices:
- Floppy drives
- Serial ports
- Parallel ports
- USB controllers
- CD-ROM drives
Control VM-VM communications
VMCI is now disabled, the VM Communications interface is no longer available in vSphere 6.5.
Control VM device connections
Refer to the text in Remove Unnecessary Hardware Devices section.
Configure network security policies
Securing Standard Switch Ports With Security Policies
As with physical network adapters, a virtual machine network adapter 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 virtual machine network adapter 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 attcks 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
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.
For encrypted disks, the data is transmitted encrypted. For disks that are not encrypted, Storage vMotion encryption is not supported.
For virtual machines that are encrypted, migration with vSphere vMotion always uses encrypted vSphere vMotion. You cannot turn off encrypted vSphere vMotion for encrypted virtual machines.
For virtual machines that are not encrypted, you can set encrypted vSphere vMotion to one of the following states.
- Right-click the virtual machine and select Edit Settings.
- Select VM Options.
- Click Encryption, and select an option from the Encrypted VMotion drop-down menu.
The default is Opportunistic.
Disabled – Do not use encrypted vSphere vMotion.
Opportunistic – Use encrypted vSphere vMotion if source and destination hosts support it. Only ESXi versions 6.5 and later use encrypted vSphere vMotion.
Required – Allow only encrypted vSphere vMotion. If the source or destination host does not support encrypted vSphere vMotion, migration with vSphere vMotion is not allowed.
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.