These security controls provide a baseline set of vSphere hardware security best practices. They are structured in a way that explains the benefits and tradeoffs of implementing the control.
Variable Used
The PowerCLI commands in this section use the following variable:
- $ESXi = "host_name"
Use Intel Trusted Execution Technology
Ensure that Intel Trusted Execution Technology (TXT) is activated, if available in the system firmware.
Intel Xeon Scalable Processor platforms have TXT, which provides authenticity of a platform and its operating system. When activated, ESXi takes advantage of the security benefits offered by this technology.
- Potential Impact if Default Value Is Changed
- Early implementations of TXT occasionally caused sudden system shutdowns, triggering attestation alarms in vCenter Server, or even boot failures. A system restart resolves these problems, while an update to system firmware usually resolves it permanently. See the VMware knowledge base article at https://kb.vmware.com/s/article/78243.
Configure UEFI Secure Boot
Ensure that UEFI Secure Boot is activated.
Activating UEFI Secure Boot on the hardware of an ESXi host helps prevent malware and untrusted configurations.
Use TPM 2.0
Ensure that a Trusted Platform Module (TPM) 2.0 is installed and configured properly on your ESXi hosts.
ESXi can use a TPM to activate advanced security features that prevent malware, remove dependencies, and secure hardware lifecycle operations. When possible, configure your hosts to use TPM 2.0 and activate the TPM in the system firmware.
Ensure that Hardware Firmware Is Up-to-date
Ensure that you apply the latest firmware updates to all components of your systems, and that the firmware is authentic and supplied by your hardware manufacturer.
Hardware firmware is not immune from serious issues affecting confidentiality, integrity, or availability. Attackers can use vulnerable system management controllers and management engines to establish persistence, and re-infect and re-compromise hosts after reboots and updates.
Secure Integrated Hardware Management Controllers
Ensure that integrated hardware management controllers are fully secured.
Many servers have integrated hardware management controllers that can be extremely helpful when monitoring and updating hardware, settings, and firmware. For these controllers:
- Deactivate all unused functionality.
- Disable all unused access methods.
- Set passwords and password controls.
- Put firewalls and access control in place so that access only occurs from authorized access workstations for the virtualization administration team.
Deactivate all "first boot" configuration options, especially ones that reconfigure the system from an inserted USB device. Also, deactivate or protect USB ports attached to management controllers. Where possible, set USB ports to permit only keyboards.
Change default passwords for accounts.
Secure external information displays to prevent information from leaking. Secure power and information buttons against unauthorized use.
Many hardware management controllers provide alert mechanisms when hardware faults and configuration changes occur. Consider using these if you are not using another method for hardware monitoring.
- Potential Impact if Default Value Is Changed
- Deactivating connection methods might cause future monitoring and management changes to the hardware management controller configurations across your deployed servers. When possible, use CLI and API management methods that you can script in lieu of using additional management software or applications. Learning these techniques saves time, avoids the additional effort of installing and maintaining additional tools, and allows for timely configuration changes.
Synchronize Time on Integrated Hardware Management Controllers
Ensure that you synchronize time on integrated hardware management controllers.
Cryptography, audit logging, cluster operations, and incident responses depend on synchronized time. This recommendation extends to all devices in your infrastructure. Network Time Protocol (NTP) must have at least four sources. If you must choose between two sources and one source, one source is preferable.
Secure How Integrated Hardware Management Controllers Use Active Directory
Ensure that you do not create a dependency loop or attack vector in how integrated hardware management controllers use Active Directory.
Either deactivate connections to Active Directory, or at a minimum, considered them as attack vectors and dependency loops (for authentication, authorization, DNS, DHCP, and time). Consider managing local accounts on these devices through APIs and CLIs. If you must use Active Directory for authentication, use local authorization so that attackers with access to Active Directory cannot promote themselves through group membership.
Deactivate Virtual Integrated Hardware Management Controllers
Ensure that integrated hardware management controllers with internal, emulated, or virtual network interfaces are deactivated.
Some hardware management controllers have the ability to present virtual network interfaces to ESXi as a management interface. These approaches create potential back doors for access that adversaries can use to circumvent network-based and perimeter firewalls, in either direction, and to avoid observation by IDS, IPS, and threat analysis tools. In many cases, this functionality is not strictly necessary to manage hosts.
Activate AMD Secure Encrypted Virtualization-Encrypted State
Ensure that AMD Secure Encrypted Virtualization-Encrypted State (SEV-ES) is activated, if available in the system firmware. Ensure that the value for Minimum SEV non-ES ASID is equal to the number of SEV-ES virtual machines plus one.
AMD EPYC platforms support SEV-ES, a technology to encrypt memory and CPU register state, and limit visibility to the hypervisor, to increase workload security and decrease exposure to certain types of attacks. When configured properly, SEV-ES provides enhanced security to the guest operating system on virtual machines and containers under vSphere and vSphere with Tanzu. Activating SEV-ES in system firmware eases future enablement inside virtual machines, containers, and guest operating systems.
- Suggested Value
- Activated (Minimum SEV non-ES ASID is equal to the number of SEV-ES virtual machines plus one)
- Potential Impact if Default Value Is Changed
- The guest operating system for a virtual machine must support SEV-ES, and so limits some features, such as vMotion, snapshots, and so on. For more information about these tradeoffs, see Unsupported VMware Features on SEV-ES.
Activate Virtual Intel Software Guard Extensions (vSGX)
Ensure that Virtual Intel® Software Guard Extensions (vSGX) is activated, if available in the system firmware.
Intel Xeon Scalable Processor platforms have Software Guard Extensions, or SGX, a technology that helps applications protect data in system memory. When configured properly, vSphere supports the use of SGX inside virtual machines. Enabling SGX in system firmware eases future enablement inside virtual machines and guest operating systems.
- Potential Impact if Default Value Is Changed
- The guest operating system for a virtual machine must support vSGX, and so limits some features such as vMotion, snapshots, and so on. For more information about these tradeoffs, see Unsupported VMware Features on vSGX.
Deactivate External Ports
Ensure that unused external ports are deactivated or protected against unauthorized use.
Unused ports, especially USB, can be used by attackers to attach storage, networking, and keyboards. Take reasonable steps to control access to these ports through disablement and access control. Where possible, use other means such as solid rack doors, rack side panels, and flooring to make the ports inaccessible from outside the rack when the rack door is closed. Be aware that cables fit easily through many gaps in and around racks and rack doors, and stiff wires can be used to push cables into sockets from outside the rack, as well as to dislodge cables to create a service disruption.
Where possible, set USB ports to permit only keyboards.
When deactivating this type of functionality, consider that you might need to access a server using a USB keyboard during an outage, or as part of lifecycle operations, and plan accordingly.
- Potential Impact if Default Value Is Changed
- Security is always a tradeoff. When considering a security control such as deactivating external ports, make ease of recovery from an outage or an incident a part of the equation. In this case, deactivating external ports affects the ability to use the ESXi console in case of emergency.
