VMware vSphere 6.5 ESXi Security Technical Implementation Guide

U_VMware_vSphere_6-5_ESXi_STIG_V1R1_Manual-xccdf.xml

This Security Technical Implementation Guide is published as a tool to improve the security of Department of Defense (DoD) information systems. The requirements are derived from the National Institute of Standards and Technology (NIST) 800-53 and related documents. Comments or proposed revisions to this document should be sent via e-mail to the following address: [email protected]
Details

Version / Release: V1R1

Published: 2019-05-22

Updated At: 2019-07-06 22:00:22

Actions

Download

Filter

Vuln Rule Version CCI Severity Title Description
SV-104035r1_rule ESXI-65-000001 CCI-000054 MEDIUM The ESXi host must limit the number of concurrent sessions to ten for all accounts and/or account types by enabling lockdown mode. 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.
SV-104037r1_rule ESXI-65-000002 CCI-000366 LOW The ESXi host must verify the DCUI.Access list. 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.
SV-104039r1_rule ESXI-65-000003 CCI-000366 LOW The ESXi host must verify the exception users list for lockdown mode. 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.
SV-104041r1_rule ESXI-65-000004 CCI-000067 MEDIUM Remote logging for ESXi hosts must be configured. 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.
SV-104043r1_rule ESXI-65-000005 CCI-000044 MEDIUM The ESXi host must enforce the limit of three consecutive invalid logon attempts by a user. 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.
SV-104045r1_rule ESXI-65-000006 CCI-002238 MEDIUM The ESXi host must enforce the unlock timeout of 15 minutes after a user account is locked out. 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.
SV-104047r1_rule ESXI-65-000007 CCI-000048 MEDIUM The ESXi host must display the Standard Mandatory DoD Notice and Consent Banner before granting access to the system. Failure to display the DoD logon banner prior to a log in attempt will negate legal proceedings resulting from unauthorized access to system resources.
SV-104049r1_rule ESXI-65-000008 CCI-000048 MEDIUM The ESXi host must display the Standard Mandatory DoD Notice and Consent Banner before granting access to the system. Failure to display the DoD logon banner prior to a log in attempt will negate legal proceedings resulting from unauthorized access to system resources.
SV-104051r1_rule ESXI-65-000009 CCI-000048 MEDIUM The ESXi host SSH daemon must be configured with the Department of Defense (DoD) login banner. 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.
SV-104053r1_rule ESXI-65-000010 CCI-000068 MEDIUM The ESXi host SSH daemon must use DoD-approved encryption to protect the confidentiality of remote access sessions. 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.
SV-104055r1_rule ESXI-65-000011 CCI-000068 HIGH The ESXi host SSH daemon must be configured to use only the SSHv2 protocol. 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.
SV-104057r1_rule ESXI-65-000012 CCI-000767 MEDIUM The ESXi host SSH daemon must ignore .rhosts files. 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.
SV-104059r1_rule ESXI-65-000013 CCI-000366 MEDIUM The ESXi host SSH daemon must not allow host-based authentication. 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.
SV-104061r1_rule ESXI-65-000014 CCI-000366 LOW The ESXi host SSH daemon must not permit root logins. 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.
SV-104063r1_rule ESXI-65-000015 CCI-000366 HIGH The ESXi host SSH daemon must not allow authentication using an empty password. 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.
SV-104065r1_rule ESXI-65-000016 CCI-000366 MEDIUM The ESXi host SSH daemon must not permit user environment settings. 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.
SV-104067r1_rule ESXI-65-000017 CCI-000366 MEDIUM The ESXi host SSH daemon must be configured to only use Message Authentication Codes (MACs) employing FIPS 140-2 approved cryptographic hash algorithms. DoD information systems are required to use FIPS 140-2 approved cryptographic hash functions.
SV-104069r1_rule ESXI-65-000018 CCI-000366 LOW The ESXi host SSH daemon must not permit GSSAPI authentication. 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.
SV-104071r1_rule ESXI-65-000019 CCI-000366 LOW The ESXi host SSH daemon must not permit Kerberos authentication. 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.
SV-104073r1_rule ESXI-65-000020 CCI-000366 MEDIUM The ESXi host SSH daemon must perform strict mode checking of home directory configuration files. If other users have access to modify user-specific SSH configuration files, they may be able to log into the system as another user.
SV-104075r1_rule ESXI-65-000021 CCI-000366 MEDIUM The ESXi host SSH daemon must not allow compression or must only allow compression after successful authentication. 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.
SV-104077r1_rule ESXI-65-000022 CCI-000366 LOW The ESXi host SSH daemon must be configured to not allow gateway ports. 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.
SV-104079r1_rule ESXI-65-000023 CCI-000366 MEDIUM The ESXi host SSH daemon must be configured to not allow X11 forwarding. 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.
SV-104081r1_rule ESXI-65-000024 CCI-000366 MEDIUM The ESXi host SSH daemon must not accept environment variables from the client. 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.
SV-104083r1_rule ESXI-65-000025 CCI-000366 MEDIUM The ESXi host SSH daemon must not permit tunnels. 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.
SV-104085r1_rule ESXI-65-000026 CCI-000366 LOW The ESXi host SSH daemon must set a timeout count on idle sessions. This ensures a user login will be terminated as soon as the "ClientAliveCountMax" is reached.
SV-104087r1_rule ESXI-65-000027 CCI-000366 LOW The ESXi hostSSH daemon must set a timeout interval on idle sessions. Causing idle users to be automatically logged out guards against compromises one system leading trivially to compromises on another.
SV-104089r1_rule ESXI-65-000028 CCI-000366 MEDIUM The ESXi host SSH daemon must limit connections to a single session. 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.
SV-104091r1_rule ESXI-65-000029 CCI-000366 MEDIUM The ESXi host must remove keys from the SSH authorized_keys file. 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.
SV-104093r1_rule ESXI-65-000030 CCI-000130 LOW The ESXi host must produce audit records containing information to establish what type of events occurred. 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.
SV-104095r1_rule ESXI-65-000031 CCI-000192 MEDIUM The ESXi host must enforce password complexity by requiring that at least one upper-case character be used. 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.
SV-104097r1_rule ESXI-65-000032 CCI-000200 MEDIUM The ESXi host must prohibit the reuse of passwords within five iterations. 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.
SV-104099r1_rule ESXI-65-000033 CCI-000366 MEDIUM The password hashes stored on the ESXi host must have been generated using a FIPS 140-2 approved cryptographic hashing algorithm. 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.
SV-104101r1_rule ESXI-65-000034 CCI-000381 MEDIUM The ESXi host must disable the Managed Object Browser (MOB). 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.
SV-104103r1_rule ESXI-65-000035 CCI-000381 MEDIUM The ESXi host must be configured to disable non-essential capabilities by disabling SSH. 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.
SV-104105r1_rule ESXI-65-000036 CCI-000381 MEDIUM The ESXi host must disable ESXi Shell unless needed for diagnostics or troubleshooting. 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.
SV-104107r1_rule ESXI-65-000037 CCI-000764 LOW The ESXi host must use Active Directory for local user authentication. 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.
SV-104109r1_rule ESXI-65-000038 CCI-000764 MEDIUM The ESXi host must use the vSphere Authentication Proxy to protect passwords when adding ESXi hosts to Active Directory. 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.
SV-104111r1_rule ESXI-65-000039 CCI-000764 LOW Active Directory ESX Admin group membership must not be used when adding ESXi hosts to Active Directory. 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.
SV-104113r1_rule ESXI-65-000040 CCI-000767 LOW The ESXi host must use multifactor authentication for local access to privileged accounts. To assure accountability and prevent unauthenticated access, privileged users must utilize multifactor authentication to prevent potential misuse and compromise of the system.
SV-104115r1_rule ESXI-65-000041 CCI-001133 MEDIUM The ESXi host must set a timeout to automatically disable idle sessions after 10 minutes. 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.
SV-104117r1_rule ESXI-65-000042 CCI-001133 MEDIUM The ESXi host must terminate shell services after 10 minutes. 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.
SV-104119r1_rule ESXI-65-000043 CCI-001133 MEDIUM The ESXi host must logout of the console UI after 10 minutes. 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.
SV-104121r1_rule ESXI-65-000044 CCI-001665 LOW The ESXi host must enable kernel core dumps. 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.
SV-104123r1_rule ESXI-65-000045 CCI-001849 MEDIUM The ESXi host must enable a persistent log location for all locally stored logs. 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.
SV-104125r1_rule ESXI-65-000046 CCI-001891 MEDIUM The ESXi host must configure NTP time synchronization. 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.
SV-104127r1_rule ESXI-65-000047 CCI-001749 HIGH The ESXi Image Profile and VIB Acceptance Levels must be verified. 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.
SV-104129r1_rule ESXI-65-000048 CCI-002418 MEDIUM The ESXi host must protect the confidentiality and integrity of transmitted information by isolating vMotion traffic. 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.
SV-104131r1_rule ESXI-65-000049 CCI-002418 MEDIUM The ESXi host must protect the confidentiality and integrity of transmitted information by protecting ESXi management traffic. The vSphere management network provides access to the vSphere management interface on each component. Services running on the management interface provide an opportunity for an attacker to gain privileged access to the systems. Any remote attack most likely would begin with gaining entry to this network.
SV-104133r1_rule ESXI-65-000050 CCI-002418 MEDIUM The ESXi host must protect the confidentiality and integrity of transmitted information by protecting IP based management traffic. 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.
SV-104135r1_rule ESXI-65-000049 CCI-002418 LOW The ESXi host must protect the confidentiality and integrity of transmitted information. From the vSphere Web Client select the ESXi Host and go to Configure >> Networking >> VMkernel adapters. Review each VMkernel adapter that is defined and ensure it is enabled for only one type of management traffic.
SV-104137r1_rule ESXI-65-000052 CCI-002418 LOW The ESXi host must protect the confidentiality and integrity of transmitted information by utilizing different TCP/IP stacks where possible. 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.
SV-104139r1_rule ESXI-65-000053 CCI-000366 MEDIUM SNMP must be configured properly on the ESXi host. 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.
SV-104141r1_rule ESXI-65-000054 CCI-000366 LOW The ESXi host must enable bidirectional CHAP authentication for iSCSI traffic. 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.
SV-104143r1_rule ESXI-65-000055 CCI-000366 LOW The ESXi host must disable Inter-VM transparent page sharing. 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).
SV-104145r1_rule ESXI-65-000056 CCI-000366 MEDIUM The ESXi host must configure the firewall to restrict access to services running on the host. 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.
SV-104147r1_rule ESXI-65-000057 CCI-000366 MEDIUM The ESXi host must configure the firewall to block network traffic by default. 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.
SV-104149r1_rule ESXI-65-000058 CCI-000366 LOW 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. 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.
SV-104151r1_rule ESXI-65-000059 CCI-000366 MEDIUM The virtual switch Forged Transmits policy must be set to reject on the ESXi host. 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.
SV-104153r1_rule ESXI-65-000060 CCI-000366 HIGH The virtual switch MAC Address Change policy must be set to reject on the ESXi host. 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.
SV-104155r1_rule ESXI-65-000061 CCI-000366 MEDIUM The virtual switch Promiscuous Mode policy must be set to reject on the ESXi host. 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.
SV-104157r1_rule ESXI-65-000062 CCI-000366 MEDIUM The ESXi host must prevent unintended use of the dvFilter network APIs. 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.
SV-104159r1_rule ESXI-65-000063 CCI-000366 MEDIUM For the ESXi host all port groups must be configured to a value other than that of the native VLAN. 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.
SV-104161r1_rule ESXI-65-000064 CCI-000366 MEDIUM For the ESXi host all port groups must not be configured to VLAN 4095 unless Virtual Guest Tagging (VGT) is required. 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.
SV-104163r1_rule ESXI-65-000065 CCI-000366 MEDIUM For the ESXi host all port groups must not be configured to VLAN values reserved by upstream physical switches. 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.
SV-104165r1_rule ESXI-65-000066 CCI-000366 MEDIUM 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. 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.
SV-104167r1_rule ESXI-65-000067 CCI-000366 LOW All ESXi host-connected physical switch ports must be configured with spanning tree disabled. 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.
SV-104169r1_rule ESXI-65-000068 CCI-000366 MEDIUM All ESXi host-connected virtual switch VLANs must be fully documented and have only the required VLANs. 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.
SV-104303r1_rule ESXI-65-000070 CCI-000366 MEDIUM The ESXi host must not provide root/administrator level access to CIM-based hardware monitoring tools or other third-party applications. 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.
SV-104307r1_rule ESXI-65-000071 CCI-000366 HIGH The ESXi host must verify the integrity of the installation media before installing ESXi. Always check the SHA1 or MD5 hash after downloading an ISO, offline bundle, or patch to ensure integrity and authenticity of the downloaded files.
SV-104309r1_rule ESXI-65-000072 CCI-000366 HIGH The ESXi host must have all security patches and updates installed. Installing software updates is a fundamental mitigation against the exploitation of publicly-known vulnerabilities.
SV-104311r1_rule ESXI-65-000073 CCI-000366 MEDIUM The ESXi host must enable TLS 1.2 exclusively for the SFCB service. TLS 1.0 and 1.1 are deprecated protocols with well published shortcomings and vulnerabilities. TLS 1.2 should be enabled on all interfaces and SSLv3, TL 1.1 and 1.0 disabled where supported. Mandating TLS 1.2 may break third party integrations and add-ons to vSphere. Test these integrations carefully after implementing TLS 1.2 and roll back where appropriate. On interfaces where required functionality is broken with TLS 1.2 this finding is N/A until such time as the third party software supports TLS 1.2. Make sure you modify TLS settings in the following order: 1. Platform Services Controllers (if applicable), 2. vCenter, 3. ESXi
SV-104313r1_rule ESXI-65-000074 CCI-000366 MEDIUM The ESXi host must exclusively enable TLS 1.2 for the ioFilter, vSANVP and reverse proxy services. TLS 1.0 and 1.1 are deprecated protocols with well published shortcomings and vulnerabilities. TLS 1.2 should be enabled on all interfaces and SSLv3, TL 1.1 and 1.0 disabled where supported. Mandating TLS 1.2 may break third party integrations and add-ons to vSphere. Test these integrations carefully after implementing TLS 1.2 and roll back where appropriate. On interfaces where required functionality is broken with TLS 1.2 this finding is N/A until such time as the third party software supports TLS 1.2. Make sure you modify TLS settings in the following order: 1. Platform Services Controllers (if applicable), 2. vCenter, 3. ESXi
SV-104315r1_rule ESXI-65-000075 CCI-000366 MEDIUM The ESXi host must exclusively enable TLS 1.2 for the authd service. TLS 1.0 and 1.1 are deprecated protocols with well published shortcomings and vulnerabilities. TLS 1.2 should be disabled on all interfaces and TL 1.1 and 1.0 disabled where supported. Mandating TLS 1.2 may break third party integrations and add-ons to vSphere. Test these integrations carefully after implementing TLS 1.2 and roll back where appropriate. On interfaces where required functionality is broken with TLS 1.2 this finding is N/A until such time as the third party software supports TLS 1.2.
SV-104317r1_rule ESXI-65-000076 CCI-000366 MEDIUM The ESXi host must enable Secure Boot. 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.
SV-104319r1_rule ESXI-65-000078 CCI-000366 MEDIUM The ESXi host must use DoD-approved certificates. 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.
SV-104321r1_rule ESXI-65-100001 CCI-001682 MEDIUM The ESXi host must enable lockdown mode to restrict remote access. 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. 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.
SV-104323r1_rule ESXI-65-100004 CCI-000154 MEDIUM The ESXi host must centrally review and analyze audit records from multiple components within the system by configuring remote logging. 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.
SV-104325r1_rule ESXI-65-100007 CCI-000050 MEDIUM The ESXi host must retain the Standard Mandatory DoD Notice and Consent Banner on the screen until users acknowledge the usage conditions and take explicit actions to log on for further access. Failure to display the DoD logon banner prior to a log in attempt will negate legal proceedings resulting from unauthorized access to system resources.
SV-104327r1_rule ESXI-65-100010 CCI-002450 MEDIUM The ESXi host SSH daemon must be configured to only use FIPS 140-2 approved ciphers. Approved algorithms should impart some level of confidence in their implementation. These are also required for compliance. Note: That this does not imply FIPS 140-2 certification.
SV-104329r1_rule ESXI-65-100030 CCI-000171 LOW The ESXi host must allow only the ISSM (or individuals or roles appointed by the ISSM) to select which auditable events are to be audited. 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.
SV-104331r1_rule ESXI-65-100031 CCI-000193 MEDIUM The ESXi host must enforce password complexity by requiring that at least one lower-case character be used. 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.
SV-104333r1_rule ESXI-65-100035 CCI-002314 MEDIUM The ESXi host must disable SSH. 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.
SV-104335r1_rule ESXI-65-100037 CCI-000770 LOW 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. 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.
SV-104337r1_rule ESXI-65-100038 CCI-000770 MEDIUM The ESXi host must require individuals to be authenticated with an individual authenticator prior to using a group authenticator by using the vSphere Authentication Proxy. 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.
SV-104339r1_rule ESXI-65-100039 CCI-000770 LOW The ESXi host must require individuals to be authenticated with an individual authenticator prior to using a group authenticator by restricting use of Active Directory ESX Admin group membership. 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.
SV-104341r1_rule ESXI-65-100040 CCI-001953 LOW The ESXi host must accept Personal Identity Verification (PIV) credentials. To assure accountability and prevent unauthenticated access, privileged users must utilize multifactor authentication to prevent potential misuse and compromise of the system.
SV-104343r1_rule ESXI-65-100041 CCI-002361 MEDIUM The ESXi host must automatically terminate a user session after inactivity timeouts have expired or at shutdown by setting an idle timeout. 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" value allows you to automatically terminate idle shell sessions.
SV-104345r1_rule ESXI-65-100042 CCI-002361 MEDIUM The ESXi host must automatically terminate a user session after inactivity timeouts have expired or at shutdown by setting an idle timeout on shell services. 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" value. The "ESXiShellTimeOut" value defines a window of time after which the ESXi Shell and SSH services will automatically be terminated.
SV-104347r1_rule ESXI-65-100043 CCI-002361 MEDIUM The ESXi host must automatically terminate a user session after inactivity timeouts have expired or at shutdown. When the Direct console user interface (DCUI) is enabled and logged in it should be automatically logged out if left logged on to avoid unauthorized privilege gains. The "DcuiTimeOut" value defines a window of time after which the DCUI will be logged off.
SV-104349r1_rule ESXI-65-100046 CCI-002046 MEDIUM The ESXi host must synchronize internal information system clocks to the authoritative time source when the time difference is greater than one second. 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.
SV-104351r1_rule ESXI-65-100047 CCI-001774 HIGH The ESXi host must employ a deny-all, permit-by-exception policy to allow the execution of authorized software programs and guest VMs by verifying Image Profile and VIP Acceptance Levels. 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.
SV-104353r1_rule ESXI-65-200004 CCI-000163 MEDIUM The ESXi host must protect audit information from unauthorized modification by configuring remote logging. 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.
SV-104355r1_rule ESXI-65-200031 CCI-000194 MEDIUM The ESXi host must enforce password complexity by requiring that at least one numeric character be used. 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.
SV-104357r1_rule ESXI-65-200035 CCI-002322 MEDIUM The ESXi host must immediately disconnect or disable remote access to the information system by disabling SSH. 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.
SV-104359r1_rule ESXI-65-200037 CCI-001941 LOW The ESXi host must implement replay-resistant authentication mechanisms for network access to privileged accounts by using Active Directory for local user authentication. 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.
SV-104361r1_rule ESXI-65-200038 CCI-001941 MEDIUM The ESXi host must implement replay-resistant authentication mechanisms for network access to privileged accounts by using the vSphere Authentication Proxy. 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.
SV-104363r1_rule ESXI-65-200039 CCI-001941 LOW The ESXi host must implement replay-resistant authentication mechanisms for network access to privileged accounts by restricting use of Active Directory ESX Admin group membership. 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.
SV-104365r1_rule ESXI-65-200040 CCI-001954 LOW The ESXi host must electronically verify Personal Identity Verification (PIV) credentials. To assure accountability and prevent unauthenticated access, privileged users must utilize multifactor authentication to prevent potential misuse and compromise of the system.
SV-104367r1_rule ESXI-65-200047 CCI-002475 HIGH The ESXi host must implement cryptographic mechanisms to prevent unauthorized modification of all information at rest on all VMM components by verifying Image Profile and VIP Acceptance Levels. 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.
SV-104369r1_rule ESXI-65-300004 CCI-000164 MEDIUM The ESXi host must protect audit information from unauthorized deletion by configuring remote logging. 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.
SV-104371r1_rule ESXI-65-300031 CCI-000195 MEDIUM The ESXi host must require the change of at least 8 of the total number of characters when passwords are changed. 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.
SV-104373r1_rule ESXI-65-300037 CCI-001942 LOW The ESXi host must implement replay-resistant authentication mechanisms for network access to non-privileged accounts by using Active Directory for local user authentication. 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.
SV-104375r1_rule ESXI-65-300038 CCI-001942 MEDIUM The ESXi host must implement replay-resistant authentication mechanisms for network access to non-privileged accounts by using the vSphere Authentication Proxy. 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.
SV-104377r1_rule ESXI-65-300039 CCI-001942 LOW The ESXi host must implement replay-resistant authentication mechanisms for network access to non-privileged accounts by restricting use of Active Directory ESX Admin group membership. 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.
SV-104379r1_rule ESXI-65-300040 CCI-002470 LOW The ESXi host must only allow the use of DoD PKI-established certificate authorities for verification of the establishment of protected sessions. To assure accountability and prevent unauthenticated access, privileged users must utilize multifactor authentication to prevent potential misuse and compromise of the system.
SV-104381r1_rule ESXI-65-400004 CCI-001851 MEDIUM The ESXi host must off-load audit records onto a different system or media than the system being audited by configuring remote logging. 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.
SV-104383r1_rule ESXI-65-400031 CCI-000205 MEDIUM The ESXi host must enforce a minimum 15-character password length. 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.
SV-104385r1_rule ESXI-65-500004 CCI-001851 MEDIUM The ESXi host must, at a minimum, off-load interconnected systems in real time and off-load standalone systems weekly by configuring remote logging. 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.
SV-104387r1_rule ESXI-65-500031 CCI-001619 MEDIUM The ESXi host must enforce password complexity by requiring that at least one special character be used. 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.