VMware vSphere 6.7 vCenter STIG
VMware vSphere 6.7 vCenter Security Technical Implementation Guide. Version v1 r2, released Feb. 8, 2022.
VCTR-67-000001: The vCenter Server must prohibit password reuse for a minimum of five generations.
From the vSphere Client, go to Administration >> Single Sign-On >> Configuration >> Policies >> Password Policy. View the value of the "Restrict reuse" setting. If the "Restrict reuse" policy is not set to "5" or more, this is a finding.
Discussion
Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. To meet password policy requirements, passwords need to be changed at specific policy-based intervals. If the information system or application allows the user to consecutively reuse their password when that password has exceeded its defined lifetime, the end result is a password that is not changed as per policy requirements.
Fix
From the vSphere Client, go to Administration >> Single Sign-On >> Configuration >> Policies >> Password Policy. Click "Edit". Enter "5" into the "Restrict reuse" setting and click "OK".
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
VCTR-67-000077: The vCenter Server must enable TLS 1.2 exclusively.
Note: For vCenter Server Appliance, this is not applicable. Download the VMware TLS Reconfigurator utility from my.vmware.com. Follow installation instructions for your vCenter platform according to VMware KB 2147469. 1. Open a command prompt and cd to C:\Program Files\VMware\CIS\vSphereTlsReconfigurator\VcTlsReconfigurator 2. Enter command "reconfigureVc scan" and press "Enter" If the output indicates versions of TLS other than 1.2 are enabled, this is a finding.
Discussion
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 TLS 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 Controls (if applicable), 2. vCenter, 3. ESXi
Fix
Download the VMware TLS Reconfigurator utility from my.vmware.com. Follow installation instructions for your vCenter platform according to VMware KB 2147469. Run the following commands. 1. Open a command prompt and cd to C:\Program Files\VMware\CIS\vSphereTlsReconfigurator\VcTlsReconfigurator 2. Enter command "reconfigureVc backup" and press "Enter" 3. Enter command "reconfigureVc update -p TLS1.2" and press "Enter" vCenter services will be restarted as part of the reconfiguration, the OS will not be restarted. You can add the --no-restart flag to restart services at a later time. Changes will not take effect until all services are restarted or the machine is rebooted.
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
VCTR-67-000071: The vCenter Server must terminate management sessions after 10 minutes of inactivity.
Note: For vCenter Server Appliance, this is not applicable. By default, vSphere Client sessions terminate after "120" minutes of idle time, requiring the user to log in again to resume using the client. You can view the timeout value by viewing the "webclient.properties" file. On the vCenter Server locate the "webclient.properties" file in C:\ProgramData\VMware\vCenterServer\cfg\vsphere-client Find the "session.timeout =" line in the "webclient.properties" file. If the session timeout is not set to "10" in the "webclient.properties" file, this is a finding.
Discussion
Terminating an idle session within a short time period reduces the window of opportunity for unauthorized personnel to take control of a management session enabled on the console or console port that has been left unattended. In addition, quickly terminating an idle session will also free up resources committed by the managed network element. Terminating network connections associated with communications sessions includes, for example, de-allocating associated TCP/IP address/port pairs at the operating system level, or de-allocating networking assignments at the application level if multiple application sessions are using a single, operating system level network connection. This does not mean that the application terminates all sessions or network access; it only ends the inactive session and releases the resources associated with that session.
Fix
Change the timeout value by editing the "webclient.properties" file. On the vCenter Server locate the "webclient.properties" file in C:\ProgramData\VMware\vCenterServer\cfg\vsphere-client Edit the file to include the line "session.timeout = 10" where "10" is the timeout value in minutes. Uncomment the line if necessary. After editing the file the vSphere Client service must be restarted.
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
VCTR-67-000005: The vCenter Server users must have the correct roles assigned.
From the vSphere Client, go to Administration >> Access Control >> Roles. View each role and verify the users and/or groups assigned to it. or From a PowerCLI command prompt while connected to the vCenter server, run the following command: Get-VIPermission | Sort Role | Select Role,Principal,Entity,Propagate,IsGroup | FT -Auto Application service account and user required privileges should be documented. If any user or service account has more privileges than required, this is a finding.
Discussion
Users and service accounts must only be assigned privileges they require. Least privilege requires that these privileges must only be assigned if needed to reduce risk of confidentiality, availability, or integrity loss.
Fix
To update a user's or group's permissions to an existing role with reduced permissions: From the vSphere Client, go to Administration >> Access Control >> Global Permissions. Select the user or group, click "Edit", change the assigned role, and click "OK". If permissions are assigned on a specific object, the role must be updated where it is assigned (for example, at the cluster level). To create a new role with reduced permissions: From the vSphere Client, go to Administration >> Access Control >> Roles. Click the green plus sign, enter a name for the role, and select only the specific permissions required. Users can then be assigned to the newly created role.
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
VCTR-67-000047: The vCenter Server must require an administrator to unlock an account locked due to excessive login failures.
From the vSphere Client, go to Administration >> Single Sign-On >> Configuration >> Policies >> Lockout Policy. View the values for the lockout policies. The following lockout policy should be set at follows: Unlock time: 0 If this account lockout policy is not configured as stated, this is a finding.
Discussion
By requiring that SSO accounts be unlocked manually, the risk of unauthorized access via user password guessing, otherwise known as brute forcing, is reduced. When the account unlock time is set to zero, once an account is locked it can only be unlocked manually by an administrator.
Fix
From the vSphere Client, go to Administration >> Single Sign-On >> Configuration >> Policies >> Lockout Policy. Click "Edit". Set the "Unlock time" to "0" and click "OK".
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
VCTR-67-000025: The vCenter Server must disable the managed object browser (MOB) at all times when not required for troubleshooting or maintenance of managed objects.
Check the operational status of the MOB by performing one of the following or both: Browse to the MOB page on the vCenter server: https://<vcenter fqdn or IP>/mob If a "503 Service Unavailable" error is returned, the MOB is disabled. If a prompt for authentication appears, it is enabled. or Run the following command from the vCenter appliance: grep -i "enableDebugBrowse" /etc/vmware-vpx/vpxd.cfg If the MOB is enabled, ask the SA if it is being used for object maintenance and if so, this is not a finding. If the "enableDebugBrowse" element is enabled (set to true) or absent, and object maintenance is not being performed, this is a finding.
Discussion
The MOB was designed to be used by SDK developers to assist in the development, programming, and debugging of objects. It is an inventory object, full-access interface, allowing attackers to determine the inventory path of an infrastructure's managed entities. The MOB provides a way to explore the object model used by the vCenter to manage the vSphere environment; it enables configurations to be changed as well. This interface is used primarily for debugging and could potentially be used to perform malicious configuration changes or actions.
Fix
If the datastore browser is enabled and required for object maintenance, no fix is immediately required. Disable the managed object browser by editing the /etc/vmware-vpx/vpxd.cfg file. Edit the file and locate the <vpxd> ... </vpxd> element. Add or update the following element in the vpxd section: <enableDebugBrowse>false</enableDebugBrowse> Note: It is not present by default and is case sensitive. Restart the vCenter Service to ensure the configuration file change(s) are in effect by running the following command on the vCenter appliance: service-control --restart vmware-vpxd
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
VCTR-67-000066: The vCenter Server must have new Key Encryption Keys (KEKs) reissued at regular intervals for vSAN encrypted datastore(s).
Interview the SA to determine that a procedure has been implemented to perform a mustow rekey of all vSAN encrypted datastores at regular, site-defined intervals. VMware recommends a 60-day rekey task, but this interval must be defined by the SA and the ISSO. If vSAN encryption is not in use, this is not a finding.
Discussion
The KEK for a vSAN encrypted datastore is generated by the Key Management Server (KMS) and serves as a wrapper and lock around the Disk Encryption Key (DEK). The DEK is generated by the host and is used to encrypt and decrypt the datastore. A mustow rekey is a procedure in which the KMS issues a new KEK to the ESXi host that rewraps the DEK but does not change the DEK or any data on disk. This operation must be done on a regular, site-defined interval and can be viewed as similar in criticality to changing an administrative password. If the KMS is compromised, a standing operational procedure to rekey will put a time limit on the usefulness of any stolen KMS data.
Fix
If vSAN encryption is in use, ensure that a regular rekey procedure is in place.
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
VCTR-67-000063: The vCenter Server must restrict access to the cryptographic role.
From the vSphere Client, go to Administration >> Access Control >> Roles. or From a PowerCLI command prompt while connected to the vCenter server, run the following command: Get-VIPermission | Where {$_.Role -eq "Admin"} | Select Role,Principal,Entity,Propagate,IsGroup | FT -Auto If there are any users other than Solution Users with the "Administrator" role that are not explicitly designated for cryptographic operations, this is a finding.
Discussion
In vSphere 6.7, the built-in "Administrator" role contains permission to perform cryptographic operations such as KMS functions and encrypting and decrypting virtual machine disks. This role must be reserved for cryptographic administrators where VM encryption and/or vSAN encryption is in use. A new built-in role called "No Cryptography Administrator" exists to provide all administrative permissions except cryptographic operations. Permissions must be restricted such that normal vSphere administrators are assigned the 'No Cryptography Administrator' role or more restrictive. The "Administrator" role must be tightly controlled and must not be applied to administrators who will not be doing cryptographic work. Catastrophic data loss can result from poorly administered cryptography.
Fix
From the vSphere Client, go to Administration >> Access Control >> Roles. Move any accounts not explicitly designated for cryptographic operations, other than Solution Users, to other roles such as "No Cryptography Administrator".
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
VCTR-67-000060: The vCenter Server must enable revocation checking for certificate-based authentication.
From the vSphere Client, go to Administration >> Single Sign-On >> Configuration >> Smart Card Authentication. Under Smart card authentication settings >> Certificate revocation, verify that "Revocation check" does not show as disabled. If "Revocation check" shows as disabled, this is a finding.
Discussion
The system must establish the validity of the user-supplied identity certificate using OCSP and/or CRL revocation checking.
Fix
From the vSphere Client, go to Administration >> Single Sign-On > Configuration >> Smart Card Authentication. Under Smart card authentication settings >> Certificate revocation, click the "Edit" button. By default, the PSC will use the CRL from the certificate to check revocation check status. OCSP with CRL fallback is recommended, but this setting is site specific and should be configured appropriately.
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
VCTR-67-000014: The vCenter Server must set the distributed port group MAC Address Change policy to reject.
If distributed switches are not used, this is not applicable. From the vSphere Client, go to Networking >> select a distributed switch >> select a port group >> Configure >> Settings >> Policies. Verify "MAC Address Changes" is set to reject. or From a PowerCLI command prompt while connected to the vCenter server, run the following commands: Get-VDSwitch | Get-VDSecurityPolicy Get-VDPortgroup | ?{$_.IsUplink -eq $false} | Get-VDSecurityPolicy If the "MAC Address Changes" policy is set to accept, this is a finding.
Discussion
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 and will affect applications that require a specific MAC address for licensing.
Fix
From the vSphere Client, go to Networking >> select a distributed switch >> select a port group >> Configure >> Settings >> Policies >> Edit >> Security. Set "MAC Address Changes" to reject. Click "OK". or From a PowerCLI command prompt while connected to the vCenter server, run the following commands: Get-VDSwitch | Get-VDSecurityPolicy | Set-VDSecurityPolicy -MacChanges $false Get-VDPortgroup | ?{$_.IsUplink -eq $false} | Get-VDSecurityPolicy | Set-VDSecurityPolicy -MacChanges $false
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
VCTR-67-000076: The vCenter Server Administrator role must be secured and assigned to specific users other than a Windows Administrator.
Note: For vCenter Server Appliance, this is not applicable. If enhanced linked mode is used then local windows authentication is not available to vCenter, this is not applicable. Under the computer management console for windows view the local administrators group and verify only vCenter administrators have access to the vCenter server. Other groups and users that are not vCenter administrators should be removed from the local administrators group such as Domain Admins. If there are any groups or users present in the local administrators group of the vCenter server, this is a finding.
Discussion
By default, vCenter Server grants full administrative rights to the local administrator's account, which can be accessed by domain administrators. Separation of duties dictates that full vCenter Administrative rights should be granted only to those administrators who are required to have it. This privilege should not be granted to any group whose membership is not strictly controlled. Therefore, administrative rights should be removed from the local Windows server to users who are not vCenter administrators.
Fix
Under the computer management console for windows view the local administrators group and remove any users or groups that do not fit the criteria defined in the check content.
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
VCTR-67-000059: The vCenter Server must enable certificate based authentication.
See supplemental document. Ensure that CAC authentication is required to log in to the vSphere Client. If CAC authentication is not required, this is a finding.
Discussion
The vSphere Client is capable of CAC authentication. This capability must be enabled and properly configured.
Fix
Configure CAC Authentication per supplemental document.
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
VCTR-67-000062: The vCenter Server must enable the login banner for vSphere Client.
From the vSphere Client, go to Administration >> Single Sign-On >> Configuration >> Login Message. If selection boxes next to "Show login message" are disabled or if "Details of login message" is not configured to the standard DoD User Agreement, this is a finding. Note: Supplementary Information: DoD Logon Banner "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."
Discussion
The required legal notice must be configured for the vCenter Web Client.
Fix
From the vSphere Client, go to Administration >> Single Sign-On >> Configuration >> Login Message. Click "Edit". Click the "Show login message" slider to enable. Configure the "Login message" to "DoD User Agreement". Click the "Consent checkbox" slider to enable. Set the "Details of login message" to the standard DoD User Agreement text. Click "Save".
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
VCTR-67-000010: The vCenter Server must limit the use of the built-in SSO administrative account.
Verify the built-in SSO administrator account is only used for emergencies and situations where it is the only option due to permissions. If the built-in SSO administrator account is used for daily operations or there is no policy restricting its use, this is a finding.
Discussion
Use of the SSO administrator account should be limited as it is a shared account and individual accounts must be used wherever possible.
Fix
Develop a policy to limit the use of the built-in SSO administrator account.
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
VCTR-67-000078: The vCenter Server must disable Password and Windows integrated authentication.
Note: For vCenter Server Appliance, this is not applicable. From the vSphere Client, go to Administration >> Single Sign-On >> Configuration >> Smart Card Authentication. If "Smart card authentication" is not enabled and "Password and windows session authentication" is not disabled, this is a finding.
Discussion
All forms of authentication other than CAC must be disabled. Password authentication can be temporarily reenabled for emergency access to the local SSO domain accounts, but it must be disabled as soon as CAC authentication is functional.
Fix
From the vSphere Client, go to Administration >> Single Sign-On >> Configuration >> Smart Card Authentication. Next to "Authentication methods", click "Edit". Click the "Enable smart card authentication" radio button and click "Save". To reenable password authentication for troubleshooting purposes, run the following command on the vCenter server: C:\Program Files\VMware\VCenter server\VMware Identity Services\sso-config.bat -set_authn_policy -pwdAuthn true -winAuthn false -certAuthn false -securIDAuthn false -t vsphere.local
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
VCTR-67-000054: The vCenter Server must disable or restrict the connectivity between vSAN Health Check and public Hardware Compatibility List by use of an external proxy server.
If no clusters are enabled for vSAN, this is not applicable. From the vSphere Client, go to Hosts and Clusters >> select the vCenter Server >> Configure >> vSAN >> Internet Connectivity. If the HCL internet download is not required, verify that "Status" is disabled. If the "Status" is enabled, this is a finding. If the HCL internet download is required, verify that "Status" is enabled and a proxy host is configured. If "Status" is enabled and a proxy is not configured, this is a finding.
Discussion
The vSAN Health Check is able to download the hardware compatibility list from VMware to check compliance against the underlying vSAN Cluster hosts. To ensure the vCenter server is not directly downloading content from the internet, this functionality must be disabled or, if this feature is necessary, an external proxy server must be configured.
Fix
From the vSphere Client, go to Hosts and Clusters >> vCenter Server >> Configure >> vSAN >> Internet Connectivity >> Edit. If the HCL internet download is not required, ensure that "Status" is disabled. If the HCL internet download is required, ensure that "Status" is enabled and a proxy host is appropriately configured.
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
VCTR-67-000068: The vCenter Server must use secure Lightweight Directory Access Protocol (LDAPS) when adding an SSO identity source.
From the vSphere Client, go to Administration >> Single Sign-On >> Configuration. Click the "Identity Sources" tab. For each identity source of type "Active Directory", if the "Server URL" does not indicate "ldaps://", this is a finding.
Discussion
LDAP is an industry-standard protocol for querying directory services such as Active Directory. This protocol can operate in clear text or over an SSL/TLS encrypted tunnel. To protect confidentiality of LDAP communications, secure LDAP (LDAPS) must be explicitly configured when adding an LDAP identity source in vSphere SSO. When configuring an identity source and supplying an SSL certificate, vCenter will enforce LDAPs. The server URLs do not need to be explicitly provided as long as an SSL certificate is uploaded.
Fix
From the vSphere Client, go to Administration >> Single Sign-On >> Configuration. Click the "Identity Sources" tab. For each identity source of type "Active Directory" where LDAPS is not configured, highlight the item and click "Edit". Ensure the primary and secondary server URLs, if specified, are configured for "ldaps://". At the bottom, click the "Browse" button, select the AD LDAP cert previously exported to the local computer, click "Open", and "Save" to complete modifications. Note: With LDAPS, the server must be a specific domain controller and its specific certificate or the domain alias with a certificate that is valid for that URL.
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
VCTR-67-000023: The vCenter Server must configure the vpxuser auto-password to be changed every 30 days.
From the vSphere Client, go to Hosts and Clusters >> select a vCenter Server >> Configure >> Settings >> Advanced Settings. Verify that "VirtualCenter.VimPasswordExpirationInDays" is set to "30". or From a PowerCLI command prompt while connected to the vCenter server, run the following command: Get-AdvancedSetting -Entity <vcenter server name> -Name VirtualCenter.VimPasswordExpirationInDays and verify it is set to 30. If the "VirtualCenter.VimPasswordExpirationInDays" is set to a value other than "30" or does not exist, this is a finding.
Discussion
By default, the vpxuser password will be automatically changed by vCenter every 30 days. Ensure this setting meets site policies; if not, configure to meet password aging policies. Note: It is very important the password aging policy not be shorter than the default interval that is set to automatically change the vpxuser password, to preclude the possibility that vCenter might be locked out of an ESXi host.
Fix
From the vSphere Client, go to Hosts and Clusters >> select a vCenter Server >> Configure >> Settings >> Advanced Settings. Click "Edit Settings" and configure the "VirtualCenter.VimPasswordExpirationInDays" value to "30". If the value does not exist, create it by entering the values in the "Key" and "Value" fields and clicking "Add". or From a PowerCLI command prompt while connected to the vCenter server, run the following command: If the setting already exists: Get-AdvancedSetting -Entity <vcenter server name> -Name VirtualCenter.VimPasswordExpirationInDays | Set-AdvancedSetting -Value 30 If the setting does not exist: New-AdvancedSetting -Entity <vcenter server name> -Name VirtualCenter.VimPasswordExpirationInDays -Value 30
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
VCTR-67-000041: The vCenter Server passwords must contain at least one lowercase character.
From the vSphere Client, go to Administration >> Single Sign-On >> Configuration >> Policies >> Password Policy. View the values of the password format requirements. The following password requirement should be set at a minimum: Lower-case Characters: At least 1 If this password complexity policy is not configured as stated, this is a finding.
Discussion
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.
Fix
From the vSphere Client, go to Administration >> Single Sign-On >> Configuration >> Policies >> Password Policy. Click "Edit". Set "Lower-case Characters" to at least "1" and click "OK".
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
VCTR-67-000040: The vCenter Server passwords must contain at least one uppercase character.
From the vSphere Client, go to Administration >> Single Sign-On >> Configuration >> Policies >> Password Policy. View the values of the password format requirements. The following password requirement should be set at a minimum: Upper-case Characters: At least 1 If this password complexity policy is not configured as stated, this is a finding.
Discussion
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.
Fix
From the vSphere Client, go to Administration >> Single Sign-On >> Configuration >> Policies >> Password Policy. Click "Edit". Set "Upper-case Characters" to at least "1" and click "OK".
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
VCTR-67-000051: The vCenter Server users must have the correct roles assigned.
From the vSphere Client, go to Administration >> Access Control >> Roles. View each role and verify the users and/or groups assigned to it. or From a PowerCLI command prompt while connected to the vCenter server, run the following command: Get-VIPermission | Sort Role | Select Role,Principal,Entity,Propagate,IsGroup | FT -Auto Application service account and user required privileges should be documented. If any user or service account has more privileges than required, this is a finding.
Discussion
Users and service accounts must only be assigned privileges they require. Least privilege requires that these privileges must only be assigned if needed to reduce risk of confidentiality, availability, or integrity loss.
Fix
To create a new role with specific permissions: From the vSphere Client, go to Administration >> Access Control >> Roles. Click the plus sign, enter a name for the role, and select only the specific permissions required. Users can then be assigned to the newly created role.
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
VCTR-67-000007: The vCenter Server must manage excess capacity, bandwidth, or other redundancy to limit the effects of information-flooding types of denial-of-service (DoS) attacks by enabling Network I/O Control (NIOC).
If distributed switches are not used, this is not applicable. From the vSphere Client, go to Networking >> select a distributed switch >> Configure >> Settings >> Properties. View the "Properties" pane and verify Network I/O Control is enabled. or From a PowerCLI command prompt while connected to the vCenter server, run the following command: Get-VDSwitch | select Name,@{N="NIOC Enabled";E={$_.ExtensionData.config.NetworkResourceManagementEnabled}} If Network I/O Control is disabled, this is a finding.
Discussion
DoS is a condition when a resource is not available for legitimate users. When this occurs, the organization either cannot accomplish its mission or must operate at degraded capacity. Managing excess capacity ensures that sufficient capacity is available to counter flooding attacks. Employing increased capacity and service redundancy may reduce the susceptibility to some DoS attacks. Managing excess capacity may include, for example, establishing selected usage priorities, quotas, or partitioning.
Fix
From the vSphere Client, go to Networking >> select a distributed switch >> Configure >> Settings >> Properties. In the "Properties" pane, click "Edit" and change Network I/O Control to enabled. or From a PowerCLI command prompt while connected to the vCenter server, run the following command: (Get-VDSwitch "VDSwitch Name" | Get-View).EnableNetworkResourceManagement($true)
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
VCTR-67-000069: The vCenter Server must use a limited privilege account when adding an LDAP identity source.
From the vSphere Client, go to Administration >> Single Sign-On >> Configuration. Click the "Identity Sources" tab. For each identity source with of type "Active Directory", highlight the item and click "Edit". If the account that is configured to bind to the LDAPS server is not one with minimal privileges, this is a finding.
Discussion
When adding an LDAP identity source to vSphere SSO, the account used to bind to AD must be minimally privileged. This account only requires read rights to the base DN specified. Any other permissions inside or outside of that OU are unnecessary and violate least privilege.
Fix
From the vSphere Client, go to Administration >> Single Sign-On >> Configuration. Click the "Identity Sources" tab. For each identity source that has been configured with a highly privileged AD account, highlight the item and click "Edit". Change the username and password to one with read-only rights to the base DN and complete the dialog.
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
VCTR-67-000043: The vCenter Server passwords must contain at least one special character.
From the vSphere Client, go to Administration >> Single Sign-On >> Configuration >> Policies >> Password Policy. View the values of the password format requirements. The following password requirements should be set at a minimum: Special Characters: At least 1 If this password complexity policy is not configured as stated, this is a finding.
Discussion
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.
Fix
From the vSphere Client, go to Administration >> Single Sign-On >> Configuration >> Policies >> Password Policy. Click "Edit". Set "Special Characters" to at least "1" and click "OK".
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
VCTR-67-000020: The vCenter Server must not configure all port groups to VLAN values reserved by upstream physical switches.
If distributed switches are not used, this is not applicable. From the vSphere Client, go to Networking >> select a distributed switch >> select a distributed port group >> Configure >> Settings >> Policies. 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 vCenter server, run the following command: Get-VDPortgroup | select Name, VlanConfiguration If any port group is configured with a reserved VLAN ID, this is a finding.
Discussion
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 the specific switch. Using a reserved VLAN might result in a denial of service on the network.
Fix
From the vSphere Client, go to Networking >> select a distributed switch >> select a distributed port group >> Configure >> Settings >> Policies. Click "Edit". Under the VLAN section, change the VLAN ID to an unreserved VLAN ID and click "OK". or From a PowerCLI command prompt while connected to the vCenter server, run the following command: Get-VDPortgroup "portgroup name" | Set-VDVlanConfiguration -VlanId "New VLAN#"
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
VCTR-67-000031: The vCenter Server must restrict the connectivity between Update Manager and public patch repositories by use of a separate Update Manager Download Server.
Check the following conditions: 1. The Update Manager must be configured to use the Update Manager Download Server. 2. The use of physical media to transfer update files to the Update Manager server (air gap model example: separate Update Manager Download Server, which may source vendor patches externally via the internet versus an internal, organization-defined source) must be enforced with site policies. From the vSphere Client, click Update Manager >> Settings >> Administrative Settings >> Patch Setup and click the "Change Download Source" button. Verify that the "Download patches from a UMDS shared repository" radio button is selected and that a valid UMDS repository is supplied. If "Direct connection to Internet" is configured, this is a finding. If all of the above conditions are not met, this is a finding.
Discussion
The Update Manager Download Service (UMDS) is an optional module of the Update Manager. UMDS downloads upgrades for virtual appliances, patch metadata, patch binaries, and notifications that would not otherwise be available to the Update Manager server. For security reasons and deployment restrictions, the Update Manager must be installed in a secured network that is disconnected from the internet. The Update Manager requires access to patch information to function properly. UMDS must be installed on a separate system that has internet access to download upgrades, patch binaries, and patch metadata and then export the downloads to a portable media drive so they become accessible to the Update Manager server.
Fix
Configure the Update Manager Server to use a separate Update Manager Download Server; the use of physical media to transfer updated files to the Update Manager server (air gap model) must be enforced and documented with organization policies. Configure the Update Manager Download Server and enable the Download Service. Patches must not be directly accessible to the Update Manager Server application from the internet. To configure a web server or local disk repository as a download source (i.e., "Direct connection to Internet" must not be selected as the source), from the vSphere Client/vCenter Server system, click "Update Manager" under "Solutions and Applications". On the "Configuration" tab, under "Settings", click "Download Settings". In the "Download Sources" pane, select "Use a shared repository". Enter the <site-specific> path or the URL to the shared repository. Click "Validate URL" to validate the path. Click "Apply".
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
VCTR-67-000074: The vCenter Server Administrators must clean up log files after failed installations.
Note: For vCenter Server Appliance, this is not applicable. If at any time a vCenter Server installation fails, only the log files of format "hs_err_pid...." should be identified on the Windows host and deleted securely before putting the host into production. Determine if a site policy exists for handling failed installation cleanup of the Windows host prior to deployment. Using the Windows host search function, determine the existence of any log files of format "hs_err_pid". If a file name of the format "hs_err_pid" is found, this is a finding. If a site policy does not exist and/or is not followed, this is a finding.
Discussion
In certain cases, if the vCenter installation fails, a log file (with a name of the form “hs_err_pidXXXX”) is created that contains the database password in plain text. An attacker who breaks into the vCenter Server could potentially steal this password and access the vCenter Database.
Fix
Develop a site policy for handling failed installation cleanup of the Windows host prior to deployment. Using the Windows host search function, determine the existence of any log files of format "hs_err_pid" and remove them.
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
VCTR-67-000003: The vCenter Server must enforce a 60-day maximum password lifetime restriction.
From the vSphere Client, go to Administration >> Single Sign-On >> Configuration >> Policies >> Password Policy. View the value of the "Maximum lifetime" setting. If the "Maximum lifetime" policy is not set to "60", this is a finding.
Discussion
Any password, no matter how complex, can eventually be cracked. Therefore, passwords need to be changed at specific intervals. One method of minimizing this risk is to use complex passwords and periodically change them. If the application does not limit the lifetime of passwords and force users to change their passwords, there is the risk that the system and/or application passwords could be compromised. This requirement does not include emergency administration accounts, which are meant for access to the application in case of failure. These accounts are not required to have maximum password lifetime restrictions.
Fix
From the vSphere Client, go to Administration >> Single Sign-On >> Configuration >> Policies >> Password Policy. Click "Edit". Enter "60" into the "Maximum lifetime" setting and click "OK".
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
VCTR-67-000075: The vCenter Server must enable all tasks to be shown to Administrators in the Web Client.
Note: For vCenter Server Appliance, this is not applicable. Verify the "webclient.properties" file contains the line "show.allusers.tasks = true". On the vCenter Server locate the "webclient.properties" file in C:\ProgramData\VMware\vCenterServer\cfg\vsphere-client If "show.allusers.tasks" is not set to "true", this is a finding.
Discussion
By default not all tasks are shown in the web client to administrators and only that user's tasks will be shown. Enabling all tasks to be shown will allow the administrator to potentially see any malicious activity they may miss with the view disabled.
Fix
Edit the "webclient.properties" file to set the "show.allusers.tasks" value to "true". On the vCenter Server locate the "webclient.properties" file in C:\ProgramData\VMware\vCenterServer\cfg\vsphere-client After editing the file the vSphere Client service will need to be restarted.
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
VCTR-67-000035: vCenter Server plugins must be verified.
Verify the vSphere Client used by administrators includes only authorized extensions from trusted sources. From the vSphere Client, go to Administration >> Solutions >> Client Plug-Ins. View the Installed/Available Plug-ins list and verify they are all identified as authorized VMware, third-party (partner), and/or site-specific approved plug-ins. If any Installed/Available plug-ins in the viewable list cannot be verified as an allowed vSphere Client plug-ins from trusted sources, this is a finding.
Discussion
The vCenter Server includes a vSphere Client extensibility framework, which provides the ability to extend the vSphere Client with menu selections or toolbar icons that provide access to vCenter Server add-on components or external, web-based functionality. vSphere Client plugins or extensions run at the same privilege level as the user. Malicious extensions might masquerade as useful add-ons while compromising the system by stealing credentials or incorrectly configuring the system.
Fix
From the vSphere Client, go to Administration >> Solutions >> Client Plug-Ins. Click the radio button next to the unknown plug-in and click disable. Proceed to uninstall the plug-in. To remove plug-ins: If vCenter Server is in linked mode, perform this procedure on the vCenter Server that is used to install the plug-in initially and then restart the vCenter Server services on the linked vCenter Server. In a web browser, navigate to http://vCenter_Server_name_or_IP/mob. vCenter_Server_name_or_IP/mob is the name of the vCenter Server or its IP address. Click "Content". Click "ExtensionManager". Select and copy the name of the plug-in to be removed from the list of values under "Properties". Click "UnregisterExtension". A new window appears. Paste the name of the plug-in and click "Invoke Method". This removes the plug-in. Close the window. Refresh the "Managed Object Type:ManagedObjectReference:ExtensionManager" window to verify that the plug-in is removed successfully. Note: If the plug-in still appears, restart the vSphere Client. Note: Enable the Managed Object Browser (MOB) temporarily if it was previously disabled.
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
VCTR-67-000042: The vCenter Server passwords must contain at least one numeric character.
From the vSphere Client, go to Administration >> Single Sign-On >> Configuration >> Policies >> Password Policy. View the values of the password format requirements. The following password requirement should be set at a minimum: Numeric Characters: At least 1 If this password complexity policy is not configured as stated, this is a finding.
Discussion
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.
Fix
From the vSphere Client, go to Administration >> Single Sign-On >> Configuration >> Policies >> Password Policy. Click "Edit". Set "Numeric Characters" to at least "1" and click "OK".
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
VCTR-67-000004: The vCenter Server must terminate management sessions after 10 minutes of inactivity.
Note: For vCenter Server Windows, this is not applicable. On the vCenter Server, execute the following command: # grep "^session\.timeout" /etc/vmware/vsphere-client/webclient.properties Expected result: session.timeout = 10 If the output does not match the expected result, this is a finding.
Discussion
Terminating an idle session within a short time period reduces the window of opportunity for unauthorized personnel to take control of a management session enabled on the console or console port that has been left unattended. In addition, quickly terminating an idle session will also free up resources committed by the managed network element.
Fix
Navigate to and open /etc/vmware/vsphere-client/webclient.properties. Remove any existing "session.timeout" line and add the following: session.timeout = 10
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
VCTR-67-000070: The vCenter Server must not automatically refresh client sessions.
Note: For vCenter Server Appliance, this is not applicable. On the vCenter Server locate the "webclient.properties" file in C:\ProgramData\VMware\vCenterServer\cfg\vsphere-client Find the "refresh.rate =" line in the "webclient.properties" file. If the refresh rate is not set to "-1" in the "webclient.properties" file, this is a finding.
Discussion
Terminating an idle session within a short time period reduces the window of opportunity for unauthorized personnel to take control of a management session enabled on the console or console port that has been left unattended. In addition, quickly terminating an idle session will also free up resources committed by the managed network element. Automatic client session refreshes keep unused sessions online, blocking session timeouts.
Fix
Change the refresh rate value by editing the "webclient.properties" file. On the vCenter Server locate the "webclient.properties" file in C:\ProgramData\VMware\vCenterServer\cfg\vsphere-client Edit the file to include the line "refresh.rate = -1" where "-1" indicates sessions are not automatically refreshed. Uncomment the line if necessary. After editing the file the vSphere Client service must be restarted.
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
VCTR-67-000072: The vCenter Server services must be ran using a service account instead of a built-in Windows account.
Note: For vCenter Server Appliance, this is not applicable. The following services should be set to run as a service account: VMware Content Library Service VMware Inventory Service VMware Performance Charts VMware VirtualCenter Server vCenter should be installed using the service account as that will configure the services appropriately. If vCenter is not installed with a service account, this is a finding. If the services identified in this control are not running as a service account, this is a finding.
Discussion
You can use the Microsoft Windows built-in system account or a domain user account to run vCenter Server. The Microsoft Windows built-in system account has more permissions and rights on the server than the vCenter Server system requires, which can contribute to security problems. With a domain user account, you can enable Windows authentication for SQL Server; it also allows more granular security and logging. The installing account only needs to be a member of the Administrators group, and have permission to act as part of the operating system and log on as a service. If you are using SQL Server for the vCenter database, you must configure the SQL Server database to allow the domain account access to SQL Server.
Fix
For each of the following services open the services console on the vCenter server and right-click, select "Properties" on the service. Go to the "Log On" tab and configure the service to run as a service account and restart the service. VMware Content Library Service VMware Inventory Service VMware Performance Charts VMware VirtualCenter Server
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
VCTR-67-000039: The vCenter Server passwords must be at least 15 characters in length.
From the vSphere Client, go to Administration >> Single Sign-On >> Configuration >> Policies >> Password Policy. View the values of the password format requirements. The following password requirement should be set at a minimum: Minimum Length: 15 If this password policy is not configured as stated, this is a finding.
Discussion
The shorter the password, the lower the number of possible combinations that need to be tested before the password is compromised. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password length is one factor of several that helps to determine strength and how long it takes to crack a password. The shorter the password, the lower the number of possible combinations that need to be tested before the password is compromised. Use of more characters in a password helps to exponentially increase the time and/or resources required to compromise the password.
Fix
From the vSphere Client, go to Administration >> Single Sign-On >> Configuration >> Policies >> Password Policy. Click "Edit". Set the Minimum Length to "15" and click "OK".
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
VCTR-67-000058: The vCenter Server Machine SSL certificate must be issued by a DoD certificate authority.
From the vSphere Client, go to Administration >> Certificates >> Certificate Management >> Machine SSL Certificate. Click "View Details". Examine the "Issuer Information" block. If the issuer specified is not a DoD-approved certificate authority (or other AO approved CA), this is a finding.
Discussion
The default self-signed, VMCA-issued vCenter reverse proxy certificate must be replaced with a DoD-approved certificate. The use of a DoD certificate on the vCenter reverse proxy assures clients that the service they are connecting to is legitimate and properly secured.
Fix
Obtain a DoD-issued certificate and private key for each vCenter in the system, following these requirements: Key size: 2048 bits or more (PEM encoded) CRT format (Base-64) x509 version 3 SubjectAltName must contain DNS Name=<machine_FQDN> Contains the following Key Usages: Digital Signature, Non Repudiation, Key Encipherment Ensure that the certificate includes all intermediates and root certificates. If it does not, export the entire certificate issuing chain up to the root in Base-64 format and concatenate the individual certificates onto the issued certificate. From the vSphere Client, go to Administration >> Certificates >> Certificate Management >> Machine SSL Certificate. Click Actions >> Replace. Supply the CA-issued certificate with the exported roots file and the private key. Click "Replace".
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
VCTR-67-000016: The vCenter Server must only send NetFlow traffic to authorized collectors.
If distributed switches are not used, this is not applicable. To view NetFlow Collector IPs configured on distributed switches: From the vSphere Client, go to Networking >> select a distributed switch >> Configure >> Settings >> NetFlow. View the NetFlow pane and verify that any collector IP addresses are valid and in use for troubleshooting. or From a PowerCLI command prompt while connected to the vCenter server, run the following command: Get-VDSwitch | select Name,@{N="NetFlowCollectorIPs";E={$_.ExtensionData.config.IpfixConfig.CollectorIpAddress}} To view if NetFlow is enabled on any distributed port groups: From the vSphere Client, go to Networking >> select a distributed port group >> Manage >> Settings >> Policies. Go to Monitoring and view the NetFlow status. or From a PowerCLI command prompt while connected to the vCenter server, run the following command: Get-VDPortgroup | select Name,VirtualSwitch,@{N="NetFlowEnabled";E={$_.Extensiondata.Config.defaultPortConfig.ipfixEnabled.Value}} If NetFlow is configured and the collector IP is not known and documented, this is a finding.
Discussion
The distributed virtual switch can export NetFlow information about traffic crossing the switch. NetFlow exports are not encrypted and can contain information about the virtual network, making it easier for a MitM attack to be executed successfully. If NetFlow export is required, verify that all NetFlow target IPs are correct.
Fix
To remove collector IPs: From the vSphere Client, go to Networking >> select a distributed switch >> Configure >> Settings >> NetFlow. Click "Edit" and remove any unknown collector IPs. or From a PowerCLI command prompt while connected to the vCenter server, run the following commands: $dvs = Get-VDSwitch dvswitch | Get-View ForEach($vs in $dvs){ $spec = New-Object VMware.Vim.VMwareDVSConfigSpec $spec.configversion = $vs.Config.ConfigVersion $spec.IpfixConfig = New-Object VMware.Vim.VMwareIpfixConfig $spec.IpfixConfig.CollectorIpAddress = "" $spec.IpfixConfig.CollectorPort = "0" $spec.IpfixConfig.ActiveFlowTimeout = "60" $spec.IpfixConfig.IdleFlowTimeout = "15" $spec.IpfixConfig.SamplingRate = "0" $spec.IpfixConfig.InternalFlowsOnly = $False $vs.ReconfigureDvs_Task($spec) } Note: This will reset the NetFlow collector configuration back to the defaults. To disable NetFlow on a distributed port group: From the vSphere Client, go to Networking >> select a distributed port group >> Manage >> Settings >> Policies. Go to "Monitoring" and change "NetFlow" to disabled. or From a PowerCLI command prompt while connected to the vCenter server, run the following commands: $pgs = Get-VDPortgroup | Get-View ForEach($pg in $pgs){ $spec = New-Object VMware.Vim.DVPortgroupConfigSpec $spec.configversion = $pg.Config.ConfigVersion $spec.defaultPortConfig = New-Object VMware.Vim.VMwareDVSPortSetting $spec.defaultPortConfig.ipfixEnabled = New-Object VMware.Vim.BoolPolicy $spec.defaultPortConfig.ipfixEnabled.inherited = $false $spec.defaultPortConfig.ipfixEnabled.value = $false $pg.ReconfigureDVPortgroup_Task($spec) }
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
VCTR-67-000033: The vCenter Server must use a least-privileges assignment for the vCenter Server database user.
Note: For vCenter Server Appliance, this is not applicable. Verify that only the following permissions are allowed on the vCenter database for the following roles and users. vCenter database administrator role used only for initial setup and periodic maintenance of the database: Schema permissions: ALTER, REFERENCES, and INSERT. Permissions CREATE TABLE, CREATE VIEW, and CREATE PROCEDURE vCenter database user role: Schema permissions: SELECT, INSERT, DELETE, UPDATE, and EXECUTE EXECUTE permissions on sp_add_job, sp_delete_job, sp_add_jobstep, sp_update_job, sp_add_jobserver, sp_add_jobschedule, and sp_add_category stored procedures. SELECT permission on syscategories, sysjobsteps, sysjobs_view, and sysjobs tables. vCenter database user: VIEW SERVER STATE and VIEW ANY DEFINITIONS. Equivalent permissions must be set for non-MSSQL databases. If the above database permissions are not set correctly, this is a finding. If the database user role is not assigned to the database account after installation, this is a finding. If the embedded Postgres database is used, this finding is not applicable. For more information, refer to the following website: https://docs.vmware.com/en/VMware-vSphere/6.7/com.vmware.vcenter.install.doc/GUID-66638880-75B5-446E-BD8C-0230FECF60E0.html
Discussion
Least privileges mitigate attacks if the vCenter database account is compromised. vCenter requires very specific privileges on the database. Privileges normally required only for installation and upgrade must be removed for/during normal operation. These privileges may be reinstated if/when any future upgrade must be performed.
Fix
Configure correct permissions and roles for SQL: Grant these privileges to a vCenter database administrator role used only for initial setup and periodic maintenance of the database: Schema permissions ALTER, REFERENCES, and INSERT. Permissions CREATE TABLE, VIEW, and CREATE PROCEDURES Grant these privileges to a vCenter database user role: SELECT, INSERT, DELETE, UPDATE, and EXECUTE EXECUTE permissions on sp_add_job, sp_delete_job, sp_add_jobstep, sp_update_job, sp_add_jobserver, sp_add_jobschedule, and sp_add_category stored procedures. SELECT permission on syscategories, sysjobsteps, sysjobs_view, and sysjobs tables. Grant the permissions VIEW SERVER STATE and VIEW ANY DEFINITIONS to the vCenter database user. For more information, refer to the following website: https://docs.vmware.com/en/VMware-vSphere/6.7/com.vmware.vcenter.install.doc/GUID-66638880-75B5-446E-BD8C-0230FECF60E0.html
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
VCTR-67-000057: The vCenter Server must enable TLS 1.2 exclusively.
Note: For vCenter Server Windows, this is not applicable. On the vCenter Server, execute the following command: # $(find /usr/lib -name reconfigureVc) scan If the output indicates versions of TLS other than 1.2 are enabled, this is a finding.
Discussion
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 TLS 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 Controls (if applicable), 2. vCenter, 3. ESXi
Fix
On the vCenter Server, execute the following commands: # $(find /usr/lib -name reconfigureVc) backup # $(find /usr/lib -name reconfigureVc) update -p TLS1.2 vCenter services will be restarted as part of the reconfiguration, the OS will not be restarted. You can add the --no-restart flag to restart services at a later time. Changes will not take effect until all services are restarted or the machine is rebooted.
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
VCTR-67-000045: The vCenter Server must limit the maximum number of failed login attempts to three.
From the vSphere Client, go to Administration >> Single Sign-On >> Configuration >> Policies >> Lockout Policy. View the values for the lockout policies. The following lockout policy should be set at follows: Maximum number of failed login attempts: 3 If this account lockout policy is not configured as stated, this is a finding.
Discussion
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.
Fix
From the vSphere Client, go to Administration >> Single Sign-On >> Configuration >> Policies >> Lockout Policy. Click "Edit". Set the "Maximum number of failed login attempts" to "3" and click "OK".
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
VCTR-67-000015: The vCenter Server must set the distributed port group Promiscuous Mode policy to reject.
If distributed switches are not used, this is not applicable. From the vSphere Client, go to Networking >> select a distributed switch >> select a port group >> Configure >> Settings >> Policies. Verify "Promiscuous Mode" is set to reject. or From a PowerCLI command prompt while connected to the vCenter server, run the following commands: Get-VDSwitch | Get-VDSecurityPolicy Get-VDPortgroup | ?{$_.IsUplink -eq $false} | Get-VDSecurityPolicy If the "Promiscuous Mode" policy is set to accept, this is a finding.
Discussion
When promiscuous mode is enabled for a virtual switch, all virtual machines connected to the port group have the potential of reading all packets across that network, meaning only the virtual machines connected to that port group. Promiscuous mode is disabled by default on the ESXi Server, and this is the recommended setting.
Fix
From the vSphere Client, go to Networking >> select a distributed switch >> select a port group >> Configure >> Settings >> Policies >> Edit >> Security. Set "Promiscuous Mode" to reject. Click "OK". or From a PowerCLI command prompt while connected to the vCenter server, run the following commands: Get-VDSwitch | Get-VDSecurityPolicy | Set-VDSecurityPolicy -AllowPromiscuous $false Get-VDPortgroup | ?{$_.IsUplink -eq $false} | Get-VDSecurityPolicy | Set-VDSecurityPolicy -AllowPromiscuous $false
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
VCTR-67-000013: The vCenter Server must set the distributed port group Forged Transmits policy to reject.
If distributed switches are not used, this is not applicable. From the vSphere Client, go to Networking >> select a distributed switch >> select a port group >> Configure >> Settings >> Policies. Verify "Forged Transmits" is set to reject. or From a PowerCLI command prompt while connected to the vCenter server, run the following commands: Get-VDSwitch | Get-VDSecurityPolicy Get-VDPortgroup | ?{$_.IsUplink -eq $false} | Get-VDSecurityPolicy If the "Forged Transmits" policy is set to accept for a non-uplink port, this is a finding.
Discussion
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. When the Forged transmits option is set to "Accept", ESXi does not compare source and effective MAC addresses. To protect against MAC impersonation, set the Forged transmits option to "Reject". The host will compare the source MAC address being transmitted by the guest operating system with the effective MAC address for its virtual machine adapter to determine if they match. If the addresses do not match, the ESXi host drops the packet.
Fix
From the vSphere Client, go to Networking >> select a distributed switch >> select a port group >> Configure >> Settings >> Policies >> Edit >> Security. Set "Forged Transmits" to reject. Click "OK". or From a PowerCLI command prompt while connected to the vCenter server, run the following commands: Get-VDSwitch | Get-VDSecurityPolicy | Set-VDSecurityPolicy -ForgedTransmits $false Get-VDPortgroup | ?{$_.IsUplink -eq $false} | Get-VDSecurityPolicy | Set-VDSecurityPolicy -ForgedTransmits $false
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
VCTR-67-000029: The vCenter Server must enable all tasks to be shown to Administrators in the Web Client.
Note: For vCenter Server Windows, this is not applicable. On the vCenter Server, execute the following command: # grep "^show\.allusers\.tasks" /etc/vmware/vsphere-client/webclient.properties Expected result: show.allusers.tasks = true If the output does not match the expected result, this is a finding.
Discussion
By default, not all tasks are shown in the Web Client to Administrators, and only that user's tasks will be shown. Enabling all tasks to be shown will allow the Administrator to potentially see any malicious activity they may miss with the view disabled.
Fix
Navigate to and open /etc/vmware/vsphere-client/webclient.properties. Remove any existing "show.allusers.tasks" line and add the following: show.allusers.tasks = true
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
VCTR-67-000065: The vCenter Server must have Mutual CHAP configured for vSAN iSCSI targets.
If no clusters are enabled for vSAN or if vSAN is enabled but iSCSI is not enabled, this is not applicable. From the vSphere Client, go to Hosts and Clusters >> select a vSAN Enabled Cluster >> Configure >> vSAN >> iSCSI Target Service. For each iSCSI target, review the value in the "Authentication" column. If the Authentication method is not set to "CHAP_Mutual" for any iSCSI target, this is a finding.
Discussion
When Mutual CHAP is 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.
Fix
From the vSphere Client, go to Hosts and Clusters >> select a vSAN Enabled Cluster >> Configure >> vSAN >> iSCSI Target Service. For each iSCSI target, select the item and click "Edit". Change the "Authentication" field to "Mutual CHAP" and configure the incoming and outgoing users and secrets appropriately.
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
VCTR-67-000019: The vCenter Server must not configure VLAN Trunking unless Virtual Guest Tagging (VGT) is required and authorized.
If distributed switches are not used, this is not applicable. From the vSphere Client, go to Networking >> select a distributed switch >> select a distributed port group >> Configure >> Settings >> Policies. Review the port group "VLAN Type" and "VLAN trunk range", if present. or From a PowerCLI command prompt while connected to the vCenter server, run the following command: Get-VDPortgroup | Where {$_.ExtensionData.Config.Uplink -ne "True"} | select Name,VlanConfiguration If any port group is configured with "VLAN Trunk" and is not documented as a needed exception (such as NSX appliances), this is a finding. If any port group is authorized to be configured with "VLAN trunking" but is not configured with the most limited range necessary, this is a finding.
Discussion
When a port group is set to VLAN Trunking, the vSwitch passes all network frames in the specified range to the attached VMs without modifying the VLAN tags. In vSphere, this is referred to as Virtual Guest Tagging (VGT). The VM must process the VLAN information itself via an 802.1Q driver in the OS. VLAN Trunking must only be implemented if the attached VMs have been specifically authorized and are capable of managing VLAN tags themselves. If VLAN Trunking is enabled inappropriately, it may cause denial of service or allow a VM to interact with traffic on an unauthorized VLAN.
Fix
From the vSphere Client, go to Networking >> select a distributed switch >> select a distributed port group >> Configure >> Settings >> Policies. Click "Edit". Click the "VLAN" tab. If "VLAN trunking" is not authorized, remove it by setting "VLAN type" to "VLAN" and configure an appropriate VLAN ID. Click "OK". If "VLAN trunking" is authorized but the range is too broad, modify the range in the "VLAN trunk range" field to the minimum necessary and authorized range. An example range would be "1,3-5,8". Click "OK". or From a PowerCLI command prompt while connected to the vCenter server, run the following command to configure trunking: Get-VDPortgroup "Portgroup Name" | Set-VDVlanConfiguration -VlanTrunkRange "<VLAN Range(s) comma separated>" or Run this command to configure a single VLAN ID: Get-VDPortgroup "Portgroup Name" | Set-VDVlanConfiguration -VlanId "<New VLAN#>"
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
VCTR-67-000052: The vCenter Server must protect the confidentiality and integrity of transmitted information by isolating IP-based storage traffic.
If IP-based storage is not used, this is not applicable. IP-based storage (iSCSI, NFS, vSAN) VMkernel port groups must be in a dedicated VLAN that can be on a standard or distributed virtual switch that is logically separated from other traffic types. The check for this will be unique per environment. To check a standard switch, from the vSphere Client select the ESXi host and go to Configure >> Networking >> Virtual switches. Select a standard switch. For each storage port group (iSCSI, NFS, vSAN), select the port group and click the "Details" button. Note the VLAN ID associated with each port group and verify that it is dedicated to that purpose and is logically separated from other traffic types. To check a distributed switch, from the vSphere Client go to Networking >> select and expand a distributed switch. For each storage port group (iSCSI, NFS, vSAN), select the port group and navigate to the "Summary" tab. Note the VLAN ID associated with each port group and verify that it is dedicated to that purpose and is logically separated from other traffic types. If any IP-based storage networks are not isolated from other traffic types, this is a finding.
Discussion
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.
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 Client, select the ESXi host and go to Configure >> Networking >> VMkernel adapters. Select the Storage VMkernel (for any IP-based storage) and click the "Edit" button. On the Port properties tab, uncheck everything (unless vSAN). On the IP Settings tab, enter the appropriate IP address and subnet information and click "OK". To configure a standard switch, from the vSphere Client, select the ESXi host and go to Configure >> Networking >> Virtual switches. Select a standard switch. For each storage port group (iSCSI, NFS, vSAN), select the port group and click the "Edit" button. On the properties page, enter the appropriate VLAN ID and click "OK". To configure a distributed switch, from the vSphere Client, go to Networking. Select and expand a distributed switch. For each storage port group (iSCSI, NFS, vSAN), select the port group and navigate to Configure >> Settings >> Properties. Click the "Edit" button. On the VLAN page, enter the appropriate VLAN type and ID and click "OK".
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
VCTR-67-000018: The vCenter Server must configure all port groups to a value other than that of the native VLAN.
If distributed switches are not used, this is not applicable. From the vSphere Client, go to Networking >> select a distributed switch >> select a distributed port group >> Configure >> Settings >> Policies. 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 vCenter server, run the following command: Get-VDPortgroup | select Name, VlanConfiguration If any port group is configured with the native VLAN of the ESXi host's attached physical switch, this is a finding.
Discussion
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.
Fix
From the vSphere Client, go to Networking >> select a distributed switch >> select a distributed port group >> Configure >> Settings >> Policies. Click "Edit". Under the VLAN section, change the VLAN ID to a non-native VLAN and click "OK". or From a PowerCLI command prompt while connected to the vCenter server, run the following command: Get-VDPortgroup "portgroup name" | Set-VDVlanConfiguration -VlanId "New VLAN#"
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
VCTR-67-000055: The vCenter Server must configure the vSAN Datastore name to a unique name.
If no clusters are enabled for vSAN, this is not applicable. From the vSphere Client, go to Hosts and Clusters >> select a vSAN Enabled Cluster >> Datastores. Review the datastores. Identify any datastores with "vSAN" as the datastore type. or From a PowerCLI command prompt while connected to the vCenter server, run the following command: If($(Get-Cluster | where {$_.VsanEnabled} | Measure).Count -gt 0){ Write-Host "vSAN Enabled Cluster found" Get-Cluster | where {$_.VsanEnabled} | Get-Datastore | where {$_.type -match "vsan"} } else{ Write-Host "vSAN is not enabled, this finding is not applicable" } If vSAN is enabled and the datastore is named "vsanDatastore", this is a finding.
Discussion
A vSAN Datastore name by default is "vsanDatastore". If more than one vSAN cluster is present in vCenter, both datastores will have the same name by default, potentially leading to confusion and manually misplaced workloads.
Fix
From the vSphere Client, go to Hosts and Clusters >> select a vSAN Enabled Cluster >> Datastores. Right-click on the datastore named "vsanDatastore" and select "Rename". Rename the datastore based on site-specific naming standards. or From a PowerCLI command prompt while connected to the vCenter server, run the following command: If($(Get-Cluster | where {$_.VsanEnabled} | Measure).Count -gt 0){ Write-Host "vSAN Enabled Cluster found" $Clusters = Get-Cluster | where {$_.VsanEnabled} Foreach ($clus in $clusters){ $clus | Get-Datastore | where {$_.type -match "vsan"} | Set-Datastore -Name $(($clus.name) + "_vSAN_Datastore") } } else{ Write-Host "vSAN is not enabled, this finding is not applicable" }
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
VCTR-67-000024: The vCenter Server must configure the vpxuser password meets length policy.
From the vSphere Client, go to Hosts and Clusters >> select a vCenter Server >> Configure >> Settings >> Advanced Settings. Verify that "config.vpxd.hostPasswordLength" is set to "32". or From a PowerCLI command prompt while connected to the vCenter server, run the following command: Get-AdvancedSetting -Entity <vcenter server name> -Name config.vpxd.hostPasswordLength Verify it is set to "32". If the "config.vpxd.hostPasswordLength" is set to a value other than "32", this is a finding. If the setting does not exist, this is not a finding.
Discussion
The vpxuser password default length is 32 characters. Ensure this setting meets site policies; if not, configure to meet password length policies. Longer passwords make brute-force password attacks more difficult. The vpxuser password is added by vCenter, meaning no manual intervention is normally required. The vpxuser password length must never be modified to less than the default length of 32 characters.
Fix
From the vSphere Client, go to Hosts and Clusters >> select a vCenter Server >> Configure >> Settings >> Advanced Settings. Click "Edit Settings" and configure the "config.vpxd.hostPasswordLength" value to "32". or From a PowerCLI command prompt while connected to the vCenter server run the following command if the setting already exists: Get-AdvancedSetting -Entity <vcenter server name> -Name config.vpxd.hostPasswordLength | Set-AdvancedSetting -Value 32
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
VCTR-67-000002: The vCenter Server must not automatically refresh client sessions.
Note: For vCenter Server Windows, this is not applicable. On the vCenter Server, execute the following command: # grep "^refresh\.rate" /etc/vmware/vsphere-client/webclient.properties Expected result: refresh.rate = -1 If the output does not match the expected result, this is a finding.
Discussion
Terminating an idle session within a short time period reduces the window of opportunity for unauthorized personnel to take control of a management session enabled on the console or console port that has been left unattended. In addition, quickly terminating an idle session will also free up resources committed by the managed network element. Automatic client session refreshes keep unused sessions online, blocking session timeouts.
Fix
Navigate to and open /etc/vmware/vsphere-ui/webclient.properties. Remove any existing "refresh.rate" line and add the following: refresh.rate = -1 After editing the file, the vSphere Client service must be restarted. # service-control --restart vsphere-client
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
VCTR-67-000026: The vCenter Server must check the privilege reassignment after restarts.
Note: For vCenter Server Appliance, this is not applicable. After the Windows server hosting the vCenter Server has been rebooted, a vCenter Server user or member of the user group granted the Administrator role must log in and verify the role permissions remain intact. If the user and/or user group granted vCenter Administrator role permissions cannot be verified as intact, this is a finding.
Discussion
Check for privilege reassignment when restarting vCenter Server. If the user or user group that is assigned the Administrator role on the root folder cannot be verified as a valid user or group during a restart, the role is removed from that user or group. In its place, vCenter Server grants the Administrator role to the vCenter Single Sign-On account [email protected]. This account can then act as the Administrator. Reestablish a named Administrator account and assign the Administrator role to that account to avoid using the anonymous [email protected] account.
Fix
As the SSO Administrator, log in to the vCenter Server and restore a legitimate Administrator account per site-specific user/group/role requirements.
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
VCTR-67-000012: The vCenter Server must disable the distributed virtual switch health check.
If distributed switches are not used, this is not applicable. From the vSphere Client, go to Networking >> select a distributed switch >> Configure >> Settings >> Health Check. View the health check pane and verify that the "VLAN and MTU" and "Teaming and failover" checks are disabled. or From a PowerCLI command prompt while connected to the vCenter server, run the following commands: $vds = Get-VDSwitch $vds.ExtensionData.Config.HealthCheckConfig If the health check feature is enabled on distributed switches and is not on temporarily for troubleshooting purposes, this is a finding.
Discussion
Network Healthcheck is disabled by default. Once enabled, the healthcheck packets contain information on host#, vds#, and port#, which an attacker would find useful. It is recommended that network healthcheck be used for troubleshooting and turned off when troubleshooting is finished.
Fix
From the vSphere Client, go to Networking >> select a distributed switch >> Configure >> Settings >> Health Check. Click "Edit" and disable the "VLAN and MTU" and "Teaming and failover" checks. or From a PowerCLI command prompt while connected to the vCenter server, run the following command: Get-View -ViewType DistributedVirtualSwitch | ?{($_.config.HealthCheckConfig | ?{$_.enable -notmatch "False"})}| %{$_.UpdateDVSHealthCheckConfig(@((New-Object Vmware.Vim.VMwareDVSVlanMtuHealthCheckConfig -property @{enable=0}),(New-Object Vmware.Vim.VMwareDVSTeamingHealthCheckConfig -property @{enable=0})))}
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
VCTR-67-000061: The vCenter Server must disable Password and Windows integrated authentication.
Note: For vCenter Server Windows, this is not applicable. From the vSphere Client go to Administration >> Single Sign-On >> Configuration >> Smart Card Authentication. If "Smart card authentication" is not enabled and "Password and windows session authentication" is not disabled, this is a finding.
Discussion
All forms of authentication other than CAC must be disabled. Password authentication can be temporarily re-enabled for emergency access to the local SSO domain accounts but it must be disable as soon as CAC authentication is functional.
Fix
From the vSphere Client go to Administration >> Single Sign-On >> Configuration >> Smart Card Authentication. Next to "Authentication methods", click "Edit". Click the "Enable smart card authentication" radio button and click "Save". To re-enable password authentication for troubleshooting purposes, run the following command on the vCenter server: /opt/vmware/bin/sso-config.sh -set_authn_policy -pwdAuthn true -winAuthn false -certAuthn false -securIDAuthn false -t vsphere.local
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
VCTR-67-000067: The vCenter Server must disable the Customer Experience Improvement Program (CEIP).
From the vSphere Client, go to Administration >> Deployment >> Customer Experience Improvement Program. If Customer Experience Improvement "Program Status" is "Joined", this is a finding.
Discussion
The VMware CEIP sends VMware anonymized system information that is used to improve the quality, reliability, and functionality of VMware products and services. For confidentiality purposes, this feature must be disabled.
Fix
From the vSphere Client, go to Administration >> Deployment >> Customer Experience Improvement Program. Click the "Leave" button.
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
VCTR-67-000034: The vCenter Server must use unique service accounts when applications connect to vCenter.
Verify that each external application that connects to vCenter has a unique service account dedicated to that application. For example, there should be separate accounts for Log Insight, Operations Manager, or anything else that requires an account to access vCenter. If any application shares a service account that is used to connect to vCenter, this is a finding.
Discussion
In order to not violate non-repudiation (i.e., deny the authenticity of who is connecting to vCenter), when applications need to connect to vCenter they must use unique service accounts.
Fix
For applications sharing service accounts, create a new service account to assign to the application so that no application shares a service account with another. When standing up a new application that requires access to vCenter, always create a new service account prior to installation and grant only the permissions needed for that application.
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
VCTR-67-000036: The vCenter Server must produce audit records containing information to establish what type of events occurred.
From the vSphere Client, go to Hosts and Clusters >> select a vCenter Server >> Configure >> Settings >> Advanced Settings. Verify that "config.log.level" value is set to "info". or From a PowerCLI command prompt while connected to the vCenter server, run the following command: Get-AdvancedSetting -Entity <vcenter server name> -Name config.log.level Verify it is set to "info". If the "config.log.level" value is not set to "info" or does not exist, this is a finding.
Discussion
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.
Fix
From the vSphere Client, go to Hosts and Clusters >> select a vCenter Server >> Configure >> Settings >> Advanced Settings. Click "Edit Settings" and configure the "config.log.level" setting to "info". or From a PowerCLI command prompt while connected to the vCenter server, run the following command: Get-AdvancedSetting -Entity <vcenter server name> -Name config.log.level | Set-AdvancedSetting -Value info
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
VCTR-67-000008: The vCenter Server must provide an immediate real-time alert to the SA and ISSO, at a minimum, of all audit failure events.
From the vSphere Client, go to Hosts and Clusters >> select a vCenter Server >> Configure >> More >> Alarm Definitions. Verify there is an alarm created to alert if an ESXi host can no longer reach its syslog server. The alarm definition will have a rule for the "Remote logging host has become unreachable" event. or From a PowerCLI command prompt while connected to the vCenter server, run the following command: Get-AlarmDefinition | Where {$_.ExtensionData.Info.Expression.Expression.EventTypeId -eq "esx.problem.vmsyslogd.remote.failure"} | Select Name,Enabled,@{N="EventTypeId";E={$_.ExtensionData.Info.Expression.Expression.EventTypeId}} If an alarm is not created and enabled to alert when syslog failures occur, this is a finding.
Discussion
It is critical for the appropriate personnel to be aware if an ESXi host is at risk of failing to process audit logs as required. Without a real-time alert, security personnel may be unaware of an impending failure of the audit capability, and system operation may be adversely affected. To ensure the appropriate personnel are alerted if an audit failure occurs, a vCenter alarm can be created to trigger when an ESXi host can no longer reach its syslog server.
Fix
From the vSphere Client, go to Hosts and Clusters >> select a vCenter Server >> Configure >> More >> Alarm Definitions. Click "Add". Provide an alarm name and description. Select "Hosts" from the "Target type" dropdown menu. Click "Next". Paste "esx.problem.vmsyslogd.remote.failure" in the line after IF and press "Enter". Select "Show as Warning" for severity. Click "Next". Configure any other options as desired, enable alarm, and finish. Note: This alarm will only trigger if syslog is configured for TCP or SSL connections and not UDP.
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
VCTR-67-000064: The vCenter Server must restrict access to cryptographic permissions.
From the vSphere Client, go to Administration >> Access Control >> Roles. Highlight each role and click the "Privileges" button in the right pane. Verify that only the Administrator and any site-specific cryptographic group(s) have the following permissions: Cryptographic Operations privileges Global.Diagnostics Host.Inventory.Add host to cluster Host.Inventory.Add standalone host Host.Local operations.Manage user groups or From a PowerCLI command prompt while connected to the vCenter server, run the following command: $roles = Get-VIRole ForEach($role in $roles){ $privileges = $role.PrivilegeList If($privileges -match "Crypto*" -or $privileges -match "Global.Diagnostics" -or $privileges -match "Host.Inventory.Add*" -or $privileges -match "Host.Local operations.Manage user groups"){ Write-Host "$role has Cryptographic privileges" } } If any role other than Administrator and any site-specific group(s) have any of these permissions, this is a finding.
Discussion
These permissions must be reserved for cryptographic administrators where VM encryption and/or vSAN encryption is in use. Catastrophic data loss can result from poorly administered cryptography.
Fix
From the vSphere Client, go to Administration >> Access Control >> Roles. Highlight each role and click the pencil button if it is enabled. Remove the following permissions from any group other than Administrator and any site-specific cryptographic group(s): Cryptographic Operations privileges Global.Diagnostics Host.Inventory.Add host to cluster Host.Inventory.Add standalone host Host.Local operations.Manage user groups
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
VCTR-67-000009: The vCenter Server must implement Active Directory authentication.
From the vSphere Web Client, go to Administration >> Single Sign-On >> Configuration. Click the "Identity Sources" tab. If there is no identity source of type "Active Directory" (either Windows Integrated Authentication or LDAP), this is a finding.
Discussion
The vCenter Server must ensure users are authenticated with an individual authenticator prior to using a group authenticator. Using Active Directory for authentication provides more robust account management capabilities.
Fix
From the vSphere Web Client go to Administration >> Single Sign-On >> Configuration. Click the "Add identity source". Select either "Active Directory over LDAP" or "Active Directory (Windows Integrated Authentication)" and configure appropriately. Note: Windows Integrated Authentication requires that the vCenter server be joined to AD before configuration via Administration >> Single Sign-On >> Configuration >> Active Directory Domain.
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
VCTR-67-000073: The vCenter Server must minimize access to the vCenter server.
Note: For vCenter Server Appliance, this is not applicable. Login to the vCenter server and verify the only local administrators group contains users and/or groups that contain vCenter Administrators. If the local administrators group contains users and/or groups that are not vCenter Administrators such as "Domain Admins", this is a finding.
Discussion
After someone has logged in to the vCenter Server system, it becomes more difficult to prevent what they can do. In general, logging in to the vCenter Server system should be limited to very privileged administrators, and then only for the purpose of administering vCenter Server or the host OS. Anyone logged in to the vCenter Server can potentially cause harm, either intentionally or unintentionally, by altering settings and modifying processes. They also have potential access to vCenter credentials, such as the SSL certificate.
Fix
Remove all unnecessary users and/or groups from the local administrators group of the vCenter server.
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None
VCTR-67-000046: The vCenter Server must set the interval for counting failed login attempts to at least 15 minutes.
From the vSphere Client, go to Administration >> Single Sign-On >> Configuration >> Policies >> Lockout Policy. View the values for the lockout policies. The following lockout policy should be set at follows: Time interval between failures: 900 seconds If this lockout policy is not configured as stated, this is a finding.
Discussion
By limiting the number of failed login attempts within a specified time period, the risk of unauthorized access via user password guessing, otherwise known as brute forcing, is reduced. Limits are imposed by locking the account.
Fix
From the vSphere Client go to Administration >> Single Sign-On >> Configuration >> Policies >> Lockout Policy. Click "Edit". Set the "Time interval between failures" to "900" and click "OK".
Rating Info
DISA Cat II. NIST impact 3.
Expert Comment
None