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

VMware vSphere 6.7 ESXi Security Technical Implementation Guide

V1R2 · · · Released 08 Feb 2022 · 73 rules
Compare

Pick two releases to diff their requirements.

View

Open a previous version of this STIG.

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

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

Removed rules 1

  • V-239330 Medium The ESXi host must centrally review and analyze audit records from multiple components within the system by configuring remote logging.

Content changes 4

  • V-239293 Medium check ESXi hosts using Host Profiles and/or Auto Deploy must use the vSphere Authentication Proxy to protect passwords when adding themselves to Active Directory.
  • V-239295 Low check The ESXi host must use multifactor authentication for local DCUI access to privileged accounts.
  • V-239299 Low check The ESXi host must enable kernel core dumps.
  • V-239331 Medium checkfix The ESXi host SSH daemon must be configured to only use FIPS 140-2 approved ciphers.
Sort by
b
Access to the ESXi host must be limited by enabling Lockdown Mode.
AC-10 - Medium - CCI-000054 - V-239258 - SV-239258r674703_rule
RMF Control
AC-10
Severity
M
CCI
CCI-000054
Version
ESXI-67-000001
Vuln IDs
  • V-239258
Rule IDs
  • SV-239258r674703_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-42491r674701_chk

From the vSphere Client, select the ESXi host and go to Configure >> System >> Security Profile. Scroll down to "Lockdown Mode" and verify it is 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. For environments that do not use vCenter server to manage ESXi, this is Not Applicable.

Fix: F-42450r674702_fix

From the vSphere Client, select the ESXi host and go to Configure >> System >> Security Profile. Click "Edit" in "Lockdown Mode" and enable ("Normal" or "Strict"). 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 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.

a
The ESXi host must verify the DCUI.Access list.
CM-6 - Low - CCI-000366 - V-239259 - SV-239259r674706_rule
RMF Control
CM-6
Severity
L
CCI
CCI-000366
Version
ESXI-67-000002
Vuln IDs
  • V-239259
Rule IDs
  • SV-239259r674706_rule
Lockdown mode disables direct host access, requiring that administrators manage hosts from vCenter Server. However, if a host becomes isolated from vCenter Server, the administrator is locked out and can no longer manage the host. If using normal Lockdown Mode, avoid becoming locked out of an ESXi host that is running in Lockdown Mode by setting DCUI.Access to a list of highly trusted users who can override Lockdown Mode and access the DCUI. The DCUI is not running in strict Lockdown Mode.
Checks: C-42492r674704_chk

For environments that do not use vCenter server to manage ESXi, this is Not Applicable. From the vSphere Client, select the ESXi host and go to Configure &gt;&gt; System &gt;&gt; Advanced System Settings. Select the "DCUI.Access" value and verify that 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-42451r674705_fix

From the vSphere Client, select the ESXi host and go to 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"

a
The ESXi host must verify the exception users list for Lockdown Mode.
CM-6 - Low - CCI-000366 - V-239260 - SV-239260r674709_rule
RMF Control
CM-6
Severity
L
CCI
CCI-000366
Version
ESXI-67-000003
Vuln IDs
  • V-239260
Rule IDs
  • SV-239260r674709_rule
In vSphere, users can be added to the Exception Users list from the vSphere Web Client. These users do not lose their permissions when the host enters Lockdown Mode. Before adding service accounts such as a backup agent to the Exception Users list, verify that the list of users who are exempted from losing permissions is legitimate and as needed per the environment. Users who do not require special permissions should not be exempted from Lockdown Mode.
Checks: C-42493r674707_chk

For environments that do not use vCenter server to manage ESXi, this is Not Applicable. From the vSphere Client, select the ESXi host and go to 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: This list is not intended for system administrator accounts but for special circumstances such as a service account.

Fix: F-42452r674708_fix

From the vSphere Client, select the ESXi host and go to Configure >> System >> Security Profile. Under "Lockdown Mode", click "Edit" and remove unnecessary users from the exceptions list.

b
Remote logging for ESXi hosts must be configured.
AC-17 - Medium - CCI-000067 - V-239261 - SV-239261r674712_rule
RMF Control
AC-17
Severity
M
CCI
CCI-000067
Version
ESXI-67-000004
Vuln IDs
  • V-239261
Rule IDs
  • SV-239261r674712_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 also provides a long-term audit record. Satisfies: SRG-OS-000032-VMM-000130, SRG-OS-000342-VMM-001230, SRG-OS-000479-VMM-001990
Checks: C-42494r674710_chk

From the vSphere Client, select the ESXi host and go to 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 hostname. 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 site-specific syslog server, this is a finding.

Fix: F-42453r674711_fix

From the vSphere Client, select the ESXi host and go to 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 commands: 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-239262 - SV-239262r674715_rule
RMF Control
AC-7
Severity
M
CCI
CCI-000044
Version
ESXI-67-000005
Vuln IDs
  • V-239262
Rule IDs
  • SV-239262r674715_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-42495r674713_chk

From the vSphere Client, select the ESXi host and go to 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 "Security.AccountLockFailures" is set to a value other than "3", this is a finding.

Fix: F-42454r674714_fix

From the vSphere Client, select the ESXi host and go to 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 the unlock timeout of 15 minutes after a user account is locked out.
AC-7 - Medium - CCI-002238 - V-239263 - SV-239263r674718_rule
RMF Control
AC-7
Severity
M
CCI
CCI-002238
Version
ESXI-67-000006
Vuln IDs
  • V-239263
Rule IDs
  • SV-239263r674718_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-42496r674716_chk

From the vSphere Client, select the ESXi host and go to 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" is set to a value other than "900", this is a finding.

Fix: F-42455r674717_fix

From the vSphere Client, select the ESXi host and go to Configure >> System >> Advanced System Settings. Click "Edit" and 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 DCUI.
AC-8 - Medium - CCI-000048 - V-239264 - SV-239264r674721_rule
RMF Control
AC-8
Severity
M
CCI
CCI-000048
Version
ESXI-67-000007
Vuln IDs
  • V-239264
Rule IDs
  • SV-239264r674721_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-42497r674719_chk

From the vSphere Client, select the ESXi host and go to Configure &gt;&gt; System &gt;&gt; Advanced System Settings. Select the "Annotations.WelcomeMessage" value and verify it contains the DoD logon banner to follow. or From a PowerCLI command prompt while connected to the ESXi host, run the following command: Get-VMHost | Get-AdvancedSetting -Name Annotations.WelcomeMessage Check for either of the following logon banners based on the character limitations imposed by the system. An exact match of the text is required. If one of these banners is not displayed, 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. OR I've read &amp; consent to terms in IS user agreem't. If the DCUI logon screen does not display the DoD logon banner, this is a finding.

Fix: F-42456r674720_fix

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

b
The ESXi host must display the Standard Mandatory DoD Notice and Consent Banner before granting access to the system via SSH.
AC-8 - Medium - CCI-000048 - V-239265 - SV-239265r674724_rule
RMF Control
AC-8
Severity
M
CCI
CCI-000048
Version
ESXI-67-000008
Vuln IDs
  • V-239265
Rule IDs
  • SV-239265r674724_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-42498r674722_chk

From the vSphere Client, select the ESXi host and go to 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-42457r674723_fix

From the vSphere Client, select the ESXi host and go to 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 commands: 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-239266 - SV-239266r674727_rule
RMF Control
AC-8
Severity
M
CCI
CCI-000048
Version
ESXI-67-000009
Vuln IDs
  • V-239266
Rule IDs
  • SV-239266r674727_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 usage of a banner that does not provide easy attribution.
Checks: C-42499r674725_chk

From an SSH session connected to the ESXi host, or from the ESXi shell, run the following command: # grep -i "^Banner" /etc/ssh/sshd_config If there is no output or the output is not exactly "Banner /etc/issue", this is a finding.

Fix: F-42458r674726_fix

From an SSH session connected to the ESXi host, or from the ESXi shell, add or correct the following line in "/etc/ssh/sshd_config": Banner /etc/issue

b
The ESXi host SSH daemon must use DoD-approved encryption to protect the confidentiality of remote access sessions.
AC-17 - Medium - CCI-000068 - V-239267 - SV-239267r674730_rule
RMF Control
AC-17
Severity
M
CCI
CCI-000068
Version
ESXI-67-000010
Vuln IDs
  • V-239267
Rule IDs
  • SV-239267r674730_rule
Approved algorithms should impart some level of confidence in their implementation. Limit the ciphers to algorithms that are FIPS approved. Counter (CTR) mode is also preferred over cipher-block chaining (CBC) mode.
Checks: C-42500r674728_chk

To verify that only FIPS-approved ciphers are in use, run the following command from an SSH session connected to the ESXi host, or from the ESXi shell: # grep -i "^FipsMode" /etc/ssh/sshd_config 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() If there is no output or the output is not exactly "FipsMode yes" over SSH, or enabled is not "true" over PowerCLI, this is a finding.

Fix: F-42459r674729_fix

Limit the ciphers to FIPS-approved algorithms. From an SSH session connected to the ESXi host, or from the ESXi shell, add or correct the following line in "/etc/ssh/sshd_config": FipsMode yes 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 SSH daemon must ignore .rhosts files.
IA-2 - Medium - CCI-000767 - V-239268 - SV-239268r674733_rule
RMF Control
IA-2
Severity
M
CCI
CCI-000767
Version
ESXI-67-000012
Vuln IDs
  • V-239268
Rule IDs
  • SV-239268r674733_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-42501r674731_chk

From an SSH session connected to the ESXi host, or from the ESXi shell, run the following command: # grep -i "^IgnoreRhosts" /etc/ssh/sshd_config If there is no output or the output is not exactly "IgnoreRhosts yes", this is a finding.

Fix: F-42460r674732_fix

From an SSH session connected to the ESXi host, or from the ESXi shell, add or correct the following line in "/etc/ssh/sshd_config": Add or correct the following line in "/etc/ssh/sshd_config": IgnoreRhosts yes

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

From an SSH session connected to the ESXi host, or from the ESXi shell, run the following command: # grep -i "^HostbasedAuthentication" /etc/ssh/sshd_config If there is no output or the output is not exactly "HostbasedAuthentication no", this is a finding.

Fix: F-42461r674735_fix

From an SSH session connected to the ESXi host, or from the ESXi shell, add or correct the following line in "/etc/ssh/sshd_config": Add or correct the following line in "/etc/ssh/sshd_config": HostbasedAuthentication no

a
The ESXi host SSH daemon must not permit root logins.
CM-6 - Low - CCI-000366 - V-239270 - SV-239270r674739_rule
RMF Control
CM-6
Severity
L
CCI
CCI-000366
Version
ESXI-67-000014
Vuln IDs
  • V-239270
Rule IDs
  • SV-239270r674739_rule
Permitting direct root login reduces auditable information about who ran privileged commands on the system and also allows direct attack attempts on root's password.
Checks: C-42503r674737_chk

From an SSH session connected to the ESXi host, or from the ESXi shell, run the following command: # grep -i "^PermitRootLogin" /etc/ssh/sshd_config If there is no output or the output is not exactly "PermitRootLogin no", this is a finding.

Fix: F-42462r674738_fix

From an SSH session connected to the ESXi host, or from the ESXi shell, add or correct the following line in "/etc/ssh/sshd_config": Add or correct the following line in "/etc/ssh/sshd_config": PermitRootLogin no

c
The ESXi host SSH daemon must not allow authentication using an empty password.
CM-6 - High - CCI-000366 - V-239271 - SV-239271r674742_rule
RMF Control
CM-6
Severity
H
CCI
CCI-000366
Version
ESXI-67-000015
Vuln IDs
  • V-239271
Rule IDs
  • SV-239271r674742_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-42504r674740_chk

From an SSH session connected to the ESXi host, or from the ESXi shell, run the following command: # grep -i "^PermitEmptyPasswords" /etc/ssh/sshd_config If there is no output or the output is not exactly "PermitEmptyPasswords no", this is a finding.

Fix: F-42463r674741_fix

From an SSH session connected to the ESXi host, or from the ESXi shell, add or correct the following line in "/etc/ssh/sshd_config": PermitEmptyPasswords no

b
The ESXi host SSH daemon must not permit user environment settings.
CM-6 - Medium - CCI-000366 - V-239272 - SV-239272r674745_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
ESXI-67-000016
Vuln IDs
  • V-239272
Rule IDs
  • SV-239272r674745_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-42505r674743_chk

From an SSH session connected to the ESXi host, or from the ESXi shell, run the following command: # grep -i "^PermitUserEnvironment" /etc/ssh/sshd_config If there is no output or the output is not exactly "PermitUserEnvironment no", this is a finding.

Fix: F-42464r674744_fix

From an SSH session connected to the ESXi host, or from the ESXi shell, add or correct the following line in "/etc/ssh/sshd_config": PermitUserEnvironment no

a
The ESXi host SSH daemon must not permit GSSAPI authentication.
CM-6 - Low - CCI-000366 - V-239273 - SV-239273r674748_rule
RMF Control
CM-6
Severity
L
CCI
CCI-000366
Version
ESXI-67-000018
Vuln IDs
  • V-239273
Rule IDs
  • SV-239273r674748_rule
GSSAPI authentication is used to provide additional authentication mechanisms to applications. Allowing GSSAPI authentication through SSH exposes the system’s GSSAPI to remote hosts, increasing the attack surface of the system.
Checks: C-42506r674746_chk

From an SSH session connected to the ESXi host, or from the ESXi shell, run the following command: # grep -i "^GSSAPIAuthentication" /etc/ssh/sshd_config If there is no output or the output is not exactly "GSSAPIAuthentication no", this is a finding.

Fix: F-42465r674747_fix

From an SSH session connected to the ESXi host, or from the ESXi shell, add or correct the following line in "/etc/ssh/sshd_config": GSSAPIAuthentication no

a
The ESXi host SSH daemon must not permit Kerberos authentication.
CM-6 - Low - CCI-000366 - V-239274 - SV-239274r674751_rule
RMF Control
CM-6
Severity
L
CCI
CCI-000366
Version
ESXI-67-000019
Vuln IDs
  • V-239274
Rule IDs
  • SV-239274r674751_rule
Kerberos authentication for SSH is often implemented using GSSAPI. If Kerberos is enabled through SSH, the SSH daemon provides a means of access to the system's Kerberos implementation. Vulnerabilities in the system's Kerberos implementation may then be subject to exploitation. To reduce the attack surface of the system, the Kerberos authentication mechanism within SSH must be disabled for systems.
Checks: C-42507r674749_chk

From an SSH session connected to the ESXi host, or from the ESXi shell, run the following command: # grep -i "^KerberosAuthentication" /etc/ssh/sshd_config If there is no output or the output is not exactly "KerberosAuthentication no", this is a finding.

Fix: F-42466r674750_fix

From an SSH session connected to the ESXi host, or from the ESXi shell, add or correct the following line in "/etc/ssh/sshd_config": KerberosAuthentication no

b
The ESXi host SSH daemon must perform strict mode checking of home directory configuration files.
CM-6 - Medium - CCI-000366 - V-239275 - SV-239275r674754_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
ESXI-67-000020
Vuln IDs
  • V-239275
Rule IDs
  • SV-239275r674754_rule
If other users have access to modify user-specific SSH configuration files, they may be able to log on to the system as another user.
Checks: C-42508r674752_chk

From an SSH session connected to the ESXi host, or from the ESXi shell, run the following command: # grep -i "^StrictModes" /etc/ssh/sshd_config If there is no output or the output is not exactly "StrictModes yes", this is a finding.

Fix: F-42467r674753_fix

From an SSH session connected to the ESXi host, or from the ESXi shell, add or correct the following line in "/etc/ssh/sshd_config": StrictModes yes

b
The ESXi host SSH daemon must not allow compression or must only allow compression after successful authentication.
CM-6 - Medium - CCI-000366 - V-239276 - SV-239276r674757_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
ESXI-67-000021
Vuln IDs
  • V-239276
Rule IDs
  • SV-239276r674757_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-42509r674755_chk

From an SSH session connected to the ESXi host, or from the ESXi shell, run the following command: # grep -i "^Compression" /etc/ssh/sshd_config If there is no output or the output is not exactly "Compression no", this is a finding.

Fix: F-42468r674756_fix

From an SSH session connected to the ESXi host, or from the ESXi shell, add or correct the following line in "/etc/ssh/sshd_config": Compression no

a
The ESXi host SSH daemon must be configured to not allow gateway ports.
CM-6 - Low - CCI-000366 - V-239277 - SV-239277r674760_rule
RMF Control
CM-6
Severity
L
CCI
CCI-000366
Version
ESXI-67-000022
Vuln IDs
  • V-239277
Rule IDs
  • SV-239277r674760_rule
SSH TCP connection forwarding provides a mechanism to establish TCP connections proxied by the SSH server. 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). Gateway ports allow remote forwarded ports to bind to non-loopback addresses on the server.
Checks: C-42510r674758_chk

From an SSH session connected to the ESXi host, or from the ESXi shell, run the following command: # grep -i "^GatewayPorts" /etc/ssh/sshd_config If there is no output or the output is not exactly "GatewayPorts no", this is a finding.

Fix: F-42469r674759_fix

From an SSH session connected to the ESXi host, or from the ESXi shell, add or correct the following line in "/etc/ssh/sshd_config": GatewayPorts no

b
The ESXi host SSH daemon must be configured to not allow X11 forwarding.
CM-6 - Medium - CCI-000366 - V-239278 - SV-239278r674763_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
ESXI-67-000023
Vuln IDs
  • V-239278
Rule IDs
  • SV-239278r674763_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-42511r674761_chk

From an SSH session connected to the ESXi host, or from the ESXi shell, run the following command: # grep -i "^X11Forwarding" /etc/ssh/sshd_config If there is no output or the output is not exactly "X11Forwarding no", this is a finding.

Fix: F-42470r674762_fix

From an SSH session connected to the ESXi host, or from the ESXi shell, add or correct the following line in "/etc/ssh/sshd_config": X11Forwarding no

b
The ESXi host SSH daemon must not accept environment variables from the client.
CM-6 - Medium - CCI-000366 - V-239279 - SV-239279r674766_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
ESXI-67-000024
Vuln IDs
  • V-239279
Rule IDs
  • SV-239279r674766_rule
Environment variables can be used to change the behavior of remote sessions and should be limited. Locale environment variables specify the language, character set, and other features modifying the operation of software to match the user's preferences.
Checks: C-42512r674764_chk

From an SSH session connected to the ESXi host, or from the ESXi shell, run the following command: # grep -i "^AcceptEnv" /etc/ssh/sshd_config If there is no output or the output is not exactly "AcceptEnv", this is a finding.

Fix: F-42471r674765_fix

From an SSH session connected to the ESXi host, or from the ESXi shell, add or correct the following line in "/etc/ssh/sshd_config": AcceptEnv

b
The ESXi host SSH daemon must not permit tunnels.
CM-6 - Medium - CCI-000366 - V-239280 - SV-239280r674769_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
ESXI-67-000025
Vuln IDs
  • V-239280
Rule IDs
  • SV-239280r674769_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-42513r674767_chk

From an SSH session connected to the ESXi host, or from the ESXi shell, run the following command: # grep -i "^PermitTunnel" /etc/ssh/sshd_config If there is no output or the output is not exactly "PermitTunnel no", this is a finding.

Fix: F-42472r674768_fix

From an SSH session connected to the ESXi host, or from the ESXi shell, add or correct the following line in "/etc/ssh/sshd_config": PermitTunnel no

a
The ESXi host SSH daemon must set a timeout count on idle sessions.
CM-6 - Low - CCI-000366 - V-239281 - SV-239281r674772_rule
RMF Control
CM-6
Severity
L
CCI
CCI-000366
Version
ESXI-67-000026
Vuln IDs
  • V-239281
Rule IDs
  • SV-239281r674772_rule
Setting a timeout ensures that a user login will be terminated as soon as the "ClientAliveCountMax" is reached.
Checks: C-42514r674770_chk

From an SSH session connected to the ESXi host, or from the ESXi shell, run the following command: # grep -i "^ClientAliveCountMax" /etc/ssh/sshd_config If there is no output or the output is not exactly "ClientAliveCountMax 3", this is a finding.

Fix: F-42473r674771_fix

From an SSH session connected to the ESXi host, or from the ESXi shell, add or correct the following line in "/etc/ssh/sshd_config": ClientAliveCountMax 3

a
The ESXi host SSH daemon must set a timeout interval on idle sessions.
CM-6 - Low - CCI-000366 - V-239282 - SV-239282r674775_rule
RMF Control
CM-6
Severity
L
CCI
CCI-000366
Version
ESXI-67-000027
Vuln IDs
  • V-239282
Rule IDs
  • SV-239282r674775_rule
Automatically logging out idle users guards against compromises via hijacked administrative sessions.
Checks: C-42515r674773_chk

From an SSH session connected to the ESXi host, or from the ESXi shell, run the following command: # grep -i "^ClientAliveInterval" /etc/ssh/sshd_config If there is no output or the output is not exactly "ClientAliveInterval 200", this is a finding.

Fix: F-42474r674774_fix

From an SSH session connected to the ESXi host, or from the ESXi shell, add or correct the following line in "/etc/ssh/sshd_config": ClientAliveInterval 200

b
The ESXi host SSH daemon must limit connections to a single session.
CM-6 - Medium - CCI-000366 - V-239283 - SV-239283r674778_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
ESXI-67-000028
Vuln IDs
  • V-239283
Rule IDs
  • SV-239283r674778_rule
The SSH protocol has the ability to provide multiple sessions over a single connection without reauthentication. A compromised client could use this feature to establish additional sessions to a system without consent or knowledge of the user.
Checks: C-42516r674776_chk

From an SSH session connected to the ESXi host, or from the ESXi shell, run the following command: # grep -i "^MaxSessions" /etc/ssh/sshd_config If there is no output or the output is not exactly "MaxSessions 1", this is a finding.

Fix: F-42475r674777_fix

From an SSH session connected to the ESXi host, or from the ESXi shell, add or correct the following line in "/etc/ssh/sshd_config": MaxSessions 1

b
The ESXi host must remove keys from the SSH authorized_keys file.
CM-6 - Medium - CCI-000366 - V-239284 - SV-239284r674781_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
ESXI-67-000029
Vuln IDs
  • V-239284
Rule IDs
  • SV-239284r674781_rule
ESXi hosts come with SSH, which can be enabled to allow remote access without requiring user authentication. To enable password-free access, copy the remote user's public key into the "/etc/ssh/keys-root/authorized_keys" file on the ESXi host. The presence of the remote user's public key in the "authorized_keys" file identifies the user as trusted, meaning the user is granted access to the host without providing a password. If using Lockdown Mode and SSH is disabled, then logon with authorized keys will have the same restrictions as username/password.
Checks: C-42517r674779_chk

From an SSH session connected to the ESXi host, or from the ESXi shell, run the following command: # ls -la /etc/ssh/keys-root/authorized_keys or # cat /etc/ssh/keys-root/authorized_keys If the "authorized_keys" file exists and is not empty, this is a finding.

Fix: F-42476r674780_fix

From an SSH session connected to the ESXi host, or from the ESXi shell, zero out or remove the /etc/ssh/keys-root/authorized_keys file: # >/etc/ssh/keys-root/authorized_keys or # rm /etc/ssh/keys-root/authorized_keys

a
The ESXi host must produce audit records containing information to establish what type of events occurred.
AU-3 - Low - CCI-000130 - V-239285 - SV-239285r674784_rule
RMF Control
AU-3
Severity
L
CCI
CCI-000130
Version
ESXI-67-000030
Vuln IDs
  • V-239285
Rule IDs
  • SV-239285r674784_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-42518r674782_chk

From the vSphere Client, select the ESXi host and go to 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-42477r674783_fix

From the vSphere Client, select the ESXi Host and go to 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 commands: Get-VMHost | Get-AdvancedSetting -Name Config.HostAgent.log.level | Set-AdvancedSetting -Value "info"

b
The ESXi host must enforce password complexity by requiring that at least one uppercase character be used.
IA-5 - Medium - CCI-000192 - V-239286 - SV-239286r674787_rule
RMF Control
IA-5
Severity
M
CCI
CCI-000192
Version
ESXI-67-000031
Vuln IDs
  • V-239286
Rule IDs
  • SV-239286r674787_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-000078-VMM-000450, SRG-OS-000072-VMM-000390, SRG-OS-000266-VMM-000940
Checks: C-42519r674785_chk

From the vSphere Client, select the ESXi host and go to 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-42478r674786_fix

From the vSphere Client, select the ESXi host and go to 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 commands: 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-239287 - SV-239287r674790_rule
RMF Control
IA-5
Severity
M
CCI
CCI-000200
Version
ESXI-67-000032
Vuln IDs
  • V-239287
Rule IDs
  • SV-239287r674790_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-42520r674788_chk

From the vSphere Client, select the ESXi host and go to 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-42479r674789_fix

From the vSphere Client, select the ESXi host and go to Configure >> System >> Advanced System Settings. 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 password hashes stored on the ESXi host must have been generated using a FIPS 140-2 approved cryptographic hashing algorithm.
CM-6 - Medium - CCI-000366 - V-239288 - SV-239288r674793_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
ESXI-67-000033
Vuln IDs
  • V-239288
Rule IDs
  • SV-239288r674793_rule
Systems must employ cryptographic hashes for passwords using the SHA-2 family of algorithms or FIPS 140-2 approved successors. The use of unapproved algorithms may result in weak password hashes more vulnerable to compromise.
Checks: C-42521r674791_chk

From an SSH session connected to the ESXi host, or from the ESXi shell, run the following command: # grep -i "^password" /etc/pam.d/passwd | grep sufficient If sha512 is not listed, this is a finding.

Fix: F-42480r674792_fix

From an SSH session connected to the ESXi host, or from the ESXi shell, add or correct the following line in “/etc/pam.d/passwd”: password sufficient /lib/security/$ISA/pam_unix.so use_authtok nullok shadow sha512 remember=5

b
The ESXi host must disable the Managed Object Browser (MOB).
CM-7 - Medium - CCI-000381 - V-239289 - SV-239289r674796_rule
RMF Control
CM-7
Severity
M
CCI
CCI-000381
Version
ESXI-67-000034
Vuln IDs
  • V-239289
Rule IDs
  • SV-239289r674796_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 as well. This interface is meant to be used primarily for debugging the vSphere 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-42522r674794_chk

From the vSphere Client, select the ESXi Host and go to 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-42481r674795_fix

From the vSphere Client, select the ESXi Host and go to Configure >> System >> Advanced System Settings. Click "Edit" and 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 commands: 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 SSH.
CM-7 - Medium - CCI-000381 - V-239290 - SV-239290r674799_rule
RMF Control
CM-7
Severity
M
CCI
CCI-000381
Version
ESXI-67-000035
Vuln IDs
  • V-239290
Rule IDs
  • SV-239290r674799_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, 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-42523r674797_chk

From the vSphere Client, select the ESXi host and go to Configure &gt;&gt; System &gt;&gt; Services. Under "Services", select "Edit", view 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 ESXi SSH service is running, this is a finding.

Fix: F-42482r674798_fix

From the vSphere Client, select the ESXi host and go to Configure >> System >> Services. Under "Services", select "SSH" service and click the "Stop" button to stop the service. Use Edit Startup policy to "Start and stop manually" and 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-239291 - SV-239291r674802_rule
RMF Control
CM-7
Severity
M
CCI
CCI-000381
Version
ESXI-67-000036
Vuln IDs
  • V-239291
Rule IDs
  • SV-239291r674802_rule
The ESXi Shell is an interactive command line environment available locally from the DCUI or remotely via SSH. Activities performed from the ESXi Shell bypass vCenter RBAC and audit controls. The ESXi shell should only be turned on when needed to troubleshoot/resolve problems that cannot be fixed through the vSphere client.
Checks: C-42524r674800_chk

From the vSphere Client, select the ESXi host and go to Configure &gt;&gt; System &gt;&gt; Services. Under "Services", select "Edit", view 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-42483r674801_fix

From the vSphere Client, select the ESXi host and go to Configure >> System >> Services. Under "Services", select "ESXi Shell" service and click the "Stop" button to stop the service. Use Edit Startup policy to "Start and stop manually" and 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-239292 - SV-239292r674805_rule
RMF Control
IA-2
Severity
L
CCI
CCI-000764
Version
ESXI-67-000037
Vuln IDs
  • V-239292
Rule IDs
  • SV-239292r674805_rule
Join ESXi hosts to an Active Directory (AD) domain to eliminate the need to create and maintain multiple local user accounts. Using AD 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 AD group "ESX Admins" (default) exists, then all users and groups that are assigned as members to this group will have full administrative access to all ESXi hosts 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-42525r674803_chk

From the vSphere Client, select the ESXi host and go to 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 have no local user accounts, other than root and/or vpxuser, this is Not Applicable. For systems that do not use Active Directory and do have local user accounts, other than root and/or vpxuser, this is a finding. If the "Directory Services Type" is not set to "Active Directory", this is a finding.

Fix: F-42484r674804_fix

From the vSphere Client, select the ESXi host and go to Configure >> System >> Authentication Services. Click "Join Domain" and enter the AD domain to join. Select the "Using credentials” radio button, enter the credentials of an account with permissions to join machines to AD (use UPN naming – user@domain), and then 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"

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-239293 - SV-239293r816572_rule
RMF Control
IA-2
Severity
M
CCI
CCI-000764
Version
ESXI-67-000038
Vuln IDs
  • V-239293
Rule IDs
  • SV-239293r816572_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. Satisfies: SRG-OS-000104-VMM-000500, SRG-OS-000109-VMM-000550, SRG-OS-000112-VMM-000560, SRG-OS-000113-VMM-000570
Checks: C-42526r816571_chk

From the vSphere Client, go to Home &gt;&gt; Host Profiles and select a Host Profile to edit. View the settings under Security and Services &gt;&gt; Security Settings &gt;&gt; Authentication Configuration &gt;&gt; Active Directory Configuration &gt;&gt; Join Domain Method. Verify the method used to join hosts to a domain is set to "Use vSphere Authentication Proxy to add the host to domain". or From a PowerCLI command prompt while connected to the ESXi host, 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}} Verify that if "JoinADEnabled" is "True", "JoinDomainMethod" is "FixedCAMConfigOption". If not using Host Profiles to join active directory, this is not a finding.

Fix: F-42485r674807_fix

From the vSphere Client, go to Home >> Host Profiles and select a Host Profile to edit. View the settings under Security and Services >> Security Settings >> Authentication Configuration >> Active Directory Configuration >> Join Domain Method. Set the method used to join hosts to a domain to "Use vSphere Authentication Proxy to add the host to domain" and provide the IP address of the vSphere Authentication Proxy server.

a
Active Directory ESX Admin group membership must not be used when adding ESXi hosts to Active Directory.
IA-2 - Low - CCI-000764 - V-239294 - SV-239294r674811_rule
RMF Control
IA-2
Severity
L
CCI
CCI-000764
Version
ESXI-67-000039
Vuln IDs
  • V-239294
Rule IDs
  • SV-239294r674811_rule
When adding ESXi hosts to Active Directory (AD), all user/group accounts assigned to the AD 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 AD group and membership therein must be severely restricted. Satisfies: SRG-OS-000104-VMM-000500, SRG-OS-000109-VMM-000550, SRG-OS-000112-VMM-000560, SRG-OS-000113-VMM-000570
Checks: C-42527r674809_chk

From the vSphere Client, select the ESXi host and go to Configuration &gt;&gt; System &gt;&gt; Advanced System Settings. Click "Edit" and 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 For systems that do not use Active Directory, this is Not Applicable. If the "Config.HostAgent.plugins.hostsvc.esxAdminsGroup" key is set to "ESX Admins", this is a finding.

Fix: F-42486r674810_fix

From the vSphere Client, select the ESXi host and go to Configuration >> System >> Advanced System Settings. Click "Edit" and 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 commands: Get-VMHost | Get-AdvancedSetting -Name Config.HostAgent.plugins.hostsvc.esxAdminsGroup | Set-AdvancedSetting -Value <AD Group>

a
The ESXi host must use multifactor authentication for local DCUI access to privileged accounts.
IA-2 - Low - CCI-000767 - V-239295 - SV-239295r816574_rule
RMF Control
IA-2
Severity
L
CCI
CCI-000767
Version
ESXI-67-000040
Vuln IDs
  • V-239295
Rule IDs
  • SV-239295r816574_rule
To ensure accountability and prevent unauthenticated access, privileged users must utilize multifactor authentication to prevent potential misuse and compromise of the system. Note: This feature requires an existing PKI and AD integration. Satisfies: SRG-OS-000107-VMM-000530, SRG-OS-000376-VMM-001520, SRG-OS-000377-VMM-001530, SRG-OS-000403-VMM-001640
Checks: C-42528r816573_chk

From the vSphere Client, select the ESXi Host and go to Configure &gt;&gt; System &gt;&gt; Authentication Services and view the Smart Card Authentication status. If "Smart Card Mode" is "Disabled", this is a finding. For environments that do not have PKI or AD available, this is Not Applicable.

Fix: F-42487r674813_fix

The following are prerequisites to configuration of smart card authentication for the ESXi DCUI: - Active Directory domain that supports smart card authentication, smart card readers, and smart cards; - ESXi joined to an Active Directory domain; and - Trusted certificates for root and intermediary certificate authorities. From the vSphere Client, select the ESXi host and go to Configure >> System >> Authentication Services, click "Edit", and check the "Enable Smart Card Authentication" checkbox. At the "Certificates" tab, click the green plus sign to import trusted certificate authority certificates and click "OK".

b
The ESXi host must set a timeout to automatically disable idle shell sessions after two minutes.
SC-10 - Medium - CCI-001133 - V-239296 - SV-239296r674817_rule
RMF Control
SC-10
Severity
M
CCI
CCI-001133
Version
ESXI-67-000041
Vuln IDs
  • V-239296
Rule IDs
  • SV-239296r674817_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-42529r674815_chk

From the vSphere Client, select the ESXi host and go to Configure &gt;&gt; System &gt;&gt; Advanced System Settings. Select the "UserVars.ESXiShellInteractiveTimeOut" value and verify it is set to "120" (2 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-42488r674816_fix

From the vSphere Client, select the ESXi Host and go to 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 commands: 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-239297 - SV-239297r674820_rule
RMF Control
SC-10
Severity
M
CCI
CCI-001133
Version
ESXI-67-000042
Vuln IDs
  • V-239297
Rule IDs
  • SV-239297r674820_rule
When the ESXi Shell or 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. Satisfies: SRG-OS-000163-VMM-000700, SRG-OS-000279-VMM-001010
Checks: C-42530r674818_chk

From the vSphere Client, select the ESXi Host and go to 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-42489r674819_fix

From the vSphere Client, select the ESXi host and go to 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-239298 - SV-239298r674823_rule
RMF Control
SC-10
Severity
M
CCI
CCI-001133
Version
ESXI-67-000043
Vuln IDs
  • V-239298
Rule IDs
  • SV-239298r674823_rule
When the direct console user interface (DCUI) is enabled and logged in, it should be automatically logged out if left logged in to avoid access by unauthorized persons. The "DcuiTimeOut" setting defines a window of time after which the DCUI will be logged out. Satisfies: SRG-OS-000163-VMM-000700, SRG-OS-000279-VMM-001010
Checks: C-42531r674821_chk

From the vSphere Client, select the ESXi host and go to Configure &gt;&gt; System &gt;&gt; Advanced System Settings. Select the "UserVars.DcuiTimeOut" value and verify it is set to "120" (2 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-42490r674822_fix

From the vSphere Client, select the ESXi host and go to 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 commands: Get-VMHost | Get-AdvancedSetting -Name UserVars.DcuiTimeOut | Set-AdvancedSetting -Value 120

a
The ESXi host must enable kernel core dumps.
SC-24 - Low - CCI-001665 - V-239299 - SV-239299r816576_rule
RMF Control
SC-24
Severity
L
CCI
CCI-001665
Version
ESXI-67-000044
Vuln IDs
  • V-239299
Rule IDs
  • SV-239299r816576_rule
In the event of a system failure, the system must preserve any information necessary to determine cause of failure and any information necessary to return to operations with least disruption to mission processes.
Checks: C-42532r816575_chk

From the vSphere Client, select the ESXi host and right-click. If the "Add Diagnostic Partition" option is greyed out, core dumps are configured. or From a PowerCLI command prompt while connected to the ESXi host, run the following commands: $esxcli = Get-EsxCli -v2 $esxcli.system.coredump.partition.get.Invoke() $esxcli.system.coredump.network.get.Invoke() The first command prepares for the other two. The second command shows whether an active core dump partition is configured. The third command shows whether a network core dump collector is configured and enabled via the "HostVNic", "NetworkServerIP", "NetworkServerPort", and "Enabled" variables. If there is an active core dump partition, via the second command, this is not a finding. If there is a network core dump collector configured and enabled, this is not a finding. If there is no core dump partition and no network core dump collector configured, this is a finding.

Fix: F-42491r674825_fix

From the vSphere Client, select the ESXi host and right-click. Select the "Add Diagnostic Partition" option to configure a core dump diagnostic partition. or From a PowerCLI command prompt while connected to the ESXi host, run at least one of the following sets of commands: To configure a core dump partition: $esxcli = Get-EsxCli -v2 #View available partitions to configure $esxcli.system.coredump.partition.list.Invoke() $arguments = $esxcli.system.coredump.partition.set.CreateArgs() $arguments.partition = "<NAA ID of target partition from output listed previously>" $esxcli.system.coredump.partition.set.Invoke($arguments) #You can't set the partition and enable it at the same time so now we can enable it $arguments = $esxcli.system.coredump.partition.set.CreateArgs() $arguments.enable = $true $esxcli.system.coredump.partition.set.Invoke($arguments) To configure a core dump collector: $esxcli = Get-EsxCli -v2 $arguments = $esxcli.system.coredump.network.set.CreateArgs() $arguments.interfacename = "<vmkernel port to use>" $arguments.serverip = "<collector IP>" $arguments.serverport = "<collector port>" $arguments = $esxcli.system.coredump.network.set.Invoke($arguments) $arguments = $esxcli.system.coredump.network.set.CreateArgs() $arguments.enable = $true $arguments = $esxcli.system.coredump.network.set.Invoke($arguments)

b
The ESXi host must enable a persistent log location for all locally stored logs.
AU-4 - Medium - CCI-001849 - V-239300 - SV-239300r674829_rule
RMF Control
AU-4
Severity
M
CCI
CCI-001849
Version
ESXI-67-000045
Vuln IDs
  • V-239300
Rule IDs
  • SV-239300r674829_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 is 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 manually configured. ESXi Installable creates a 4 GB Fat16 partition on the target device during installation if there is sufficient space and if the device is considered "local". 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-42533r674827_chk

From the vSphere Client, select the ESXi host and go to Configure &gt;&gt; System &gt;&gt; Advanced System Settings. Select the "Syslog.global.logDir" value and verify it is set to a persistent location. 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-42492r674828_fix

From the vSphere Client, select the ESXi host and go to Configure >> System >> Advanced System Settings. Click "Edit" and select the "Syslog.global.logDir" value and set it to a known persistent location. or From a PowerCLI command prompt while connected to the ESXi host, run the following commands: 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-239301 - SV-239301r674832_rule
RMF Control
AU-8
Severity
M
CCI
CCI-001891
Version
ESXI-67-000046
Vuln IDs
  • V-239301
Rule IDs
  • SV-239301r674832_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-42534r674830_chk

From the vSphere Client, select the ESXi host and go to Configure &gt;&gt; System &gt;&gt; Time Configuration. Click "Edit" to verify the configured NTP servers and service startup policy. or From a PowerCLI command prompt while connected to the ESXi host, run the following command: 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-42493r674831_fix

From the vSphere Client, select the ESXi host and go to Configure >> System >> Time Configuration. 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 command: $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-239302 - SV-239302r674835_rule
RMF Control
CM-5
Severity
H
CCI
CCI-001749
Version
ESXI-67-000047
Vuln IDs
  • V-239302
Rule IDs
  • SV-239302r674835_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 CommunitySupported 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-42535r674833_chk

From the vSphere Client, select the ESXi host and go to 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-42494r674834_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 pull-down selection, set the acceptance level to be "VMwareCertified", "VMwareAccepted", or "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 also 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-239303 - SV-239303r674838_rule
RMF Control
SC-8
Severity
M
CCI
CCI-002418
Version
ESXI-67-000048
Vuln IDs
  • V-239303
Rule IDs
  • SV-239303r674838_rule
While encrypted vMotion is available now, vMotion traffic should still be sequestered from other traffic to further protect it from attack. This network must be only be accessible to other ESXi hosts preventing outside access to the network.
Checks: C-42536r674836_chk

Verify the vMotion VMKernel port group is in a dedicated VLAN, which can be on a common 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. For environments that do not use vCenter server to manage ESXi, this is Not Applicable. The check for this will be unique per environment. From the vSphere Client, select the ESXi host and go to Configuration &gt;&gt; Networking. Review the VLAN associated with the vMotion VMkernel(s) and verify it is dedicated for that purpose and 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-42495r674837_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 >> 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-239304 - SV-239304r674841_rule
RMF Control
SC-8
Severity
M
CCI
CCI-002418
Version
ESXI-67-000049
Vuln IDs
  • V-239304
Rule IDs
  • SV-239304r674841_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.
Checks: C-42537r674839_chk

Verify the Management VMkernel port group is on a dedicated VLAN, which can be on a common standard or distributed virtual switch as long as the Management VLAN is not shared by any other function and is not accessible to anything other than management-related functions such as vCenter. The check for this will be unique per environment. From the vSphere Client, select the ESXi host and go to Configure &gt;&gt; Networking. Review the VLAN associated with the Management VMkernel and verify it is dedicated for that purpose and is logically separated from other functions. If the network segment is accessible, except to networks where other management-related entities such as vCenter are located, this is a finding.

Fix: F-42496r674840_fix

From the vSphere Client, select the ESXi host and go to Configure >> Networking >> VMkernel adapters. Select the Management VMkernel and click "Edit". On the Port properties tab, uncheck everything but "Management.” On the IP Settings tab, enter the appropriate IP address and subnet information and click "OK". Set the appropriate VLAN ID >> Configure >> Networking >> Virtual switches. Select the Management portgroup and click "Edit". On the properties tab, enter the appropriate VLAN ID and 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-239305 - SV-239305r674844_rule
RMF Control
SC-8
Severity
M
CCI
CCI-002418
Version
ESXI-67-000050
Vuln IDs
  • V-239305
Rule IDs
  • SV-239305r674844_rule
Virtual machines 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 virtual machine 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 the production traffic. Configuring the IP-based storage adaptors on separate VLANs or network segments from other VMkernels and virtual machines will limit unauthorized users from viewing the traffic.
Checks: C-42538r674842_chk

If IP-based storage is not used, this is Not Applicable. Verify that IP-based storage (iSCSI, NFS, vSAN) VMkernel port groups are in a dedicated VLAN, which can be on a standard or distributed virtual switch that is logically separated from other traffic types. The check for this will be unique per environment. 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 it is dedicated for that purpose and logically separated from other functions. If any IP-based storage networks are not isolated from other traffic types, this is a finding.

Fix: F-42497r674843_fix

Configuration of an IP-Based VMkernel will be unique to each environment. However, as an example, to modify the IP address and VLAN information to the correct network on a standard switch for an iSCSI VMkernel, do the following: vSAN Example: From the vSphere Client, select the ESXi host and go to Configure >> Networking >> VMkernel adapters. Select the dedicated vSAN VMkernel adapter and click Edit settings. On the Port properties tab, uncheck everything but "vSAN.” On the IP Settings tab, enter the appropriate IP address and subnet information and click "OK". Set the appropriate VLAN ID by navigating to Configure >> Networking >> Virtual switches. Select the appropriate portgroup (iSCSI, NFS, vSAN) and click Edit settings. On the properties tab, enter the appropriate VLAN ID and click "OK".

a
The ESXi host must protect the confidentiality and integrity of transmitted information by using different TCP/IP stacks where possible.
SC-8 - Low - CCI-002418 - V-239306 - SV-239306r674847_rule
RMF Control
SC-8
Severity
L
CCI
CCI-002418
Version
ESXI-67-000052
Vuln IDs
  • V-239306
Rule IDs
  • SV-239306r674847_rule
Three different TCP/IP stacks are available by default on ESXi: Default, Provisioning, and vMotion. To better protect and isolate sensitive network traffic within ESXi, administrators must configure each of these stacks. Additional custom TCP/IP stacks can be created if desired.
Checks: C-42539r674845_chk

From the vSphere Client, select the ESXi host and go to Configure &gt;&gt; Networking &gt;&gt; TCP/IP configuration. Review the default system TCP/IP stacks and verify they are configured with the appropriate IP address information. If vMotion and Provisioning VMKernels are in use and are not using their own TCP/IP stack, this is a finding.

Fix: F-42498r674846_fix

From the vSphere Client, select the ESXi host and go to Configure >> Networking >> TCP/IP configuration. Select a TCP/IP stack and click "Edit". Enter the appropriate site-specific IP address information for the particular TCP/IP stack and click "OK".

b
SNMP must be configured properly on the ESXi host.
CM-6 - Medium - CCI-000366 - V-239307 - SV-239307r674850_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
ESXI-67-000053
Vuln IDs
  • V-239307
Rule IDs
  • SV-239307r674850_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 then use this information to plan an attack.
Checks: C-42540r674848_chk

From a PowerCLI command prompt while connected to the ESXi host, run the following command: Get-VMHostSnmp | Select * or From an console or ssh session, run the follow command: esxcli system snmp get If SNMP is not in use and is enabled, this is a finding. If SNMP is enabled and read-only communities is 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 from the esxcli command.

Fix: F-42499r674849_fix

To disable SNMP, run the following command from a PowerCLI command prompt while connected to the ESXi Host: Get-VMHostSnmp | Set-VMHostSnmp -Enabled $false or From a console or ssh session, run the follow command: esxcli system snmp set -e no To configure SNMP for v3 targets, use the "esxcli system snmp set" command set.

a
The ESXi host must enable bidirectional CHAP authentication for iSCSI traffic.
CM-6 - Low - CCI-000366 - V-239308 - SV-239308r674853_rule
RMF Control
CM-6
Severity
L
CCI
CCI-000366
Version
ESXI-67-000054
Vuln IDs
  • V-239308
Rule IDs
  • SV-239308r674853_rule
When enabled, vSphere performs bidirectional authentication of both the iSCSI target and host. There is a potential for a MiTM attack, when not authenticating both the iSCSI target and host, in which an attacker might impersonate either side of the connection to steal data. Bidirectional authentication mitigates this risk.
Checks: C-42541r674851_chk

From the vSphere Client, select the ESXi host and go to Configure &gt;&gt; Storage &gt;&gt; Storage Adapters. Select the iSCSI adapter &gt;&gt; Properties &gt;&gt; Authentication 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 not used, this is not a finding. 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-42500r674852_fix

From the vSphere Client, select the ESXi host and go to Configure >> Storage >> Storage Adapters. Select the iSCSI adapter >> Properties >> Authentication and click the "Edit" button. 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-VM transparent page sharing.
CM-6 - Low - CCI-000366 - V-239309 - SV-239309r674856_rule
RMF Control
CM-6
Severity
L
CCI
CCI-000366
Version
ESXI-67-000055
Vuln IDs
  • V-239309
Rule IDs
  • SV-239309r674856_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 AES encryption key in use on another virtual machine running on the same physical processor of the host server if Transparent Page Sharing is enabled between the two virtual machines. This technique works only in a highly controlled system configured in a non-standard 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 virtual machines by default (TPS will still be used within individual VMs).
Checks: C-42542r674854_chk

From the vSphere Client, select the ESXi host and go to 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-42501r674855_fix

From the vSphere Client, select the ESXi host and go to Configure >> System >> Advanced System Settings. Click "Edit", select the "Mem.ShareForceSalting" value, and configure it to "2". or From a PowerCLI command prompt while connected to the ESXi host, run the following commands: 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-239310 - SV-239310r674859_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
ESXI-67-000056
Vuln IDs
  • V-239310
Rule IDs
  • SV-239310r674859_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-42543r674857_chk

From the vSphere Client, select the ESXi host and go to Configure &gt;&gt; System &gt;&gt; Firewall. Under the "Firewall" section, click "Edit". For each enabled service, click "Firewall" and review the allowed IPs. Check this for incoming and outgoing connections. 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-42502r674858_fix

From the vSphere Client, select the ESXi host and go to Configure >> System >> Firewall. Under the "Firewall" section, 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. Configure this for incoming and outgoing connections. 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 command: $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-239311 - SV-239311r674862_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
ESXI-67-000057
Vuln IDs
  • V-239311
Rule IDs
  • SV-239311r674862_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 making sure this is set to deny incoming and outgoing traffic.
Checks: C-42544r674860_chk

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-42503r674861_fix

From a PowerCLI command prompt while connected to the ESXi host, run the following command: Get-VMHostFirewallDefaultPolicy | Set-VMHostFirewallDefaultPolicy -AllowIncoming $false -AllowOutgoing $false

a
The ESXi host must enable BPDU filter on the host to prevent being locked out of physical switch ports with Portfast and BPDU Guard enabled.
CM-6 - Low - CCI-000366 - V-239312 - SV-239312r674865_rule
RMF Control
CM-6
Severity
L
CCI
CCI-000366
Version
ESXI-67-000058
Vuln IDs
  • V-239312
Rule IDs
  • SV-239312r674865_rule
BPDU Guard and Portfast are commonly enabled on the physical switch to which the ESXi host is directly connected to reduce the STP convergence delay. If a BPDU packet is sent from a virtual machine on the ESXi host to the physical switch so configured, 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 SSL VPNs that use Windows bridging capability can legitimately generate BPDU packets. The administrator should verify that there are no legitimate BPDU packets generated by virtual machines on the ESXi host prior to enabling BPDU Filter. If BPDU Filter is enabled in this situation, enabling Reject Forged Transmits on the virtual switch port group adds protection against Spanning Tree loops.
Checks: C-42545r674863_chk

From the vSphere Client, select the ESXi host and go to 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-42504r674864_fix

From the vSphere Client, select the ESXi host and go to 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 commands: Get-VMHost | Get-AdvancedSetting -Name Net.BlockGuestBPDU | Set-AdvancedSetting -Value 1

b
The virtual switch Forged Transmits policy must be set to reject on the ESXi host.
CM-6 - Medium - CCI-000366 - V-239313 - SV-239313r674868_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
ESXI-67-000059
Vuln IDs
  • V-239313
Rule IDs
  • SV-239313r674868_rule
If the virtual machine operating system changes the MAC address, the operating system can send frames with an impersonated source MAC address at any time. 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 should 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-42546r674866_chk

From the vSphere Client, go to Configure &gt;&gt; Networking &gt;&gt; Virtual Switches. View the properties on each virtual switch and port group and verify "Forged Transmits" is set to reject. or From a PowerCLI command prompt while connected to the ESXi host, run the following commands: Get-VirtualSwitch | Get-SecurityPolicy Get-VirtualPortGroup | Get-SecurityPolicy If the "Forged Transmits" policy is set to accept (or true, via PowerCLI), this is a finding.

Fix: F-42505r674867_fix

From the vSphere Client, go to Configure >> Networking >> Virtual Switches. For each virtual switch and port group, click Edit settings (dots) and change "Forged Transmits" to reject. or From a PowerCLI command prompt while connected to the ESXi host, run the following commands: Get-VirtualSwitch | Get-SecurityPolicy | Set-SecurityPolicy -ForgedTransmits $false Get-VirtualPortGroup | Get-SecurityPolicy | Set-SecurityPolicy -ForgedTransmitsInherited $true

c
The virtual switch MAC Address Change policy must be set to reject on the ESXi host.
CM-6 - High - CCI-000366 - V-239314 - SV-239314r674871_rule
RMF Control
CM-6
Severity
H
CCI
CCI-000366
Version
ESXI-67-000060
Vuln IDs
  • V-239314
Rule IDs
  • SV-239314r674871_rule
If the virtual machine 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. It will affect applications that require this functionality, how a layer 2 bridge will operate, and 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-42547r674869_chk

From the vSphere Client, go to Configure &gt;&gt; Networking &gt;&gt; Virtual Switches. View the properties on each virtual switch and port group and 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 | Get-SecurityPolicy Get-VirtualPortGroup | Get-SecurityPolicy If the "MAC Address Changes" policy is set to accept (or true, via PowerCLI), this is a finding.

Fix: F-42506r674870_fix

From the vSphere Client, go to Configure >> Networking >> Virtual Switches. For each virtual switch and port group, click Edit settings (dots) and change "MAC Address Changes" to reject. or From a PowerCLI command prompt while connected to the ESXi host, run the following commands: Get-VirtualSwitch | Get-SecurityPolicy | Set-SecurityPolicy -MacChanges $false Get-VirtualPortGroup | Get-SecurityPolicy | Set-SecurityPolicy -MacChangesInherited $true

b
The virtual switch Promiscuous Mode policy must be set to reject on the ESXi host.
CM-6 - Medium - CCI-000366 - V-239315 - SV-239315r674874_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
ESXI-67-000061
Vuln IDs
  • V-239315
Rule IDs
  • SV-239315r674874_rule
When Promiscuous Mode is enabled for a virtual switch, all virtual machines connected to the Portgroup have the potential of reading all packets across that network, meaning 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-42548r674872_chk

From the vSphere Client, go to Configure &gt;&gt; Networking &gt;&gt; Virtual Switches. View the properties on each virtual switch and port group and verify that "Promiscuous Mode" is set to reject. or From a PowerCLI command prompt while connected to the ESXi host, run the following commands: Get-VirtualSwitch | Get-SecurityPolicy Get-VirtualPortGroup | Get-SecurityPolicy If the "Promiscuous Mode" policy is set to accept (or true, via PowerCLI), this is a finding.

Fix: F-42507r674873_fix

From the vSphere Client go to Configure >> Networking >> Virtual Switches. For each virtual switch and port group, click Edit settings (dots) and change "Promiscuous Mode" to reject. or From a PowerCLI command prompt while connected to the ESXi host, run the following commands: Get-VirtualSwitch | Get-SecurityPolicy | Set-SecurityPolicy -AllowPromiscuous $false Get-VirtualPortGroup | Get-SecurityPolicy | Set-SecurityPolicy -AllowPromiscuousInherited $true

b
The ESXi host must prevent unintended use of the dvFilter network APIs.
CM-6 - Medium - CCI-000366 - V-239316 - SV-239316r674877_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
ESXI-67-000062
Vuln IDs
  • V-239316
Rule IDs
  • SV-239316r674877_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 VM. If the API is enabled, an attacker might attempt to connect a VM to it, potentially providing access to the network of other VMs on the host. If the organization is using a product that uses this API, verify that the host has been configured correctly. If the organization is not using such a product, ensure the setting is blank.
Checks: C-42549r674875_chk

From the vSphere Client, select the ESXi host and go to 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-42508r674876_fix

From the vSphere Client, select the ESXi Host and go to 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
For the ESXi host, all port groups must be configured to a value other than that of the native VLAN.
CM-6 - Medium - CCI-000366 - V-239317 - SV-239317r674880_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
ESXI-67-000063
Vuln IDs
  • V-239317
Rule IDs
  • SV-239317r674880_rule
ESXi does not use the concept of native VLAN. Frames with 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 end up as belonging 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 correctly routed (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 VMs will not be visible to the native VLAN on the switch because the switch is expecting untagged traffic.
Checks: C-42550r674878_chk

From the vSphere Client, select the ESXi host and go to Configure &gt;&gt; Networking &gt;&gt; Virtual switches. For each virtual switch, review the port group VLAN tags and 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 | Select Name, VLanId If any port group is configured with the native VLAN of the attached physical switch, this is a finding.

Fix: F-42509r674879_fix

From the vSphere Client, select the ESXi host and go to Configure >> Networking >> Virtual switches. Highlight the port group where VLAN ID is set to native VLAN ID and click Edit settings (dots). 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
For the ESXi host, all port groups must not be configured to VLAN 4095 unless Virtual Guest Tagging (VGT) is required.
CM-6 - Medium - CCI-000366 - V-239318 - SV-239318r674883_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
ESXI-67-000064
Vuln IDs
  • V-239318
Rule IDs
  • SV-239318r674883_rule
When a port group is set to VLAN 4095, this activates VGT mode. In this mode, the vSwitch passes all network frames to the guest VM without modifying the VLAN tags, leaving it up to the guest to deal with them. VLAN 4095 should be used only if the guest has been specifically configured to manage VLAN tags itself. If VGT is enabled inappropriately, it might cause denial of service or allow a guest VM to interact with traffic on an unauthorized VLAN.
Checks: C-42551r674881_chk

From the vSphere Client, select the ESXi host and go to Configure &gt;&gt; Networking &gt;&gt; Virtual switches. For each virtual switch, review the port group VLAN tags and verify they are not set to 4095. or From a PowerCLI command prompt while connected to the ESXi host, run the following command: Get-VirtualPortGroup | Select Name, VLanID If any port group is configured with VLAN 4095 and is not documented as a needed exception, this is a finding.

Fix: F-42510r674882_fix

From the vSphere Client, select the ESXi host and go to Configure >> Networking >> Virtual switches. Highlight a port group where VLAN ID is set to 4095 and click Edit settings (dots). Change the VLAN ID to an appropriate 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
For the ESXi host, all port groups must not be configured to VLAN values reserved by upstream physical switches.
CM-6 - Medium - CCI-000366 - V-239319 - SV-239319r674886_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
ESXI-67-000065
Vuln IDs
  • V-239319
Rule IDs
  • SV-239319r674886_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-1024 and 4094, while Nexus switches typically reserve 3968-4047 and 4094. Check the documentation for the specific switch. Using a reserved VLAN might result in a denial of service on the network.
Checks: C-42552r674884_chk

From the vSphere Client, select the ESXi host and go to Configure &gt;&gt; Networking &gt;&gt; Virtual switches. For each virtual switch, review the port group VLAN tags and verify they are 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 | Select Name, VLanId If any port group is configured with a reserved VLAN ID, this is a finding.

Fix: F-42511r674885_fix

From the vSphere Client, select the ESXi host and go to Configure >> Networking >> Virtual switches. Highlight a port group where VLAN ID is set to a reserved value and click "Edit" settings (dots). Change the VLAN ID to an appropriate 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
For physical switch ports connected to the ESXi host, the non-negotiate option must be configured for trunk links between external physical switches and virtual switches in Virtual Switch Tagging (VST) mode.
CM-6 - Medium - CCI-000366 - V-239320 - SV-239320r674889_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
ESXI-67-000066
Vuln IDs
  • V-239320
Rule IDs
  • SV-239320r674889_rule
To communicate with virtual switches in VST mode, external switch ports must be configured as trunk ports. VST mode does not support Dynamic Trunking Protocol (DTP), so the trunk must be static and unconditional. The auto or desirable physical switch settings do not work with the ESXi Server because the physical switch communicates with the ESXi Server using DTP. The non-negotiate and on options unconditionally enable VLAN trunking on the physical switch and create a VLAN trunk link between the ESXi Server and the physical switch. The difference between non-negotiate and on options is that on mode still sends out DTP frames, whereas the non-negotiate option does not. The non-negotiate option should be used for all VLAN trunks to minimize unnecessary network traffic for virtual switches in VST mode.
Checks: C-42553r674887_chk

Note that this check refers to an entity outside the physical scope of the ESXi server system. The configuration of external switch ports as trunk ports must be documented. VST mode does not support DTP, so the trunk must be static and unconditional. Inspect the documentation and verify that it is correct and updated according to an organization-defined frequency and/or whenever modifications are made to either ESXi hosts or the upstream external switch ports. If DTP is enabled on the physical switch ports connected to the ESXi host, this is a finding.

Fix: F-42512r674888_fix

Note that this check refers to an entity outside the physical scope of the ESXi server system. Document the configuration of external switch ports as trunk ports. Log in to the vendor-specific physical switch and disable DTP on the physical switch ports connected to the ESXi host. Update the documentation according to an organization-defined frequency or whenever modifications are made to either ESXi hosts or the upstream external switch ports.

a
All ESXi host-connected physical switch ports must be configured with spanning tree disabled.
CM-6 - Low - CCI-000366 - V-239321 - SV-239321r674892_rule
RMF Control
CM-6
Severity
L
CCI
CCI-000366
Version
ESXI-67-000067
Vuln IDs
  • V-239321
Rule IDs
  • SV-239321r674892_rule
Since VMware virtual switches do not support STP, the ESXi host-connected physical switch ports must have portfast configured if spanning tree is enabled to avoid loops within the physical switch network. If these are not set, potential performance and connectivity issues might arise.
Checks: C-42554r674890_chk

Note that this check refers to an entity outside the physical scope of the ESXi server system. The configuration of upstream physical switches must be documented to ensure that spanning tree protocol is disabled and/or portfast is configured for all physical ports connected to ESXi hosts. Inspect the documentation and verify that the documentation is updated according to an organization-defined frequency and/or whenever modifications are made to either ESXi hosts or the upstream physical switches. Alternatively, log in to the physical switch and verify that spanning tree protocol is disabled and/or portfast is configured for all physical ports connected to ESXi hosts. If the physical switch's spanning tree protocol is not disabled or portfast is not configured for all physical ports connected to ESXi hosts, this is a finding.

Fix: F-42513r674891_fix

Note that this check refers to an entity outside the scope of the ESXi server system. Document the upstream physical switch configuration for spanning tree protocol disablement and/or portfast configuration for all physical ports connected to ESXi hosts. Log in to the physical switch(es) and disable spanning tree protocol and/or configure portfast for all physical ports connected to ESXi hosts. Update the documentation on an organization defined frequency or whenever modifications are made to either ESXi hosts or the upstream physical switches.

b
All ESXi host-connected virtual switch VLANs must be fully documented and have only the required VLANs.
CM-6 - Medium - CCI-000366 - V-239322 - SV-239322r674895_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
ESXI-67-000068
Vuln IDs
  • V-239322
Rule IDs
  • SV-239322r674895_rule
When defining a physical switch port for trunk mode, only specified VLANs must be configured on the VLAN trunk link. The risk with not fully documenting all VLANs on the vSwitch is that it is possible that a physical trunk port might be configured without needed VLANs, or with unneeded VLANs. This could enable an administrator to either accidentally or maliciously connect a VM to an unauthorized VLAN.
Checks: C-42555r674893_chk

Note that this check refers to an entity outside the physical scope of the ESXi server system. The configuration of upstream physical switches must be documented to ensure that unneeded VLANs are configured for all physical ports connected to ESXi hosts. Inspect the documentation and verify that the documentation is updated according to an organization-defined frequency and/or whenever modifications are made to either ESXi hosts or the upstream physical switches. Alternatively, log in to the physical switch and verify that only needed VLANs are configured for all physical ports connected to ESXi hosts. If the physical switch's configuration is trunked VLANs that are not used by ESXi for all physical ports connected to ESXi hosts, this is a finding.

Fix: F-42514r674894_fix

Note that this check refers to an entity outside the scope of the ESXi server system. Remove any VLANs trunked across physical ports connected to ESXi hosts that are not in use.

b
The ESXi host must not provide root/administrator-level access to CIM-based hardware monitoring tools or other third-party applications.
CM-6 - Medium - CCI-000366 - V-239323 - SV-239323r674898_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
ESXI-67-000070
Vuln IDs
  • V-239323
Rule IDs
  • SV-239323r674898_rule
The CIM system provides an interface that enables hardware-level management from remote applications via a set of standard APIs. Create a limited-privilege, read-only service account for CIM. Grant this role to the user on the ESXi server. Place this user in the Exception Users list. When/where write access is required, create/enable a limited-privilege service account and grant only the minimum required privileges.
Checks: C-42556r674896_chk

From the Host Client, select the ESXi host, right-click and go to "Permissions". Verify the CIM account user role is limited to read only and CIM permissions. If there is no dedicated CIM account and the root is used for CIM monitoring, this is a finding. If write access is not required and the access level is not "read-only", this is a finding.

Fix: F-42515r674897_fix

Create a role for the CIM 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 user 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 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 account from the drop-down list, select the new CIM role from the drop-down list, and click "Add User".

c
The SA must verify the integrity of the installation media before installing ESXi.
CM-6 - High - CCI-000366 - V-239324 - SV-239324r674901_rule
RMF Control
CM-6
Severity
H
CCI
CCI-000366
Version
ESXI-67-000071
Vuln IDs
  • V-239324
Rule IDs
  • SV-239324r674901_rule
Always check the SHA1 or MD5 hash after downloading an ISO, offline bundle, or patch to ensure integrity and authenticity of the downloaded files.
Checks: C-42557r674899_chk

The downloaded ISO, offline bundle, or patch hash must be verified against the vendor's checksum to ensure the integrity and authenticity of the files. See some typical command line example(s) for both the md5 and sha1 hash check(s) below: # md5sum &lt;filename&gt;.iso # sha1sum &lt;filename&gt;.iso If any of the system's downloaded ISO, offline bundle, or system patch hashes cannot be verified against the vendor's checksum, this is a finding.

Fix: F-42516r674900_fix

If the hash returned from the "md5sum" or "sha1sum" commands do not match the vendor's hash, the downloaded software must be discarded. If the physical media is obtained from VMware and the security seal is broken, the software must be returned to VMware for replacement.

c
The ESXi host must have all security patches and updates installed.
CM-6 - High - CCI-000366 - V-239325 - SV-239325r674904_rule
RMF Control
CM-6
Severity
H
CCI
CCI-000366
Version
ESXI-67-000072
Vuln IDs
  • V-239325
Rule IDs
  • SV-239325r674904_rule
Installing software updates is a fundamental mitigation against the exploitation of publicly known vulnerabilities.
Checks: C-42558r674902_chk

If vCenter Update Manager is used on the network, it can be used to scan all hosts for missing patches. From the vSphere Client, go to Hosts and Clusters &gt;&gt; Updates. Check under "Attached Baselines" and verify that a compliance check has been run. If vCenter Update Manager is not used, host compliance status must be determined manually by the build number. VMware KB 1014508 can be used to correlate patches with build numbers. 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-42517r674903_fix

If vCenter Update Manager is used on the network, hosts can be remediated from the vSphere Web Client. From the vSphere Client, go to Hosts and Clusters >> Updates. Check under "Attached Baselines". If there are no baselines attached, select the drop-down "Attach >> Attach Baseline or Baseline Group". Select "attach" and select the type of patches. Click on Check Compliance to check Host(s) Compliance. To manually remediate a host, the patch file must be copied locally and the following command run from an SSH session connected to the ESXi host or from the ESXi shell: esxcli software vib update -d <path to offline patch bundle.zip>

c
The ESXi host must exclusively enable TLS 1.2 for all endpoints.
CM-6 - High - CCI-000366 - V-239326 - SV-239326r674907_rule
RMF Control
CM-6
Severity
H
CCI
CCI-000366
Version
ESXI-67-000074
Vuln IDs
  • V-239326
Rule IDs
  • SV-239326r674907_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 the third-party software supports TLS 1.2. Be sure to modify TLS settings in the following order: 1. Platform Services Controllers (if applicable) 2. vCenter 3. ESXi
Checks: C-42559r674905_chk

From the vSphere Web Client, select the host and click Configure &gt;&gt; System &gt;&gt; Advanced System Settings. Find the "UserVars.ESXiVPsDisabledProtocols" value and verify that it is set to the following: tlsv1,tlsv1.1,sslv3 If the value is not set as above or it does not exist, this is a finding. 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 value returned is not "tlsv1,tlsv1.1,sslv3" or the setting does not exist, this is a finding.

Fix: F-42518r674906_fix

From the vSphere Web Client, select the host and click Configure >> System >> Advanced System Settings. Find 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" A host reboot is required for changes to take effect.

b
The ESXi host must enable Secure Boot.
CM-6 - Medium - CCI-000366 - V-239327 - SV-239327r674910_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
ESXI-67-000076
Vuln IDs
  • V-239327
Rule IDs
  • SV-239327r674910_rule
Secure Boot is a protocol of UEFI firmware that ensures the integrity of the boot process from hardware up through to the OS. 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.
Checks: C-42560r674908_chk

Temporarily enable SSH, connect to the ESXi host, and run the following command: /usr/lib/vmware/secureboot/bin/secureBoot.py -s If the output is not "Enabled", this is a finding.

Fix: F-42519r674909_fix

Temporarily enable SSH, connect to the ESXi host, and 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. Consult vendor documentation and boot the host into BIOS setup mode. Enable UEFI boot mode and Secure Boot. Restart the host. Temporarily enable SSH, connect to the ESXi host, and run the following command to verify that Secure Boot is enabled: /usr/lib/vmware/secureboot/bin/secureBoot.py -s

b
The ESXi host must use DoD-approved certificates.
CM-6 - Medium - CCI-000366 - V-239328 - SV-239328r674913_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
ESXI-67-000078
Vuln IDs
  • V-239328
Rule IDs
  • SV-239328r674913_rule
The default self-signed, VMware Certificate Authority-issued host certificate must be replaced with a DoD-approved certificate when the host will be accessed directly, such as during a VM console connection. The use of a DoD certificate on the host assures clients that the service they are connecting to is legitimate and properly secured.
Checks: C-42561r674911_chk

From the vSphere Web Client, select the host and click 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 (VM console connections bypass vCenter), this is not a finding.

Fix: F-42520r674912_fix

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. Put the host into maintenance mode. Temporarily enable SSH on the host. SCP 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 From the vSphere Web Client, select the vCenter Server and click Configure >> System >> Advanced Settings. Find the "vpxd.certmgmt value" and set it to "custom".

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

From the vSphere Web Client, select the host and click Configure &gt;&gt; System &gt;&gt; Advanced System Settings. Find the "UserVars.SuppressShellWarning" value and verify that it is set to the following: 0 If the value is not set as above or does not exist, this is a finding. 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 value returned is not "0" or the setting does not exist, this is a finding.

Fix: F-42521r674915_fix

From the vSphere Web Client, select the host and click Configure >> System >> Advanced System Settings. Find the "UserVars.SuppressShellWarning" value and set it to the following: 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 SSH daemon must be configured to only use FIPS 140-2 approved ciphers.
SC-13 - Medium - CCI-002450 - V-239331 - SV-239331r816580_rule
RMF Control
SC-13
Severity
M
CCI
CCI-002450
Version
ESXI-67-100010
Vuln IDs
  • V-239331
Rule IDs
  • SV-239331r816580_rule
Approved algorithms should impart some level of confidence in their implementation. These are also required for compliance.
Checks: C-42564r816578_chk

Verify that only FIPS-approved ciphers are used by running the following command: # grep -i "^Ciphers" /etc/ssh/sshd_config If there is no output, or the output is not exactly "Ciphers aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr", this is a finding.

Fix: F-42523r816579_fix

Limit the ciphers to algorithms that are FIPS approved. Counter (CTR) mode is also preferred over cipher-block chaining (CBC) mode. 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