Select any two versions of this STIG to compare the individual requirements
Select any old version/release of this STIG to view the previous requirements
Temporarily disable Lockdown Mode and enable the ESXi Shell via the vSphere Client. Open the vSphere/VMware Infrastructure (VI) Client and log in with appropriate credentials. If connecting to vCenter Server, click on the desired host. Click the Configuration tab. Click Software, Security Profile, Services, Properties, ESXi Shell and Options, respectively. Start the ESXi Shell service, where/as required. As root, log in to the host and verify the expected settings are configured in the /etc/pam.d/passwd file. The entry format is : "password requisite /lib/security/pam_passwdqc.so similar=deny retry=N min=N0,N1,N2,N3,N4" The "N2" field controls the behavior enforcing "no dictionary words". This flag should be set to "disabled". # grep "^password" /etc/pam.d/passwd | grep requisite | grep "min=" If the "N2" password complexity field is not set to "disabled", this is a finding. Re-enable Lockdown Mode on the host.
Temporarily disable Lockdown Mode and enable the ESXi Shell via the vSphere Client. Open the vSphere/VMware Infrastructure (VI) Client and log in with appropriate credentials. If connecting to vCenter Server, click on the desired host. Click the Configuration tab. Click Software, Security Profile, Services, Properties, ESXi Shell and Options, respectively. Start the ESXi Shell service, where/as required. As root, log in to the host and ensure the expected settings of the "min" keyword are configured in the /etc/pam.d/passwd file. # vi /etc/pam.d/passwd Set the "N2" password complexity field to "disabled", i.e., min=disabled,disabled,disabled,disabled,14 Re-enable Lockdown Mode on the host.
Disable lock down mode. Enable the ESXi Shell. Login as root and check the snmp configuration file for default(s): # egrep -i "community|communities" /etc/vmware/snmp.xml If any community name or password is set to a default value such as public, private or password, this is a finding. Re-enable lock down mode.
From the Power/v CLI, run the (below example) command: > # vicfg-snmp.pl --server <hostname|IP address> --username <username> --password <password> -E -c <community_name> In the above example, -E enables the VMware SNMP agent, and -c sets communities to the provided name.
Disable lock down mode. Enable the ESXi Shell. Check the SSH daemon configuration for the TCP connection forwarding setting. # grep -i AllowTCPForwarding /etc/ssh/sshd_config | grep -v '^#' If "AllowTCPForwarding" is set to "yes", this is a finding. Re-enable lock down mode.
Disable lock down mode. Enable the ESXi Shell. Edit the SSH daemon configuration and add/modify the "AllowTCPForwarding" configuration setting it to "no". # vi /etc/ssh/sshd_config Re-enable lock down mode.
Disable lock down mode. Enable the ESXi Shell. Execute the following command(s): # grep Forward /etc/ssh/ssh_config Re-enable lock down mode. If any of the following attributes (ForwardAgent, ForwardX11, or ForwardX11Trusted) exist and are not set to "no", this is a finding. If the /etc/ssh/ssh_config file does not exist, this is not a finding.
Disable lock down mode. Enable the ESXi Shell. Execute the following command(s): # vi /etc/ssh/ssh_config Add/modify the attribute line entry to the following (quotes for emphasis only): "ForwardAgent no" "ForwardX11 no" "ForwardX11Trusted no" Re-enable lock down mode.
Disable lock down mode. Enable the ESXi Shell. Execute the following command(s): # grep -i GatewayPorts /etc/ssh/sshd_config If "GatewayPorts" is not set to "no", this is a finding. Re-enable lock down mode.
Disable lock down mode. Enable the ESXi Shell. Execute the following command(s): # vi /etc/ssh/sshd_config Add/modify the attribute line entry to the following (quotes for emphasis only): "GatewayPorts no" Re-enable lock down mode.
Disable lock down mode. Enable the ESXi Shell. Check the SSH client configuration for the gateway ports setting. # grep -i GatewayPorts /etc/ssh/ssh_config | grep -v '^#' If "GatewayPorts" is set to "yes", this is a finding. If the /etc/ssh/ssh_config file does not exist, this is not a finding. Re-enable lock down mode.
Disable lock down mode. Enable the ESXi Shell. Edit the SSH client configuration and add/modify the "GatewayPorts" configuration, setting it to "no". # vi /etc/ssh/ssh_config Re-enable lock down mode.
The files hosts.equiv (/etc) and .rhosts (in the user home directory) contains host/user pairs to be trusted by the local system. Locate the files: # ls -l /etc/hosts.equiv # find / | grep .rhosts or # cd <user's home directory> # ls -l .rhosts If the hosts.equiv file or one or more .rhosts files are found, this is a finding.
Remove the file(s): # rm -f /etc/hosts.equiv # rm -f <user's home directory>/.rhosts
Disable lock down mode. Enable the ESXi Shell. Execute the following command(s): # grep MaxSessions /etc/ssh/sshd_config If the command returns nothing, or if "MaxSessions" is not set to "1", this is a finding. Re-enable lock down mode.
Disable lock down mode. Enable the ESXi Shell. Execute the following command(s): # vi /etc/ssh/sshd_config Add/modify the attribute line entry to the following (quotes for emphasis only): "MaxSessions 1" Re-enable lock down mode.
From the vSphere Client: Select the host and click Configuration >> Time Configuration". Select the properties link and chose 'Options'. Select NTP Settings to view configured NTP servers. If NTP is not configured to use NTP server(s) local to the enclave, this is a finding.
From the vSphere Client: Select the host and click Configuration >> Time Configuration". Select the properties link and chose 'Options'. From the General tab start the NTP service and select "Start and stop with host". From the NTP Settings tab click the 'Add' button to add NTP server(s) local to the enclave.
Temporarily disable Lockdown Mode and enable the ESXi Shell via the vSphere Client. Open the vSphere/VMware Infrastructure (VI) Client and log in with appropriate credentials. If connecting to vCenter Server, click on the desired host. Click the Configuration tab. Click Software, Security Profile, Services, Properties, ESXi Shell and Options, respectively. Start the ESXi Shell service, where/as required. As root, log in to the host and verify the expected settings are configured in the /etc/pam.d/passwd file. The entry format is : "password requisite /lib/security/pam_passwdqc.so similar=deny retry=N min=N0,N1,N2,N3,N4" The "N4" field controls the behavior requiring at least one character each of the 4 different character classes (i.e., number, special, UPPER_CASE, and lower_case), with a minimum required length of 14 characters. # grep "^password" /etc/pam.d/passwd | grep requisite | grep "min=" If the "N4" password complexity field is not set to "14" or greater and the "N0" thru "N3" fields are not set to "disabled", this is a finding. Re-enable Lockdown Mode on the host.
Temporarily disable Lockdown Mode and enable the ESXi Shell via the vSphere Client. Open the vSphere/VMware Infrastructure (VI) Client and log in with appropriate credentials. If connecting to vCenter Server, click on the desired host. Click the Configuration tab. Click Software, Security Profile, Services, Properties, ESXi Shell and Options, respectively. Start the ESXi Shell service, where/as required. As root, log in to the host and ensure the expected settings of the "min" keyword are configured in the /etc/pam.d/passwd file. # vi /etc/pam.d/passwd Set the "N4" password complexity field to "14" or greater and set the "N0" thru "N3" fields to "disabled", i.e., min=disabled,disabled,disabled,disabled,14 Re-enable Lockdown Mode on the host.
Temporarily disable Lockdown Mode and enable the ESXi Shell via the vSphere Client. Open the vSphere/VMware Infrastructure (VI) Client and log in with appropriate credentials. If connecting to vCenter Server, click on the desired host. Click the Configuration tab. Click Software, Security Profile, Services, Properties, ESXi Shell and Options, respectively. Start the ESXi Shell service, where/as required. As root, log in to the host, and using the vi editor, verify the expected settings are configured in the /etc/pam.d/passwd file. The entry format is: "password requisite /lib/security/pam_passwdqc.so similar=deny retry=N min=N0,N1,N2,N3,N4" The "N4" field controls the behavior requiring at least one character each of the 4 different character classes (i.e., number, special, UPPER_CASE, and lower_case), with a minimum required length of 14 characters. # grep "^password" /etc/pam.d/passwd | grep requisite | grep "min=" If the "N4" password complexity field is not set to "14" or greater and the "N0" thru "N3" fields are not set to "disabled", this is a finding. Re-enable Lockdown Mode on the host.
Temporarily disable Lockdown Mode and enable the ESXi Shell via the vSphere Client. Open the vSphere/VMware Infrastructure (VI) Client and log in with appropriate credentials. If connecting to vCenter Server, click on the desired host. Click the Configuration tab. Click Software, Security Profile, Services, Properties, ESXi Shell and Options, respectively. Start the ESXi Shell service, where/as required. As root, log in to the host and ensure the expected settings of the "min" keyword are configured in the /etc/pam.d/passwd file. # vi /etc/pam.d/passwd Set the "min" keyword's "N4" flag password complexity field to "14" or greater and set the "N0" thru "N3" flag fields to "disabled", i.e., min=disabled,disabled,disabled,disabled,14 Re-enable Lockdown Mode on the host.
Temporarily disable Lockdown Mode and enable the ESXi Shell via the vSphere Client. Open the vSphere/VMware Infrastructure (VI) Client and log in with appropriate credentials. If connecting to vCenter Server, click on the desired host. Click the Configuration tab. Click Software, Security Profile, Services, Properties, ESXi Shell and Options, respectively. Start the ESXi Shell service, where/as required. As root, log in to the host and verify the expected settings are configured in the /etc/pam.d/passwd file. The entry format is : "password requisite /lib/security/pam_passwdqc.so similar=deny retry=N min=N0,N1,N2,N3,N4" The "N4" field controls the behavior requiring at least one character each of the 4 different character classes (i.e., number, special, UPPER_CASE, and lower_case), with a minimum required length of 14 characters. # grep "^password" /etc/pam.d/passwd | grep requisite | grep "min=" If the "N4" password complexity field is not set to "14" or greater and the "N0" thru "N3" fields are not set to "disabled", this is a finding. Re-enable Lockdown Mode on the host.
Temporarily disable Lockdown Mode and enable the ESXi Shell via the vSphere Client. Open the vSphere/VMware Infrastructure (VI) Client and log in with appropriate credentials. If connecting to vCenter Server, click on the desired host. Click the Configuration tab. Click Software, Security Profile, Services, Properties, ESXi Shell and Options, respectively. Start the ESXi Shell service, where/as required. As root, log in to the host and ensure the expected settings of the "min" keyword are configured in the /etc/pam.d/passwd file. # vi /etc/pam.d/passwd Set the "N4" password complexity field to "14" or greater and set the "N0" thru "N3" fields to "disabled", i.e., min=disabled,disabled,disabled,disabled,14 Re-enable Lockdown Mode on the host.
Temporarily disable Lockdown Mode and enable the ESXi Shell via the vSphere Client. Open the vSphere/VMware Infrastructure (VI) Client and log in with appropriate credentials. If connecting to vCenter Server, click on the desired host. Click the Configuration tab. Click Software, Security Profile, Services, Properties, ESXi Shell and Options, respectively. Start the ESXi Shell service, where/as required. As root, log in to the host and verify the expected settings are configured in the /etc/pam.d/passwd file. An example line format is: "password requisite /lib/security/pam_passwdqc.so similar=deny retry=N min=N0,N1,N2,N3,N4" # grep "^password" /etc/pam.d/passwd | grep requisite | grep "similar=deny" If "similar" is not set to "deny", this is a finding. Re-enable Lockdown Mode on the host.
Temporarily disable Lockdown Mode and enable the ESXi Shell via the vSphere Client. Open the vSphere/VMware Infrastructure (VI) Client and log in with appropriate credentials. If connecting to vCenter Server, click on the desired host. Click the Configuration tab. Click Software, Security Profile, Services, Properties, ESXi Shell and Options, respectively. Start the ESXi Shell service, where/as required. As root, log in to the host and ensure the expected settings of the "min" keyword are configured in the /etc/pam.d/passwd file. # vi /etc/pam.d/passwd Set the "similar" keyword complexity field to "deny", i.e., similar=deny Re-enable Lockdown Mode on the host.
Temporarily disable Lockdown Mode and enable the ESXi Shell via the vSphere Client. Open the vSphere/VMware Infrastructure (VI) Client and log in with appropriate credentials. If connecting to vCenter Server, click on the desired host. Click the Configuration tab. Click Software, Security Profile, Services, Properties, ESXi Shell and Options, respectively. Start the ESXi Shell service, where/as required. As root, log in to the host and verify the expected setting is configured in the /etc/pam.d/passwd file. The entry format will look similar to "password sufficient /lib/security/$ISA/pam_unix.so use_authtok nullok shadow". Search for the existing hash key (sha512). # grep "^password sufficient " /etc/pam.d/passwd | grep sha512 If sha512 is missing from the configuration, this is a finding. Re-enable Lockdown Mode on the host.
Temporarily disable Lockdown Mode and enable the ESXi Shell via the vSphere Client. Open the vSphere/VMware Infrastructure (VI) Client and log in with appropriate credentials. If connecting to vCenter Server, click on the desired host. Click the Configuration tab. Click Software, Security Profile, Services, Properties, ESXi Shell and Options, respectively. Start the ESXi Shell service, where/as required. As root, log in to the host and verify the expected setting is configured in the /etc/pam.d/passwd file. The entry format will look similar to "password sufficient /lib/security/$ISA/pam_unix.so use_authtok nullok shadow". Edit the file and replace the existing hash key ( md5, des, or sha256) with sha512 or append sha512, if there is no existing key. For example: "password sufficient /lib/security/$ISA/pam_unix.so use_authtok nullok shadow sha512". Re-enable Lockdown Mode on the host.
Temporarily disable Lockdown Mode and enable the ESXi Shell via the vSphere Client. Open the vSphere/VMware Infrastructure (VI) Client and log in with appropriate credentials. If connecting to vCenter Server, click on the desired host. Click the Configuration tab. Click Software, Security Profile, Services, Properties, ESXi Shell and Options, respectively. Start the ESXi Shell service, where/as required. The entry format will look similar to: "password sufficient /lib/security/$ISA/pam_unix.so use_authtok nullok shadow sha512 remember=5" As root, log in to the host and execute the following: # grep "^password" /etc/pam.d/passwd | grep sufficient | grep "remember=" If "remember" is set to less than 5, this is a finding. Re-enable Lockdown Mode on the host.
Temporarily disable Lockdown Mode and enable the ESXi Shell via the vSphere Client. Open the vSphere/VMware Infrastructure (VI) Client and log in with appropriate credentials. If connecting to vCenter Server, click on the desired host. Click the Configuration tab. Click Software, Security Profile, Services, Properties, ESXi Shell and Options, respectively. Start the ESXi Shell service, where/as required. "remember" is an option to pam_unix.so. As root, log in to the host and modify the "remember" keyword value, example: "remember=5". # vi /etc/pam.d/passwd Re-enable Lockdown Mode on the host.
Temporarily disable Lockdown Mode and enable the ESXi Shell via the vSphere Client. Open the vSphere/VMware Infrastructure (VI) Client and log in with appropriate credentials. If connecting to vCenter Server, click on the desired host. Click the Configuration tab. Click Software, Security Profile, Services, Properties, ESXi Shell and Options, respectively. Start the ESXi Shell service, where/as required. As root, log in to the host and verify the expected settings are configured in the /etc/pam.d/passwd file. The entry format is : "password requisite /lib/security/pam_passwdqc.so similar=deny retry=N min=N0,N1,N2,N3,N4" In addition to other password characteristics, the "N4" field controls the minimum required length of 14 characters. # grep "^password" /etc/pam.d/passwd | grep requisite | grep "min=" If the "N4" password complexity field is not set to "14" or greater and the "N0" thru "N3" fields are not set to "disabled", this is a finding.
Temporarily disable Lockdown Mode and enable the ESXi Shell via the vSphere Client. Open the vSphere/VMware Infrastructure (VI) Client and log in with appropriate credentials. If connecting to vCenter Server, click on the desired host. Click the Configuration tab. Click Software, Security Profile, Services, Properties, ESXi Shell and Options, respectively. Start the ESXi Shell service, where/as required. As root, log in to the host and ensure the expected settings of the "min" keyword are configured in the /etc/pam.d/passwd file. # vi /etc/pam.d/passwd Set the "N4" password complexity field to "14" or greater and set the "N0" thru "N3" fields to "disabled", i.e., min=disabled,disabled,disabled,disabled,14 Re-enable Lockdown Mode on the host.
Disable lock down mode. Enable the ESXi Shell and attempt to log into the root account using only the first 8 of 14 required characters. If the login succeeds, this is a finding. Re-enable lock down mode.
Temporarily disable Lockdown Mode and enable the ESXi Shell via the vSphere Client. Open the vSphere/VMware Infrastructure (VI) Client and log in with appropriate credentials. If connecting to vCenter Server, click on the desired host. Click the Configuration tab. Click Software, Security Profile, Services, Properties, ESXi Shell and Options, respectively. Start the ESXi Shell service, where/as required. As root, log in to the host and verify the expected settings are configured in the /etc/pam.d/passwd file. The entry format is "password requisite /lib/security/pam_passwdqc.so similar=deny retry=N min=N0,N1,N2,N3,N4". The "N4" field controls the behavior requiring at least one character each of the 4 different character classes, with a minimum required length of 14 characters. # vi /etc/pam.d/passwd Set the "N4" password complexity field to "14" and set the "N0" thru "N3" fields to "disabled". Re-enable Lockdown Mode on the host.
On systems with a BIOS or system controller, ask the SA if a supervisor or administrator password is set. If a password is not set, this is a finding.
On systems with a BIOS or system controller, set the supervisor or administrator password.
Disable lock down mode. Enable the ESXi Shell. Check the SSH daemon configuration for the X11 forwarding setting. # grep -i "^X11Forwarding" /etc/ssh/sshd_config If "X11Forwarding" is set to "yes", this is a finding. Re-enable lock down mode.
Disable lock down mode. Enable the ESXi Shell. Edit the SSH daemon configuration and add/modify the "X11Forwarding" configuration, setting it to "no". # vi /etc/ssh/sshd_config Re-enable lock down mode.
Disable lock down mode. Enable the ESXi Shell. Execute the following command(s): # grep AcceptEnv /etc/ssh/sshd_config If the "AcceptEnv" attribute is not set to "LOCALE" or unassigned (the "AcceptEnv" attribute minus any parameter assignment), this is a finding. Re-enable lock down mode.
Disable lock down mode. Enable the ESXi Shell. Execute the following command(s): # vi /etc/ssh/sshd_config Add/modify the attribute line entry to the following (quotes for emphasis only): "AcceptEnv LOCALE" or "AcceptEnv" Re-enable lock down mode.
Disable lock down mode. Enable the ESXi Shell. Execute the following command(s): # grep PermitUserEnvironment /etc/ssh/sshd_config If the command returns nothing, or the returned "PermitUserEnvironment" attribute is not set to "no", this is a finding. Re-enable lock down mode.
Disable lock down mode. Enable the ESXi Shell. Execute the following command(s): # vi /etc/ssh/sshd_config Add/modify the attribute line entry to the following (quotes for emphasis only): "PermitUserEnvironment no" Re-enable lock down mode.
Disable lock down mode. Enable the ESXi Shell. Execute the following command(s): # grep PermitTunnel /etc/ssh/sshd_config If the command returns nothing, or the returned "PermitTunnel" attribute is not set to "no", this is a finding.
Disable lock down mode. Enable the ESXi Shell. Execute the following command(s): # vi /etc/ssh/sshd_config Add/modify the attribute line entry to the following (quotes for emphasis only): "PermitTunnel no" Re-enable lock down mode.
Disable lock down mode. Enable the ESXi Shell. Execute the following command(s): # grep SendEnv /etc/ssh/ssh_config If the "SendEnv" attribute is not set to "LOCALE", this is a finding. If the /etc/ssh/ssh_config file does not exist or the SendEnv option is not set, this is not a finding. Re-enable lock down mode.
Disable lock down mode. Enable the ESXi Shell. Execute the following command(s): # vi /etc/ssh/ssh_config Add/modify the attribute line entry to one of the following (quotes for emphasis only): "SendEnv LOCALE " or "SendEnv" Re-enable lock down mode.
Disable lock down mode. Enable the ESXi Shell. Execute the following command(s): # grep Tunnel /etc/ssh/ssh_config If the "Tunnel" attribute is not set to "no", this is a finding. If the /etc/ssh/ssh_config file does not exist or the Tunnel option is not set, this is not a finding. Re-enable lock down mode.
Disable lock down mode. Enable the ESXi Shell. Execute the following command(s): # vi /etc/ssh/ssh_config Add/modify the attribute line entry to the following (quotes for emphasis only): "Tunnel no" Re-enable lock down mode.
Disable lock down mode. Enable the ESXi Shell. Check the SSH client configuration for the X11 forwarding setting. # grep -i "^ForwardX11" /etc/ssh/ssh_config If "ForwardX11" is set to "yes", this is a finding. If the /etc/ssh/ssh_config file does not exist or the ForwardX11 option is not set, this is not a finding. Re-enable lock down mode.
Disable lock down mode. Enable the ESXi Shell. Edit the SSH client configuration and add/modify the "ForwardX11" configuration to "no". # vi /etc/ssh/ssh_config Re-enable lock down mode.
Disable lock down mode. Enable the ESXi Shell. <file> = /etc/profile <required_keyword> = PATH <required_keyword_setpoint> = /bin:/sbin Execute the following command(s): # grep PATH /etc/profile If the "PATH" is not set to "/bin:/sbin", this is a finding. Re-enable lock down mode.
Disable lock down mode. Enable the ESXi Shell. <file> = /etc/profile <required_keyword> = PATH <required_keyword_setpoint> = /bin:/sbin Execute the following command(s): # vi /etc/profile Set the "PATH" to "/bin:/sbin". Re-enable lock down mode.
From the vSphere Client/vCenter, click on the "Local Users and Groups" tab, then select to view Groups. Select to view Users. Highlight the user, right click and select Edit. Click Cancel. If any user's primary GID is not found in the Group list, this is a finding.
From the vSphere Client/vCenter, click on the "Local Users and Groups" tab, then select Groups. Highlight the user, right click the user and select Edit. Select/highlight/assign the user's correct primary GID. Click OK.
Disable lock down mode. Enable the ESXi Shell. <file> = /etc/shells Execute the following command(s): # ls -l /etc/shells If /etc/shells does not exist, this is a finding. Re-enable lock down mode.
Disable lock down mode. Enable the ESXi Shell. <file> = /etc/shells Execute the following command(s): # > /etc/shells Re-enable lock down mode.
Disable lock down mode. Enable the ESXi Shell. <file> = /etc/shells Available shells for ESXi are "/bin/sh" and "/bin/ash". Execute the following command(s): # ls -lL `cat /etc/shells` If /etc/shells does not exist, this is a finding. If /etc/shells exists and is empty, this is a finding. If /etc/shells exists and includes both the /bin/sh and /bin/ash shells, this is not a finding. Re-enable lock down mode.
Disable lock down mode. Enable the ESXi Shell. <file> = /etc/shells Available shells for ESXi are "/bin/sh" and "/bin/ash". Ensure both the above interactive shell(s) are listed in the /etc/shells file. If necessary, add them: # vi /etc/shells Re-enable lock down mode.
Note: Checking a system's BIOS is vendor and hardware dependent. To verify media boot options: Interrupt the host computer's boot process and enter the BIOS menu. Inspect the menu option for boot order. If any media other than the ESXi boot disk is listed as a boot option, this is a finding.
Note: Checking a system's BIOS is vendor and hardware dependent. To ensure media boot options: Interrupt the host computer's boot process and enter the BIOS menu. Inspect the menu option for boot order. Remove all boot media options except for ESXi. Save the change and exit to verify the boot cycle.
Verify that the vSphere Syslog Collector syslog host has been justified and documented with the IAO. From the vSphere Client: Select the host and click "Configuration >> Advanced Settings >> Syslog >> Global". Verify that the 'Syslog.global.logHost' is set to the (site-specific) syslog server hostname. If the 'Syslog.global.logHost' is not justified and documented with the IAO, this is a finding.
Step 1: Verify that the vSphere Syslog Collector syslog host has been configured. If not, install/enable the vSphere Syslog Collector. Step 2: From the vSphere Client: Select the host and click "Configuration >> Advanced Settings >> Syslog >> Global". Step 3: Set 'Syslog.global.logHost' to the syslog server hostname justified and documented with the IAO.
Verify that the vSphere Syslog Collector syslog host has been justified and documented with the IAO. From the vSphere Client: Select the host and click "Configuration >> Advanced Settings >> Syslog >> Global". Verify that the 'Syslog.global.logHost' is set to the (site-specific) syslog server hostname. If the 'Syslog.global.logHost' is not restricted to the enclave, this is a finding.
Step 1: Verify that the vSphere Syslog Collector syslog host has been configured. If not, install/enable the vSphere Syslog Collector. Step 2: From the vSphere Client: Select the host and click "Configuration >> Advanced Settings >> Syslog >> Global". Step 3: Set 'Syslog.global.logHost' to the syslog server hostname restricted to the enclave.
Disable lock down mode. Enable the ESXi Shell. Execute the following command(s): # grep Compression /etc/ssh/sshd_config If the command returns nothing, or if the "Compression" attribute is set to "yes", this is a finding. Re-enable lock down mode.
Disable lock down mode. Enable the ESXi Shell. Execute the following command(s): # vi /etc/ssh/sshd_config Add/modify the attribute line entry to the following (quotes for emphasis only): "Compression no" or "Compression delayed" Re-enable lock down mode.
If the system does not use IPv6, this check is not applicable. From the vSphere Client/vCenter; click on the "Configuration" tab, click on "Networking"; click on "Standard Switch/Properties"; click on "Management NetworkProperties/Edit/IP Settings" and click "Cancel". If the "VMkernel Default Gateway" field is not initialized (valid IP address is required), this is a finding.
The following fix text applies only if the system uses IPv6. From the vSphere Client/vCenter; click on the "Configuration" tab; click on "Networking"; click on "Standard Switch/Properties"; click on "Management NetworkProperties/Edit/IP Settings". Select "Use the following IP settings"; fill in the field(s) (at a minimum, the default gateway IP Address is required) per the local site requirements and click "OK".
If DHCP is used, this is not applicable. From the vSphere Client/vCenter, click on the "Configuration" tab; click on "Networking"; click on "Standard Switch/Properties"; click on "Management NetworkProperties/Edit/IP Settings"; verify "Obtain IP settings automatically" is not selected, and click "Cancel". If "Obtain IP settings automatically" is selected, this is a finding.
From the vSphere Client/vCenter, click on the "Configuration" tab; click on "Networking"; click on "Standard Switch/Properties"; click on "Management NetworkProperties/Edit/IP Settings"; select "Use the following IP settings"; fill in the IPAddress fields per local site requirements and click "OK".
If the system uses USB, this is not applicable. To verify hardware enabled options: Interrupt the host computer's boot process and enter the BIOS menu. Inspect the menu option for USB device connectivity. If the system does not require USB and USB is enabled, this is a finding.
To modify hardware enabled options: Interrupt the host computer's boot process and enter the BIOS menu. Inspect the menu option for USB device connectivity. Disable USB.
If the system uses USB mass storage, this is not applicable. To verify hardware enabled options: Interrupt the host computer's boot process and enter the BIOS menu. Inspect the menu option for USB mass storage connectivity. If the system does not require USB mass storage and USB mass storage connectivity is enabled, this is a finding.
To modify hardware enabled options: Interrupt the host computer's boot process and enter the BIOS menu. Inspect the menu option for USB mass storage connectivity. Disable USB mass storage connectivity.
If the system uses IEEE 1394, this is not applicable. To verify hardware enabled options: Interrupt the host computer's boot process and enter the BIOS menu. Inspect the menu option for IEEE 1394 device connectivity. If the system does not use IEEE 1394 and IEEE 1394 is enabled, this is a finding.
To modify hardware enabled options: Interrupt the host computer's boot process and enter the BIOS menu. Inspect the menu option for IEEE 1394 device connectivity. Disable IEEE 1394.
From the vSphere Client: Select the host and click "Configuration >> Time Configuration". Select the properties link and chose 'Options'. Select NTP Settings to view configured NTP servers. If NTP is not configured, this is a finding.
From the vSphere Client: Select the host and click "Configuration >> Time Configuration". Select the properties link and chose 'Options'. From the General tab start the NTP service and select "Start and stop with host". From the NTP Settings tab click the 'Add' button to add the organization defined NTP servers.
In vSphere Client, select the host in the inventory panel. Click the Configuration tab, then click Advanced Settings under Software. Check that the Syslog.global.logDir points to a persistent location. The directory should be specified as [datastorename] path_to_file where the path is relative to the datastore. For example, [datastore1] /systemlogs. If the Syslog.global.logDir field is empty or explicitly points to a scratch partition, make sure that the field ScratchConfig.CurrentScratchLocation shows a location on persistent storage. If the Syslog.global.logDir field entry is not located on persistent storage, this is a finding. Re-enable Lockdown Mode on the host.
From the vSphere Client, select the ESXi hosts and click "Configuration >> Advanced Settings >> Syslog >> global" and specify a known, persistent datastore for 'Syslog.global.logDir'.
From the vSphere Client, select the host and select "Configuration >> Security Profile". In the services section select "Properties". Select "Direct Console UI" and click "Options". From the pop-up verify the DCUI service startup policy is set to "start and stop manually". If the DCUI service startup policy is not set to "Start and stop manually", this is a finding.
From the vSphere Client, select the host and select "Configuration >> Security Profile". In the services section select "Properties". Select "Direct Console UI" and click "Options". From the pop-up stop the DCUI service and set the startup policy to "start and stop manually".
From the vSphere Client, select the host then select "Configuration >> Security Profiles". In the Services section select "Properties". Select the "ESXi Shell" and click Options. Verify the ESXi Shell is set to "Start and stop manually". If the ESXi Shell service startup policy is not set to "Start and stop manually", this is a finding.
From the vSphere Client, select the host then select "Configuration >> Security Profiles". In the Services section select "Properties". Select the "ESXi Shell" and click Options. Stop the ESXi Shell and select the option to "Start and stop manually".
Temporarily disable Lockdown Mode and enable the ESXi Shell via the vSphere Client. Open the vSphere/VMware Infrastructure (VI) Client and log in with appropriate credentials. If connecting to vCenter Server, click on the desired host. Click the Configuration tab. Click Software, Security Profile, Services, Properties, ESXi Shell, and Options, respectively. Start the ESXi Shell service, where/as required. As root, log in to the ESXi Shell and determine if the MOB is enabled. # vim-cmd proxysvc/service_list | grep proxy-mob If the command return lists "proxy-mob", this is a finding. Re-enable Lockdown Mode on the host.
Temporarily disable Lockdown Mode and enable the ESXi Shell via the vSphere Client. Open the vSphere/VMware Infrastructure (VI) Client and log in with appropriate credentials. If connecting to vCenter Server, click on the desired host. Click the Configuration tab. Click Software, Security Profile, Services, Properties, ESXi Shell, and Options, respectively. Start the ESXi Shell service, where/as required. As root, log in to the ESXi Shell and disable the MOB. # vim-cmd proxysvc/remove_service "/mob" "httpsWithRedirect". Re-enable Lockdown Mode on the host.
If the CIM account does not exist, this check is not applicable. If write access is required, this check is not applicable. From the vSphere client, select the ESXi host, and go to "Permissions". Select the CIM account user, then right-click and select properties to verify read-only access. If write access is not required and the access level is not "read-only", this is a finding.
From the vSphere client, select the ESXi host; go to "Local Users and Groups". Create a limited-privileged, read-only service account for CIM. Place the CIM account into the "root" group. Select Users and right-click in the user screen. Select "Add", then Add a new user. If write access is required only grant the minimum required privileges. CIM accounts should be limited to the "Host > Config > System Management" and "Host > CIM > CIMInteraction" privileges.
This check applies to the use of iSCSI storage. If iSCSI storage is not used, this check is not applicable. In the vSphere Client, select the host, and then choose: Configuration - Storage Adaptors - iSCSI Initiator Properties - CHAP - CHAP (Target Authenticates Host) - determine if "Use Chap" is selected with a "Name" and a "Secret" configured. If iSCSI storage is used and "Use CHAP" is not selected and configured with a "Name" and a "Secret", this is a finding.
In the vSphere Client, select the host, and then choose: Configuration >> Storage Adaptors >> iSCSI Initiator Properties >> CHAP >> CHAP (Target Authenticates Host). Select "Use Chap", and configure the "Name" and "Secret" options.
NOTE: SSL for NFC is used for copying or migrating VMs between ESXi hosts via vCenter. If the host is a standalone unit (i.e., not managed by a vCenter Server), this check is not applicable. From the vSphere client select "Administration >> vCenter Server Settings >> Advanced Settings". Verify "config.nfc.useSSL" is set to true. If "config.nfc.useSSL" is set to false, this is a finding.
From the vSphere client select "Administration >> vCenter Server Settings >> Advanced Settings". Set "config.nfc.useSSL = true".
From the vSphere client select "Administration >> vCenter Server Settings >> Advanced Settings". Verify that the "VirtualCenter.VimPasswordExpirationInDays" keyword is set to 60 or less. The default keyword value is 30 days and it is strongly recommended that this value not be changed from "30". If the "VirtualCenter.VimPasswordExpirationInDays" keyword setting is greater than 60, this is a finding.
From the vSphere client select "Administration >> vCenter Server Settings >> Advanced Settings". Set the "VirtualCenter.VimPasswordExpirationInDays" to 60 or less. Note that it is strongly recommended that this value not be changed from "30".
From the vSphere client select "Administration >> vCenter Server Settings >> Advanced Settings". Verify that the "VirtualCenter.VimPasswordExpirationInDays" keyword is set to 60 or less. The default keyword value is 30 days and it is strongly recommended that this value not be changed from "30". If the "VirtualCenter.VimPasswordExpirationInDays" keyword setting is greater than 60, this is a finding.
From the vSphere client select "Administration >> vCenter Server Settings >> Advanced Settings". Set the "VirtualCenter.VimPasswordExpirationInDays" to 60 or less. Note that it is strongly recommended that this value not be changed from "30".
The default minimum length for passwords is 14. The vpxuser password default length is 32 characters. The vpxuser password length must never be modified to less than the default length of 32 characters. From the vSphere client select "Administration >> vCenter Server Settings >> Advanced Settings". Verify the "config.vpxd.hostPasswordLength" is set to 32 or greater. Default is 32 characters. If the "config.vpxd.hostPasswordLength" setting is less than 32, this is a finding.
From the vSphere client select "Administration >> vCenter Server Settings >> Advanced Settings". Set the "config.vpxd.hostPasswordLength" to comply with site requirements. Default is 32 characters. Note that the vpxuser password is added by vCenter, meaning no manual intervention is required. The vpxuser password length must never be modified to less than the default length of 32 characters.
From the vSphere Client, select the host, and then choose: Configuration - Storage Adaptors - iSCSI Initiator Properties - CHAP - CHAP (Target Authenticates Host) - determine if a different authentication secret is configured for each ESXi host. If a different authentication secret is not configured for each ESXi host, this is a finding. If iSCSI is not used, this is not a finding.
From the vSphere Client, select the host, and then choose: Configuration - Storage Adaptors - iSCSI Initiator Properties - CHAP - CHAP (Target Authenticates Host) - configure the authentication secret.
Zoning and masking capabilities for each SAN switch and disk array are vendor specific. Ask the SA if a SAN device is used to support hosts. If a SAN device is deployed and zoning/masking is not used, this is a finding. If SAN devices are not used, this is not a finding.
If SAN devices are used, a vendor-specific procedure must be developed and documented to mask/zone host LUNs.
From the vSphere client select the host and click "Configuration >> Advanced Settings >> Net" and verify the value of Net.DVFilterBindIpAddress. For a host without a dvfilter-based network security appliance, the following kernel parameter value must be blank/empty: /Net/DVFilterBindIpAddress. For a host with a dvfilter-based network security appliance is being used, the value of this parameter must be set to match the appliance. If a dvfilter-based network security appliance is not used and the kernel parameter /Net/DVFilterBindIpAddress is populated, this is a finding. If a dvfilter-based network security appliance is used and the kernel parameter /Net/DVFilterBindIpAddress does not match the appliance, this is a finding.
From the vSphere client select the host and click "Configuration >> Advanced Settings >> Net" Set the value of Net.DVFilterBindIpAddress to blank if a dvfilter-based network security appliance is not used or (where used) set the value of Net.DVFilterBindIpAddress to match the dvfilter-based network security appliance.
Temporarily disable Lockdown Mode and enable the ESXi Shell via the vSphere Client. Open the vSphere/VMware Infrastructure (VI) Client and log in with appropriate credentials. If connecting to vCenter Server, click on the desired host. Click the Configuration tab. Click Software, Security Profile, Services, Properties, ESXi Shell, and Options, respectively. Start the ESXi Shell service, where/as required. As root, log in to the host and verify the /etc/ssh/keys-root/authorized_keys file does not exist or is empty (zero bytes): # ls -l /etc/ssh/keys-root/authorized_keys If the authorized_keys file exists and is not empty, this is a finding. Re-enable Lockdown Mode on the host.
Temporarily disable Lockdown Mode and enable the ESXi Shell via the vSphere Client. Open the vSphere/VMware Infrastructure (VI) Client and log in with appropriate credentials. If connecting to vCenter Server, click on the desired host. Click the Configuration tab. Click Software, Security Profile, Services, Properties, ESXi Shell and Options, respectively. Start the ESXi Shell service, where/as required. As root, log in to the host and zero/remove /etc/ssh/keys-root/authorized_keys file: # >/etc/ssh/keys-root/authorized_keys or # rm /etc/ssh/keys-root/authorized_keys Re-enable Lockdown Mode on the host.
For systems that do not use Active Directory and have no local user accounts, other than root and/or vpxuser, this check is not applicable. For systems that do not use Active Directory and do have local user accounts, other than root and/or vpxuser, this check is a finding. From the vSphere client, select the host, then "Configuration >> Authentication Services" and verify the Directory Services Type is set to Active Directory. If the Directory Services Type is not set to "Active Directory", this is a finding.
Perform the following steps to configure the ESXi host to use Active Directory: (1) Log into the ESXi host using the vSphere Client and authenticating with the root account (or an equivalent account). (2) Select the ESXi host from the inventory and click the Configuration tab. (3) From the Software section, select Authentication Services. (4) Click Properties in the upper-right corner. (5) From the Directory Services Configuration dialog box, select Active Directory from the Select Directory Service Type drop-down list. (6) Supply the DNS domain name of the Active Directory domain this ESXi host will use for authentication. (7) Click the Join Domain button. (8) Specify a username and password that has permission to allow the host to join the domain. Once the ESXi host is joined to Active Directory, users will be able to authenticate to an ESXi host using their Active Directory credentials. Using the vSphere Client or the vCLI, users can use either the domain\username or username@domain syntax.
For systems that do not use Active Directory and have no local user accounts, other than root and/or vpxuser, this check is not applicable. For systems that do not use Active Directory and do have local user accounts, other than root and/or vpxuser, this check is a finding. From the vSphere Client/vCenter, select the host, then Configuration >> Software/Advanced Settings >> HostAgent. Verify "Config.HostAgent.plugins.hostsvc.esxAdminsGroup" is not set to "ESX Admins". If the "Config.HostAgent.plugins.hostsvc.esxAdminsGroup" keyword is set to "ESX Admins", this is a finding.
From the vSphere Client/vCenter, select the host, then Configuration >> Software/Advanced Settings >> HostAgent. Change the "Config.HostAgent.plugins.hostsvc.esxAdminsGroup" to a pre-defined group other than the default "ESX Admins". Note: The new administrator group must have been previously defined on the Active Directory server.
ESXi Configuration files can be found by browsing to https://<hostname>/mob. A cryptographically hashed file integrity baseline is the best means to ensure these configuration files are preserved. Ask the SA if a cryptographically hashed file integrity baseline has been created and maintained for the system. If no file integrity baseline exists for the system, this is a finding. If the configuration files can be viewed with the MOB, this is a finding.
Temporarily disable Lockdown Mode and enable the ESXi Shell via the vSphere Client. Open the vSphere/VMware Infrastructure (VI) Client and log in with appropriate credentials. If connecting to vCenter Server, click on the desired host. Click the Configuration tab. Click Software, Security Profile, Services, Properties, ESXi Shell, and Options, respectively. Start the ESXi Shell service, where/as required. As root, log in to the host and run the following command(s): Determine if the MOB is enabled. # vim-cmd proxysvc/service_list If enabled, disable the MOB with the following command. # vim-cmd proxysvc/remove_service "/mob" "httpsWithRedirect" NOTE: Some third-party tools use MOB to gather information. Testing should be done after disabling the MOB to verify third-party applications are still functioning as expected. To re-enable the MOB: # vim-cmd proxysvc/add_np_service "/mob" httpsWithRedirect". Re-enable Lockdown Mode on the host.
Temporarily disable Lockdown Mode and enable the ESXi Shell via the vSphere Client. Open the vSphere/VMware Infrastructure (VI) Client and log in with appropriate credentials. If connecting to vCenter Server, click on the desired host. Click the Configuration tab. Click Software, Security Profile, Services, Properties, ESXi Shell and Options, respectively. Start the ESXi Shell service, where/as required. As root, log in to and inspect the host for unsigned kernel modules. To list all the loaded kernel modules run: # esxcli system module list For each host module verify the signature by running: # esxcli system module get -m <module>" Note that the integrity of unsigned third party kernel modules and modules with inadvertently omitted digital signatures (by VMware) can still be verified using the digital signature of the vSphere Installation Bundle (VIB) originally used to install the software. If the host's module list contains any unsigned modules, check the acceptance level for all installed VIBs via the following ESXCLI command: # esxcli software vib list If the host's installed kernel module/VIB digital signatures cannot be determined, this is a finding. Re-enable Lockdown Mode on the host.
Temporarily disable Lockdown Mode and enable the ESXi Shell via the vSphere Client. Open the vSphere/VMware Infrastructure (VI) Client and log in with appropriate credentials. If connecting to vCenter Server, click on the desired host. Click the Configuration tab. Click Software, Security Profile, Services, Properties, ESXi Shell, and Options, respectively. Start the ESXi Shell service, where/as required. As root, log in to and secure the host by individually disabling unsigned modules and removing the offending VIBs from the host. Note that in order to disable kernel modules, from the vSphere Client, VMs must first be evacuated and the host must then be placed into maintenance mode. # esxcli system modules set -e false -m <module> Re-enable Lockdown Mode on the host.
For systems that do not use Active Directory and have no local user accounts, other than root and/or vpxuser, this check is not applicable. NOTE: vSphere Authentication Proxy is available via the vSphere vCenter Server ISO. Although mainly used with Auto Deploy, which is available only with the vSphere Enterprise Plus Edition, vSphere Authentication Proxy does not require a specific vSphere Edition (i.e., Standard vs Enterprise) to be installed. From the vSphere client, select "Host Profiles". Right click the Host Profile and select Edit. Choose "Authentication configuration >> Active Directory Configuration >> Join Domain Method". Verify the Join Domain Method is set to "Use vSphere Authentication Proxy to add the host to domain". If the vSphere Authentication Proxy is installed and the Join Domain Method is not set to "Use vSphere Authentication Proxy to add the host to domain", this is a finding.
From the vSphere client, select "Host Profiles". Right click the Host Profile and select Edit. Choose "Authentication configuration >> Active Directory Configuration >> Join Domain Method". Set the Join Domain Method to "Use vSphere Authentication Proxy to add the host to domain".
Ask the SA if a documented procedure is used to overwrite sensitive data in VMDK flat files prior to deletion. The procedure must include a command to zero out data and the file must then be deleted. See some examples directly below. vmkfstools --writezeroes <path+vmdk_flat_file> or dd if=/dev/zero of=<path+vmdk_flat_file> If a documented procedure to overwrite sensitive data in VMDK flat files prior to deletion does not exist, this is a finding.
Create and document a procedure to zero out sensitive data prior to removal of the VMDK file. Command line interface commands such as vmkfstools, dd, and rm must be used, per the examples below. vmkfstools --writezeroes <path+vmdk_flat_file> or dd if=/dev/zero of=<path+vmdk_flat_file> Note: The vSphere Client does not automatically zero out a VMDK file when it is destroyed.
Temporarily disable Lockdown Mode and enable the ESXi Shell via the vSphere Client. Open the vSphere/VMware Infrastructure (VI) Client and log in with appropriate credentials. If connecting to vCenter Server, click on the desired host. Click the Configuration tab. Click Software, Security Profile, Services, Properties, ESXi Shell and Options, respectively. Start the ESXi Shell service, where/as required. Open a root console session to the ESXi host. Retrieve the currently active diagnostic partition using the esxcli command line utility. The output (when configured) looks similar to : Active: mpx.vmhba2:C0:T0:L0:7 and Configured: mpx.vmhba2:C0:T0:L0:7. # esxcli system coredump partition get Use the device information from the above command to determine partition size (100MB required, 200MB recommended): # esxcli storage core device partition list For ESXi 5.0 servers (standalone or managed by vCenter Server) that have kernel core dumps configured locally: If the ESXi 5.0 server's local dump partition size is at least 100 MB, this is not a finding. For ESXi 5.0 servers managed by vCenter Server using the ESXi Network Dump Collector, dump partition size is a function of the number of systems configured to use the remote collection system. The configuration (size) of the dump partition is not applicable for this check. If the ESXi 5.0 server's dump partition is hosted on a remote device using the ESXi Network Dump Collector, this is not a finding.
For ESXi 5.0 servers (standalone or managed by vCenter Server) that have kernel core dumps configured locally: To create a diagnostic coredump partition on disk, select a storage device with at least 100MB of free space (200MB recommended) that is accessible by the ESXi host. Ensure the storage device you intend to use does not contain any useful data as it will be overwritten. Use the partedUtil command line utility (refer to the vendor's documentation) to create a new partition. Then use the esxcli command line utility to list all accessible diagnostic partitions. # esxcli system coredump partition list The output appears similar to: Name Path Active Configured ---------------------------------- ------ --------- ---------------- mpx.vmhba2:C0:T0:L0:7 /vmfs/devices/... false false Configure and activate one of the accessible diagnostic partitions using the esxcli command line utility. # esxcli system coredump partition set --partition="Partition_Name" # esxcli system coredump partition set --enable true Validate that the diagnostic partition is now active using the command: # esxcli system coredump partition list The output should now appear similar to: Name Path Active Configured ---------------------------------- ------ --------- ---------------- mpx.vmhba2:C0:T0:L0:7 /vmfs/devices/... true true For ESXi 5.0 servers managed by vCenter Server using a network core dump server: View the current network configuration. # esxcli system coredump network get Specify the VMkernel network interface to use for outbound traffic and the IP address/UDP port number of the remote network coredump server. # esxcli system coredump network set --interface-name <VMkernelInterface> --server-ipv4 <IPAddress> --server-port PortNumber Enable the above selected network coredump configuration. # esxcli system coredump network set --enable true Confirm the configuration. # esxcli system coredump network get
If a vNetwork Distributed Switch (vDS) is not configured, this is not applicable. From the vSphere Client log into vCS. Home >> Inventory >> Networking. Select dvSwitch and dvPortgroup and Edit Settings >> Policies >> VLAN >> VLAN ID. The dvPortGroup VLAN tags must be documented to match the IDs on external VLAN-aware upstream switches. Verify that VLAN IDs are documented and matched in an (organization-specific) tracking system. If the VLAN tagging on a dvPortgroup does not correspond to the IDs on external VLAN-aware upstream switches, this is a finding.
From the vSphere Client log into vCS. Home >> Inventory >> Networking. Select dvSwitch and dvPortgroup and Edit Settings >> Policies >> VLAN >> VLAN ID. Record all VLAN IDs in an organization defined tracking system.
Verify by using the vSphere Client to connect to the vCenter Server and as administrator go to "Home>> Inventory>> Hosts and Clusters". Select each ESXi host with virtual switches connected to active VMs requiring securing. Go to "Configuration>> Network>> vSwitch(?)>> Properties>> Ports>> [Portgroup Name]>> VLAN ID". The dvSwitch Private VLAN tags must be documented to match the IDs on external PVLAN-aware upstream switches. Verify that Private VLAN IDs are documented and matched in an (organization-specific) tracking system. If any PVLAN IDs do not correspond to the IDs on external PVLAN-aware upstream switches, this is a finding.
From the vSphere Client connect to the vCenter Server and as administrator go to "Home>> Inventory>> Hosts and Clusters". Select each ESXi host with virtual switches connected to active VMs requiring securing. Go to "Configuration>> Network>> vSwitch(?)>> Properties>> Ports>> [Portgroup Name]>> VLAN ID". Record all configured VLAN IDs in an organization defined tracking system.
From the vSphere Client/vCenter, navigate to Home>> Inventory>> Networking. Port groups must be clearly labeled or must be renamed with a meaningful name. If all port groups are not clearly labeled with functionally meaningful names, this is a finding.
From the vSphere Client/vCenter, navigate to Home>> Inventory>> Networking. Clearly label/rename all port groups with a meaningful name.
Both standard and distributed vSwitch configurations can be viewed in the vSphere Client. For vSwitch: Home>> Inventory>> Hosts and Clusters, then select an ESXi host in Inventory panel on left. In the Configuration tab, Hardware window, under Networking, select each vSwitch, and for each port group on the vSwitch, verify and record the VLAN IDs used. For dvSwitches, go to Home>> Inventory>> Networking and for each dvSwitch in the inventory, and for each dvPortGroup in each dvSwitch, select Edit Settings>> Policies>> VLAN and verify the recorded VLAN IDs. If the system VLAN IDs do not match the VLAN IDs on record, this is a finding.
Both standard and distributed vSwitch configurations can be viewed in the vSphere Client. For vSwitch: Home>> Inventory>> Hosts and Clusters, then select an ESXi host in Inventory panel on left. In the Configuration tab, Hardware window, under Networking, select each vSwitch, and for each port group on the vSwitch, verify and record the VLAN IDs used. For dvSwitches, go to Home>> Inventory>> Networking and for each dvSwitch in the inventory, and for each dvPortGroup in each dvSwitch, select Edit Settings>> Policies>> VLAN and record all VLAN IDs.
From the vSphere Client/vCenter: Go to "Home>> Inventory>> Hosts and Clusters". Select each ESXi host with virtual switches connected to active VMs. Go to "Configuration>> Network>> vSwitch(?)>> Properties>> Ports>> [Portgroup Name]>> VLAN ID". Verify the recorded VLAN IDs in the (site-specific) tracking system. If the system VLAN IDs do not match the external VLAN IDs on record, this is a finding.
From the vSphere Client/vCenter: Go to "Home>> Inventory>> Hosts and Clusters". Select each ESXi host with virtual switches connected to active VMs. Go to "Configuration>> Network>> vSwitch(?)>> Properties>> Ports>> [Portgroup Name]>> VLAN ID". Record all VLAN IDs in a (site-specific) tracking system.
If IP-based storage is not used, this check is not applicable. To view the VMkernel Networking configuration, from the vSphere Client/vCenter as administrator: Select the host in the inventory pane. On the host Configuration tab, click Networking. In the vSphere Standard Switch view, select Properties and ensure at least one physical network adaptor is dedicated to a management-only network. If at least one physical network adaptor is not dedicated to a management-only network, this is a finding.
Restrict physical network access to management-only entities. To modify VMkernel Networking configuration, from the vSphere Client/vCenter as administrator: Select the host in the inventory pane. On the host Configuration tab, click Networking. In the vSphere Standard Switch view, select Properties and modify the properties to enforce the dedication of at least one physical network adaptor to management-only.
If IP-based storage is not used, this check is not applicable. To view the VMkernel Networking configuration, from the vSphere Client/vCenter as administrator: Select the host in the inventory pane. On the host Configuration tab, click Networking. In the vSphere Standard Switch view, select Properties and ensure the storage port group is on a management-only vSwitch. If the storage port group is not on a management-only vSwitch, this is a finding.
To restrict physical network access to management-only entities, modify the VMkernel Networking configuration. From the vSphere Client/vCenter as administrator: Select the host in the inventory pane. On the host Configuration tab, click Networking. In the vSphere Standard Switch view, select Properties. Modify the storage port group property to ensure the storage port group is located on a management-only vSwitch.
If IP-based storage is not used, this check is not applicable. To view the VMkernel Networking configuration, from the vSphere Client/vCenter as administrator: Select the host in the inventory pane. On the host Configuration tab, click Networking. In the vSphere Standard Switch view, select Properties and ensure the storage port group vSwitch exclusively contains non-management port groups. If the storage port group vSwitch does not exclusively contain management-only port groups, this is a finding.
To restrict physical network access to management-only entities, modify the VMkernel Networking configuration. From the vSphere Client/vCenter as administrator: Select the host in the inventory pane. On the host Configuration tab, click Networking. In the vSphere Standard Switch view, and select Properties. Modify the storage port group vSwitch property to ensure the storage port group vSwitch exclusively contains management-only port groups.
vSphere permissions to specific port groups must be granted only to individuals who need it. From the vSphere Client/vCenter as a user with full Administrator Role rights to the Inventory object to be checked: Select "[Inventory Object]>> Permissions". Verify that users assigned to the selected Inventory object have the appropriate role. If any user assigned to the selected Inventory object have an inappropriate role, this is a finding.
vSphere permissions to specific port groups must be granted only to individuals who need it. From the vSphere Client/vCenter as a user with full Administrator Role rights to the Inventory object to be checked: (1) Select "[Inventory Object]>> Permissions". Assign users with the appropriate Role to the all Inventory object(s).
Note that this check refers to an entity outside the physical scope of the ESXi server system. The configuration of upstream physical switches must be documented to ensure that spanning tree protocol is disabled and/or portfast is configured for all physical ports connected to ESXi hosts. Inspect the documentation and verify that the documentation is updated on an organization defined frequency and/or whenever modifications are made to either ESXi hosts or the upstream physical switches. Alternatively, log in to the physical switch and verify that spanning tree protocol is disabled and/or portfast is configured for all physical ports connected to ESXi hosts. If the physical switch's spanning tree protocol is not disabled or portfast is not configured for all physical ports connected to ESXi hosts, this is a finding.
Note that this check refers to an entity outside the scope of the ESXi server system. Document the upstream physical switch configuration for spanning tree protocol disablement and/or portfast configuration for all physical ports connected to ESXi hosts. Log in to the physical switch(es) and disable spanning tree protocol and/or configure portfast for all physical ports connected to ESXi hosts. Update the documentation on an organization defined frequency or whenever modifications are made to either ESXi hosts or the upstream physical switches.
From the vSphere Client/vCenter, navigate to Home>> Inventory>> Networking. Individual port groups must be clearly labeled with a meaningful name. If individual port groups are not clearly labeled with a meaningful name, this is a finding.
From the vSphere Client/vCenter, navigate to Home>> Inventory>> Networking. Clearly label all individual port groups with a meaningful name.
Temporarily disable Lockdown Mode and enable the ESXi Shell via the vSphere Client. Open the vSphere/VMware Infrastructure (VI) Client and log in with appropriate credentials. If connecting to vCenter Server, click on the desired host. Click the Configuration tab. Click Software, Security Profile, Services, Properties, ESXi Shell and Options, respectively. Start the ESXi Shell service, where/as required. As root, log in to the ESXi Shell and run the following command. # esxcli network vswitch standard portgroup list If the default value (1) for the native VLAN is being used, this is a finding. Re-enable Lockdown Mode on the host.
Temporarily disable Lockdown Mode and enable the ESXi Shell via the vSphere Client. Open the vSphere/VMware Infrastructure (VI) Client and log in with appropriate credentials. If connecting to vCenter Server, click on the desired host. Click the Configuration tab. Click Software, Security Profile, Services, Properties, ESXi Shell, and Options, respectively. Start the ESXi Shell service, where/as required. As root, log in to the ESXi Shell and run the command to set the value to something other than the default value. esxcli network vswitch standard portgroup set --portgroup-name=<name> --vlan-id=<non-default_id_number> Re-enable Lockdown Mode on the host.
Temporarily disable Lockdown Mode and enable the ESXi Shell via the vSphere Client. Open the vSphere/VMware Infrastructure (VI) Client and log in with appropriate credentials. If connecting to vCenter Server, click on the desired host. Click the Configuration tab. Click Software, Security Profile, Services, Properties, ESXi Shell, and Options, respectively. Start the ESXi Shell service, where/as required. As root, log in to the ESXi Shell and run the following command. # esxcli network vswitch standard portgroup list If the VGT value (4095) is set and the guest is not configured to handle VLAN tags, this is a finding. Re-enable Lockdown Mode on the host.
Temporarily disable Lockdown Mode and enable the ESXi Shell via the vSphere Client. Open the vSphere/VMware Infrastructure (VI) Client and log in with appropriate credentials. If connecting to vCenter Server, click on the desired host. Click the Configuration tab. Click Software, Security Profile, Services, Properties, ESXi Shell, and Options, respectively. Start the ESXi Shell service, where/as required. As root, log in to the ESXi Shell and run the command to set the value to something other than the VGT 4095 value. esxcli network vswitch standard portgroup set --portgroup-name=<name> --vlan-id=<non-default_id_number> Re-enable Lockdown Mode on the host.
Temporarily disable Lockdown Mode and enable the ESXi Shell via the vSphere Client. Open the vSphere/VMware Infrastructure (VI) Client and log in with appropriate credentials. If connecting to vCenter Server, click on the desired host. Click the Configuration tab. Click Software, Security Profile, Services, Properties, ESXi Shell and Options, respectively. Start the ESXi Shell service, where/as required. Determine the site-specific switch reserved VLAN, configuration requirements via vendor documentation. For example, Cisco Catalyst switches typically reserve VLANs 1001-1024 and 4094 and Nexus switches typically reserve 3968-4047 and 4094. As root, log in to the ESXi Shell and run the command: # esxcli network vswitch standard portgroup list If the VLAN ID is set to a vendor-reserved value, this is a finding. Re-enable Lockdown Mode on the host.
Temporarily disable Lockdown Mode and enable the ESXi Shell via the vSphere Client. Open the vSphere/VMware Infrastructure (VI) Client and log in with appropriate credentials. If connecting to vCenter Server, click on the desired host. Click the Configuration tab. Click Software, Security Profile, Services, Properties, ESXi Shell, and Options, respectively. Start the ESXi Shell service, where/as required. As root, log in to the ESXi Shell and run the command to set the value to something other than the vendor-specific reserved value. esxcli network vswitch standard portgroup set --portgroup-name=<name> --vlan-id=<non-default_id_number>; Re-enable Lockdown Mode on the host.
The "Forged Transmits" parameter must be set to "Reject" on all vSwitches. From the vSphere Client/vCenter as administrator, verify by using the vSphere Client to connect to the vCenter Server and as administrator: 1. Go to "Home > Inventory > Hosts and clusters". 2. Select each ESXi host with active virtual switches connected to active VM's requiring securing. 3. Go to tab "Configuration > Network > vSwitch(?) > Properties > Ports > vSwitch > Default Policies > Security" 4. "Forged Transmits" = "Reject" If the "Forged Transmits" parameter is not set to "Reject" on all vSwitches, this is a finding.
The "Forged Transmits" parameter must be set to "Reject" on all vSwitches. From the vSphere Client/vCenter as administrator, using the vSphere Client to connect to the vCenter Server and as administrator: 1. Go to "Home > Inventory > Hosts and clusters". 2. Select each ESXi host with active virtual switches connected to active VM's requiring securing. 3. Go to tab "Configuration > Network > vSwitch(?) > Properties > Ports > vSwitch > Default Policies > Security" 4. Set "Forged Transmits" = "Reject".
If a vNetwork Distributed Switch (vDS) is not configured, this is not applicable. The "Forged Transmits" parameter must be set to "Reject" on all dvPortgroups. From the vSphere Client/vCenter as administrator: Go to Home >> Inventory >> Networking. Select each dvPortgroup connected to VMs. Go to tab Summary >> Edit Settings >> Policies >> Security. Verify "Forged Transmits" = "Reject". If the "Forged Transmits" parameter is not set to "Reject" on all dvPortgroups, this is a finding.
The "Forged Transmits" parameter must be set to "Reject" on all dvPortgroups. From the vSphere Client/vCenter as administrator: Go to Home >> Inventory >> Networking. Select each dvPortgroup connected to VMs. Go to tab Summary >> Edit Settings >> Policies >> Security. Set "Forged Transmits" = "Reject".
If a vNetwork Distributed Switch (vDS) is not configured, this is not applicable. Check the setting by using the vSphere Client to connect to the vCenter Server and as administrator: Go to Home >> Inventory >> Networking. Select each dvPortgroup connected to active VMs requiring securing. Go to tab Summary >> Edit Settings >> Policies >> Security. Check the "Mac Address Changes" = "Reject". If the VM/guest OS/application requires a specific MAC Address parameter setting for normal operation and is placed in a separate, specially-configured dvPortgroup ( with "Mac Address Changes" = "Accept") on the vDistributed Switch (vDS), this is not a finding. If the VM/guest OS/application does not require a specific MAC Address parameter setting for normal operation and the "Mac Address Changes" parameter is not set to "Reject", this is a finding.
Verify by using the vSphere Client to connect to the vCenter Server and as administrator: Go to Home >> Inventory >> Networking. Select each dvPortgroup connected to active VMs requiring securing. Go to tab Summary >> Edit Settings >> Policies >> Security. Change the "Mac Address Changes" = "Reject".
From the vSphere Client, connect to the vCenter Server and as administrator: Go to "Home>> Inventory>> Hosts and clusters". Select each ESXi host with active virtual switches connected to active VMs requiring securing. Go to tab "Configuration>> Network>> vSwitch(?)>> Properties>> Ports>> vSwitch>> Default Policies>> Security". Verify the "Mac Address Changes" = "Reject". If the VM/guest OS/application requires a specific MAC Address parameter setting for normal operation and is placed in a separate, specially-configured Portgroup ( with "Mac Address Changes" = "Accept") on the vSwitch, this is not a finding. If the VM/guest OS/application does not require a specific MAC Address parameter setting for normal operation and the "Mac Address Changes" parameter is not set to "Reject", this is a finding.
From the vSphere Client, connect to the vCenter Server and as administrator: Go to "Home>> Inventory>> Hosts and clusters". Select each ESXi host with active virtual switches connected to active VMs requiring securing. Go to tab "Configuration>> Network>> vSwitch(?)>> Properties>> Ports>> vSwitch>> Default Policies>> Security". Change the "Mac Address Changes" = "Reject".
Note that this check refers to an entity outside the physical scope of the ESXi server system. The configuration of external switch ports as trunk ports must be documented. Virtual Switch Tagging (VST) mode does not support Dynamic Trunking Protocol (DTP), so the trunk must be static and unconditional. Inspect the documentation and verify that the documentation is correct and updated on an organization defined frequency and/or whenever modifications are made to either ESXi hosts or the upstream external switch ports. If DTP is enabled on the physical switch ports connected to the ESXi Host, this is a finding.
Note that this check refers to an entity outside the physical scope of the ESXi server system. Document the configuration of external switch ports as trunk ports. Log in to the vendor-specific physical switch and disable DTP on the physical switch ports connected to the ESXi Host. Update the documentation on an organization defined frequency or whenever modifications are made to either ESXi hosts or the upstream external switch ports.
Use the vSphere Client to connect to the vCenter Server and as administrator: Go to "Home > Inventory > Hosts and clusters". Select each ESXi host with active virtual switches connected to active VM's requiring securing. Go to the tab "Configuration >> Network >> vSwitch(?) >> Properties >> Ports >> vSwitch >> Default Policies >> Security". Check that the "Promiscuous Mode" is set to "Reject". If the "Promiscuous Mode" is not set to "Reject", this is a finding.
From the vSphere Client/vCenter Server as administrator: Go to "Home>> Inventory>> Hosts and clusters". Select each ESXi host with active virtual switches connected to active VMs requiring securing. Go to tab "Configuration>> Network>> vSwitch(?)>> Properties>> Ports>> vSwitch>> Default Policies>> Security". Set "Promiscuous Mode" = "Reject".
If a vNetwork Distributed Switch (vDS) is not configured, this is not applicable. If the dvPortgroup contains only security devices that continuously monitor all dvPortgroup traffic switch packets, this check is not a finding. From the vSphere Client/vCenter Server as administrator: Go to Home >> Inventory >> Hosts and clusters. Select each ESXi host with active virtual switches connected to active VMs requiring securing. Go to tab Home >> Inventory >> Networking. Individually select each dvPortgroup, then go to tab Summary >>Edit Settings >>Policies >> Security. Verify "Promiscuous Mode" = "Reject". If the "Promiscuous Mode" parameter is not set to "Reject", this is a finding.
From the vSphere Client/vCenter Server as administrator: Go to Home >> Inventory >> Hosts and clusters. Select each ESXi host with active virtual switches connected to active VMs requiring securing. Go to tab Home >> Inventory >> Networking. Individually select each dvPortgroup, then go to tab Summary >> Edit Settings >> Policies >> Security. Set the "Promiscuous Mode" keyword to "Reject".
If a vNetwork Distributed Switch (vDS) is not configured, this is not applicable. As administrator, find all dvSwitches from the vSphere Client/vCenter, Home >> Inventory >> Networking view. For any dvSwitches with dvPortgroups, verify the settings for that dvPortgroup. Compare the number of ports in that port group to the number of vNICs connecting to that port group. The number of ports must match, or approximate to the nearest number of menu selectable ports, the number of vNICs residing in that port group. If the number of ports in the port group do not match (or approximate to the nearest number of menu selectable ports) the number of VM NICs connecting to that port group, this is a finding.
As administrator, find all dvSwitches from the vSphere Client/vCenter: Home >> Inventory >> Networking view. For dvSwitches with dvPortgroups, edit the settings for that dvPortgroup. Limit (match or approximate) the number of ports in that port group to the number of vNICs residing in that port group.
If vMotion is not used, this check is not applicable. The vMotion port group must be on a management-only vSwitch to avoid dependency on VLANs for isolation. Verify the vMotion port group vSwitch does not contain any non-management port groups. At least one physical network adaptor must be dedicated to management. To ensure a vMotion vSwitch is on a VMkernel management-only switch, from the vSphere Client/vCenter, select the ESXi host, and select the configuration tab. In the hardware panel, select Networking; locate the vSwitch containing the vMotion port group and visually verify that the vSwitch does not contain any VM Networking or VM references, i.e., the vSwitch must contain management-only, non-production network traffic/functions. If the vMotion port group is not on a management-only vSwitch, this is a finding.
To create a vMotion vSwitch from the vSphere Client/vCenter, select the ESXi host, and select the configuration tab. In the hardware panel, select Networking; click the Add Network link; choose VMKernel and click next; select the desired NIC(s). In the port groups dialog box type a name, (example: "vMotion"). Next, select the "use this port group for vMotion" and set the IP address and subnet mask and gateway where/as required.
Organization and vendor specific check. Ask the SA if any ESXi host guest VM is configured to perform a bridging function. If any host VM is configured to perform a bridging function, ask the SA to confirm that port spanning tree protocol is enabled. Note that this check refers to an entity outside the scope of the ESXi server system. If a guest VM is configured to perform a bridging function and spanning tree protocol is not enabled, this is a finding.
Organization and vendor specific fix. If a guest VM is configured to perform a bridging function, enable spanning tree protocol for the VMs switch port. Note that this check refers to an entity outside the scope of the ESXi server system.
If a vNetwork Distributed Switch (vDS) is not configured, this is not applicable. Temporarily disable Lockdown Mode and enable the ESXi Shell via the vSphere Client. 1. Open the vSphere/VMware Infrastructure (VI) Client and log in with appropriate credentials. 2. If connecting to vCenter Server, click on the desired host. 3. Click the Configuration tab. 4. Click Software, Security Profile, Services, Properties, ESXi Shell and Options, respectively. 5. Start the ESXi Shell service, where/as required. As root, log in to the ESXi Shell and determine if the managed object browser (MOB) is enabled: # vim-cmd proxysvc/service_list | grep proxy-mob If the command return lists "proxy-mob", the mob is enabled. If not, re-enable the MOB: # vim-cmd proxysvc/add_np_service "/mob" httpsWithRedirect /var/run/vmware/proxy-mob The autoexpand property is disabled by default, but it can be enabled using the MOB: 1. In a browser, enter the address http://vc-ip-address/mob/. 2. When prompted, enter the vCenter Server appropriate username and password. 3. Click the Content link. 4. In the left pane, search for the row with the word rootFolder. 5. Open the link in the right pane of the row. The link should be similar to group-d1 (Datacenters). 6. In the left pane, search for the row with the word childEntity. In the right pane, you see a list of datacenter links. 7. Click the datacenter link in which the vDS is defined. 8. In the left pane, search for the row with the word networkFolder and open the link in the right pane. The link should be similar to group-n123 (network). 9. In the left pane, search for the row with the word childEntity. You see a list of vDS and distributed port group links in the right pane. 10.Click the distributed port group for which you want to change this property. 11.In the left pane, search for the row with the word config and click the link in the right pane. 12.In the left pane, search for the row with the word autoExpand. It is usually the first row. 13.Note the corresponding value displayed in the right pane. The value should be false by default. If the setting is true, the autoexpand feature is enabled and this is a finding. Disable the MOB. # vim-cmd proxysvc/remove_service "/mob" "httpsWithRedirect" Re-enable Lockdown Mode on the host.
Temporarily disable Lockdown Mode and enable the ESXi Shell via the vSphere Client. 1. Open the vSphere/VMware Infrastructure (VI) Client and log in with appropriate credentials. 2. If connecting to vCenter Server, click on the desired host. 3. Click the Configuration tab. 4. Click Software, Security Profile, Services, Properties, ESXi Shell and Options, respectively. 5. Start the ESXi Shell service, where/as required. As root, log in to the ESXi Shell and determine if the managed object browser (MOB) is enabled: # vim-cmd proxysvc/service_list | grep proxy-mob If the command return lists "proxy-mob", the mob is enabled. If not, re-enable the MOB: # vim-cmd proxysvc/add_np_service "/mob" httpsWithRedirect /var/run/vmware/proxy-mob The autoexpand property is disabled by default, but it can be enabled using the MOB: 1. In a browser, enter the address http://vc-ip-address/mob/. 2. When prompted, enter the vCenter Server appropriate username and password. 3. Click the Content link. 4. In the left pane, search for the row with the word rootFolder. 5. Open the link in the right pane of the row. The link should be similar to group-d1 (Datacenters). 6. In the left pane, search for the row with the word childEntity. In the right pane, you see a list of datacenter links. 7. Click the datacenter link in which the vDS is defined. 8. In the left pane, search for the row with the word networkFolder and open the link in the right pane. The link should be similar to group-n123 (network). 9. In the left pane, search for the row with the word childEntity. You see a list of vDS and distributed port group links in the right pane. 10.Click the distributed port group for which you want to change this property. 11.In the left pane, search for the row with the word config and click the link in the right pane. 12.In the left pane, search for the row with the word autoExpand. It is usually the first row. 13.Note the corresponding value displayed in the right pane. The value should be false by default. 14. In the left pane, search for the row with the word configVersion. The value should be 1 only if it has not been previously modified. 15. Note the corresponding value displayed in the right pane as it is needed in step 18. 16. Go back to the distributed port group page. 17. Click the link that reads ReconfigureDvs_Task. A new window appears. 18. In the Spec text field, enter this text: <spec><autoExpand>false</autoExpand><configversion>configVersion</configversion></spec> where configVersion is what was recorded directly above in step 15. 19. Click the Invoke Method link. 20. Close the window. 21. Repeat Steps 10 through 14 to verify the new value for autoExpand. Disable the MOB. # vim-cmd proxysvc/remove_service "/mob" "httpsWithRedirect" Re-enable Lockdown Mode on the host.
Temporarily disable Lockdown Mode and enable the ESXi Shell via the vSphere Client. Open the vSphere/VMware Infrastructure (VI) Client and log in with appropriate credentials. If connecting to vCenter Server, click on the desired host. Click the Configuration tab. Click Software, Security Profile, Services, Properties, ESXi Shell and Options, respectively. Start the ESXi Shell service, where/as required. As root, log in to the host. Check the system for NFS mounts that do not use the nodev option. Execute the following: # cat /etc/fstab | grep -i nfs | grep -v "nodev" If the mounted NFS file systems do not use the nodev option, this is a finding. Re-enable Lockdown Mode on the host.
Temporarily disable Lockdown Mode and enable the ESXi Shell via the vSphere Client. Open the vSphere/VMware Infrastructure (VI) Client and log in with appropriate credentials. If connecting to vCenter Server, click on the desired host. Click the Configuration tab. Click Software, Security Profile, Services, Properties, ESXi Shell and Options, respectively. Start the ESXi Shell service, where/as required. As root, log in to the host. Edit /etc/fstab and add the nodev option for all NFS file systems. Re-enable Lockdown Mode on the host.
Disable lock down mode. Enable the ESXi Shell. <file> = /etc/vmware/config <required_keyword> = libdir <required_keyword_setpoint> = /usr/lib/vmware Execute the following command(s): # grep libdir /etc/vmware/config If the "libdir" path is not set to "/usr/lib/vmware", this is a finding. Re-enable lock down mode.
Disable lock down mode. Enable the ESXi Shell. <file> = /etc/vmware/config <required_keyword> = libdir <required_keyword_setpoint> = /usr/lib/vmware Execute the following command(s): # vi /etc/vmware/config Set the "libdir" path to "/usr/lib/vmware". Re-enable lock down mode.
Disable lock down mode. Enable the ESXi Shell. Execute the following command(s): # grep LD_PRELOAD /etc/vmware/config If the LD_PRELOAD attribute is present and set to anything other than an empty string, this is a finding. Re-enable lock down mode.
Disable lock down mode. Enable the ESXi Shell. Execute the following command(s): # vi /etc/vmware/config Set the LD_PRELOAD to "". Re-enable lock down mode.
Note: Checking a system's BIOS is vendor and hardware dependent. To verify media boot options: Interrupt the host computer's boot process and enter the BIOS menu. Inspect the menu option for boot order. If any media other than the ESXi boot disk is listed as a boot option, this is a finding.
Note: Checking a system's BIOS is vendor and hardware dependent. To ensure media boot options: Interrupt the host computer's boot process and enter the BIOS menu. Inspect the menu option for boot order. Remove all boot media options except for ESXi. Save the change and exit to verify the boot cycle.
For ESXi hosts that are not managed by a vCenter Server, this check is not applicable. From the vSphere client, select the host then select "Configuration >> Security Profile". Verify Lockdown Mode is enabled. Alternatively, issue the following command via the CLI: # vim-cmd vimsvc/auth/lockdown_is_enabled If Lockdown Mode is not enabled (true), this is a finding.
To enable Lockdown mode on an ESXi host managed by a vCenter Server, log in directly the ESXi host as root. Open the DCUI on the host. Press F2 for Initial Setup. Toggle the Configure Lockdown Mode setting and configure Lockdown Mode.
Temporarily disable Lockdown Mode and enable the ESXi Shell via the vSphere Client. Open the vSphere/VMware Infrastructure (VI) Client and log in with appropriate credentials. If connecting to vCenter Server, click on the desired host. Click the Configuration tab. Click Software, Security Profile, Services, Properties, ESXi Shell and Options, respectively. Start the ESXi Shell service, where/as required. As root, log in to the ESXi Shell and execute the following: # egrep -v "^sshd|authd" /var/run/inetd.conf> The above command filters for services other than sshd and/or authd. If any other services are found, ask the SA if the services are required (i.e., required by 3rd party software). If services other than sshd and/or authd are found and cannot be accounted for, this is a finding. Re-enable Lockdown Mode on the host.
Temporarily disable Lockdown Mode and enable the ESXi Shell via the vSphere Client. Open the vSphere/VMware Infrastructure (VI) Client and log in with appropriate credentials. If connecting to vCenter Server, click on the desired host. Click the Configuration tab. Click Software, Security Profile, Services, Properties, ESXi Shell and Options, respectively. Start the ESXi Shell service, where/as required. As root, log in to the ESXi Shell and edit the /var/run/inetd.conf file. Comment (do not remove) any service line entries that cannot be accounted for. Re-enable Lockdown Mode on the host.
The downloaded ISO, offline bundle, or patch hash must be verified against the vendor's checksum to ensure the integrity and authenticity of the files. See some typical command line example(s) for both the md5 and sha1 hash check(s) directly below. # md5sum <filename>.iso # sha1sum <filename>.iso If any of the system's downloaded ISO, offline bundle, or system patch hashes cannot be verified against the vendor's checksum, this is a finding.
If the hash returned from the md5sum or sha1sum commands do not match the vendor's hash, the downloaded software must be discarded. If the physical media is obtained from VMware and the security seal is broken, the software must be returned to VMware for replacement.
Disable lock down mode. Enable the ESXi Shell. Execute the following command(s): # cat /etc/passwd If any non-unique user name is found (example: multiple root user name entries), this is a finding. Re-enable lock down mode.
Change user account names, or delete accounts, so each account has a unique name. From the vSphere Client/vCenter: Click on the "Users and Groups" tab. Click on the "Users" button. Right click and select "Add". Specify the desired User Name, Password, etc and Click "OK".
Disable lock down mode. Enable the ESXi Shell. Execute the following command(s): # cat /etc/passwd | cut -f 3 -d ":" | sort If any duplicate UIDs are found, this is a finding. Re-enable lock down mode.
Modify user accounts to provide unique UIDs for each account. From the vSphere Client/vCenter: Click on the "Users and Groups" tab. Click on the "Users" button Right click and select "Add". Specify the desired User Name, Password, etc and Click "OK".
From the vSphere client, select the ESXi host, go to "Configuration >> Security Profile". In the "Services" section select "Properties". Verify 'SSH' is stopped. If the SSH service is running, this is a finding.
From the vSphere client, select the ESXi host, go to "Configuration >> Security Profile". In the "Services" section select "Properties". Select "SSH", "Options..." and configure the 'SSH' option to "Start and stop manually".
For ESXi hosts that are not managed by a vCenter Server, this check is not applicable. Disable lock down mode. Enable the ESXi Shell. Execute the following command(s): # grep PermitRootLogin /etc/ssh/sshd_config If "PermitRootLogin" is set to "yes", this is a finding. Re-enable lock down mode.
This step assumes that root access to the system is available via the vSphere Client/vCenter Server, local availability via the DCUI, or that remote systems are accessible at the remote site via touch labor by an authorized (root) user. Disable lock down mode. Enable the ESXi Shell. Execute the following command(s): # vi /etc/ssh/sshd_config Add/modify the attribute line entry to the following (quotes for emphasis only): "PermitRootLogin no" Re-enable lock down mode.
From the vSphere client select the host and click "Configuration >> Advanced Settings". Select "UserVars.ESXiShellTimeOut" parameter and verify it is set to a value not to exceed 900 seconds (15 minutes). A value of 0 disables the ESXi Shell timeout. If the "UserVars.ESXiShellTimeOut" parameter is set to a value less than 1 or greater than 900, this is a finding.
From the vSphere client select the host and click "Configuration >> Advanced Settings". Select UserVars.ESXiShellTimeOut parameter and configure it to a value not to exceed 900 seconds (15 minutes). A value of 0 disables the ESXi Shell timeout.
The ESXi server's vSphere management port group should be in a dedicated VLAN on a common vSwitch. The vSwitch can be shared with production (virtual machine) traffic, as long as the vSphere management port group's VLAN is not used by production virtual machines. Check that the network segment is not routed, except possibly to networks where other management-related entities are found. Production virtual machine traffic must not be routed to this network. As root (or using a different administrator Active Directory account), from the vSphere Client/vCenter, select the host; select the Configuration tab; then select Hardware/Networking. Select switch Properties for the Management Network NIC, and in the Ports tab, verify that the Management Port Group list does not include any production virtual machine traffic. If the network segment is routed, except to networks where other management-related entities are located, this is a finding. If production virtual machine traffic is routed to this network, this is a finding. Note that this check refers to an entity outside the scope of the ESXi server system.
The vSphere management port group should be in a dedicated VLAN on a common vSwitch. The vSwitch can be shared with production (virtual machine) traffic, as long as the vSphere management port group's VLAN is not used by production virtual machines. As root (or using a different administrator Active Directory account), from the vSphere Client/vCenter, select the host; select the Configuration tab; then select Hardware/Networking. Select switch Properties for the Management Network NIC, and select the Ports tab. If any virtual machine traffic is found in the port list, create another vSwitch and migrate either the Management Port group or virtual machine traffic to a different vSwitch. Under the Configuration tab, select the Add Networking wizard, select either the Virtual Machine or VMkernel radio button, click Next and follow the directions for selecting the remaining switch type and connection settings based on the local system's hardware.
Disable lock down mode. Enable the ESXi Shell. Execute the following command to inspect the /etc/issue (or otherwise configured) SSHD banner file: # cat /etc/issue Access the system console and make a logon attempt. Check for either of the following login banners based on the character limitations imposed by the system. An exact match is required. If one of these banners is not displayed, this is a finding. "You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only. By using this IS (which includes any device attached to this IS), you consent to the following conditions: -The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations. -At any time, the USG may inspect and seize data stored on this IS. -Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose. -This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy. -Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details. " OR "I've read & consent to terms in IS user agreem't." If the /etc/issue (or otherwise configured) SSHD banner file does not contain one of the two login banners exactly as shown above, this is a finding. Re-enable lock down mode.
Configure the /etc/issue (or otherwise configured) SSHD banner file in order to display one of the DoD login banners (based on the character limitations imposed by the system) prior to any local login attempt. DoD Login Banners: You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only. By using this IS (which includes any device attached to this IS), you consent to the following conditions: -The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations. -At any time, the USG may inspect and seize data stored on this IS. -Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose. -This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy. -Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details. OR I've read & consent to terms in IS user agreem't.
From the vSphere Client/vCenter: Click on the Configuration tab, Click on the DNS and Routing tabs, and verify that the default gateway information is entered and Click "Cancel". If the default gateway field has not been initialized (IP address is required), this is a finding.
From the vSphere Client/vCenter, click on the Configuration tab; click on DNS and Routing; click on Properties/DNS and Routing, Configuration/Routing. Add a default gateway (IP address is required). Click "OK"
From the vSphere client, select the host, then select "Configuration >> Security Profile". In the "Firewall" section select "Properties". For each enabled service, (e.g., ssh, vSphere Web Access, http client), select "Firewall", and verify "Only allow connections from the following networks" is selected and a range of authorized IP addresses is listed. If any enabled service's firewall entry is not configured for "Only allow connections from the following networks" with a range of authorized IP addresses listed, this is a finding.
For each host, from the vSphere client, select the host and go to "Configuration >> Security Profile". In the "Firewall" section select "Properties". For each enabled service, (e.g., ssh, vSphere Web Access, http client), select "Firewall", select "Only allow connections from the following networks", and provide a range of authorized IP addresses.
From the vSphere client, select the host, then select "Configuration >> Security Profile". In the "Firewall" section select "Properties". For each enabled service, (e.g., ssh, vSphere Web Access, http client), select "Firewall", and verify "Only allow connections from the following networks" is selected and a range of authorized IP addresses is listed. If any enabled service's firewall entry is not configured for "Only allow connections from the following networks" with a range of authorized IP addresses listed, this is a finding.
For each host, from the vSphere client, select the host and go to "Configuration >> Security Profile". In the "Firewall" section select "Properties". For each enabled service, (e.g., ssh, vSphere Web Access, http client), select "Firewall", select "Only allow connections from the following networks", and provide a range of authorized IP addresses.
From the vSphere client, select the host, then select "Configuration >> Security Profile". In the "Firewall" section select "Properties". For each enabled service, (e.g., ssh, vSphere Web Access, http client), select "Firewall", and verify "Only allow connections from the following networks" is selected and a range of authorized IP addresses is listed. If any enabled service's firewall entry is not configured for "Only allow connections from the following networks" with a range of authorized IP addresses listed, this is a finding.
For each host, from the vSphere client, select the host and go to "Configuration >> Security Profile". In the "Firewall" section select "Properties". For each enabled service, (e.g., ssh, vSphere Web Access, http client), select "Firewall", select "Only allow connections from the following networks", and provide a range of authorized IP addresses.
From the vSphere client, select the host, then select "Configuration >> Security Profile". In the "Firewall" section select "Properties". For each enabled service, (e.g., ssh, vSphere Web Access, http client), select "Firewall", and verify "Only allow connections from the following networks" is selected and a range of authorized IP addresses is listed. If any enabled service's firewall entry is not configured for "Only allow connections from the following networks" with a range of authorized IP addresses listed, this is a finding.
For each host, from the vSphere client, select the host and go to "Configuration >> Security Profile". In the "Firewall" section select "Properties". For each enabled service, (e.g., ssh, vSphere Web Access, http client), select "Firewall", select "Only allow connections from the following networks", and provide a range of authorized IP addresses.
Ask the SA if a controlled gateway or other controlled access method to the management network has been implemented and documented. Ask to see the documentation. Note that this check refers to an entity outside the scope of the ESXi server system. If a controlled gateway or other controlled access method has not been implemented or documented, this is a finding.
Implement and document a controlled gateway or other controlled access method to the management network. Note that this check refers to an entity outside the scope of the ESXi server system.
Ask the SA if a management network jump box has been implemented and documented. Ask to see the documentation. Note that this check refers to an entity outside the scope of the ESXi server system. If a management network jump box has not been implemented or documented, this is a finding.
Implement and document a management network jump box solution. Note that this check refers to an entity outside the scope of the ESXi server system.
Disable lock down mode. Enable the ESXi Shell. Check the SSH client configuration for allowed ciphers. # grep -i ciphers /etc/ssh/ssh_config | grep -v '^#' Re-enable lock down mode. If the returned ciphers list contains any cipher ending with cbc, this is a finding. If the /etc/ssh/ssh_config file does not exist or the Ciphers option is not set, this is not a finding.
Disable lock down mode. Enable the ESXi Shell. Edit the SSH client configuration and add/modify the "Ciphers" configuration (examples of disallowed ciphers: aes128-cbc, aes192-cbc, aes256-cbc, arcfour256blowfish-cbc, cast128-cbc, 3des-cbc). # vi /etc/ssh/ssh_config Re-enable lock down mode.
Disable lock down mode. Enable the ESXi Shell. Execute the following command(s): # grep -i macs /etc/ssh/ssh_config Re-enable lock down mode. If the returned list contains MACs other than a variant of the hmac-sha1 or hmac-sha2 form, this is a finding. If the /etc/ssh/ssh_config file does not exist or the MACs option is not set, this is not a finding.
Disable lock down mode. Enable the ESXi Shell. Execute the following command(s): # vi /etc/ssh/ssh_config Add/modify the attribute line entry to the following (quotes for emphasis only): "MACs <hmac-sha1 or hmac-sha2 variant(s)>" The above list "may" include any number of the following (current) comma-separated variants: hmac-sha1, hmac-sha1-96, hmac-sha2-256, hmac-sha2-256-96, hmac-sha2-512, hmac-sha2-512-96. Re-enable lock down mode.
Disable lock down mode. Enable the ESXi Shell. Check the SSH client configuration for allowed ciphers. # grep -i ciphers /etc/ssh/ssh_config | grep -v '^#' If the returned ciphers list contains any cipher not starting with 3des or aes, this is a finding. If the /etc/ssh/ssh_config file does not exist or the Ciphers option is not set, this is not a finding. Re-enable lock down mode.
Disable lock down mode. Enable the ESXi Shell. Edit the SSH client configuration and add/modify the "Ciphers" configuration (example: 3des-ctr, aes128-ctr, aes192-ctr, aes256-ctr). # vi /etc/ssh/ssh_config Re-enable lock down mode.
From the vSphere client select the host and click "Configuration >> Advanced Settings". Select "UserVars.ESXiShellTimeOut" parameter and verify it is set to a value not to exceed 900 seconds (15 minutes). A value of 0 disables the ESXi Shell timeout. If the "UserVars.ESXiShellTimeOut" parameter is set to a value less than 1 or greater than 900, this is a finding.
From the vSphere client select the host and click "Configuration >> Advanced Settings". Select UserVars.ESXiShellTimeOut parameter and configure it to a value not to exceed 900 seconds (15 minutes). A value of 0 disables the ESXi Shell timeout.
Temporarily disable Lockdown Mode and enable the ESXi Shell via the vSphere Client. Open the vSphere/VMware Infrastructure (VI) Client and log in with appropriate credentials. If connecting to vCenter Server, click on the desired host. Click the Configuration tab. Click Software, Security Profile, Services, Properties, ESXi Shell, and Options, respectively. Start the ESXi Shell service, where/as required. As root, log in to the host and verify the host and VIB acceptance level(s) are not set to "CommunitySupported" by running the command(s): # esxcli software acceptance get # esxcli software vib list. If the host or listed VIB acceptance levels allow "CommunitySupported", this is a finding. Re-enable Lockdown Mode on the host.
Temporarily disable Lockdown Mode and enable the ESXi Shell via the vSphere Client. Open the vSphere/VMware Infrastructure (VI) Client and log in with appropriate credentials. If connecting to vCenter Server, click on the desired host. Click the Configuration tab. Click Software, Security Profile, Services, Properties, ESXi Shell and Options, respectively. Start the ESXi Shell service, where/as required. As root, log in to the host and set the host acceptance level to at least "PartnerSupported" by running the command: # esxcli software acceptance set --<level> Re-enable Lockdown Mode on the host.
Verify the vSphere Syslog Collector syslog host has been configured. From the vSphere Client: Select the host and click "Configuration >> Advanced Settings >> Syslog >> Global". Verify the 'Syslog.global.logHost' is set to the (site-specific) syslog server hostname. If the 'Syslog.global.logHost' is unconfigured, this is a finding.
Step 1: Verify the vSphere Syslog Collector syslog host has been configured. If not, install/enable the vSphere Syslog Collector. Step 2: From the vSphere Client: Select the host and click "Configuration >> Advanced Settings >> Syslog >> Global". Step 3: Set 'Syslog.global.logHost' to the syslog server hostname.
Verify the vSphere Syslog Collector syslog host has been configured. From the vSphere Client: Select the host and click "Configuration >> Advanced Settings >> Syslog >> Global". Verify the 'Syslog.global.logHost' is set to the (site-specific) syslog server hostname. If the 'Syslog.global.logHost' is unconfigured, this is a finding.
Step 1: Verify the vSphere Syslog Collector syslog host has been configured. If not, install/enable the vSphere Syslog Collector. Step 2: From the vSphere Client: Select the host and click "Configuration >> Advanced Settings >> Syslog >> Global". Step 3: Set 'Syslog.global.logHost' to the syslog server hostname.
Verify the vSphere Syslog Collector syslog host has been configured. From the vSphere Client: Select the host and click "Configuration >> Advanced Settings >> Syslog >> Global". Verify the 'Syslog.global.logHost' is set to the (site-specific) syslog server hostname. If the 'Syslog.global.logHost' is unconfigured, this is a finding.
Step 1: Verify the vSphere Syslog Collector syslog host has been configured. If not, install/enable the vSphere Syslog Collector. Step 2: From the vSphere Client: Select the host and click "Configuration >> Advanced Settings >> Syslog >> Global". Step 3: Set 'Syslog.global.logHost' to the syslog server hostname.
Disable lock down mode. Enable the ESXi Shell. Check the SSH daemon configuration for required protocol. # grep -i "Protocol 2" /etc/ssh/sshd_config | grep -v '^#' Re-enable lock down mode. If no lines are returned, or the returned protocol list contains anything except 2, this is a finding.
Disable lock down mode. Enable the ESXi Shell. Edit the SSH daemon configuration and add/modify the "Protocol" configuration for Protocol 2 only. # vi /etc/ssh/sshd_config Re-enable lock down mode.
Disable lock down mode. Enable the ESXi Shell. Check the SSH daemon configuration for required protocol. # grep -i "Protocol 2" /etc/ssh/sshd_config | grep -v '^#' Re-enable lock down mode. If no lines are returned, or the returned protocol list contains anything except 2, this is a finding.
Disable lock down mode. Enable the ESXi Shell. Edit the SSH daemon configuration and add/modify the "Protocol" configuration for Protocol 2 only. # vi /etc/ssh/sshd_config Re-enable lock down mode.
Disable lock down mode. Enable the ESXi Shell. Check the SSH client configuration for required protocol. # grep -i "Protocol 2" /etc/ssh/ssh_config | grep -v '^#' Re-enable lock down mode. If the returned protocol list contains anything except 2, this is a finding. If the /etc/ssh/ssh_config file does not exist or the Protocol option is not set, this is not a finding.
Disable lock down mode. Enable the ESXi Shell. Edit the SSH client configuration and add/modify the "Protocol" configuration for Protocol 2 only. # vi /etc/ssh/ssh_config Re-enable lock down mode.
Disable lock down mode. Enable the ESXi Shell. Check the SSH client configuration for required protocol. # grep -i "Protocol 2" /etc/ssh/ssh_config | grep -v '^#' Re-enable lock down mode. If the returned protocol list contains anything except 2, this is a finding. If the /etc/ssh/ssh_config file does not exist or the Protocol option is not set, this is not a finding because the SSH client cannot enforce the Protocol setting on a compliant SSH server.
Disable lock down mode. Enable the ESXi Shell. Edit the SSH client configuration and add/modify the "Protocol" configuration for Protocol 2 only. # vi /etc/ssh/ssh_config Re-enable lock down mode.
Disable lock down mode. Enable the ESXi Shell. Execute the following command(s): # grep -i macs /etc/ssh/sshd_config Re-enable lock down mode. If the command returns nothing, or the returned list contains MACs other than a variant of the hmac-sha1 or hmac-sha2 format, this is a finding.
Disable lock down mode. Enable the ESXi Shell. Execute the following command(s): # vi /etc/ssh/sshd_config Add/modify the attribute line entry to the following (quotes for emphasis only): "MACs <hmac-sha1 or hmac-sha2 variant(s)>" The above list "may" include any number of the following (current) comma-separated variants: hmac-sha1, hmac-sha1-96, hmac-sha2-256, hmac-sha2-256-96, hmac-sha2-512, hmac-sha2-512-96. Re-enable lock down mode.
Temporarily disable Lockdown Mode and enable the ESXi Shell via the vSphere Client. Open the vSphere/VMware Infrastructure (VI) Client and log in with appropriate credentials. If connecting to vCenter Server, click on the desired host. Click the Configuration tab. Click Software, Security Profile, Services, Properties, ESXi Shell and Options, respectively. Start the ESXi Shell service, where/as required. As root, log in to the host and verify the expected settings are configured in the /etc/pam.d/passwd file. The entry format is : "password requisite /lib/security/pam_passwdqc.so similar=deny retry=N min=N0,N1,N2,N3,N4" The "N4" field controls the behavior requiring at least one character each of the 4 different character classes (i.e., number, special, UPPER_CASE, and lower_case), with a minimum required length of 14 characters. # grep "^password" /etc/pam.d/passwd | grep requisite | grep "min=" If the "N4" password complexity field is not set to "14" or greater and the "N0" thru "N3" fields are not set to "disabled", this is a finding. Re-enable Lockdown Mode on the host.
Temporarily disable Lockdown Mode and enable the ESXi Shell via the vSphere Client. Open the vSphere/VMware Infrastructure (VI) Client and log in with appropriate credentials. If connecting to vCenter Server, click on the desired host. Click the Configuration tab. Click Software, Security Profile, Services, Properties, ESXi Shell and Options, respectively. Start the ESXi Shell service, where/as required. As root, log in to the host and ensure the expected settings of the "min" keyword are configured in the /etc/pam.d/passwd file. # vi /etc/pam.d/passwd Set the "N4" password complexity field to "14" or greater and set the "N0" thru "N3" fields to "disabled", i.e., min=disabled,disabled,disabled,disabled,14 Re-enable Lockdown Mode on the host.
From the Power/v CLI, run: "vicfg-snmp.pl --server <server_name> -s" to determine if SNMP is being used. An alternative command option instead of the "-s" is "--show". If SNMP is not being used and "enabled" = 1, this is a finding. If the read-only community name is set to "public", this is a finding. If the read-write community name is set to private, this is a finding.
If SNMP is not being used, configure "enabled" = 0. From the Power/v CLI, execute "vicfg-snmp.pl --server <server_name> -D". If SNMP is being used, ensure the community name is configured: From the vSphere CLI, type "vicfg-snmp.pl --server hostname --username <username> --password <password> -c <community_name>". To enable SNMP from the vSphere CLI, type. # vicfg-snmp.pl --server <hostname> --username <username> --password <password> --enable
Temporarily disable Lockdown Mode and enable the ESXi Shell via the vSphere Client. Open the vSphere/VMware Infrastructure (VI) Client and log in with appropriate credentials. If connecting to vCenter Server, click on the desired host. Click the Configuration tab. Click Software, Security Profile, Services, Properties, ESXi Shell and Options, respectively. Start the ESXi Shell service, where/as required. As root, log in to the host and verify the expected settings are configured in the /etc/pam.d/passwd file. The entry format is : "password requisite /lib/security/pam_passwdqc.so similar=deny retry=N min=N0,N1,N2,N3,N4" The "N2" field controls the behavior enforcing "no dictionary words". This flag should be set to "disabled". # grep "^password" /etc/pam.d/passwd | grep requisite | grep "min=" If the "N2" password complexity field is not set to "disabled", this is a finding. Re-enable Lockdown Mode on the host.
Temporarily disable Lockdown Mode and enable the ESXi Shell via the vSphere Client. Open the vSphere/VMware Infrastructure (VI) Client and log in with appropriate credentials. If connecting to vCenter Server, click on the desired host. Click the Configuration tab. Click Software, Security Profile, Services, Properties, ESXi Shell and Options, respectively. Start the ESXi Shell service, where/as required. As root, log in to the host and ensure the expected settings of the "min" keyword are configured in the /etc/pam.d/passwd file. # vi /etc/pam.d/passwd Set the "N2" password complexity field to "disabled", i.e., min=disabled,disabled,disabled,disabled,14 Re-enable Lockdown Mode on the host.
Disable lock down mode. Enable the ESXi Shell. Execute the following command(s): # grep StrictModes /etc/ssh/sshd_config If the command returns nothing, or the returned "StrictModes" attribute is set to "no", this is a finding. Re-enable lock down mode.
Disable lock down mode. Enable the ESXi Shell. Execute the following command(s): # vi /etc/ssh/sshd_config Add/modify the attribute line entry to the following (quotes for emphasis only): "StrictModes yes" Re-enable lock down mode.
Temporarily disable Lockdown Mode and enable the ESXi Shell via the vSphere Client. Open the vSphere/VMware Infrastructure (VI) Client and log in with appropriate credentials. If connecting to vCenter Server, click on the desired host. Click the Configuration tab. Click Software, Security Profile, Services, Properties, ESXi Shell and Options, respectively. Start the ESXi Shell service, where/as required. As root, log in to the host. Check /etc/fstab and verify the nosuid mount option is used on file systems mounted from removable media, network shares, or any other file system not containing approved setuid or setgid files. Each file system line entry must contain a device specific file and may additionally contain all of the following fields, in the following order (per the NFSv3 specification): mount directory, type, OPTION(s), backup frequency, pass number (on parallel fsck) and comment. Execute the following: # cat /etc/fstab | grep -v "^#" If the "nosuid" mount OPTION is not used on file systems mounted from removable media, network shares, or any other file system that does not contain approved setuid or setgid files, this is a finding. Re-enable Lockdown Mode on the host.
Temporarily disable Lockdown Mode and enable the ESXi Shell via the vSphere Client. Open the vSphere/VMware Infrastructure (VI) Client and log in with appropriate credentials. If connecting to vCenter Server, click on the desired host. Click the Configuration tab. Click Software, Security Profile, Services, Properties, ESXi Shell and Options, respectively. Start the ESXi Shell service, where/as required. As root, log in to the host. Edit /etc/fstab and add the nosuid mount option to all file systems mounted from removable media or network shares, and any file system not containing approved setuid or setgid files. Re-enable Lockdown Mode on the host.
Temporarily disable Lockdown Mode and enable the ESXi Shell via the vSphere Client. Open the vSphere/VMware Infrastructure (VI) Client and log in with appropriate credentials. If connecting to vCenter Server, click on the desired host. Click the Configuration tab. Click Software, Security Profile, Services, Properties, ESXi Shell and Options, respectively. Start the ESXi Shell service, where/as required. As root, log in to the host. Check the system for NFS mounts that do not use the nosuid option. Execute the following: # cat /etc/fstab | grep -i nfs | grep -v "nosuid" If the mounted NFS file systems do not use the nosuid option, this is a finding. Re-enable Lockdown Mode on the host.
Temporarily disable Lockdown Mode and enable the ESXi Shell via the vSphere Client. Open the vSphere/VMware Infrastructure (VI) Client and log in with appropriate credentials. If connecting to vCenter Server, click on the desired host. Click the Configuration tab. Click Software, Security Profile, Services, Properties, ESXi Shell and Options, respectively. Start the ESXi Shell service, where/as required. As root, log in to the host. Edit /etc/fstab and add the nosuid option for all NFS file systems. Re-enable Lockdown Mode on the host.
Ask the SA if the system is checked for extraneous device files on a weekly basis. To manually perform the check, disable lock down mode, enable the ESXi Shell, and execute the following command: # find / \( -type b -o -type c \) -exec ls -lL {} \; Re-enable lock down mode. If no automated or manual process is in place, this is a finding.
Configure the system to check for extraneous device files on a weekly basis. Refer to the Check Content section above for the basic command structure to search the file system. Additionally, ensure persistence of the command output by storing results to a target located on persistent storage.
Ask the SA if the system is checked for unauthorized setuid files on a weekly basis. To manually perform the check, disable lock down mode, enable the ESXi Shell, and execute the following command: # find / -perm -4000 -exec ls -lL {} \; Re-enable lock down mode. If no automated or manual process is in place, this is a finding.
Configure the system to check for unauthorized setuid files on a weekly basis. Refer to the Check Content section above for the basic command structure to search the file system. Additionally, ensure persistence of the command output by storing results to a target located on persistent storage.
Ask the SA if the system is checked for unauthorized setgid files on a weekly basis. To manually perform the check, disable lock down mode, enable the ESXi Shell, and execute the following command: # find / -perm -2000 -exec ls -lL {} \; Re-enable lock down mode. If no automated or manual process is in place, this is a finding.
Configure the system to check for unauthorized setgid files on a weekly basis. Refer to the Check Content section above for the basic command structure to search the file system. Additionally, ensure persistence of the command output by storing results to a target located on persistent storage.
Open the vSphere/VMware Infrastructure (VI) Client and log in with appropriate credentials. If connecting to vCenter Server, click on the desired host. Click the Configuration tab and view the listed DNS server setting(s). If DNS is not configured and is not used, this is not a finding. If DNS is configured with less than 2 servers, this is a finding.
Open the vSphere/VMware Infrastructure (VI) Client and log in with appropriate credentials. If connecting to vCenter Server, click on the desired host. Click the Configuration tab and view the listed DNS server setting(s). If DNS is configured has less than 2 servers configured, add a second server.
Ask the SA if the system boots from removable media. If so, ask if the boot media is stored in a secure container when not in use. If it is not, this is a finding.
Store the system boot media in a secure container when not in use.
From the vSphere Client/vCenter and select the host: View the menu header above the "Configuration" tab. If the version is not supported, this is a finding.
Upgrade to a supported version.
From the vSphere Client: Select the host and click "Configuration >> Time Configuration". Select the properties link and chose 'Options'. Select NTP Settings to view configured NTP servers. If NTP is not synchronized with an authoritative time source within DoD, this is a finding.
From the vSphere Client: Select the host and click "Configuration >> Time Configuration". Select the properties link and chose 'Options'. From the General tab start the NTP service and select "Start and stop with host". From the NTP Settings tab click the ' Add' button to add the organization defined, authoritative time source within DoD NTP servers.
This is N/A for systems that do not have wireless network adapters. If a wireless interface is configured, it must be documented and approved by the local Authorizing Official. If a wireless interface is configured and has not been documented and approved, this is a finding.
Configure the system to disable all wireless network interfaces.