Cyber · Trackr The Free Compliance Library
⌘K
DoD Compliance · STIG

VMware vSphere 8.0 ESXi Security Technical Implementation Guide

V2R1 · · · Released 01 Aug 2024 · 77 rules
Compare

Pick two releases to diff their requirements.

View

Open a previous version of this STIG.

This Security Technical Implementation Guide is published as a tool to improve the security of Department of Defense (DOD) information systems. The requirements are derived from the National Institute of Standards and Technology (NIST) 800-53 and related documents. Comments or proposed revisions to this document should be sent via email to the following address: disa.stig_spt@mail.mil.
Digest of Updates vs. V1R1 · 31 Oct 2023 +4 ✎ 10

Comparison against the immediately-prior release (V1R1). Rule matching uses the Group Vuln ID. Content-change detection compares the rule’s description, check, and fix text after stripping inline markup — cosmetic-only edits aren’t flagged.

Added rules 4

  • V-265974 Medium The ESXi host must use DOD-approved encryption to protect the confidentiality of network sessions.
  • V-265975 Medium The ESXi host must disable key persistence.
  • V-265976 Medium The ESXi host must deny shell access for the dcui account.
  • V-265977 Medium The ESXi host must disable virtual hardware management network interfaces.

Content changes 10

  • V-258739 Medium check The ESXi host must set a timeout to automatically end idle shell sessions after fifteen minutes.
  • V-258741 Medium checkfix The ESXi host must enable Secure Boot.
  • V-258742 Medium check The ESXi host must enforce an unlock timeout of 15 minutes after a user account is locked out.
  • V-258756 Medium check The ESXi host must automatically stop shell services after 10 minutes.
  • V-258757 Medium check The ESXi host must set a timeout to automatically end idle DCUI sessions after 10 minutes.
  • V-258769 Medium checkfix The ESXi host must configure the firewall to block network traffic by default.
  • V-258779 Medium checkfix The ESXi host must verify certificates for SSL syslog endpoints.
  • V-258787 Medium fix The ESXi host must enable audit logging.
  • V-258794 Medium checkfix The ESXi host must configure the firewall to restrict access to services running on the host.
  • V-258797 Medium fix The ESXi host must configure a persistent log location for all locally stored logs.
Sort by
b
The ESXi host must enforce the limit of three consecutive invalid logon attempts by a user.
AC-7 - Medium - CCI-000044 - V-258728 - SV-258728r958388_rule
RMF Control
AC-7
Severity
M
CCI
CCI-000044
Version
ESXI-80-000005
Vuln IDs
  • V-258728
Rule IDs
  • SV-258728r958388_rule
By limiting the number of failed logon attempts, the risk of unauthorized access via user password guessing, otherwise known as brute forcing, is reduced. Once the configured number of attempts is reached, the account is locked by the ESXi host.
Checks: C-62468r933243_chk

From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host >> Configure >> System >> Advanced System Settings. Select the "Security.AccountLockFailures" value and verify it is set to "3". or From a PowerCLI command prompt while connected to the ESXi host, run the following command: Get-VMHost | Get-AdvancedSetting -Name Security.AccountLockFailures If the "Security.AccountLockFailures" setting is set to a value other than "3", this is a finding.

Fix: F-62377r933244_fix

From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host >> Configure >> System >> Advanced System Settings. Click "Edit". Select the "Security.AccountLockFailures" value and configure it to "3". or From a PowerCLI command prompt while connected to the ESXi host, run the following command: Get-VMHost | Get-AdvancedSetting -Name Security.AccountLockFailures | Set-AdvancedSetting -Value 3

b
The ESXi host must display the Standard Mandatory DOD Notice and Consent Banner before granting access to the system via the Direct Console User Interface (DCUI).
AC-8 - Medium - CCI-000048 - V-258729 - SV-258729r958390_rule
RMF Control
AC-8
Severity
M
CCI
CCI-000048
Version
ESXI-80-000006
Vuln IDs
  • V-258729
Rule IDs
  • SV-258729r958390_rule
Display of a standardized and approved use notification before granting access to the host ensures privacy and security notification verbiage used is consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance. System use notifications are required only for access via logon interfaces with human users and are not required when such human interfaces do not exist. The banner must be formatted in accordance with applicable DOD policy. Use the following verbiage for a host that can accommodate banners of 1300 characters: "You are accessing a U.S. Government (USG) VMM (IS) that is provided for USG-authorized use only. By using this IS (which includes any device attached to this IS), you consent to the following conditions: -The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations. -At any time, the USG may inspect and seize data stored on this IS. -Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose. -This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy. -Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details." Use the following verbiage for VMMs that have severe limitations on the number of characters that can be displayed in the banner: "I've read (literal ampersand) consent to terms in IS user agreem't." Satisfies: SRG-OS-000023-VMM-000060, SRG-OS-000024-VMM-000070
Checks: C-62469r933246_chk

From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host >> Configure >> System >> Advanced System Settings. Select the "Annotations.WelcomeMessage" value and verify it contains the standard mandatory DOD notice and consent banner. or From a PowerCLI command prompt while connected to the ESXi host, run the following command: Get-VMHost | Get-AdvancedSetting -Name Annotations.WelcomeMessage If the "Annotations.WelcomeMessage" setting does not contain the standard mandatory DOD notice and consent banner, this is a finding.

Fix: F-62378r933247_fix

From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host >> Configure >> System >> Advanced System Settings. Click "Edit". Select the "Annotations.WelcomeMessage" value and set it to the following. Click "OK". {bgcolor:black} {/color}{align:left}{bgcolor:black}{color:yellow}{hostname} , {ip}{/color}{/bgcolor}{/align} {bgcolor:black} {/color}{align:left}{bgcolor:black}{color:yellow}{esxproduct} {esxversion}{/color}{/bgcolor}{/align} {bgcolor:black} {/color}{align:left}{bgcolor:black}{color:yellow}{memory} RAM{/color}{/bgcolor}{/align} {bgcolor:black} {/color}{align:left}{bgcolor:black}{color:white} {/color}{/bgcolor}{/align} {bgcolor:black} {/color}{align:left}{bgcolor:yellow}{color:black} {/color}{/bgcolor}{/align} {bgcolor:black} {/color}{align:left}{bgcolor:yellow}{color:black} You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only. By {/color}{/bgcolor}{/align} {bgcolor:black} {/color}{align:left}{bgcolor:yellow}{color:black} using this IS (which includes any device attached to this IS), you consent to the following conditions: {/color}{/bgcolor}{/align} {bgcolor:black} {/color}{align:left}{bgcolor:yellow}{color:black} {/color}{/bgcolor}{/align} {bgcolor:black} {/color}{align:left}{bgcolor:yellow}{color:black} - The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited {/color}{/bgcolor}{/align} {bgcolor:black} {/color}{align:left}{bgcolor:yellow}{color:black} to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law {/color}{/bgcolor}{/align} {bgcolor:black} {/color}{align:left}{bgcolor:yellow}{color:black} enforcement (LE), and counterintelligence (CI) investigations. {/color}{/bgcolor}{/align} {bgcolor:black} {/color}{align:left}{bgcolor:yellow}{color:black} {/color}{/bgcolor}{/align} {bgcolor:black} {/color}{align:left}{bgcolor:yellow}{color:black} - At any time, the USG may inspect and seize data stored on this IS. {/color}{/bgcolor}{/align} {bgcolor:black} {/color}{align:left}{bgcolor:yellow}{color:black} {/color}{/bgcolor}{/align} {bgcolor:black} {/color}{align:left}{bgcolor:yellow}{color:black} - Communications using, or data stored on, this IS are not private, are subject to routine monitoring, {/color}{/bgcolor}{/align} {bgcolor:black} {/color}{align:left}{bgcolor:yellow}{color:black} interception, and search, and may be disclosed or used for any USG-authorized purpose. {/color}{/bgcolor}{/align} {bgcolor:black} {/color}{align:left}{bgcolor:yellow}{color:black} {/color}{/bgcolor}{/align} {bgcolor:black} {/color}{align:left}{bgcolor:yellow}{color:black} - This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not {/color}{/bgcolor}{/align} {bgcolor:black} {/color}{align:left}{bgcolor:yellow}{color:black} for your personal benefit or privacy. {/color}{/bgcolor}{/align} {bgcolor:black} {/color}{align:left}{bgcolor:yellow}{color:black} {/color}{/bgcolor}{/align} {bgcolor:black} {/color}{align:left}{bgcolor:yellow}{color:black} - Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching {/color}{/bgcolor}{/align} {bgcolor:black} {/color}{align:left}{bgcolor:yellow}{color:black} or monitoring of the content of privileged communications, or work product, related to personal representation {/color}{/bgcolor}{/align} {bgcolor:black} {/color}{align:left}{bgcolor:yellow}{color:black} or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work {/color}{/bgcolor}{/align} {bgcolor:black} {/color}{align:left}{bgcolor:yellow}{color:black} product are private and confidential. See User Agreement for details. {/color}{/bgcolor}{/align} {bgcolor:black} {/color}{align:left}{bgcolor:yellow}{color:black} {/color}{/bgcolor}{/align} {bgcolor:black} {/color}{bgcolor:dark-grey}{color:black} {/color}{/bgcolor} {bgcolor:black} {/color}{bgcolor:dark-grey}{color:black} {/color}{/bgcolor} {bgcolor:black} {/color}{bgcolor:dark-grey}{color:black} {/color}{/bgcolor} {bgcolor:black} {/color}{bgcolor:dark-grey}{color:black} {/color}{/bgcolor} {bgcolor:black} {/color}{bgcolor:dark-grey}{color:black} {/color}{/bgcolor} {bgcolor:black} {/color}{bgcolor:dark-grey}{color:black} {/color}{/bgcolor} {bgcolor:black} {/color}{bgcolor:dark-grey}{color:black} {/color}{/bgcolor} {bgcolor:black} {/color}{bgcolor:dark-grey}{color:black} {/color}{/bgcolor} {bgcolor:black} {/color}{bgcolor:dark-grey}{color:black} {/color}{/bgcolor} {bgcolor:black} {/color}{bgcolor:dark-grey}{color:black} {/color}{/bgcolor} {bgcolor:black} {/color}{bgcolor:dark-grey}{color:black} {/color}{/bgcolor} {bgcolor:black} {/color}{bgcolor:dark-grey}{color:black} {/color}{/bgcolor} {bgcolor:black} {/color}{bgcolor:dark-grey}{color:black} {/color}{/bgcolor} {bgcolor:black} {/color}{bgcolor:dark-grey}{color:black} {/color}{/bgcolor} {bgcolor:black} {/color}{bgcolor:dark-grey}{color:black} {/color}{/bgcolor} {bgcolor:black} {/color}{bgcolor:dark-grey}{color:black} {/color}{/bgcolor} {bgcolor:black} {/color}{bgcolor:dark-grey}{color:black} {/color}{/bgcolor} {bgcolor:black} {/color}{align:left}{bgcolor:dark-grey}{color:white} <F2> Accept Conditions and Customize System / View Logs{/align}{align:right}<F12> Accept Conditions and Shut Down/Restart {bgcolor:black} {/color}{/color}{/bgcolor}{/align} {bgcolor:black} {/color}{bgcolor:dark-grey}{color:black} {/color}{/bgcolor} or From a PowerCLI command prompt while connected to the ESXi host, run the following command: Get-VMHost | Get-AdvancedSetting -Name Annotations.WelcomeMessage | Set-AdvancedSetting -Value "<Banner text above>"

b
The ESXi host must enable lockdown mode.
AC-10 - Medium - CCI-000054 - V-258730 - SV-258730r958398_rule
RMF Control
AC-10
Severity
M
CCI
CCI-000054
Version
ESXI-80-000008
Vuln IDs
  • V-258730
Rule IDs
  • SV-258730r958398_rule
Enabling Lockdown Mode disables direct access to an ESXi host, requiring the host to be managed remotely from vCenter Server. This is done to ensure the roles and access controls implemented in vCenter are always enforced and users cannot bypass them by logging on to a host directly. By forcing all interaction to occur through vCenter Server, the risk of someone inadvertently attaining elevated privileges or performing tasks that are not properly audited is greatly reduced.
Checks: C-62470r933249_chk

For environments that do not use vCenter server to manage ESXi, this is not applicable. From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host &gt;&gt; Configure &gt;&gt; System &gt;&gt; Security Profile. Scroll down to "Lockdown Mode" and verify it is set to "Enabled" (Normal or Strict). or From a PowerCLI command prompt while connected to the ESXi host, run the following command: Get-VMHost | Select Name,@{N="Lockdown";E={$_.Extensiondata.Config.LockdownMode}} If "Lockdown Mode" is disabled, this is a finding.

Fix: F-62379r933250_fix

From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host >> Configure >> System >> Security Profile >> Lockdown Mode. Click edit and select either the "Normal" or "Strict" radio buttons. or From a PowerCLI command prompt while connected to the ESXi host, run the following commands: $level = "lockdownNormal" OR "lockdownStrict" $vmhost = Get-VMHost -Name <hostname> | Get-View $lockdown = Get-View $vmhost.ConfigManager.HostAccessManager $lockdown.ChangeLockdownMode($level) Note: In strict lockdown mode, the Direct Console User Interface (DCUI) service is stopped. If the connection to vCenter Server is lost and the vSphere Client is no longer available, the ESXi host becomes inaccessible.

b
The ESXi host client must be configured with an idle session timeout.
AC-11 - Medium - CCI-000057 - V-258731 - SV-258731r958402_rule
RMF Control
AC-11
Severity
M
CCI
CCI-000057
Version
ESXI-80-000010
Vuln IDs
  • V-258731
Rule IDs
  • SV-258731r958402_rule
The ESXi host client is the UI served up by the host itself, outside of vCenter. It is accessed at https:///ui. ESXi is not usually administered via this interface for long periods, and all users will be highly privileged. Implementing a mandatory session idle limit will ensure that orphaned, forgotten, or ignored sessions will be closed promptly.
Checks: C-62471r933252_chk

From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host &gt;&gt; Configure &gt;&gt; System &gt;&gt; Advanced System Settings. Select the "UserVars.HostClientSessionTimeout" value and verify it is set to "900" or less. or From a PowerCLI command prompt while connected to the ESXi host, run the following command: Get-VMHost | Get-AdvancedSetting -Name UserVars.HostClientSessionTimeout If the "UserVars.HostClientSessionTimeout" setting is not set to "900" or less, this is a finding.

Fix: F-62380r933253_fix

From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host >> Configure >> System >> Advanced System Settings. Click "Edit". Select the "UserVars.HostClientSessionTimeout" value and configure it to "900". or From a PowerCLI command prompt while connected to the ESXi host, run the following command: Get-VMHost | Get-AdvancedSetting -Name UserVars.HostClientSessionTimeout | Set-AdvancedSetting -Value "900"

c
The ESXi host Secure Shell (SSH) daemon must use FIPS 140-2 validated cryptographic modules to protect the confidentiality of remote access sessions.
AC-17 - High - CCI-000068 - V-258732 - SV-258732r958408_rule
RMF Control
AC-17
Severity
H
CCI
CCI-000068
Version
ESXI-80-000014
Vuln IDs
  • V-258732
Rule IDs
  • SV-258732r958408_rule
Without confidentiality protection mechanisms, unauthorized individuals may gain access to sensitive information via a remote access session. OpenSSH on the ESXi host ships with a FIPS 140-2 validated cryptographic module and it is enabled by default. For backward compatibility reasons, this can be disabled so this setting must be audited and corrected if necessary.
Checks: C-62472r933255_chk

From an ESXi shell, run the following command: # esxcli system security fips140 ssh get or From a PowerCLI command prompt while connected to the ESXi host, run the following commands: $esxcli = Get-EsxCli -v2 $esxcli.system.security.fips140.ssh.get.invoke() Expected result: Enabled: true If the FIPS mode is not enabled for SSH, this is a finding.

Fix: F-62381r933256_fix

From an ESXi shell, run the following command: # esxcli system security fips140 ssh set -e true or From a PowerCLI command prompt while connected to the ESXi host, run the following commands: $esxcli = Get-EsxCli -v2 $arguments = $esxcli.system.security.fips140.ssh.set.CreateArgs() $arguments.enable = $true $esxcli.system.security.fips140.ssh.set.Invoke($arguments)

b
The ESXi must produce audit records containing information to establish what type of events occurred.
AU-3 - Medium - CCI-000130 - V-258733 - SV-258733r958412_rule
RMF Control
AU-3
Severity
M
CCI
CCI-000130
Version
ESXI-80-000015
Vuln IDs
  • V-258733
Rule IDs
  • SV-258733r958412_rule
Without establishing what types of events occurred, it would be difficult to establish, correlate, and investigate the events leading up to an outage or attack. Satisfies: SRG-OS-000037-VMM-000150, SRG-OS-000063-VMM-000310
Checks: C-62473r933258_chk

From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host &gt;&gt; Configure &gt;&gt; System &gt;&gt; Advanced System Settings. Select the "Config.HostAgent.log.level" value and verify it is set to "info". or From a PowerCLI command prompt while connected to the ESXi host, run the following command: Get-VMHost | Get-AdvancedSetting -Name Config.HostAgent.log.level If the "Config.HostAgent.log.level" setting is not set to "info", this is a finding. Note: Verbose logging level is acceptable for troubleshooting purposes.

Fix: F-62382r933259_fix

From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host >> Configure >> System >> Advanced System Settings. Click "Edit". Select the "Config.HostAgent.log.level" value and configure it to "info". or From a PowerCLI command prompt while connected to the ESXi host, run the following command: Get-VMHost | Get-AdvancedSetting -Name Config.HostAgent.log.level | Set-AdvancedSetting -Value "info"

b
The ESXi host must enforce password complexity by configuring a password quality policy.
Medium - CCI-004066 - V-258734 - SV-258734r1003558_rule
RMF Control
Severity
M
CCI
CCI-004066
Version
ESXI-80-000035
Vuln IDs
  • V-258734
Rule IDs
  • SV-258734r1003558_rule
To enforce the use of complex passwords, minimum numbers of characters of different classes are mandated. The use of complex passwords reduces the ability of attackers to successfully obtain valid passwords using guessing or exhaustive search techniques. Complexity requirements increase the password search space by requiring users to construct passwords from a larger character set than they may otherwise use. Satisfies: SRG-OS-000069-VMM-000360, SRG-OS-000070-VMM-000370, SRG-OS-000071-VMM-000380, SRG-OS-000072-VMM-000390, SRG-OS-000072-VMM-000390, SRG-OS-000078-VMM-000450, SRG-OS-000266-VMM-000940
Checks: C-62474r933261_chk

From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host &gt;&gt; Configure &gt;&gt; System &gt;&gt; Advanced System Settings. Select the "Security.PasswordQualityControl" value and verify it is set to "similar=deny retry=3 min=disabled,disabled,disabled,disabled,15". or From a PowerCLI command prompt while connected to the ESXi host, run the following command: Get-VMHost | Get-AdvancedSetting -Name Security.PasswordQualityControl If the "Security.PasswordQualityControl" setting is set to a value other than "similar=deny retry=3 min=disabled,disabled,disabled,disabled,15", this is a finding.

Fix: F-62383r933262_fix

From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host >> Configure >> System >> Advanced System Settings. Click "Edit". Select the "Security.PasswordQualityControl" value and configure it to "similar=deny retry=3 min=disabled,disabled,disabled,disabled,15". or From a PowerCLI command prompt while connected to the ESXi host, run the following command: Get-VMHost | Get-AdvancedSetting -Name Security.PasswordQualityControl | Set-AdvancedSetting -Value "similar=deny retry=3 min=disabled,disabled,disabled,disabled,15"

b
The ESXi host must prohibit password reuse for a minimum of five generations.
Medium - CCI-004061 - V-258735 - SV-258735r1003559_rule
RMF Control
Severity
M
CCI
CCI-004061
Version
ESXI-80-000043
Vuln IDs
  • V-258735
Rule IDs
  • SV-258735r1003559_rule
If a user or root used the same password continuously or was allowed to change it back shortly after being forced to change it to something else, it would provide a potential intruder with the opportunity to keep guessing at one user's password until it was guessed correctly.
Checks: C-62475r933264_chk

From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host &gt;&gt; Configure &gt;&gt; System &gt;&gt; Advanced System Settings. Select the "Security.PasswordHistory" value and verify it is set to "5" or greater. or From a PowerCLI command prompt while connected to the ESXi host, run the following command: Get-VMHost | Get-AdvancedSetting -Name Security.PasswordHistory If the "Security.PasswordHistory" setting is set to a value other than 5 or greater, this is a finding.

Fix: F-62384r933265_fix

From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host >> Configure >> System >> Advanced System Settings. Click "Edit". Select the "Security.PasswordHistory" value and configure it to "5". or From a PowerCLI command prompt while connected to the ESXi host, run the following command: Get-VMHost | Get-AdvancedSetting -Name Security.PasswordHistory | Set-AdvancedSetting -Value 5

b
The ESXi host must be configured to disable nonessential capabilities by disabling the Managed Object Browser (MOB).
CM-7 - Medium - CCI-000381 - V-258736 - SV-258736r958478_rule
RMF Control
CM-7
Severity
M
CCI
CCI-000381
Version
ESXI-80-000047
Vuln IDs
  • V-258736
Rule IDs
  • SV-258736r958478_rule
The MOB provides a way to explore the object model used by the VMkernel to manage the host and enables configurations to be changed. This interface is meant to be used primarily for debugging the vSphere Software Development Kit (SDK), but because there are no access controls it could also be used as a method to obtain information about a host being targeted for unauthorized access.
Checks: C-62476r933267_chk

From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host &gt;&gt; Configure &gt;&gt; System &gt;&gt; Advanced System Settings. Select the "Config.HostAgent.plugins.solo.enableMob" value and verify it is set to "false". or From a PowerCLI command prompt while connected to the ESXi host, run the following command: Get-VMHost | Get-AdvancedSetting -Name Config.HostAgent.plugins.solo.enableMob If the "Config.HostAgent.plugins.solo.enableMob" setting is not set to "false", this is a finding.

Fix: F-62385r933268_fix

From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host >> Configure >> System >> Advanced System Settings. Click "Edit". Select the "Config.HostAgent.plugins.solo.enableMob" value and configure it to "false". or From a PowerCLI command prompt while connected to the ESXi host, run the following command: Get-VMHost | Get-AdvancedSetting -Name Config.HostAgent.plugins.solo.enableMob | Set-AdvancedSetting -Value false

a
The ESXi host must uniquely identify and must authenticate organizational users by using Active Directory.
IA-2 - Low - CCI-000764 - V-258737 - SV-258737r1003560_rule
RMF Control
IA-2
Severity
L
CCI
CCI-000764
Version
ESXI-80-000049
Vuln IDs
  • V-258737
Rule IDs
  • SV-258737r1003560_rule
Join ESXi hosts to an Active Directory domain to eliminate the need to create and maintain multiple local user accounts. Using Active Directory for user authentication simplifies the ESXi host configuration, ensures password complexity and reuse policies are enforced, and reduces the risk of security breaches and unauthorized access. Note: If the Active Directory group "ESX Admins" (default) exists, all users and groups assigned as members to this group will have full administrative access to all ESXi hosts in the domain. Satisfies: SRG-OS-000104-VMM-000500, SRG-OS-000109-VMM-000550, SRG-OS-000112-VMM-000560, SRG-OS-000113-VMM-000570, SRG-OS-000123-VMM-000620
Checks: C-62477r933270_chk

For systems that do not use Active Directory and have no local user accounts other than root and/or service accounts, this is not applicable. From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host &gt;&gt; Configure &gt;&gt; System &gt;&gt; Authentication Services. Verify the "Directory Services Type" is set to "Active Directory". or From a PowerCLI command prompt while connected to the ESXi host, run the following command: Get-VMHost | Get-VMHostAuthentication For systems that do not use Active Directory and do have local user accounts, other than root and/or service accounts, this is a finding. If the "Directory Services Type" is not set to "Active Directory", this is a finding.

Fix: F-62386r933271_fix

From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host >> Configure >> System >> Authentication Services. Click "Join Domain..." and enter the AD domain to join. Select the "Using credentials" radio button and enter the credentials of an account with permissions to join machines to AD (use UPN naming "user@domain"). Click "OK". or From a PowerCLI command prompt while connected to the ESXi host, run the following command: Get-VMHost | Get-VMHostAuthentication | Set-VMHostAuthentication -JoinDomain -Domain "domain name" -User "username" -Password "password" If any local user accounts are present besides root and service accounts, delete them by going to Host UI >> Manage >> Security & Users >> Users.

b
The ESXi host Secure Shell (SSH) daemon must ignore .rhosts files.
IA-2 - Medium - CCI-000765 - V-258738 - SV-258738r1003561_rule
RMF Control
IA-2
Severity
M
CCI
CCI-000765
Version
ESXI-80-000052
Vuln IDs
  • V-258738
Rule IDs
  • SV-258738r1003561_rule
SSH trust relationships mean a compromise on one host can allow an attacker to move trivially to other hosts. SSH can emulate the behavior of the obsolete "rsh" command in allowing users to enable insecure access to their accounts via ".rhosts" files.
Checks: C-62478r933273_chk

From an ESXi shell, run the following command: # esxcli system ssh server config list -k ignorerhosts or From a PowerCLI command prompt while connected to the ESXi host, run the following commands: $esxcli = Get-EsxCli -v2 $esxcli.system.ssh.server.config.list.invoke() | Where-Object {$_.Key -eq 'ignorerhosts'} Example result: ignorerhosts yes If "ignorerhosts" is not configured to "yes", this is a finding.

Fix: F-62387r933274_fix

From an ESXi shell, run the following command: # esxcli system ssh server config set -k ignorerhosts -v yes or From a PowerCLI command prompt while connected to the ESXi host, run the following commands: $esxcli = Get-EsxCli -v2 $arguments = $esxcli.system.ssh.server.config.set.CreateArgs() $arguments.keyword = 'ignorerhosts' $arguments.value = 'yes' $esxcli.system.ssh.server.config.set.Invoke($arguments)

b
The ESXi host must set a timeout to automatically end idle shell sessions after fifteen minutes.
SC-10 - Medium - CCI-001133 - V-258739 - SV-258739r1003562_rule
RMF Control
SC-10
Severity
M
CCI
CCI-001133
Version
ESXI-80-000068
Vuln IDs
  • V-258739
Rule IDs
  • SV-258739r1003562_rule
If a user forgets to log out of their local or remote ESXi Shell session, the idle connection will remain open indefinitely and increase the likelihood of inappropriate host access via session hijacking. The "ESXiShellInteractiveTimeOut" allows the automatic termination of idle shell sessions. Satisfies: SRG-OS-000163-VMM-000700, SRG-OS-000279-VMM-001010
Checks: C-62479r1003518_chk

From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host &gt;&gt; Configure &gt;&gt; System &gt;&gt; Advanced System Settings. Select the "UserVars.ESXiShellInteractiveTimeOut" value and verify it is set to "900" or less and not "0". or From a PowerCLI command prompt while connected to the ESXi host, run the following command: Get-VMHost | Get-AdvancedSetting -Name UserVars.ESXiShellInteractiveTimeOut If the "UserVars.ESXiShellInteractiveTimeOut" setting is set to a value greater than "900" or "0", this is a finding.

Fix: F-62388r933277_fix

From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host >> Configure >> System >> Advanced System Settings. Click "Edit". Select the "UserVars.ESXiShellInteractiveTimeOut" value and configure it to "900". or From a PowerCLI command prompt while connected to the ESXi host, run the following command: Get-VMHost | Get-AdvancedSetting -Name UserVars.ESXiShellInteractiveTimeOut | Set-AdvancedSetting -Value 900

b
The ESXi host must implement Secure Boot enforcement.
AU-9 - Medium - CCI-001494 - V-258740 - SV-258740r958612_rule
RMF Control
AU-9
Severity
M
CCI
CCI-001494
Version
ESXI-80-000085
Vuln IDs
  • V-258740
Rule IDs
  • SV-258740r958612_rule
Secure Boot is part of the UEFI firmware standard. With UEFI Secure Boot enabled, a 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 and it requires that all ESXi kernel modules, drivers, and VIBs be signed by VMware or a partner subordinate. Secure Boot is enabled 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 enabled, 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 it up without ESXi complaining. Satisfies: SRG-OS-000257-VMM-000910, SRG-OS-000258-VMM-000920, SRG-OS-000445-VMM-001780, SRG-OS-000446-VMM-001790
Checks: C-62480r933279_chk

If the ESXi host does not have a compatible TPM, this finding is downgraded to a CAT III. From an ESXi shell, run the following command: # esxcli system settings encryption get or From a PowerCLI command prompt while connected to the ESXi host, run the following commands: $esxcli = Get-EsxCli -v2 $esxcli.system.settings.encryption.get.invoke() | Select RequireSecureBoot Expected result: Require Secure Boot: true If "Require Secure Boot" is not enable, this is a finding.

Fix: F-62389r933280_fix

This setting cannot be configured until Secure Boot is properly enabled in the servers firmware. From an ESXi shell, run the following commands: # esxcli system settings encryption set --require-secure-boot=true # /sbin/auto-backup.sh or From a PowerCLI command prompt while connected to the ESXi host, run the following commands: $esxcli = Get-EsxCli -v2 $arguments = $esxcli.system.settings.encryption.set.CreateArgs() $arguments.requiresecureboot = $true $esxcli.system.settings.encryption.set.Invoke($arguments) Evacuate the host and gracefully reboot for changes to take effect.

b
The ESXi host must enable Secure Boot.
AU-9 - Medium - CCI-001496 - V-258741 - SV-258741r1003563_rule
RMF Control
AU-9
Severity
M
CCI
CCI-001496
Version
ESXI-80-000094
Vuln IDs
  • V-258741
Rule IDs
  • SV-258741r1003563_rule
Secure Boot is part of the Unified Extensible Firmware Interface (UEFI) firmware standard. With UEFI Secure Boot enabled, a 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 and requires that all ESXi kernel modules, drivers, and vSphere Installation Bundles (VIBs) be signed by VMware or a partner subordinate. Secure Boot is enabled in the BIOS of the ESXi physical server and supported by the hypervisor boot loader. There is no ESXi control to "turn on" Secure Boot. Requiring Secure Boot (failing to boot without it present) is accomplished in another control.
Checks: C-62481r1003520_chk

From an ESXi shell, run the following command: # /usr/lib/vmware/secureboot/bin/secureBoot.py -s or From a PowerCLI command prompt while connected to the ESXi host, run the following command: ((Get-VMHost).ExtensionData.Capability).UefiSecureBoot If Secure Boot is not enabled, this is a finding.

Fix: F-62390r1003521_fix

From an ESXi shell, run the following command: # /usr/lib/vmware/secureboot/bin/secureBoot.py -c If the output indicates that Secure Boot cannot be enabled, correct the discrepancies and try again. Once all discrepancies are resolved, the server ESXi is installed on can be updated to enable Secure Boot in the firmware. To enable Secure Boot in the server's firmware, follow the instructions for the specific manufacturer.

b
The ESXi host must enforce an unlock timeout of 15 minutes after a user account is locked out.
AC-7 - Medium - CCI-002238 - V-258742 - SV-258742r1003564_rule
RMF Control
AC-7
Severity
M
CCI
CCI-002238
Version
ESXI-80-000111
Vuln IDs
  • V-258742
Rule IDs
  • SV-258742r1003564_rule
By enforcing a reasonable unlock timeout after multiple failed logon attempts, the risk of unauthorized access via user password guessing, otherwise known as brute forcing, is reduced. Users must wait for the timeout period to elapse before subsequent logon attempts are allowed.
Checks: C-62482r1003523_chk

From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host &gt;&gt; Configure &gt;&gt; System &gt;&gt; Advanced System Settings. Select the "Security.AccountUnlockTime" value and verify it is set to "900" or less and not "0". or From a PowerCLI command prompt while connected to the ESXi host, run the following command: Get-VMHost | Get-AdvancedSetting -Name Security.AccountUnlockTime If the "Security.AccountUnlockTime" setting is less than 900 or 0, this is a finding.

Fix: F-62391r933286_fix

From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host >> Configure >> System >> Advanced System Settings. Click "Edit". Select the "Security.AccountUnlockTime" value and configure it to "900". or From a PowerCLI command prompt while connected to the ESXi host, run the following command: Get-VMHost | Get-AdvancedSetting -Name Security.AccountUnlockTime | Set-AdvancedSetting -Value 900

b
The ESXi host must allocate audit record storage capacity to store at least one week's worth of audit records.
AU-4 - Medium - CCI-001849 - V-258743 - SV-258743r958752_rule
RMF Control
AU-4
Severity
M
CCI
CCI-001849
Version
ESXI-80-000113
Vuln IDs
  • V-258743
Rule IDs
  • SV-258743r958752_rule
In order to ensure ESXi has sufficient storage capacity in which to write the audit logs, audit record storage capacity should be configured. If a central audit record storage facility is available, the local storage capacity should be sufficient to hold audit records that would accumulate during anticipated interruptions in delivery of records to the facility.
Checks: C-62483r933288_chk

From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host &gt;&gt; Configure &gt;&gt; System &gt;&gt; Advanced System Settings. Select the "Syslog.global.auditRecord.storageCapacity" value and verify it is set to "100". or From a PowerCLI command prompt while connected to the ESXi host, run the following command: Get-VMHost | Get-AdvancedSetting -Name Syslog.global.auditRecord.storageCapacity If the "Syslog.global.auditRecord.storageCapacity" setting is not set to 100, this is a finding.

Fix: F-62392r933289_fix

From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host >> Configure >> System >> Advanced System Settings. Click "Edit". Select the "Syslog.global.auditRecord.storageCapacity" value and configure it to "100". or From a PowerCLI command prompt while connected to the ESXi host, run the following command: Get-VMHost | Get-AdvancedSetting -Name Syslog.global.auditRecord.storageCapacity | Set-AdvancedSetting -Value 100

b
The ESXi host must offload logs via syslog.
AC-2 - Medium - CCI-000015 - V-258744 - SV-258744r1003565_rule
RMF Control
AC-2
Severity
M
CCI
CCI-000015
Version
ESXI-80-000114
Vuln IDs
  • V-258744
Rule IDs
  • SV-258744r1003565_rule
Remote logging to a central log host provides a secure, centralized store for ESXi logs. By gathering host log files onto a central host, it can more easily monitor all hosts with a single tool. It can also do aggregate analysis and searching to look for such things as coordinated attacks on multiple hosts. Logging to a secure, centralized log server also helps prevent log tampering and provides a long-term audit record. Satisfies: SRG-OS-000342-VMM-001230, SRG-OS-000274-VMM-000960, SRG-OS-000275-VMM-000970, SRG-OS-000277-VMM-000990, SRG-OS-000479-VMM-001990
Checks: C-62484r933291_chk

From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host &gt;&gt; Configure &gt;&gt; System &gt;&gt; Advanced System Settings. Select the "Syslog.global.logHost" value and verify it is set to a site-specific syslog server. Syslog servers are specified in the following formats: udp://&lt;IP or FQDN&gt;:514 tcp://&lt;IP or FQDN&gt;:514 ssl://&lt;IP or FQDN&gt;:1514 Multiple servers can also be specified when separated by commas. or From a PowerCLI command prompt while connected to the ESXi host, run the following command: Get-VMHost | Get-AdvancedSetting -Name Syslog.global.logHost If the "Syslog.global.logHost" setting is not set to a valid, site-specific syslog server, this is a finding.

Fix: F-62393r933292_fix

From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host >> Configure >> System >> Advanced System Settings. Click "Edit". Select the "Syslog.global.logHost" value and configure it to a site-specific syslog server. or From a PowerCLI command prompt while connected to the ESXi host, run the following command: Get-VMHost | Get-AdvancedSetting -Name Syslog.global.logHost | Set-AdvancedSetting -Value "enter site specific servers"

b
The ESXi host must synchronize internal information system clocks to an authoritative time source.
Medium - CCI-004923 - V-258745 - SV-258745r1003566_rule
RMF Control
Severity
M
CCI
CCI-004923
Version
ESXI-80-000124
Vuln IDs
  • V-258745
Rule IDs
  • SV-258745r1003566_rule
To ensure the accuracy of the system clock, it must be synchronized with an authoritative time source within DOD. Many system functions, including time-based logon and activity restrictions, automated reports, system logs, and audit records, depend on an accurate system clock. If there is no confidence in the correctness of the system clock, time-based functions may not operate as intended and records may be of diminished value. Satisfies: SRG-OS-000355-VMM-001330, SRG-OS-000356-VMM-001340
Checks: C-62485r933294_chk

From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host &gt;&gt; Configure &gt;&gt; System &gt;&gt; Time Configuration. Verify NTP or PTP are configured, and one or more authoritative time sources are listed. From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host &gt;&gt; Configure &gt;&gt; System &gt;&gt; Services. Verify the NTP or PTP service is running and configured to start and stop with the host. or From a PowerCLI command prompt while connected to the ESXi host, run the following commands: Get-VMHost | Get-VMHostNTPServer Get-VMHost | Get-VMHostService | Where {$_.Label -eq "NTP Daemon" -or $_.Label -eq "PTP Daemon"} If the NTP service is not configured with authoritative DOD time sources or the service is not configured to start and stop with the host ("Policy" of "on" in PowerCLI) or is stopped, this is a finding. If PTP is used instead of NTP, this is not a finding.

Fix: F-62394r933295_fix

To configure NTP, perform the following: From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host >> Configure >> System >> Time Configuration. Click "Add Service" and select "Network Time Protocol". Enter or update the NTP servers listed with a comma-separated list of authoritative time servers. Click "OK". From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host >> Configure >> System >> Services. Select the "NTP Daemon" service and click "Edit Startup Policy". Select "Start and stop with host". Click "OK". or From a PowerCLI command prompt while connected to the ESXi host, run the following commands: $NTPServers = "ntpserver1","ntpserver2" Get-VMHost | Add-VMHostNTPServer $NTPServers Get-VMHost | Get-VMHostService | Where {$_.Label -eq "NTP Daemon"} | Set-VMHostService -Policy On Get-VMHost | Get-VMHostService | Where {$_.Label -eq "NTP Daemon"} | Start-VMHostService To configure PTP, perform the following: From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host >> Configure >> System >> Time Configuration. Click "Add Service" and select "Precision Time Protocol". Select the network adapter that can receive the PTP traffic. If NTP servers are available, select "Enable fallback" and enter or update the NTP servers listed with a comma separate list of authoritative time servers. Click "OK". From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host >> Configure >> System >> Services. Select the "PTP Daemon" service and click "Edit Startup Policy". Select "Start and stop with host". Click "OK".

c
The ESXi Image Profile and vSphere Installation Bundle (VIB) acceptance level must be verified.
High - CCI-003992 - V-258746 - SV-258746r1003567_rule
RMF Control
Severity
H
CCI
CCI-003992
Version
ESXI-80-000133
Vuln IDs
  • V-258746
Rule IDs
  • SV-258746r1003567_rule
Verify the ESXi Image Profile to only allow signed VIBs. An unsigned VIB represents untested code installed on an ESXi host. The ESXi Image profile supports four acceptance levels: 1. VMwareCertified - VIBs created, tested, and signed by VMware. 2. VMwareAccepted - VIBs created by a VMware partner but tested and signed by VMware. 3. PartnerSupported - VIBs created, tested, and signed by a certified VMware partner. 4. CommunitySupported - VIBs that have not been tested by VMware or a VMware partner. Community Supported VIBs are not supported and do not have a digital signature. To protect the security and integrity of ESXi hosts, do not allow unsigned (CommunitySupported) VIBs to be installed on hosts. Satisfies: SRG-OS-000366-VMM-001430, SRG-OS-000370-VMM-001460
Checks: C-62486r933297_chk

From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host &gt;&gt; Configure &gt;&gt; System &gt;&gt; Security Profile. Under "Host Image Profile Acceptance Level" view the acceptance level. or From a PowerCLI command prompt while connected to the ESXi host, run the following commands: $esxcli = Get-EsxCli -v2 $esxcli.software.acceptance.get.Invoke() If the acceptance level is "CommunitySupported", this is a finding.

Fix: F-62395r933298_fix

From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host >> Configure >> System >> Security Profile. Under "Host Image Profile Acceptance Level", click "Edit". Using the drop-down selection, set the acceptance level as "VMwareCertified", "VMwareAccepted", or "PartnerSupported". The default is "PartnerSupported". or From a PowerCLI command prompt while connected to the ESXi host, run the following commands: $esxcli = Get-EsxCli -v2 $arguments = $esxcli.software.acceptance.set.CreateArgs() $arguments.level = "PartnerSupported" $esxcli.software.acceptance.set.Invoke($arguments) Note: "VMwareCertified" or "VMwareAccepted" may be substituted for "PartnerSupported", depending on local requirements. These are case sensitive.

b
The ESXi host must enable bidirectional Challenge-Handshake Authentication Protocol (CHAP) authentication for Internet Small Computer Systems Interface (iSCSI) traffic.
IA-3 - Medium - CCI-001967 - V-258747 - SV-258747r971545_rule
RMF Control
IA-3
Severity
M
CCI
CCI-001967
Version
ESXI-80-000145
Vuln IDs
  • V-258747
Rule IDs
  • SV-258747r971545_rule
When enabled, vSphere performs bidirectional authentication of both the iSCSI target and host. When not authenticating both the iSCSI target and host, there is potential for a man-in-the-middle attack, in which an attacker might impersonate either side of the connection to steal data. Bidirectional authentication mitigates this risk.
Checks: C-62487r933300_chk

If iSCSI is not used, this is not applicable. From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host &gt;&gt; Configure &gt;&gt; Storage &gt;&gt; Storage Adapters. Select the iSCSI adapter &gt;&gt; Properties &gt;&gt; Authentication &gt;&gt; Method. View the CHAP configuration and verify CHAP is required for target and host authentication. or From a PowerCLI command prompt while connected to the ESXi host, run the following command: Get-VMHost | Get-VMHostHba | Where {$_.Type -eq "iscsi"} | Select AuthenticationProperties -ExpandProperty AuthenticationProperties If iSCSI is used and CHAP is not set to "required" for both the target and host, this is a finding. If iSCSI is used and unique CHAP secrets are not used for each host, this is a finding.

Fix: F-62396r933301_fix

From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host >> Configure >> Storage >> Storage Adapters. Select the iSCSI adapter >> Properties >> Authentication. Click "Edit...". Set "Authentication Method" to "Use bidirectional CHAP" and enter a unique secret for each traffic flow direction. or From a PowerCLI command prompt while connected to the ESXi host, run the following command: Get-VMHost | Get-VMHostHba | Where {$_.Type -eq "iscsi"} | Set-VMHostHba -ChapType Required -ChapName "chapname" -ChapPassword "password" -MutualChapEnabled $true -MutualChapName "mutualchapname" -MutualChapPassword "mutualpassword"

b
The ESXi host must protect the confidentiality and integrity of transmitted information by isolating vMotion traffic.
SC-8 - Medium - CCI-002418 - V-258748 - SV-258748r958908_rule
RMF Control
SC-8
Severity
M
CCI
CCI-002418
Version
ESXI-80-000160
Vuln IDs
  • V-258748
Rule IDs
  • SV-258748r958908_rule
While encrypted vMotion is available, vMotion traffic should still be sequestered from other traffic to further protect it from attack. This network must only be accessible to other ESXi hosts, preventing outside access to the network. The vMotion VMkernel port group must be in a dedicated VLAN that can be on a standard or distributed virtual switch as long as the vMotion VLAN is not shared by any other function and is only routed to ESXi hosts.
Checks: C-62488r933303_chk

For environments that do not use vCenter server to manage ESXi, this is not applicable. From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host &gt;&gt; Configure &gt;&gt; Networking &gt;&gt; VMkernel adapters. Review the VLAN associated with any vMotion VMkernel(s) and verify they are dedicated for that purpose and are logically separated from other functions. If long distance or cross vCenter vMotion is used, the vMotion network can be routable but must be accessible to only the intended ESXi hosts. If the vMotion port group is not on an isolated VLAN and/or is routable to systems other than ESXi hosts, this is a finding.

Fix: F-62397r933304_fix

Configuration of the vMotion VMkernel will be unique to each environment. For example, to modify the IP address and VLAN information to the correct network on a distributed switch, do the following: From the vSphere Client, go to Networking. Select a distributed switch >> Select a port group >> Configure >> Settings >> Properties. Click "Edit" and select VLAN. Change the "VLAN Type" to "VLAN" and change the "VLAN ID" to a network allocated and dedicated to vMotion traffic exclusively. Click "OK".

c
The ESXi host must maintain the confidentiality and integrity of information during transmission by exclusively enabling Transport Layer Security (TLS) 1.2.
SC-8 - High - CCI-002420 - V-258749 - SV-258749r1003568_rule
RMF Control
SC-8
Severity
H
CCI
CCI-002420
Version
ESXI-80-000161
Vuln IDs
  • V-258749
Rule IDs
  • SV-258749r1003568_rule
TLS 1.0 and 1.1 are deprecated protocols with well-published shortcomings and vulnerabilities. TLS 1.2 should be enabled on all interfaces and SSLv3, TL 1.1, and 1.0 disabled, where supported. Mandating TLS 1.2 may break third-party integrations and add-ons to vSphere. Test these integrations carefully after implementing TLS 1.2 and roll back where appropriate. On interfaces where required functionality is broken with TLS 1.2, this finding is not applicable until such time as the third-party software supports TLS 1.2. Modify TLS settings in the following order: 1. vCenter. 2. ESXi. Satisfies: SRG-OS-000425-VMM-001710, SRG-OS-000426-VMM-001720
Checks: C-62489r933306_chk

From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host &gt;&gt; Configure &gt;&gt; System &gt;&gt; Advanced System Settings. Select the "UserVars.ESXiVPsDisabledProtocols" value and verify it is set to "sslv3,tlsv1,tlsv1.1". or From a PowerCLI command prompt while connected to the ESXi host, run the following command: Get-VMHost | Get-AdvancedSetting -Name UserVars.ESXiVPsDisabledProtocols If the "UserVars.ESXiVPsDisabledProtocols" setting is set to a value other than "sslv3,tlsv1,tlsv1.1", this is a finding.

Fix: F-62398r933307_fix

From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host >> Configure >> System >> Advanced System Settings. Click "Edit". Select the "UserVars.ESXiVPsDisabledProtocols" value and configure it to "sslv3,tlsv1,tlsv1.1". or From a PowerCLI command prompt while connected to the ESXi host, run the following command: Get-VMHost | Get-AdvancedSetting -Name UserVars.ESXiVPsDisabledProtocols | Set-AdvancedSetting -Value "sslv3,tlsv1,tlsv1.1"

b
The ESXi host Secure Shell (SSH) daemon must be configured to only use FIPS 140-2 validated ciphers.
SC-13 - Medium - CCI-002450 - V-258750 - SV-258750r959006_rule
RMF Control
SC-13
Severity
M
CCI
CCI-002450
Version
ESXI-80-000187
Vuln IDs
  • V-258750
Rule IDs
  • SV-258750r959006_rule
Use of weak or untested encryption algorithms undermines the purposes of utilizing encryption to protect data. ESXi must implement cryptographic modules adhering to the higher standards approved by the federal government since this provides assurance they have been tested and validated.
Checks: C-62490r933309_chk

From an ESXi shell, run the following command: # esxcli system ssh server config list -k ciphers or From a PowerCLI command prompt while connected to the ESXi host, run the following commands: $esxcli = Get-EsxCli -v2 $esxcli.system.ssh.server.config.list.invoke() | Where-Object {$_.Key -eq 'ciphers'} Expected result: ciphers aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr If the output matches the ciphers in the expected result or a subset thereof, this is not a finding. If the ciphers in the output contain any ciphers not listed in the expected result, this is a finding.

Fix: F-62399r933310_fix

From an ESXi shell, run the following command: # esxcli system ssh server config set -k ciphers -v aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr or From a PowerCLI command prompt while connected to the ESXi host, run the following commands: $esxcli = Get-EsxCli -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)

b
The ESXi host DCUI.Access list must be verified.
CM-6 - Medium - CCI-000366 - V-258751 - SV-258751r959010_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
ESXI-80-000189
Vuln IDs
  • V-258751
Rule IDs
  • SV-258751r959010_rule
Lockdown mode disables direct host access, requiring that administrators manage hosts from vCenter Server. However, if a host becomes isolated from vCenter, the administrator is locked out and can no longer manage the host. The "DCUI.Access" advanced setting allows specified users to exit lockdown mode in such a scenario. If the Direct Console User Interface (DCUI) is running in strict lockdown mode, this setting is ineffective.
Checks: C-62491r933312_chk

For environments that do not use vCenter server to manage ESXi, this is not applicable. From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host &gt;&gt; Configure &gt;&gt; System &gt;&gt; Advanced System Settings. Select the "DCUI.Access" value and verify only the root user is listed. or From a PowerCLI command prompt while connected to the ESXi host, run the following command: Get-VMHost | Get-AdvancedSetting -Name DCUI.Access and verify it is set to root. If the "DCUI.Access" is not restricted to "root", this is a finding. Note: This list is only for local user accounts and should only contain the root user.

Fix: F-62400r933313_fix

From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host >> Configure >> System >> Advanced System Settings. Click "Edit". Select the "DCUI.Access" value and configure it to "root". or From a PowerCLI command prompt while connected to the ESXi host, run the following command: Get-VMHost | Get-AdvancedSetting -Name DCUI.Access | Set-AdvancedSetting -Value "root"

b
The ESXi host must display the Standard Mandatory DOD Notice and Consent Banner before granting access to the system via Secure Shell (SSH).
AC-8 - Medium - CCI-000048 - V-258752 - SV-258752r958390_rule
RMF Control
AC-8
Severity
M
CCI
CCI-000048
Version
ESXI-80-000191
Vuln IDs
  • V-258752
Rule IDs
  • SV-258752r958390_rule
Display of a standardized and approved use notification before granting access to the host ensures privacy and security notification verbiage used is consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance. System use notifications are required only for access via logon interfaces with human users and are not required when such human interfaces do not exist. The banner must be formatted in accordance with applicable DOD policy. Use the following verbiage for a host that can accommodate banners of 1300 characters: "You are accessing a U.S. Government (USG) VMM (IS) that is provided for USG-authorized use only. By using this IS (which includes any device attached to this IS), you consent to the following conditions: -The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations. -At any time, the USG may inspect and seize data stored on this IS. -Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose. -This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy. -Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details." Use the following verbiage for VMMs that have severe limitations on the number of characters that can be displayed in the banner: "I've read (literal ampersand) consent to terms in IS user agreem't."
Checks: C-62492r933315_chk

From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host &gt;&gt; Configure &gt;&gt; System &gt;&gt; Advanced System Settings. Select the "Config.Etc.issue" value and verify it contains the standard mandatory DOD notice and consent banner. or From a PowerCLI command prompt while connected to the ESXi host, run the following command: Get-VMHost | Get-AdvancedSetting -Name Config.Etc.issue If the "Config.Etc.issue" setting does not contain the standard mandatory DOD notice and consent banner, this is a finding.

Fix: F-62401r933316_fix

From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host >> Configure >> System >> Advanced System Settings. Click "Edit". Select the "Config.Etc.issue" value and set it to the following: "You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only. By using this IS (which includes any device attached to this IS), you consent to the following conditions: -The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations. -At any time, the USG may inspect and seize data stored on this IS. -Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose. -This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy. -Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details." or From a PowerCLI command prompt while connected to the ESXi host, run the following command: Get-VMHost | Get-AdvancedSetting -Name Config.Etc.issue | Set-AdvancedSetting -Value "<Banner text above>"

b
The ESXi host Secure Shell (SSH) daemon must display the Standard Mandatory DOD Notice and Consent Banner before granting access to the system.
AC-8 - Medium - CCI-000048 - V-258753 - SV-258753r958390_rule
RMF Control
AC-8
Severity
M
CCI
CCI-000048
Version
ESXI-80-000192
Vuln IDs
  • V-258753
Rule IDs
  • SV-258753r958390_rule
Display of a standardized and approved use notification before granting access to the host ensures privacy and security notification verbiage used is consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance. System use notifications are required only for access via logon interfaces with human users and are not required when such human interfaces do not exist. The banner must be formatted in accordance with applicable DOD policy. Use the following verbiage for a host that can accommodate banners of 1300 characters: "You are accessing a U.S. Government (USG) VMM (IS) that is provided for USG-authorized use only. By using this IS (which includes any device attached to this IS), you consent to the following conditions: -The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations. -At any time, the USG may inspect and seize data stored on this IS. -Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose. -This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy. -Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details." Use the following verbiage for VMMs that have severe limitations on the number of characters that can be displayed in the banner: "I've read (literal ampersand) consent to terms in IS user agreem't."
Checks: C-62493r933318_chk

From an ESXi shell, run the following command: # esxcli system ssh server config list -k banner or From a PowerCLI command prompt while connected to the ESXi host, run the following commands: $esxcli = Get-EsxCli -v2 $esxcli.system.ssh.server.config.list.invoke() | Where-Object {$_.Key -eq 'banner'} Example result: banner /etc/issue If "banner" is not configured to "/etc/issue", this is a finding.

Fix: F-62402r933319_fix

From an ESXi shell, run the following command: # esxcli system ssh server config set -k banner -v /etc/issue or From a PowerCLI command prompt while connected to the ESXi host, run the following commands: $esxcli = Get-EsxCli -v2 $arguments = $esxcli.system.ssh.server.config.set.CreateArgs() $arguments.keyword = 'banner' $arguments.value = '/etc/issue' $esxcli.system.ssh.server.config.set.Invoke($arguments)

b
The ESXi host must be configured to disable nonessential capabilities by disabling Secure Shell (SSH).
CM-7 - Medium - CCI-000381 - V-258754 - SV-258754r958478_rule
RMF Control
CM-7
Severity
M
CCI
CCI-000381
Version
ESXI-80-000193
Vuln IDs
  • V-258754
Rule IDs
  • SV-258754r958478_rule
The ESXi Shell is an interactive command line interface (CLI) available at the ESXi server console. The ESXi shell provides temporary access to commands essential for server maintenance. Intended primarily for use in break-fix scenarios, the ESXi shell is well suited for checking and modifying configuration details, which are not always generally accessible, using the vSphere Client. The ESXi shell is accessible remotely using SSH by users with the Administrator role. Under normal operating conditions, SSH access to the host must be disabled as is the default. As with the ESXi shell, SSH is also intended only for temporary use during break-fix scenarios. SSH must therefore be disabled under normal operating conditions and must only be enabled for diagnostics or troubleshooting. Remote access to the host must therefore be limited to the vSphere Client or Host Client at all other times. Satisfies: SRG-OS-000095-VMM-000480, SRG-OS-000297-VMM-001040, SRG-OS-000298-VMM-001050
Checks: C-62494r933321_chk

From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host &gt;&gt; Configure &gt;&gt; System &gt;&gt; Services. Under Services, locate the "SSH" service and verify it is "Stopped". or From a PowerCLI command prompt while connected to the ESXi host, run the following command: Get-VMHost | Get-VMHostService | Where {$_.Label -eq "SSH"} If the SSH service is "Running", this is a finding.

Fix: F-62403r933322_fix

From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host >> Configure >> System >> Services. Under "Services", select the "SSH" service and click the "Stop" button. Click the "Edit Startup policy..." button. Select the "Start and stop manually" radio button. Click "OK". or From a PowerCLI command prompt while connected to the ESXi host, run the following commands: Get-VMHost | Get-VMHostService | Where {$_.Label -eq "SSH"} | Set-VMHostService -Policy Off Get-VMHost | Get-VMHostService | Where {$_.Label -eq "SSH"} | Stop-VMHostService

b
The ESXi host must be configured to disable nonessential capabilities by disabling the ESXi shell.
CM-7 - Medium - CCI-000381 - V-258755 - SV-258755r958478_rule
RMF Control
CM-7
Severity
M
CCI
CCI-000381
Version
ESXI-80-000194
Vuln IDs
  • V-258755
Rule IDs
  • SV-258755r958478_rule
The ESXi Shell is an interactive command line environment available locally from the Direct Console User Interface (DCUI) or remotely via SSH. Activities performed from the ESXi Shell bypass vCenter role-based access control (RBAC) and audit controls. The ESXi shell must only be turned on when needed to troubleshoot/resolve problems that cannot be fixed through the vSphere client.
Checks: C-62495r933324_chk

From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host &gt;&gt; Configure &gt;&gt; System &gt;&gt; Services. Under Services, locate the "ESXi Shell" service and verify it is "Stopped". or From a PowerCLI command prompt while connected to the ESXi host, run the following command: Get-VMHost | Get-VMHostService | Where {$_.Label -eq "ESXi Shell"} If the ESXi Shell service is "Running", this is a finding.

Fix: F-62404r933325_fix

From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host >> Configure >> System >> Services. Under "Services", select the "ESXi Shell" service and click the "Stop" button. Click the "Edit Startup policy..." button. Select the "Start and stop manually" radio button. Click "OK". or From a PowerCLI command prompt while connected to the ESXi host, run the following commands: Get-VMHost | Get-VMHostService | Where {$_.Label -eq "ESXi Shell"} | Set-VMHostService -Policy Off Get-VMHost | Get-VMHostService | Where {$_.Label -eq "ESXi Shell"} | Stop-VMHostService

b
The ESXi host must automatically stop shell services after 10 minutes.
SC-10 - Medium - CCI-001133 - V-258756 - SV-258756r1003569_rule
RMF Control
SC-10
Severity
M
CCI
CCI-001133
Version
ESXI-80-000195
Vuln IDs
  • V-258756
Rule IDs
  • SV-258756r1003569_rule
When the ESXi Shell or Secure Shell (SSH) services are enabled on a host, they will run indefinitely. To avoid having these services left running, set the "ESXiShellTimeOut". The "ESXiShellTimeOut" defines a window of time after which the ESXi Shell and SSH services will be stopped automatically.
Checks: C-62496r1003529_chk

From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host &gt;&gt; Configure &gt;&gt; System &gt;&gt; Advanced System Settings. Select the "UserVars.ESXiShellTimeOut" value and verify it is set to "600" or less and not "0". or From a PowerCLI command prompt while connected to the ESXi host, run the following command: Get-VMHost | Get-AdvancedSetting -Name UserVars.ESXiShellTimeOut If the "UserVars.ESXiShellTimeOut" setting is set to a value greater than "600" or "0", this is a finding.

Fix: F-62405r933328_fix

From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host >> Configure >> System >> Advanced System Settings. Click "Edit". Select the "UserVars.ESXiShellTimeOut" value and configure it to "600". or From a PowerCLI command prompt while connected to the ESXi host, run the following command: Get-VMHost | Get-AdvancedSetting -Name UserVars.ESXiShellTimeOut | Set-AdvancedSetting -Value 600

b
The ESXi host must set a timeout to automatically end idle DCUI sessions after 10 minutes.
SC-10 - Medium - CCI-001133 - V-258757 - SV-258757r1003570_rule
RMF Control
SC-10
Severity
M
CCI
CCI-001133
Version
ESXI-80-000196
Vuln IDs
  • V-258757
Rule IDs
  • SV-258757r1003570_rule
When the Direct Console User Interface (DCUI) is enabled and logged in, it should be automatically logged out if left logged on to avoid access by unauthorized persons. The "DcuiTimeOut" setting defines a window of time after which the DCUI will be logged out.
Checks: C-62497r1003531_chk

From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host &gt;&gt; Configure &gt;&gt; System &gt;&gt; Advanced System Settings. Select the "UserVars.DcuiTimeOut" value and verify it is set to "600" or less and not "0". or From a PowerCLI command prompt while connected to the ESXi host, run the following command: Get-VMHost | Get-AdvancedSetting -Name UserVars.DcuiTimeOut If the "UserVars.DcuiTimeOut" setting is set to a value greater than "600" or "0", this is a finding.

Fix: F-62406r933331_fix

From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host >> Configure >> System >> Advanced System Settings. Click "Edit". Select the "UserVars.DcuiTimeOut" value and configure it to "600". or From a PowerCLI command prompt while connected to the ESXi host, run the following command: Get-VMHost | Get-AdvancedSetting -Name UserVars.DcuiTimeOut | Set-AdvancedSetting -Value 600

b
The ESXi host must protect the confidentiality and integrity of transmitted information by isolating ESXi management traffic.
SC-8 - Medium - CCI-002418 - V-258758 - SV-258758r958908_rule
RMF Control
SC-8
Severity
M
CCI
CCI-002418
Version
ESXI-80-000198
Vuln IDs
  • V-258758
Rule IDs
  • SV-258758r958908_rule
The vSphere management network provides access to the vSphere management interface on each component. Services running on the management interface provide an opportunity for an attacker to gain privileged access to the systems. Any remote attack most likely would begin with gaining entry to this network. The Management VMkernel port group can be on a standard or distributed virtual switch but must be on a dedicated VLAN. The Management VLAN must not be shared by any other function and must not be accessible to anything other than management-related functions such as vCenter.
Checks: C-62498r933333_chk

From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host &gt;&gt; Configure &gt;&gt; Networking &gt;&gt; VMkernel adapters. Review each VMkernel adapter that is used for management traffic and view the "Enabled services". Review the VLAN associated with each VMkernel that is used for management traffic. Verify with the system administrator that they are dedicated for that purpose and are logically separated from other functions. If any services other than "Management" are enabled on the Management VMkernel adapter, this is a finding. If the network segment is accessible, except to networks where other management-related entities are located such as vCenter, this is a finding. If there are any other systems or devices such as VMs on the ESXi management segment, this is a finding.

Fix: F-62407r933334_fix

Configuration of the management VMkernel will be unique to each environment. For example, to modify the IP address and VLAN information to the correct network on a distributed switch, do the following: From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host >> Configure >> Networking >> VMkernel adapters. Select the Management VMkernel and click "Edit". On the Port properties tab, uncheck all services except for "Management". Click "OK". From the vSphere Client, go to Networking. Select a distributed switch >> Select a port group >> Configure >> Settings >> Properties. Click "Edit" and select VLAN. Change the "VLAN Type" to "VLAN" and change the "VLAN ID" to a network allocated and dedicated to management traffic exclusively. Click "OK".

b
The ESXi host must protect the confidentiality and integrity of transmitted information by isolating IP-based storage traffic.
SC-8 - Medium - CCI-002418 - V-258759 - SV-258759r958908_rule
RMF Control
SC-8
Severity
M
CCI
CCI-002418
Version
ESXI-80-000199
Vuln IDs
  • V-258759
Rule IDs
  • SV-258759r958908_rule
Virtual machines (VMs) might share virtual switches and VLANs with the IP-based storage configurations. IP-based storage includes vSAN, iSCSI, and NFS. This configuration might expose IP-based storage traffic to unauthorized VM users. IP-based storage frequently is not encrypted. It can be viewed by anyone with access to this network. To restrict unauthorized users from viewing the IP-based storage traffic, the IP-based storage network must be logically separated from any other traffic. Configuring the IP-based storage adaptors on separate VLANs or network segments from other VMkernels and VMs will limit unauthorized users from viewing the traffic.
Checks: C-62499r933336_chk

If IP-based storage is not used, this is not applicable. From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host &gt;&gt; Configure &gt;&gt; Networking &gt;&gt; VMkernel adapters. Review each VMkernel adapter that is used for IP-based storage traffic and view the "Enabled services". Review the VLAN associated with each VMkernel that is used for IP-based storage traffic. Verify with the system administrator that they are dedicated for that purpose and are logically separated from other functions. If any services are enabled on an NFS or iSCSI IP-based storage VMkernel adapter, this is a finding. If any services are enabled on a vSAN VMkernel adapter other than vSAN, this is a finding. If any IP-based storage networks are not isolated from other traffic types, this is a finding.

Fix: F-62408r933337_fix

Configuration of an IP-Based VMkernel will be unique to each environment. From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host >> Configure >> Networking >> VMkernel adapters. Select the VMkernel used for IP-based storage and click "Edit". On the "Port" properties tab, uncheck all services. Click "OK". Note: For VMkernels used for vSAN leave the vSAN service enabled and uncheck all others. From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host >> Configure >> Networking >> Virtual switches. Find the port group that is dedicated to IP-based storage and click the '...' button next to the name. Click "Edit Settings". On the "Properties" tab, change the "VLAN ID" to one dedicated for IP-based storage traffic. Click "OK".

b
The ESXi host lockdown mode exception users list must be verified.
CM-6 - Medium - CCI-000366 - V-258760 - SV-258760r959010_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
ESXI-80-000201
Vuln IDs
  • V-258760
Rule IDs
  • SV-258760r959010_rule
While a host is in lockdown mode (strict or normal), only users on the "Exception Users" list are allowed access. These users do not lose their permissions when the host enters lockdown mode. The organization may want to add service accounts such as a backup agent to the Exception Users list. Verify the list of users exempted from losing permissions is legitimate and as needed per the environment. Adding unnecessary users to the exception list defeats the purpose of lockdown mode.
Checks: C-62500r933339_chk

For environments that do not use vCenter server to manage ESXi, this is not applicable. From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host &gt;&gt; Configure &gt;&gt; System &gt;&gt; Security Profile. Under "Lockdown Mode", review the Exception Users list. or From a PowerCLI command prompt while connected to the ESXi host, run the following script: $vmhost = Get-VMHost | Get-View $lockdown = Get-View $vmhost.ConfigManager.HostAccessManager $lockdown.QueryLockdownExceptions() If the Exception Users list contains accounts that do not require special permissions, this is a finding. Note: The Exception Users list is empty by default and should remain that way except under site-specific circumstances.

Fix: F-62409r933340_fix

From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host >> Configure >> System >> Security Profile. Under "Lockdown Mode", click "Edit" and remove unnecessary users from the Exception Users list.

b
The ESXi host Secure Shell (SSH) daemon must not allow host-based authentication.
CM-6 - Medium - CCI-000366 - V-258761 - SV-258761r959010_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
ESXI-80-000202
Vuln IDs
  • V-258761
Rule IDs
  • SV-258761r959010_rule
SSH trust relationships mean a compromise on one host can allow an attacker to move trivially to other hosts. SSH's cryptographic host-based authentication is more secure than ".rhosts" authentication since hosts are cryptographically authenticated. However, it is not recommended that hosts unilaterally trust one another, even within an organization.
Checks: C-62501r933342_chk

From an ESXi shell, run the following command: # esxcli system ssh server config list -k hostbasedauthentication or From a PowerCLI command prompt while connected to the ESXi host, run the following commands: $esxcli = Get-EsxCli -v2 $esxcli.system.ssh.server.config.list.invoke() | Where-Object {$_.Key -eq 'hostbasedauthentication'} Example result: hostbasedauthentication no If "hostbasedauthentication" is not configured to "no", this is a finding.

Fix: F-62410r933343_fix

From an ESXi shell, run the following command: # esxcli system ssh server config set -k hostbasedauthentication -v no or From a PowerCLI command prompt while connected to the ESXi host, run the following commands: $esxcli = Get-EsxCli -v2 $arguments = $esxcli.system.ssh.server.config.set.CreateArgs() $arguments.keyword = 'hostbasedauthentication' $arguments.value = 'no' $esxcli.system.ssh.server.config.set.Invoke($arguments)

b
The ESXi host Secure Shell (SSH) daemon must not permit user environment settings.
CM-6 - Medium - CCI-000366 - V-258762 - SV-258762r959010_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
ESXI-80-000204
Vuln IDs
  • V-258762
Rule IDs
  • SV-258762r959010_rule
SSH environment options potentially allow users to bypass access restriction in some configurations. Users must not be able to present environment options to the SSH daemon.
Checks: C-62502r933345_chk

From an ESXi shell, run the following command: # esxcli system ssh server config list -k permituserenvironment or From a PowerCLI command prompt while connected to the ESXi host, run the following commands: $esxcli = Get-EsxCli -v2 $esxcli.system.ssh.server.config.list.invoke() | Where-Object {$_.Key -eq 'permituserenvironment'} Example result: permituserenvironment no If "permituserenvironment" is not configured to "no", this is a finding.

Fix: F-62411r933346_fix

From an ESXi shell, run the following command: # esxcli system ssh server config set -k permituserenvironment -v no or From a PowerCLI command prompt while connected to the ESXi host, run the following commands: $esxcli = Get-EsxCli -v2 $arguments = $esxcli.system.ssh.server.config.set.CreateArgs() $arguments.keyword = 'permituserenvironment' $arguments.value = 'no' $esxcli.system.ssh.server.config.set.Invoke($arguments)

a
The ESXi host Secure Shell (SSH) daemon must be configured to not allow gateway ports.
CM-6 - Low - CCI-000366 - V-258763 - SV-258763r959010_rule
RMF Control
CM-6
Severity
L
CCI
CCI-000366
Version
ESXI-80-000207
Vuln IDs
  • V-258763
Rule IDs
  • SV-258763r959010_rule
SSH Transmission Control Protocol (TCP) connection forwarding provides a mechanism to establish TCP connections proxied by the SSH server. This function can provide convenience similar to a virtual private network (VPN) with the similar risk of providing a path to circumvent firewalls and network Access Control Lists (ACLs). Gateway ports allow remote forwarded ports to bind to nonloopback addresses on the server.
Checks: C-62503r933348_chk

From an ESXi shell, run the following command: # esxcli system ssh server config list -k gatewayports or From a PowerCLI command prompt while connected to the ESXi host, run the following commands: $esxcli = Get-EsxCli -v2 $esxcli.system.ssh.server.config.list.invoke() | Where-Object {$_.Key -eq 'gatewayports'} Example result: gatewayports no If "gatewayports" is not configured to "no", this is a finding.

Fix: F-62412r933349_fix

From an ESXi shell, run the following command: # esxcli system ssh server config set -k gatewayports -v no or From a PowerCLI command prompt while connected to the ESXi host, run the following commands: $esxcli = Get-EsxCli -v2 $arguments = $esxcli.system.ssh.server.config.set.CreateArgs() $arguments.keyword = 'gatewayports' $arguments.value = 'no' $esxcli.system.ssh.server.config.set.Invoke($arguments)

b
The ESXi host Secure Shell (SSH) daemon must not permit tunnels.
CM-6 - Medium - CCI-000366 - V-258764 - SV-258764r959010_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
ESXI-80-000209
Vuln IDs
  • V-258764
Rule IDs
  • SV-258764r959010_rule
OpenSSH has the ability to create network tunnels (layer 2 and layer 3) over an SSH connection. This function can provide similar convenience to a virtual private network (VPN) with the similar risk of providing a path to circumvent firewalls and network Access Control Lists (ACLs).
Checks: C-62504r933351_chk

From an ESXi shell, run the following command: # esxcli system ssh server config list -k permittunnel or From a PowerCLI command prompt while connected to the ESXi host, run the following commands: $esxcli = Get-EsxCli -v2 $esxcli.system.ssh.server.config.list.invoke() | Where-Object {$_.Key -eq 'permittunnel'} Example result: permittunnel no If "permittunnel" is not configured to "no", this is a finding.

Fix: F-62413r933352_fix

From an ESXi shell, run the following command: # esxcli system ssh server config set -k permittunnel -v no or From a PowerCLI command prompt while connected to the ESXi host, run the following commands: $esxcli = Get-EsxCli -v2 $arguments = $esxcli.system.ssh.server.config.set.CreateArgs() $arguments.keyword = 'permittunnel' $arguments.value = 'no' $esxcli.system.ssh.server.config.set.Invoke($arguments)

a
The ESXi host Secure Shell (SSH) daemon must set a timeout count on idle sessions.
CM-6 - Low - CCI-000366 - V-258765 - SV-258765r959010_rule
RMF Control
CM-6
Severity
L
CCI
CCI-000366
Version
ESXI-80-000210
Vuln IDs
  • V-258765
Rule IDs
  • SV-258765r959010_rule
Setting a timeout ensures that a user login will be terminated as soon as the "ClientAliveCountMax" is reached.
Checks: C-62505r933354_chk

From an ESXi shell, run the following command: # esxcli system ssh server config list -k clientalivecountmax or From a PowerCLI command prompt while connected to the ESXi host, run the following commands: $esxcli = Get-EsxCli -v2 $esxcli.system.ssh.server.config.list.invoke() | Where-Object {$_.Key -eq 'clientalivecountmax'} Example result: clientalivecountmax 3 If "clientalivecountmax" is not configured to "3", this is a finding.

Fix: F-62414r933355_fix

From an ESXi shell, run the following command: # esxcli system ssh server config set -k clientalivecountmax -v 3 or From a PowerCLI command prompt while connected to the ESXi host, run the following commands: $esxcli = Get-EsxCli -v2 $arguments = $esxcli.system.ssh.server.config.set.CreateArgs() $arguments.keyword = 'clientalivecountmax' $arguments.value = '3' $esxcli.system.ssh.server.config.set.Invoke($arguments)

a
The ESXi host Secure Shell (SSH) daemon must set a timeout interval on idle sessions.
CM-6 - Low - CCI-000366 - V-258766 - SV-258766r959010_rule
RMF Control
CM-6
Severity
L
CCI
CCI-000366
Version
ESXI-80-000211
Vuln IDs
  • V-258766
Rule IDs
  • SV-258766r959010_rule
Automatically logging out idle users guards against compromises via hijacked administrative sessions.
Checks: C-62506r933357_chk

From an ESXi shell, run the following command: # esxcli system ssh server config list -k clientaliveinterval or From a PowerCLI command prompt while connected to the ESXi host, run the following commands: $esxcli = Get-EsxCli -v2 $esxcli.system.ssh.server.config.list.invoke() | Where-Object {$_.Key -eq 'clientaliveinterval'} Example result: clientaliveinterval 200 If "clientaliveinterval" is not configured to "200", this is a finding.

Fix: F-62415r933358_fix

From an ESXi shell, run the following command: # esxcli system ssh server config set -k clientaliveinterval -v 200 or From a PowerCLI command prompt while connected to the ESXi host, run the following commands: $esxcli = Get-EsxCli -v2 $arguments = $esxcli.system.ssh.server.config.set.CreateArgs() $arguments.keyword = 'clientaliveinterval' $arguments.value = '200' $esxcli.system.ssh.server.config.set.Invoke($arguments)

b
The ESXi host must disable Simple Network Management Protocol (SNMP) v1 and v2c.
CM-6 - Medium - CCI-000366 - V-258767 - SV-258767r959010_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
ESXI-80-000212
Vuln IDs
  • V-258767
Rule IDs
  • SV-258767r959010_rule
If SNMP is not being used, it must remain disabled. If it is being used, the proper trap destination must be configured. If SNMP is not properly configured, monitoring information can be sent to a malicious host that can use this information to plan an attack.
Checks: C-62507r933360_chk

From an ESXi shell, run the following command: # esxcli system snmp get or From a PowerCLI command prompt while connected to the ESXi host, run the following command: Get-VMHostSnmp | Select * If SNMP is not in use and is enabled, this is a finding. If SNMP is enabled and is not using v3 targets with authentication, this is a finding. Note: SNMP v3 targets can only be viewed and configured via the "esxcli" command.

Fix: F-62416r933361_fix

To disable SNMP from an ESXi shell, run the following command: # esxcli system snmp set -e no or From a PowerCLI command prompt while connected to the ESXi Host: Get-VMHostSnmp | Set-VMHostSnmp -Enabled $false

a
The ESXi host must disable Inter-Virtual Machine (VM) Transparent Page Sharing.
CM-6 - Low - CCI-000366 - V-258768 - SV-258768r959010_rule
RMF Control
CM-6
Severity
L
CCI
CCI-000366
Version
ESXI-80-000213
Vuln IDs
  • V-258768
Rule IDs
  • SV-258768r959010_rule
Published academic papers have demonstrated that by forcing a flush and reload of cache memory, it is possible to measure memory timings to try to determine an Advanced Encryption Standard (AES) encryption key in use on another virtual machine running on the same physical processor of the host server if Transparent Page Sharing (TPS) is enabled between the two VMs. This technique works only in a highly controlled system configured in a nonstandard way that VMware believes would not be recreated in a production environment. Although VMware believes information being disclosed in real-world conditions is unrealistic, out of an abundance of caution, upcoming ESXi update releases will no longer enable TPS between VMs by default (TPS will still be used within individual VMs).
Checks: C-62508r933363_chk

From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host &gt;&gt; Configure &gt;&gt; System &gt;&gt; Advanced System Settings. Select the "Mem.ShareForceSalting" value and verify it is set to "2". or From a PowerCLI command prompt while connected to the ESXi host, run the following command: Get-VMHost | Get-AdvancedSetting -Name Mem.ShareForceSalting If the "Mem.ShareForceSalting" setting is not set to 2, this is a finding.

Fix: F-62417r933364_fix

From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host >> Configure >> System >> Advanced System Settings. Click "Edit". Select the "Mem.ShareForceSalting" value and set it to "2". or From a PowerCLI command prompt while connected to the ESXi host, run the following command: Get-VMHost | Get-AdvancedSetting -Name Mem.ShareForceSalting | Set-AdvancedSetting -Value 2

b
The ESXi host must configure the firewall to block network traffic by default.
CM-6 - Medium - CCI-000366 - V-258769 - SV-258769r1003571_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
ESXI-80-000214
Vuln IDs
  • V-258769
Rule IDs
  • SV-258769r1003571_rule
In addition to service-specific firewall rules, ESXi has a default firewall rule policy to allow or deny incoming and outgoing traffic. Reduce the risk of attack by ensuring this is set to deny incoming and outgoing traffic.
Checks: C-62509r1003533_chk

From an ESXi shell, run the following command: # esxcli network firewall get or From a PowerCLI command prompt while connected to the ESXi host, run the following commands: $esxcli = Get-EsxCli -v2 $esxcli.network.firewall.get.invoke() If the "Default Action" does not equal "DROP", this is a finding. If "Enabled" does not equal "true", this is a finding.

Fix: F-62418r1003534_fix

From an ESXi shell, run the following command: # esxcli network firewall set --default-action false --enabled true or From a PowerCLI command prompt while connected to the ESXi host, run the following commands: $esxcli = Get-EsxCli -v2 $arguments = $esxcli.network.firewall.set.CreateArgs() $arguments.enabled = $true $arguments.defaultaction = $false $esxcli.network.firewall.set.Invoke($arguments)

b
The ESXi host must enable Bridge Protocol Data Units (BPDU) filter on the host to prevent being locked out of physical switch ports with Portfast and BPDU Guard enabled.
CM-6 - Medium - CCI-000366 - V-258770 - SV-258770r959010_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
ESXI-80-000215
Vuln IDs
  • V-258770
Rule IDs
  • SV-258770r959010_rule
BPDU Guard and Portfast are commonly enabled on the physical switch to which the ESXi host is directly connected to reduce the Spanning Tree Protocol (STP) convergence delay. If a BPDU packet is sent from a virtual machine (VM) on the ESXi host to the physical switch configured as stated above, a cascading lockout of all the uplink interfaces from the ESXi host can occur. To prevent this type of lockout, BPDU Filter can be enabled on the ESXi host to drop any BPDU packets being sent to the physical switch. The caveat is that certain Secure Socket Layer (SSL) virtual private networks that use Windows bridging capability can legitimately generate BPDU packets. The administrator should verify no legitimate BPDU packets are generated by VMs on the ESXi host prior to enabling BPDU Filter. If BPDU Filter is enabled in this situation, enabling Reject Forged Transmits on the virtual switch port group adds protection against Spanning Tree loops.
Checks: C-62510r933369_chk

From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host &gt;&gt; Configure &gt;&gt; System &gt;&gt; Advanced System Settings. Select the "Net.BlockGuestBPDU" value and verify it is set to "1". or From a PowerCLI command prompt while connected to the ESXi host, run the following command: Get-VMHost | Get-AdvancedSetting -Name Net.BlockGuestBPDU If the "Net.BlockGuestBPDU" setting is not set to "1", this is a finding.

Fix: F-62419r933370_fix

From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host >> Configure >> System >> Advanced System Settings. Click "Edit". Select the "Net.BlockGuestBPDU" value and configure it to "1". or From a PowerCLI command prompt while connected to the ESXi host, run the following command: Get-VMHost | Get-AdvancedSetting -Name Net.BlockGuestBPDU | Set-AdvancedSetting -Value 1

b
The ESXi host must configure virtual switch security policies to reject forged transmits.
CM-6 - Medium - CCI-000366 - V-258771 - SV-258771r959010_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
ESXI-80-000216
Vuln IDs
  • V-258771
Rule IDs
  • SV-258771r959010_rule
If the virtual machine (VM) operating system changes the Media Access Control (MAC) address, the operating system can send frames with an impersonated source MAC address at any time. This allows an operating system to stage malicious attacks on the devices in a network by impersonating a network adaptor authorized by the receiving network. This means the virtual switch does not compare the source and effective MAC addresses. To protect against MAC address impersonation, all virtual switches must have forged transmissions set to reject. Reject Forged Transmit can be set at the vSwitch and/or the Portgroup level. Switch-level settings can be overridden at the Portgroup level.
Checks: C-62511r933372_chk

Note: This control addresses ESXi standard switches. Distributed switches are addressed in the vCenter STIG. If there is no standard switch on the ESXi host, this is not applicable. From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host &gt;&gt; Configure &gt;&gt; Networking &gt;&gt; Virtual Switches. On each standard switch, click the '...' button next to each port group and select "Edit Settings". Click the "Security" tab. Verify that "Forged transmits" is set to "Reject" and that "Override" is not checked. or From a PowerCLI command prompt while connected to the ESXi host, run the following commands: Get-VirtualSwitch | Get-SecurityPolicy Get-VirtualPortGroup | Get-SecurityPolicy | Select-Object * If the "Forged Transmits" policy is set to "Accept" (or "true", via PowerCLI) or the security policy inherited from the virtual switch is overridden, this is a finding.

Fix: F-62420r933373_fix

From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host >> Configure >> Networking >> Virtual Switches. On each standard switch, click "Edit" and select Security. Set "Forged transmits" to "Reject". Click "OK". For each port group, click the '...' button and select "Edit Settings" then Security. Set "Forged transmits" to "Reject" and uncheck the "Override" box. Click "OK". or From a PowerCLI command prompt while connected to the ESXi host, run the following commands: Get-VirtualSwitch | Get-SecurityPolicy | Set-SecurityPolicy -ForgedTransmits $false Get-VirtualPortGroup | Get-SecurityPolicy | Set-SecurityPolicy -ForgedTransmitsInherited $true

c
The ESXi host must configure virtual switch security policies to reject Media Access Control (MAC) address changes.
CM-6 - High - CCI-000366 - V-258772 - SV-258772r959010_rule
RMF Control
CM-6
Severity
H
CCI
CCI-000366
Version
ESXI-80-000217
Vuln IDs
  • V-258772
Rule IDs
  • SV-258772r959010_rule
If the virtual machine (VM) operating system changes the MAC address, it can send frames with an impersonated source MAC address at any time. This allows it to stage malicious attacks on the devices in a network by impersonating a network adaptor authorized by the receiving network. This will prevent VMs from changing their effective MAC address, which will affect applications that require this functionality. This will also affect how a layer 2 bridge will operate and will affect applications that require a specific MAC address for licensing. "Reject MAC Changes" can be set at the vSwitch and/or the Portgroup level. Switch-level settings can be overridden at the Portgroup level.
Checks: C-62512r933375_chk

This control addresses ESXi standard switches. Distributed switches are addressed in the vCenter STIG. If there is no standard switch on the ESXi host, this is not applicable. From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host &gt;&gt; Configure &gt;&gt; Networking &gt;&gt; Virtual Switches. On each standard switch, click the '...' button next to each port group and select "Edit Settings". Click the "Security" tab. Verify that "MAC Address Changes" is set to "Reject" and that "Override" is not checked. or From a PowerCLI command prompt while connected to the ESXi host, run the following commands: Get-VirtualSwitch | Get-SecurityPolicy Get-VirtualPortGroup | Get-SecurityPolicy | Select-Object * If the "MAC Address Changes" policy is set to "Accept" (or "true", via PowerCLI) or the security policy inherited from the virtual switch is overridden, this is a finding.

Fix: F-62421r933376_fix

From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host >> Configure >> Networking >> Virtual Switches. On each standard switch, click "Edit" and select Security. Set "MAC Address Changes" to "Reject". Click "OK". For each port group, click the '...' button and select "Edit Settings" then Security. Set "MAC Address Changes" to "Reject" and uncheck the "Override" box. Click "OK". or From a PowerCLI command prompt while connected to the ESXi host, run the following commands: Get-VirtualSwitch | Get-SecurityPolicy | Set-SecurityPolicy -MacChanges $false Get-VirtualPortGroup | Get-SecurityPolicy | Set-SecurityPolicy -MacChangesInherited $true

b
The ESXi host must configure virtual switch security policies to reject promiscuous mode requests.
CM-6 - Medium - CCI-000366 - V-258773 - SV-258773r959010_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
ESXI-80-000218
Vuln IDs
  • V-258773
Rule IDs
  • SV-258773r959010_rule
When promiscuous mode is enabled for a virtual switch, all virtual machines (VMs) connected to the Portgroup have the potential to read all packets across that network (only the virtual machines connected to that Portgroup). Promiscuous mode is disabled by default on the ESXi Server, and this is the recommended setting. Promiscuous mode can be set at the vSwitch and/or the Portgroup level. Switch-level settings can be overridden at the Portgroup level.
Checks: C-62513r933378_chk

This control addresses ESXi standard switches. Distributed switches are addressed in the vCenter STIG. If there is no standard switch on the ESXi host, this is not applicable. From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host &gt;&gt; Configure &gt;&gt; Networking &gt;&gt; Virtual Switches. On each standard switch, click the '...' button next to each port group and select "Edit Settings". Click the "Security" tab. Verify that "Promiscuous Mode" is set to "Reject" and that "Override" is not checked. or From a PowerCLI command prompt while connected to the ESXi host, run the following commands: Get-VirtualSwitch | Get-SecurityPolicy Get-VirtualPortGroup | Get-SecurityPolicy | Select-Object * If the "Promiscuous Mode" policy is set to "Accept" (or "true", via PowerCLI) or the security policy inherited from the virtual switch is overridden, this is a finding.

Fix: F-62422r933379_fix

From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host >> Configure >> Networking >> Virtual Switches. On each standard switch, click "Edit" and select Security. Set "Promiscuous Mode" to "Reject". Click "OK". For each port group, click the '...' button and select "Edit Settings" then Security. Set "Promiscuous Mode" to "Reject" and uncheck the "Override" box. Click "OK". or From a PowerCLI command prompt while connected to the ESXi host, run the following commands: Get-VirtualSwitch | Get-SecurityPolicy | Set-SecurityPolicy -AllowPromiscuous $false Get-VirtualPortGroup | Get-SecurityPolicy | Set-SecurityPolicy -AllowPromiscuousInherited $true

b
The ESXi host must restrict use of the dvFilter network application programming interface (API).
CM-6 - Medium - CCI-000366 - V-258774 - SV-258774r959010_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
ESXI-80-000219
Vuln IDs
  • V-258774
Rule IDs
  • SV-258774r959010_rule
If the organization is not using products that use the dvFilter network API, the host should not be configured to send network information to a virtual machine (VM). If the API is enabled, an attacker might attempt to connect a virtual machine to it, potentially providing access to the network of other VMs on the host. If using a product that makes use of this API, verify the host has been configured correctly. If not using such a product, ensure the setting is blank.
Checks: C-62514r933381_chk

From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host &gt;&gt; Configure &gt;&gt; System &gt;&gt; Advanced System Settings. Select the "Net.DVFilterBindIpAddress" value and verify the value is blank or the correct IP address of a security appliance if in use. or From a PowerCLI command prompt while connected to the ESXi host, run the following command: Get-VMHost | Get-AdvancedSetting -Name Net.DVFilterBindIpAddress If the "Net.DVFilterBindIpAddress" setting is not blank and security appliances are not in use on the host, this is a finding.

Fix: F-62423r933382_fix

From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host >> Configure >> System >> Advanced System Settings. Click "Edit". Select the "Net.DVFilterBindIpAddress" value and remove any incorrect addresses. or From a PowerCLI command prompt while connected to the ESXi host, run the following command: Get-VMHost | Get-AdvancedSetting -Name Net.DVFilterBindIpAddress | Set-AdvancedSetting -Value ""

b
The ESXi host must restrict the use of Virtual Guest Tagging (VGT) on standard switches.
CM-6 - Medium - CCI-000366 - V-258775 - SV-258775r959010_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
ESXI-80-000220
Vuln IDs
  • V-258775
Rule IDs
  • SV-258775r959010_rule
When a port group is set to VLAN 4095, the vSwitch passes all network frames to the attached virtual machines (VMs) without modifying the VLAN tags. In vSphere, this is referred to as VGT. The VM must process the VLAN information itself via an 802.1Q driver in the operating system. VLAN 4095 must only be implemented if the attached VMs have been specifically authorized and are capable of managing VLAN tags themselves. If VLAN 4095 is enabled inappropriately, it may cause denial of service or allow a VM to interact with traffic on an unauthorized VLAN.
Checks: C-62515r933384_chk

This control addresses ESXi standard switches. Distributed switches are addressed in the vCenter STIG. If there is no standard switch on the ESXi host, this is not applicable. From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host &gt;&gt; Configure &gt;&gt; Networking &gt;&gt; Virtual Switches. For each standard switch, review the "VLAN ID" on each port group and verify it is not set to "4095". or From a PowerCLI command prompt while connected to the ESXi host, run the following command: Get-VirtualPortGroup | Select Name, VLanID If any port group is configured with VLAN 4095 and is not documented as a needed exception, this is a finding.

Fix: F-62424r933385_fix

From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host >> Configure >> Networking >> Virtual Switches. For each port group on a standard switch that is configured to a native VLAN, click the '...' button next to the port group. Click "Edit Settings". On the "Properties" tab, change the "VLAN ID" to an appropriate VLAN ID. Click "OK". or From a PowerCLI command prompt while connected to the ESXi host, run the following command: Get-VirtualPortGroup -Name "portgroup name" | Set-VirtualPortGroup -VLanId "New VLAN#"

c
The ESXi host must have all security patches and updates installed.
CM-6 - High - CCI-000366 - V-258776 - SV-258776r959010_rule
RMF Control
CM-6
Severity
H
CCI
CCI-000366
Version
ESXI-80-000221
Vuln IDs
  • V-258776
Rule IDs
  • SV-258776r959010_rule
Installing software updates is a fundamental mitigation against the exploitation of publicly known vulnerabilities.
Checks: C-62516r933387_chk

Determine the current version and build: From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host &gt;&gt; Summary. Note the version string next to "Hypervisor:". or From a Secure Shell (SSH) session connected to the ESXi host, or from the ESXi shell, run the following command: # vmware -v If the ESXi host does not have the latest patches, this is a finding. If the ESXi host is not on a supported release, this is a finding. The latest ESXi versions and their build numbers can be found here: https://kb.vmware.com/s/article/2143832 VMware also publishes advisories on security patches and offers a way to subscribe to email alerts for them. Go to: https://www.vmware.com/support/policies/security_response

Fix: F-62425r933388_fix

ESXi can be patched in multiple ways, and this fix text does not cover all methods. Manual patching when image profiles are not used: - Download the latest "offline bundle" .zip update from vmware.com. Verify the hash. - Transfer the file to a datastore accessible by the ESXi host, local or remote. - Put the ESXi host into maintenance mode. - From an ESXi shell, run the following command: esxcli software vib update -d <path to offline patch bundle.zip> Manual patching when image profiles are used: From an ESXi shell, run the following command: # esxcli software sources profile list -d /vmfs/volumes/<your datastore>/<bundle name.zip> Note the available profiles. The organization will usually want the one ending in "-standard". # esxcli software profile update -p <selected profile> -d /vmfs/volumes/<your datastore>/<bundle name.zip> There will be little output during the update. Once complete, reboot the host for changes to take effect.

b
The ESXi host must not suppress warnings that the local or remote shell sessions are enabled.
CM-6 - Medium - CCI-000366 - V-258777 - SV-258777r959010_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
ESXI-80-000222
Vuln IDs
  • V-258777
Rule IDs
  • SV-258777r959010_rule
Warnings that local or remote shell sessions are enabled alert administrators to activity they may not be aware of and need to investigate.
Checks: C-62517r933390_chk

From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host &gt;&gt; Configure &gt;&gt; System &gt;&gt; Advanced System Settings. Select the "UserVars.SuppressShellWarning" value and verify it is set to "0". or From a PowerCLI command prompt while connected to the ESXi host, run the following command: Get-VMHost | Get-AdvancedSetting -Name UserVars.SuppressShellWarning If the "UserVars.SuppressShellWarning" setting is not set to "0", this is a finding.

Fix: F-62426r933391_fix

From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host >> Configure >> System >> Advanced System Settings. Click "Edit". Select the "UserVars.SuppressShellWarning" value and configure it to "0". or From a PowerCLI command prompt while connected to the ESXi host, run the following command: Get-VMHost | Get-AdvancedSetting -Name UserVars.SuppressShellWarning | Set-AdvancedSetting -Value 0

b
The ESXi host must not suppress warnings about unmitigated hyperthreading vulnerabilities.
CM-6 - Medium - CCI-000366 - V-258778 - SV-258778r959010_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
ESXI-80-000223
Vuln IDs
  • V-258778
Rule IDs
  • SV-258778r959010_rule
The L1 Terminal Fault (L1TF) CPU vulnerabilities published in 2018 have patches and mitigations available in vSphere. However, there are performance impacts to these mitigations that require careful thought and planning from the system administrator before implementation. Until a mitigation is implemented, the UI warning about the lack of a mitigation must not be dismissed so the system administrator does not assume the vulnerability has been addressed.
Checks: C-62518r933393_chk

From the vSphere Client go to Hosts and Clusters. Select the ESXi Host &gt;&gt; Configure &gt;&gt; System &gt;&gt; Advanced System Settings. Select the "UserVars.SuppressHyperthreadWarning" value and verify it is set to "0". or From a PowerCLI command prompt while connected to the ESXi host, run the following command: Get-VMHost | Get-AdvancedSetting -Name UserVars.SuppressHyperthreadWarning If the "UserVars.SuppressHyperthreadWarning" setting is not set to "0", this is a finding.

Fix: F-62427r933394_fix

From the vSphere Client go to Hosts and Clusters. Select the ESXi Host >> Configure >> System >> Advanced System Settings. Click "Edit". Select the "UserVars.SuppressHyperthreadWarning" value and configure it to "0". or From a PowerCLI command prompt while connected to the ESXi host, run the following command: Get-VMHost | Get-AdvancedSetting -Name UserVars.SuppressHyperthreadWarning | Set-AdvancedSetting -Value 0

b
The ESXi host must verify certificates for SSL syslog endpoints.
CM-6 - Medium - CCI-000366 - V-258779 - SV-258779r1003572_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
ESXI-80-000224
Vuln IDs
  • V-258779
Rule IDs
  • SV-258779r1003572_rule
When sending syslog data to a remote host, ESXi can be configured to use any combination of TCP, UDP, and SSL transports. When using SSL, the server certificate must be validated to ensure that the host is connecting to a valid syslog server.
Checks: C-62519r1003536_chk

If SSL is not used for a syslog target, this is not applicable. From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host &gt;&gt; Configure &gt;&gt; System &gt;&gt; Advanced System Settings. Select the "Syslog.global.certificate.checkSSLCerts" value and verify it is set to "true". or From a PowerCLI command prompt while connected to the ESXi host, run the following command: Get-VMHost | Get-AdvancedSetting -Name Syslog.global.certificate.checkSSLCerts If the "Syslog.global.certificate.checkSSLCerts" setting is not set to "true", this is a finding.

Fix: F-62428r1003537_fix

To configure SSL syslog endpoint certificate checking, it must be turned on and the trusted certificate chain must be added to ESXi's trusted store. From the vSphere Client go to Hosts and Clusters. Select the ESXi Host >> Configure >> System >> Advanced System Settings. Click "Edit". Select the "Syslog.global.certificate.checkSSLCerts" value and configure it to "true". Copy the PEM formatted trusted CA certificate so that is accessible to the host and append the contents to /etc/vmware/ssl/castore.pem by running the following command: # <path/to/cacert> >> /etc/vmware/ssl/castore.pem or From a PowerCLI command prompt while connected to the ESXi host, run the following commands: Get-VMHost | Get-AdvancedSetting -Name Syslog.global.certificate.checkSSLCerts | Set-AdvancedSetting -Value "true" Copy the PEM formatted trusted CA certificate so that is accessible to the host. $esxcli = Get-EsxCli -v2 $arguments = $esxcli.system.security.certificatestore.add.CreateArgs() $arguments.filename = <path/to/cacert> $esxcli.system.security.certificatestore.add.Invoke($arguments)

b
The ESXi host must enable volatile key destruction.
CM-6 - Medium - CCI-000366 - V-258780 - SV-258780r959010_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
ESXI-80-000225
Vuln IDs
  • V-258780
Rule IDs
  • SV-258780r959010_rule
By default, pages allocated for virtual machines (VMs), userspace applications, and kernel threads are zeroed out at allocation time. ESXi will always ensure that no nonzero pages are exposed to VMs or userspace applications. While this prevents exposing cryptographic keys from VMs or userworlds to other clients, these keys can stay present in host memory for a long time if the memory is not reused. The NIAP Virtualization Protection Profile and Server Virtualization Extended Package require that memory that may contain cryptographic keys be zeroed upon process exit. To this end, a new configuration option, MemEagerZero, can be configured to enforce zeroing out 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 needed.
Checks: C-62520r933399_chk

From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host &gt;&gt; Configure &gt;&gt; System &gt;&gt; Advanced System Settings. Select the "Mem.MemEagerZero" value and verify it is set to "1". or From a PowerCLI command prompt while connected to the ESXi host, run the following command: Get-VMHost | Get-AdvancedSetting -Name Mem.MemEagerZero If the "Mem.MemEagerZero" setting is not set to "1", this is a finding.

Fix: F-62429r933400_fix

From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host >> Configure >> System >> Advanced System Settings. Click "Edit". Select the "Mem.MemEagerZero" value and configure it to "1". or From a PowerCLI command prompt while connected to the ESXi host, run the following command: Get-VMHost | Get-AdvancedSetting -Name Mem.MemEagerZero | Set-AdvancedSetting -Value 1

b
The ESXi host must configure a session timeout for the vSphere API.
CM-6 - Medium - CCI-000366 - V-258781 - SV-258781r959010_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
ESXI-80-000226
Vuln IDs
  • V-258781
Rule IDs
  • SV-258781r959010_rule
The vSphere API (VIM) allows for remote, programmatic administration of the ESXi host. Authenticated API sessions are no different from a risk perspective than authenticated UI sessions and they need similar protections. One of these protections is a basic inactivity timeout, after which the session will be invalidated and reauthentication will be required by the application accessing the API. This is set to 30 seconds by default but can be disabled, thus leaving API sessions open indefinitely. The 30 second default must be verified and maintained.
Checks: C-62521r933402_chk

From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host &gt;&gt; Configure &gt;&gt; System &gt;&gt; Advanced System Settings. Select the "Config.HostAgent.vmacore.soap.sessionTimeout" value and verify it is set to "30". or From a PowerCLI command prompt while connected to the ESXi host, run the following command: Get-VMHost | Get-AdvancedSetting -Name Config.HostAgent.vmacore.soap.sessionTimeout If the "Config.HostAgent.vmacore.soap.sessionTimeout" setting is not set to "30", this is a finding.

Fix: F-62430r933403_fix

From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host >> Configure >> System >> Advanced System Settings. Click "Edit". Select the "Config.HostAgent.vmacore.soap.sessionTimeout" value and configure it to "30". or From a PowerCLI command prompt while connected to the ESXi host, run the following command: Get-VMHost | Get-AdvancedSetting -Name Config.HostAgent.vmacore.soap.sessionTimeout | Set-AdvancedSetting -Value 30

b
The ESXi host must be configured with an appropriate maximum password age.
CM-6 - Medium - CCI-000366 - V-258782 - SV-258782r959010_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
ESXI-80-000227
Vuln IDs
  • V-258782
Rule IDs
  • SV-258782r959010_rule
The older an ESXi local account password is, the larger the opportunity window is for attackers to guess, crack or reuse a previously cracked password. Rotating passwords on a regular basis is a fundamental security practice and one that ESXi supports.
Checks: C-62522r933405_chk

From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host &gt;&gt; Configure &gt;&gt; System &gt;&gt; Advanced System Settings. Select the "Security.PasswordMaxDays" value and verify it is set to "90". or From a PowerCLI command prompt while connected to the ESXi host, run the following command: Get-VMHost | Get-AdvancedSetting -Name Security.PasswordMaxDays If the "Security.PasswordMaxDays" setting is not set to "90", this is a finding.

Fix: F-62431r933406_fix

From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host >> Configure >> System >> Advanced System Settings. Click "Edit". Select the "Security.PasswordMaxDays" value and configure it to "90". or From a PowerCLI command prompt while connected to the ESXi host, run the following command: Get-VMHost | Get-AdvancedSetting -Name Security.PasswordMaxDays | Set-AdvancedSetting -Value 90

b
The ESXi Common Information Model (CIM) service must be disabled.
CM-6 - Medium - CCI-000366 - V-258783 - SV-258783r959010_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
ESXI-80-000228
Vuln IDs
  • V-258783
Rule IDs
  • SV-258783r959010_rule
The CIM system provides an interface that enables hardware-level management from remote applications via a set of standard application programming interfaces (APIs). These APIs are consumed by external applications such as HP SIM or Dell OpenManage for agentless, remote hardware monitoring of the ESXi host. To reduce attack surface area and following the minimum functionality principal, the CIM service must be disabled unless explicitly needed and approved.
Checks: C-62523r933408_chk

From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host &gt;&gt; Configure &gt;&gt; System &gt;&gt; Services. Under "Services", locate the "CIM Server" service and verify it is "Stopped" and the "Startup Policy" is set to "Start and stop manually". or From a PowerCLI command prompt while connected to the ESXi host, run the following command: Get-VMHost | Get-VMHostService | Where {$_.Label -eq "CIM Server"} If the "CIM Server" service does not have a "Policy" of "off" or is running, this is a finding.

Fix: F-62432r933409_fix

From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host >> Configure >> System >> Services. Under "Services" select the "CIM Server" service and click the "Stop" button. Click "Edit Startup policy..." and select the "Start and stop manually" radio button. Click "OK". or From a PowerCLI command prompt while connected to the ESXi host, run the following commands: Get-VMHost | Get-VMHostService | Where {$_.Label -eq "CIM Server"} | Set-VMHostService -Policy Off Get-VMHost | Get-VMHostService | Where {$_.Label -eq "CIM Server"} | Stop-VMHostService

b
The ESXi host must use DOD-approved certificates.
CM-6 - Medium - CCI-000366 - V-258784 - SV-258784r959010_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
ESXI-80-000229
Vuln IDs
  • V-258784
Rule IDs
  • SV-258784r959010_rule
The default self-signed host certificate issued by the VMware Certificate Authority (VMCA) must be replaced with a DOD-approved certificate when the host will be accessed directly, such as during a virtual machine (VM) console connection. The use of a DOD certificate on the host assures clients the service they are connecting to is legitimate and properly secured.
Checks: C-62524r933411_chk

From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host &gt;&gt; Configure &gt;&gt; System &gt;&gt; Certificate. If the issuer is not a DOD-approved certificate authority, this is a finding. If the host will never be accessed directly (virtual machine console connections bypass vCenter), this is not a finding.

Fix: F-62433r933412_fix

Join the ESXi host to vCenter before replacing the certificate. Obtain a DOD-issued certificate and private key for the host following the requirements below: Key size: 2048 bits or more (PEM encoded) Key format: PEM VMware supports PKCS8 and PKCS1 (RSA keys) x509 version 3 SubjectAltName must contain DNS Name=<machine_FQDN> CRT (Base-64) format Contains the following Key Usages: Digital Signature, Non Repudiation, Key Encipherment Start time of one day before the current time CN (and SubjectAltName) set to the host name (or IP address) that the ESXi host has in the vCenter Server inventory From the vSphere Web Client, select the ESXi host's vCenter Server >> Configure >> System >> Advanced Settings. Select the "vpxd.certmgmt.mode" value and ensure it is set to "custom". Put the host into maintenance mode. Temporarily enable Secure Shell (SSH) on the host. Use Secure Copy Protocol (SCP) to transfer the new certificate and key to /tmp. SSH to the host. Back up the existing certificate and key: # mv /etc/vmware/ssl/rui.crt /etc/vmware/ssl/rui.crt.bak # mv /etc/vmware/ssl/rui.key /etc/vmware/ssl/rui.key.bak Copy the new certificate and key to "/etc/vmware/ssl/" and rename them to "rui.crt" and "rui.key" respectively. Restart management agents to implement the new certificate: # services.sh restart

b
The ESXi host Secure Shell (SSH) daemon must disable port forwarding.
CM-6 - Medium - CCI-000366 - V-258785 - SV-258785r959010_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
ESXI-80-000230
Vuln IDs
  • V-258785
Rule IDs
  • SV-258785r959010_rule
While enabling Transmission Control Protocol (TCP) tunnels is a valuable function of sshd, this feature is not appropriate for use on the ESXi hypervisor.
Checks: C-62525r933414_chk

From an ESXi shell, run the following command: # esxcli system ssh server config list -k allowtcpforwarding or From a PowerCLI command prompt while connected to the ESXi host, run the following commands: $esxcli = Get-EsxCli -v2 $esxcli.system.ssh.server.config.list.invoke() | Where-Object {$_.Key -eq 'allowtcpforwarding'} Example result: allowtcpforwarding no If "allowtcpforwarding" is not configured to "no", this is a finding.

Fix: F-62434r933415_fix

From an ESXi shell, run the following command: # esxcli system ssh server config set -k allowtcpforwarding -v no or From a PowerCLI command prompt while connected to the ESXi host, run the following commands: $esxcli = Get-EsxCli -v2 $arguments = $esxcli.system.ssh.server.config.set.CreateArgs() $arguments.keyword = 'allowtcpforwarding' $arguments.value = 'no' $esxcli.system.ssh.server.config.set.Invoke($arguments)

b
The ESXi host OpenSLP service must be disabled.
CM-6 - Medium - CCI-000366 - V-258786 - SV-258786r959010_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
ESXI-80-000231
Vuln IDs
  • V-258786
Rule IDs
  • SV-258786r959010_rule
OpenSLP implements the Service Location Protocol to help CIM clients discover CIM servers over TCP 427. This service is not widely needed and has had vulnerabilities exposed in the past. To reduce attack surface area and following the minimum functionality principal, the OpenSLP service must be disabled unless explicitly needed and approved. Note: Disabling the OpenSLP service may affect monitoring and third-party systems that use the WBEM DTMF protocols.
Checks: C-62526r933417_chk

From the vSphere Client go to Hosts and Clusters. Select the ESXi Host &gt;&gt; Configure &gt;&gt; System &gt;&gt; Services. Under "Services", locate the "slpd" service and verify it is "Stopped" and the "Startup Policy" is set to "Start and stop manually". or From a PowerCLI command prompt while connected to the ESXi host, run the following command: Get-VMHost | Get-VMHostService | Where {$_.Label -eq "slpd"} If the slpd service does not have a "Policy" of "off" or is running, this is a finding.

Fix: F-62435r933418_fix

From the vSphere Client go to Hosts and Clusters. Select the ESXi Host >> Configure >> System >> Services. Under "Services" select the "slpd" service and click the "Stop" button. Click "Edit Startup policy..." and select the "Start and stop manually" radio button. Click "OK". or From a PowerCLI command prompt while connected to the ESXi host, run the following commands: Get-VMHost | Get-VMHostService | Where {$_.Label -eq "slpd"} | Set-VMHostService -Policy Off Get-VMHost | Get-VMHostService | Where {$_.Label -eq "slpd"} | Stop-VMHostService

b
The ESXi host must enable audit logging.
CM-6 - Medium - CCI-000366 - V-258787 - SV-258787r1003573_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
ESXI-80-000232
Vuln IDs
  • V-258787
Rule IDs
  • SV-258787r1003573_rule
ESXi offers both local and remote audit recordkeeping to meet the requirements of the NIAP Virtualization Protection Profile and Server Virtualization Extended Package. Local records are stored on any accessible local or VMFS path. Remote records are sent to the global syslog servers configured elsewhere. To operate in the NIAP validated state, ESXi must enable and properly configure this audit system. This system is disabled by default. Note: Audit records can be viewed locally via the "/bin/viewAudit" utility over SSH or at the ESXi shell.
Checks: C-62527r933420_chk

From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host &gt;&gt; Configure &gt;&gt; System &gt;&gt; Advanced System Settings. Select the "Syslog.global.auditRecord.storageEnable" value and verify it is set to "true". or From a PowerCLI command prompt while connected to the ESXi host, run the following command: Get-VMHost | Get-AdvancedSetting -Name Syslog.global.auditRecord.storageEnable If the "Syslog.global.auditRecord.storageEnable" setting is not set to "true", this is a finding.

Fix: F-62436r1003539_fix

Note: ESXI-80-000113 and ESXI-80-000243 must be configured and validated prior to enabling audit logging. From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host >> Configure >> System >> Advanced System Settings. Click "Edit". Select the "Syslog.global.auditRecord.storageEnable" value and configure it to "true". or From a PowerCLI command prompt while connected to the ESXi host, run the following command: Get-VMHost | Get-AdvancedSetting -Name Syslog.global.auditRecord.storageEnable | Set-AdvancedSetting -Value "true"

b
The ESXi host must off-load audit records via syslog.
AU-4 - Medium - CCI-001851 - V-258788 - SV-258788r958754_rule
RMF Control
AU-4
Severity
M
CCI
CCI-001851
Version
ESXI-80-000233
Vuln IDs
  • V-258788
Rule IDs
  • SV-258788r958754_rule
ESXi offers both local and remote audit recordkeeping to meet the requirements of the NIAP Virtualization Protection Profile and Server Virtualization Extended Package. Local records are stored on any accessible local or VMFS path. Remote records are sent to the global syslog servers configured elsewhere. To operate in the NIAP-validated state, ESXi must enable and properly configure this audit system. This system is disabled by default. Note: Audit records can be viewed locally via the "/bin/viewAudit" utility over SSH or at the ESXi shell.
Checks: C-62528r933423_chk

From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host &gt;&gt; Configure &gt;&gt; System &gt;&gt; Advanced System Settings. Select the "Syslog.global.auditRecord.remoteEnable" value and verify it is set to "true". or From a PowerCLI command prompt while connected to the ESXi host, run the following command: Get-VMHost | Get-AdvancedSetting -Name Syslog.global.auditRecord.remoteEnable If the "Syslog.global.auditRecord.remoteEnable" setting is not set to "true", this is a finding.

Fix: F-62437r933424_fix

From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host >> Configure >> System >> Advanced System Settings. Click "Edit". Select the "Syslog.global.auditRecord.remoteEnable" value and configure it to "true". or From a PowerCLI command prompt while connected to the ESXi host, run the following command: Get-VMHost | Get-AdvancedSetting -Name Syslog.global.auditRecord.remoteEnable | Set-AdvancedSetting -Value "true"

b
The ESXi host must enable strict x509 verification for SSL syslog endpoints.
CM-6 - Medium - CCI-000366 - V-258789 - SV-258789r959010_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
ESXI-80-000234
Vuln IDs
  • V-258789
Rule IDs
  • SV-258789r959010_rule
When sending syslog data to a remote host via SSL, the ESXi host is presented with the endpoint's SSL server certificate. In addition to trust verification, configured elsewhere, this "x509-strict" option performs additional validity checks on CA root certificates during verification. These checks are generally not performed (CA roots are inherently trusted) and might cause incompatibilities with existing, misconfigured CA roots. The NIAP requirements in the Virtualization Protection Profile and Server Virtualization Extended Package, however, require even CA roots to pass validations.
Checks: C-62529r933426_chk

If SSL is not used for a syslog target, this is not applicable. From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host &gt;&gt; Configure &gt;&gt; System &gt;&gt; Advanced System Settings. Select the "Syslog.global.certificate.strictX509Compliance" value and verify it is set to "true". or From a PowerCLI command prompt while connected to the ESXi host, run the following command: Get-VMHost | Get-AdvancedSetting -Name Syslog.global.certificate.strictX509Compliance If the "Syslog.global.certificate.strictX509Compliance" setting is not set to "true", this is a finding.

Fix: F-62438r933427_fix

From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host >> Configure >> System >> Advanced System Settings. Click "Edit". Select the "Syslog.global.certificate.strictX509Compliance" value and configure it to "true". or From a PowerCLI command prompt while connected to the ESXi host, run the following command: Get-VMHost | Get-AdvancedSetting -Name Syslog.global.certificate.strictX509Compliance | Set-AdvancedSetting -Value "true"

b
The ESXi host must forward audit records containing information to establish what type of events occurred.
AU-3 - Medium - CCI-000130 - V-258790 - SV-258790r958412_rule
RMF Control
AU-3
Severity
M
CCI
CCI-000130
Version
ESXI-80-000235
Vuln IDs
  • V-258790
Rule IDs
  • SV-258790r958412_rule
Without establishing what types of events occurred, it would be difficult to establish, correlate, and investigate the events leading up to an outage or attack. Audit record content that may be necessary to satisfy this requirement includes, for example, time stamps, source and destination addresses, user/process/VM identifiers, event descriptions, success/fail indications, filenames involved, and access control or flow control rules invoked. Associating event types with detected events in the ESXi audit logs provides a means of investigating an attack; recognizing resource utilization or capacity thresholds; or identifying an improperly configured host.
Checks: C-62530r933429_chk

From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host &gt;&gt; Configure &gt;&gt; System &gt;&gt; Advanced System Settings. Select the "Syslog.global.logLevel" value and verify it is set to "info". or From a PowerCLI command prompt while connected to the ESXi host, run the following command: Get-VMHost | Get-AdvancedSetting -Name Syslog.global.logLevel If the "Syslog.global.logLevel" setting is not set to "info", this is a finding. Note: Verbose logging level is acceptable for troubleshooting purposes.

Fix: F-62439r933430_fix

From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host >> Configure >> System >> Advanced System Settings. Click "Edit". Select the "Syslog.global.logLevel" value and configure it to "info". or From a PowerCLI command prompt while connected to the ESXi host, run the following command: Get-VMHost | Get-AdvancedSetting -Name Syslog.global.logLevel | Set-AdvancedSetting -Value "info"

b
The ESXi host must not be configured to override virtual machine (VM) configurations.
CM-6 - Medium - CCI-000366 - V-258791 - SV-258791r959010_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
ESXI-80-000236
Vuln IDs
  • V-258791
Rule IDs
  • SV-258791r959010_rule
Each VM on an ESXi host runs in its own "vmx" process. Upon creation, a vmx process will look in two locations for configuration items, the ESXi host itself and the per-vm *.vmx file in the VM storage path on the datastore. The settings on the ESXi host are read first and take precedence over settings in the *.vmx file. This can be a convenient way to set a setting in one place and have it apply to all VMs running on that host. The difficulty is in managing those settings and determining the effective state. Since managing per-VM vmx settings can be fully automated and customized while the ESXi setting cannot be easily queried, the ESXi configuration must not be used.
Checks: C-62531r933432_chk

From an ESXi shell, run the following command: # stat -c "%s" /etc/vmware/settings Expected result: 0 If the output does not match the expected result, this is a finding.

Fix: F-62440r933433_fix

From an ESXi shell, run the following command: # echo -n >/etc/vmware/settings

b
The ESXi host must not be configured to override virtual machine (VM) logger settings.
CM-6 - Medium - CCI-000366 - V-258792 - SV-258792r959010_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
ESXI-80-000237
Vuln IDs
  • V-258792
Rule IDs
  • SV-258792r959010_rule
Each VM on an ESXi host runs in its own "vmx" process. Upon creation, a vmx process will look in two locations for configuration items, the ESXi host itself and the per-vm *.vmx file in the VM storage path on the datastore. The settings on the ESXi host are read first and take precedence over settings in the *.vmx file. This can be a convenient way to set a setting in one place and have it apply to all VMs running on that host. The difficulty is in managing those settings and determining the effective state. Since managing per-VM vmx settings can be fully automated and customized while the ESXi setting cannot be easily queried, the ESXi configuration must not be used.
Checks: C-62532r933435_chk

From an ESXi shell, run the following command: # grep "^vmx\.log" /etc/vmware/config If the command produces any output, this is a finding.

Fix: F-62441r933436_fix

From an ESXi shell, run the following commands: # cp /etc/vmware/config /etc/vmware/config.bak # grep -v "^vmx\.log" /etc/vmware/config.bak>/etc/vmware/config

b
The ESXi host must require TPM-based configuration encryption.
CM-6 - Medium - CCI-000366 - V-258793 - SV-258793r959010_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
ESXI-80-000238
Vuln IDs
  • V-258793
Rule IDs
  • SV-258793r959010_rule
An ESXi host's configuration 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, it 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, the ESXi host must be told to reconfigure to use the newly available TPM. Once the TPM configuration encryption is enabled, it cannot be disabled.
Checks: C-62533r933438_chk

If the ESXi host does not have a compatible TPM, this finding is downgraded to a CAT III. From an ESXi shell, run the following command: # esxcli system settings encryption get or From a PowerCLI command prompt while connected to the ESXi host, run the following commands: $esxcli = Get-EsxCli -v2 $esxcli.system.settings.encryption.get.invoke() | Select Mode Expected result: Mode: TPM If the "Mode" is not set to "TPM", this is a finding.

Fix: F-62442r933439_fix

Ensure the TPM 2.0 chip is enabled in the BIOS and the ESX UI does not show any errors about a present but unavailable TPM. This setting cannot be configured until the TPM is properly enabled in firmware. From an ESXi shell, run the following command: # esxcli system settings encryption set --mode=TPM or From a PowerCLI command prompt while connected to the ESXi host, run the following commands: $esxcli = Get-EsxCli -v2 $arguments = $esxcli.system.settings.encryption.set.CreateArgs() $arguments.mode = "TPM" $esxcli.system.settings.encryption.set.Invoke($arguments) Enter the host into maintenance mode and reboot for changes to take effect.

b
The ESXi host must configure the firewall to restrict access to services running on the host.
CM-6 - Medium - CCI-000366 - V-258794 - SV-258794r1003574_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
ESXI-80-000239
Vuln IDs
  • V-258794
Rule IDs
  • SV-258794r1003574_rule
Unrestricted access to services running on an ESXi host can expose a host to outside attacks and unauthorized access. Reduce the risk by configuring the ESXi firewall to only allow access from authorized networks.
Checks: C-62534r1003541_chk

From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host &gt;&gt; Configure &gt;&gt; System &gt;&gt; Firewall. Under the "Allowed IP addresses" column, review the allowed IPs for each service. Check this for "Incoming" and "Outgoing" sections. or From a PowerCLI command prompt while connected to the ESXi host, run the following command: Get-VMHost | Get-VMHostFirewallException | Where {($_.Enabled -eq $true) -and ($_.ExtensionData.IpListUserConfigurable -eq $true)} | Select Name,Enabled,@{N="AllIPEnabled";E={$_.ExtensionData.AllowedHosts.AllIP}},@{N="AllIPUserConfigurable";E={$_.ExtensionData.IpListUserConfigurable}} If "Allow connections from any IP address" is configured on a user-configurable enabled service, this is a finding. Note: In vSphere 8 U2 firewall rules were categorized as user or system owned for both enabling/disabling and configuring the allowed IP addresses. This control is only applicable for rules in which a user can configure the allowed IP addresses.

Fix: F-62443r1003542_fix

From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host >> Configure >> System >> Firewall. Click "Edit...". For each user-configurable enabled service, uncheck the check box to "Allow connections from any IP address" and input the site-specific network(s) required. The following example formats are acceptable: 192.168.0.0/24 192.168.1.2, 2001::1/64 fd3e:29a6:0a81:e478::/64 or From a PowerCLI command prompt while connected to the ESXi host, run the following commands: $esxcli = Get-EsxCli -v2 #This disables the allow all rule for the target service. The sshServer service is the target in this example. $arguments = $esxcli.network.firewall.ruleset.set.CreateArgs() $arguments.rulesetid = "sshServer" $arguments.allowedall = $false $esxcli.network.firewall.ruleset.set.Invoke($arguments) #Next add the allowed IPs for the service. Note that executing the "vSphere Web Client" service this way may disable access but may be done through vCenter or through the console. $arguments = $esxcli.network.firewall.ruleset.allowedip.add.CreateArgs() $arguments.rulesetid = "sshServer" $arguments.ipaddress = "10.0.0.0/8" $esxcli.network.firewall.ruleset.allowedip.add.Invoke($arguments) This must be done for each user-configurable enabled service.

b
The ESXi host when using Host Profiles and/or Auto Deploy must use the vSphere Authentication Proxy to protect passwords when adding themselves to Active Directory.
CM-6 - Medium - CCI-000366 - V-258795 - SV-258795r959010_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
ESXI-80-000240
Vuln IDs
  • V-258795
Rule IDs
  • SV-258795r959010_rule
If a host is configured to join an Active Directory domain using Host Profiles and/or Auto Deploy, the Active Directory credentials are saved in the profile and are transmitted over the network. To avoid having to save Active Directory credentials in the Host Profile and to avoid transmitting Active Directory credentials over the network, use the vSphere Authentication Proxy.
Checks: C-62535r933444_chk

For environments that do not use vCenter server to manage ESXi, this is not applicable. If the organization is not using Host Profiles to join Active Directory, this is not applicable. From the vSphere Client, go to Home &gt;&gt; Policies and Profiles &gt;&gt; Host Profiles. Click a Host Profile &gt;&gt; Configure &gt;&gt; Security and Services &gt;&gt; Security Settings &gt;&gt; Authentication Configuration &gt;&gt; Active Directory Configuration &gt;&gt; Join Domain Method. If the method used to join hosts to a domain is not set to "Use vSphere Authentication Proxy to add the host to domain", this is a finding. or From a PowerCLI command prompt while connected to vCenter, run the following command: Get-VMHost | Select Name, ` @{N="HostProfile";E={$_ | Get-VMHostProfile}}, ` @{N="JoinADEnabled";E={($_ | Get-VmHostProfile).ExtensionData.Config.ApplyProfile.Authentication.ActiveDirectory.Enabled}}, ` @{N="JoinDomainMethod";E={(($_ | Get-VMHostProfile).ExtensionData.Config.ApplyProfile.Authentication.ActiveDirectory | Select -ExpandProperty Policy | Where {$_.Id -eq "JoinDomainMethodPolicy"}).Policyoption.Id}} If "JoinADEnabled" is "True" and "JoinDomainMethod" is not "FixedCAMConfigOption", this is a finding.

Fix: F-62444r933445_fix

From the vSphere Client, go to Home >> Policies and Profiles >> Host Profiles. Click a Host Profile >> Configure >> Security and Services >> Security Settings >> Authentication Configuration >> Active Directory Configuration. Click "Edit Host Profile...". Set the "Join Domain Method" to "Use vSphere Authentication Proxy to add the host to domain" and provide the IP address of the vSphere Authentication Proxy server. Click "Save".

b
The ESXi host must not use the default Active Directory ESX Admin group.
CM-6 - Medium - CCI-000366 - V-258796 - SV-258796r959010_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
ESXI-80-000241
Vuln IDs
  • V-258796
Rule IDs
  • SV-258796r959010_rule
When adding ESXi hosts to Active Directory, all user/group accounts assigned to the Active Directory group "ESX Admins" will have full administrative access to the host. If this group is not controlled or known to the system administrators, it may be used for inappropriate access to the host. Therefore, the default group must be changed to a site-specific Active Directory group and membership must be severely restricted.
Checks: C-62536r933447_chk

For systems that do not use Active Directory, this is not applicable. From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host &gt;&gt; Configure &gt;&gt; System &gt;&gt; Advanced System Settings. Select the "Config.HostAgent.plugins.hostsvc.esxAdminsGroup" value and verify it is not set to "ESX Admins". or From a PowerCLI command prompt while connected to the ESXi host, run the following command: Get-VMHost | Get-AdvancedSetting -Name Config.HostAgent.plugins.hostsvc.esxAdminsGroup If the "Config.HostAgent.plugins.hostsvc.esxAdminsGroup" setting is set to "ESX Admins", this is a finding.

Fix: F-62445r933448_fix

From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host >> Configure >> System >> Advanced System Settings. Click "Edit". Select the "Config.HostAgent.plugins.hostsvc.esxAdminsGroup" key and configure its value to an appropriate Active Directory group other than "ESX Admins". or From a PowerCLI command prompt while connected to the ESXi host, run the following command: Get-VMHost | Get-AdvancedSetting -Name Config.HostAgent.plugins.hostsvc.esxAdminsGroup | Set-AdvancedSetting -Value "<site specific AD group>" Note: Changing the group name does not remove the permissions of the previous group.

b
The ESXi host must configure a persistent log location for all locally stored logs.
AU-4 - Medium - CCI-001849 - V-258797 - SV-258797r1003575_rule
RMF Control
AU-4
Severity
M
CCI
CCI-001849
Version
ESXI-80-000243
Vuln IDs
  • V-258797
Rule IDs
  • SV-258797r1003575_rule
ESXi can be configured to store log files on an in-memory file system. This occurs when the host's "/scratch" directory is linked to "/tmp/scratch". When this is done, only a single day's worth of logs are stored at any time. In addition, log files will be reinitialized upon each reboot. This presents a security risk as user activity logged on the host is only stored temporarily and will not persist across reboots. This can also complicate auditing and make it harder to monitor events and diagnose issues. ESXi host logging should always be configured to a persistent datastore. Note: Scratch space is configured automatically during installation or first boot of an ESXi host and does not usually need to be configured manually. If ESXi is installed on an SD card or USB device, a persistent log location may not be configured upon install as normal.
Checks: C-62537r933450_chk

From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host &gt;&gt; Configure &gt;&gt; System &gt;&gt; Advanced System Settings. Select the "Syslog.global.logDir" value and verify it is set to a persistent location. If the value of the setting is "[] /scratch/logs", verify the advanced setting "ScratchConfig.CurrentScratchLocation" is not set to "/tmp/scratch". This is a nonpersistent location. If "Syslog.global.logDir" is not configured to a persistent location, this is a finding. or From a PowerCLI command prompt while connected to the ESXi host, run the following commands: $esxcli = Get-EsxCli -v2 $esxcli.system.syslog.config.get.Invoke() | Select LocalLogOutput,LocalLogOutputIsPersistent If the "LocalLogOutputIsPersistent" value is not true, this is a finding.

Fix: F-62446r1003544_fix

From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host >> Configure >> System >> Advanced System Settings. Click "Edit". Select the "Syslog.global.logDir" value and set it to a known persistent location. An example is shown below, where 51dda02d-fade5016-8a08-005056171889 is the UUID of the target datastore: /vmfs/volumes/51dda02d-fade5016-8a08-005056171889 or From a PowerCLI command prompt while connected to the ESXi host, run the following command: Get-VMHost | Get-AdvancedSetting -Name Syslog.global.logDir | Set-AdvancedSetting -Value "New Log Location" Note: The new location should not include a subfolder as enabling audit logging will create a folder and will fail if a subfolder is specified.

b
The ESXi host must enforce the exclusive running of executables from approved VIBs.
CM-6 - Medium - CCI-000366 - V-258798 - SV-258798r959010_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
ESXI-80-000244
Vuln IDs
  • V-258798
Rule IDs
  • SV-258798r959010_rule
The "execInstalledOnly" advanced ESXi boot option, when set to TRUE, guarantees that the VMkernel executes only those binaries that have been packaged as part of a signed VIB. While this option is effective on its own, it can be further enhanced by telling the Secure Boot to check with the TPM to make sure that the boot process does not proceed unless this setting is enabled. This further protects against malicious offline changes to ESXi configuration to disable the "execInstalledOnly" option.
Checks: C-62538r933453_chk

If the ESXi host does not have a compatible TPM, this finding is downgraded to a CAT III. From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host &gt;&gt; Configure &gt;&gt; System &gt;&gt; Advanced System Settings. Select the "VMkernel.Boot.execInstalledOnly" value and verify that it is "true". or From a PowerCLI command prompt while connected to the ESXi host, run the following command: Get-VMHost | Get-AdvancedSetting -Name VMkernel.Boot.execInstalledOnly If the "VMkernel.Boot.execInstalledOnly" setting is not "true", this is a finding.

Fix: F-62447r933454_fix

From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host >> Configure >> System >> Advanced System Settings. Click "Edit". Select the "VMkernel.Boot.execInstalledOnly" value and configure it to "true". or From a PowerCLI command prompt while connected to the ESXi host, run the following command: Get-VMHost | Get-AdvancedSetting -Name VMkernel.Boot.execInstalledOnly | Set-AdvancedSetting -Value True

b
The ESXi host must use sufficient entropy for cryptographic operations.
CM-6 - Medium - CCI-000366 - V-258799 - SV-258799r959010_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
ESXI-80-000245
Vuln IDs
  • V-258799
Rule IDs
  • SV-258799r959010_rule
Starting in vSphere 8.0, 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. In computing, the term "entropy" refers to random characters and data that are collected for use in cryptography, such as generating encryption keys to secure data transmitted over a network. Entropy is required by security for generating keys and communicating securely over the network. Entropy is often collected from a variety of sources on a system. FIPS entropy handling is the default behavior if the following conditions are true: -The hardware supports RDSEED. -The disableHwrng VMkernel boot option is not present or is FALSE. -The entropySources VMkernel boot option is not present or is 0 (zero).
Checks: C-62539r933456_chk

From an ESXi shell, run the following commands: # esxcli system settings kernel list -o disableHwrng # esxcli system settings kernel list -o entropySources or From a PowerCLI command prompt while connected to the ESXi host, run the following commands: $esxcli = Get-EsxCli -v2 $esxcli.system.settings.kernel.list.invoke() | Where {$_.Name -eq "disableHwrng" -or $_.Name -eq "entropySources"} If "disableHwrng" is not set to "false", this is a finding. If "entropySources" is not set to "0", this is a finding.

Fix: F-62448r933457_fix

From an ESXi shell, run the following commands: # esxcli system settings kernel set -s disableHwrng -v FALSE # esxcli system settings kernel set -s entropySources -v 0 or From a PowerCLI command prompt while connected to the ESXi host, run the following commands: $esxcli = Get-EsxCli -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) Reboot the ESXi host after updating entropy settings.

b
The ESXi host must not enable log filtering.
CM-6 - Medium - CCI-000366 - V-258800 - SV-258800r959010_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
ESXI-80-000246
Vuln IDs
  • V-258800
Rule IDs
  • SV-258800r959010_rule
The log filtering capability allows users to modify the logging policy of the syslog service that is running on an ESXi host. Users can create log filters to reduce the number of repetitive entries in the ESXi logs and to deny specific log events entirely. Setting a limit to the amount of logging information restricts the ability to detect and respond to potential security issues or system failures properly.
Checks: C-62540r933459_chk

From an ESXi shell, run the following command: # esxcli system syslog config logfilter get or From a PowerCLI command prompt while connected to the ESXi host, run the following commands: $esxcli = Get-EsxCli -v2 $esxcli.system.syslog.config.logfilter.get.invoke() If "LogFilteringEnabled" is not set to "false", this is a finding.

Fix: F-62449r933460_fix

From an ESXi shell, run the following command: # esxcli system syslog config logfilter set --log-filtering-enabled=false or From a PowerCLI command prompt while connected to the ESXi host, run the following commands: $esxcli = Get-EsxCli -v2 $arguments = $esxcli.system.syslog.config.logfilter.set.CreateArgs() $arguments.logfilteringenabled = $false $esxcli.system.syslog.config.logfilter.set.invoke($arguments)

b
The ESXi host must use DOD-approved encryption to protect the confidentiality of network sessions.
AC-17 - Medium - CCI-000068 - V-265974 - SV-265974r1003578_rule
RMF Control
AC-17
Severity
M
CCI
CCI-000068
Version
ESXI-80-000247
Vuln IDs
  • V-265974
Rule IDs
  • SV-265974r1003578_rule
Without confidentiality protection mechanisms, unauthorized individuals may gain access to sensitive information via a remote access session. In ESXi 8.0 Update 3 and newer TLS profiles are available to configure client and server TLS settings and must be configured to use only strong ciphers.
Checks: C-69897r1003576_chk

From an ESXi shell, run the following command: # esxcli system tls server get --show-profile-defaults --show-current-boot-profile or From a PowerCLI command prompt while connected to the ESXi host, run the following commands: $esxcli = Get-EsxCli -v2 $arguments = $esxcli.system.tls.server.get.CreateArgs() $arguments.showprofiledefaults = $true $arguments.showcurrentbootprofile = $true $esxcli.system.tls.server.get.invoke($arguments) Example result: Profile: NIST_2024 Cipher List: ECDHE+AESGCM Cipher Suite: TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384 Groups: prime256v1:secp384r1:secp521r1 Protocol Versions: tls1.2,tls1.3 Reboot Required: true If the TLS profile is not set to "NIST_2024" or is not the current boot profile, this is a finding.

Fix: F-69800r1003577_fix

TLS Profiles can be configured with vSphere Configuration Profiles or manually on each host for clusters not using vSphere Configuration Profiles. For ESXi hosts in clusters managed with vSphere Configuration Profiles do the following: Note: These steps assume a vSphere Configuration Profile is already in use for the target cluster. From the vSphere Client, go to Host and Clusters. Select the vCenter Server >> Select the target cluster >> Configure >> Desired State >> Configuration >> Draft. Click "Create Draft" or "Import from Host" if a draft does not exist. Select system >> tls_server >> Configure Settings. Select "NIST_2024" from the drop down for profile and click "Save". Click "Apply Changes" and run through the pre-check to enforce the change. Note: Updating this setting through a vSphere Configuration Profile will place hosts into maintenance mode and perform a rolling reboot of all hosts in the cluster. For standalone hosts or clusters not managed with vSphere Configuration Profiles do the following: Prior to changing the TLS profile it is highly recommended to place the host in maintenance mode. From an ESXi shell, run the following command: # esxcli system tls server set -p NIST_2024 or From a PowerCLI command prompt while connected to the ESXi host, run the following commands: $esxcli = Get-EsxCli -v2 $arguments = $esxcli.system.tls.server.set.CreateArgs() $arguments.profile = "NIST_2024" $esxcli.system.tls.server.set.invoke($arguments) A reboot is required to complete the process of changing profiles.

b
The ESXi host must disable key persistence.
CM-6 - Medium - CCI-000366 - V-265975 - SV-265975r1003581_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
ESXI-80-000248
Vuln IDs
  • V-265975
Rule IDs
  • SV-265975r1003581_rule
When using a standard key provider, the ESXi host relies on vCenter Server to manage the encryption keys. When using a trusted key provider, the ESXi host relies directly on the Trust Authority Hosts for keys, and vCenter Server is not involved. Regardless of the type of key provider, the ESXi host obtains the keys initially and retains them in its key cache. If the ESXi host reboots, it loses its key cache. The ESXi host then requests the keys again, either from the key server (standard key provider), or the Trust Authority Hosts (trusted key provider). When the ESXi host tries to obtain keys and the key server is offline or unreachable, vTPMs, vSAN encryption, and VM encryption cannot function. In vSphere, encrypted workloads can continue to function even when the key server is offline or unreachable. If the ESXi host has a TPM, the encryption keys are persisted in the TPM across reboots. So, even if an ESXi host reboots, the host does not need to request encryption keys. Also, encryption and decryption operations can continue when the key server is unavailable, because the keys have persisted in the TPM. If the encryption features of vSphere are used, it is to protect the confidentiality of workloads and while key persistence protects the availability of the environment it does so at the cost of confidentiality. An organization must consider the physical security posture and key provider reliability in their environments and if the risk of physical loss of equipment outweighs the availability of the workloads.
Checks: C-69898r1003579_chk

If the ESXi host does not have a compatible TPM, this is not applicable. From an ESXi shell, run the following command: # esxcli system security keypersistence get or From a PowerCLI command prompt while connected to the ESXi host, run the following commands: $esxcli = Get-EsxCli -v2 $esxcli.system.security.keypersistence.get.invoke() If key persistence is enabled, this is a finding.

Fix: F-69801r1003580_fix

From an ESXi shell, run the following command: # esxcli system security keypersistence disable --remove-all-stored-keys or From a PowerCLI command prompt while connected to the ESXi host, run the following commands: $esxcli = Get-EsxCli -v2 $arguments = $esxcli.system.security.keypersistence.disable.CreateArgs() $arguments.removeallstoredkeys = $true $esxcli.system.security.keypersistence.disable.invoke($arguments)

b
The ESXi host must deny shell access for the dcui account.
CM-6 - Medium - CCI-000366 - V-265976 - SV-265976r1003584_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
ESXI-80-000249
Vuln IDs
  • V-265976
Rule IDs
  • SV-265976r1003584_rule
The dcui user is used for process isolation for the DCUI itself. The account has shell access which can be deactivated to reduce attack surface.
Checks: C-69899r1003582_chk

From an ESXi shell, run the following command: # esxcli system account list or From a PowerCLI command prompt while connected to the ESXi host, run the following commands: $esxcli = Get-EsxCli -v2 $esxcli.system.account.list.Invoke() | Where-Object {$_.UserID -eq 'dcui'} If shell access is not disabled for the dcui account, this is a finding.

Fix: F-69802r1003583_fix

From an ESXi shell, run the following command: # esxcli system account set -i dcui -s false or From a PowerCLI command prompt while connected to the ESXi host, run the following commands: $esxcli = Get-EsxCli -v2 $arguments = $esxcli.system.account.set.CreateArgs() $arguments.id = "dcui" $arguments.shellaccess = "false" $esxcli.system.account.set.invoke($arguments)

b
The ESXi host must disable virtual hardware management network interfaces.
CM-6 - Medium - CCI-000366 - V-265977 - SV-265977r1003587_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
ESXI-80-000250
Vuln IDs
  • V-265977
Rule IDs
  • SV-265977r1003587_rule
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 ESXi.
Checks: C-69900r1003585_chk

From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host &gt;&gt; Configure &gt;&gt; System &gt;&gt; Advanced System Settings. Select the "Net.BMCNetworkEnable" value and verify it is set to "0". or From a PowerCLI command prompt while connected to the ESXi host, run the following command: Get-VMHost | Get-AdvancedSetting -Name Net.BMCNetworkEnable If the "Net.BMCNetworkEnable" setting is not set to "0", this is a finding.

Fix: F-69803r1003586_fix

From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host >> Configure >> System >> Advanced System Settings. Click "Edit". Select the "Net.BMCNetworkEnable" value and configure it to "0". or From a PowerCLI command prompt while connected to the ESXi host, run the following command: Get-VMHost | Get-AdvancedSetting -Name Net.BMCNetworkEnable | Set-AdvancedSetting -Value 0