Cyber Trackr - Free Compliance Library
Cyber Trackr
The Free Compliance Library

VMware vSphere 7.0 ESXi Security Technical Implementation Guide

  • Version/Release: V1R2
  • Published: 2023-06-21
  • Expand All:
  • Severity:
  • Sort:
Compare

Select any two versions of this STIG to compare the individual requirements

View

Select any old version/release of this STIG to view the previous requirements

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.
b
Access to the ESXi host must be limited by enabling lockdown mode.
AC-10 - Medium - CCI-000054 - V-256375 - SV-256375r885906_rule
RMF Control
AC-10
Severity
Medium
CCI
CCI-000054
Version
ESXI-70-000001
Vuln IDs
  • V-256375
Rule IDs
  • SV-256375r885906_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. Satisfies: SRG-OS-000027-VMM-000080, SRG-OS-000123-VMM-000620
Checks: C-60050r885904_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 >> Configure >> System >> 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-59993r885905_fix

From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host >> Configure >> System >> Security Profile >> Lockdown Mode. Click "Edit...". Select 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 must verify the DCUI.Access list.
CM-6 - Medium - CCI-000366 - V-256376 - SV-256376r885909_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
ESXI-70-000002
Vuln IDs
  • V-256376
Rule IDs
  • SV-256376r885909_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-60051r885907_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-59994r885908_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 verify the exception users list for lockdown mode.
CM-6 - Medium - CCI-000366 - V-256377 - SV-256377r885912_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
ESXI-70-000003
Vuln IDs
  • V-256377
Rule IDs
  • SV-256377r885912_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-60052r885910_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-59995r885911_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
Remote logging for ESXi hosts must be configured.
AC-17 - Medium - CCI-000067 - V-256378 - SV-256378r885915_rule
RMF Control
AC-17
Severity
Medium
CCI
CCI-000067
Version
ESXI-70-000004
Vuln IDs
  • V-256378
Rule IDs
  • SV-256378r885915_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-000032-VMM-000130, SRG-OS-000342-VMM-001230, SRG-OS-000479-VMM-001990, SRG-OS-000059-VMM-000280, SRG-OS-000058-VMM-000270, SRG-OS-000051-VMM-000230
Checks: C-60053r885913_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. Follow the conventions shown below: udp://&lt;IP/FQDN&gt;:514 tcp://&lt;IP/FQDN&gt;:514 ssl://&lt;IP/FQDN&gt;:1514 Multiple servers can 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-59996r885914_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 "<syslog server hostname>"

b
The ESXi host must enforce the limit of three consecutive invalid logon attempts by a user.
AC-7 - Medium - CCI-000044 - V-256379 - SV-256379r885918_rule
RMF Control
AC-7
Severity
Medium
CCI
CCI-000044
Version
ESXI-70-000005
Vuln IDs
  • V-256379
Rule IDs
  • SV-256379r885918_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-60054r885916_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.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-59997r885917_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 enforce an unlock timeout of 15 minutes after a user account is locked out.
AC-7 - Medium - CCI-002238 - V-256380 - SV-256380r885921_rule
RMF Control
AC-7
Severity
Medium
CCI
CCI-002238
Version
ESXI-70-000006
Vuln IDs
  • V-256380
Rule IDs
  • SV-256380r885921_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-60055r885919_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 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 set to a value other than "900", this is a finding.

Fix: F-59998r885920_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 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-256381 - SV-256381r885924_rule
RMF Control
AC-8
Severity
Medium
CCI
CCI-000048
Version
ESXI-70-000007
Vuln IDs
  • V-256381
Rule IDs
  • SV-256381r885924_rule
Failure to display the DOD logon banner prior to a logon attempt will negate legal proceedings resulting from unauthorized access to system resources. Satisfies: SRG-OS-000023-VMM-000060, SRG-OS-000024-VMM-000070
Checks: C-60056r885922_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 "Annotations.WelcomeMessage" value and verify it contains the DOD logon banner below. or From a PowerCLI command prompt while connected to the ESXi host, run the following command: Get-VMHost | Get-AdvancedSetting -Name Annotations.WelcomeMessage Banner: {bgcolor:black} {/color}{align:left}{bgcolor:black}{color:yellow}{hostname} , {ip}{/color}{/bgcolor}{/align}\n{bgcolor:black} {/color}{align:left}{bgcolor:black}{color:yellow}{esxproduct} {esxversion}{/color}{/bgcolor}{/align}\n{bgcolor:black} {/color}{align:left}{bgcolor:black}{color:yellow}{memory} RAM{/color}{/bgcolor}{/align}\n{bgcolor:black} {/color}{align:left}{bgcolor:black}{color:white} {/color}{/bgcolor}{/align}\n{bgcolor:black} {/color}{align:left}{bgcolor:yellow}{color:black} {/color}{/bgcolor}{/align}\n{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}\n{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}\n{bgcolor:black} {/color}{align:left}{bgcolor:yellow}{color:black} {/color}{/bgcolor}{/align}\n{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}\n{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}\n{bgcolor:black} {/color}{align:left}{bgcolor:yellow}{color:black} enforcement (LE), and counterintelligence (CI) investigations. {/color}{/bgcolor}{/align}\n{bgcolor:black} {/color}{align:left}{bgcolor:yellow}{color:black} {/color}{/bgcolor}{/align}\n{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}\n{bgcolor:black} {/color}{align:left}{bgcolor:yellow}{color:black} {/color}{/bgcolor}{/align}\n{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}\n{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}\n{bgcolor:black} {/color}{align:left}{bgcolor:yellow}{color:black} {/color}{/bgcolor}{/align}\n{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}\n{bgcolor:black} {/color}{align:left}{bgcolor:yellow}{color:black} for your personal benefit or privacy. {/color}{/bgcolor}{/align}\n{bgcolor:black} {/color}{align:left}{bgcolor:yellow}{color:black} {/color}{/bgcolor}{/align}\n{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}\n{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}\n{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}\n{bgcolor:black} {/color}{align:left}{bgcolor:yellow}{color:black} product are private and confidential. See User Agreement for details. {/color}{/bgcolor}{/align}\n{bgcolor:black} {/color}{align:left}{bgcolor:yellow}{color:black} {/color}{/bgcolor}{/align}\n{bgcolor:black} {/color}{bgcolor:dark-grey}{color:black} {/color}{/bgcolor}\n{bgcolor:black} {/color}{bgcolor:dark-grey}{color:black} {/color}{/bgcolor}\n{bgcolor:black} {/color}{bgcolor:dark-grey}{color:black} {/color}{/bgcolor}\n{bgcolor:black} {/color}{bgcolor:dark-grey}{color:black} {/color}{/bgcolor}\n{bgcolor:black} {/color}{bgcolor:dark-grey}{color:black} {/color}{/bgcolor}\n{bgcolor:black} {/color}{bgcolor:dark-grey}{color:black} {/color}{/bgcolor}\n{bgcolor:black} {/color}{bgcolor:dark-grey}{color:black} {/color}{/bgcolor}\n{bgcolor:black} {/color}{bgcolor:dark-grey}{color:black} {/color}{/bgcolor}\n{bgcolor:black} {/color}{bgcolor:dark-grey}{color:black} {/color}{/bgcolor}\n{bgcolor:black} {/color}{bgcolor:dark-grey}{color:black} {/color}{/bgcolor}\n{bgcolor:black} {/color}{bgcolor:dark-grey}{color:black} {/color}{/bgcolor}\n{bgcolor:black} {/color}{bgcolor:dark-grey}{color:black} {/color}{/bgcolor}\n{bgcolor:black} {/color}{bgcolor:dark-grey}{color:black} {/color}{/bgcolor}\n{bgcolor:black} {/color}{bgcolor:dark-grey}{color:black} {/color}{/bgcolor}\n{bgcolor:black} {/color}{bgcolor:dark-grey}{color:black} {/color}{/bgcolor}\n{bgcolor:black} {/color}{bgcolor:dark-grey}{color:black} {/color}{/bgcolor}\n{bgcolor:black} {/color}{bgcolor:dark-grey}{color:black} {/color}{/bgcolor}\n{bgcolor:black} {/color}{align:left}{bgcolor:dark-grey}{color:white} &lt;F2&gt; Accept Conditions and Customize System / View Logs{/align}{align:right}&lt;F12&gt; Accept Conditions and Shut Down/Restart {bgcolor:black} {/color}{/color}{/bgcolor}{/align}\n{bgcolor:black} {/color}{bgcolor:dark-grey}{color:black} {/color}{/bgcolor} If the "Annotations.WelcomeMessage" setting is not set to the specified banner, this is a finding.

Fix: F-59999r885923_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}\n{bgcolor:black} {/color}{align:left}{bgcolor:black}{color:yellow}{esxproduct} {esxversion}{/color}{/bgcolor}{/align}\n{bgcolor:black} {/color}{align:left}{bgcolor:black}{color:yellow}{memory} RAM{/color}{/bgcolor}{/align}\n{bgcolor:black} {/color}{align:left}{bgcolor:black}{color:white} {/color}{/bgcolor}{/align}\n{bgcolor:black} {/color}{align:left}{bgcolor:yellow}{color:black} {/color}{/bgcolor}{/align}\n{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}\n{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}\n{bgcolor:black} {/color}{align:left}{bgcolor:yellow}{color:black} {/color}{/bgcolor}{/align}\n{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}\n{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}\n{bgcolor:black} {/color}{align:left}{bgcolor:yellow}{color:black} enforcement (LE), and counterintelligence (CI) investigations. {/color}{/bgcolor}{/align}\n{bgcolor:black} {/color}{align:left}{bgcolor:yellow}{color:black} {/color}{/bgcolor}{/align}\n{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}\n{bgcolor:black} {/color}{align:left}{bgcolor:yellow}{color:black} {/color}{/bgcolor}{/align}\n{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}\n{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}\n{bgcolor:black} {/color}{align:left}{bgcolor:yellow}{color:black} {/color}{/bgcolor}{/align}\n{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}\n{bgcolor:black} {/color}{align:left}{bgcolor:yellow}{color:black} for your personal benefit or privacy. {/color}{/bgcolor}{/align}\n{bgcolor:black} {/color}{align:left}{bgcolor:yellow}{color:black} {/color}{/bgcolor}{/align}\n{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}\n{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}\n{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}\n{bgcolor:black} {/color}{align:left}{bgcolor:yellow}{color:black} product are private and confidential. See User Agreement for details. {/color}{/bgcolor}{/align}\n{bgcolor:black} {/color}{align:left}{bgcolor:yellow}{color:black} {/color}{/bgcolor}{/align}\n{bgcolor:black} {/color}{bgcolor:dark-grey}{color:black} {/color}{/bgcolor}\n{bgcolor:black} {/color}{bgcolor:dark-grey}{color:black} {/color}{/bgcolor}\n{bgcolor:black} {/color}{bgcolor:dark-grey}{color:black} {/color}{/bgcolor}\n{bgcolor:black} {/color}{bgcolor:dark-grey}{color:black} {/color}{/bgcolor}\n{bgcolor:black} {/color}{bgcolor:dark-grey}{color:black} {/color}{/bgcolor}\n{bgcolor:black} {/color}{bgcolor:dark-grey}{color:black} {/color}{/bgcolor}\n{bgcolor:black} {/color}{bgcolor:dark-grey}{color:black} {/color}{/bgcolor}\n{bgcolor:black} {/color}{bgcolor:dark-grey}{color:black} {/color}{/bgcolor}\n{bgcolor:black} {/color}{bgcolor:dark-grey}{color:black} {/color}{/bgcolor}\n{bgcolor:black} {/color}{bgcolor:dark-grey}{color:black} {/color}{/bgcolor}\n{bgcolor:black} {/color}{bgcolor:dark-grey}{color:black} {/color}{/bgcolor}\n{bgcolor:black} {/color}{bgcolor:dark-grey}{color:black} {/color}{/bgcolor}\n{bgcolor:black} {/color}{bgcolor:dark-grey}{color:black} {/color}{/bgcolor}\n{bgcolor:black} {/color}{bgcolor:dark-grey}{color:black} {/color}{/bgcolor}\n{bgcolor:black} {/color}{bgcolor:dark-grey}{color:black} {/color}{/bgcolor}\n{bgcolor:black} {/color}{bgcolor:dark-grey}{color:black} {/color}{/bgcolor}\n{bgcolor:black} {/color}{bgcolor:dark-grey}{color:black} {/color}{/bgcolor}\n{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}\n{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 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-256382 - SV-256382r885927_rule
RMF Control
AC-8
Severity
Medium
CCI
CCI-000048
Version
ESXI-70-000008
Vuln IDs
  • V-256382
Rule IDs
  • SV-256382r885927_rule
Failure to display the DOD logon banner prior to a logon attempt will negate legal proceedings resulting from unauthorized access to system resources.
Checks: C-60057r885925_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 is set to the DOD logon banner below. 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 (/etc/issue file) does not contain the logon banner exactly as shown below, this is a finding. "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."

Fix: F-60000r885926_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 "<insert logon banner>"

b
The ESXi host SSH daemon must be configured with the DOD logon banner.
AC-8 - Medium - CCI-000048 - V-256383 - SV-256383r885930_rule
RMF Control
AC-8
Severity
Medium
CCI
CCI-000048
Version
ESXI-70-000009
Vuln IDs
  • V-256383
Rule IDs
  • SV-256383r885930_rule
The warning message reinforces policy awareness during the logon process and facilitates possible legal action against attackers. Alternatively, systems whose ownership should not be obvious should ensure use of a banner that does not provide easy attribution.
Checks: C-60058r885928_chk

From an ESXi shell, run the following command: # /usr/lib/vmware/openssh/bin/sshd -T|grep banner Expected result: banner /etc/issue If the output does not match the expected result, this is a finding.

Fix: F-60001r885929_fix

From an ESXi shell, add or correct the following line in "/etc/ssh/sshd_config": Banner /etc/issue

b
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 - Medium - CCI-000068 - V-256384 - SV-256384r885933_rule
RMF Control
AC-17
Severity
Medium
CCI
CCI-000068
Version
ESXI-70-000010
Vuln IDs
  • V-256384
Rule IDs
  • SV-256384r885933_rule
OpenSSH on the ESXi host ships with a FIPS 140-2 validated cryptographic module that is enabled by default. For backward compatibility reasons, this can be disabled so this setting can be audited and corrected if necessary.
Checks: C-60059r885931_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 output does not match the expected result, this is a finding.

Fix: F-60002r885932_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 host Secure Shell (SSH) daemon must ignore ".rhosts" files.
IA-2 - Medium - CCI-000767 - V-256385 - SV-256385r919018_rule
RMF Control
IA-2
Severity
Medium
CCI
CCI-000767
Version
ESXI-70-000012
Vuln IDs
  • V-256385
Rule IDs
  • SV-256385r919018_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-60060r885934_chk

From an ESXi shell, run the following command: # /usr/lib/vmware/openssh/bin/sshd -T|grep ignorerhosts Expected result: ignorerhosts yes If the output does not match the expected result, this is a finding.

Fix: F-60003r918908_fix

From an ESXi shell, add or correct the following line in "/etc/ssh/sshd_config": IgnoreRhosts yes

b
The ESXi host Secure Shell (SSH) daemon must not allow host-based authentication.
CM-6 - Medium - CCI-000366 - V-256386 - SV-256386r885939_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
ESXI-70-000013
Vuln IDs
  • V-256386
Rule IDs
  • SV-256386r885939_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 because hosts are cryptographically authenticated. However, it is not recommended that hosts unilaterally trust one another, even within an organization.
Checks: C-60061r885937_chk

From an ESXi shell, run the following command: # /usr/lib/vmware/openssh/bin/sshd -T|grep hostbasedauthentication Expected result: hostbasedauthentication no If the output does not match the expected result, this is a finding.

Fix: F-60004r885938_fix

From an ESXi shell, add or correct the following line in "/etc/ssh/sshd_config": HostbasedAuthentication no

a
The ESXi host Secure Shell (SSH) daemon must not allow authentication using an empty password.
CM-6 - Low - CCI-000366 - V-256387 - SV-256387r885942_rule
RMF Control
CM-6
Severity
Low
CCI
CCI-000366
Version
ESXI-70-000015
Vuln IDs
  • V-256387
Rule IDs
  • SV-256387r885942_rule
Configuring this setting for the SSH daemon provides additional assurance that remote logon via SSH will require a password, even in the event of misconfiguration elsewhere.
Checks: C-60062r885940_chk

From an ESXi shell, run the following command: # /usr/lib/vmware/openssh/bin/sshd -T|grep permitemptypasswords Expected result: permitemptypasswords no If the output does not match the expected result, this is a finding.

Fix: F-60005r885941_fix

From an ESXi shell, add or correct the following line in "/etc/ssh/sshd_config": PermitEmptyPasswords no

b
The ESXi host Secure Shell (SSH) daemon must not permit user environment settings.
CM-6 - Medium - CCI-000366 - V-256388 - SV-256388r885945_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
ESXI-70-000016
Vuln IDs
  • V-256388
Rule IDs
  • SV-256388r885945_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-60063r885943_chk

From an ESXi shell, run the following command: # /usr/lib/vmware/openssh/bin/sshd -T|grep permituserenvironment Expected result: permituserenvironment no If the output does not match the expected result, this is a finding.

Fix: F-60006r885944_fix

From an ESXi shell, add or correct the following line in "/etc/ssh/sshd_config": PermitUserEnvironment no

b
The ESXi host Secure Shell (SSH) daemon must perform strict mode checking of home directory configuration files.
CM-6 - Medium - CCI-000366 - V-256389 - SV-256389r885948_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
ESXI-70-000020
Vuln IDs
  • V-256389
Rule IDs
  • SV-256389r885948_rule
If other users have access to modify user-specific SSH configuration files, they may be able to log on the system as another user.
Checks: C-60064r885946_chk

From an ESXi shell, run the following command: # /usr/lib/vmware/openssh/bin/sshd -T|grep strictmodes Expected result: strictmodes yes If the output does not match the expected result, this is a finding.

Fix: F-60007r885947_fix

From an ESXi shell, add or correct the following line in "/etc/ssh/sshd_config": StrictModes yes

b
The ESXi host Secure Shell (SSH) daemon must not allow compression or must only allow compression after successful authentication.
CM-6 - Medium - CCI-000366 - V-256390 - SV-256390r885951_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
ESXI-70-000021
Vuln IDs
  • V-256390
Rule IDs
  • SV-256390r885951_rule
If compression is allowed in an SSH connection prior to authentication, vulnerabilities in the compression software could result in compromise of the system from an unauthenticated connection, potentially with root privileges.
Checks: C-60065r885949_chk

From an ESXi shell, run the following command: # /usr/lib/vmware/openssh/bin/sshd -T|grep compression Expected result: compression no If the output does not match the expected result, this is a finding.

Fix: F-60008r885950_fix

From an ESXi shell, add or correct the following line in "/etc/ssh/sshd_config": Compression no

a
The ESXi host Secure Shell (SSH) daemon must be configured to not allow gateway ports.
CM-6 - Low - CCI-000366 - V-256391 - SV-256391r885954_rule
RMF Control
CM-6
Severity
Low
CCI
CCI-000366
Version
ESXI-70-000022
Vuln IDs
  • V-256391
Rule IDs
  • SV-256391r885954_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-60066r885952_chk

From an ESXi shell, run the following command: # /usr/lib/vmware/openssh/bin/sshd -T|grep gatewayports Expected result: gatewayports no If the output does not match the expected result, this is a finding.

Fix: F-60009r885953_fix

From an ESXi shell, add or correct the following line in "/etc/ssh/sshd_config": GatewayPorts no

b
The ESXi host Secure Shell (SSH) daemon must be configured to not allow X11 forwarding.
CM-6 - Medium - CCI-000366 - V-256392 - SV-256392r885957_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
ESXI-70-000023
Vuln IDs
  • V-256392
Rule IDs
  • SV-256392r885957_rule
X11 forwarding over SSH allows for the secure remote execution of X11-based applications. This feature can increase the attack surface of an SSH connection.
Checks: C-60067r885955_chk

From an ESXi shell, run the following command: # /usr/lib/vmware/openssh/bin/sshd -T|grep x11forwarding Expected result: x11forwarding no If the output does not match the expected result, this is a finding.

Fix: F-60010r885956_fix

From an ESXi shell, add or correct the following line in "/etc/ssh/sshd_config": X11Forwarding no

b
The ESXi host Secure Shell (SSH) daemon must not permit tunnels.
CM-6 - Medium - CCI-000366 - V-256393 - SV-256393r885960_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
ESXI-70-000025
Vuln IDs
  • V-256393
Rule IDs
  • SV-256393r885960_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-60068r885958_chk

From an ESXi shell, run the following command: # /usr/lib/vmware/openssh/bin/sshd -T|grep permittunnel Expected result: permittunnel no If the output does not match the expected result, this is a finding.

Fix: F-60011r885959_fix

From an ESXi shell, add or correct the following line in "/etc/ssh/sshd_config": PermitTunnel no

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

From an ESXi shell, run the following command: # /usr/lib/vmware/openssh/bin/sshd -T|grep clientalivecountmax Expected result: clientalivecountmax 3 If the output does not match the expected result, this is a finding.

Fix: F-60012r885962_fix

From an ESXi shell, add or correct the following line in "/etc/ssh/sshd_config": ClientAliveCountMax 3

a
The ESXi host Secure Shell (SSH) daemon must set a timeout interval on idle sessions.
CM-6 - Low - CCI-000366 - V-256395 - SV-256395r885966_rule
RMF Control
CM-6
Severity
Low
CCI
CCI-000366
Version
ESXI-70-000027
Vuln IDs
  • V-256395
Rule IDs
  • SV-256395r885966_rule
Automatically logging out idle users guards against compromises via hijacked administrative sessions.
Checks: C-60070r885964_chk

From an ESXi shell, run the following command: # /usr/lib/vmware/openssh/bin/sshd -T|grep clientaliveinterval Expected result: clientaliveinterval 200 If the output does not match the expected result, this is a finding.

Fix: F-60013r885965_fix

From an ESXi shell, add or correct the following line in "/etc/ssh/sshd_config": ClientAliveInterval 200

b
The ESXi host must produce audit records containing information to establish what type of events occurred.
AU-3 - Medium - CCI-000130 - V-256396 - SV-256396r885969_rule
RMF Control
AU-3
Severity
Medium
CCI
CCI-000130
Version
ESXI-70-000030
Vuln IDs
  • V-256396
Rule IDs
  • SV-256396r885969_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-60071r885967_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-60014r885968_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 be configured with a sufficiently complex password policy.
IA-5 - Medium - CCI-000192 - V-256397 - SV-256397r885972_rule
RMF Control
IA-5
Severity
Medium
CCI
CCI-000192
Version
ESXI-70-000031
Vuln IDs
  • V-256397
Rule IDs
  • SV-256397r885972_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-000078-VMM-000450, SRG-OS-000266-VMM-000940
Checks: C-60072r885970_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 not set to "similar=deny retry=3 min=disabled,disabled,disabled,disabled,15", this is a finding.

Fix: F-60015r885971_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 the reuse of passwords within five iterations.
IA-5 - Medium - CCI-000200 - V-256398 - SV-256398r919019_rule
RMF Control
IA-5
Severity
Medium
CCI
CCI-000200
Version
ESXI-70-000032
Vuln IDs
  • V-256398
Rule IDs
  • SV-256398r919019_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-60073r885973_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 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 not set to "5" this is a finding.

Fix: F-60016r918910_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 disable the Managed Object Browser (MOB).
CM-7 - Medium - CCI-000381 - V-256399 - SV-256399r919020_rule
RMF Control
CM-7
Severity
Medium
CCI
CCI-000381
Version
ESXI-70-000034
Vuln IDs
  • V-256399
Rule IDs
  • SV-256399r919020_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-60074r885976_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-60017r918912_fix

From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host >> Configure >> System >> Advanced System Settings. Click "Edit". 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

b
The ESXi host must be configured to disable nonessential capabilities by disabling Secure Shell (SSH).
CM-7 - Medium - CCI-000381 - V-256400 - SV-256400r885981_rule
RMF Control
CM-7
Severity
Medium
CCI
CCI-000381
Version
ESXI-70-000035
Vuln IDs
  • V-256400
Rule IDs
  • SV-256400r885981_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-60075r885979_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-60018r885980_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 disable ESXi Shell unless needed for diagnostics or troubleshooting.
CM-7 - Medium - CCI-000381 - V-256401 - SV-256401r885984_rule
RMF Control
CM-7
Severity
Medium
CCI
CCI-000381
Version
ESXI-70-000036
Vuln IDs
  • V-256401
Rule IDs
  • SV-256401r885984_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-60076r885982_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-60019r885983_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

a
The ESXi host must use Active Directory for local user authentication.
IA-2 - Low - CCI-000764 - V-256402 - SV-256402r885987_rule
RMF Control
IA-2
Severity
Low
CCI
CCI-000764
Version
ESXI-70-000037
Vuln IDs
  • V-256402
Rule IDs
  • SV-256402r885987_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
Checks: C-60077r885985_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-60020r885986_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
ESXi hosts using Host Profiles and/or Auto Deploy must use the vSphere Authentication Proxy to protect passwords when adding themselves to Active Directory.
IA-2 - Medium - CCI-000764 - V-256403 - SV-256403r885990_rule
RMF Control
IA-2
Severity
Medium
CCI
CCI-000764
Version
ESXI-70-000038
Vuln IDs
  • V-256403
Rule IDs
  • SV-256403r885990_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-60078r885988_chk

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-60021r885989_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
Active Directory ESX Admin group membership must not be used when adding ESXi hosts to Active Directory.
IA-2 - Medium - CCI-000764 - V-256404 - SV-256404r885993_rule
RMF Control
IA-2
Severity
Medium
CCI
CCI-000764
Version
ESXI-70-000039
Vuln IDs
  • V-256404
Rule IDs
  • SV-256404r885993_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-60079r885991_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" key is set to "ESX Admins", this is a finding.

Fix: F-60022r885992_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 <AD Group>

b
The ESXi host must set a timeout to automatically disable idle shell sessions after two minutes.
SC-10 - Medium - CCI-001133 - V-256405 - SV-256405r885996_rule
RMF Control
SC-10
Severity
Medium
CCI
CCI-001133
Version
ESXI-70-000041
Vuln IDs
  • V-256405
Rule IDs
  • SV-256405r885996_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-60080r885994_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 "120" (two minutes). 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 not set to "120", this is a finding.

Fix: F-60023r885995_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 "120". 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 120

b
The ESXi host must terminate shell services after 10 minutes.
SC-10 - Medium - CCI-001133 - V-256406 - SV-256406r885999_rule
RMF Control
SC-10
Severity
Medium
CCI
CCI-001133
Version
ESXI-70-000042
Vuln IDs
  • V-256406
Rule IDs
  • SV-256406r885999_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-60081r885997_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" (10 minutes). 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 not set to "600", this is a finding.

Fix: F-60024r885998_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 commands: Get-VMHost | Get-AdvancedSetting -Name UserVars.ESXiShellTimeOut | Set-AdvancedSetting -Value 600

b
The ESXi host must log out of the console UI after two minutes.
SC-10 - Medium - CCI-001133 - V-256407 - SV-256407r886002_rule
RMF Control
SC-10
Severity
Medium
CCI
CCI-001133
Version
ESXI-70-000043
Vuln IDs
  • V-256407
Rule IDs
  • SV-256407r886002_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-60082r886000_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 "120" (two minutes). 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 not set to "120", this is a finding.

Fix: F-60025r886001_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 "120". 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 120

b
The ESXi host must enable a persistent log location for all locally stored logs.
AU-4 - Medium - CCI-001849 - V-256408 - SV-256408r886005_rule
RMF Control
AU-4
Severity
Medium
CCI
CCI-001849
Version
ESXI-70-000045
Vuln IDs
  • V-256408
Rule IDs
  • SV-256408r886005_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-60083r886003_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-60026r886004_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"

b
The ESXi host must configure NTP time synchronization.
AU-8 - Medium - CCI-001891 - V-256409 - SV-256409r886008_rule
RMF Control
AU-8
Severity
Medium
CCI
CCI-001891
Version
ESXI-70-000046
Vuln IDs
  • V-256409
Rule IDs
  • SV-256409r886008_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-60084r886006_chk

From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host &gt;&gt; Configure &gt;&gt; System &gt;&gt; Time Configuration. Under "Current Time Configuration", verify "Time Synchronization" is set to "Network Time Protocol". Under "Network Time Protocol", verify the "NTP Servers" are authorized DOD time sources. If the ESXi host is not configured to pull time from authoritative DOD time sources, this is a finding. 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"} If the NTP service is not configured with authoritative DOD time sources or the service does not have a "Policy" of "on" or is stopped, this is a finding.

Fix: F-60027r886007_fix

From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host >> Configure >> System >> Time Configuration. Under "Network Time Protocol", click "Edit...". Ensure the "NTP Servers" are authorized DOD time sources. Ensure the "NTP Service Startup Policy" is set to "Start and stop with host". Ensure the "Enable" checkbox, in the upper left, is checked. Click "OK". Click "Edit" to configure the NTP service to start and stop with the host and with authoritative DOD time sources. 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

c
The ESXi Image Profile and vSphere Installation Bundle (VIB) acceptance levels must be verified.
CM-5 - High - CCI-001749 - V-256410 - SV-256410r892863_rule
RMF Control
CM-5
Severity
High
CCI
CCI-001749
Version
ESXI-70-000047
Vuln IDs
  • V-256410
Rule IDs
  • SV-256410r892863_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, SRG-OS-000404-VMM-001650
Checks: C-60085r886009_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-60028r892863_fix

From the vSphere Client, select the ESXi Host and go to 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 protect the confidentiality and integrity of transmitted information by isolating vMotion traffic.
SC-8 - Medium - CCI-002418 - V-256411 - SV-256411r886014_rule
RMF Control
SC-8
Severity
Medium
CCI
CCI-002418
Version
ESXI-70-000048
Vuln IDs
  • V-256411
Rule IDs
  • SV-256411r886014_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 not routed to anything but ESXi hosts.
Checks: C-60086r886012_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. Review the VLAN associated with the 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-60029r886013_fix

Configuration of the vMotion VMkernel will be unique to each environment. As an 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, and then go to Configure >> Settings >> Edit >> VLAN. Change the "VLAN Type" to "VLAN" and change the "VLAN ID" to a network allocated and dedicated to vMotion traffic exclusively.

b
The ESXi host must protect the confidentiality and integrity of transmitted information by protecting ESXi management traffic.
SC-8 - Medium - CCI-002418 - V-256412 - SV-256412r919022_rule
RMF Control
SC-8
Severity
Medium
CCI
CCI-002418
Version
ESXI-70-000049
Vuln IDs
  • V-256412
Rule IDs
  • SV-256412r919022_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-60087r919021_chk

From the vSphere Client, select the ESXi host and go to Configure &gt;&gt; Networking &gt;&gt; VMkernel adapters. Select each VMkernel adapter that is "Enabled" for management traffic and, in the bottom pane, view the "Enabled services". If any services other than "Management" are enabled on the Management VMkernel adapter, this is a finding. From the vSphere Client, select the ESXi host and go to Configure &gt;&gt; Networking &gt;&gt; VMkernel adapters. Review the VLAN associated with each VMkernel that is "Enabled" for management traffic. Verify with the system administrator that they are dedicated for that purpose and are logically separated from other functions. 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-60030r886016_fix

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 "Management". Click "OK". From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host >> Configure >> Networking >> Virtual switches. Find the port group that contains the Management VMkernel and click the "..." button next to the name. Click "Edit Settings". On the "Properties" tab, change the "VLAN ID" to one dedicated to Management traffic. 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-256413 - SV-256413r886020_rule
RMF Control
SC-8
Severity
Medium
CCI
CCI-002418
Version
ESXI-70-000050
Vuln IDs
  • V-256413
Rule IDs
  • SV-256413r886020_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-60088r886018_chk

If IP-based storage is not used, this is not applicable. From the vSphere Client, select the ESXi host and go to Configure &gt;&gt; Networking &gt;&gt; VMkernel adapters. Select each IP-based storage VMkernel adapter and view the enabled services. 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. From the vSphere Client, select the ESXi host and go to Configure &gt;&gt; Networking &gt;&gt; VMkernel adapters. Review the VLANs associated with any IP-based storage VMkernels and verify they are dedicated for that purpose and are logically separated from other functions. If any IP-based storage networks are not isolated from other traffic types, this is a finding.

Fix: F-60031r886019_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
Simple Network Management Protocol (SNMP) must be configured properly on the ESXi host.
CM-6 - Medium - CCI-000366 - V-256414 - SV-256414r886023_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
ESXI-70-000053
Vuln IDs
  • V-256414
Rule IDs
  • SV-256414r886023_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-60089r886021_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 read-only communities are set to "public", this is a finding. If SNMP is enabled and is not using v3 targets, this is a finding. Note: SNMP v3 targets can only be viewed and configured via the "esxcli" command.

Fix: F-60032r886022_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 To configure SNMP for v3 targets, use the "esxcli system snmp set" command set locally on the host or remotely via PowerCLI.

b
The ESXi host must enable bidirectional Challenge-Handshake Authentication Protocol (CHAP) authentication for Internet Small Computer Systems Interface (iSCSI) traffic.
CM-6 - Medium - CCI-000366 - V-256415 - SV-256415r886026_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
ESXI-70-000054
Vuln IDs
  • V-256415
Rule IDs
  • SV-256415r886026_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-60090r886024_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-60033r886025_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"

a
The ESXi host must disable Inter-Virtual Machine (VM) Transparent Page Sharing.
CM-6 - Low - CCI-000366 - V-256416 - SV-256416r886029_rule
RMF Control
CM-6
Severity
Low
CCI
CCI-000366
Version
ESXI-70-000055
Vuln IDs
  • V-256416
Rule IDs
  • SV-256416r886029_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-60091r886027_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-60034r886028_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 restrict access to services running on the host.
CM-6 - Medium - CCI-000366 - V-256417 - SV-256417r886032_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
ESXI-70-000056
Vuln IDs
  • V-256417
Rule IDs
  • SV-256417r886032_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-60092r886030_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} | Select Name,Enabled,@{N="AllIPEnabled";E={$_.ExtensionData.AllowedHosts.AllIP}} If for an enabled service "Allow connections from any IP address" is selected, this is a finding.

Fix: F-60035r886031_fix

From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host >> Configure >> System >> Firewall. Click "Edit...". For each 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. We are targeting the sshServer service 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 doing 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 enabled service.

b
The ESXi host must configure the firewall to block network traffic by default.
CM-6 - Medium - CCI-000366 - V-256418 - SV-256418r886035_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
ESXI-70-000057
Vuln IDs
  • V-256418
Rule IDs
  • SV-256418r886035_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-60093r886033_chk

From an ESXi shell, run the following command: # esxcli network firewall get If the "Default Action" does not equal "DROP", this is a finding. or From a PowerCLI command prompt while connected to the ESXi host, run the following command: Get-VMHostFirewallDefaultPolicy If the Incoming or Outgoing policies are "True", this is a finding.

Fix: F-60036r886034_fix

From an ESXi shell, run the following command: # esxcli network firewall set --default-action=false or From a PowerCLI command prompt while connected to the ESXi host, run the following command: Get-VMHostFirewallDefaultPolicy | Set-VMHostFirewallDefaultPolicy -AllowIncoming $false -AllowOutgoing $false

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-256419 - SV-256419r886038_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
ESXI-70-000058
Vuln IDs
  • V-256419
Rule IDs
  • SV-256419r886038_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-60094r886036_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-60037r886037_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
All port groups on standard switches must be configured to reject forged transmits.
CM-6 - Medium - CCI-000366 - V-256420 - SV-256420r886041_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
ESXI-70-000059
Vuln IDs
  • V-256420
Rule IDs
  • SV-256420r886041_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-60095r886039_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. Click View Settings &gt;&gt; Policies tab. Verify that "Forged transmits" is set to "Reject". or From a PowerCLI command prompt while connected to the ESXi host, run the following commands: Get-VirtualSwitch -Standard | Get-SecurityPolicy Get-VirtualPortGroup -Standard | Get-SecurityPolicy If the "Forged Transmits" policy is set to "Accept" (or "true", via PowerCLI), this is a finding.

Fix: F-60038r886040_fix

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

c
All port groups on standard switches must be configured to reject guest Media Access Control (MAC) address changes.
CM-6 - High - CCI-000366 - V-256421 - SV-256421r886044_rule
RMF Control
CM-6
Severity
High
CCI
CCI-000366
Version
ESXI-70-000060
Vuln IDs
  • V-256421
Rule IDs
  • SV-256421r886044_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-60096r886042_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. Click View Settings &gt;&gt; Policies tab. Verify "MAC Address Changes" is set to "Reject". or From a PowerCLI command prompt while connected to the ESXi host, run the following commands: Get-VirtualSwitch -Standard | Get-SecurityPolicy Get-VirtualPortGroup -Standard | Get-SecurityPolicy If the "MAC Address Changes" policy is set to "Accept" (or "true", via PowerCLI), this is a finding.

Fix: F-60039r886043_fix

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

b
All port groups on standard switches must be configured to reject guest promiscuous mode requests.
CM-6 - Medium - CCI-000366 - V-256422 - SV-256422r886047_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
ESXI-70-000061
Vuln IDs
  • V-256422
Rule IDs
  • SV-256422r886047_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-60097r886045_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. Click View Settings &gt;&gt; Policies tab. Verify "Promiscuous Mode" is set to "Reject". or From a PowerCLI command prompt while connected to the ESXi host, run the following commands: Get-VirtualSwitch -Standard | Get-SecurityPolicy Get-VirtualPortGroup -Standard | Get-SecurityPolicy If the "Promiscuous Mode" policy is set to "Accept" (or "true", via PowerCLI), this is a finding.

Fix: F-60040r886046_fix

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

b
Use of the dvFilter network application programming interfaces (APIs) must be restricted.
CM-6 - Medium - CCI-000366 - V-256423 - SV-256423r886050_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
ESXI-70-000062
Vuln IDs
  • V-256423
Rule IDs
  • SV-256423r886050_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-60098r886048_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" is not blank and security appliances are not in use on the host, this is a finding.

Fix: F-60041r886049_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
All port groups on standard switches must be configured to a value other than that of the native virtual local area network (VLAN).
CM-6 - Medium - CCI-000366 - V-256424 - SV-256424r886053_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
ESXI-70-000063
Vuln IDs
  • V-256424
Rule IDs
  • SV-256424r886053_rule
ESXi does not use the concept of native VLAN. Frames with a VLAN specified in the port group will have a tag, but frames with VLAN not specified in the port group are not tagged and therefore will belong to the native VLAN of the physical switch. For example, frames on VLAN 1 from a Cisco physical switch will be untagged, because this is considered as the native VLAN. However, frames from ESXi specified as VLAN 1 will be tagged with a "1"; therefore, traffic from ESXi that is destined for the native VLAN will not be routed correctly (because it is tagged with a "1" instead of being untagged), and traffic from the physical switch coming from the native VLAN will not be visible (because it is not tagged). If the ESXi virtual switch port group uses the native VLAN ID, traffic from those virtual machines (VMs) will not be visible to the native VLAN on the switch because the switch is expecting untagged traffic.
Checks: C-60099r886051_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. For each standard switch, review the "VLAN ID" on each port group. Verify they are not set to the native VLAN ID of the attached physical switch. or From a PowerCLI command prompt while connected to the ESXi host, run the following command: Get-VirtualPortGroup -Standard | Select Name, VLanId If any port group is configured with the native VLAN of the attached physical switch, this is a finding.

Fix: F-60042r886052_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 a non-native VLAN and 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#"

b
All port groups on standard switches must not be configured to virtual local area network (VLAN) 4095 unless Virtual Guest Tagging (VGT) is required.
CM-6 - Medium - CCI-000366 - V-256425 - SV-256425r919425_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
ESXI-70-000064
Vuln IDs
  • V-256425
Rule IDs
  • SV-256425r919425_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-60100r886054_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. 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 -Standard | 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-60043r919425_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 and 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#"

b
All port groups on standard switches must not be configured to virtual local area network (VLAN) values reserved by upstream physical switches.
CM-6 - Medium - CCI-000366 - V-256426 - SV-256426r892864_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
ESXI-70-000065
Vuln IDs
  • V-256426
Rule IDs
  • SV-256426r892864_rule
Certain physical switches reserve certain VLAN IDs for internal purposes and often disallow traffic configured to these values. For example, Cisco Catalyst switches typically reserve VLANs 1001 to 1024 and 4094, while Nexus switches typically reserve 3968 to 4094. Check the documentation for the specific switch in use. Using a reserved VLAN might result in a denial of service on the network.
Checks: C-60101r886057_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. For each standard switch, review the "VLAN ID" on each port group and verify it is not set to a reserved VLAN ID. or From a PowerCLI command prompt while connected to the ESXi host, run the following command: Get-VirtualPortGroup -Standard | Select Name, VLanId If any port group is configured with a reserved VLAN ID, this is a finding.

Fix: F-60044r892864_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 reserved 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 and 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#"

b
The ESXi host must not provide root/administrator-level access to Common Information Model (CIM)-based hardware monitoring tools or other third-party applications.
CM-6 - Medium - CCI-000366 - V-256427 - SV-256427r886062_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
ESXI-70-000070
Vuln IDs
  • V-256427
Rule IDs
  • SV-256427r886062_rule
The CIM system provides an interface that enables hardware-level management from remote applications via a set of standard application programming interfaces (APIs). In environments that implement CIM hardware monitoring, create a limited-privilege, read-only service account for CIM and place this user in the Exception Users list. When CIM write access is required, create a new role with only the "Host.CIM.Interaction" permission and apply that role to the CIM service account.
Checks: C-60102r886060_chk

If CIM monitoring is not implemented, this is not applicable. From the Host Client, select the ESXi host, right-click, and go to "Permissions". Verify the CIM service account is assigned the "Read-only" role or a custom role as described in the discussion. If there is no dedicated CIM service account, this is a finding. If the CIM service account has more permissions than necessary as noted in the discussion, this is a finding.

Fix: F-60045r886061_fix

If write access is required, create a new role for the CIM service account: From the Host Client, go to Manage >> Security & Users. Select "Roles" and click "Add role". Provide a name for the new role and select Host >> Cim >> Ciminteraction and click "Add". Add a CIM service account: From the Host Client, go to Manage >> Security & Users. Select "Users" and click "Add user". Provide a name, description, and password for the new user and click "Add". Assign the CIM service account permissions to the host with the new role: From the Host Client, select the ESXi host, right-click, and go to "Permissions". Click "Add User", select the CIM service account from the drop-down list, and select either "Read-only" or the role just created. Click "Add User".

c
The ESXi host must have all security patches and updates installed.
CM-6 - High - CCI-000366 - V-256428 - SV-256428r886065_rule
RMF Control
CM-6
Severity
High
CCI
CCI-000366
Version
ESXI-70-000072
Vuln IDs
  • V-256428
Rule IDs
  • SV-256428r886065_rule
Installing software updates is a fundamental mitigation against the exploitation of publicly known vulnerabilities.
Checks: C-60103r886063_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 Because ESXi hosts should never be able to touch the internet, manually compare the current ESXi version and patch level to the latest available on vmware.com: https://kb.vmware.com/s/article/2143832 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. 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-60046r886064_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.

c
The ESXi host must exclusively enable Transport Layer Security (TLS) 1.2 for all endpoints.
SC-8 - High - CCI-002420 - V-256429 - SV-256429r886068_rule
RMF Control
SC-8
Severity
High
CCI
CCI-002420
Version
ESXI-70-000074
Vuln IDs
  • V-256429
Rule IDs
  • SV-256429r886068_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-000480-VMM-002000, SRG-OS-000425-VMM-001710
Checks: C-60104r886066_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 the following: tlsv1,tlsv1.1,sslv3 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 not set to "tlsv1,tlsv1.1,sslv3" or the setting does not exist, this is a finding.

Fix: F-60047r886067_fix

From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host >> Configure >> System >> Advanced System Settings. Select the "UserVars.ESXiVPsDisabledProtocols" value and set it to the following: tlsv1,tlsv1.1,sslv3 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 "tlsv1,tlsv1.1,sslv3" Reboot the host for changes to take effect.

b
The ESXi host must enable Secure Boot.
CM-6 - Medium - CCI-000366 - V-256430 - SV-256430r886071_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
ESXI-70-000076
Vuln IDs
  • V-256430
Rule IDs
  • SV-256430r886071_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-60105r886069_chk

From an ESXi shell, run the following command: # /usr/lib/vmware/secureboot/bin/secureBoot.py -s If the output is not "Enabled", this is a finding.

Fix: F-60048r886070_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. If the discrepancies cannot be rectified, this finding is downgraded to a CAT III.

b
The ESXi host must use DOD-approved certificates.
CM-6 - Medium - CCI-000366 - V-256431 - SV-256431r886074_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
ESXI-70-000078
Vuln IDs
  • V-256431
Rule IDs
  • SV-256431r886074_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-60106r886072_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-60049r886073_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 must not suppress warnings that the local or remote shell sessions are enabled.
CM-6 - Medium - CCI-000366 - V-256432 - SV-256432r919023_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
ESXI-70-000079
Vuln IDs
  • V-256432
Rule IDs
  • SV-256432r919023_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-60107r886075_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" or the setting does not exist, this is a finding.

Fix: F-60050r918916_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 set 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-256433 - SV-256433r919025_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
ESXI-70-000081
Vuln IDs
  • V-256433
Rule IDs
  • SV-256433r919025_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 SA does not assume the vulnerability has been addressed.
Checks: C-60108r886078_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 "UserVars.SuppressHyperthreadWarning" is not set to "0" or the setting does not exist, this is a finding.

Fix: F-60051r919024_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 set 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 Secure Shell (SSH) daemon must disable port forwarding.
CM-6 - Medium - CCI-000366 - V-256434 - SV-256434r886083_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
ESXI-70-000082
Vuln IDs
  • V-256434
Rule IDs
  • SV-256434r886083_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-60109r886081_chk

From an ESXi shell, run the following command: # /usr/lib/vmware/openssh/bin/sshd -T|grep allowtcpforwarding Expected result: allowtcpforwarding no If the output does not match the expected result, this is a finding.

Fix: F-60052r886082_fix

From an ESXi shell, add or correct the following line in "/etc/ssh/sshd_config": AllowTcpForwarding no

b
The ESXi host OpenSLP service must be disabled.
CM-6 - Medium - CCI-000366 - V-256435 - SV-256435r886086_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
ESXI-70-000083
Vuln IDs
  • V-256435
Rule IDs
  • SV-256435r886086_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-60110r886084_chk

From the vSphere Client go to Hosts and Clusters. Select the ESXi Host &gt;&gt; Configure &gt;&gt; System &gt;&gt; Services. Locate the "slpd" service and verify that the "Daemon" 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-60053r886085_fix

From the vSphere Client go to Hosts and Clusters. Select the ESXi Host >> Configure >> System >> Services. Select the "slpd" service. If the service is started, click "Stop". Click "Edit Startup Policy...". Select "Start and stop manually". Click "OK". or From a PowerCLI command prompt while connected to the ESXi host, run the following command: 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-256436 - SV-256436r919017_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
ESXI-70-000084
Vuln IDs
  • V-256436
Rule IDs
  • SV-256436r919017_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/auditLogReader" utility over SSH or at the ESXi shell.
Checks: C-60111r919015_chk

From an ESXi shell, run the following command: # esxcli system auditrecords get or From a PowerCLI command prompt while connected to the ESXi host, run the following commands: $esxcli = Get-EsxCli -v2 $esxcli.system.auditrecords.get.invoke()|Format-List Example result: AuditRecordRemoteTransmissionActive : true AuditRecordStorageActive : true AuditRecordStorageCapacity : 100 AuditRecordStorageDirectory : /scratch/auditLog Note: The "Audit Record Storage Directory" may differ from the default above, but it must still be located on persistent storage. If audit record storage is not active and configured, this is a finding.

Fix: F-60054r919016_fix

From an ESXi shell, run the following commands: Optional: Set the audit log location to persistent storage. This is set to "/scratch/auditLog" by default and does not normally need to be changed. # esxcli system auditrecords local set --directory="/full/path/here" Mandatory: # esxcli system auditrecords local set --size=100 # esxcli system auditrecords local enable # esxcli system auditrecords remote enable # esxcli system syslog reload or From a PowerCLI command prompt while connected to the ESXi host, run the following commands: $esxcli = Get-EsxCli -v2 $arguments = $esxcli.system.auditrecords.local.set.CreateArgs() *Optional* $arguments.directory = "/full/path/here" $arguments.size="100" $esxcli.system.auditrecords.local.set.Invoke($arguments) $esxcli.system.auditrecords.local.enable.Invoke() $esxcli.system.auditrecords.remote.enable.Invoke()

b
The ESXi host must enable strict x509 verification for SSL syslog endpoints.
CM-6 - Medium - CCI-000366 - V-256437 - SV-256437r919026_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
ESXI-70-000085
Vuln IDs
  • V-256437
Rule IDs
  • SV-256437r919026_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-60112r918920_chk

If SSL is not used for the syslog target, this is not applicable. From an ESXi shell, run the following command: # esxcli system syslog config get|grep 509 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 StrictX509Compliance Expected result: Strict X509Compliance: true If the output does not match the expected result, this is a finding.

Fix: F-60055r886091_fix

From an ESXi shell, run the following commands: # esxcli system syslog config set --x509-strict="true" # esxcli system syslog reload 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.set.CreateArgs() $arguments.x509strict = $true $esxcli.system.syslog.config.set.Invoke($arguments) $esxcli.system.syslog.reload.Invoke()

b
The ESXi host must verify certificates for SSL syslog endpoints.
CM-6 - Medium - CCI-000366 - V-256438 - SV-256438r886095_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
ESXI-70-000086
Vuln IDs
  • V-256438
Rule IDs
  • SV-256438r886095_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-60113r886093_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.logCheckSSLCerts" 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.logCheckSSLCerts If the "Syslog.global.logCheckSSLCerts" setting is not set to "true", this is a finding.

Fix: F-60056r886094_fix

To configure SSL syslog endpoint certificate checking it must be turned on and also 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. Select the "Syslog.global.logCheckSSLCerts" value and set 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 follow command: # <path/to/cacert> >> /etc/vmware/ssl/castore.pem or From a PowerCLI command prompt while connected to the ESXi host, run the following command: Get-VMHost | Get-AdvancedSetting -Name Syslog.global.logCheckSSLCerts | 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-256439 - SV-256439r919028_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
ESXI-70-000087
Vuln IDs
  • V-256439
Rule IDs
  • SV-256439r919028_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-60114r886096_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-60057r919027_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 set 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-256440 - SV-256440r886101_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
ESXI-70-000088
Vuln IDs
  • V-256440
Rule IDs
  • SV-256440r886101_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-60115r886099_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-60058r886100_fix

From the vSphere Client go to Hosts and Clusters. Select the ESXi Host >> Configure >> System >> Advanced System Settings. Select the "Config.HostAgent.vmacore.soap.sessionTimeout" value and set 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 Client must be configured with a session timeout.
CM-6 - Medium - CCI-000366 - V-256441 - SV-256441r886104_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
ESXI-70-000089
Vuln IDs
  • V-256441
Rule IDs
  • SV-256441r886104_rule
The ESXi Host Client is the UI served up by the host itself, outside of vCenter. It is accessed by browsing to "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-60116r886102_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 "600". 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 "600", this is a finding.

Fix: F-60059r886103_fix

From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host >> Configure >> System >> Advanced System Settings. Select the "UserVars.HostClientSessionTimeout" value and set 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.HostClientSessionTimeout | Set-AdvancedSetting -Value "600"

b
The ESXi host rhttpproxy daemon must use FIPS 140-2 validated cryptographic modules to protect the confidentiality of remote access sessions.
AC-17 - Medium - CCI-000068 - V-256442 - SV-256442r886107_rule
RMF Control
AC-17
Severity
Medium
CCI
CCI-000068
Version
ESXI-70-000090
Vuln IDs
  • V-256442
Rule IDs
  • SV-256442r886107_rule
ESXi runs a reverse proxy service called rhttpproxy that front ends internal services and application programming interfaces (APIs) over one HTTPS port by redirecting virtual paths to localhost ports. This proxy implements a FIPS 140-2 validated OpenSSL cryptographic module that is in FIPS mode by default. This configuration must be validated and maintained to protect the traffic that rhttpproxy manages.
Checks: C-60117r886105_chk

From an ESXi shell, run the following command: # esxcli system security fips140 rhttpproxy 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.rhttpproxy.get.invoke() Expected result: Enabled: true If the output does not match the expected result, this is a finding.

Fix: F-60060r886106_fix

From an ESXi shell, run the following command: # esxcli system security fips140 rhttpproxy 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.rhttpproxy.set.CreateArgs() $arguments.enable = $true $esxcli.system.security.fips140.rhttpproxy.set.Invoke($arguments)

b
The ESXi host must be configured with an appropriate maximum password age.
CM-6 - Medium - CCI-000366 - V-256443 - SV-256443r919030_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
ESXI-70-000091
Vuln IDs
  • V-256443
Rule IDs
  • SV-256443r919030_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-60118r886108_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-60061r919029_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 set 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 host must not be configured to override virtual machine (VM) configurations.
CM-6 - Medium - CCI-000366 - V-256444 - SV-256444r886113_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
ESXI-70-000092
Vuln IDs
  • V-256444
Rule IDs
  • SV-256444r886113_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-60119r886111_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-60062r886112_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-256445 - SV-256445r919031_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
ESXI-70-000093
Vuln IDs
  • V-256445
Rule IDs
  • SV-256445r919031_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-60120r886114_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-60063r918926_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-256446 - SV-256446r919032_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
ESXI-70-000094
Vuln IDs
  • V-256446
Rule IDs
  • SV-256446r919032_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-60121r918928_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|grep Mode 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 output does not match the expected result, this is a finding.

Fix: F-60064r886118_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 the BIOS. 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) Evacuate the host and gracefully reboot for changes to take effect.

b
The ESXi host must implement Secure Boot enforcement.
AU-9 - Medium - CCI-001494 - V-256447 - SV-256447r886122_rule
RMF Control
AU-9
Severity
Medium
CCI
CCI-001494
Version
ESXI-70-000095
Vuln IDs
  • V-256447
Rule IDs
  • SV-256447r886122_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. Note: This setting is only available in 7.0 Update 2 and later. Satisfies: SRG-OS-000480-VMM-002000, SRG-OS-000257-VMM-000910, SRG-OS-000278-VMM-001000, SRG-OS-000446-VMM-001790
Checks: C-60122r886120_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|grep "Secure Boot" 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 the output does not match the expected result, this is a finding.

Fix: F-60065r886121_fix

This setting cannot be configured until Secure Boot is properly enabled in the BIOS. From an ESXi shell, run the following command: # esxcli system settings encryption set --require-secure-boot=true 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 Common Information Model (CIM) service must be disabled.
CM-6 - Medium - CCI-000366 - V-256448 - SV-256448r886125_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
ESXI-70-000097
Vuln IDs
  • V-256448
Rule IDs
  • SV-256448r886125_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-60123r886123_chk

From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host &gt;&gt; Configure &gt;&gt; System &gt;&gt; Services. Locate the "CIM Server" service and verify the "Daemon" 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 slpd service does not have a "Policy" of "off" or is running, this is a finding.

Fix: F-60066r886124_fix

From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host >> Configure >> System >> Services. Select the "CIM Server" service. If the service is started, click "Stop". Click "Edit Startup Policy...". Select "Start and stop manually". 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 SSH daemon must be configured to only use FIPS 140-2 validated ciphers.
SC-13 - Medium - CCI-002450 - V-256449 - SV-256449r886128_rule
RMF Control
SC-13
Severity
Medium
CCI
CCI-002450
Version
ESXI-70-000274
Vuln IDs
  • V-256449
Rule IDs
  • SV-256449r886128_rule
Use of weak or untested encryption algorithms undermines the purposes of using encryption to protect data. ESXi must implement cryptographic modules adhering to the higher standards approved by the federal government because this provides assurance they have been tested and validated.
Checks: C-60124r886126_chk

From an ESXi shell, run the following command: # /usr/lib/vmware/openssh/bin/sshd -T|grep ciphers Expected result: ciphers aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr If the output does not match the expected result, this is a finding.

Fix: F-60067r886127_fix

From an ESXi shell, add or correct the following line in "/etc/ssh/sshd_config": Ciphers aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr