You must follow multiple best practices at all times when you operate your ESXi hosts.
Best Practice |
Description |
|---|---|
Add only system accounts to the ESXi exception users list.
|
You can add users to the exception users list from the vSphere Client. These user accounts do not lose their permissions when the host enters lockdown mode. Only add service accounts such as backup agents. Do not add administrative users or user groups to exception users list. |
Install security patches and updates for ESXi hosts.
|
You install all security patches and updates on the ESXi hosts as soon as the update bundles are available in SDDC Manager. Do not apply patches to ESXi manually or by using vSphere Update Manager or VMware vCenter Lifecycle Manager in a VMware Cloud Foundation environment unless directed to do so by support. If you patch the environment without using SDDC Manager, it can not only lead to a less-secure environment, but may cause issues with automated upgrades or actions in the future. |
Do not provide root or administrator level access to CIM-based hardware monitoring tools or other third-party applications.
|
The CIM system provides an interface that activates hardware-level management from remote applications through a set of standard APIs. In environments that implement CIM hardware monitoring, create a limited-privilege, read-only service account for CIM and place this user in the Exception Users list. If a CIM write access is required, create a new role with only the |
The ESXi host must use approved certificates.
|
The default self-signed, VMCA-issued host certificate must be replaced with a certificate from a trusted Certificate Authority (CA) when the host is accessed directly, such as during a virtual machine (VM) console connection. |
Ensure that a TPM 2.0 is installed and activated on the host.
|
ESXi can use Trusted Platform Modules (TPM) to activate advanced security features that prevent malware, remove dependencies, and secure hardware life cycle operations. We recommend all servers be configured with a TPM 2.0 and the TPM be activated in the system firmware.
Note:
Activating TPM functionality deactivates Quick Boot, making patch cycles longer but forcing the system to go through the process of attestation to help prevent malware loading at boot. |
Ensure that all system and device firmware is auditable, authentic, and up to date.
|
Hardware firmware is not immune to serious issues affecting confidentiality, integrity, or availability. Vulnerable system management controllers and management engines can provide places for attackers to establish persistence, in order to re-infect and re-compromise hosts after reboots and updates. Ensure that the latest firmware updates are applied to all components of your systems and that the firmware is authentic and supplied by your hardware manufacturer.
Note:
If you are a vSAN customer please ensure that storage device & controller firmware versions are certified. |
Ensure that integrated hardware management controller internal, emulated, or virtual network interfaces are disabled.
|
Many servers have integrated hardware management controllers with the ability to present virtual network interfaces to ESXi as a management interface. These approaches create potential backdoors for access and are used by adversaries to circumvent network-based/perimeter firewalls, in either direction, and avoid observation by IDS/IPS/threat analysis tools. In many cases this functionality is not strictly necessary to manage hosts. |
Ensure that Intel Trusted Execution Technology is enabled in the system firmware, if available.
|
Intel Xeon Scalable Processor platforms have Trusted Execution Technology (TXT), that help harden systems against malware, rootkits, BIOS andfirmware attacks, and more. When enabled, ESXi will take advantage of security benefits offered by this technology.
Note:
Enabling early implementations of Intel TXT may cause operations like firmware updates and sudden system shutdowns to trigger attestation alarms in vCenter Server, or cause failures while booting. See VMware Knowledge Base Article 78243. |
Ensure that integrated hardware management controllers are fully secured.
|
Configure all integrated hardware management components to turn off all unused functionality and all unused access methods, to set passwords and password controlls, and to have firewall and access control in place. Ensure that the only access to the integrated hardware management components is from authorized access workstations for the virtualization administration team. All first boot configuration options must be disabled, especially ones that reconfigure the system through the use of inserted USB devices. Disable or protect USB ports attached to the management controllers. Where possible, USB ports should be set to only permit keyboards. Default passwords for accounts must be changed. Ensure that external information displays are secured to prevent information leaks. Ensure that power and information buttons are secured against unauthorized use. If there are no alternative methods set up in your environment, ensure that you use mechanism embedded in the hardware management controllers to monitor and alert for hardware faults and configuration changes. |
Configure NTP servers for the integrated hardware management controllers and ensure NTP servers are authorized per your organization's policies.
|
Configure the integrated hardware management controllers to synchronize internal system clocks by using redundant authoritative time sources. Ensure that all systems use the same relative time source (including the relevant localization offset), and that the relative time source can be correlated to an agreedupon time standard (such as Coordinated Universal Time—UTC). Cryptography, audit logging, cluster operations, and incident response/forensics depend on synchronized time. Ensure that you have at least four authorized time sources. |
Ensure that the use of centralized authentication sources for the integrated hardware management controllers does not create a dependency loop or an attack vector.
|
Connections to centralized authentication sources, like Active Directory, must be disabled or carefully considered as attack vectors and dependency loops (for authentication, authorization, DNS, DHCP, and NTP). Consider managing local accounts on these devices through the provided APIs and CLI interfaces. If you must use Active Directory for authentication, ensure local authorization to deny promotion through group membership for an attacker with access to Active Directory. |
Ensure that AMD Secure Encrypted Virtualization-Encrypted State is enabled in the system firmware, and is configured for a reasonable number of protected VMs (minimum SEV non-ES ASID), if available.
|
AMD EPYC platforms support Secure Encrypted Virtualization-Encrypted State (SEV-ES), a technology to encrypt memory and CPU register state, and limit visibility to the hypervisor, in order to increase workload security and decrease exposure to certain types of attacks. When configured properly, vSphere supports the use of SEV-ES inside guest virtual machines and containers under vSphere and vSphere with Tanzu.
Note:
Use of SEV-ES in a particular VMs requires the guest OS to support it, and will limit some operational features such as vMotion, snapshots, etc. |
Ensure that Intel Software Guard Extensions is enabled in the system firmware, if available.
|
Intel Xeon Scalable Processor platforms support Software Guard Extensions (SGX), a technology that helps applications protect data in system memory. When configured properly, vSphere supports the use of SGX inside guest virtual machines.
Note:
Use of SGX requires guest OS support, and will limit some operational features inside vSphere, such as vMotion, snapshots, fault tolerance, and suspend/resume. |
Ensure that unused external ports are disabled 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, access control, and/or with other means such as solid rack doors, rack side panels, and flooring that makes the ports inaccessible from outside the rack when the rack door is closed. Cables fit easily through many gaps in and around racks and rack doors, and stiff wires can be used to push them into sockets from outside the rack, as well as to dislodge cables to create a service disruption. Where possible, USB ports should also be set to only permit keyboards. When disabling functionality like this, consider that you may need to access the server using a USB keyboard during an outage or as part of lifecycle operations, and plan accordingly. |
