Follow the ESXi security best practices to ensure the integrity of a vSphere deployment.

Verify Installation Media

Check the hash of the file after downloading an ISO, offline bundle, or patch to ensure integrity and authenticity of the downloaded files. Physical media acquired from VMware with a broken security seal must be returned for a replacement.

After downloading the media, use the MD5 sum value to verify the integrity of the download. Compare the MD5 sum output with the value provided along with the file. Each operating system has a different method and tool for checking MD5 sum values. For Linux, use the md5sum command. For Microsoft Windows, an add-on product can be downloaded.

Check CRLs Manually

By default, an ESXi host does not support CRL checking. Revoked certificates must be searched for and removed manually. These certificates are typically custom generated certificates from a corporate CA or a third-party CA. Many corporations use scripts to find and replace revoked SSL certificates on ESXi hosts.

Monitor the ESX Admins Active Directory Group

The Active Directory group used by vSphere is defined by the plugins.hostsvc.esxAdminsGroup advanced system setting. By default this option is set to ESX Admins. All members of the ESX Admins group are granted full administrative access to all ESXi hosts in the domain. Monitor the Active Directory for the creation of this group and limit membership to highly trusted users and groups.

Monitor Configuration Files

Although most ESXi configuration settings are controlled with an API, a limited number of configuration files affect the host directly. These files are exposed through the vSphere file transfer API, which uses HTTPS. If changes are made to these files, the corresponding administrative action must also performed (for example, making a configuration change).

Note:

Do not attempt to monitor files that are not exposed using this file transfer API.

Use vmkfstools to Erase Sensitive Data

After a VMDK file with sensitive data is deleted, shut down or stop the associated VM, and then issue the vCLI command vmkfstools --writezeros on that file. Then the file can be deleted from the datastore.

Special Care Required with PCI, PCIe Devices, and ESXi

Using the VMware DirectPath I/O feature to pass through a PCI or PCIe device to a VM results in a potential security vulnerability. The vulnerability can be triggered by malicious code, such as a device driver, running in privileged mode in the guest OS. Industry standard hardware and firmware does not currently have sufficient error containment support to make it possible for ESXi to fully close the vulnerability.

VMware recommends using PCI or PCIe passthrough to a VM only if the VM is owned and administered by a trusted or VMware validated entity. If exploited, it is possible to crash or manipulate the host from the VM.

The host can also be compromised in one of the following ways.

  • The guest OS can generate an unrecoverable PCI or PCIe error. Such an error does not corrupt data, but can crash the ESXi host. Such errors might occur because of bugs or incompatibilities in the hardware devices that are being passed through, or because of problems with drivers in the guest OS.

  • The guest OS might generate a Direct Memory Access (DMA) operation that causes an IOMMU page fault on the ESXi host, for example, if the DMA operation targets an address outside the VM's memory. On some machines, host firmware configures IOMMU faults to report a fatal error through a Non-Maskable Interrupt (NMI), which causes the ESXi host to crash. This problem might occur because of problems with the drivers in the guest OS.

  • If the operating system on the ESXi host is not using interrupt remapping, the guest OS might inject a spurious interrupt into the ESXi host on any vector. ESXi currently uses interrupt remapping on Intel platforms where it is available; interrupt mapping is part of the Intel VT-d feature set. ESXi does not use interrupt mapping on AMD platforms. A spurious interrupt most likely results in a crash of the ESXi host; however, other ways to exploit these interrupts might exist in theory.