Professional Documents
Culture Documents
1 Benchmark
v1.0.1 - 06-23-2014
http://benchmarks.cisecurity.org
The CIS Security Benchmarks division provides consensus-oriented information security products, services, tools, metrics, suggestions, and
recommendations (the “SB Products”) as a public service to Internet users worldwide. Downloading or using SB Products in any way signifies
and confirms your acceptance of and your binding agreement to these CIS Security Benchmarks Terms of Use.
SPECIAL RULES FOR CIS MEMBER ORGANIZATIONS: CIS reserves the right to create special rules for: (1) CIS Members; and (2) Non-
Member organizations and individuals with which CIS has a written contractual relationship. CIS hereby grants to each CIS Member
Organization in good standing the right to distribute the SB Products within such Member's own organization, whether by manual or
electronic means. Each such Member Organization acknowledges and agrees that the foregoing grants in this paragraph are subject to the
terms of such Member's membership arrangement with CIS and may, therefore, be modified or terminated by CIS at any time.
Table of Contents
Table of Contents .................................................................................................................................................. 2
Overview .................................................................................................................................................................. 3
Intended Audience ........................................................................................................................................... 3
Consensus Guidance........................................................................................................................................ 3
Typographical Conventions ......................................................................................................................... 4
Scoring Information ........................................................................................................................................ 4
Profile Definitions ............................................................................................................................................ 5
Acknowledgements ......................................................................................................................................... 6
Recommendations ................................................................................................................................................ 7
1 Install ................................................................................................................................................................. 7
2 Communication .......................................................................................................................................... 14
3 Logging .......................................................................................................................................................... 25
4 Access ............................................................................................................................................................. 31
5 Console .......................................................................................................................................................... 38
6 Storage ........................................................................................................................................................... 50
7 vNetwork ...................................................................................................................................................... 53
7.1 VDS .......................................................................................................................................................... 53
7.2 VLAN ...................................................................................................................................................... 61
7.3 vSwitch .................................................................................................................................................. 64
8 Virtual Machines ........................................................................................................................................ 69
8.1 Communication .................................................................................................................................. 69
8.2 Devices .................................................................................................................................................. 73
8.3 Guest....................................................................................................................................................... 82
8.4 Monitor.................................................................................................................................................. 87
8.5 Resources ........................................................................................................................................... 120
8.6 Storage ................................................................................................................................................. 121
8.7 Tools ..................................................................................................................................................... 124
Appendix: Change History ............................................................................................................................ 131
Overview
This document provides prescriptive guidance for establishing a secure configuration
posture for VMware ESXi 5.1. To obtain the latest version of this guide, please visit
http://benchmarks.cisecurity.org. If you have questions, comments, or have identified
ways to improve this guide, please write us at feedback@cisecurity.org.
Intended Audience
This document is intended for system and application administrators, security specialists,
auditors, help desk, and platform deployment personnel who plan to develop, deploy,
assess, or secure solutions that incorporate VMware ESXi 5.1 Update 2.
Consensus Guidance
This benchmark was created using a consensus review process comprised subject matter
experts. Consensus participants provide perspective from a diverse set of backgrounds
including consulting, software development, audit and compliance, security research,
operations, government, and legal.
Each CIS benchmark undergoes two phases of consensus review. The first phase occurs
during initial benchmark development. During this phase, subject matter experts convene
to discuss, create, and test working drafts of the benchmark. This discussion occurs until
consensus has been reached on benchmark recommendations. The second phase begins
after the benchmark has been published. During this phase, all feedback provided by the
Internet community is reviewed by the consensus team for incorporation in the
benchmark. If you are interested in participating in the consensus process, please visit
https://community.cisecurity.org.
Typographical Conventions
The following typographical conventions are used throughout this guide:
Convention Meaning
Stylized Monospace font Used for blocks of code, command, and script examples.
Text should be interpreted exactly as presented.
Monospace font Used for inline code, commands, or examples. Text should
be interpreted exactly as presented.
<italic font in brackets> Italic texts set in angle brackets denote a variable
requiring substitution for a real value.
Scoring Information
A scoring status indicates whether compliance with the given recommendation impacts the
assessed target's benchmark score. The following scoring statuses are used in this
benchmark:
Scored
Failure to comply with "Scored" recommendations will decrease the final benchmark score.
Compliance with "Scored" recommendations will increase the final benchmark score.
Not Scored
Failure to comply with "Not Scored" recommendations will not decrease the final
benchmark score. Compliance with "Not Scored" recommendations will not increase the
final benchmark score.
Profile Definitions
The following configuration profiles are defined by this Benchmark:
Level 1
Level 2
This profile extends the "Level 1" profile. Items in this profile exhibit one or more of
the following characteristics:
Additional special recognition to Mike Foley as the principal author of the VMware’s vSphere
5.1 Hardening Guide and to Jordan Rakoske and Iben Rodriguez for their significant
contributions to the development of this document.
Recommendations
1 Install
1.1 Keep ESXi system properly patched (Scored)
Profile Applicability:
Level 1
Description:
VMware Update Manager is a tool used to automate patch management for vSphere hosts
and Virtual machines. Creating a baseline for patches is a good way to ensure all hosts are
at the same patch level.
Rationale:
Audit:
Employ a process to keep ESXi hosts up to date with patches in accordance with industry-
standards and internal guidelines. VMware Update Manager is an automated tool that can
greatly assist with this. VMware also publishes Advisories on security patches, and offers a
way to subscribe to email alerts for them.
Remediation:
Leverage the VMware Update Manager to test and apply patches as they become available.
Impact:
VMs must be powered off in order to update the host ESXi server.
References:
1. http://pubs.vmware.com/vsphere-
51/topic/com.vmware.vsphere.update_manager.doc/GUID-EF6BEE4C-4583-4A8C-
81B9-5B074CA2E272.html
1.2 Verify Image Profile and VIB Acceptance Levels (Scored)
Profile Applicability:
Level 1
Description:
The ESXi Image Profiles supports four VIB acceptance levels. A VIB (vSphere Installation
Bundle) is a collection of files that are packaged into an archive. The VIB contains a
signature file that is used to verify the level of trust.
Rationale:
Verify the ESXi Image Profile to only allow signed VIBs. An unsigned VIB represents
untested code installed on an ESXi host.
Community Supported VIBs are not supported and do not have a digital signature. To
protect the security and integrity of your ESXi hosts do not allow unsigned
(CommunitySupported) VIBs to be installed on your hosts.
Audit:
1. Connect to each ESX/ESXi host using the ESXi Shell or vCLI and execute the
command "esxcli software acceptance get" to verify the acceptance level is at either
"VMware Certified", "VMware Supported", or "PartnerSupported".
2. Connect to each ESX/ESXi host using the vCLI and execute the command "esxcli
software vib list" and verify the acceptance level for each VIB is either "VMware
Certified", "VMware Supported", or "Partner Supported"
Remediation:
Default Value:
References:
1. http://pubs.vmware.com/vsphere-
51/topic/com.vmware.vsphere.install.doc/GUID-56600593-EC2E-4125-B1A0-
065BDD16CF2D.html
Level 1
Description:
ESXi hosts by default do not permit the loading of kernel modules that lack valid digital
signatures. This feature can be overridden which would result in unauthorized kernel
modules to be loaded.
Rationale:
VMware provides digital signatures for kernel modules. By default the ESXi host does not
permit loading of kernel modules that lack a valid digital signature. However, this behavior
can be overridden allowing unauthorized kernel modules to be loaded. Untested or
malicious kernel modules loaded on the ESXi host can put the host at risk for instability
and/or exploitation.
Audit:
Each ESXi host should be monitored for unsigned kernel modules. To list all the loaded
kernel modules from the ESXi Shell or vCLI run: "esxcli system module list". For each
module, verify the signature by running: esxcli system module get -m <module>. Secure
the host by disabling unsigned modules and removing the offending VIBs from the host.
Remediation:
References:
1. http://pubs.vmware.com/vsphere-
51/topic/com.vmware.vsphere.security.doc/GUID-E9B71B85-FBA3-447C-8A60-
DEE2AE1A405A.html http://kb.vmware.com/kb/2042473
2. http://kb.vmware.com/kb/2042473
1.4 Ensure that the Forged Transmits policy is set to reject (Scored)
Profile Applicability:
Level 1
Description:
Rationale:
If the virtual machine operating system changes the MAC address, the operating system can
send frames with an impersonated source MAC address at any time. This allows an
operating system to stage malicious attacks on the devices in a network by impersonating a
network adaptor authorized by the receiving network. Forged transmissions should be set
to accept by default. This means the dvPortgroup does not compare the source and
effective MAC addresses. To protect against MAC address impersonation, all virtual
switches should have forged transmissions set to reject.
Audit:
1. Verify by using the vSphere Web Client to connect to the vCenter Server and as
administrator:
2. Go to Home > Networking.
3. Select each VDS and edit each dvPortgroup connected to active VM's requiring
securing.
4. Edit Settings for each PortGroup under Security.
5. Verify that the Forged transmits value is set to "Reject"
Remediation:
1. Configure by using the vSphere Web Client to connect to the vCenter Server and as
administrator:
2. Go to Home > Networking.
3. Select each VDS and edit each dvPortgroup connected to active VM's requiring
securing.
4. Edit Settings for each PortGroup under Security.
5. Set the Forged transmits value to "Reject"
Impact:
This will prevent VMs from changing their effective MAC address. This will affect
applications that require this functionality. An example of an application like this is
Microsoft Clustering, which requires systems to effectively share a MAC address. This will
also affect how a layer 2 bridge will operate. This will also affect applications that require a
specific MAC address for licensing. An exception should be made for the dvPortgroups that
these applications are connected to.
1.5 Ensure that VDS Netflow traffic is only being sent to authorized
collector IP Addresses (Not Scored)
Profile Applicability:
Level 1
Description:
Ensure that VDS Netflow traffic is only being sent to authorized collector IP Addresses.
Rationale:
The vSphere vDS can export Netflow information about traffic crossing the vDS. Netflow
exports are not encrypted and can contain information about the virtual network making it
easier for a MITM attack to be executed successfully. If Netflow export is required, verify
that all vDS Netflow target IP Addresses are correct.
Audit:
1. From the Web or vSphere Clients, verify that Netflow destinations are correct.
2. Edit the VDS properties.
3. In the Netflow tab, verify the Collector Settings > IP Address and Port.
Remediation:
References:
1. http://pubs.vmware.com/vsphere-
51/topic/com.vmware.vsphere.networking.doc/GUID-E19FECAD-8629-4E8A-
B61C-1F1C16770B3B.html
Level 1
Description:
Rationale:
Port-level configuration over-rides are disabled by default. Once enabled, this allows for
different security settings to be set from what is established at the Port-Group level. There
are cases where particular VM's require unique configurations, but this should be
monitored so it is only used when authorized. If over-rides are not monitored, anyone who
gains access to a VM with a less secure VDS configuration could exploit that broader access.
Audit:
Remediation:
Default Value:
Port-level configuration over-rides are disabled by default. This is the prescribed state.
References:
1. http://pubs.vmware.com/vsphere-
51/topic/com.vmware.vsphere.networking.doc/GUID-EA78AD26-F099-4136-
9EA6-AD60626D3EF7.html
2 Communication
2.1 Configure NTP time synchronization (Scored)
Profile Applicability:
Level 1
Description:
Rationale:
By ensuring that all systems use the same relative time source (including the relevant
localization offset), and that the relative time source can be correlated to an agreed-upon
time standard, you can make it simpler to track and correlate an intruder's actions when
reviewing the relevant log files. Incorrect time settings can make it difficult to inspect and
correlate log files to detect attacks, and can make auditing inaccurate.
Audit:
Notes: verify the NTP firewall ports are open. It is recommended to synchronize the ESXi
clock with a time server that is located on the management network rather than directly
with a time server on a public network. This time server can then synchronize with a public
source through a strictly controlled network connection with a firewall.
Remediation:
To implement the recommended configuration state, run the following PowerCLI
command:
# Set the NTP Settings for all hosts
# If an internal NTP server is used replace pool.ntp.org with
# the IP address of the internal NTP server
$NTPServers = "pool.ntp.org", "pool2.ntp.org" Get-VMHost | Add-VmHostNtpServer
$NTPServers
Default Value:
References:
1. http://pubs.vmware.com/vsphere-
51/topic/com.vmware.vcli.examples.doc/cli_manage_networks.11.9.html
2.2 Configure the ESXi host firewall to restrict access to services running
on the host (Scored)
Profile Applicability:
Level 1
Description:
The ESXi Firewall is enabled by default and allows ping (ICMP) and communication with
DHCP/DNS clients. Confirm that access to services are only allowed by authorized
IP's/networks to protect from outside attacks.
Rationale:
Unrestricted access to services running on an ESXi host can expose a host to outside attacks
and unauthorized access. Reduce the risk by configuring the ESXi firewall to only allow
access from authorized networks.
Audit:
Remediation:
To implement the recommended configuration state, run the following ESXi shell
command:
# /etc/init.d/[SERVICE] STOP
Impact:
Only systems in the IP whitelist/ACL will be able to connect to services on the ESXi server.
Default Value:
References:
1. http://pubs.vmware.com/vsphere-
51/topic/com.vmware.vsphere.security.doc/GUID-DD4322FF-3DC4-4716-8819-
6688938F99D7.html
Level 1
Description:
The Managed Object Browser (MOB) is a web-based server application that lets you
examine objects that exist on the server side. This is installed and started automatically
when vCenter is installed.
Rationale:
The managed object browser (MOB) provides a way to explore the object model used by
the VMkernel to manage the host; it enables configurations to be changed as well. This
interface is meant to be used primarily for debugging the vSphere SDK. Because there are
no access controls the MOB could also be used as a method to obtain information about a
host being targeted for unauthorized access.
Audit:
To determine if the MOB is enabled run the following command from the ESXi shell:
vim-cmd proxysvc/service_list
Remediation:
To implement the recommended configuration state, run the following ESXi shell
command:
vim-cmd proxysvc/remove_service "/mob" "httpsWithRedirect"
Note: You cannot disable the MOB while a host is in lockdown mode.
Impact:
The MOB will no longer be available for diagnostics. Some 3rd party tools use this interface
to gather information. Testing should be done after disabling the MOB to verify 3rd party
applications are still functioning as expected.
Default Value:
References:
1. http://pubs.vmware.com/vsphere-
51/topic/com.vmware.vsphere.security.doc/GUID-0EF83EA7-277C-400B-B697-
04BDC9173EA3.html
Level 1
Description:
The default certificates are not signed by a commercial certificate authority (CA). These
default x.509 certificates should be replaced with those issued by a trusted CA.
Rationale:
Using the default self-signed certificates may increase risk related to Man-in-The-Middle
(MiTM) attacks. Replace default self-signed certificates with those from a trusted CA, either
commercial or organizational.
Audit:
View the details of the SSL certificate presented by the ESXi host and determine if it is
issued by a trusted CA, either commercial or organizational.
Remediation:
Default Value:
References:
1. http://pubs.vmware.com/vsphere-
51/topic/com.vmware.vsphere.security.doc/GUID-A261E6D8-03E4-48ED-ADB6-
473C2DAAB7AD.html
2. http://kb.vmware.com/kb/2015499
3. http://kb.vmware.com/kb/2034833
Level 2
Description:
Enable SSL encryption for the Network File Copy function used during Virtual Machine
migration or clone operations between two ESXi hosts.
Rationale:
NFC (Network File Copy) is the name of the mechanism used to migrate or clone a VM
between two ESXi hosts over the network. By default, SSL is used only for the
authentication of the transfer, but if desired, SSL can also be enabled on the data transfer.
Without this setting VM contents could potentially be sniffed if the management network is
not adequately isolated and secured.
Audit:
1. From the vSphere client select "Administration -> vCenter Server Settings ->
Advanced Settings"
2. Check if the config.nfc.useSSL key exists and is set to true
Remediation:
1. From the vSphere client select "Administration -> vCenter Server Settings ->
Advanced Settings"
2. Check if the config.nfc.useSSL key exists
3. If the key does not exist, add it to the list of keys
4. Set the value of the key to true
Impact:
Using SSL may reduce performance of actions involving NFC, such as VM clone or
migration.
Default Value:
References:
1. http://kb.vmware.com/kb/2010332
Level 1
Description:
Verify that SNMP (Simple Network Management Protocol) is configured and that all the
settings are correct. If SNMP is not being used, it should be disabled.
Note: ESXi 5.1 supports SNMPv3 which provides stronger security than SNMPv1 or
SNMPv2, including key authentication and encryption.
Rationale:
If SNMP is not being used, it should remain disabled. If it is being used, the proper trap
destination should be configured. If SNMP is not properly configured, monitoring
information can be sent to a malicious host.
Audit:
1. From the ESXi Shell or vCLI run the following to determine if SNMP is being used:
3. If SNMP is being used, refer to the vSphere Monitoring and Performance guide,
chapter 8 for steps to configure the required parameters.
Remediation:
To implement the recommended configuration state, run the following PowerCLI
command:
# Update the host SNMP Configuration (single host connection required)
Get-VmHostSNMP | Set-VMHostSNMP -Enabled:$true -ReadOnlyCommunity '<secret>'
Notes:
References:
1. http://pubs.vmware.com/vsphere-
51/topic/com.vmware.vsphere.monitoring.doc/GUID-8EF36D7D-59B6-4C74-
B1AA-4A9D18AB6250.html
Level 1
Description:
Confirm that dvfilter API is not configured if not is use. If you are using virtual security
appliances that leverage this API then configuration may be necessary.
Rationale:
If you are not using products that make use of the dvfilter network API (e.g. VMSafe), the
host should not be configured to send network information to a VM. If the API is enabled,
an attacker might attempt to connect a VM to it, thereby potentially providing access to the
network of other VMs on the host. If you are using a product that makes use of this API then
verify that the host has been configured correctly.
Audit:
If a dvfilter-based network security appliance is not being used on the host, ensure that the
following kernel parameter has a blank value: /Net/DVFilterBindIpAddress.
1. From the vSphere web client select the host and click "Manage" -> "Advanced
System Settings".
2. Enter Net.DVFilterBindIpAddress in the filter.
3. Verify Net.DVFilterBindIpAddress has an empty value.
4. If an appliance is being used, then make sure the value of this parameter is set to the
proper IP address.
Remediation:
Impact:
This will prevent a dvfilter-based network security appliance such as a firewall from
functioning if not configured correctly.
Default Value:
References:
1. http://pubs.vmware.com/vsphere-
51/topic/com.vmware.vsphere.ext_solutions.doc/GUID-6013E15D-92CE-4970-
953C-ACCB36ADA8AD.html
2.8 When adding ESXi hosts to Active Directory use the vSphere
Authentication Proxy to protect passwords (Scored)
Profile Applicability:
Level 1
Description:
If you are using Host Profiles to join ESXi hosts to Active Directory then vSphere
Authentication Proxy should be used to keep credentials from being sent over the
network.
Rationale:
If you configure your host to join an Active Directory domain using Host Profiles the active
directory credentials are saved in the host profile and are transmitted over the network. To
avoid having to save active directory credentials in the Host Profile and to avoid
transmitting active directory credentials over the network use the vSphere Authentication
Proxy.
Audit:
Remediation:
Default Value:
References:
1. http://pubs.vmware.com/vsphere-
51/topic/com.vmware.vsphere.security.doc/GUID-084B74BD-40A5-4A4B-A82C-
0C9912D580DC.html
3 Logging
3.1 Configure a centralized location to collect ESXi host core dumps
(Scored)
Profile Applicability:
Level 1
Description:
The VMware vSphere Network Dump Collector service allows for collecting diagnostic
information from a host that experiences a critical fault.
Rationale:
When a host crashes, an analysis of the resultant core dump is essential to being able to
identify the cause of the crash to identify a resolution. Installing a centralized dump
collector helps ensure that core files are successfully saved and made available in the event
an ESXi host should ever panic.
Audit:
Run the following ESXi shell command to determine if the host is configured as prescribed:
esxcli system coredump network get
Remediation:
To implement the recommended configuration state, run the following ESXi shell
command:
Impact:
No impact on functionality.
Default Value:
References:
1. http://kb.vmware.com/kb/1032051 http://kb.vmware.com/kb/2003042
Level 1
Description:
The Host Profiles feature monitors host configurations against an established profile and
provides notification when unauthorized configurations take place.
Rationale:
Monitoring for configuration drift and unauthorized changes is critical to ensuring the
security of an ESXi hosts. Host Profiles provide an automated method for monitoring host
configurations against an established template and for providing notification in the event
deviations are detected.
Audit:
There are 3 ways to monitor an ESXi host's compliance to the host profile:
2. Schedule the "Check compliance of a profile" task to run once in the future or multiple
times, at a recurring interval. This task checks that a host's configuration matches the
configuration specified in a host profile. By default, this interval is set to check once a day.
1. Alarm Settings -> Alarm Type: "Hosts" -> "Monitor for specific events" -> Triggers:
"Host profile applied", "Host compliant with profile", "Host noncompliant with
profile"
2. Alarm Settings -> Alarm Type: "Clusters" -> "Monitor for specific events" ->
Triggers: "Cluster compliance checked"
Remediation:
1. Configure a reference ESXi host with the desired configuration and use the host to
create a Host Profile.
2. Attach the host profile to other hosts with identical hardware configurations.
3. Monitor hosts compliance to the host profile from the vSphere Client.
References:
1. http://pubs.vmware.com/vsphere-
51/topic/com.vmware.vsphere.hostprofiles.doc/GUID-78BB234A-D735-4356-
9CCF-19DD55DB8060.html
Level 1
Description:
System logs are required for auditing and diagnostic purposes. If you do not store system
logs permanently, for example on a datastore, they disappear after a reboot. Ensuring
persistent logging is set can prevent the loss of logs on reboot.
Rationale:
ESXi can be configured to store log files on an in-memory file system. This occurs when the
host's /scratch directory is linked to /tmp/scratch. When this is done only a single day's
worth of logs are stored at any time, in addition log files will be reinitialized upon each
reboot. This presents a security risk as user activity logged on the host is only stored
temporarily and will not be preserved across reboots. This can also complicate auditing
and make it harder to monitor events and diagnose issues. ESXi host logging should always
be configured to a persistent datastore.
Audit:
Remediation:
Note: the Syslog.global.LogDir must be set for each host. The host syslog parameters can
also be configured using the vCLI or PowerCLI, or using an API client.
Impact:
Default Value:
References:
1. http://pubs.vmware.com/vsphere-
51/topic/com.vmware.vsphere.install.doc/GUID-9F67DB52-F469-451F-B6C8-
DAE8D95976E7.html http://kb.vmware.com/kb/1033696
Level 1
Description:
By default ESXI logs are stored on a local scratch volume or ramdisk. To preserve logs
further configure centralized logging for the ESXI hosts.
Rationale:
Remote logging to a central log host provides a secure, centralized store for ESXi logs. By
gathering host log files onto a central host you can more easily monitor all hosts with a
single tool. You can also do aggregate analysis and searching to look for such things as
coordinated attacks on multiple hosts. Logging to a secure, centralized log server also helps
prevent log tampering and also provides a long-term audit record.
Audit:
Remediation:
Note: When setting a remote log host it is also recommended to set the
"Syslog.global.logDirUnique" to true. You must configure the syslog settings for each host.
The host syslog parameters can also be configured using the vCLI or PowerCLI, or using an
API client.
Default Value:
References:
1. http://pubs.vmware.com/vsphere-
51/topic/com.vmware.vsphere.install.doc/GUID-471EFE67-9035-473E-8217-
6B67E493A518.html
4 Access
4.1 Create a non-root user account for local admin access (Scored)
Profile Applicability:
Level 1
Description:
Create at least one named user account and use this account in lieu of a shared "root"
account.
Rationale:
By default each ESXi host has a single "root" admin account that is used for local
administration and to connect the host to vCenter Server. To avoid sharing a common root
account it is recommended on each host to create at least one named user account and
assign it full admin privileges and to use this account in lieu of a shared "root" account. Set
a highly complex password for the "root" account and secure it in a safe location. Limit the
use of "root" but do not remove the "root" account.
Audit:
Remediation:
Local ESXi user accounts cannot be created using the vSphere web client, you must use the
vSphere client.
Notes:
1. Even if you add your ESXi host to an Active Directory domain it is still recommended
to add at least one local user account to ensure admins can still login in the event the
host ever becomes isolated and unable to access Active Directory.
2. Adding local user accounts can be automated using Host Profiles.
Default Value:
References:
1. http://pubs.vmware.com/vsphere-
51/topic/com.vmware.vsphere.security.doc/GUID-670B9B8C-3810-4790-AC83-
57142A9FE16F.html
Level 1
Description:
When a host is added to the vCenter Server inventory, vCenter Server creates a special user
account called vpxuser on the host. vpxuser is a privileged account that acts as a proxy for
all actions initiated through vCenter Server. Ensure that vpxuser's password is set to
change every 10 or fewer days.
Rationale:
Ensuring that the password expires frequently limits the amount of time an attacker can
use the vpxuser password if it is compromised.
Audit:
Remediation:
Impact:
The password aging policy must not be shorter than the interval that is set to automatically
change the vpxuser password, otherwise vCenter might get locked out of an ESXi host.
Default Value:
References:
1. http://pubs.vmware.com/vsphere-
51/topic/com.vmware.vsphere.security.doc/GUID-96210743-0C17-4AE9-89FC-
76778EC9D06E.html
Level 1
Description:
Require the use of passwords that are not easily guessed and that are difficult for password
generators to determine.
Rationale:
ESXi uses the pam_passwdqc.so plug-in to set password strength and complexity. It is
important to use passwords that are not easily guessed and that are difficult for password
generators to determine.
Note: ESXi imposes no restrictions on the root password. Password strength and
complexity rules only apply to non-root users.
Audit:
This above requires all passwords to be 14 or more characters long and comprised of at
least one character from four distinct character sets. Additionally, a maximum of 5 login
attempts are permitted.
Remediation:
This above requires all passwords to be 14 or more characters long and comprised of at
least one character from four distinct character sets. Additionally, a maximum of 5 login
attempts are permitted.
Default Value:
References:
1. http://pubs.vmware.com/vsphere-
51/topic/com.vmware.vsphere.security.doc/GUID-F48903DA-8A66-47C7-9796-
CD12339B2164.html
2. http://www.openwall.com/passwdqc/README.shtml
Level 1
Description:
ESXi can be configured to use a directory service such as Active Directory to manage users
and groups. It is recommended that a directory service be used.
Rationale:
Joining ESXi hosts to an Active Directory (AD) domain will eliminate the need to create and
maintain multiple local user accounts. Using AD for user authentication simplifies the ESXi
host configuration, ensures password complexity and reuse policies are enforced and
reduces the risk of security breaches and unauthorized access.
Audit:
Remediation:
Notes:
References:
1. http://pubs.vmware.com/vsphere-
51/topic/com.vmware.vsphere.security.doc/GUID-A61A8FA4-A4AF-475C-860E-
3FD8947F0D0B.html http://kb.vmware.com/kb/1025569.
4.5 Verify Active Directory group membership for the "ESX Admins"
group (Not Scored)
Profile Applicability:
Level 1
Description:
The AD group used by vSphere is defined by the esxAdminsGroup attribute. By default, this
attribute is set to "ESX Admins". All members of the "ESX Admins" group are granted full
administrative access to all ESXi hosts in the domain. Monitor AD for the creation of this
group and limit membership to highly trusted users and groups.
Rationale:
An unauthorized user having membership in the group set by the esxAdminsGroup
attribute will have full administrative access to all ESXi hosts. Given this, such users may
compromise the confidentiality, availability, and integrity of the all ESXi hosts and the
respective data and processes they influence.
Audit:
From Active Directory, monitor the membership of the group name that is defined by the
advanced host setting: Config.HostAgent.plugins.hostsvc.esxAdminsGroup. As with any
default group, consider changing this name to avoid possible exploits) and verify only
authorized user and group accounts are members of this group.
If full admin access for the AD ESX admins group is not desired you can disable this
behavior using the advanced host setting:
"Config.HostAgent.plugins.hostsvc.esxAdminsGroupAutoAdd"
Remediation:
Impact:
Default Value:
The AD group used by vSphere is defined by the esxAdminsGroup attribute. By default, this
attribute is set to "ESX Admins"
References:
1. http://pubs.vmware.com/vsphere-
51/topic/com.vmware.wssdk.apiref.doc/vim.host.AuthenticationManager.html
5 Console
5.1 Disable DCUI to prevent local administrative control (Scored)
Profile Applicability:
Level 2
Description:
The Direct Console User Interface (DCUI) can be disabled to prevent any local
administration from the Host. Once the DCUI is disabled any administration of the ESXi
host will be done through vCenter.
Rationale:
The DCUI allows for low-level host configuration such as configuring IP address, hostname
and root password as well as diagnostic capabilities such as enabling the ESXi shell,
viewing log files, restarting agents, and resetting configurations. Actions performed from
the DCUI are not tracked by vCenter Server. Even if Lockdown Mode is enabled, users who
are members of the DCUI.Access list can perform administrative tasks in the DCUI
bypassing RBAC and auditing controls provided through vCenter. DCUI access can be
disabled. Disabling it prevents all local activity and thus forces actions to be performed in
vCenter Server where they can be centrally audited and monitored.
Audit:
Remediation:
Impact:
Disabling the DCUI can create a potential "lock out" situation should the host become
isolated from vCenter Server. Recovering from a "lock out" scenario requires re-installing
ESXi. Consider leaving DCUI enabled and instead enable lockdown mode and limit the users
allowed to access the DCUI using the DCUI.Access list.
Default Value:
References:
1. http://pubs.vmware.com/vsphere-
51/topic/com.vmware.vsphere.security.doc/GUID-6779F098-48FE-4E22-B116-
A8353D19FF56.html
Level 1
Description:
The ESXi shell should only be enabled when running diagnostics or troubleshooting.
Otherwise it should be disabled on each host.
Rationale:
ESXi Shell is an interactive command line environment available from the Direct Console
User Interface (DCUI) or remotely via SSH. Access to this mode requires the root password
of the server. The ESXi Shell can be turned on and off for individual hosts. Activities
performed from the ESXi Shell bypass vCenter RBAC and audit controls. The ESXi shell
should only be turned on when needed to troubleshoot/resolve problems that cannot be
fixed through the vSphere client or vCLI/PowerCLI.
Audit:
Remediation:
References:
1. http://kb.vmware.com/kb/2004746
Level 1
Description:
Disable Secure Shell (SSH) for each ESXi host to prevent remote access to the ESXi shell.
only enable if needed for troubleshooting or diagnostics.
Rationale:
The ESXi shell, when enabled, can be accessed directly from the host console through the
DCUI or remotely using SSH. Remote access to the host should be limited to the vSphere
Client, remote command-line tools (vCLI/PowerCLI), and through the published APIs.
Under normal circumstances remote access to the host using SSH should be disabled.
Audit:
Remediation:
Perform the following:
Default Value:
References:
1. http://pubs.vmware.com/vsphere-
51/topic/com.vmware.vsphere.security.doc/GUID-12E27BF3-3769-4665-8769-
DA76C2BC9FFE.html
Level 1
Description:
Lockdown mode disables local access to the ESXi host. All management must be done from
vCenter to ensure proper permissions and roles are being applied when using lockdown
mode.
Rationale:
Enabling lockdown mode disables direct access to an ESXi host requiring the host be
managed remotely from vCenter Server. Lockdown limits ESXi host access to the vCenter
server. This is done to ensure the roles and access controls implemented in vCenter are
always enforced and users cannot bypass them by logging into a host directly. By forcing all
interaction to occur through vCenter Server, the risk of someone inadvertently attaining
elevated privileges or performing tasks that are not properly audited is greatly reduced.
Note: Lockdown mode does not apply to users who log in using authorized keys. When you
use an authorized key file for root user authentication, root users are not prevented from
accessing a host with SSH even when the host is in lockdown mode. Note that users listed in
the DCUI.Access list for each host are allowed to override lockdown mode and login to the
DCUI. By default the "root" user is the only user listed in the DCUI.Access list.
Audit:
Remediation:
Impact:
There are some operations, such as backup and troubleshooting, that require direct access
to the host. In these cases Lockdown Mode can be disabled on a temporary basis for
specific hosts as needed, and then re-enabled when the task is completed.
Note: Lockdown mode does not apply to users listed in the DCUI.Access list, which by
default includes the root user.
Default Value:
References:
1. http://pubs.vmware.com/vsphere-
51/topic/com.vmware.vsphere.security.doc/GUID-88B24613-E8F9-40D2-B838-
225F5FF480FF.html http://kb.vmware.com/kb/1008077
Level 1
Description:
For day-to-day operations the ESXi host should be in Lockdown mode with the Secure Shell
(SSH) service disabled. Lockdown mode does not prevent root users from logging in using
authorized keys. When you use an authorized key file for root user authentication, root
users are not prevented from accessing a host with SSH even when the host is in lockdown
mode.
Rationale:
ESXi hosts come with SSH which can be enabled to allow remote access without requiring
user authentication. To enable password free access copy the remote users public key into
the /etc/ssh/keys-root/authorized_keys file on the ESXi host. The presence of the
remote user's public key in the authorized_keys file identifies the user as trusted, meaning
the user is granted access to the host without providing a password.
Note: Lockdown mode does not apply to root users who log in using authorized keys.
When you use an authorized key file for root user authentication, root users are not
prevented from accessing a host with SSH even when the host is in lockdown mode.
Audit:
Remediation:
Impact:
Disabling the SSH authorized_keys access may limit your ability to run unattended remote
scripts.
Default Value:
References:
1. http://pubs.vmware.com/vsphere-
51/topic/com.vmware.vsphere.security.doc/GUID-392ADDE9-FD3B-49A2-BF64-
4ACBB60EB149.html
5.6 Set a timeout to automatically terminate idle ESXi Shell and SSH
sessions (Scored)
Profile Applicability:
Level 1
Description:
Set a timeout to automatically terminate any idle ESXi shell and SSH sessions.
Rationale:
If a user forgets to logout of their SSH session the idle connection will remain indefinitely
increasing the potential for someone to gain privileged access to the host. The
ESXiShellInteractiveTimeOut allows you to automatically terminate idle shell sessions.
Audit:
Remediation:
Default Value:
References:
1. http://pubs.vmware.com/vsphere-
51/topic/com.vmware.vsphere.security.doc/GUID-A1D310D7-F00B-4827-9469-
EC2C318A0C30.html http://kb.vmware.com/kb/2004746
Level 2
Description:
Set a timeout to automatically stop the service for ESXi shell and SSH sessions.
Rationale:
When the ESXi Shell or SSH services are enabled on a host they will run indefinitely. To
avoid having these services left running set the ESXiShellTimeOut. The ESXiShellTimeOut
defines a window of time after which the ESXi Shell and SSH services will automatically be
terminated.
Audit:
1. Select the host and click "Manage" -> "Advanced System Settings".
2. Type ESXiShellTimeOut in the filter.
3. Ensure the attribute is set to 3600 seconds (1 hour) or less. This value is in seconds.
Remediation:
1. Select the host and click "Manage" -> "Advanced System Settings".
2. Type ESXiShellTimeOut in the filter.
3. Set the attribute to 3600 seconds (1 hour) or less.
References:
1. http://pubs.vmware.com/vsphere-
51/topic/com.vmware.vsphere.security.doc/GUID-862CA8EF-C8CE-4322-864E-
86D0803015A5.html
2. https://blogs.vmware.com/vsphere/2012/09/vsphere-5-1-new-
esxishellinteractivetimeout.html
3. http://kb.vmware.com/kb/2004746
Level 1
Description:
Create a list of highly trusted users that would be able to override lockdown mode and
access the DCUI in the event a host became isolated.
Rationale:
Lockdown disables direct host access requiring admins manage hosts from vCenter.
However, if a host becomes isolated from vCenter the admin would become locked out and
would be unable to manage the host. To avoid potentially becoming locked out of an ESXi
hosts that is running in locked down mode set the DCUI.Access to a list of highly trusted
users that are allowed to override the lockdown mode and access the DCUI.
Audit:
Remediation:
To implement the recommended configuration state, run the following ESXi shell
command:
vim-cmd hostsvc/advopt/update DCUI.Access string [USERS]
Default Value:
References:
1. http://pubs.vmware.com/vsphere-
51/topic/com.vmware.vsphere.security.doc/GUID-D92BB375-9F94-449E-838E-
51086C43CF80.html
6 Storage
6.1 Enable bidirectional CHAP authentication for iSCSI traffic (Scored)
Profile Applicability:
Level 1
Description:
Rationale:
vSphere allows for the use of bidirectional authentication of both the iSCSI target and host.
Choosing not to enforce more stringent authentication can make sense if you create a
dedicated network or VLAN to service all your iSCSI devices. By not authenticating both the
iSCSI target and host, there is a potential for a MiTM attack in which an attacker might
impersonate either side of the connection to steal data. Bidirectional authentication can
mitigate this risk. If the iSCSI facility is isolated from general network traffic, it is less
vulnerable to exploitation.
Audit:
Remediation:
References:
1. http://pubs.vmware.com/vsphere-
51/topic/com.vmware.vsphere.storage.doc/GUID-AC65D747-728F-4109-96DD-
49B433E2F266.html
Level 1
Description:
Rationale:
The mutual authentication secret for each host should be different; if possible, the secret
should be different for each client authenticating to the server as well. This ensures that if a
single host is compromised, an attacker cannot create another arbitrary host and
authenticate to the storage device. With a single shared secret, compromise of one host can
allow an attacker to authenticate to the storage device.
Audit:
Default Value:
References:
1. http://pubs.vmware.com/vsphere-
51/topic/com.vmware.vsphere.storage.doc/GUID-AC65D747-728F-4109-96DD-
49B433E2F266.html
7 vNetwork
This section contains recommendations for configuring aspects of the vNetwork, such as
VLANs, vSwitches, and VDSs.
7.1 VDS
This section contains recommendations for configuring vSphere Distributed Switches
(VDS).
Level 1
Description:
Rationale:
Network Healthcheck is disabled by default. Once enabled, the healthcheck packets contain
information on host#, vds# port#, which an attacker would find useful. It is recommended
that network healthcheck be used for troubleshooting, and turned off when
troubleshooting is finished.
Audit:
Remediation:
Impact:
Limit the use of this feature only to when actively troubleshooting VLAN or MTU issues on
a VDS.
Default Value:
7.1.2 Ensure that the MAC Address Change policy is set to reject (Scored)
Profile Applicability:
Level 1
Description:
Rationale:
If the virtual machine operating system changes the MAC address, it can send frames with
an impersonated source MAC address at any time. This allows it to stage malicious attacks
on the devices in a network by impersonating a network adaptor authorized by the
receiving network. This will prevent VMs from changing their effective MAC address. It will
affect applications that require this functionality. An example of an application like this is
Microsoft Clustering, which requires systems to effectively share a MAC address. This will
also affect how a layer 2 bridge will operate. This will also affect applications that require a
specific MAC address for licensing. An exception should be made for the dvPortgroups that
these applications are connected to.
Audit:
1. Verify by using the vSphere Client to connect to the vCenter Server and logging in as
an administrator.
2. Go to "Home > Inventory > Networking".
3. Select each dvPortgroup connected to active VMs requiring securing.
4. Go to tab "Summary > Edit Settings > Policies > Security".
5. "Mac Address Changes" = "Reject"
Remediation:
1. Configure by using the vSphere Client to connect to the vCenter Server and logging
in as an administrator.
2. Go to "Home > Inventory > Networking".
3. Select each dvPortgroup connected to active VMs requiring securing.
4. Go to tab "Summary > Edit Settings > Policies > Security".
5. Set "Mac Address Changes" = "Reject"
Impact:
This will prevent VMs from changing their effective MAC address. It will affect applications
that require this functionality. An example of an application like this is Microsoft Clustering,
which requires systems to effectively share a MAC address. This will also affect how a layer
2 bridge will operate. This will also affect applications that require a specific MAC address
for licensing. An exception should be made for the dvPortgroups that these applications are
connected to.
References:
1. http://pubs.vmware.com/vsphere-
51/topic/com.vmware.wssdk.apiref.doc/vim.host.NetworkPolicy.SecurityPolicy.ht
ml
7.1.3 Ensure that the Promiscuous Mode policy is set to reject (Scored)
Profile Applicability:
Level 1
Description:
Rationale:
When promiscuous mode is enabled for a dvPortgroup, all virtual machines connected to
the dvPortgroup have the potential of reading all packets across that network, meaning
only the virtual machines connected to that dvPortgroup. Promiscuous mode is disabled by
default on the ESXi host, and this is the recommended setting. However, there might be a
legitimate reason to enable it for debugging, monitoring or troubleshooting reasons.
Security devices might require the ability to see all packets on a vSwitch. An exception
should be made for the dvPortgroups that these applications are connected to, in order to
allow for full-time visibility to the traffic on that dvPortgroup.
Audit:
1. Verify by using the vSphere Client to connect to the vCenter Server and logging in as
an administrator.
2. Go to "Home > Inventory > Networking".
3. Select each dvPortgroup connected to active VM's requiring securing.
4. Go to tab "Summary > Edit Settings > Policies > Security".
5. Configure "Promiscuous Mode" = "Reject"
Remediation:
1. Verify by using the vSphere Client to connect to the vCenter Server and logging in as
an administrator.
2. Go to "Home > Inventory > Networking".
3. Select each dvPortgroup connected to active VMs requiring securing.
4. Go to tab "Summary > Edit Settings > Policies > Security".
5. Configure "Promiscuous Mode" = "Reject"
Impact:
Security devices that require the ability to see all packets on a vSwitch will not operate
properly if the Promiscuous Mode parameter is set to Reject.
Default Value:
References:
1. http://pubs.vmware.com/vsphere-
51/topic/com.vmware.wssdk.apiref.doc/vim.host.NetworkPolicy.SecurityPolicy.ht
ml
7.1.4 Ensure that there are no unused ports on a distributed virtual port
group (Scored)
Profile Applicability:
Level 1
Description:
Ensure that there are no unused ports on a distributed virtual port group.
Rationale:
The number of ports available on a vdSwitch distributed port group can be adjusted to
exactly match the number of virtual machine vNICs that need to be assigned to that
dvPortgroup. Limiting the number of ports to just what is needed limits the potential for an
administrator, either accidentally or maliciously, to move a virtual machine to an
unauthorized network. This is especially relevant if the management network is on a
dvPortgroup, because it could help prevent someone from putting a rogue virtual machine
on this network.
Audit:
$VDSPG.ExtensionData.Vm | Foreach {
$VMView = Get-View $_
$nic = $VMView.Config.Hardware.Device | where {$nicTypes -contains $_.GetType().Name -
and $_.Backing.GetType().Name -match "Distributed"}
$nic | where {$_.Backing.Port.PortKey} | Foreach
{$ports.Remove($_.Backing.Port.PortKey)}
}
($ports.Keys).Count
}
}
Get-VirtualPortGroup -Distributed | Select Name, @{N="NumFreePorts";E={Get-FreeVDSPort
-VDSPG $_}}
Remediation:
1. Connect to the vCenter Server with vSphere Client ( Home > Inventory >
Networking view, find all dvSwitches) or the Web Client (Networking > vDS name >
dvPortgroup name > Manage > Edit Settings > General)
2. Configure the number of ports available to be only the amount required for
legitimate virtual machine connections to that dvPortgroup.
Impact:
The VDS or dvPortgroup on the VDS will not have any extra available port capacity.
References:
1. http://pubs.vmware.com/vsphere-
51/topic/com.vmware.wssdk.apiref.doc/vim.dvs.DistributedVirtualPortgroup.html
7.1.5 Ensure that VDS Port Mirror traffic is only being sent to authorized
collector ports or VLANs (Not Scored)
Profile Applicability:
Level 1
Description:
Ensure that VDS Port Mirror traffic is only being sent to authorized collectors.
Rationale:
The vSphere VDS can mirror traffic from one port to another in order to allow for packet
capture devices to collect specific traffic flows. Port mirroring will send a copy of all traffic
specified in un-encrypted format. This mirrored traffic contains the full data in the packets
captured and can result in total compromise of that data if misdirected. If Port Mirroring is
required, verify that all Port Mirror Destination VLAN, Port and Uplink ID's are correct.
Audit:
Remediation:
References:
1. http://pubs.vmware.com/vsphere-
51/topic/com.vmware.vsphere.networking.doc/GUID-CFFD9157-FC17-440D-
BDB4-E16FD447A1BA.html
Level 1
Description:
Rationale:
If the "no-unused-dvports" guideline is followed, there should be only the exact number of
ports on a vDS that are actually needed. The Autoexpand feature on vDS dvPortgroups can
override that limit. The feature allows dvPortgroups to automatically add 10 virtual
distributed switch ports to a dvPortgroup that has run out of available ports. The risk is
that maliciously or inadvertently, a virtual machine that is not supposed to be part of that
portgroup is able to affect confidentiality, integrity or authenticity of data of other virtual
machines on that portgroup. To reduce the risk of inappropriate dvPortgroup access, the
autoexpand option on VDS should be disabled. By default the option is disabled, but regular
monitoring should be implemented to verify this has not been changed.
Audit:
Remediation:
Default Value:
References:
1. http://kb.vmware.com/kb/1022312
7.2 VLAN
This section contains recommendations for VLAN configuration.
7.2.1 Ensure that port groups are not configured to the value of the
native VLAN (Scored)
Profile Applicability:
Level 1
Description:
Rationale:
ESXi does not use the concept of native VLAN. Frames with VLAN specified in the port
group will have a tag, but frames with VLAN not specified in the port group are not tagged
and therefore will end up as belonging to native VLAN of the physical switch. For example,
frames on VLAN 1 from a Cisco physical switch will be untagged, because this is considered
as the native VLAN. However, frames from ESXi specified as VLAN 1 will be tagged with a 1;
therefore, traffic from ESXi that is destined for the native VLAN will not be correctly routed
(because it is tagged with a 1 instead of being untagged), and traffic from the physical
switch coming from the native VLAN will not be visible (because it is not tagged). If the
ESXi virtual switch port group uses the native VLAN ID, traffic from those VMs will not be
visible to the native VLAN on the switch, because the switch is expecting untagged traffic.
Audit:
If the default value of 1 for the native VLAN is being used, the ESXi Server virtual switch
port groups should be configured with any value between 2 and 4094. Otherwise, ensure
that the port group is not configured to use whatever value is set for the native VLAN.
Remediation:
If the default value of 1 for the native VLAN is being used, the ESXi Server virtual switch
port groups should be configured with any value between 2 and 4094. Otherwise, ensure
that the port group is not configured to use whatever value is set for the native VLAN.
7.2.2 Ensure that port groups are not configured to VLAN 4095 except
for Virtual Guest Tagging (VGT) (Scored)
Profile Applicability:
Level 1
Description:
Don't use VLAN 4095 except for Virtual Guest Tagging (VGT).
Rationale:
When a port group is set to VLAN 4095, this activates VGT mode. In this mode, the vSwitch
passes all network frames to the guest VM without modifying the VLAN tags, leaving it up
to the guest to deal with them. VLAN 4095 should be used only if the guest has been
specifically configured to manage VLAN tags itself. If VGT is enabled inappropriately, it
might cause denial of service or allow a guest VM to interact with traffic on an
unauthorized VLAN.
Audit:
VLAN ID setting on all port groups should not be set to 4095 unless VGT is required.
Remediation:
VLAN ID setting on all port groups should not be set to 4095 unless VGT is required.
7.2.3 Ensure that port groups are not configured to VLAN values
reserved by upstream physical switches (Not Scored)
Profile Applicability:
Level 1
Description:
Ensure that port groups are not configured to VLAN values reserved by upstream physical
switches
Rationale:
Certain physical switches reserve certain VLAN IDs for internal purposes and often
disallow traffic configured to these values. For example, Cisco Catalyst switches typically
reserve VLANs 1001 through 1024 and 4094, while Nexus switches typically reserve 3968
through 4047 and 4094. Check with the documentation for your specific switch. Using a
reserved VLAN might result in a denial of service on the network.
Audit:
VLAN ID setting on all port groups should not be set to reserved values of the physical
switch.
Remediation:
VLAN ID setting on all port groups should not be set to reserved values of the physical
switch.
References:
1. http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst4500/12-
2/20ew/configuration/guide/config/vlans.html#wp1038758
2. http://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus5500/sw/laye
r2/7x/b_5500_Layer2_Config_7x/b_5500_Layer2_Config_7x_chapter_010.html#con_
1143823
7.3 vSwitch
This section contains recommendations for securing vSwitches.
7.3.1 Ensure that the vSwitch Forged Transmits policy is set to reject
(Scored)
Profile Applicability:
Level 1
Description:
Set the vSwitch Forged Transmits policy is set to reject for each vSwitch.
Rationale:
If the virtual machine operating system changes the MAC address, the operating system can
send frames with an impersonated source MAC address at any time. This allows an
operating system to stage malicious attacks on the devices in a network by impersonating a
network adaptor authorized by the receiving network. Forged transmissions should be set
to accept by default. This means the virtual switch does not compare the source and
effective MAC addresses. To protect against MAC address impersonation, all virtual
switches should have forged transmissions set to reject.
Audit:
Verify by using the vSphere Client to connect to the vCenter Server and as administrator:
Verify by using the vSphere Client to connect to the vCenter Server and as administrator:
Impact:
This will prevent VMs from changing their effective MAC address. This will affect
applications that require this functionality. An example of an application like this is
Microsoft Clustering, which requires systems to effectively share a MAC address. This will
also affect how a layer 2 bridge will operate. This will also affect applications that require a
specific MAC address for licensing. An exception should be made for the port groups that
these applications are connected to.
References:
1. http://pubs.vmware.com/vsphere-
51/topic/com.vmware.vsphere.networking.doc/GUID-74E2059A-CC5E-4B06-81B5-
3881C80E46CE.html
7.3.2 Ensure that the vSwitch MAC Address Change policy is set to reject
(Scored)
Profile Applicability:
Level 1
Description:
Ensure that the MAC Address Change policy within the vSwitch is set to reject.
Rationale:
If the virtual machine operating system changes the MAC address, it can send frames with
an impersonated source MAC address at any time. This allows it to stage malicious attacks
on the devices in a network by impersonating a network adaptor authorized by the
receiving network. This will prevent VMs from changing their effective MAC address. It will
affect applications that require this functionality. An example of an application like this is
Microsoft Clustering, which requires systems to effectively share a MAC address. This will
also affect how a layer 2 bridge will operate. This will also affect applications that require a
specific MAC address for licensing. An exception should be made for the port groups that
these applications are connected to.
Audit:
Verify by using the vSphere Client to connect to the vCenter Server and as administrator:
Remediation:
Using the vSphere Client, connect to the vCenter Server and as administrator:
Impact:
This will prevent VMs from changing their effective MAC address. It will affect applications
that require this functionality. An example of an application like this is Microsoft Clustering,
which requires systems to effectively share a MAC address. This will also affect how a layer
2 bridge will operate. This will also affect applications that require a specific MAC address
for licensing. An exception should be made for the port groups that these applications are
connected to.
References:
1. http://pubs.vmware.com/vsphere-
51/topic/com.vmware.vsphere.networking.doc/GUID-74E2059A-CC5E-4B06-81B5-
3881C80E46CE.html
7.3.3 Ensure that the vSwitch Promiscuous Mode policy is set to reject
(Scored)
Profile Applicability:
Level 1
Description:
Ensure that the Promiscuous Mode Policy within the vSwitch is set to reject.
Rationale:
When promiscuous mode is enabled for a virtual switch all virtual machines connected to
the dvPortgroup have the potential of reading all packets crossing that network.
Promiscuous mode is disabled by default on the ESXi Server, and this is the recommended
setting. However, there might be a legitimate reason to enable it for debugging, monitoring
or troubleshooting reasons. Security devices might require the ability to see all packets on
a vSwitch. An exception should be made for the dvPortgroups that these applications are
connected to, in order to allow for full-time visibility to the traffic on that dvPortgroup.
Audit:
Verify by using the vSphere Client to connect to the vCenter Server and as administrator:
Remediation:
Using the vSphere Client, connect to the vCenter Server and as administrator:
Additionally, perform the following to implement the recommended configuration state via
the ESXi shell:
Impact:
Security devices that require the ability to see all packets on a vSwitch will not operate
properly if the Promiscuous Mode parameter is set to Reject.
Default Value:
References:
1. http://kb.vmware.com/kb/1004099
8 Virtual Machines
8.1 Communication
8.1.1 Disable VM communication through VMCI (Scored)
Profile Applicability:
Level 1
Description:
Rationale:
If the interface is not restricted, a VM can detect and be detected by all other VMs with the
same option enabled within the same host. This might be the intended behavior, but
custom-built software can have unexpected vulnerabilities that might potentially lead to an
exploit. Additionally, it is possible for a VM to detect how many other VMs are within the
same ESXI system by simply registering the VM. This information might also be used for a
potentially malicious objective. By default, the setting is FALSE. The VM can be exposed to
other VMs within the same system as long as there is at least one program connected to the
VMCI socket interface.
Audit:
Check virtual machine configuration file and verify that vmci0.unrestricted is set to FALSE
Remediation:
Impact:
Default Value:
References:
1. http://pubs.vmware.com/vsphere-
51/topic/com.vmware.ICbase/PDF/ws8x_esx51_vmci_sockets.pdf
8.1.2 Limit informational messages from the VM to the VMX file (Scored)
Profile Applicability:
Level 1
Description:
Limit informational messages from the virtual machine to the VMX file to avoid filling the
datastore and causing a Denial of Service (DoS).
Rationale:
The configuration file containing these name-value pairs is limited to a size of 1MB. This
1MB capacity should be sufficient for most cases, but you can change this value if
necessary. You might increase this value if large amounts of custom information are being
stored in the configuration file. The default limit is 1MB; this limit is applied even when the
sizeLimit parameter is not listed in the .vmx file. Uncontrolled size for the VMX file can
lead to denial of service if the datastore is filled.
Audit:
Check virtual machine configuration file and verify that tools.setInfo.sizeLimit is set to
1048576.
Default Value:
References:
1. http://pubs.vmware.com/vsphere-
51/topic/com.vmware.vmtools.install.doc/GUID-685722FA-9009-439C-9142-
18A9E7C592EA.html
Level 1
Description:
Rationale:
By default, remote console sessions can be connected to by more than one user at a time.
When multiple sessions are activated, each terminal window gets a notification about the
new session. If an administrator in the VM logs in using a VMware remote console during
their session, a non-administrator in the VM might connect to the console and observe the
administrator's actions. Also, this could result in an administrator losing console access to a
virtual machine. For example if a jump box is being used for an open console session, and
the admin loses connection to that box, then the console session remains open. Allowing
two console sessions permits debugging via a shared session. For highest security, only one
remote console session at a time should be allowed.
Audit:
Remediation:
Impact:
Only one remote console connection to the VM will be permitted. Other attempts will be
rejected until the first session disconnects.
Default Value:
References:
1. http://kb.vmware.com/kb/2015407
8.2 Devices
8.2.1 Disconnect unauthorized devices - Floppy Devices (Scored)
Profile Applicability:
Level 1
Description:
Any enabled or connected device represents a potential attack channel. Users and
processes without privileges on a virtual machine can connect or disconnect hardware
devices, such as network adapters and CD-ROM drives. Attackers can use this capability to
breach virtual machine security. Removing unnecessary hardware devices can help prevent
attacks.
Rationale:
Besides disabling unnecessary virtual devices from within the virtual machine, you should
ensure that no device is connected to a virtual machine if it is not required to be there. For
example, serial and parallel ports are rarely used for virtual machines in a datacenter
environment, and CD/DVD drives are usually connected only temporarily during software
installation. For less commonly used devices that are not required, either the parameter
should not be present or its value must be FALSE.
NOTE: The parameters listed are not sufficient to ensure that a device is usable; other
parameters are required to indicate specifically how each device is instantiated. Any
enabled or connected device represents another potential attack channel.
Audit:
The following parameters should either NOT be present or should be set to FALSE, unless
Floppy drives are required: floppyX.present
Remediation:
Impact:
Virtual machine will need to be powered off to reverse change if any of these devices are
needed at a later time.
Default Value:
References:
1. http://pubs.vmware.com/vsphere-
51/topic/com.vmware.vsphere.security.doc/GUID-822B2ED3-D8D2-4F57-8335-
CA46E915A729.html
Level 1
Description:
Any enabled or connected device represents a potential attack channel. Users and
processes without privileges on a virtual machine can connect or disconnect hardware
devices, such as network adapters and CD-ROM drives. Attackers can use this capability to
breach virtual machine security. Removing unnecessary hardware devices can help prevent
attacks.
Rationale:
Besides disabling unnecessary virtual devices from within the virtual machine, you should
ensure that no device is connected to a virtual machine if it is not required to be there. For
example, serial and parallel ports are rarely used for virtual machines in a datacenter
environment, and CD/DVD drives are usually connected only temporarily during software
installation. For less commonly used devices that are not required, either the parameter
should not be present or its value must be FALSE.
NOTE: The parameters listed are not sufficient to ensure that a device is usable; other
parameters are required to indicate specifically how each device is instantiated. Any
enabled or connected device represents another potential attack channel.
Audit:
The following parameters should either NOT be present or should be set to FALSE, unless
CD-ROM is required: ideX:Y.present
Remediation:
Impact:
Virtual machine will need to be powered off to reverse change if any of these devices are
needed at a later time.
Default Value:
References:
1. http://pubs.vmware.com/vsphere-
51/topic/com.vmware.vsphere.security.doc/GUID-822B2ED3-D8D2-4F57-8335-
CA46E915A729.html
Level 1
Description:
Any enabled or connected device represents a potential attack channel. Users and
processes without privileges on a virtual machine can connect or disconnect hardware
devices, such as network adapters and CD-ROM drives. Attackers can use this capability to
breach virtual machine security. Removing unnecessary hardware devices can help prevent
attacks.
Rationale:
Besides disabling unnecessary virtual devices from within the virtual machine, you should
ensure that no device is connected to a virtual machine if it is not required to be there. For
example, serial and parallel ports are rarely used for virtual machines in a datacenter
environment, and CD/DVD drives are usually connected only temporarily during software
installation. For less commonly used devices that are not required, either the parameter
should not be present or its value must be FALSE.
NOTE: The parameters listed are not sufficient to ensure that a device is usable; other
parameters are required to indicate specifically how each device is instantiated. Any
enabled or connected device represents another potential attack channel.
Audit:
The following parameters should either NOT be present or should be set to FALSE, unless
Parallel ports are required: parallelX.present
Remediation:
Impact:
Virtual machine will need to be powered off to reverse change if any of these devices are
needed at a later time.
Default Value:
References:
1. http://pubs.vmware.com/vsphere-
51/topic/com.vmware.vsphere.security.doc/GUID-822B2ED3-D8D2-4F57-8335-
CA46E915A729.html
Level 1
Description:
Any enabled or connected device represents a potential attack channel. Users and
processes without privileges on a virtual machine can connect or disconnect hardware
devices, such as network adapters and CD-ROM drives. Attackers can use this capability to
breach virtual machine security. Removing unnecessary hardware devices can help prevent
attacks.
Rationale:
Besides disabling unnecessary virtual devices from within the virtual machine, you should
ensure that no device is connected to a virtual machine if it is not required to be there. For
example, serial and parallel ports are rarely used for virtual machines in a datacenter
environment, and CD/DVD drives are usually connected only temporarily during software
installation. For less commonly used devices that are not required, either the parameter
should not be present or its value must be FALSE.
NOTE: The parameters listed are not sufficient to ensure that a device is usable; other
parameters are required to indicate specifically how each device is instantiated. Any
enabled or connected device represents another potential attack channel.
Audit:
The following parameters should either NOT be present or should be set to FALSE, unless
Serial ports are required: serialX.present
# In this Example you will need to add the functions from this post:
http://blogs.vmware.com/vipowershell/2012/05/working-with-vm-devices-in-powercli.html
# Check for Serial ports attached to VMs
Get-VM | Get-SerialPort
Remediation:
To implement the recommended configuration state, run the following PowerCLI
command:
# In this Example you will need to add the functions from this post:
http://blogs.vmware.com/vipowershell/2012/05/working-with-vm-devices-in-powercli.html
# Remove all Serial Ports attached to VMs
Get-VM | Get-SerialPort | Remove-SerialPort
Impact:
Virtual machine will need to be powered off to reverse change if any of these devices are
needed at a later time.
Default Value:
References:
1. http://pubs.vmware.com/vsphere-
51/topic/com.vmware.vsphere.security.doc/GUID-822B2ED3-D8D2-4F57-8335-
CA46E915A729.html
Level 1
Description:
Any enabled or connected device represents a potential attack channel. Users and
processes without privileges on a virtual machine can connect or disconnect hardware
devices, such as network adapters and CD-ROM drives. Attackers can use this capability to
breach virtual machine security. Removing unnecessary hardware devices can help prevent
attacks.
Rationale:
Besides disabling unnecessary virtual devices from within the virtual machine, you should
ensure that no device is connected to a virtual machine if it is not required to be there. For
example, serial and parallel ports are rarely used for virtual machines in a datacenter
environment, and CD/DVD drives are usually connected only temporarily during software
installation. For less commonly used devices that are not required, either the parameter
should not be present or its value must be FALSE.
NOTE: The parameters listed are not sufficient to ensure that a device is usable; other
parameters are required to indicate specifically how each device is instantiated. Any
enabled or connected device represents another potential attack channel.
Audit:
The following parameters should either NOT be present or should be set to FALSE, unless
USB controllers are required: usb.present
Remediation:
Impact:
Virtual machine will need to be powered off to reverse change if any of these devices are
needed at a later time.
Default Value:
References:
1. http://pubs.vmware.com/vsphere-
51/topic/com.vmware.vsphere.security.doc/GUID-822B2ED3-D8D2-4F57-8335-
CA46E915A729.html
Level 1
Description:
Prevent unauthorized removal, connection, and modification of devices.
Rationale:
Normal users and processes - that is, users and processes without root or administrator
privileges within virtual machines have the capability to connect or disconnect devices,
such as network adaptors and CD-ROM drives, as well as the ability to modify device
settings. In general, you should use the virtual machine settings editor or configuration
editor to remove any unneeded or unused hardware devices. However, you might want to
use the device again, so removing it is not always a good solution. In that case, you can
prevent a user or running process in the virtual machine from connecting or disconnecting
a device from within the guest operating system, as well as modifying devices, by adding
the following parameters.
Audit:
Remediation:
Impact:
Default Value:
The prescribed state is not the default state.
References:
1. http://pubs.vmware.com/vsphere-
51/topic/com.vmware.vsphere.security.doc/GUID-C5898E50-2182-4B71-BADC-
C9BFA409FB6C.html
2. http://pubs.vmware.com/vsphere-
51/topic/com.vmware.vmtools.install.doc/GUID-685722FA-9009-439C-9142-
18A9E7C592EA.html
8.3 Guest
8.3.1 Disable unnecessary or superfluous functions inside VMs (Not
Scored)
Profile Applicability:
Level 1
Description:
Rationale:
By disabling unnecessary system components that are not needed to support the
application or service running on the system, you reduce the number of parts that can be
attacked. VMs often don't require as many services or functions as ordinary physical
servers; so when virtualizing, you should evaluate whether a particular service or function
is truly needed. Any service running in a VM provides a potential avenue of attack.
Audit:
1. Unused services in the operating system. For example, if the system runs a file
server, make sure to turn off any Web services.
2. Unused physical devices, such as CD/DVD drives, floppy drives, and USB adaptors.
This is described in the Removing Unnecessary Hardware Devices section in the
ESXI Configuration Guide.
3. Screen savers. X-Windows if using a Linux, BSD, or Solaris guest operating system.
Remediation:
1. Disable unused services in the operating system. For example, if the system runs a
file server, make sure to turn off any Web services.
2. Disconnect unused physical devices, such as CD/DVD drives, floppy drives, and USB
adaptors. This is described in the Removing Unnecessary Hardware Devices section
in the ESXI Configuration Guide.
3. Turn off any screen savers. If using a Linux, BSD, or Solaris guest operating system,
do not run the X Window system unless it is necessary.
References:
1. http://pubs.vmware.com/vsphere-
51/topic/com.vmware.vsphere.security.doc/GUID-6BFA8CA7-610F-4E6B-9FC6-
D656917B7E7A.html
Level 1
Description:
Grant access to the Virtual Machine console only when needed. Use custom roles to provide
fine grained permissions.
Rationale:
The VM console enables you to connect to the console of a virtual machine, in effect seeing
what a monitor on a physical server would show. The VM console also provides power
management and removable device connectivity controls, which might potentially allow a
malicious user to bring down a virtual machine. In addition, it also has a performance
impact on the service console, especially if many VM console sessions are open
simultaneously.
Audit:
Instead of VM console, use native remote management services, such as terminal services
and ssh, to interact with virtual machines. Grant VM console access only when necessary.
Remediation:
By default the vCenter roles "Virtual Machine Power User" and "Virtual Machine
Administrator" have the "Virtual Machine.Interaction.Console Interaction" privilege. Do not
allow unauthorized individuals to have these roles on a virtual machine or folder of virtual
machines.
References:
1. http://www.vmware.com/support/developer/PowerCLI/PowerCLI51/html/Invok
e-VMScript.html
2. http://pubs.vmware.com/vsphere-
51/topic/com.vmware.vsphere.security.doc/GUID-3D47149A-947D-4608-88B3-
E5811129EFA8.html
8.3.3 Use secure protocols for virtual serial port access (Not Scored)
Profile Applicability:
Level 1
Description:
Virtual serial ports allow virtual machines to communicate over the network. Doing so
allows you to redirect the virtual serial port connection to a TCP/IP connection on the ESXi
host. If virtual serial ports are needed be sure they are configured to use secure protocols.
Rationale:
Serial ports are interfaces for connecting peripherals to the virtual machine. They are often
used on physical systems to provide a direct, low-level connection to the console of a
server. Serial ports allow for debug level access, which often does not have strong controls
like logging or privileges.
Audit:
Remediation:
References:
1. http://pubs.vmware.com/vsphere-
51/topic/com.vmware.wssdk.apiref.doc/vim.vm.device.VirtualSerialPort.URIBackin
gInfo.html
2. http://kb.vmware.com/kb/2004954
3. http://pubs.vmware.com/vsphere-
51/topic/com.vmware.wssdk.vsp.doc/virtual_serial_port_using_proxy_Chapter1.3.2.
html
Level 1
Description:
Use a hardened base operating system template image to create other, application-specific
templates and use the application-specific templates to deploy virtual machines.
Rationale:
Audit:
Verify that new virtual machine deployments are completed using hardened, patched, and
properly configured OS templates.
Remediation:
Provide templates for VM creation that contain hardened, patched, and properly configured
OS deployments. If possible, pre-deploy applications in templates as well, although care
should be taken that the application doesn't depend upon VM-specific information to be
deployed. In vSphere, you can convert a template to a virtual machine and back again
quickly, which makes updating templates quite easy.
References:
1. http://pubs.vmware.com/vsphere-
51/topic/com.vmware.vsphere.vm_admin.doc/GUID-9062F225-E01B-42BA-8AFB-
8EA4069068FE.html
8.4 Monitor
8.4.1 Control access to VMs through the dvfilter network APIs (Not
Scored)
Profile Applicability:
Level 1
Description:
Rationale:
A VM must be configured explicitly to accept access by the dvfilter network API. This
should be done only for VMs for which you want this to be done. An attacker might
compromise the VM by making use of this introspection channel.
Audit:
If a VM is supposed to be protected:
Verify that the following is not in its VMX file: ethernet0.filter1.name = dv-
filter1 where ethernet0 is the network adapter interface of the virtual machine
that is to be protected, filter1 is the number of the filter that is being used, and dv-
filter1 is the name of the particular data path kernel module that is protecting the
VM.
Remediation:
If a VM is supposed to be protected:
Impact:
Incorrectly configuring this option can negatively impact functionality of tools that use
vmsafe API.
Incorrectly configuring this option can prevent VMs from connecting to the network.
Default Value:
References:
1. http://kb.vmware.com/kb/1714
2. http://kb.vmware.com/kb/1028151
Level 1
Description:
Rationale:
The VMsafe CPU/memory API allows a security virtual machine to inspect and modify the
contents of the memory and CPU registers on other VMs, for the purpose of detecting and
preventing malware attacks. However, an attacker might compromise the VM by making
use of this introspection channel; therefore you should monitor for unauthorized usage of
this API. A VM must be configured explicitly to accept access by the VMsafe CPU/memory
API.
If the VM is being protected by such a product, then make sure the latter two parameters
are set correctly. This should be done only for specific VMs for which you want this
protection.
Audit:
If the VM is not being protected by a VMsafe CPU/memory product, then check virtual
machine configuration file and verify that vmsafe.agentAddress is not present.
Remediation:
If the VM is not being protected by a VMsafe CPU/memory product, then check virtual
machine configuration file and verify that vmsafe.agentAddress is not present.
If it is being protected by a VMsafe CPU/Memory product then make sure this is set to the
correct value
Impact:
Incorrectly configuring this option can negatively impact functionality of tools that use
VMsafe API.
Default Value:
References:
1. http://kb.vmware.com/kb/1714
2. http://www.vmware.com/files/xls/hardeningguide-vsphere5-1-ga-release-
public.xlsx
Level 1
Description:
Configure the vmsafe.agentPort option in the virtual machine configuration file correctly.
Rationale:
The VMsafe CPU/memory API allows a security virtual machine to inspect and modify the
contents of the memory and CPU registers on other VMs, for the purpose of detecting and
preventing malware attacks. However, an attacker might compromise the VM by making
use of this introspection channel; therefore you should monitor for unauthorized usage of
this API. A VM must be configured explicitly to accept access by the VMsafe CPU/memory
API.
If the VM is being protected by such a product, then make sure the latter two parameters
are set correctly. This should be done only for specific VMs for which you want this
protection.
Audit:
If the VM is not being protected by a VMsafe CPU/memory product, then check virtual
machine configuration file and verify that vmsafe.agentPort is not present. If it is being
protect by a VMsafe CPU/Memory product, make sure this is set to the correct value
If the VM is not being protected by a VMsafe CPU/memory product, then check virtual
machine configuration file and verify that vmsafe.agentPort is not present.
Impact:
Incorrectly configuring this option can negatively impact functionality of tools that use
VMsafe API.
Default Value:
References:
1. http://kb.vmware.com/kb/1714
2. http://www.vmware.com/files/xls/hardeningguide-vsphere5-1-ga-release-
public.xlsx
Level 1
Description:
Configure the vmsafe.enable option in the virtual machine configuration file correctly.
Rationale:
The VMsafe CPU/memory API allows a security virtual machine to inspect and modify the
contents of the memory and CPU registers on other VMs, for the purpose of detecting and
preventing malware attacks. However, an attacker might compromise the VM by making
use of this introspection channel; therefore you should monitor for unauthorized usage of
this API. A VM must be configured explicitly to accept access by the VMsafe CPU/memory
API.
If the VM is being protected by such a product, then make sure the latter two parameters
are set correctly. This should be done only for specific VMs for which you want this
protection.
Audit:
If the VM is not being protected by a VMsafe CPU/memory product, then check virtual
machine configuration file and verify that vmsafe.enable is either not present, or set to
FALSE.
Remediation:
If the VM is not being protected by a VMsafe CPU/memory product, then check virtual
machine configuration file and set vmsafe.enable to FALSE.
Impact:
Incorrectly configuring this option can negatively impact functionality of tools that use
vmsafe API.
Default Value:
References:
1. http://kb.vmware.com/kb/1714
2. http://www.vmware.com/files/xls/hardeningguide-vsphere5-1-ga-release-
public.xlsx
Level 2
Description:
Rationale:
Because VMware virtual machines are designed to work on both vSphere as well as hosted
virtualization platforms such as Workstation and Fusion, there are some VMX parameters
that don't apply when running on vSphere. Although the functionality governed by these
parameters is not exposed on ESX, explicitly disabling them will reduce the potential for
vulnerabilities. Disabling these features reduces the number of vectors through which a
guest can attempt to influence the host, and thus may help prevent successful exploits.
Audit:
Remediation:
Default Value:
References:
1. http://pubs.vmware.com/vsphere-
51/topic/com.vmware.vsphere.security.doc/GUID-60E83710-8295-41A2-9C9D-
83DEBB6872C2.html
Description:
Rationale:
Because VMware virtual machines are designed to work on both vSphere as well as hosted
virtualization platforms such as Workstation and Fusion, there are some VMX parameters
that don't apply when running on vSphere. Although the functionality governed by these
parameters is not exposed on ESX, explicitly disabling them will reduce the potential for
vulnerabilities. Disabling these features reduces the number of vectors through which a
guest can attempt to influence the host, and thus may help prevent successful exploits.
Audit:
Remediation:
Default Value:
References:
1. http://pubs.vmware.com/vsphere-
51/topic/com.vmware.vsphere.security.doc/GUID-60E83710-8295-41A2-9C9D-
83DEBB6872C2.html
Level 2
Description:
Disable Guest Host Interaction Protocol Handle to reduce opportunity for vulnerabilities.
Rationale:
Because VMware virtual machines are designed to work on both vSphere as well as hosted
virtualization platforms such as Workstation and Fusion, there are some VMX parameters
that don't apply when running on vSphere. Although the functionality governed by these
parameters is not exposed on ESX, explicitly disabling them will reduce the potential for
vulnerabilities. Disabling these features reduces the number of vectors through which a
guest can attempt to influence the host, and thus may help prevent successful exploits.
Audit:
Remediation:
Impact:
Default Value:
References:
1. https://pubs.vmware.com/vsphere-
51/topic/com.vmware.vmtools.install.doc/GUID-685722FA-9009-439C-9142-
18A9E7C592EA.html
Level 2
Description:
Rationale:
Because VMware virtual machines are designed to work on both vSphere as well as hosted
virtualization platforms such as Workstation and Fusion, there are some VMX parameters
that don't apply when running on vSphere. Although the functionality governed by these
parameters is not exposed on ESX, explicitly disabling them will reduce the potential for
vulnerabilities. Disabling these features reduces the number of vectors through which a
guest can attempt to influence the host, and thus may help prevent successful exploits.
Audit:
Remediation:
Impact:
References:
1. https://pubs.vmware.com/vsphere-
51/topic/com.vmware.vmtools.install.doc/GUID-685722FA-9009-439C-9142-
18A9E7C592EA.html
Level 2
Description:
Rationale:
Because VMware virtual machines are designed to work on both vSphere as well as hosted
virtualization platforms such as Workstation and Fusion, there are some VMX parameters
that don't apply when running on vSphere. Although the functionality governed by these
parameters is not exposed on ESX, explicitly disabling them will reduce the potential for
vulnerabilities. Disabling these features reduces the number of vectors through which a
guest can attempt to influence the host, and thus may help prevent successful exploits.
Audit:
Remediation:
Impact:
Default Value:
References:
1. https://pubs.vmware.com/vsphere-
51/topic/com.vmware.vmtools.install.doc/GUID-685722FA-9009-439C-9142-
18A9E7C592EA.html
Level 2
Description:
Rationale:
Because VMware virtual machines are designed to work on both vSphere as well as hosted
virtualization platforms such as Workstation and Fusion, there are some VMX parameters
that don't apply when running on vSphere. Although the functionality governed by these
parameters is not exposed on ESX, explicitly disabling them will reduce the potential for
vulnerabilities. Disabling these features reduces the number of vectors through which a
guest can attempt to influence the host, and thus may help prevent successful exploits.
Audit:
Impact:
Default Value:
References:
1. https://pubs.vmware.com/vsphere-
51/topic/com.vmware.vmtools.install.doc/GUID-685722FA-9009-439C-9142-
18A9E7C592EA.html
Level 2
Description:
Rationale:
Because VMware virtual machines are designed to work on both vSphere as well as hosted
virtualization platforms such as Workstation and Fusion, there are some VMX parameters
that don't apply when running on vSphere. Although the functionality governed by these
parameters is not exposed on ESX, explicitly disabling them will reduce the potential for
vulnerabilities. Disabling these features reduces the number of vectors through which a
guest can attempt to influence the host, and thus may help prevent successful exploits.
Audit:
Remediation:
Impact:
Default Value:
References:
1. http://pubs.vmware.com/vsphere-
51/topic/com.vmware.vsphere.security.doc/GUID-60E83710-8295-41A2-9C9D-
83DEBB6872C2.html
Level 2
Description:
Rationale:
Because VMware virtual machines are designed to work on both vSphere as well as hosted
virtualization platforms such as Workstation and Fusion, there are some VMX parameters
that don't apply when running on vSphere. Although the functionality governed by these
parameters is not exposed on ESX, explicitly disabling them will reduce the potential for
vulnerabilities. Disabling these features reduces the number of vectors through which a
guest can attempt to influence the host, and thus may help prevent successful exploits.
Audit:
Remediation:
Impact:
Default Value:
References:
1. https://pubs.vmware.com/vsphere-
51/topic/com.vmware.vmtools.install.doc/GUID-685722FA-9009-439C-9142-
18A9E7C592EA.html
Level 2
Description:
Rationale:
Because VMware virtual machines are designed to work on both vSphere as well as hosted
virtualization platforms such as Workstation and Fusion, there are some VMX parameters
that don't apply when running on vSphere. Although the functionality governed by these
parameters is not exposed on ESX, explicitly disabling them will reduce the potential for
vulnerabilities. Disabling these features reduces the number of vectors through which a
guest can attempt to influence the host, and thus may help prevent successful exploits.
Audit:
Remediation:
Impact:
Default Value:
References:
1. https://pubs.vmware.com/vsphere-
51/topic/com.vmware.vmtools.install.doc/GUID-685722FA-9009-439C-9142-
18A9E7C592EA.html
Level 2
Description:
Disable unexposed Shell Action feature.
Rationale:
Because VMware virtual machines are designed to work on both vSphere as well as hosted
virtualization platforms such as Workstation and Fusion, there are some VMX parameters
that don't apply when running on vSphere. Although the functionality governed by these
parameters is not exposed on ESX, explicitly disabling them will reduce the potential for
vulnerabilities. Disabling these features reduces the number of vectors through which a
guest can attempt to influence the host, and thus may help prevent successful exploits.
Audit:
Remediation:
Impact:
Default Value:
References:
1. https://pubs.vmware.com/vsphere-
51/topic/com.vmware.vmtools.install.doc/GUID-685722FA-9009-439C-9142-
18A9E7C592EA.html
Level 2
Description:
Rationale:
Because VMware virtual machines are designed to work on both vSphere as well as hosted
virtualization platforms such as Workstation and Fusion, there are some VMX parameters
that don't apply when running on vSphere. Although the functionality governed by these
parameters is not exposed on ESX, explicitly disabling them will reduce the potential for
vulnerabilities. Disabling these features reduces the number of vectors through which a
guest can attempt to influence the host, and thus may help prevent successful exploits.
Audit:
Remediation:
Impact:
Default Value:
References:
1. https://pubs.vmware.com/vsphere-
51/topic/com.vmware.vmtools.install.doc/GUID-685722FA-9009-439C-9142-
18A9E7C592EA.html
Level 2
Description:
Rationale:
Because VMware virtual machines are designed to work on both vSphere as well as hosted
virtualization platforms such as Workstation and Fusion, there are some VMX parameters
that don't apply when running on vSphere. Although the functionality governed by these
parameters is not exposed on ESX, explicitly disabling them will reduce the potential for
vulnerabilities. Disabling these features reduces the number of vectors through which a
guest can attempt to influence the host, and thus may help prevent successful exploits.
Audit:
Remediation:
Impact:
References:
1. https://pubs.vmware.com/vsphere-
51/topic/com.vmware.vmtools.install.doc/GUID-685722FA-9009-439C-9142-
18A9E7C592EA.html
Level 2
Description:
Rationale:
Because VMware virtual machines are designed to work on both vSphere as well as hosted
virtualization platforms such as Workstation and Fusion, there are some VMX parameters
that don't apply when running on vSphere. Although the functionality governed by these
parameters is not exposed on ESX, explicitly disabling them will reduce the potential for
vulnerabilities. Disabling these features reduces the number of vectors through which a
guest can attempt to influence the host, and thus may help prevent successful exploits.
Audit:
Remediation:
Impact:
Default Value:
References:
1. https://pubs.vmware.com/vsphere-
51/topic/com.vmware.vmtools.install.doc/GUID-685722FA-9009-439C-9142-
18A9E7C592EA.html
Level 2
Description:
Rationale:
Because VMware virtual machines are designed to work on both vSphere as well as hosted
virtualization platforms such as Workstation and Fusion, there are some VMX parameters
that don't apply when running on vSphere. Although the functionality governed by these
parameters is not exposed on ESX, explicitly disabling them will reduce the potential for
vulnerabilities. Disabling these features reduces the number of vectors through which a
guest can attempt to influence the host, and thus may help prevent successful exploits.
Audit:
Impact:
Default Value:
References:
1. https://pubs.vmware.com/vsphere-
51/topic/com.vmware.vmtools.install.doc/GUID-685722FA-9009-439C-9142-
18A9E7C592EA.html
Level 2
Description:
Rationale:
Because VMware virtual machines are designed to work on both vSphere as well as hosted
virtualization platforms such as Workstation and Fusion, there are some VMX parameters
that don't apply when running on vSphere. Although the functionality governed by these
parameters is not exposed on ESX, explicitly disabling them will reduce the potential for
vulnerabilities. Disabling these features reduces the number of vectors through which a
guest can attempt to influence the host, and thus may help prevent successful exploits.
Audit:
Remediation:
Impact:
Default Value:
References:
1. https://pubs.vmware.com/vsphere-
51/topic/com.vmware.vmtools.install.doc/GUID-685722FA-9009-439C-9142-
18A9E7C592EA.html
Level 2
Description:
Rationale:
Because VMware virtual machines are designed to work on both vSphere as well as hosted
virtualization platforms such as Workstation and Fusion, there are some VMX parameters
that don't apply when running on vSphere. Although the functionality governed by these
parameters is not exposed on ESX, explicitly disabling them will reduce the potential for
vulnerabilities. Disabling these features reduces the number of vectors through which a
guest can attempt to influence the host, and thus may help prevent successful exploits.
Audit:
Remediation:
Impact:
Default Value:
References:
1. https://pubs.vmware.com/vsphere-
51/topic/com.vmware.vmtools.install.doc/GUID-685722FA-9009-439C-9142-
18A9E7C592EA.html
Level 2
Description:
Rationale:
Certain automated operations such as automated tools upgrades use a component into the
hypervisor called Host Guest File System (HGFS) and an attacker could potentially use this
to transfer files inside the guest OS.
Audit:
Remediation:
Impact:
Default Value:
References:
1. https://pubs.vmware.com/vsphere-
51/topic/com.vmware.vsphere.security.doc/GUID-60E83710-8295-41A2-9C9D-
83DEBB6872C2.html
Level 2
Description:
Rationale:
Because VMware virtual machines are designed to work on both vSphere as well as hosted
virtualization platforms such as Workstation and Fusion, there are some VMX parameters
that don't apply when running on vSphere. Although the functionality governed by these
parameters is not exposed on ESXi, explicitly disabling them will reduce the potential for
vulnerabilities. Disabling these features reduces the number of vectors through which a
guest can attempt to influence the host, and thus may help prevent successful exploits.
Audit:
Remediation:
Impact:
Default Value:
References:
1. https://pubs.vmware.com/vsphere-
51/topic/com.vmware.vsphere.security.doc/GUID-60E83710-8295-41A2-9C9D-
83DEBB6872C2.html
8.4.23 Disable memSchedFakeSampleStats (Scored)
Profile Applicability:
Level 2
Description:
Rationale:
Because VMware virtual machines are designed to work on both vSphere as well as hosted
virtualization platforms such as Workstation and Fusion, there are some VMX parameters
that don't apply when running on vSphere. Although the functionality governed by these
parameters is not exposed on ESX, explicitly disabling them will reduce the potential for
vulnerabilities. Disabling these features reduces the number of vectors through which a
guest can attempt to influence the host, and thus may help prevent successful exploits.
Audit:
Remediation:
Impact:
Default Value:
1. https://pubs.vmware.com/vsphere-
51/topic/com.vmware.vsphere.security.doc/GUID-60E83710-8295-41A2-9C9D-
83DEBB6872C2.html
Level 2
Description:
Rationale:
When Virtual Machines are running on a hypervisor they are "aware" that they are running
in a virtual environment and this and this information is available to tools inside the guest
OS. This can give attackers information about the platform that they are running on that
they may not get from a normal physical server. This option completely disables all hooks
for a virtual machine and the guest OS will not be aware that it is running in a virtual
environment at all.
Audit:
Remediation:
Impact:
This configuration option may cause unexpected results, the virtual machine will be
completely unaware that it is running in a virtualized setting. VMware tools will not install
or function.
Default Value:
References:
1. http://www.vmware.com/files/xls/hardeningguide-vsphere5-1-ga-release-
public.xlsx
Level 1
Description:
Rationale:
By default, the ability to copy and paste text, graphics, and files is disabled, as is the ability
to drag and drop files. When this feature is enabled, you can copy and paste rich text and,
depending on the VMware product, graphics and files from your clipboard to the guest
operating system in a virtual machine. That is, as soon as the console window of a virtual
machine gains focus, nonprivileged users and processes running in the virtual machine can
access the clipboard on the computer where the console window is running.
Audit:
Remediation:
To implement the recommended configuration state, run the following PowerCLI
command:
# Add the setting to all VMs
Get-VM | New-AdvancedSetting -Name "isolation.tools.copy.disable" -value $true
Impact:
Default Value:
References:
1. http://pubs.vmware.com/vsphere-
51/topic/com.vmware.vmtools.install.doc/GUID-685722FA-9009-439C-9142-
18A9E7C592EA.html
Level 1
Description:
Rationale:
By default, the ability to copy and paste text, graphics, and files is disabled, as is the ability
to drag and drop files. When this feature is enabled, you can copy and paste rich text and,
depending on the VMware product, graphics and files from your clipboard to the guest
operating system in a virtual machine. That is, as soon as the console window of a virtual
machine gains focus, nonprivileged users and processes running in the virtual machine can
access the clipboard on the computer where the console window is running.
Audit:
Remediation:
Impact:
Default Value:
References:
1. http://pubs.vmware.com/vsphere-
50/topic/com.vmware.vmtools.install.doc/GUID-685722FA-9009-439C-9142-
18A9E7C592EA.html
Level 1
Description:
Rationale:
By default, the ability to copy and paste text, graphics, and files is disabled, as is the ability
to drag and drop files. When this feature is enabled, you can copy and paste rich text and,
depending on the VMware product, graphics and files from your clipboard to the guest
operating system in a virtual machine. That is, as soon as the console window of a virtual
machine gains focus, nonprivileged users and processes running in the virtual machine can
access the clipboard on the computer where the console window is running.
Audit:
Check virtual machine configuration and verify that
isolation.tools.setGUIOptions.enable option is missing or set to FALSE.
Remediation:
Impact:
Default Value:
References:
1. http://pubs.vmware.com/vsphere-
50/topic/com.vmware.vmtools.install.doc/GUID-685722FA-9009-439C-9142-
18A9E7C592EA.html
Level 1
Description:
Rationale:
By default, the ability to copy and paste text, graphics, and files is disabled, as is the ability
to drag and drop files. When this feature is enabled, you can copy and paste rich text and,
depending on the VMware product, graphics and files from your clipboard to the guest
operating system in a virtual machine. That is, as soon as the console window of a virtual
machine gains focus, nonprivileged users and processes running in the virtual machine can
access the clipboard on the computer where the console window is running.
Audit:
Remediation:
Impact:
Default Value:
References:
1. http://pubs.vmware.com/vsphere-
51/topic/com.vmware.vmtools.install.doc/GUID-685722FA-9009-439C-9142-
18A9E7C592EA.html
8.5 Resources
8.5.1 Prevent virtual machines from taking over resources (Not Scored)
Profile Applicability:
Level 2
Description:
Use limits, shares, and reservations to prevent virtual machines from taking over
resources.
Rationale:
By default, all virtual machines on an ESXi host share the resources equally. By using the
resource management capabilities of ESXi, such as shares and limits, you can control the
server resources that a virtual machine consumes. You can use this mechanism to prevent a
denial of service that causes one virtual machine to consume so much of the host's
resources that other virtual machines on the same host cannot perform their intended
functions.
Audit:
Use shares or reservations to guarantee resources to critical VMs. Use limits to constrain
resource consumption by virtual machines that have a greater risk of being exploited or
attacked, or that run applications that are known to have the potential to greatly consume
resources.
Remediation:
References:
1. http://pubs.vmware.com/vsphere-50/topic/com.vmware.ICbase/PDF/vsphere-
esxi-vcenter-server-50-resource-management-guide.pdf
8.6 Storage
8.6.1 Avoid using nonpersistent disks (Scored)
Profile Applicability:
Level 1
Description:
Virtual Machine Disks are created as Dependent by default and are affected by snapshots.
To ensure a virtual machine disk is not affected by snapshots the disk mode can be set to
Independent.
Disks with Independent persistent mode have their data written permanently to the disk.
Independent Nonpersistent disks lose any changes made to the disk when the system is
rebooted and can mask any trace of an attack on the system.
Rationale:
The security issue with nonpersistent disk mode is that successful attackers, with a simple
shutdown or reboot, might undo or remove any traces that they were ever on the machine.
To safeguard against this risk production virtual machines should be configured as follows:
Without a persistent record of activity on a VM, administrators might never know whether
they have been attacked or hacked.
Audit:
If remote logging of events and activity is not configured for the guest, scsiX:Y.mode should
be either:
Remediation:
Impact:
Won't be able to make use of nonpersistent mode, which allows rollback to a known state
when rebooting the VM.
Default Value:
References:
1. https://pubs.vmware.com/vsphere-
51/topic/com.vmware.wssdk.apiref.doc/vim.vm.device.VirtualDiskOption.DiskMod
e.html
2. https://pubs.vmware.com/vsphere-
51/topic/com.vmware.vsphere.vm_admin.doc/GUID-81629CAB-72FA-42F0-9F86-
F8FD0DE39E57.html
Level 2
Description:
If Virtual disk shrinking is done repeatedly it will cause the virtual disk to become
unavailable resulting in a denial of service. You can prevent virtual disk shrinking by
disabling it.
Rationale:
Shrinking a virtual disk reclaims unused space in it. If there is empty space in the disk, this
process reduces the amount of space the virtual disk occupies on the host drive. Normal
users and processes—that is, users and processes without root or administrator
privileges—within virtual machines have the capability to invoke this procedure. However,
if this is done repeatedly, the virtual disk can become unavailable while this shrinking is
being performed, effectively causing a denial of service. In most datacenter environments,
disk shrinking is not done, so you should disable this feature. Repeated disk shrinking can
make a virtual disk unavailable. This capability is available to nonadministrative users in
the guest.
Audit:
Remediation:
Impact:
Inability to shrink virtual machine disks in the event that a datastore runs out of space.
Default Value:
References:
1. https://pubs.vmware.com/vsphere-
51/topic/com.vmware.vsphere.security.doc/GUID-C7D50832-CDBF-4E64-B5C0-
57DF4A94B892.html
8.7 Tools
8.7.1 Disable VMware Tools auto install (Scored)
Profile Applicability:
Level 1
Description:
When installing VMware tools, it can sometimes require a reboot to finalize the installation.
If you choose the auto install option it will reboot the system without notice if one is
required.
Rationale:
VMware Tools auto install can initiate an automatic reboot, disabling this option will
prevent tools from being installed automatically and prevent automatic machine reboots.
Audit:
Remediation:
Impact:
This option disables tools auto install via the hypervisor. It is recommended that VMware
tools installs and upgrades be handled through other means (For example: a devops tool
such as ansible, chef, puppet, or saltstack).
Default Value:
The prescribed state is not the default state.
References:
1. https://pubs.vmware.com/vsphere-
51/topic/com.vmware.vmtools.install.doc/GUID-65BCA561-5A03-4D17-A663-
46A0C50CE6A7.html
Level 1
Description:
If you do not make use of custom VIX programming in your environment then you should
disable this feature to reduce the potential for vulnerabilities.
Rationale:
The VIX API is a library for writing scripts and programs to manipulate virtual machines. If
you do not make use of custom VIX programming in your environment, then you should
disable certain features to reduce the potential for vulnerabilities. The ability to send
messages from the VM to the host is one of these features.
Note: Disabling this feature does NOT adversely affect the functioning of VIX operations
that originate outside the guest, so certain VMware and 3rd party solutions that rely upon
this capability should continue to work. This is a deprecated interface. Ensure that any
deprecated interface is turned off for audit purposes.
Audit:
Remediation:
Impact:
Default Value:
References:
1. https://pubs.vmware.com/vsphere-
51/topic/com.vmware.vddk.pg.doc/vddkTasks.8.7.html
Level 1
Description:
Configure VMware Tools to disable host info from being sent to guests.
Rationale:
If set to TRUE a VM can obtain detailed information about the physical host. The default
value for the parameter is FALSE. This setting should not be TRUE unless a particular VM
requires this information for performance monitoring. An adversary potentially can use
this information to inform further attacks on the host.
Audit:
Remediation:
To implement the recommended configuration state, run the following PowerCLI
command:
# Add the setting to all VMs
Get-VM | New-AdvancedSetting -Name "tools.guestlib.enableHostInfo" -value $false
Impact:
Unable to retrieve performance information about the host from inside the guest, there are
times when this can be useful for troubleshooting.
Default Value:
References:
1. https://pubs.vmware.com/vsphere-
51/topic/com.vmware.vsphere.security.doc/GUID-2CF880DA-2435-4201-9AFB-
A16A11951A2D.html
Level 1
Description:
Rationale:
You can use these settings to limit the total size and number of log files. Normally a new log
file is created only when a host is rebooted, so the file can grow to be quite large. You can
ensure that new log files are created more frequently by limiting the maximum size of the
log files. If you want to restrict the total size of logging data, VMware recommends saving
10 log files, each one limited to 1,000KB. Datastores are likely to be formatted with a block
size of 2MB or 4MB, so a size limit too far below this size would result in unnecessary
storage utilization. Each time an entry is written to the log, the size of the log is checked; if
it is over the limit, the next entry is written to a new log. If the maximum number of log files
already exists, when a new one is created, the oldest log file is deleted. A denial-of-service
attack that avoids these limits might be attempted by writing an enormous log entry. But
each log entry is limited to 4KB, so no log files are ever more than 4KB larger than the
configured limit. A second option is to disable logging for the virtual machine. Disabling
logging for a virtual machine makes troubleshooting challenging and support difficult. You
should not consider disabling logging unless the log file rotation approach proves
insufficient. Uncontrolled logging can lead to denial of service due to the datastore's being
filled.
Audit:
Check virtual machine configuration file and verify that log.keepOld is set to 10.
Remediation:
Impact:
A more extreme strategy is to disable logging altogether for the virtual machine. Disabling
logging makes troubleshooting challenging and support difficult. Do not consider disabling
logging unless the log file rotation approach proves insufficient.
Default Value:
References:
1. https://pubs.vmware.com/vsphere-
51/topic/com.vmware.vmtools.install.doc/GUID-685722FA-9009-439C-9142-
18A9E7C592EA.html
Level 1
Description:
Configure VM settings to prevent uncontrolled logging.
Rationale:
You can use these settings to limit the total size and number of log files. Normally a new log
file is created only when a host is rebooted, so the file can grow to be quite large. You can
ensure that new log files are created more frequently by limiting the maximum size of the
log files. If you want to restrict the total size of logging data, VMware recommends saving
10 log files, each one limited to 1,000KB. Datastores are likely to be formatted with a block
size of 2MB or 4MB, so a size limit too far below this size would result in unnecessary
storage utilization. Each time an entry is written to the log, the size of the log is checked; if
it is over the limit, the next entry is written to a new log. If the maximum number of log files
already exists, when a new one is created, the oldest log file is deleted. A denial-of-service
attack that avoids these limits might be attempted by writing an enormous log entry. But
each log entry is limited to 4KB, so no log files are ever more than 4KB larger than the
configured limit. A second option is to disable logging for the virtual machine. Disabling
logging for a virtual machine makes troubleshooting challenging and support difficult. You
should not consider disabling logging unless the log file rotation approach proves
insufficient. Uncontrolled logging can lead to denial of service due to the datastore's being
filled.
Audit:
Check virtual machine configuration file and verify that log.rotateSize is set to 100000.
Remediation:
Impact:
A more extreme strategy is to disable logging altogether for the virtual machine. Disabling
logging makes troubleshooting challenging and support difficult. Do not consider disabling
logging unless the log file rotation approach proves insufficient.
Default Value:
The prescribed state is not the default state.
References:
1. http://kb.vmware.com/kb/8182749
Appendix: Change History
Date Version Changes for this version