These security controls provide a baseline set of ESXi security best practices. They are structured in a way that explains the benefits and tradeoffs of implementing the control. Most controls are in the form of advanced system settings. To change advanced system settings, you can use either the PowerCLI provided, or the vSphere Client ().
Variable Used
The PowerCLI commands in this section use the following variables:
- $ESXi = "host_name"
- $vmkernel_interface = "vmkernel_adapter"
Ensure the DCUI Account Is Denied Access
The ESXi host must deny shell access for the dcui user account.
The dcui user account is used for process isolation for the DCUI itself. To reduce attack surface, deactivate shell access for the dcui user account.
Annotations.WelcomeMessage
Configures the text of the login message that is displayed on the VMware Host Client and the DCUI.
ESXi provides the ability to display a login message. Usages of the login message include informing intruders that their activities are illegal, and conveying to authorized users the expectations and obligations they must meet and agree to while using the system.
Config.HostAgent.vmacore.soap.sessionTimeout
Configures a session timeout for the vSphere API.
This practice helps mitigate potential security risks by ensuring that unattended sessions, which could be exploited by unauthorized users or malicious software, are not left open indefinitely.
Config.Etc.issue
Configures the text of the banner when a user connects to an ESXi host by using SSH.
ESXi provides the ability to display banner for SSH connections. Usages of the banner include informing intruders that their activities are illegal, and conveying to authorized users the expectations and obligations they must meet and agree to while using the system. Keep the SSH service deactivated unless you are performing troubleshooting operations. An implementation inconsistency between ESXi and vCenter Server requires that "issue" in Config.Etc.issue be lowercase, to work in both scenarios.
- PowerCLI Command Remediation Example
-
Get-VMHost -Name $ESXi | Get-AdvancedSetting Config.Etc.issue | Set-AdvancedSetting -Value "****************************************************************************`n* Authorized users only. Actual or attempted unauthorized use of this *`n* system is prohibited and may result in criminal, civil, security, or *`n* administrative proceedings and/or penalties. Use of this information *`n* system indicates consent to monitoring and recording, without notice *`n* or permission. Users have no expectation of privacy. Any information *`n* stored on or transiting this system, or obtained by monitoring and/or *`n* recording, may be disclosed to law enforcement and/or used in accordance *`n* with Federal law, State statute, and organization policy. If you are not *`n* an authorized user of this system, exit the system at this time. *`n****************************************************************************`n"
Deactivate Shell Access for vpxuser
The ESXi host must deny shell access for the vpxuser account.
vCenter Server creates the vpxuser account when an ESXi host is first attached. The vpxuser account is subsequently used for privileged authentication to ESXi. While vCenter Server automatically rotates the password for the vpxuser account on an interval governed by the VirtualCenter.VimPasswordExpirationInDays option, the vpxuser account also has shell access. Deactivate the vpxuser account to reduce attack surface.
- Potential Functional Impact if Default Value Is Changed
- User accounts that do not have shell access cannot reconfigure the shell access of other users, no matter their privilege levels. Because vCenter Server connects to an ESXi host as the vpxuser account, once you deactivate the shell access for vpxuser, it can no longer be used to change those account settings for other accounts. Further reconfiguration must occur on a host-by-host basis using an account that is authorized.
vCenter Server Must Use the vSphere Authentication Proxy to Avoid Storing Active Directory Credentials
The vSphere Authentication Proxy enables vCenter Server to connect to and manage Active Directory entities without the need to directly store Active Directory credentials, which reduces the risk of credential exposure or misuse.
DCUI.Access
The ESXi host must have an accurate DCUI.Access list.
Sets the Lockdown Mode Exception Users list to contain an accurate list of users, and ensures that only authorized users have direct console user interface (DCUI) access to the ESXi host when Lockdown Mode is activated.
You cannot remove the root user from the list.
To control ESXi Shell and SSH access, use the Lockdown Mode Exception Users list. See Ensure the ESXi Host Has an Accurate Exception Users List.
Ensure the ESXi Host Has an Accurate Exception Users List
The ESXi host must have an accurate Exception Users list.
Users on the Lockdown Mode Exception Users list do not lose their privileges when the host enters lockdown mode. This situation might possibly defeat the purpose of lockdown mode.
- Potential Functional Impact if Default Value Is Changed
- Potential loss of administrative access to ESXi hosts. Ensure that you attach ESXi hosts to vCenter Server, and that you configure access lists and exception lists before configuring lockdown mode.
Activate Normal Lockdown Mode to Restrict Access to ESXi
Activating lockdown mode deactivates direct access to an ESXi host. Lockdown mode requires vCenter Server to manage the ESXi host directly.
Restricting access in this way ensures that vCenter Server enforces roles and permissions. Also, users cannot bypass these roles and permissions by logging into an ESXi host directly. Requiring all interaction to occur through vCenter Server reduces the risk of users inadvertently attaining elevated privileges or performing tasks for which they are not properly audited.
Users listed in the Exception Users list for each ESXi host are allowed to override lockdown mode and log in. By default, no users are present on the Exception Users list.
The lockdown mode settings are Disabled, Normal, and Strict. When lockdown mode is set to Strict, if the ESXi host loses contact with vCenter Server, you cannot manage it until that connection is restored. If you cannot restore the connection, you must rebuild the ESXi host. In general, Strict lockdown mode exceeds the needs of most deployments. As such, Normal lockdown mode typically suffices.
- Potential Functional Impact if Default Value Is Changed
- Potential loss of administrative access to hosts. Ensure that you attach ESXi hosts to vCenter Server, and that you configure access lists and exception lists before configuring lockdown mode.
Syslog.global.auditRecord.storageEnable
Configures the ESXi host to store audit records locally.
You must activate audit record logging on ESXi hosts.
- Potential Functional Impact if Default Value Is Changed
- Additional storage space is consumed by logs.
Syslog.global.auditRecord.storageCapacity
You must activate storage capacity for one week of audit records on ESXi hosts.
If a remote audit record storage facility is available, it is essential to ensure that the local storage capacity is sufficient to hold audit records that can accumulate during anticipated interruptions in the delivery of records to the facility. This ensures that audit records are not lost or overwritten during periods when the remote storage is unavailable, allowing for seamless continuity of the audit trail and compliance requirements.
- Potential Functional Impact if Default Value Is Changed
- Additional storage space is consumed by logs.
ScratchConfig.CurrentScratchLocation and Syslog.global.auditRecord.storageDirectory
Configures a persistent log location for all locally stored audit records on the ESXi host.
You can configure ESXi to store audit records on an in-memory file system. This occurs when the "/scratch" directory of the host is linked to "/tmp/scratch." When this is done, only a single day's worth of records are stored at any time. In addition, audit records are reinitialized upon each reboot. This presents a security risk as user activity logged on the host is only stored temporarily and does not persistent across reboots. This can also complicate auditing and make it harder to monitor events and diagnose issues. Always configure ESXi host audit record logging to a persistent datastore.
You can detect if the scratch volume is temporary or persistent by querying the ScratchConfig.CurrentScratchLocation advanced setting. If, when queried, it returns "/tmp/scratch," then the volume is temporary and you should remap the audit record storage to a persistent device.
The storage cannot be a vSAN datastore. If your only local, non-vSAN storage is SD or USB media (which can become unreliable with repeated writes from logs), consider leaving the logs in the ramdisk and ensuring that a remote logging host is configured instead. Document the decision and rationale in preparation for future audits.
- Values
-
Installation Default Value:
ScratchConfig.CurrentScratchLocation: Depends on boot device
Syslog.global.auditRecord.storageDirectory: /scratch/auditLog
- Potential Functional Impact if Default Value Is Changed
- Additional storage space is consumed by logs.
- PowerCLI Command Assessment
-
$ESXcli = Get-EsxCli -VMHost $ESXi -V2 $ESXcli.system.syslog.config.get.Invoke() | Select LocalLogOutput,LocalLogOutputIsPersistent # If your LocalLogOutput is set to a directory in /scratch, and LocalLogOutputIsPersistent is true, that means your boot device is of a type and size that makes /scratch persistent. Verify that your audit storage is also on /scratch, and that /scratch points to a VMFS datastore: Get-VMHost -Name $ESXi | Get-AdvancedSetting ScratchConfig.CurrentScratchLocation Get-VMHost -Name $ESXi | Get-AdvancedSetting Syslog.global.auditRecord.storageDirectory
Syslog.global.auditRecord.remoteEnable
Configures the ESXi host for transmission of audit logs to a remote host.
Syslog.global.logFiltersEnable
Activates log filtering on the ESXi host.
You can create log filters to reduce the number of repetitive entries, and to deny specific log events entirely.
LocalLogOutputIsPersistent, ScratchConfig.CurrentScratchLocation, and Syslog.global.logDir
Configures persistent logging for all locally stored logs on the ESXi host.
You can configure ESXi to store log files on an in-memory file system. This occurs when the "/scratch" directory of the host is linked to "/tmp/scratch." When this is done, only a single day's worth of logs is stored at any time. Additionally, log files are reinitialized upon each reboot. This presents a security risk as user activity logged on the host is only stored temporarily and does not persist across reboots. It can also complicate auditing and make it harder to monitor events and diagnose issues. Always configure ESXi host logging to a persistent datastore.
You can detect if the scratch volume is temporary or persistent by querying the ScratchConfig.CurrentScratchLocation advanced parameter. If, when queried, it returns "/tmp/scratch," then the volume is temporary and you should remap the audit record storage to a persistent device.
The storage cannot be a vSAN datastore, unless you set Syslog.global.vsanBacking, which has caveats and dependencies. If your only local, non-vSAN storage is SD or USB media (which can become unreliable with repeated writes from logs), consider leaving the logs in the ramdisk and ensuring that a remote logging host is configured instead. Document the decision and rationale in preparation for future audits.
- Values
-
Installation Default Value: ScratchConfig.CurrentScratchLocation: Depends on boot device
Syslog.global.logDir: /scratch/log
- PowerCLI Command Assessment
-
$ESXcli = Get-EsxCli -VMHost $ESXi -V2 $ESXcli.system.syslog.config.get.Invoke() | Select LocalLogOutput,LocalLogOutputIsPersistent # If your LocalLogOutput is set to a directory in /scratch, and LocalLogOutputIsPersistent is true, that means your boot device is of a type and size that makes /scratch persistent. Verify that your log storage is also on /scratch, , and that /scratch points to a VMFS datastore: Get-VMHost -Name $ESXi | Get-AdvancedSetting ScratchConfig.CurrentScratchLocation Get-VMHost -Name $ESXi | Get-AdvancedSetting Syslog.global.logDir
Syslog.global.logHost
Configures remote logging.
When you configure remote logging to a central log host, you provide a secure, centralized store for ESXi logs. Gathering host log files onto a central host gives you the ability to monitor all hosts with a single tool. You can also perform aggregate analysis and search for items such as coordinated attacks on multiple hosts. Logging to a secure, central log server helps prevent log tampering and also provides a long-term audit record.
Syslog.global.certificate.checkSSLCerts
Verifies certificates for TLS.
The ESXi host must verify certificates for TLS remote logging endpoints. TLS certificates help ensure that the endpoint is authentic and trustworthy.
Syslog.global.certificate.strictX509Compliance
Performs strict x509 verification for TLS-enabled remote logging endpoints.
The ESXi host must use strict x509 verification for TLS-enabled remote logging endpoints. The Syslog.global.certificate.strictX509Compliance setting performs additional validity checks on CA root certificates during verification.
Mem.MemEagerZero
Activates volatile key destruction.
By default, ESXi zeroes out pages allocated for virtual machines, userspace applications, and kernel threads at the time of allocation. This ensures that no non-zero pages are exposed to virtual machines or userspace applications. This measure is in place to prevent the exposure of cryptographic keys from virtual machines or userworlds to other clients.
However, if memory is not reused, these keys can remain present in host memory for an extended period. To address this, you can configure the MemEagerZero setting to enforce the zeroing out of userworld and guest memory pages when a userworld process or guest exits. For kernel threads, memory spaces holding keys are zeroed out as soon as the secret is no longer required.
Check for Active Maintenance on the ESXi Version
Ensure that the ESXi version has not reached VMware End of General Support status.
Activate Time Synchronization Sources
The ESXi host must have time synchronization services activated and running.
Cryptography, audit logging, cluster operations, and incident response and forensics rely on synchronized time. To ensure time is synchronized across services and operations, activate NTP and/or PTP services to start with the host, and ensure that those services are running.
Configure Reliable Time Synchronization Sources
The ESXi host must have reliable time synchronization sources configured.
Cryptography, audit logging, cluster operations, and incident response and forensics depend on synchronized time. Network Time Protocol (NTP) must have at least four sources. If you must choose between two sources and one source, one source is preferable.
Precision Time Protocol (PTP) is an alternative to NTP that provides sub-millisecond time accuracy. The architecture of PTP is different than NTP, and does not have the same resilience to primary server failure. Consider configuring NTP as a backup source to PTP so that a time source continues to be available, even if the accuracy is less.
Use TLS Ciphers
The ESXi host must maintain confidentiality and integrity of transmissions by enabling modern TLS ciphers.
Starting in ESXi 8.0 Update 3, TLS profiles configure client and server TLS settings to use only strong ciphers. You can view the entire cipher list and suites by using the following commands:
$ESXcli = Get-EsxCli -VMHost $ESXi -V2 $arguments = $ESXcli.system.tls.server.get.CreateArgs() $arguments.showprofiledefaults = $true $arguments.showcurrentbootprofile = $true $ESXcli.system.tls.server.get.invoke($arguments)
You must reboot the ESXi host after making changes to the TLS profile. (In the vSphere Client, the host displays the suffix of "Reboot Required.")
- Potential Functional Impact if Default Value Is Changed
- Changes to cipher suites impact connectivity with external systems. You must reboot the host for this TLS profile change to take effect.
UserVars.ESXiVPsDisabledProtocols
The ESXi host must enable the highest version of TLS supported.
ESXi 8.0 activates TLS 1.2 by default, but it is possible to activate other protocols if necessary. Starting with ESXi 8.0 Update 3, TLS 1.3 is activated by default.
Configure TPM-Based Encryption
The ESXi host must require TPM-based configuration encryption.
The configuration of an ESXi host consists of configuration files for each service that runs on the host. The configuration files typically reside in the /etc directory, but they can also reside in other namespaces. The configuration files contain run-time information about the state of the services. Over time, the default values in the configuration files might change, for example, when settings on the ESXi host are changed.
A cron job backs up the ESXi configuration files periodically, when ESXi shuts down gracefully or on demand, and creates an archived configuration file in the boot bank. When ESXi reboots, the system reads the archived configuration file and recreates the state that ESXi was in when the backup was taken.
Before vSphere 7.0 Update 2, the archived ESXi configuration file is not encrypted. In vSphere 7.0 Update 2 and later, the archived configuration file is encrypted. When the ESXi host is configured with a Trusted Platform Module (TPM), the TPM is used to "seal" the configuration to the host, providing a strong security guarantee and additional protection from offline attacks.
Configuration encryption uses the physical TPM when it is available and supported at install or upgrade time. If the TPM was added or enabled later, you must explicitly reconfigure the ESXi host to use the newly available TPM. Once the TPM configuration encryption is enabled, it cannot be deactivated.
- Potential Functional Impact if Default Value Is Changed
- Use of Secure Boot and TPM-enforced configuration encryption render traditional root password recovery efforts unusable. Ensure that you do not lose access to ESXi administrator accounts.
Check that ESXi Software Is Up-to-date
By staying current on ESXi patches, you mitigate vulnerabilities in the hypervisor.
An educated attacker can exploit known vulnerabilities when attempting to access or elevate privileges on an ESXi host. Always update vCenter Server first, if an update is available, then update ESXi.
VMkernel.Boot.execInstalledOnly
Run binaries that are only delivered by a VIB.
ESXi conducts integrity checks of VIBs based upon the Acceptance Level. Instructing ESXi to only execute binaries that originate from a valid VIB installed on the host makes it harder for attackers to use pre-built toolkits during a compromise, and increases chances of detection.
- Potential Functional Impact if Default Value Is Changed
- Third-party unsigned software might not install or execute.
Deactivate Management Services on VMkernel Adapters
Ensure that vSAN, vMotion, and other dedicated VMkernel adapters do not have management services activated.
VMkernel network interfaces that are intended for specialized use can be configured with management capabilities, which might defeat network isolation and security efforts. Only enable management services on VMkernel interfaces that are intended for management.
- Potential Functional Impact if Default Value Is Changed
- Some third-party managed solutions might require that you activate management servcies on VMkernel adapters.
Configure the ESXi Firewall to Block Traffic
You must configure the ESXi host firewall to block network traffic by default.
Ensure that all incoming and outgoing network traffic is blocked unless explicitly allowed, reducing the attack surface and preventing unauthorized access to the host.
Configure the ESXi Firewall for Authorized Networks
Configure the ESXi firewall to allow traffic only from authorized networks.
Ensure that all incoming and outgoing network traffic is blocked unless explicitly allowed, reducing the attack surface and preventing unauthorized access to the ESXi host.
Starting in vSphere 8.0 Update 2, firewall rules are categorized as 'user' or 'system' owned, where only 'user' owned rules are configurable. In vSphere 8 Update 2b and PowerCLI 13.2.1, there are additional queryable parameters to automate setting and checking for configurable rules.
- Potential Functional Impact if Default Value Is Changed
- Firewall is simplistic, akin to router ACLs. You might need to reconfigure reflexive rules.
- PowerCLI Command Assessment
-
$ESXcli = Get-EsxCli -VMHost $ESXi -V2 $list = $ESXcli.network.firewall.ruleset.list.Invoke() | Where {($_.AllowedIPconfigurable -eq $true) -and ($_.EnableDisableconfigurable -eq $true)} | Select -ExpandProperty Name $arguments = $ESXcli.network.firewall.ruleset.allowedip.list.CreateArgs() foreach ($rule in $list) { $arguments.rulesetid = $rule $ESXcli.network.firewall.ruleset.allowedip.list.Invoke($arguments) }
- PowerCLI Command Remediation Example
-
# Customize this example for your environment. $ESXcli = Get-EsxCli -VMHost $ESXi -V2 # Deactivate firewall temporarily so we don't lose connectivity $arguments = $ESXcli.network.firewall.set.CreateArgs() $arguments.enabled = $false $ESXcli.network.firewall.set.Invoke($arguments) # Unset the "allow all" flag $arguments = $ESXcli.network.firewall.ruleset.set.CreateArgs() $arguments.allowedall = $false $arguments.rulesetid = "sshServer" $ESXcli.network.firewall.ruleset.set.Invoke($arguments) # Add an IP range $arguments = $ESXcli.network.firewall.ruleset.allowedip.add.CreateArgs() $arguments.ipaddress = "192.168.0.0/16" $arguments.rulesetid = "sshServer" $ESXcli.network.firewall.ruleset.allowedip.add.Invoke($arguments) # Enable the firewall $arguments = $ESXcli.network.firewall.set.CreateArgs() $arguments.enabled = $true $ESXcli.network.firewall.set.Invoke($arguments)
Set the Forged Transmits Policy to Reject
Set the Forged Transmits policy to Reject on both the vSphere Standard Switch and its port groups.
If the virtual machine operating system changes the MAC address, the operating system can send frames with an impersonated source MAC address at any time. MAC address impersonation allows an operating system to stage malicious attacks on the devices in a network by impersonating a network adaptor authorized by the receiving network. When the Forged Transmits policy is set to Accept, ESXi does not compare source and effective MAC addresses. To protect against MAC impersonation, set the Forged Transmits policy to Reject. The host then compares the source MAC address being transmitted by the guest operating system with the effective MAC address for its virtual machine adapter for a match. If the addresses do not match, the ESXi host drops the packet.
- Potential Functional Impact if Default Value Is Changed
- Some workloads, such as clustered applications and network devices and functions, rely on these techniques as a normal part of their operation. If needed, you can configure a separate port group that permits this behavior, and attach only authorized virtual machines to it.
Set the MAC Address Changes Policy to Reject
Set the MAC Address Changes policy to Reject on both the vSphere Standard Switch and its port groups.
If the virtual machine operating system changes the MAC address, it can send frames with an impersonated source MAC address, enabling it to stage malicious attacks on devices within a network by impersonating a network adapter authorized by the receiving network. To prevent virtual machines from changing their effective MAC address, measures should be taken to enforce MAC address stability or restrict the ability to modify MAC addresses. This helps mitigate the risk of MAC impersonation and potential malicious activities.
- Potential Functional Impact if Default Value Is Changed
- Some workloads, such as clustered applications, network devices and functions, applications licensed by MAC address, and vCenter Server Reduced Downtime Upgrade, rely on these techniques as a normal part of their operation. If needed, you can configure a separate port group that permits this behavior, and attach only authorized virtual machines to it.
Set the Promiscuous Mode Policy to Reject
Set the Promiscuous Mode policy to Reject on both the vSphere Standard Switch and its port groups.
When promiscuous mode is enabled for a port group, all virtual machines connected to that port group have the potential to read all packets transmitted across that port group, regardless of the intended recipient. Consider the potential impact and design considerations before changing the default value of promiscuous mode.
- Potential Functional Impact if Default Value Is Changed
- Certain workloads and types of work, such as DHCP servers, network devices, and security monitoring, incorporate these techniques as a regular part of their operation. If needed, you can configure a separate port group that permits this behavior, and attach only authorized virtual machines to it.
Restrict Virtual Guest Tagging on Standard Switches
The ESXi host must restrict the use of Virtual Guest Tagging (VGT) on Standard Switches.
When a port group is set to VLAN 4095, the vSwitch passes all network frames to the attached virtual machines without modifying the VLAN tags. In vSphere, this is referred to as VGT. The virtual machine must process the VLAN information itself by using an 802.1Q driver in the operating system.
VLAN 4095 must only be implemented if the attached virtual machines have been specifically authorized and are capable of managing VLAN tags themselves. If VLAN 4095 is enabled inappropriately, it might cause denial of service or allow a virtual machine to interact with traffic on an unauthorized VLAN.
Activate Secure Boot Enforcement
Secure Boot is part of the UEFI firmware standard. With UEFI Secure Boot activated, an ESXi host refuses to load any UEFI driver or app unless the operating system bootloader has a valid digital signature. Secure Boot for ESXi requires support from the firmware. Secure Boot for ESXi also requires that all ESXi kernel modules, drivers, and VIBs be signed by VMware or a partner subordinate.
Secure Boot is activated in the BIOS of the ESXi physical server and supported by the hypervisor boot loader. This control flips ESXi from merely supporting Secure Boot to requiring it. Without this setting activated, and configuration encryption, an ESXi host could be subject to offline attacks. An attacker could simply transfer the ESXi install drive to a non-Secure Boot host and boot.
- Potential Functional Impact if Default Value Is Changed
- Use of Secure Boot and TPM-enforced configuration encryption render traditional root password recovery efforts unusable. Ensure that you do not lose access to ESXi administrator accounts.
Deactivate the ESXi Shell
The ESXi Shell should be deactivated.
UserVars.ESXiShellInteractiveTimeOut
Sets a timeout to automatically terminate idle ESXi Shell and SSH sessions.
If users forget to log out of their SSH session, the idle connection remains open indefinitely, increasing the potential for other users to gain privileged access to the host. You can configure idle shell sessions to terminate automatically.
Deactivate the SNMP Service
Deactivate the SNMP service if you are not using it.
Deactivate the SSH Service
Deactivate SSH, and activate it only for troubleshooting.
ESXi is not a UNIX-like multi-user operating system. ESXi is a purpose-built hypervisor intended to be managed by the VMware Host Client, the vSphere Client, the CLIs, and the APIs. On ESXi, SSH is a troubleshooting and support interface, and is intentionally stopped and deactivated by default. Activation of the interface brings risk.
Use Entropy for Cryptographic Operations
The ESXi host must use sufficient entropy for cryptographic operations.
In vSphere 8.0 and later, the ESXi Entropy implementation supports the FIPS 140-3 and EAL4 certifications. Kernel boot options control which entropy sources to activate on an ESXi host.
- PowerCLI Command Assessment
-
$ESXcli = Get-EsxCli -VMHost $ESXi -V2 $ESXcli.system.settings.kernel.list.Invoke() | Where {$_.Name -eq "disableHwrng" -or $_.Name -eq "entropySources"}
- PowerCLI Command Remediation Example
-
$ESXcli = Get-EsxCli -VMHost $ESXi -V2 $arguments = $ESXcli.system.settings.kernel.set.CreateArgs() $arguments.setting = "disableHwrng" $arguments.value = "FALSE" $ESXcli.system.settings.kernel.set.invoke($arguments) $arguments.setting = "entropySources" $arguments.value = "0" $ESXcli.system.settings.kernel.set.invoke($arguments)
Verify the Image Profile and the VIB Acceptance Levels
The ESXi host image profile acceptance level must be PartnerSupported or higher.
The acceptance level controls what ESXi permits to be installed. See Manage the Acceptance Levels of ESXi Hosts and vSphere Installation Bundles for the VIB levels.
Neither VMware nor VMware partners test CommunitySupported VIBs, nor do CommunitySupported VIBs contain a digital signature. For these reasons, exercise caution when installing CommunitySupported VIBs.
Security.AccountUnlockTime
The ESXi host must unlock accounts after a specified timeout period.
Security.AccountUnlockTime ensures that user accounts on ESXi host are automatically unlocked after a defined period of inactivity. By enforcing automatic account unlocking, organizations can maintain a balance between security and usability, ensuring that idle accounts are reactivated promptly while minimizing the potential for unauthorized access.
Security.AccountLockFailures
Sets the count of maximum failed login attempts before the account is locked out.
Protects against brute-force attacks and unauthorized access attempts by temporarily disabling the affected account, preventing further login attempts until the lockout period expires or is manually reset by an administrator. To unlock a locked account requires either administrative action or waiting for the account to automatically unlock if the Security.AccountUnlockTime setting is used.
- Potential Functional Impact if Default Value Is Changed
- A low threshold for login failures can potentially increase denial-of-service attacks, whether intentional or unintentional, such as with SSH connection retries.
Security.PasswordHistory
Does not permit password reuse.
This setting prevents the reuse of previous passwords, thus mitigating potential breaches from old, compromised credentials.
Security.PasswordMaxDays
Sets the maximum number of days between password changes.
Modern best practices for passwords, as outlined in NIST 800-63B Section 5.1.1.2 and other relevant guidance, state that enforcing periodic password changes does not enhance security when passwords already possess adequate entropy.
Security.PasswordQualityControl
Enforces password complexity.
Recommendations such as NIST 800-63B Section 5.1.1.2 suggest that composition rules, for example, mandating mixtures of character classes, should not be enforced on systems as they often fail to enhance password security and discourage the adoption of more secure passphrases.
Password strength and complexity rules are applicable to all ESXi users, including the root user. However, when the ESXi host is joined to a domain, these rules do not apply to Active Directory (AD) users because password policies for AD users are enforced by the AD system.
- Potential Functional Impact if Default Value Is Changed
- Other products and services within the VMware ecosystem might not expect changes to password complexity requirements and might fail installation.
UserVars.SuppressHyperthreadWarning
Suppresses the warning for a potential hyperthreading security vulnerability.
Hyperthreading security warnings signify unaddressed CPU vulnerabilities in the system. Ignoring these warnings could mask potential risks. Ensure that hardware remediations align with accepted risk of your organization. When you do suppress a warning, document the decision and rationale.
UserVars.DcuiTimeOut
Sets a timeout to automatically terminate idle DCUI sessions.
DCUI allows direct login to the ESXi host for management tasks. To prevent unintended DCUI usage from leftover login sessions, terminate idle connections.
Deactivate CIM Service
The ESXi CIM service should be deactivated.
Services that are not in use and are non-essential for operations should be deactivated.
Config.HostAgent.log.level
Sets the logging informational level.
When setting the log level, ensure that enough information is present in audit logs to conduct diagnostics and forensics.
Syslog.global.logLevel
Logs sufficient information for events.
Without sufficient log data, critical indicators of compromise can go unnoticed, leading to increased vulnerability and potential failure to respond effectively to cybersecurity incidents.
Config.HostAgent.plugins.solo.enableMob
Deactivates the Managed Object Browser (MOB).
Services that are not in use and are non-essential for operations should be deactivated.
Net.BlockGuestBPDU
Blocks guest operating system Bridge Protocol Data Unit (BPDU) transmissions.
BPDUs are used to transmit Spanning Tree Protocol (STP) information and detect network loops. BPDU Guard and Portfast are commonly activated on the physical switch directly connected to the ESXi host to reduce spanning tree convergence delay.
However, if a BPDU packet is sent from a virtual machine on the ESXi host to the configured physical switch, it can result in a cascading lockout of all uplink interfaces from the ESXi host. To prevent this type of lockout, you can activate the BPDU Filter on the ESXi host to drop any BPDU packets being sent to the physical switch.
Standard and Distributed Virtual Switches do not support STP and do not generate BPDUs.
- Potential Functional Impact if Default Value Is Changed
- Some network-oriented workloads can legitimately generate BPDU packets. Verify that there are no legitimate BPDU packets generated by virtual machines on the ESXi host prior to enabling BPDU Filter. If BPDU Filter is activated in this situation, enabling Reject Forged Transmits on the virtual switch port group adds protection against Spanning Tree loops.
Net.DVFilterBindIpAddress
Restricts the use of the dvFilter network APIs.
If you do not use a product such as VMware NSX that utilizes the dvFilter network API, do not configure the ESXi host to send network information to an IP address. Enabling the API and referencing an IP address that is compromised could potentially provide unauthorized access to the network of other virtual machines on the ESXi host.
If you are using a product that relies on this API, it is important to verify that the ESXi host has been configured correctly to ensure secure network communication.
UserVars.ESXiShellTimeOut
Sets a timeout to limit how long the ESXi Shell and SSH services are allowed to run.
This advanced system setting defines a window of time after which the ESXi Shell and SSH services are automatically terminated.
UserVars.SuppressShellWarning
Suppresses the warning for support and troubleshooting interfaces.
The ESXi host must not suppress warnings that the ESXi Shell is activated.
Warnings indicating that SSH or the ESXi Shell is activated can be clues that an attack is in progress. It is important to ensure that SSH and the ESXi Shell are deactivated, and that this advanced system setting is not activated.
Configure the ESXi Secure Shell Daemon for FIPS
The ESXi host Secure Shell (SSH) daemon must be configured to only use FIPS 140-2/140-3 validated ciphers. You must harden and secure system services when they are activated.
- Values
- Installation Default Value: aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
- PowerCLI Command Assessment
-
$ESXcli = Get-EsxCli -VMHost $ESXi -V2 $ESXcli.system.ssh.server.config.list.invoke() | Where-Object {$_.Key -eq 'ciphers'} | Select-Object -ExpandProperty Value
- PowerCLI Command Remediation Example
-
$ESXcli = Get-EsxCli -VMHost $ESXi -V2 $arguments = $ESXcli.system.ssh.server.config.set.CreateArgs() $arguments.keyword = 'ciphers' $arguments.value = 'aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr' $ESXcli.system.ssh.server.config.set.Invoke($arguments)
Configure the ESXi SSH Daemon for FIPS
The ESXi host SSH daemon must use FIPS 140-2/140-3 validated cryptographic modules.
OpenSSH on the ESXi host ships with a FIPS 140-2/140-3 validated cryptographic module, activated by default. For backward compatibility reasons, you can deactivate this module. Audit and correct if necessary.
Configure the ESXi Secure Shell Daemon to Not Allow Gateway Ports
The ESXi host Secure Shell (SSH) daemon must be configured to not allow gateway ports.
You must harden and secure system services when activated.
Configure the ESXi Secure Shell Daemon to Not Use Host-Based Authentication
The ESXi host Secure Shell (SSH) daemon must not allow host-based authentication.
You must harden and secure system services when activated.
Configure the ESXi Secure Shell Daemon to Set a Timeout Count
The ESXi host Secure Shell (SSH) daemon must set a timeout count on idle sessions.
You must harden and secure system services when activated. The timeout count, multiplied by the idle timeout interval, is the total number of seconds the session can be idle until it is disconnected.
Configure the ESXi Secure Shell Daemon to Set a Timeout Interval
The ESXi host Secure Shell (SSH) daemon must set a timeout count on idle sessions.
You must harden and secure system services when activated. The timeout count, multiplied by the idle timeout interval, is the total number of seconds the session may be idle until it is disconnected.
Configure the ESXi Secure Shell Daemon to Display a Login Banner
The ESXi host Secure Shell (SSH) daemon must display the system login banner before granting access to the system.
You must harden and secure system services when activated. You must set the Config.Etc.issue setting as well, to provide text to this banner.
Configure the ESXi Secure Shell Daemon to Ignore .rhosts Files
The ESXi host Secure Shell (SSH) daemon must ignore .rhosts files.
You must harden and secure system services when activated.
Configure the ESXi Secure Shell Daemon to Deactivate Stream Local Forwarding
The ESXi host Secure Shell (SSH) daemon must deactivate stream local forwarding.
You must harden and secure system services when activated.
Configure the ESXi Secure Shell Daemon to Deactivate TCP Forwarding
The ESXi host Secure Shell (SSH) daemon must deactivate TCP forwarding.
You must harden and secure system services when activated.
Configure the ESXi Secure Shell Daemon to Not Permit Tunnels
The ESXi host Secure Shell (SSH) daemon must not permit tunnels.
You must harden and secure system services when activated.
Configure the ESXi Secure Shell Daemon to Not Permit User Environment Settings
The ESXi host Secure Shell (SSH) daemon must not permit user environment settings.
You must harden and secure system services when activated.
Deactivate the Service Location Protocol Service
Deactivate the Service Location Protocol (SLP) service if you are not using it.
Mem.ShareForceSalting
Restricts transparent page sharing to virtual machines that are configured with sched.mem.pshare.salt.
Transparent Page Sharing (TPS) is a method to reduce the memory footprint of virtual machines. Under highly controlled conditions, attackers can use TPS to gain unauthorized access to data on neighboring virtual machines. Virtual machines that do not have the sched.mem.pshare.salt setting configured cannot share memory with other virtual machines. Large page sizes, a performance optimization in the hypervisor on many modern CPUs, is incompatible with TPS.
UserVars.HostClientSessionTimeout
Sets a timeout to automatically terminate idle ESXi host client sessions.
The ESXi host must automatically terminate idle host client sessions. This practice helps mitigate potential security risks by ensuring that unattended sessions, which could be exploited by unauthorized users or malicious software, are not left open indefinitely.
Net.BMCNetworkEnable
Deactivates virtual hardware management network interfaces.
Hardware management controllers often present virtual or USB NICs to the ESXi host. These can be used as backdoors and should be deactivated both in the hardware configuration and in the ESXi configuration.
Activate Bidirectional/Mutual CHAP Authentication for iSCSI Traffic
Set the iSCSI storage adapter authentication to "Use bidirectional CHAP" and supply credentials.
Mutual CHAP provides an additional layer of protection by requiring both the initiator (client) and the target (server) to verify their identities to each other, thereby ensuring data transmitted between the two is not intercepted or altered by unauthorized entities.
Do Not Store Encryption Keys on ESXi Hosts Without Securing Physical Access
The ESXi host must not store encryption keys on the ESXi host itself without securing physical access to the host.
Key Persistence is a mechanism that uses a local Trusted Platform Module (TPM) to store Standard Key Provider keys, usually found only in an external Key Management System (KMS). While this setup can improve the management of dependencies, using Key Persistence changes the encryption risks. If an attacker steals the host, they have access to the encryption keys for data on that host, bypassing the access controls of the external KMS. Therefore, only use Key Persistence when you can assure the physical security of your hosts. If the physical hosts are not secure and an attacker can steal the host, the attacker also has the means to access and use encrypted workloads.
Key Persistence and vSphere Native Key Provider are often conflated because both store encryption data on hosts. However, the vSphere Native Key Provider does not use Key Persistence, so turning off Key Persistence does not affect it. Like Key Persistence, the vSphere Native Key Provider also requires careful consideration of physical security. See vSphere System Design Security Controls Reference.
- Potential Functional Impact if Default Value Is Changed
- Default is the desired behavior. Change away from the default might negatively impact confidentiality in environments where physical access by attackers is possible.
