VMware vSphere 6.5 ESXi V2R3

b

The ESXi host must limit the number of concurrent sessions to ten for all accounts and/or account types by enabling lockdown mode.

AC-10 - Medium - CCI-000054 - V-207602 - SV-207602r378532_rule

RMF Control

AC-10

Severity

M

CCI

CCI-000054

Version

ESXI-65-000001

Vuln IDs

V-207602
V-93949

Rule IDs

SV-207602r378532_rule
SV-104035

Enabling lockdown mode disables direct access to an ESXi host requiring the host 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 into a host directly. By forcing all interaction to occur through vCenter Server, the risk of someone inadvertently attaining elevated privileges or performing tasks that are not properly audited is greatly reduced.

Checks: C-7857r364205_chk

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

Fix: F-7857r364206_fix

From the vSphere Web Client select the ESXi Host and go to Configure >> System >> Security Profile. Click edit on "Lockdown Mode" and set to Enabled (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 Web 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-207603 - SV-207603r388482_rule

RMF Control

CM-6

Severity

L

CCI

CCI-000366

Version

ESXI-65-000002

Vuln IDs

V-207603
V-93951

Rule IDs

SV-207603r388482_rule
SV-104037

Lockdown mode disables direct host access requiring that admins manage hosts from vCenter Server. However, if a host becomes isolated from vCenter Server, the admin is locked out and can no longer manage the host. If you are using normal lockdown mode, you can 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-7858r364208_chk

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

Fix: F-7858r364209_fix

From the vSphere Web Client select the ESXi Host and go to Configure >> System >> Advanced System Settings. Click Edit and 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-207604 - SV-207604r388482_rule

RMF Control

CM-6

Severity

L

CCI

CCI-000366

Version

ESXI-65-000003

Vuln IDs

V-207604
V-93953

Rule IDs

SV-207604r388482_rule
SV-104039

In vSphere you can add users to the Exception Users list from the vSphere Web Client. These users do not lose their permissions when the host enters lockdown mode. Usually you may want to add 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 your environment. Users who do not require special permissions should not be exempted from lockdown mode.

Checks: C-7859r364211_chk

From the vSphere Web Client select the ESXi Host and go to Configure >> System >> 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. For environments that do not use vCenter server to manage ESXi, this is not applicable.

Fix: F-7859r364212_fix

From the vSphere Web Client select the ESXi Host and go to Configure >> System >> Security Profile. Under lockdown mode click Edit and remove unnecessary users to the exceptions list.

b

Remote logging for ESXi hosts must be configured.

AC-17 - Medium - CCI-000067 - V-207605 - SV-207605r378607_rule

RMF Control

AC-17

Severity

M

CCI

CCI-000067

Version

ESXI-65-000004

Vuln IDs

V-207605
V-93955

Rule IDs

SV-207605r378607_rule
SV-104041

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.

Checks: C-7860r364214_chk

From the vSphere Web Client select the ESXi Host and go to Configure >> System >> 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-7860r364215_fix

From the vSphere Web Client select the ESXi Host and go to Configure >> System >> Advanced System Settings. Click Edit and 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-207606 - SV-207606r378517_rule

RMF Control

AC-7

Severity

M

CCI

CCI-000044

Version

ESXI-65-000005

Vuln IDs

V-207606
V-93957

Rule IDs

SV-207606r378517_rule
SV-104043

By limiting the number of failed login attempts, the risk of unauthorized access via user password guessing, otherwise known as brute-forcing, is reduced. Limits are imposed by locking the account.

Checks: C-7861r364217_chk

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

Fix: F-7861r364218_fix

From the vSphere Web Client select the ESXi Host and go to Configure >> System >> Advanced System Settings. Click Edit and 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-207607 - SV-207607r379606_rule

RMF Control

AC-7

Severity

M

CCI

CCI-002238

Version

ESXI-65-000006

Vuln IDs

V-207607
V-93959

Rule IDs

SV-207607r379606_rule
SV-104045

By limiting the number of failed login attempts, the risk of unauthorized access via user password guessing, otherwise known as brute-forcing, is reduced. Limits are imposed by locking the account.

Checks: C-7862r364220_chk

From the vSphere Web Client select the ESXi Host and go to Configure >> System >> 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 and verify it is set to 900. If the Security.AccountUnlockTime is set to a value other than 900, this is a finding.

Fix: F-7862r364221_fix

From the vSphere Web 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 commands: 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.

AC-8 - Medium - CCI-000048 - V-207608 - SV-207608r378520_rule

RMF Control

AC-8

Severity

M

CCI

CCI-000048

Version

ESXI-65-000007

Vuln IDs

V-207608
V-93961

Rule IDs

SV-207608r378520_rule
SV-104047

Failure to display the DoD logon banner prior to a log in attempt will negate legal proceedings resulting from unauthorized access to system resources.

Checks: C-7863r364223_chk

From the vSphere Web Client select the ESXi Host and go to Configure >> System >> 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 login 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 & 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-7863r364224_fix

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

b

The ESXi host must display the Standard Mandatory DoD Notice and Consent Banner before granting access to the system.

AC-8 - Medium - CCI-000048 - V-207609 - SV-207609r378520_rule

RMF Control

AC-8

Severity

M

CCI

CCI-000048

Version

ESXI-65-000008

Vuln IDs

V-207609
V-93963

Rule IDs

SV-207609r378520_rule
SV-104049

Failure to display the DoD logon banner prior to a log in attempt will negate legal proceedings resulting from unauthorized access to system resources.

Checks: C-7864r364226_chk

From the vSphere Web Client select the ESXi Host and go to Configure >> System >> Advanced System Settings. Select the Config.Etc.issue value and verify it is set to 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-7864r364227_fix

From the vSphere Web Client select the ESXi Host and go to Configure >> System >> Advanced System Settings. Click Edit and 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 Department of Defense (DoD) login banner.

AC-8 - Medium - CCI-000048 - V-207610 - SV-207610r378520_rule

RMF Control

AC-8

Severity

M

CCI

CCI-000048

Version

ESXI-65-000009

Vuln IDs

V-207610
V-93965

Rule IDs

SV-207610r378520_rule
SV-104051

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-7865r364229_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-7865r364230_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-207611 - SV-207611r766919_rule

RMF Control

AC-17

Severity

M

CCI

CCI-000068

Version

ESXI-65-000010

Vuln IDs

V-207611
V-93967

Rule IDs

SV-207611r766919_rule
SV-104053

Approved algorithms should impart some level of confidence in their implementation. Limit the ciphers to those algorithms which are FIPS-approved. Counter (CTR) mode is also preferred over cipher-block chaining (CBC) mode. Note: This does not imply FIPS 140-2 validation.

Checks: C-7866r766917_chk

Only FIPS-approved ciphers should be used. 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 "^Ciphers" /etc/ssh/sshd_config If there is no output or the output is not exactly "Ciphers aes256-ctr,aes192-ctr,aes128-ctr", this is a finding.

Fix: F-7866r766918_fix

Limit the ciphers to those algorithms which are FIPS-approved. Counter (CTR) mode is also preferred over cipher-block chaining (CBC) mode. 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": Ciphers aes256-ctr,aes192-ctr,aes128-ctr

c

The ESXi host SSH daemon must be configured to use only the SSHv2 protocol.

AC-17 - High - CCI-000068 - V-207612 - SV-207612r378610_rule

RMF Control

AC-17

Severity

H

CCI

CCI-000068

Version

ESXI-65-000011

Vuln IDs

V-207612
V-93969

Rule IDs

SV-207612r378610_rule
SV-104055

SSH protocol version 1 suffers from design flaws that result in security vulnerabilities and should not be used. Only SSH protocol version 2 connections should be permitted.

Checks: C-7867r364235_chk

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

Fix: F-7867r364236_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": Protocol 2

b

The ESXi host SSH daemon must ignore .rhosts files.

IA-2 - Medium - CCI-000767 - V-207613 - SV-207613r378856_rule

RMF Control

IA-2

Severity

M

CCI

CCI-000767

Version

ESXI-65-000012

Vuln IDs

V-207613
V-93971

Rule IDs

SV-207613r378856_rule
SV-104057

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-7868r364238_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-7868r364239_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-207614 - SV-207614r388482_rule

RMF Control

CM-6

Severity

M

CCI

CCI-000366

Version

ESXI-65-000013

Vuln IDs

V-207614
V-93973

Rule IDs

SV-207614r388482_rule
SV-104059

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-7869r364241_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-7869r364242_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-207615 - SV-207615r388482_rule

RMF Control

CM-6

Severity

L

CCI

CCI-000366

Version

ESXI-65-000014

Vuln IDs

V-207615
V-93975

Rule IDs

SV-207615r388482_rule
SV-104061

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-7870r364244_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-7870r364245_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-207616 - SV-207616r388482_rule

RMF Control

CM-6

Severity

H

CCI

CCI-000366

Version

ESXI-65-000015

Vuln IDs

V-207616
V-93977

Rule IDs

SV-207616r388482_rule
SV-104063

Configuring this setting for the SSH daemon provides additional assurance that remote login via SSH will require a password, even in the event of misconfiguration elsewhere.

Checks: C-7871r364247_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-7871r364248_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-207617 - SV-207617r388482_rule

RMF Control

CM-6

Severity

M

CCI

CCI-000366

Version

ESXI-65-000016

Vuln IDs

V-207617
V-93979

Rule IDs

SV-207617r388482_rule
SV-104065

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-7872r364250_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-7872r364251_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

b

The ESXi host SSH daemon must be configured to only use Message Authentication Codes (MACs) employing FIPS 140-2 approved cryptographic hash algorithms.

CM-6 - Medium - CCI-000366 - V-207618 - SV-207618r388482_rule

RMF Control

CM-6

Severity

M

CCI

CCI-000366

Version

ESXI-65-000017

Vuln IDs

V-207618
V-93981

Rule IDs

SV-207618r388482_rule
SV-104067

DoD information systems are required to use FIPS 140-2 approved cryptographic hash functions.

Checks: C-7873r364253_chk

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

Fix: F-7873r364254_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": MACs hmac-sha1,hmac-sha2-256,hmac-sha2-512

a

The ESXi host SSH daemon must not permit GSSAPI authentication.

CM-6 - Low - CCI-000366 - V-207619 - SV-207619r388482_rule

RMF Control

CM-6

Severity

L

CCI

CCI-000366

Version

ESXI-65-000018

Vuln IDs

V-207619
V-93983

Rule IDs

SV-207619r388482_rule
SV-104069

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-7874r364256_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-7874r364257_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-207620 - SV-207620r388482_rule

RMF Control

CM-6

Severity

L

CCI

CCI-000366

Version

ESXI-65-000019

Vuln IDs

V-207620
V-93985

Rule IDs

SV-207620r388482_rule
SV-104071

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-7875r364259_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-7875r364260_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-207621 - SV-207621r388482_rule

RMF Control

CM-6

Severity

M

CCI

CCI-000366

Version

ESXI-65-000020

Vuln IDs

V-207621
V-93987

Rule IDs

SV-207621r388482_rule
SV-104073

If other users have access to modify user-specific SSH configuration files, they may be able to log into the system as another user.

Checks: C-7876r364262_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-7876r364263_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-207622 - SV-207622r388482_rule

RMF Control

CM-6

Severity

M

CCI

CCI-000366

Version

ESXI-65-000021

Vuln IDs

V-207622
V-93989

Rule IDs

SV-207622r388482_rule
SV-104075

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-7877r364265_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-7877r364266_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-207623 - SV-207623r388482_rule

RMF Control

CM-6

Severity

L

CCI

CCI-000366

Version

ESXI-65-000022

Vuln IDs

V-207623
V-93991

Rule IDs

SV-207623r388482_rule
SV-104077

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 ACLs. Gateway ports allow remote forwarded ports to bind to non-loopback addresses on the server.

Checks: C-7878r364268_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-7878r364269_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-207624 - SV-207624r388482_rule

RMF Control

CM-6

Severity

M

CCI

CCI-000366

Version

ESXI-65-000023

Vuln IDs

V-207624
V-93993

Rule IDs

SV-207624r388482_rule
SV-104079

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-7879r364271_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-7879r364272_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-207625 - SV-207625r388482_rule

RMF Control

CM-6

Severity

M

CCI

CCI-000366

Version

ESXI-65-000024

Vuln IDs

V-207625
V-93995

Rule IDs

SV-207625r388482_rule
SV-104081

Environment variables can be used to change the behavior of remote sessions and should be limited. Locale environment variables that specify the language, character set, and other features modifying the operation of software to match the user's preferences.

Checks: C-7880r364274_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-7880r364275_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-207626 - SV-207626r388482_rule

RMF Control

CM-6

Severity

M

CCI

CCI-000366

Version

ESXI-65-000025

Vuln IDs

V-207626
V-93997

Rule IDs

SV-207626r388482_rule
SV-104083

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 ACLs.

Checks: C-7881r364277_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-7881r364278_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-207627 - SV-207627r388482_rule

RMF Control

CM-6

Severity

L

CCI

CCI-000366

Version

ESXI-65-000026

Vuln IDs

V-207627
V-93999

Rule IDs

SV-207627r388482_rule
SV-104085

This ensures a user login will be terminated as soon as the "ClientAliveCountMax" is reached.

Checks: C-7882r364280_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-7882r364281_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 hostSSH daemon must set a timeout interval on idle sessions.

CM-6 - Low - CCI-000366 - V-207628 - SV-207628r388482_rule

RMF Control

CM-6

Severity

L

CCI

CCI-000366

Version

ESXI-65-000027

Vuln IDs

V-207628
V-94001

Rule IDs

SV-207628r388482_rule
SV-104087

Causing idle users to be automatically logged out guards against compromises one system leading trivially to compromises on another.

Checks: C-7883r364283_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-7883r364284_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-207629 - SV-207629r388482_rule

RMF Control

CM-6

Severity

M

CCI

CCI-000366

Version

ESXI-65-000028

Vuln IDs

V-207629
V-94003

Rule IDs

SV-207629r388482_rule
SV-104089

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-7884r364286_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-7884r364287_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-207630 - SV-207630r388482_rule

RMF Control

CM-6

Severity

M

CCI

CCI-000366

Version

ESXI-65-000029

Vuln IDs

V-207630
V-94005

Rule IDs

SV-207630r388482_rule
SV-104091

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 users 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 login with authorized keys will have the same restrictions as username/password.

Checks: C-7885r364289_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-7885r364290_fix

From an SSH session connected to the ESXi host, or from the ESXi shell, zero 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-207631 - SV-207631r378616_rule

RMF Control

AU-3

Severity

L

CCI

CCI-000130

Version

ESXI-65-000030

Vuln IDs

V-207631
V-94007

Rule IDs

SV-207631r378616_rule
SV-104093

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.

Checks: C-7886r364292_chk

From the vSphere Web Client select the ESXi Host and go to Configure >> System >> 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-7886r364293_fix

From the vSphere Web Client select the ESXi Host and go to Configure >> System >> Advanced System Settings. Click Edit and 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 upper-case character be used.

IA-5 - Medium - CCI-000192 - V-207632 - SV-207632r378739_rule

RMF Control

IA-5

Severity

M

CCI

CCI-000192

Version

ESXI-65-000031

Vuln IDs

V-207632
V-94009

Rule IDs

SV-207632r378739_rule
SV-104095

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.

Checks: C-7887r364295_chk

From the vSphere Web Client select the ESXi Host and go to Configure >> System >> 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-7887r364296_fix

From the vSphere Web Client select the ESXi Host and go to Configure >> System >> Advanced System Settings. Click Edit and 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-207633 - SV-207633r378763_rule

RMF Control

IA-5

Severity

M

CCI

CCI-000200

Version

ESXI-65-000032

Vuln IDs

V-207633
V-94011

Rule IDs

SV-207633r378763_rule
SV-104097

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-7888r364298_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 the remember setting is not set or is not "remember=5", this is a finding.

Fix: F-7888r364299_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 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-207634 - SV-207634r388482_rule

RMF Control

CM-6

Severity

M

CCI

CCI-000366

Version

ESXI-65-000033

Vuln IDs

V-207634
V-94013

Rule IDs

SV-207634r388482_rule
SV-104099

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-7889r364301_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-7889r364302_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-207635 - SV-207635r378841_rule

RMF Control

CM-7

Severity

M

CCI

CCI-000381

Version

ESXI-65-000034

Vuln IDs

V-207635
V-94015

Rule IDs

SV-207635r378841_rule
SV-104101

The Managed Object Browser (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 obtain information about a host being targeted for unauthorized access. By default this is disabled for ESXi in version 6.

Checks: C-7890r364304_chk

From the vSphere Web Client select the ESXi Host and go to Configure >> System >> 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-7890r364305_fix

From the vSphere Web 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 non-essential capabilities by disabling SSH.

CM-7 - Medium - CCI-000381 - V-207636 - SV-207636r378841_rule

RMF Control

CM-7

Severity

M

CCI

CCI-000381

Version

ESXI-65-000035

Vuln IDs

V-207636
V-94017

Rule IDs

SV-207636r378841_rule
SV-104103

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 at all other times.

Checks: C-7891r364307_chk

From the vSphere Web Client select the ESXi Host and go to Configure >> System >> Security Profile. Under Services select Edit and 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-7891r364308_fix

From the vSphere Web Client select the ESXi Host and go to Configure >> System >> Security Profile. Under Services select Edit then select the SSH service and click the Stop button to stop the service. Use the pull-down menu to change the 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-207637 - SV-207637r378841_rule

RMF Control

CM-7

Severity

M

CCI

CCI-000381

Version

ESXI-65-000036

Vuln IDs

V-207637
V-94019

Rule IDs

SV-207637r378841_rule
SV-104105

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-7892r364310_chk

From the vSphere Web Client select the ESXi Host and go to Configure >> System >> Security Profile. Under Services select Edit and 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-7892r364311_fix

From the vSphere Web Client select the ESXi Host and go to Configure >> System >> Security Profile. Under Services select Edit then select the ESXi Shell service and click the Stop button to stop the service. Use the pull-down menu to change the 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-207638 - SV-207638r378847_rule

RMF Control

IA-2

Severity

L

CCI

CCI-000764

Version

ESXI-65-000037

Vuln IDs

V-207638
V-94021

Rule IDs

SV-207638r378847_rule
SV-104107

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.

Checks: C-7893r364313_chk

From the vSphere Web Client select the ESXi Host and go to Configure >> System >> 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-7893r364314_fix

From the vSphere Web 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 and 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

The ESXi host must use the vSphere Authentication Proxy to protect passwords when adding ESXi hosts to Active Directory.

IA-2 - Medium - CCI-000764 - V-207639 - SV-207639r378847_rule

RMF Control

IA-2

Severity

M

CCI

CCI-000764

Version

ESXI-65-000038

Vuln IDs

V-207639
V-94023

Rule IDs

SV-207639r378847_rule
SV-104109

If you configure your host to join an Active Directory domain using Host Profiles the Active Directory credentials are saved in the host profile and are transmitted over the network. To avoid having to save Active Directory credentials in the Host Profile and to avoid transmitting Active Directory credentials over the network use the vSphere Authentication Proxy.

Checks: C-7894r364316_chk

From the vSphere Web 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. 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 vCenter run the following command: Get-VMHost | Select Name, ` @{N="HostProfile";E={$_ | Get-VMHostProfile}}, ` @{N="JoinADEnabled";E={($_ | Get-VmHostProfile).ExtensionData.Config.ApplyProfile.Authentication.ActiveDirectory.Enabled}}, ` @{N="JoinDomainMethod";E={(($_ | Get-VMHostProfile).ExtensionData.Config.ApplyProfile.Authentication.ActiveDirectory | Select -ExpandProperty Policy | Where {$_.Id -eq "JoinDomainMethodPolicy"}).Policyoption.Id}} Verify if JoinADEnabled is True then JoinDomainMethod should be "FixedCAMConfigOption". If you are not using Host Profiles to join active directory, this is not a finding.

Fix: F-7894r364317_fix

From the vSphere Web 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-207640 - SV-207640r378847_rule

RMF Control

IA-2

Severity

L

CCI

CCI-000764

Version

ESXI-65-000039

Vuln IDs

V-207640
V-94025

Rule IDs

SV-207640r378847_rule
SV-104111

When adding ESXi hosts to Active Directory, if the group "ESX Admins" exists, all user/group accounts assigned to the group will have full administrative access to the host. Discretion should be used when managing membership to the "ESX Admins" group.

Checks: C-7895r364319_chk

From the vSphere Web Client select the ESXi Host and go to Configuration >> System >> 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 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 "Config.HostAgent.plugins.hostsvc.esxAdminsGroup" keyword is set to "ESX Admins", this is a finding.

Fix: F-7895r364320_fix

From the vSphere Web Client select the ESXi Host and go to Configuration >> System >> Advanced System Settings. Click Edit and select the Config.HostAgent.plugins.hostsvc.esxAdminsGroup value and configure it to an 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 access to privileged accounts.

IA-2 - Low - CCI-000767 - V-207641 - SV-207641r378856_rule

RMF Control

IA-2

Severity

L

CCI

CCI-000767

Version

ESXI-65-000040

Vuln IDs

V-207641
V-94027

Rule IDs

SV-207641r378856_rule
SV-104113

To assure accountability and prevent unauthenticated access, privileged users must utilize multifactor authentication to prevent potential misuse and compromise of the system.

Checks: C-7896r364322_chk

From the vSphere Web Client select the ESXi Host and go to Configure >> System >> Authentication Services and view the Smart Card Authentication status. If "Enable Smart Card Authentication" is checked, the system requires smart cards to authentication to an Active Directory Domain. For systems that have no local user accounts, other than root and/or vpxuser, this is not applicable. For environments that do not use vCenter server to manage ESXi, this is not applicable. For systems that do not use smart cards with Active Directory and do have local user accounts, other than root and/or vpxuser, this is a finding.

Fix: F-7896r364323_fix

The following are pre-requisites to configuration 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. -Trusted certificates for root and intermediary certificate authorities. From the vSphere Web Client select the ESXi Host and go to Configure >> System >> Authentication Services and click Edit and check "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 sessions after 10 minutes.

SC-10 - Medium - CCI-001133 - V-207642 - SV-207642r378994_rule

RMF Control

SC-10

Severity

M

CCI

CCI-001133

Version

ESXI-65-000041

Vuln IDs

V-207642
V-94029

Rule IDs

SV-207642r378994_rule
SV-104115

If a user forgets to log out of their SSH session, the idle connection will remains open indefinitely, increasing the potential for someone to gain privileged access to the host. The ESXiShellInteractiveTimeOut allows you to automatically terminate idle shell sessions.

Checks: C-7897r364325_chk

From the vSphere Web Client select the ESXi Host and go to Configure >> System >> Advanced System Settings. Select the UserVars.ESXiShellInteractiveTimeOut 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.ESXiShellInteractiveTimeOut If the UserVars.ESXiShellInteractiveTimeOut setting is not set to 600, this is a finding.

Fix: F-7897r364326_fix

From the vSphere Web Client select the ESXi Host and go to Configure >> System >> Advanced System Settings. Click Edit and select the UserVars.ESXiShellInteractiveTimeOut 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.ESXiShellInteractiveTimeOut | Set-AdvancedSetting -Value 600

b

The ESXi host must terminate shell services after 10 minutes.

SC-10 - Medium - CCI-001133 - V-207643 - SV-207643r378994_rule

RMF Control

SC-10

Severity

M

CCI

CCI-001133

Version

ESXI-65-000042

Vuln IDs

V-207643
V-94031

Rule IDs

SV-207643r378994_rule
SV-104117

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 automatically be terminated.

Checks: C-7898r364328_chk

From the vSphere Web Client select the ESXi Host and go to Configure >> System >> 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-7898r364329_fix

From the vSphere Web Client select the ESXi Host and go to Configure >> System >> Advanced System Settings. Click Edit and 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 logout of the console UI after 10 minutes.

SC-10 - Medium - CCI-001133 - V-207644 - SV-207644r378994_rule

RMF Control

SC-10

Severity

M

CCI

CCI-001133

Version

ESXI-65-000043

Vuln IDs

V-207644
V-94033

Rule IDs

SV-207644r378994_rule
SV-104119

When the Direct console user interface (DCUI) is enabled and logged in it should be automatically logged out if left logged in to avoid unauthorized privilege gains. The DcuiTimeOut defines a window of time after which the DCUI will be logged out.

Checks: C-7899r364331_chk

From the vSphere Web Client select the ESXi Host and go to Configure >> System >> Advanced System Settings. Select the UserVars.DcuiTimeOut 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.DcuiTimeOut If the UserVars.DcuiTimeOut setting is not set to 600, this is a finding.

Fix: F-7899r364332_fix

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

a

The ESXi host must enable kernel core dumps.

SC-24 - Low - CCI-001665 - V-207645 - SV-207645r379318_rule

RMF Control

SC-24

Severity

L

CCI

CCI-001665

Version

ESXI-65-000044

Vuln IDs

V-207645
V-94035

Rule IDs

SV-207645r379318_rule
SV-104121

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-7900r364334_chk

From the vSphere Web Client select the ESXi Host and right click. If the "Add Diagnostic Partition" option is greyed out then core dumps are configured. or From a PowerCLI command prompt while connected to the ESXi host run the following commands: $esxcli = Get-EsxCli $esxcli.system.coredump.partition.get() $esxcli.system.coredump.network.get() The first command prepares for the other two. The second command shows whether there is an active core dump partition 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 no active core dump partition or the network core dump collector is not configured and enabled, this is a finding.

Fix: F-7900r364335_fix

From the vSphere Web Client select the ESXi Host and right click. Select the "Add Diagnostic Partition" option 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 #View available partitions to configure $esxcli.system.coredump.partition.list() $esxcli.system.coredump.partition.set($null,"PartitionName",$null,$null) To configure a core dump collector: $esxcli = Get-EsxCli $esxcli.system.coredump.network.set($null,"vmkernel port to use",$null,"CollectorIP","CollectorPort") $esxcli.system.coredump.network.set($true)

b

The ESXi host must enable a persistent log location for all locally stored logs.

AU-4 - Medium - CCI-001849 - V-207646 - SV-207646r379690_rule

RMF Control

AU-4

Severity

M

CCI

CCI-001849

Version

ESXI-65-000045

Vuln IDs

V-207646
V-94037

Rule IDs

SV-207646r379690_rule
SV-104123

ESXi can be configured to store log files on an in-memory file system. This occurs when the host's "/scratch" directory is linked to "/tmp/scratch". When this is done only a single day's worth of logs are stored at any time. In addition log files will be reinitialized upon each reboot. This presents a security risk as user activity logged on the host is only stored temporarily and will not persistent 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-7901r364337_chk

From the vSphere Web Client select the ESXi Host and go to Configure >> System >> 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: Get-VMHost | Get-AdvancedSetting -Name Syslog.global.logDir or $esxcli = Get-EsxCli $esxcli.system.syslog.config.get() | Select LocalLogOutput,LocalLogOutputIsPersistent If the Syslog.global.logDir or LocalLogOutput value is not on persistent storage, this is a finding. If the LocalLogOutputIsPersistent value is not true, this is a finding.

Fix: F-7901r364338_fix

From the vSphere Web 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-207647 - SV-207647r379732_rule

RMF Control

AU-8

Severity

M

CCI

CCI-001891

Version

ESXI-65-000046

Vuln IDs

V-207647
V-94039

Rule IDs

SV-207647r379732_rule
SV-104125

To assure the accuracy of the system clock, it must be synchronized with an authoritative time source within DoD. Many system functions, including time-based login 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.

Checks: C-7902r364340_chk

From the vSphere Web Client select the ESXi Host and go to Configure >> System >> 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 and the service is not configured to start and stop with the host and is running, this is a finding.

Fix: F-7902r364341_fix

From the vSphere Web 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 VIB Acceptance Levels must be verified.

CM-5 - High - CCI-001749 - V-207648 - SV-207648r379825_rule

RMF Control

CM-5

Severity

H

CCI

CCI-001749

Version

ESXI-65-000047

Vuln IDs

V-207648
V-94041

Rule IDs

SV-207648r379825_rule
SV-104127

Verify the ESXi Image Profile to only allow signed VIBs. An unsigned VIB represents untested code installed on an ESXi host. The ESXi Image profile supports four acceptance levels: (1) VMwareCertified - VIBs created, tested and signed by VMware (2) VMwareAccepted - VIBs created by a VMware partner but tested and signed by VMware, (3) PartnerSupported - VIBs created, tested and signed by a certified VMware partner (4) CommunitySupported - VIBs that have not been tested by VMware or a VMware partner. Community Supported VIBs are not supported and do not have a digital signature. To protect the security and integrity of your ESXi hosts do not allow unsigned (CommunitySupported) VIBs to be installed on your hosts.

Checks: C-7903r364343_chk

From the vSphere Web Client select the ESXi Host and go to Configure >> System >> 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 $esxcli.software.acceptance.get() If the acceptance level is CommunitySupported, this is a finding.

Fix: F-7903r364344_fix

From the vSphere Web Client select the ESXi Host and go to Configure >> System >> Security Profile. Under "Host Image Profile Acceptance Level" click Edit… and use 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 $esxcli.software.acceptance.Set("PartnerSupported") Note: VMwareCertified or VMwareAccepted may be substituted for PartnerSupported, depending upon local requirements.

b

The ESXi host must protect the confidentiality and integrity of transmitted information by isolating vMotion traffic.

SC-8 - Medium - CCI-002418 - V-207649 - SV-207649r380176_rule

RMF Control

SC-8

Severity

M

CCI

CCI-002418

Version

ESXI-65-000048

Vuln IDs

V-207649
V-94043

Rule IDs

SV-207649r380176_rule
SV-104129

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-7904r364346_chk

The vMotion VMKernel port group should in a dedicated VLAN that can be on a common standard or distributed virtual switch as long as the vMotion VLAN is not shared by any other function and it not routed to anything but ESXi hosts. The check for this will be unique per environment. From the vSphere Client select the ESXi host and go to Configuration > Networking and review the VLAN associated with the vMotion VMkernel(s) and verify they are dedicated for that purpose and are logically separated from other functions. If long distance or cross vCenter vMotion is used the vMotion network can be routable but must be accessible to only the intended ESXi hosts. If the vMotion port group is not on an isolated VLAN and/or is routable to systems other than ESXi hosts, this is a finding. For environments that do not use vCenter server to manage ESXi, this is not applicable.

Fix: F-7904r364347_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 Web 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 IP based management traffic.

SC-8 - Medium - CCI-002418 - V-207650 - SV-207650r380176_rule

RMF Control

SC-8

Severity

M

CCI

CCI-002418

Version

ESXI-65-000050

Vuln IDs

V-207650
V-94047

Rule IDs

SV-207650r380176_rule
SV-104133

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-7905r364349_chk

IP-Based storage (iSCSI, NFS, vSAN) VMkernel port groups must be in a dedicated VLAN that can be on a common 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 Web Client select the ESXi Host and go to Configure >> Networking >> VMkernel adapters and review the VLANs associated with any IP-Based storage VMkernels and verify they are dedicated for that purpose and are logically separated from other functions. If any IP-Based storage networks are not isolated from other traffic types, this is a finding. If IP-based storage is not used, this is not applicable.

Fix: F-7905r364350_fix

Configuration of an IP-Based VMkernel will be unique to each environment but for example to modify the IP address and VLAN information to the correct network on a standard switch for an iSCSI VMkernel do the following: From the vSphere Web Client select the ESXi host and go to Configure >> Networking >> VMkernel adapters. Select the Storage VMkernel (for vSAN only) 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 >> Configure >> Networking >> Virtual switches. Select the Storage 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 utilizing different TCP/IP stacks where possible.

SC-8 - Low - CCI-002418 - V-207651 - SV-207651r380176_rule

RMF Control

SC-8

Severity

L

CCI

CCI-002418

Version

ESXI-65-000052

Vuln IDs

V-207651
V-94051

Rule IDs

SV-207651r380176_rule
SV-104137

There are three different TCP/IP stacks by default available on ESXi now which are Default, Provisioning, and vMotion. To better protect and isolate sensitive network traffic within ESXi admins must configure each of these stacks. Additional custom TCP/IP stacks can be created if desired.

Checks: C-7906r364352_chk

From the vSphere Web Client select the ESXi Host and go to Configure >> Networking >> 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 utilizing their own TCP/IP stack, this is a finding.

Fix: F-7906r364353_fix

From the vSphere Web Client select the ESXi Host and go to Configure >> Networking >> TCP/IP configuration >> Select a TCP/IP stack >> 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-207652 - SV-207652r388482_rule

RMF Control

CM-6

Severity

M

CCI

CCI-000366

Version

ESXI-65-000053

Vuln IDs

V-207652
V-94053

Rule IDs

SV-207652r388482_rule
SV-104139

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-7907r364355_chk

From a PowerCLI command prompt while connected to the ESXi host run the following command: Get-VMHostSnmp | Select * or From a 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-7907r364356_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-207653 - SV-207653r388482_rule

RMF Control

CM-6

Severity

L

CCI

CCI-000366

Version

ESXI-65-000054

Vuln IDs

V-207653
V-94055

Rule IDs

SV-207653r388482_rule
SV-104141

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-7908r364358_chk

From the vSphere Web Client select the ESXi Host and go to Configure >> Storage >> Storage Adapters >> Select the iSCSI adapter >> Properties >> Authentication method and 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-7908r364359_fix

From the vSphere Web 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-207654 - SV-207654r388482_rule

RMF Control

CM-6

Severity

L

CCI

CCI-000366

Version

ESXI-65-000055

Vuln IDs

V-207654
V-94057

Rule IDs

SV-207654r388482_rule
SV-104143

Published academic papers have demonstrated that by forcing a flush and reload of cache memory, it is possible to measure memory timings to try and 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. Even though 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 utilized within individual VMs).

Checks: C-7909r364361_chk

From the vSphere Web Client select the ESXi Host and go to Configure >> System >> 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-7909r364362_fix

From the vSphere Web Client select the ESXi Host and go to Configure >> System >> Advanced System Settings. Click Edit and 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-207655 - SV-207655r388482_rule

RMF Control

CM-6

Severity

M

CCI

CCI-000366

Version

ESXI-65-000056

Vuln IDs

V-207655
V-94059

Rule IDs

SV-207655r388482_rule
SV-104145

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-7910r364364_chk

From the vSphere Web Client select the ESXi Host and go to Configure >> System >> Security Profile. Under the Firewall section click Edit and 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-7910r364365_fix

From the vSphere Web Client select the ESXi Host and go to Configure >> System >> Security Profile. Under the Firewall section click Edit and 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. or From a PowerCLI command prompt while connected to the ESXi host run the following command: $esxcli = Get-EsxCli #This disables the allow all rule for the target service $esxcli.network.firewall.ruleset.set($false,$true,"sshServer") $esxcli.network.firewall.ruleset.allowedip.add("192.168.0.0/24","sshServer") 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-207656 - SV-207656r388482_rule

RMF Control

CM-6

Severity

M

CCI

CCI-000366

Version

ESXI-65-000057

Vuln IDs

V-207656
V-94061

Rule IDs

SV-207656r388482_rule
SV-104147

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-7911r364367_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-7911r364368_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-207657 - SV-207657r388482_rule

RMF Control

CM-6

Severity

L

CCI

CCI-000366

Version

ESXI-65-000058

Vuln IDs

V-207657
V-94063

Rule IDs

SV-207657r388482_rule
SV-104149

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 VPN which 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-7912r364370_chk

From the vSphere Web Client select the ESXi Host and go to Configure >> System >> 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-7912r364371_fix

From the vSphere Web Client select the ESXi Host and go to Configure >> System >> Advanced System Settings. Click Edit and 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-207658 - SV-207658r388482_rule

RMF Control

CM-6

Severity

M

CCI

CCI-000366

Version

ESXI-65-000059

Vuln IDs

V-207658
V-94065

Rule IDs

SV-207658r388482_rule
SV-104151

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. You can override switch level settings at the Portgroup level.

Checks: C-7913r364373_chk

From the vSphere Web Client go to Configure >> Networking >> 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, this is a finding.

Fix: F-7913r364374_fix

From the vSphere Web Client go to Configure >> Networking >> Virtual Switches. For each virtual switch and port group click Edit settings 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-207659 - SV-207659r388482_rule

RMF Control

CM-6

Severity

H

CCI

CCI-000366

Version

ESXI-65-000060

Vuln IDs

V-207659
V-94067

Rule IDs

SV-207659r388482_rule
SV-104153

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. This will also affect how a layer 2 bridge will operate. This will also affect applications that require a specific MAC address for licensing. Reject MAC Changes can be set at the vSwitch and/or the Portgroup level. You can override switch level settings at the Portgroup level.

Checks: C-7914r364376_chk

From the vSphere Web Client go to Configure >> Networking >> 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, this is a finding.

Fix: F-7914r364377_fix

From the vSphere Web Client go to Configure >> Networking >> Virtual Switches. For each virtual switch and port group click Edit settings 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-207660 - SV-207660r388482_rule

RMF Control

CM-6

Severity

M

CCI

CCI-000366

Version

ESXI-65-000061

Vuln IDs

V-207660
V-94069

Rule IDs

SV-207660r388482_rule
SV-104155

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. Promiscous mode can be set at the vSwitch and/or the Portgroup level. You can override switch level settings at the Portgroup level.

Checks: C-7915r364379_chk

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

Fix: F-7915r364380_fix

From the vSphere Web Client go to Configure >> Networking >> Virtual Switches. For each virtual switch and port group click Edit settings 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-207661 - SV-207661r388482_rule

RMF Control

CM-6

Severity

M

CCI

CCI-000366

Version

ESXI-65-000062

Vuln IDs

V-207661
V-94071

Rule IDs

SV-207661r388482_rule
SV-104157

If you are not using products that make use of 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 thereby potentially providing access to the network of other VMs on the host. If you are using a product that makes use of this API then verify that the host has been configured correctly. If you are not using such a product make sure the setting is blank.

Checks: C-7916r364382_chk

From the vSphere Web Client select the ESXi Host and go to Configure >> System >> 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-7916r364383_fix

From the vSphere Web Client select the ESXi Host and go to Configure >> System >> Advanced System Settings. Click Edit and 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-207662 - SV-207662r388482_rule

RMF Control

CM-6

Severity

M

CCI

CCI-000366

Version

ESXI-65-000063

Vuln IDs

V-207662
V-94073

Rule IDs

SV-207662r388482_rule
SV-104159

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 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-7917r364385_chk

From the vSphere Web Client select the ESXi Host and go to Configure >> Networking >> 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 ESXi hosts attached physical switch, this is a finding.

Fix: F-7917r364386_fix

From the vSphere Web Client select the ESXi Host and go to Configure >> Networking >> Virtual switches. Highlight a port group (where VLAN ID set to native VLAN ID) and click Edit settings. 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-207663 - SV-207663r388482_rule

RMF Control

CM-6

Severity

M

CCI

CCI-000366

Version

ESXI-65-000064

Vuln IDs

V-207663
V-94075

Rule IDs

SV-207663r388482_rule
SV-104161

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-7918r364388_chk

From the vSphere Web Client select the ESXi Host and go to Configure >> Networking >> 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-7918r364389_fix

From the vSphere Web Client select the ESXi Host and go to Configure >> Networking >> Virtual switches. Highlight a port group (where VLAN ID set to 4095) and click Edit settings. Change the VLAN ID to not be 4095 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-207664 - SV-207664r388482_rule

RMF Control

CM-6

Severity

M

CCI

CCI-000366

Version

ESXI-65-000065

Vuln IDs

V-207664
V-94077

Rule IDs

SV-207664r388482_rule
SV-104163

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 with the documentation for your specific switch. Using a reserved VLAN might result in a denial of service on the network.

Checks: C-7919r364391_chk

From the vSphere Web Client select the ESXi Host and go to Configure >> Networking >> 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-7919r364392_fix

From the vSphere Web Client select the ESXi Host and go to Configure >> Networking >> Virtual switches. Highlight a port group (where VLAN ID set to 4095) and click Edit settings (pencil). Change the VLAN ID to not be a reserved VLAN ID and click OK. or From a PowerCLI command prompt while connected to the ESXi host run the following command: Get-VirtualPortGroup -Name "portgroup name" | Set-VirtualPortGroup -VLanId "New VLAN#"

b

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 VST mode.

CM-6 - Medium - CCI-000366 - V-207665 - SV-207665r388482_rule

RMF Control

CM-6

Severity

M

CCI

CCI-000366

Version

ESXI-65-000066

Vuln IDs

V-207665
V-94079

Rule IDs

SV-207665r388482_rule
SV-104165

In order 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-7920r364394_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. Virtual Switch Tagging (VST) mode does not support Dynamic Trunking Protocol (DTP), so the trunk must be static and unconditional. Inspect the documentation and verify that the documentation is correct and updated on 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-7920r364395_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 on 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-207666 - SV-207666r388482_rule

RMF Control

CM-6

Severity

L

CCI

CCI-000366

Version

ESXI-65-000067

Vuln IDs

V-207666
V-94081

Rule IDs

SV-207666r388482_rule
SV-104167

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-7921r364397_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 on 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-7921r364398_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-207667 - SV-207667r388482_rule

RMF Control

CM-6

Severity

M

CCI

CCI-000366

Version

ESXI-65-000068

Vuln IDs

V-207667
V-94083

Rule IDs

SV-207667r388482_rule
SV-104169

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, potentially enabling an administrator to either accidentally or maliciously connect a VM to an unauthorized VLAN.

Checks: C-7922r364400_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 on 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-7922r364401_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-207668 - SV-207668r388482_rule

RMF Control

CM-6

Severity

M

CCI

CCI-000366

Version

ESXI-65-000070

Vuln IDs

V-207668
V-94349

Rule IDs

SV-207668r388482_rule
SV-104303

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-7923r364403_chk

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. 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-7923r364404_fix

Create a role for the CIM account. From the Host Client, go to manage, then Security & Users. Select Roles then click Add Role. Provide a name for the new role then select Host >> Cim >> Ciminteraction and click Add. Add a CIM user account. From the Host Client, go to manage, then Security & Users. Select Users then click Add User. Provide a name, description, and password for the new user then 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 and select the CIM account from the drop down list and select the new CIM role from the drop down list and click Add User.

c

The ESXi host must verify the integrity of the installation media before installing ESXi.

CM-6 - High - CCI-000366 - V-207669 - SV-207669r388482_rule

RMF Control

CM-6

Severity

H

CCI

CCI-000366

Version

ESXI-65-000071

Vuln IDs

V-207669
V-94477

Rule IDs

SV-207669r388482_rule
SV-104307

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-7924r364406_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) directly below. # md5sum <filename>.iso # sha1sum <filename>.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-7924r364407_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-207670 - SV-207670r388482_rule

RMF Control

CM-6

Severity

H

CCI

CCI-000366

Version

ESXI-65-000072

Vuln IDs

V-207670
V-94479

Rule IDs

SV-207670r388482_rule
SV-104309

Installing software updates is a fundamental mitigation against the exploitation of publicly-known vulnerabilities.

Checks: C-7925r364409_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 > Update Manager tab and select scan to view all hosts compliance status. If vCenter Update Manager is not used a hosts compliance status must be manually determined by the build number. The following 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. https://www.vmware.com/support/policies/security_response

Fix: F-7925r364410_fix

If vCenter Update Manager is used on the network, hosts can be remediated from the vSphere Web Client. From the vSphere Web Client go to Hosts and Clusters >> Update Manager tab and select a non-compliant host and click the Remediate button. 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>

b

The ESXi host must enable Secure Boot.

CM-6 - Medium - CCI-000366 - V-207673 - SV-207673r388482_rule

RMF Control

CM-6

Severity

M

CCI

CCI-000366

Version

ESXI-65-000076

Vuln IDs

V-207673
V-94487

Rule IDs

SV-207673r388482_rule
SV-104317

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 it requires that all ESXi kernel modules, drivers, and VIBs be signed by VMware or a partner subordinate.

Checks: C-7928r364418_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-7928r364419_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 your 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-207674 - SV-207674r617349_rule

RMF Control

CM-6

Severity

M

CCI

CCI-000366

Version

ESXI-65-000078

Vuln IDs

V-207674
V-94489

Rule IDs

SV-207674r617349_rule
SV-104319

The default self-signed, VMCA issued host certificate must be replaced with a DoD-approved certificate. 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-7929r622444_chk

Temporarily enable SSH, connect to the ESXi host and run the following command: # openssl x509 -in /etc/vmware/ssl/rui.crt -text | grep Issuer If the issuer is not a DoD approved certificate authority, or other AO approved certificate authority, this is a finding.

Fix: F-7929r364422_fix

Obtain a DoD issued certificate and private key for the host following the below requirements: 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 your 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 go to vCenter Inventory Lists >> vCenter Servers >> Select your vCenter Server >> Manage >> Settings >> Advanced Settings. Find or create the vpxd.certmgmt.mode key and set its value to custom.

a

The ESXi host must require individuals to be authenticated with an individual authenticator prior to using a group authenticator by using Active Directory for local user authentication.

IA-2 - Low - CCI-000770 - V-207675 - SV-207675r378862_rule

RMF Control

IA-2

Severity

L

CCI

CCI-000770

Version

ESXI-65-100037

Vuln IDs

V-207675
V-94505

Rule IDs

SV-207675r378862_rule
SV-104335

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.

Checks: C-7930r364424_chk

For systems that do not use Active Directory and have no local user accounts, other than "root" and/or "vpxuser", this is not applicable. From the vSphere Client select the ESXi host and go to Configuration >> Authentication Services. Verify the "Directory Services Type" is set to "Active Directory". or From a PowerCLI command prompt while connected to the ESXi host run the following command: Get-VMHost | Get-VMHostAuthentication For systems that do not use Active Directory and do have local user accounts, other than "root" and/or "vpxuser"", this is a finding. If the "Directory Services Type" is not set to "Active Directory", this is a finding. If you are not using Host Profiles to join active directory, this is not a finding.

Fix: F-7930r364425_fix

From the vSphere Client select the ESXi host and go to Configuration >> Authentication Services. Click "Properties" and change the "Directory Service Type" to "Active Directory", enter the domain to join, check "Use vSphere Authentication Proxy" and enter the proxy server address then click "Join Domain". 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

The ESXi host must protect the confidentiality and integrity of transmitted information.

SC-8 - Medium - CCI-002418 - V-251043 - SV-251043r802909_rule

RMF Control

SC-8

Severity

M

CCI

CCI-002418

Version

ESXI-65-000049

Vuln IDs

V-251043

Rule IDs

SV-251043r802909_rule

Without protection of the transmitted information, confidentiality and integrity may be compromised as unprotected communications can be intercepted and either read or altered. This requirement applies to both internal and external networks and all types of VMM components from which information can be transmitted (e.g., guest VMs, servers, mobile devices, notebook computers, printers, copiers, scanners, and facsimile machines). Communication paths outside the physical protection of a controlled boundary are exposed to the possibility of interception and modification. Protecting the confidentiality and integrity of organizational information can be accomplished by physical means (e.g., employing physical distribution systems) or by logical means (e.g., employing cryptographic techniques). If physical means of protection are employed, then logical means (cryptography) do not have to be employed, and vice versa.

Checks: C-54478r802907_chk

From the vSphere Web Client, select the ESXi Host and go to Manage >> Networking >> VMkernel adapters. Review each VMkernel adapter that is defined and ensure it is enabled for only one type of management traffic. If any VMkernel is used for more than one type of management traffic, this is a finding.

Fix: F-54431r802908_fix

From the vSphere Web Client, select the ESXi Host and go to Configure >> Networking >> VMkernel adapters >> Select a VMkernel Adapter >> Click Edit settings >> Uncheck any additional services that have been enabled on the VMkernel adapter so that there is only one service left checked.

Added rules 1

Checks: C-7857r364205_chk

Fix: F-7857r364206_fix

Generate Mitigation Statement:

Checks: C-7858r364208_chk

Fix: F-7858r364209_fix

Generate Mitigation Statement:

Checks: C-7859r364211_chk

Fix: F-7859r364212_fix

Generate Mitigation Statement:

Checks: C-7860r364214_chk

Fix: F-7860r364215_fix

Generate Mitigation Statement:

Checks: C-7861r364217_chk

Fix: F-7861r364218_fix

Generate Mitigation Statement:

Checks: C-7862r364220_chk

Fix: F-7862r364221_fix

Generate Mitigation Statement:

Checks: C-7863r364223_chk

Fix: F-7863r364224_fix

Generate Mitigation Statement:

Checks: C-7864r364226_chk

Fix: F-7864r364227_fix

Generate Mitigation Statement:

Checks: C-7865r364229_chk

Fix: F-7865r364230_fix

Generate Mitigation Statement:

Checks: C-7866r766917_chk

Fix: F-7866r766918_fix

Generate Mitigation Statement:

Checks: C-7867r364235_chk

Fix: F-7867r364236_fix

Generate Mitigation Statement:

Checks: C-7868r364238_chk

Fix: F-7868r364239_fix

Generate Mitigation Statement:

Checks: C-7869r364241_chk

Fix: F-7869r364242_fix

Generate Mitigation Statement:

Checks: C-7870r364244_chk

Fix: F-7870r364245_fix

Generate Mitigation Statement:

Checks: C-7871r364247_chk

Fix: F-7871r364248_fix

Generate Mitigation Statement:

Checks: C-7872r364250_chk

Fix: F-7872r364251_fix

Generate Mitigation Statement:

Checks: C-7873r364253_chk

Fix: F-7873r364254_fix

Generate Mitigation Statement:

Checks: C-7874r364256_chk

Fix: F-7874r364257_fix

Generate Mitigation Statement:

Checks: C-7875r364259_chk

Fix: F-7875r364260_fix

Generate Mitigation Statement:

Checks: C-7876r364262_chk

Fix: F-7876r364263_fix

Generate Mitigation Statement:

Checks: C-7877r364265_chk

Fix: F-7877r364266_fix

Generate Mitigation Statement:

Checks: C-7878r364268_chk

Fix: F-7878r364269_fix

Generate Mitigation Statement:

Checks: C-7879r364271_chk

Fix: F-7879r364272_fix

Generate Mitigation Statement:

Checks: C-7880r364274_chk

Fix: F-7880r364275_fix

Generate Mitigation Statement:

Checks: C-7881r364277_chk

Fix: F-7881r364278_fix

Generate Mitigation Statement:

Checks: C-7882r364280_chk

Fix: F-7882r364281_fix

Generate Mitigation Statement:

Checks: C-7883r364283_chk