#
# This script is Copyright (C) 2004-2019 and is owned by Tenable, Inc. or an Affiliate thereof.
#
# This script is released under the Tenable Subscription License and
# may not be used from within scripts released under another license
# without authorization from Tenable, Inc.
#
# See the following licenses for details:
#
# http://static.tenable.com/prod_docs/Nessus_6_SLA_and_Subscription_Agreement.pdf
#
# @PROFESSIONALFEED@
# $Revision: 1.0 $
# $Date: 2019/08/21 $
#
# Description : This .audit is designed to query VMware 6.7
# as defined by CIS in the VMware ESXi 6.7 v1.0.0 benchmark
# https://workbench.cisecurity.org/files/2392
#
#
#CIS VMware ESXi 6.7 v1.0.0 Level 1
#
# CIS
# VMware ESXi 6.7 Level 1
# 1.0.0
# https://workbench.cisecurity.org/files/2392
#
#vmware,cis,esxi,esxi_6,esxi_6.7
#LEVEL,CSCv7
#
#
# NTP_SERVER
# 0\.us\.pool\.ntp\.org
# NTP server address
# The name or IP address of the NTP server for your organization.
#
#
# LOG_HOST
# 192\.168\.0\.1
# Remote syslog IP
# The IP address of the centralized syslog server for your organization.
#
#
# DCUI_ACCESS
# root
# DCUI Access Users
# List of trusted users that can override lockdown mode
#
#
# AGENT_ADDRESS
# 192\.168\.0\.1
# VMSafe agent addr
# 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.
#
#
# AGENT_PORT
# 10000
# Agent Port Num
# 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.
#
#
# LOG_DIR
# \\[\\] \/scratch\/log1
# System log dir
# The path to the system log directory.
#
#
# PASSWORD_POLICY
# retry=3 min=disabled,disabled,disabled,disabled,14
# Password Quality Control
# Value of the Security.PasswordQualityControl parameter
#
#
# AUDIT_EXCEPTION_USERS
# root
# Lockdown mode xception users
# List of users who are exceptions to lockdown mode rules
#
#
#
description : "1.1 Ensure ESXi is properly patched"
info : "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. VMware also publishes advisories on security patches and offers a
way to subscribe to email alerts for them.
Rationale:
By staying up to date on ESXi patches, vulnerabilities in the hypervisor can be mitigated. An
educated attacker can exploit known vulnerabilities when attempting to attain access or
elevate privileges on an ESXi host.
NOTE: Nessus has not performed this check. Please review the benchmark to ensure target compliance."
solution : "Employ a process to keep ESXi hosts up to date with patches in accordance with industry
standards and internal guidelines. Leverage the VMware Update Manager to test and apply
patches as they become available.
Impact:
ESXi servers must be in Maintenance Mode to apply patches. This implies all VMs must be
moved or powered off on the ESXi server, so the patching process may necessitate having
brief outages."
reference : "LEVEL|1S"
see_also : "https://workbench.cisecurity.org/files/2392"
type : AUDIT_ESX
description : "1.4 Ensure the default value of individual salt per vm is configured"
info : "The concept of salting has been introduced to help address concerns system administrators
may have over the security implications of TPS. As per the original TPS implementation,
multiple virtual machines could share pages when the contents of the pages were same.
With the new salting settings, the virtual machines can share pages only if the salt value
and contents of the pages are identical. A new host config option Mem.ShareForceSalting is
introduced to enable or disable salting.
By default, salting is enabled (Mem.ShareForceSalting=2) and each virtual machine has a
different salt. This means page sharing does not occur across the virtual machines (inter-
VM TPS) and only happens inside a virtual machine (intra VM).
Rationale:
Intra-VM means that TPS will de-duplicate identical pages of memory within a virtual
machine, but will not share the pages with any other virtual machines. Ensuring the default
setting is in place so that page sharing only occurs inside a virtual machine is the best
option here."
solution : "From vSphere Web Client:
1. Select a host
2. Click \"Configure\" -> \"Settings\" -> \"System\" -> \"Advanced System settings\"
3. Filter for Mem.ShareForceSalting.
4. Click edit
5. Set it to 2.
Additionally, the following PowerCLI command can be used:
Get-VMHost | Get-AdvancedSetting -Name Mem.ShareForceSalting | Set-AdvancedSetting -Value 2"
reference : "800-53|SI-16,LEVEL|1S"
see_also : "https://workbench.cisecurity.org/files/2392"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " - : "
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " - Mem.ShareForceSalting : NOT configured"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
regex : "Mem\.ShareForceSalting : "
expect : "Mem\.ShareForceSalting : 2$"
type : AUDIT_ESX
description : "2.1 Ensure NTP time synchronization is configured properly"
info : "Network Time Protocol (NTP) synchronization should be configured correctly and enabled
on each VMware ESXi host to ensure accurate time for system event logs. The time sources
used by the ESXi hosts should be in sync with an agreed-upon time standard such as
Coordinated Universal Time (UTC). There should be at minimum two NTP sources in place,
and they should sync whenever possible.
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, it is simpler to track and correlate an intruder's actions when reviewing the
relevant log files. Incorrect time settings can also make auditing inaccurate."
solution : "To enable and properly configure NTP synchronization, perform the following from the
vSphere web client:
1. Select the host.
2. Click \"Configure\" -> \"System\" -> \"Time Configuration\".
3. Click the \"Edit...\" button.
4. Click on \"Use Network Time Protocol\".
5. Provide the names or IP addresses of your NTP servers. Separate servers with commas.
6. If the NTP Service Status is \"Stopped\", click on \"Start\".
7. Change the startup policy to \"Start and stop with host\".
8. Click \"OK\".
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 or the Fully Qualified Domain Name (FQDN) of the internal NTP server
$NTPServers = \"pool.ntp.org\", \"pool2.ntp.org\"
Get-VMHost | Add-VmHostNtpServer $NTPServers"
reference : "800-171|3.3.7,800-53|AU-8,CSCv6|6.1,CSCv7|6.7,CSF|PR.PT-1,ISO/IEC-27001|A.12.4.4,ITSG-33|AU-8,LEVEL|1S,NESA|T3.6.7,NIAv2|NS44,NIAv2|NS45,NIAv2|NS46,NIAv2|NS47,PCI-DSSv3.1|10.4,PCI-DSSv3.2|10.4"
see_also : "https://workbench.cisecurity.org/files/2392"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " - NTP Server : "
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " - NTP Server : NOT found"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
regex : "NTP Server : "
# Note: Variable @NTP_SERVER@ replaced with "0\\.us\\.pool\\.ntp\\.org" in field "expect".
expect : "NTP Server : 0\\.us\\.pool\\.ntp\\.org$"
type : AUDIT_ESX
description : "2.3 Ensure Managed Object Browser (MOB) is disabled"
info : "The Managed Object Browser (MOB) is a web-based server application that lets you
examine objects that exist on the server side, explore the object model used by the VM
kernel to manage the host, and change configurations. It is installed and started
automatically when vCenter is installed.
Rationale:
The MOB 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.
NOTE: Nessus has not performed this check. Please review the benchmark to ensure target compliance."
solution : "To disable the MOB, run the following ESXi shell command:
vim-cmd proxysvc/remove_service \"/mob\" \"httpsWithRedirect\"
Additionally, the following PowerCLI command may be used:
Get-VMHost | Get-AdvancedSetting -Name Config.HostAgent.plugins.solo.enableMob |Set-AdvancedSetting -value \"false\"
Note: You cannot disable the MOB while a host is in lockdown mode."
reference : "800-171|3.4.6,800-171|3.4.7,800-53|CM-7,CSCv7|9.2,CSF|PR.IP-1,CSF|PR.PT-3,ITSG-33|CM-7,LEVEL|1S,NIAv2|SS15a,SWIFT-CSCv1|2.3"
see_also : "https://workbench.cisecurity.org/files/2392"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " - : "
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " - Config.HostAgent.plugins.solo.enableMob : NOT configured"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
regex : "Config.HostAgent.plugins.solo.enableMob : "
expect : "Config.HostAgent.plugins.solo.enableMob : false"
type : AUDIT_VCENTER
description : "Ensure proper SNMP configuration"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " - : "
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
regex : "snmp\.receiver\.([Xx]|[0-9]+)\.enabled : "
expect : "snmp\.receiver\.([Xx]|[0-9]+)\.enabled : TRUE$"
type : AUDIT_VCENTER
description : "2.5 Ensure SNMP is configured properly - 'community name public does not exist'"
info : "Simple Network Management Protocol (SNMP) can be used to help manage hosts. Many
organizations have other means in place of managing hosts and do not need SNMP enabled.
If SNMP is needed, it should be configured properly to reduce the risk of misuse or
compromise. For example, ESXi supports SNMPv3, which provides stronger security than
SNMPv1 or SNMPv2, including key authentication and encryption. It is also important to
configure the destination for SNMP traps.
Rationale:
If SNMP is not properly configured, monitoring data containing sensitive information can
be sent to a malicious host and used to help exploit the host."
solution : "To correct the SNMP configuration, perform the following from the ESXi Shell or vCLI:
1. If SNMP is not needed, disable it by running:
esxcli system snmp set --enable false
2. If SNMP is needed, refer to the vSphere Monitoring and Performance guide, chapter 8 for steps to configure it.
Additionally, the following PowerCLI command may be used to implement the configuration:
# Update the host SNMP Configuration (single host connection required)
Get-VmHostSNMP | Set-VMHostSNMP -Enabled:$true -ReadOnlyCommunity ''
Notes:
. SNMP must be configured on each ESXi host
. SNMP settings can be configured using Host Profiles"
reference : "800-171|3.5.2,800-53|IA-5,CN-L3|7.1.2.7(d),CSCv7|9.2,CSF|PR.AC-1,ISO/IEC-27001|A.9.4.3,ITSG-33|IA-5,LEVEL|1NS,NESA|T5.2.1,NESA|T5.2.3,NESA|T5.5.2,NESA|T5.5.3"
see_also : "https://workbench.cisecurity.org/files/2392"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " - : "
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
regex : "snmp\.receiver\.[0-9]+\.community : "
not_expect : "snmp\.receiver\.[0-9]+\.community : [Pp][Uu][Bb][Ll][Ii][Cc]"
type : AUDIT_VCENTER
description : "2.5 Ensure SNMP is configured properly - 'community name private does not exist'"
info : "Simple Network Management Protocol (SNMP) can be used to help manage hosts. Many
organizations have other means in place of managing hosts and do not need SNMP enabled.
If SNMP is needed, it should be configured properly to reduce the risk of misuse or
compromise. For example, ESXi supports SNMPv3, which provides stronger security than
SNMPv1 or SNMPv2, including key authentication and encryption. It is also important to
configure the destination for SNMP traps.
Rationale:
If SNMP is not properly configured, monitoring data containing sensitive information can
be sent to a malicious host and used to help exploit the host."
solution : "To correct the SNMP configuration, perform the following from the ESXi Shell or vCLI:
1. If SNMP is not needed, disable it by running:
esxcli system snmp set --enable false
2. If SNMP is needed, refer to the vSphere Monitoring and Performance guide, chapter 8 for steps to configure it.
Additionally, the following PowerCLI command may be used to implement the configuration:
# Update the host SNMP Configuration (single host connection required)
Get-VmHostSNMP | Set-VMHostSNMP -Enabled:$true -ReadOnlyCommunity ''
Notes:
. SNMP must be configured on each ESXi host
. SNMP settings can be configured using Host Profiles"
reference : "800-171|3.5.2,800-53|IA-5,CN-L3|7.1.2.7(d),CSCv7|9.2,CSF|PR.AC-1,ISO/IEC-27001|A.9.4.3,ITSG-33|IA-5,LEVEL|1NS,NESA|T5.2.1,NESA|T5.2.3,NESA|T5.5.2,NESA|T5.5.3"
see_also : "https://workbench.cisecurity.org/files/2392"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " - : "
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
regex : "snmp\.receiver\.[0-9]+\.community : "
not_expect : "snmp\.receiver\.[0-9]+\.community : [Pp][Rr][Ii][Vv][Aa][Tt][Ee]"
description : "2.5 Ensure SNMP is configured properly - 'community name public does not exist'"
info : "Simple Network Management Protocol (SNMP) can be used to help manage hosts. Many
organizations have other means in place of managing hosts and do not need SNMP enabled.
If SNMP is needed, it should be configured properly to reduce the risk of misuse or
compromise. For example, ESXi supports SNMPv3, which provides stronger security than
SNMPv1 or SNMPv2, including key authentication and encryption. It is also important to
configure the destination for SNMP traps.
Rationale:
If SNMP is not properly configured, monitoring data containing sensitive information can be sent to a malicious host and used to help exploit the host."
solution : "To correct the SNMP configuration, perform the following from the ESXi Shell or vCLI:
1. If SNMP is not needed, disable it by running:
esxcli system snmp set --enable false
2. If SNMP is needed, refer to the vSphere Monitoring and Performance guide, chapter 8 for steps to configure it.
Additionally, the following PowerCLI command may be used to implement the configuration:
# Update the host SNMP Configuration (single host connection required)
Get-VmHostSNMP | Set-VMHostSNMP -Enabled:$true -ReadOnlyCommunity ''
Notes:
. SNMP must be configured on each ESXi host
. SNMP settings can be configured using Host Profiles"
reference : "800-171|3.5.2,800-53|IA-5,CN-L3|7.1.2.7(d),CSCv7|9.2,CSF|PR.AC-1,ISO/IEC-27001|A.9.4.3,ITSG-33|IA-5,LEVEL|1NS,NESA|T5.2.1,NESA|T5.2.3,NESA|T5.5.2,NESA|T5.5.3"
description : "2.5 Ensure SNMP is configured properly - 'community name private does not exist'"
info : "Simple Network Management Protocol (SNMP) can be used to help manage hosts. Many
organizations have other means in place of managing hosts and do not need SNMP enabled.
If SNMP is needed, it should be configured properly to reduce the risk of misuse or
compromise. For example, ESXi supports SNMPv3, which provides stronger security than
SNMPv1 or SNMPv2, including key authentication and encryption. It is also important to
configure the destination for SNMP traps.
Rationale:
If SNMP is not properly configured, monitoring data containing sensitive information can be sent to a malicious host and used to help exploit the host."
solution : "To correct the SNMP configuration, perform the following from the ESXi Shell or vCLI:
1. If SNMP is not needed, disable it by running:
esxcli system snmp set --enable false
2. If SNMP is needed, refer to the vSphere Monitoring and Performance guide, chapter 8 for steps to configure it.
Additionally, the following PowerCLI command may be used to implement the configuration:
# Update the host SNMP Configuration (single host connection required)
Get-VmHostSNMP | Set-VMHostSNMP -Enabled:$true -ReadOnlyCommunity ''
Notes:
. SNMP must be configured on each ESXi host
. SNMP settings can be configured using Host Profiles"
reference : "800-171|3.5.2,800-53|IA-5,CN-L3|7.1.2.7(d),CSCv7|9.2,CSF|PR.AC-1,ISO/IEC-27001|A.9.4.3,ITSG-33|IA-5,LEVEL|1NS,NESA|T5.2.1,NESA|T5.2.3,NESA|T5.5.2,NESA|T5.5.3"
type : AUDIT_ESX
description : "2.6 Ensure dvfilter API is not configured if not used"
info : "The dvfilter network API is used by some products (e.g., VMSafe). If it is not in use, it should
not be configured to send network information to a VM.
Rationale:
If the dvfilter network API is enabled in the future and it is already configured, an attacker
might attempt to connect a VM to it, thereby potentially providing access to the network of
other VMs on the host."
solution : "To remove the configuration for the dvfilter network API, perform the following from the vSphere web client:
1. Select the host and click \"Configure\" -> \"System\" -> \"Advanced System Settings\".
2. Enter Net.DVFilterBindIpAddress in the filter.
3. Set Net.DVFilterBindIpAddress to an empty value.
4. If an appliance is being used, make sure the value of this parameter is set to the proper IP address.
5. Make sure the attribute is highlighted, then click the pencil icon.
6. Enter the proper IP address.
7. Click \"OK\".
To implement the recommended configuration state, run the following PowerCLI command:
# Set Net.DVFilterBindIpAddress to null on all hosts
Get-VMHost HOST1 | Foreach { Set-AdvancedSetting -VMHost $_ -Name Net.DVFilterBindIpAddress -IPValue \"\" }
Impact:
This will prevent a dvfilter-based network security appliance such as a firewall from
functioning if not configured correctly.
Default Value:
Not configured"
reference : "800-171|3.1.1,800-53|AC-3,CSCv7|9.2,CSF|PR.AC-4,CSF|PR.PT-3,ISO/IEC-27001|A.9.4.1,ITSG-33|AC-3,LEVEL|1S,NESA|T4.2.1,NESA|T5.4.4,NESA|T5.4.5,NESA|T5.5.4,NESA|T5.6.1,NESA|T7.5.2,NESA|T7.5.3,NIAv2|AM3,NIAv2|SS29"
see_also : "https://workbench.cisecurity.org/files/2392"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " - : "
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " - Net.DVFilterBindIpAddress : NOT configured"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
regex : "Net\.DVFilterBindIpAddress : "
expect : "Net\.DVFilterBindIpAddress : NOT configured"
description : "2.8 Ensure vSphere Authentication Proxy is used when adding hosts to Active Directory"
info : "vSphere Authentication Proxy enables ESXi hosts to join a domain without using Active
Directory credentials. vSphere Authentication Proxy enhances security for PXE-booted
hosts and hosts that are provisioned using Auto Deploy and Host profiles, by removing the
need to store Active Directory credentials in the host configuration.
The vSphere Authentication Proxy service binds to an IPv4 address for communication
with vCenter Server, and does not support IPv6. The vCenter Server can be on a host
machine in an IPv4-only, IPv4/IPv6 mixed-mode, or IPv6-only network environment, but
the machine that connects to the vCenter Server through the vSphere Client must have an
IPv4 address for the vSphere Authentication Proxy service to work.
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.
NOTE: Nessus has not performed this check. Please review the benchmark to ensure target compliance."
solution : "To properly set the vSphere Authentication Proxy from Web Client directly:
1. Select the host
2. Click on \"Configure\" -> \"Settings\" -> \"Authentication Services\"
3. Click on \"Join Domain\"
4. Select \"Using Proxy Server\" radio button.
5. Provide proxy server IP address.
To properly set the vSphere Authentication Proxy via Host Profiles:
1. Install and configure the Authentication proxy
2. From the vSphere web client, navigate to \"Host Profiles\"
3. Select the host profile
4. Select \"Configure\" -> \"Edit Host profile\"
5. Expand \"Security and Services\" -> \"Security Settings\" -> \"Authentication Configuration\"
6. Select \"Active Directory configuration\"
7. Set the \"Join Domain Method\" to \"Use vSphere Authentication Proxy to add the host do domain\"
8. Provide the IP address of the authentication proxy"
reference : "LEVEL|1S"
see_also : "https://workbench.cisecurity.org/files/2392"
description : "2.9 Ensure VDS health check is disabled"
info : "The health check support in VDS helps you identify and troubleshoot configuration errors
in a vSphere Distributed Switch. It is recommended that health check be turned off by
default and confirmed that it is turned off when troubleshooting is finished.
Rationale:
vSphere Distributed switch health check once enabled, collects packets that contain
information on host#, vds# port#, which an attacker would find useful.
NOTE: Nessus has not performed this check. Please review the benchmark to ensure target compliance."
solution : "Using the vSphere Web Client for each VDS:
1. Select a VDS
2. Go to \"Configure\" -> \"Settings\" -> Health check\".
3. Click \"Edit\"
4. Set \"VLAN and MTU Check\" to \"Disabled\".
5. Set \"Teaming and Failover Check\" to \"Disabled\".
Additionally, the following PowerCLI command can be used:
Get-View -ViewType DistributedVirtualSwitch | ?{($_.config.HealthCheckConfig | ?{$_.enable -notmatch \"False\"})}| %{$_.UpdateDVSHealthCheckConfig(@((New-Object Vmware.Vim.VMwareDVSVlanMtuHealthCheckConfig -property @{enable=0}),(New-Object Vmware.Vim.VMwareDVSTeamingHealthCheckConfig -property @{enable=0})))}"
reference : "LEVEL|1S"
see_also : "https://workbench.cisecurity.org/files/2392"
type : AUDIT_ESX
description : "3.2 Ensure persistent logging is configured for all ESXi hosts"
info : "ESXi can be configured to store log files on an in-memory file system. This occurs when the
host's Syslog.global.LogDir property is set to a non-persistent location, such as
/scratch. When this is done, only a single day's worth of logs are stored at any time.
Additionally, log files will be reinitialized upon each reboot.
Rationale:
Non-persistent logging presents a security risk because 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."
solution : "To configure persistent logging properly, perform the following from the vSphere web client:
1. Select the host and go to \"Configure\" -> \"System\" -> \"Advanced System Settings\".
2. Enter Syslog.global.LogDir in the filter.
3. Set the Syslog.global.LogDir to a persistent location specified as [datastorename] path_to_file where the path is relative to the datastore. For example, [datastore1] /systemlogs.
4. Make sure the attribute is highlighted, then click the pencil icon.
Alternatively, run the following PowerCLI command:
# Set Syslog.global.logDir for each host
Get-VMHost | Foreach { Set-AdvancedConfiguration -VMHost $_ -Name Syslog.global.logDir -Value \"\" }"
reference : "800-171|3.3.1,800-171|3.3.2,800-53|AU-12,CSCv7|6.2,CSCv7|6.3,CSF|DE.CM-1,CSF|DE.CM-3,CSF|DE.CM-7,CSF|PR.PT-1,ITSG-33|AU-12,LEVEL|1S,SWIFT-CSCv1|6.4"
see_also : "https://workbench.cisecurity.org/files/2392"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " - : "
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " - Syslog.global.logDir : NOT found"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
regex : "Syslog\.global\.logDir : "
# Note: Variable @LOG_DIR@ replaced with "\\\\[\\\\] \\/scratch\\/log1" in field "expect".
expect : "Syslog\.global\.logDir : \\\\[\\\\] \\/scratch\\/log1$"
type : AUDIT_ESX
description : "3.3 Ensure remote logging is configured for ESXi hosts"
info : "By default, ESXI logs are stored on a local scratch volume or ramdisk. To preserve logs, also
configure remote logging to a central log host for the ESXI hosts.
Rationale:
Remote logging to a central log host provides a secure, centralized store for ESXi logs. 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 helps prevent log tampering and provides a long-term audit
record."
solution : "To configure remote logging properly, perform the following from the vSphere web client:
1. Select the host and click \"Configure\" -> \"System\" -> \"Advanced System Settings\".
2. Enter Syslog.global.logHost in the filter.
3. Make sure Syslog.global.logHost is highlighted, then click the pencil icon.
4. Set Syslog.global.logHost to the hostname or IP address of the central log server.
5. Click \"OK\".
Alternately, run the following PowerCLI command:
# Set Syslog.global.logHost for each host
Get-VMHost | Foreach { Set-AdvancedSetting-VMHost $_ -Name Syslog.global.logHost -Value \"\" }
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."
reference : "800-171|3.3.8,800-53|AU-9,CSCv7|6.2,CSCv7|6.3,CSF|PR.PT-1,ITSG-33|AU-9,LEVEL|1S,NESA|M5.2.3,NESA|M5.5.2,NIAv2|SS13e"
see_also : "https://workbench.cisecurity.org/files/2392"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " - : "
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " - Syslog.global.logHost : NOT configured"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
regex : "Syslog\.global\.logHost : "
# Note: Variable @LOG_HOST@ replaced with "192\\.168\\.0\\.1" in field "expect".
expect : "Syslog\.global\.logHost : 192\\.168\\.0\\.1$"
type : AUDIT_ESX
description : "4.2 Ensure passwords are required to be complex"
info : "ESXi uses the pam_passwdqc.so plug-in to set password strength and complexity. Options
include setting minimum password length, requiring password characters to come from
particular character sets, and restricting the number of consecutive failed logon attempts
permitted. The settings should enforce the organization's password policies.
Note that an uppercase character that begins a password does not count toward the
number of character classes used, and neither does a number that ends a password.
Rationale:
All passwords for ESXi hosts should be hard to guess to reduce the risk of unauthorized
access.
Note: ESXi imposes no restrictions on the root password. Password strength and
complexity rules only apply to non-root users.
NOTE: Nessus has not performed this check. Please review the benchmark to ensure target compliance."
solution : "To set the password complexity requirements, perform the following:
1. Login to the ESXi shell as a user with administrator privileges.
2. Open /etc./pam.d/passwd.
3. Locate the following line:
password requisite /lib/security/$ISA/pam_passwdqc.so retry=N min=N0,N1,N2,N3,N4
4. Set N to less than or equal to 3.
5. Set N0 to disabled.
6. Set N1 to disabled.
7. Set N2 to disabled.
8. Set N3 to disabled.
9. Set N4 to 8 or greater.
The above requires all passwords to be 8 or more characters long and comprised of at
least one character from four distinct character sets. Additionally, a maximum of 3
consecutive failed login attempts are permitted."
reference : "800-53|IA-5,CSCv7|4.4,CSF|PR.AC-1,ITSG-33|IA-5,LEVEL|1S,NESA|T5.2.3,SWIFT-CSCv1|4.1"
see_also : "https://workbench.cisecurity.org/files/2392"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " - : "
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " - Security.PasswordQualityControl : NOT found"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
regex : "Security\.PasswordQualityControl : "
# Note: Variable @PASSWORD_POLICY@ replaced with "retry=3 min=disabled,disabled,disabled,disabled,14" in field "expect".
expect : "Security\.PasswordQualityControl : retry=3 min=disabled,disabled,disabled,disabled,14"
type : AUDIT_ESX
description : "4.3 Ensure Active Directory is used for local user authentication - Enabled = 'true'"
info : "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.
Note: If the AD group \"ESX Admins\" (default) is created, all users and groups that are members of this group will have full administrative access to all ESXi hosts in the domain.
Rationale:
Joining ESXi hosts to an Active Directory (AD) domain eliminates 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."
solution : "To use AD for local user authentication, perform the following from the vSphere Web Client:
1. Select the host and go to \"Manage\" -> \"Security & Users\" -> \"Authentication\".
2. Click the \"Join Domain\" button.
3. Provide the domain name along with the user credentials for an AD user that has the rights to join computers to the domain.
4. Click \"OK\".
Alternately, run the following PowerCLI command:
# Join the ESXI Host to the Domain
Get-VMHost HOST1 | Get-VMHostAuthentication | Set-VMHostAuthentication -Domain domain.local -User Administrator -Password Passw0rd -JoinDomain
Notes:
1. Host Profiles can be used to automate adding hosts to an AD domain.
2. Consider using the vSphere Authentication proxy to avoid transmitting AD credentials over the network."
reference : "800-171|3.5.1,800-53|IA-2,CN-L3|7.1.3.1(a),CN-L3|7.1.3.1(e),CSCv7|16.2,CSF|PR.AC-1,ITSG-33|IA-2,LEVEL|1S,NESA|T2.3.8,NESA|T5.3.1,NESA|T5.4.2,NESA|T5.5.1,NESA|T5.5.2,NESA|T5.5.3,NIAv2|AM14b,NIAv2|AM2,NIAv2|AM8"
see_also : "https://workbench.cisecurity.org/files/2392"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : "\nEnabled : "
xsl_stmt : ""
xsl_stmt : ""
regex : "Enabled"
expect : "Enabled : true"
type : AUDIT_ESX
description : "4.3 Ensure Active Directory is used for local user authentication - Review Domain"
info : "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.
Note: If the AD group \"ESX Admins\" (default) is created, all users and groups that are members of this group will have full administrative access to all ESXi hosts in the domain.
Rationale:
Joining ESXi hosts to an Active Directory (AD) domain eliminates the need to create and
maintain multiple local user accounts. Using AD for user authentication simplifies the ESXi
host configuration, ensures password complexity and reuse policies are enforced, and
reduces the risk of security breaches and unauthorized access.
NOTE: Nessus has provided the target output to assist in reviewing the benchmark to ensure target compliance."
solution : "To use AD for local user authentication, perform the following from the vSphere Web Client:
1. Select the host and go to \"Manage\" -> \"Security & Users\" -> \"Authentication\".
2. Click the \"Join Domain\" button.
3. Provide the domain name along with the user credentials for an AD user that has the rights to join computers to the domain.
4. Click \"OK\".
Alternately, run the following PowerCLI command:
# Join the ESXI Host to the Domain
Get-VMHost HOST1 | Get-VMHostAuthentication | Set-VMHostAuthentication -Domain domain.local -User Administrator -Password Passw0rd -JoinDomain
Notes:
1. Host Profiles can be used to automate adding hosts to an AD domain.
2. Consider using the vSphere Authentication proxy to avoid transmitting AD credentials over the network."
reference : "CSCv7|16.2,LEVEL|1S"
see_also : "https://workbench.cisecurity.org/files/2392"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : "\nDomain : "
xsl_stmt : ""
xsl_stmt : ""
severity : MEDIUM
type : AUDIT_ESX
description : "4.4 Ensure only authorized users and groups belong to the esxAdminsGroup group"
info : "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 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 or group having membership in the esxAdminsGroup group will have
full administrative access to all ESXi hosts. Such users may compromise the confidentiality,
availability, and integrity of the all ESXi hosts and the respective data and processes they
influence."
solution : "To remove unauthorized users and groups belonging to esxAdminsGroup, perform the following steps after coordination between vSphere admins and Active Directory admins:
1. Verify the setting of the esxAdminsGroup attribute.
2. View the list of members for that Microsoft Active Directory group.
3. Remove all unauthorized users and groups from that 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\".
Default Value:
\"ESX Admins\""
reference : "800-171|3.1.5,800-53|AC-6,CN-L3|7.1.3.2(b),CN-L3|7.1.3.2(g),CSCv7|4.1,CSF|PR.AC-4,CSF|PR.DS-5,ITSG-33|AC-6,LEVEL|1NS,NESA|T5.1.1,NESA|T5.2.2,NESA|T5.4.1,NESA|T5.4.4,NESA|T5.4.5,NESA|T5.5.4,NESA|T5.6.1,NESA|T7.5.3,NIAv2|AM1,NIAv2|AM23f,NIAv2|SS13c,NIAv2|SS15c,SWIFT-CSCv1|5.1"
see_also : "https://workbench.cisecurity.org/files/2392"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " - : "
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " - Config.HostAgent.plugins.hostsvc.esxAdminsGroup : NOT configured"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
regex : "Config\.HostAgent\.plugins\.hostsvc\.esxAdminsGroup : "
not_expect : "ESX Admins$"
type : AUDIT_ESX
description : "4.5 Ensure the Exception Users list is properly configured"
info : "Users who are added to the \"Exception Users\" list do not lose their permissions when the
host enters lockdown mode. Usually you may want to add some service accounts, such as a
backup agent, to the Exception Users list.
Rationale:
Users who do not require special permissions should not be exempted from lockdown
mode because this increases the risk of unauthorized actions being performed, especially if
a user account is compromised.
NOTE: Nessus has not performed this check. Please review the benchmark to ensure target compliance."
solution : "To correct the membership of the \"Exception Users\" list, perform the following:
1. From the vSphere web client, select host.
2. Click on \"Configure\" -> \"Settings\" -> \"System\" -> \"Security Profile\".
3. Scroll down to \"Lockdown Mode\".
4. Click \"Edit\", then click on \"Exception Users\".
5. Add or delete users as per your organization's requirements."
reference : "800-171|3.1.5,800-53|AC-6,CSCv7|16,CSF|PR.AC-4,ISO/IEC-27001|A.9.2.3,ITSG-33|AC-6,LEVEL|1S,NESA|T5.1.1,NESA|T5.2.2,NESA|T5.6.1,NIAv2|AM32,NIAv2|AM33,NIAv2|VL3a,SWIFT-CSCv1|1.2"
see_also : "https://workbench.cisecurity.org/files/2392"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " - : "
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " - DCUI.Access : NOT found"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
regex : "DCUI\.Access : "
# Note: Variable @AUDIT_EXCEPTION_USERS@ replaced with "root" in field "expect".
expect : "DCUI\.Access : root$"
type : AUDIT_ESX
description : "4.6 Ensure the maximum failed login attempts is set to 3"
info : "Authentication should be configured so there is a maximum number of consecutive failed
login attempts for each account, at which point the account at risk will be locked out.
Rationale:
Multiple account login failures for the same account could possibly be an attacker trying to brute force guess the password."
solution : "To set the maximum failed login attempts correctly, perform the following steps:
1. From the vSphere Web Client, select the host.
2. Click \"Configure\" -> \"Settings\" -> \"System\" -> \"Advanced System Settings\".
3. Enter \"Security.AccountLockFailures\" in the filter.
4. Click \"Edit\".
5. Set the value for this parameter to 3.
Alternately, use the following PowerCLI command:
Get-VMHost | Get-AdvancedSetting -Name Security.AccountLockFailures | Set-AdvancedSetting -Value 3"
reference : "800-171|3.1.8,800-53|AC-7,CSCv7|16,ITSG-33|AC-7,LEVEL|1S,NESA|T5.5.1,NIAv2|AM24,TBA-FIISB|45.1.2,TBA-FIISB|45.2.1,TBA-FIISB|45.2.2"
see_also : "https://workbench.cisecurity.org/files/2392"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " - : "
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " - Security.AccountLockFailures : NOT configured"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
regex : "Security\.AccountLockFailures : "
expect : "Security\.AccountLockFailures : \b[1-3]\b"
type : AUDIT_ESX
description : "4.7 Ensure account lockout is set to 15 minutes"
info : "An account is automatically locked after the maximum number of failed consecutive login
attempts is reached. The account should be automatically unlocked after 15 minutes,
otherwise administrators will need to manually unlock accounts on request by authorized
users.
Rationale:
This setting reduces the inconvenience for benign users and the overhead on
administrators, while also severely slowing down any brute force password guessing
attacks."
solution : "To set the account lockout to 15 minutes, perform the following:
1. From the vSphere Web Client, select the host.
2. Click \"Configure\" -> \"Settings\" -> \"System\" -> \"Advanced System Settings\".
3. Enter \"Security.AccountUnlockTime\" in the filter.
4. Click \"Edit\".
5. Set the value for this parameter to 900.
Alternately, use the following PowerCLI command:
Get-VMHost | Get-AdvancedSetting -Name Security.AccountUnlockTime | Set-AdvancedSetting -Value 900"
reference : "800-171|3.1.8,800-53|AC-7,CSCv7|16,ITSG-33|AC-7,LEVEL|1S,NESA|T5.5.1,NIAv2|AM24,TBA-FIISB|45.1.2,TBA-FIISB|45.2.1,TBA-FIISB|45.2.2"
see_also : "https://workbench.cisecurity.org/files/2392"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " - : "
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " - Security.AccountUnlockTime : NOT configured"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
regex : "Security.AccountUnlockTime : "
expect : "Security.AccountUnlockTime : \b([0-9]|[1-8][0-9]|9[0-9]|[1-8][0-9]{2}|900)\b"
type : AUDIT_ESX
description : "5.1 Ensure the DCUI timeout is set to 1800 seconds or less"
info : "The Direct Console User Interface (DCUI) is used for directly logging into an ESXi host and
carrying out host management tasks. This setting terminates an idle DCUI session after the
specified number of seconds has elapsed.
Rationale:
Terminating idle DCUI sessions helps avoid unauthorized usage of the DCUI originating from leftover login sessions."
solution : "To correct the DCUI timeout setting, perform the following steps:
1. From the vSphere Web Client, select the host.
2. Click \"Configure\" -> \"Settings\" -> \"System\" -> \"Advanced System Settings\".
3. Enter \"UserVars.DcuiTimeOut\" in the filter.
4. Click \"Edit\".
5. Set the value for this parameter to 1800 seconds or less.
Alternately, use the following PowerCLI command:
Get-VMHost | Get-AdvancedSetting -Name UserVars.DcuiTimeOut | Set-AdvancedSetting -Value 1800"
reference : "800-171|3.1.11,800-53|AC-12,CN-L3|7.1.2.2(d),CN-L3|7.1.3.7(b),CSCv7|16.11,ITSG-33|AC-12,LEVEL|1S,NIAv2|NS49"
see_also : "https://workbench.cisecurity.org/files/2392"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " - : "
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " - UserVars.DcuiTimeOut : NOT configured"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
regex : "UserVars\.DcuiTimeOut : "
expect : "UserVars\.DcuiTimeOut : \b(([1-9]$)|([1-9][0-9]$)|([1-9][0-9][0-9]$)|([1][0-7][0-9][0-9]$)|(1800$))\b"
type : AUDIT_ESX
description : "5.3 Ensure the ESXi shell is disabled"
info : "The ESXi shell is an interactive command line environment available from the Direct
Console User Interface (DCUI) or remotely via SSH. The ESXi shell should only be enabled
on a host when running diagnostics or troubleshooting.
Rationale:
Activities performed from the ESXi shell bypass vCenter RBAC and audit controls, so the
ESXi shell should only be enabled when needed to troubleshoot/resolve problems that
cannot be fixed through the vSphere web client or vCLI/PowerCLI."
solution : "To disable the ESXi shell, perform the following:
1. From the vSphere web client, select the host.
2. Select \"Configure\" -> \"System\" -> \"Security Profile\".
3. Scroll down to \"Services\".
4. Click \"Edit...\".
5. Select \"ESXi Shell\".
6. Click \"Stop\".
7. Change the Startup Policy to \"Start and Stop Manually\".
8. Click \"OK\".
Alternately, use the following PowerCLI command:
# Set the ESXi shell to start manually rather than automatically for all hosts
Get-VMHost | Get-VMHostService | Where { $_.key -eq \"TSM\" } | Set-VMHostService -Policy Off"
reference : "800-171|3.4.6,800-171|3.4.7,800-53|CM-7,CSCv7|9.2,CSF|PR.IP-1,CSF|PR.PT-3,ITSG-33|CM-7,LEVEL|1S,NIAv2|SS15a,SWIFT-CSCv1|2.3"
see_also : "https://workbench.cisecurity.org/files/2392"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " - : running = "
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " - ESXi Shell : running = NOT configured"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
regex : "ESXi Shell : running ="
expect : "ESXi Shell : running = FALSE$"
type : AUDIT_ESX
description : "5.4 Ensure SSH is disabled"
info : "The ESXi shell, when enabled, can be accessed directly from the host console through the
DCUI or remotely using SSH. Disable Secure Shell (SSH) for each ESXi host to prevent
remote access to the ESXi shell, and only enable SSH when needed for troubleshooting or
diagnostics.
Rationale:
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."
solution : "To disable SSH, perform the following:
1. From the vSphere web client, select the host.
2. Select \"Configure\" -> \"System\" -> \"Security Profile\".
3. Scroll down to \"Services\".
4. Click \"Edit...\".
5. Select \"SSH\".
6. Click \"Stop\".
7. Change the Startup Policy to \"to Start and Stop Manually\".
8. Click \"OK\".
Alternately, use the following PowerCLI command:
# Set SSH to start manually rather than automatically for all hosts
Get-VMHost | Get-VMHostService | Where { $_.key -eq \"TSM-SSH\" } | Set-VMHostService -Policy Off"
reference : "800-171|3.4.6,800-171|3.4.7,800-53|CM-7,CN-L3|7.1.3.5(c),CN-L3|7.1.3.7(d),CSCv7|9.2,CSF|PR.IP-1,CSF|PR.PT-3,ITSG-33|CM-7,LEVEL|1S,NIAv2|SS13b,NIAv2|SS14a,NIAv2|SS14c,NIAv2|SS15a,SWIFT-CSCv1|2.3"
see_also : "https://workbench.cisecurity.org/files/2392"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " - : running = "
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " - SSH : running = NOT found"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
regex : "SSH : running = "
expect : "SSH : running = FALSE$"
description : "5.5 Ensure CIM access is limited"
info : "The Common Information Model (CIM) system provides an interface that enables
hardware-level management from remote applications using a set of standard APIs.
Provide only the minimum access necessary to applications. Do not provision CIM-based
hardware monitoring tools and other third-party applications to run as root or as another
administrator account. Instead, create a dedicated service account specific to each CIM
application with the minimal access and privileges needed for that application.
Rationale:
If CIM-based hardware monitoring tools or other third-party applications are granted
unneeded administrator level access, they could potentially be used to compromise the
security of the host.
NOTE: Nessus has not performed this check. Please review the benchmark to ensure target compliance."
solution : "To limit CIM access, perform the following:
1. Create a limited-privileged service account for CIM and other third-party
applications.
2. This account should access the system via vCenter.
3. Give the account the \"CIM Interaction\" privilege only. This will enable the account to
obtain a CIM ticket, which can then be used to perform both read and write CIM
operations on the target host. If an account must connect to the host directly, this
account must be granted the full \"Administrator\" role on the host. This is not
recommended unless required by the monitoring software being used.
Alternately, run the following PowerCLI command:
# Create a new host user account -Host Local connection required-
New-VMHostAccount -ID ServiceUser -Password -UserAccount"
reference : "CSCv7|4.3,LEVEL|1NS"
see_also : "https://workbench.cisecurity.org/files/2392"
type : AUDIT_ESX
description : "5.6 Ensure Lockdown mode is enabled"
info : "Enabling lockdown mode disables direct local access to an ESXi host, requiring the host be
managed remotely from vCenter Server.
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 who log in using authorized keys. Also, users
in the DCUI.Access list for each host are allowed to override lockdown mode and log in to
the DCUI. By default, the \"root\" user is the only user listed in the DCUI.Access list.
Rationale:
Lockdown mode limits ESXi host access to the vCenter server 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."
solution : "To enable lockdown mode, perform the following from the vSphere web client:
1. Select the host.
2. Select \"Configure\" -> \"System\" -> \"Security Profile\".
3. Scroll down to \"Lockdown Mode\".
4. Click \"Edit...\".
5. Select the \"Enable Lockdown Mode\" checkbox.
6. Click \"OK\".
Alternately, run the following PowerCLI command:
# Enable lockdown mode for each host
Get-VMHost | Foreach { $_.EnterLockdownMode() }"
reference : "800-171|3.1.5,800-53|AC-6,CSF|PR.AC-4,ISO/IEC-27001|A.9.2.3,ITSG-33|AC-6,LEVEL|1S,NESA|T5.1.1,NESA|T5.2.2,NESA|T5.6.1,NIAv2|AM32,NIAv2|AM33,NIAv2|VL3a,SWIFT-CSCv1|1.2"
see_also : "https://workbench.cisecurity.org/files/2392"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " - Lockdown Mode : "
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " - Lockdown Mode : NOT found"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
regex : "Lockdown Mode : "
expect : "Lockdown Mode : lockdownNormal$"
type : AUDIT_ESX
description : "5.8 Ensure idle ESXi shell and SSH sessions time out after 1800 seconds or less"
info : "The ESXiShellInteractiveTimeOut allows you to automatically terminate idle ESXi shell and SSH sessions. The permitted idle time should be 1800 seconds or less.
Rationale:
If a user forgets to log out of an ESXi shell or SSH session, the idle session will exist
indefinitely, increasing the potential for someone to gain unauthorized privileged access to
the host, unless a timeout is set."
solution : "To set the timeout to the desired value, perform the following from the vSphere web client:
1. Select the host.
2. Click \"Configure\" -> \"System\" -> \"Advanced System Settings\".
3. Type ESXiShellInteractiveTimeOut in the filter.
4. Click on the attribute to highlight it.
5. Click the pencil icon to edit.
6. Set the attribute to the desired value (1800 seconds or less).
7. Click \"OK\".
Note: A value of 0 disables the ESXi ShellInteractiveTimeOut.
Alternately, use the following PowerCLI command:
# Set Remove UserVars.ESXiShellInteractiveTimeOut to 1800 on all hosts
Get-VMHost | Get-AdvancedSetting -Name 'UserVars.ESXiShellInteractiveTimeOut'
| Set-AdvancedSetting -Value \"1800\""
reference : "800-171|3.1.11,800-53|AC-12,CN-L3|7.1.2.2(d),CN-L3|7.1.3.7(b),CSCv7|16.11,ITSG-33|AC-12,LEVEL|1S,NIAv2|NS49"
see_also : "https://workbench.cisecurity.org/files/2392"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " - : "
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " - UserVars.ESXiShellInteractiveTimeOut : NOT configured"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
regex : "UserVars\.ESXiShellInteractiveTimeOut : "
expect : "UserVars\.ESXiShellInteractiveTimeOut : \b(([1-9]$)|([1-9][0-9]$)|([1-9][0-9][0-9]$)|([1][0-7][0-9][0-9]$)|(1800$))\b"
type : AUDIT_ESX
description : "5.9 Ensure the shell services timeout is set to 1 hour or less"
info : "When the ESXi shell or SSH services are enabled on a host, they will run indefinitely. To
avoid this, set the ESXiShellTimeOut, which defines a window of time after which the ESXi
shell and SSH services will automatically be terminated.
It is recommended to set the ESXiShellInteractiveTimeOut together with ESXiShellTimeOut.
Rationale:
This reduces the risk of an inactive ESXi shell or SSH service being misused by an unauthorized party to compromise a host."
solution : "To set the timeout to the desired value, perform the following from the vSphere web client:
1. Select the host and click \"Configure\" -> \"System\" -> \"Advanced System Settings\".
2. Type ESXiShellTimeOut in the filter.
3. Click on the attribute to highlight it.
4. Click the pencil icon to edit.
5. Set the attribute to 1800 seconds (30 minutes) or less.
6. Click \"OK\".
Note: A value of 0 disables the ESXiShellTimeOut.
Alternately, run the following PowerCLI command:
# Set UserVars.ESXiShellTimeOut to 1800 on all hosts
Get-VMHost | Get-AdvancedSetting -Name 'UserVars.ESXiShellTimeOut' | Set-AdvancedSetting -Value \"1800\""
reference : "800-171|3.1.11,800-53|AC-12,CN-L3|7.1.2.2(d),CN-L3|7.1.3.7(b),CSCv7|16.11,ITSG-33|AC-12,LEVEL|1S,NIAv2|NS49"
see_also : "https://workbench.cisecurity.org/files/2392"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " - : "
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " - UserVars.ESXiShellTimeout : NOT configured"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
regex : "UserVars\.ESXiShellTimeout : "
expect : "UserVars\.ESXiShellTimeout : (([1-9]$)|([1-9][0-9]$)|([1-9][0-9][0-9]$)|([1][0-7][0-9][0-9]$)|(1800$))"
##expect : "UserVars\.ESXiShellTimeout : (([0-9]|[1-8][0-9]|9[0-9]|[1-8][0-9]{2}|9[0-8][0-9]|99[0-9]|1[0-7][0-9]{2}|1800))"
type : AUDIT_ESX
description : "5.10 Ensure DCUI has a trusted users list for lockdown mode"
info : "Lockdown mode disables direct host access, requiring admins to manage hosts from
vCenter. Set DCUI.Access to a list of highly trusted users who would be able to override
lockdown mode and access the DCUI in the event an ESXi host became isolated from
vCenter.
NOTE: If you disable lockdown mode using the DCUI, all users with the DCUI.Access
privilege will be granted the Administrator role on the host.
Rationale:
The list prevents all admins from becoming locked out and no longer being able to manage
the host."
solution : "To set a trusted users list for DCUI, perform the following from the vSphere web client:
1. Select the host.
2. Select \"Configure\" -> \"System\" -> \"Advanced System Settings\".
3. Type DCUI.Access in the filter.
4. Click on the attribute to highlight it.
5. Click edit.
6. Set the DCUI.Access attribute to a comma-separated list of the users who are allowed to override lockdown mode.
7. Click \"OK\"."
reference : "800-171|3.1.15,800-171|3.1.2,800-53|AC-17,CSCv7|16.6,CSF|PR.AC-3,CSF|PR.PT-4,ITSG-33|AC-17,LEVEL|1NS,SWIFT-CSCv1|5.1"
see_also : "https://workbench.cisecurity.org/files/2392"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " - : "
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " - DCUI.Access : NOT configured"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
regex : "DCUI\.Access : "
# Note: Variable @DCUI_ACCESS@ replaced with "root" in field "expect".
expect : "DCUI\.Access : root$"
type : AUDIT_ESX
description : "6.1 Ensure bidirectional CHAP authentication for iSCSI traffic is enabled"
info : "vSphere allows for the use of bidirectional authentication of both the iSCSI target and host.
Bidirectional Challenge-Handshake Authentication Protocol (CHAP), also known as Mutual
CHAP, should be enabled to provide bidirectional authentication.
Rationale:
By not authenticating both the iSCSI target and host, there is a potential for a man-in-the-
middle attack in which an attacker might impersonate either side of the connection to steal
data. Bidirectional authentication can mitigate this risk.
Note: Choosing not to enforce bidirectional authentication can make sense if you create a
dedicated network or VLAN to service all your iSCSI devices. If the iSCSI facility is isolated
from general network traffic, it is less vulnerable to exploitation."
solution : "To enable bidirectional CHAP authentication for iSCSI traffic, perform the following:
1. From the vSphere Web Client, navigate to \"Hosts and Clusters\".
2. Click on a host.
3. Click on \"Configure\" -> \"Storage\" -> \"Storage Adapters\".
4. Select the iSCSI adapter to configure OR click the green plus symbol to create a new adapter.
5. Under Adapter Details, click the Properties tab and click \"Edit\" in the Authentication panel.
6. Specify authentication method: \"Use bidirectional CHAP\".
7. Specify the outgoing CHAP name.
- Make sure that the name you specify matches the name configured on the storage side.
- To set the CHAP name to the iSCSI adapter name, select \"Use initiator name\".
- To set the CHAP name to anything other than the iSCSI initiator name, deselect \"Use initiator name\" and type a name in the Name text box.
8. Enter an outgoing CHAP secret to be used as part of authentication. Use the same secret as your storage side secret.
9. Specify incoming CHAP credentials. Make sure your outgoing and incoming secrets do not match.
10. Click OK.
11. Click the second to last symbol to rescan the iSCSI adapter.
Alternately, run the following PowerCLI command:
# Set the Chap settings for the Iscsi Adapter
Get-VMHost | Get-VMHostHba | Where {$_.Type -eq \"Iscsi\"} | Set-VMHostHba #Use desired parameters here"
reference : "800-53|IA-3,CSF|PR.AC-1,ITSG-33|IA-3,LEVEL|1S,NESA|T5.4.3"
see_also : "https://workbench.cisecurity.org/files/2392"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " () - chapAuthEnabled : "
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " - chapAuthEnabled : No iSCSI devices found"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
regex : "chapAuthEnabled : "
not_expect : "chapAuthEnabled : FALSE$"
description : "6.2 Ensure the uniqueness of CHAP authentication secrets for iSCSI traffic"
info : "Challenge-Handshake Authentication Protocol (CHAP) requires both client and host to
know the secret (password) to establish a connection. Each mutual authentication secret
should be unique.
Rationale:
If all mutual authentication secrets are unique, compromise of one secret does not allow an attacker to authenticate to other hosts or clients using that same secret.
NOTE: Nessus has not performed this check. Please review the benchmark to ensure target compliance."
solution : "To change the values of CHAP secrets so they are unique, perform the following:
1. From the vSphere Web Client, navigate to \"Hosts\".
2. Click on a host.
3. Click on \"Configure\" -> \"Storage\" -> \"Storage Adapters\".
4. Select the iSCSI adapter to configure OR click the green plus symbol to create a new adapter.
5. Under Adapter Details, click the Properties tab and click \"Edit\" in the Authentication panel.
6. Specify the authentication method.
- None
- Use unidirectional CHAP if required by target
- Use unidirectional CHAP unless prohibited by target
- Use unidirectional CHAP
- Use bidirectional CHAP
7. Specify the outgoing CHAP name.
- Make sure that the name you specify matches the name configured on the storage side.
- To set the CHAP name to the iSCSI adapter name, select \"Use initiator name\".
- To set the CHAP name to anything other than the iSCSI initiator name, deselect \"Use initiator name\" and type a name in the Name text box.
8. Enter an outgoing CHAP secret to be used as part of authentication. Use the same secret as your storage side secret.
9. If configuring with bidirectional CHAP, specify incoming CHAP credentials.
- Make sure your outgoing and incoming secrets do not match.
10. Click OK.
11. Click the second to last symbol to rescan the iSCSI adapter."
reference : "LEVEL|1NS"
see_also : "https://workbench.cisecurity.org/files/2392"
description : "6.3 Ensure storage area network (SAN) resources are segregated properly"
info : "Use zoning and logical unit number (LUN) masking to segregate storage area network (SAN) activity.
Zoning provides access control in the SAN topology. Zoning defines which host bus
adapters (HBAs) can connect to which targets. The devices outside a zone are not visible to
the devices inside the zone when SAN zoning is configured. For example, zones defined for
testing should be managed independently within the SAN so they do not interfere with
activity in the production zones. Similarly, you can set up different zones for different
departments. Zoning must take into account any host groups that have been set up on the
SAN device.
LUN masking is a process that makes a LUN available to some hosts and unavailable to
other hosts.
Rationale:
Segregating SAN activity can reduce the attack surface for the SAN, prevent non-ESXi
systems from accessing SANs, and separate environments, for example, test and production
environments.
NOTE: Nessus has not performed this check. Please review the benchmark to ensure target compliance."
solution : "The remediation procedures to properly segregate SAN activity are SAN vendor or product-specific.
In general, with ESXi hosts, use a single-initiator zoning or a single-initiator-single-target
zoning. The latter is a preferred zoning practice. Using the more restrictive zoning prevents
problems and misconfigurations that can occur on the SAN."
reference : "LEVEL|1NS"
see_also : "https://workbench.cisecurity.org/files/2392"
type : AUDIT_ESX
description : "7.1 Ensure the vSwitch Forged Transmits policy is set to reject"
info : "Set the vSwitch Forged Transmits policy to reject for each vSwitch. Reject Forged Transmit
can be set at the vSwitch and/or the Portgroup level. You can override switch-level settings
at the Portgroup level.
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. Setting forged transmissions to
accept 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."
solution : "To set the policy to reject forged transmissions, perform the following:
1. In the vSphere Web Client, navigate to the host.
2. Go to \"Hosts and Clusters\" -> \"vCenter\" -> host.
3. On the Configure tab, click Networking, and select Virtual switches.
4. Select a standard switch from the list and click the pencil icon to edit settings.
5. Select Security.
6. Set Forged transmits to \"Reject\".
7. Click \"OK\".
Alternately, the following ESXi shell command may be used:
# esxcli network vswitch standard policy security set -v vSwitch2 -f false"
reference : "800-171|3.13.1,800-53|SC-7,CSCv7|12.4,ITSG-33|SC-7,LEVEL|1S,NIAv2|AM38,NIAv2|SS13d,NIAv2|SS26"
see_also : "https://workbench.cisecurity.org/files/2392"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " () - forgedTransmits = "
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " - forgedTransmits = NOT configured"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
regex : "forgedTransmits ="
expect : "forgedTransmits = FALSE$"
type : AUDIT_ESX
description : "7.2 Ensure the vSwitch MAC Address Change policy is set to reject"
info : "Ensure the MAC Address Change policy within the vSwitch is set to reject. Reject MAC
Changes can be set at the vSwitch and/or the Portgroup level. You can override switch-
level settings at the Portgroup level.
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."
solution : "To set the policy to reject, perform the following:
1. In the vSphere Web Client, navigate to the host.
2. Go to \"Hosts and Clusters\" -> \"vCenter\" -> host.
3. On the Configure tab, click Networking, and select Virtual switches.
4. Select a standard switch from the list and click the pencil icon to edit settings.
5. Select Security.
6. Set MAC Address Changes to \"Reject\".
7. Click \"OK\".
Alternately, perform the following using the ESXi shell:
# esxcli network vswitch standard policy security set -v vSwitch2 -m false"
reference : "800-171|3.13.1,800-53|SC-7,CSCv7|12.4,ITSG-33|SC-7,LEVEL|1S,NIAv2|AM38,NIAv2|SS13d,NIAv2|SS26"
see_also : "https://workbench.cisecurity.org/files/2392"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " () - macChanges = "
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " - macChanges = NOT configured"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
regex : "macChanges ="
expect : "macChanges = FALSE$"
type : AUDIT_ESX
description : "7.3 Ensure the vSwitch Promiscuous Mode policy is set to reject"
info : "Ensure the Promiscuous Mode Policy within the vSwitch is set to reject. Promiscuous mode
can be set at the vSwitch and/or the Portgroup level. You can override switch-level settings
at the Portgroup level.
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. This could
enable unauthorized access to the contents of those packets."
solution : "To set the policy to reject, perform the following:
1. In the vSphere Web Client, navigate to the host.
2. Go to \"Hosts and Clusters\" -> \"vCenter\" -> host.
3. On the Configure tab, click Networking, and select Virtual switches.
4. Select a standard switch from the list and click the pencil icon to edit settings.
5. Select Security.
6. Set Promiscuous Mode to \"Reject\".
7. Click \"OK\".
Alternately, perform the following via the ESXi shell:
# esxcli network vswitch standard policy security set -v vSwitch2 -p false
Default Value:
reject"
reference : "800-171|3.13.1,800-53|SC-7,CSCv7|12.4,ITSG-33|SC-7,LEVEL|1S,NIAv2|AM38,NIAv2|SS13d,NIAv2|SS26"
see_also : "https://workbench.cisecurity.org/files/2392"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " () - allowPromiscuous = "
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " - allowPromiscuous = NOT configured"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
regex : "allowPromiscuous ="
expect : "allowPromiscuous = FALSE$"
type : AUDIT_ESX
description : "7.4 Ensure port groups are not configured to the value of the native VLAN"
info : "ESXi does not use the concept of native VLAN, so do not configure port groups to use the
native VLAN ID. 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.
Rationale:
Frames with VLAN specified in the port group will have a tag, but frames without a VLAN
specified in the port group are not tagged and therefore will end up as belonging to the
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.
NOTE: Nessus has provided the target output to assist in reviewing the benchmark to ensure target compliance."
solution : "To stop using the native VLAN ID for port groups, perform the following:
1. From the vSphere web client, select the host.
2. On the Configure tab, click Networking, and select Virtual switches.
3. Select a standard switch from the list.
4. View the topology diagram of the switch, which shows the various port groups associated with that switch.
5. For each port group on the vSwitch, verify and record the VLAN IDs used.
6. If a VLAN ID change is needed, click the name of the port group in the topology diagram of the virtual switch.
7. Click the \"Edit settings\" pencil icon under the topology diagram title.
8. In the Properties section, name the port group in the Network Label text field.
9. Choose an existing VLAN ID drop-down menu or type in a new one."
reference : "CSCv7|9.2,LEVEL|1S"
see_also : "https://workbench.cisecurity.org/files/2392"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " () - vlanId = "
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " - vlanId = NOT configured"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
severity : MEDIUM
type : AUDIT_ESX
description : "7.5 Ensure port groups are not configured to VLAN values reserved by upstream physical switches"
info : "Ensure that port groups are not configured to VLAN values reserved by upstream physical
switches. Certain physical switches reserve certain VLAN IDs for internal purposes and
often disallow traffic configured to these values. For example, Cisco Catalyst switches
typically reserve VLANs 1001 through 1024 and 4094, while Nexus switches typically
reserve 3968 through 4047 and 4094. Check the documentation for your specific switch.
Rationale:
Using a reserved VLAN might result in a denial of service on the network.
NOTE: Nessus has provided the target output to assist in reviewing the benchmark to ensure target compliance."
solution : "To change the VLAN values for port groups to non-reserved values, perform the following:
1. From the vSphere web client, select the host.
2. On the Configure tab, click Networking, and select Virtual switches.
3. Select a standard switch from the list.
4. View the topology diagram of the switch, which shows the various port groups associated with that switch.
5. For each port group on the vSwitch, verify and record the VLAN IDs used.
6. If a VLAN ID change is needed, click the name of the port group in the topology diagram of the virtual switch.
7. Click the \"Edit settings\" pencil icon under the topology diagram title.
8. In the Properties section, name the port group in the Network Label text field.
9. Choose an existing VLAN ID drop-down menu or type in a new one."
reference : "CSCv7|9.2,LEVEL|1NS"
see_also : "https://workbench.cisecurity.org/files/2392"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " () - vlanId = "
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " - vlanId = NOT configured"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
severity : MEDIUM
type : AUDIT_ESX
description : "7.6 Ensure port groups are not configured to VLAN 4095 except for Virtual Guest Tagging (VGT)"
info : "Port groups should not be configured to VLAN 4095 except for Virtual Guest Tagging (VGT).
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 virtual machine 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.
Rationale:
If VGT is enabled inappropriately, it might cause a denial of service or allow a guest virtual
machine to interact with traffic on an unauthorized VLAN."
solution : "To set port groups to values other than 4095 unless VGT is required, perform the following:
1. From the vSphere web client, select the host.
2. On the Configure tab, click Networking, and select Virtual switches.
3. Select a standard switch from the list.
4. View the topology diagram of the switch, which shows the various port groups associated with that switch.
5. For each port group on the vSwitch, verify and record the VLAN IDs used.
6. If a VLAN ID change is needed, click the name of the port group in the topology diagram of the virtual switch.
7. Click the \"Edit settings\" pencil icon under the topology diagram title.
8. In the Properties section, name the port group in the Network Label text field.
9. Choose an existing VLAN ID drop-down menu or type in a new one."
reference : "800-171|3.4.2,800-53|CM-6,CSCv7|9.2,CSF|PR.IP-1,ITSG-33|CM-6,LEVEL|1S,NESA|T3.2.1,SWIFT-CSCv1|2.3"
see_also : "https://workbench.cisecurity.org/files/2392"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " () - vlanId = "
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " - vlanId = NOT configured"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
regex : "vlanId ="
not_expect : "vlanId = 4095$"
description : "7.7 Ensure Virtual Disributed Switch Netflow traffic is sent to an authorized collector"
info : "The vSphere VDS can export Netflow information about traffic crossing the VDS. These
exports are not encrypted and can contain information about the virtual network making it
easier for a Man in the Middle attack to be executed successfully.
Rationale:
If Netflow export is required, verify that all VDS Netflow target systems are approved
collectors by confirming the IP's are set correctly.
NOTE: Nessus has not performed this check. Please review the benchmark to ensure target compliance."
solution : "Using the vSphere Web Client
1. For each distributed switch
2. Go to \"Configure\" -> \"Settings\" -> \"NetFlow\".
3. Click \"Edit\"
4. Set the \"Collector IP address\" and \"Collector port\" to the organization approved systems.
Additionally, the following PowerCLI command may be used
\"# Disable Netfow for a VDPortgroup
$DPortgroup =
Get-VDPortgroup $DPortGroup | Disable-PGNetflow
#Function for Disable-PGNetflow
#From: http://www.virtu-al.net/2013/07/23/disabling-netflow-with-powercli/
Function Disable-PGNetflow {
[CmdletBinding()]
Param (
[Parameter(ValueFromPipeline=$true)]
$DVPG
)
Process {
Foreach ($PG in $DVPG) {
$spec = New-Object VMware.Vim.DVPortgroupConfigSpec
$spec.configversion = $PG.Extensiondata.Config.ConfigVersion
$spec.defaultPortConfig = New-Object VMware.Vim.VMwareDVSPortSetting
$spec.defaultPortConfig.ipfixEnabled = New-Object
VMware.Vim.BoolPolicy
$spec.defaultPortConfig.ipfixEnabled.inherited = $false
$spec.defaultPortConfig.ipfixEnabled.value = $false
$PGView = Get-View -Id $PG.Id
$PGView.ReconfigureDVPortgroup_Task($spec)
}
}
}"
reference : "LEVEL|1S"
see_also : "https://workbench.cisecurity.org/files/2392"
description : "7.8 Ensure port-level configuration overrides are disabled."
info : "Port-level configuration overrides are disabled by default. Once enabled, it allows for
different security to be set ignoring what is set at the Port-Group level.
Rationale:
There are cases where unique configurations are needed, but this should be monitored so it
is only used when authorized. If overrides are not monitored, anyone who gains access to a
VM with a less secure VDS configuration could secretly exploit the broader access.
NOTE: Nessus has not performed this check. Please review the benchmark to ensure target compliance."
solution : "Using the vSphere Web Client,
1. For each portgroup within each distributed switch
2. Go to \"Configure\" -> \"Settings\" -> \"Properties\".
3. Click \"Edit\"
4. Go to \"Advanced\".
5. Disable all \"Override port policies\"."
reference : "LEVEL|1S"
see_also : "https://workbench.cisecurity.org/files/2392"
type : AUDIT_VM
description : "8.1.1 Ensure informational messages from the VM to the VMX file are limited"
info : "Limit informational messages from the virtual machine (VM) to the virtual machine
extensions (VMX) file to avoid filling the datastore. The configuration file containing these
name-value pairs is limited to a size of 1 MB by default. This should be sufficient for most
cases, but you can change this value if necessary, such as if large amounts of custom
information are being stored in the configuration file.
Rationale:
Filling the datastore with informational messages from the VM to the VMX file could cause
a denial of service."
solution : "To limit informational messages to 1 MB, run the following PowerCLI command:
# Add the setting to all VMs
Get-VM | New-AdvancedSetting -Name \"tools.setInfo.sizeLimit\" -value 1048576
Default Value:
1048576"
reference : "800-53|AU-4,CSF|PR.DS-4,CSF|PR.PT-1,ITSG-33|AU-4,LEVEL|1S,NESA|T3.3.1,NESA|T3.6.2"
see_also : "https://workbench.cisecurity.org/files/2392"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " () - tools.setInfo.sizeLimit : "
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " () - tools.setInfo.sizeLimit : "
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " () - tools.setInfo.sizeLimit : NOT configured"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " () - tools.setInfo.sizeLimit : NOT configured"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
regex : "tools\.setInfo\.sizeLimit : "
expect : "tools\.setInfo\.sizeLimit : 1048576$"
type : AUDIT_VM
description : "8.2.1 Ensure unnecessary floppy devices are disconnected"
info : "Ensure that no floppy device is connected to a virtual machine unless required. For a floppy
device to be disconnected, the floppyX.present parameter should either not be present or
have a value of FALSE.
Rationale:
Removing unnecessary hardware devices can reduce the number of potential attack channels and help prevent attacks."
solution : "To disconnect all floppy drives from VMs, run the following PowerCLI command:
# Remove all Floppy drives attached to VMs
Get-VM | Get-FloppyDrive | Remove-FloppyDrive
The VM will need to be powered off for this change to take effect."
reference : "800-171|3.8.7,800-53|MP-7,CSCv7|9.2,CSF|PR.PT-2,LEVEL|1S,NESA|T1.4.1"
see_also : "https://workbench.cisecurity.org/files/2392"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " () - : "
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " () - : "
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " () - floppyX.present : NOT found"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " () - floppyX.present : NOT found"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
regex : "floppy([Xx]|[0-9]+)\.present :"
expect : "floppy[a-zA-Z0-9]\.present : (False|NOT found)$"
type : AUDIT_VM
description : "8.2.3 Ensure unnecessary parallel ports are disconnected"
info : "Ensure that no parallel port is connected to a virtual machine unless required. For a
parallel port to be disconnected, the parallelX.present parameter should either not be
present or have a value of FALSE.
Rationale:
Removing unnecessary hardware devices can reduce the number of potential attack channels and help prevent attacks."
solution : "To disconnect all parallel ports from VMs, 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 Parallel Ports attached to VMs
Get-VM | Get-ParallelPort | Remove-ParallelPort
The VM will need to be powered off for this change to take effect."
reference : "800-171|3.4.6,800-171|3.4.7,800-53|CM-7,CSCv7|9.2,CSF|PR.IP-1,CSF|PR.PT-3,ITSG-33|CM-7,LEVEL|1S,NIAv2|SS15a,SWIFT-CSCv1|2.3"
see_also : "https://workbench.cisecurity.org/files/2392"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " () - : "
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " () - : "
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " () - parallelX.present : NOT found"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " () - parallelX.present : NOT found"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
regex : "parallel([Xx]|[0-9]+)\.present :"
expect : "parallel([Xx]|[0-9]+)\.present : (False|NOT found)$"
type : AUDIT_VM
description : "8.2.4 Ensure unnecessary serial ports are disconnected"
info : "Ensure that no serial port is connected to a virtual machine unless required. For a serial
port to be disconnected, the serialX.present parameter should either not be present or have
a value of FALSE.
Rationale:
Removing unnecessary hardware devices can reduce the number of potential attack channels and help prevent attacks."
solution : "To disconnect all serial ports from VMs, 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
The VM will need to be powered off for this change to take effect."
reference : "800-171|3.4.6,800-171|3.4.7,800-53|CM-7,CSCv7|9.2,CSF|PR.IP-1,CSF|PR.PT-3,ITSG-33|CM-7,LEVEL|1S,NIAv2|SS15a,SWIFT-CSCv1|2.3"
see_also : "https://workbench.cisecurity.org/files/2392"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " () - : "
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " () - : "
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " () - serialX.present : NOT found"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " () - serialX.present : NOT found"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
regex : "serial([Xx]|[0-9]+)\.present :"
expect : "serial([Xx]|[0-9]+)\.present : (False|NOT found)$"
type : AUDIT_VM
description : "8.2.5 Ensure unnecessary USB devices are disconnected"
info : "Ensure that no USB device is connected to a virtual machine unless required. For a USB
device to be disconnected, the usb.present parameter should either not be present or have
a value of FALSE.
Rationale:
Removing unnecessary hardware devices can reduce the number of potential attack channels and help prevent attacks."
solution : "To disconnect all USB devices from VMs, run the following PowerCLI command:
# Remove all USB Devices attached to VMs
Get-VM | Get-USBDevice | Remove-USBDevice
The VM will need to be powered off for this change to take effect."
reference : "800-171|3.4.6,800-171|3.4.7,800-53|CM-7,CSCv7|9.2,CSF|PR.IP-1,CSF|PR.PT-3,ITSG-33|CM-7,LEVEL|1S,NIAv2|SS15a,SWIFT-CSCv1|2.3"
see_also : "https://workbench.cisecurity.org/files/2392"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " () - Virtual USB Controller : "
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " () - Virtual USB Controller : "
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " () - Virtual USB Controller : NOT found"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " () - Virtual USB Controller : NOT found"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
regex : "Virtual USB Controller :"
expect : "Virtual USB Controller : (False|NOT found)$"
type : AUDIT_VM
description : "8.2.6 Ensure unauthorized modification and disconnection of devices is disabled"
info : "In a virtual machine, users and processes without root or administrator privileges can
disconnect devices, such as network adapters and CD-ROM drives, and modify device
settings within the guest operating system. These actions should be prevented.
Rationale:
Disabling unauthorized modification and disconnection of devices helps prevents
unauthorized changes within the guest operating system, which could be used to gain
unauthorized access, cause denial of service conditions, and otherwise negatively affect the
security of the guest operating system."
solution : "To prevent unauthorized device modifications and disconnections, run the following
PowerCLI command:
# Add the setting to all VMs
Get-VM | New-AdvancedSetting -Name \"isolation.device.edit.disable\" -value $true"
reference : "800-171|3.1.7,800-53|AC-6,CSCv7|9.2,CSF|PR.AC-4,LEVEL|1S"
see_also : "https://workbench.cisecurity.org/files/2392"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " () - isolation.device.edit.disable : "
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " () - isolation.device.edit.disable : "
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " () - isolation.device.edit.disable : NOT found"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " () - isolation.device.edit.disable : NOT found"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
regex : "isolation\.device\.edit\.disable : "
expect : "isolation\.device\.edit\.disable : TRUE$"
type : AUDIT_VM
description : "8.2.7 Ensure unauthorized connection of devices is disabled"
info : "In a virtual machine, users and processes without root or administrator privileges can
connect devices, such as network adapters and CD-ROM drives. This should be prevented.
Rationale:
Disabling unauthorized connection of devices helps prevents unauthorized changes within
the guest operating system, which could be used to gain unauthorized access, cause denial
of service conditions, and otherwise negatively affect the security of the guest operating
system."
solution : "To prevent unauthorized device connections, run the following PowerCLI command:
# Add the setting to all VMs
Get-VM | New-AdvancedSetting -Name \"isolation.device.connectable.disable\" -value $true"
reference : "800-171|3.1.7,800-53|AC-6,CSCv7|9.2,CSF|PR.AC-4,LEVEL|1S"
see_also : "https://workbench.cisecurity.org/files/2392"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " () - isolation.device.connectable.disable : "
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " () - isolation.device.connectable.disable : "
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " () - isolation.device.connectable.disable : NOT found"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " () - isolation.device.connectable.disable : NOT found"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
regex : "isolation\.device\.connectable\.disable : "
expect : "isolation\.device\.connectable\.disable : True$"
type : AUDIT_VM
description : "8.2.8 Ensure PCI and PCIe device passthrough is disabled"
info : "Using the VMware DirectPath I/O feature to pass through a PCI or PCIe device to a virtual
machine can result in a potential security vulnerability.
Rationale:
The vulnerability can be triggered by buggy or malicious code running in privileged mode in the guest OS, such as a device driver."
solution : "Using the vSphere Web Client:
1. Select each VM
2. Click \"Configure\" -> \"Settings\" -> \"Virtual Hardware\" ->
3. Remove the PCI/PCIe passthrough device.
Additionally, the following PowerCLI command can be used:
# Add the setting to all VMs
Get-VM | New-AdvancedSetting -Name \"pciPassthru*.present\" -value \"\""
reference : "800-171|3.4.6,800-171|3.4.7,800-53|CM-7,CN-L3|7.1.3.5(c),CN-L3|7.1.3.7(d),CSF|PR.IP-1,CSF|PR.PT-3,ITSG-33|CM-7,LEVEL|1S,NIAv2|SS13b,NIAv2|SS14a,NIAv2|SS14c,NIAv2|SS15a,SWIFT-CSCv1|2.3"
see_also : "https://workbench.cisecurity.org/files/2392"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " () - pciPassthru*.present : "
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " () - pciPassthru*.present : "
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " () - pciPassthru*.present : NOT found"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " () - pciPassthru*.present : NOT found"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
regex : "pciPassthru.*\.present : "
expect : "pciPassthru.*\.present : NOT found$"
description : "8.3.1 Ensure unnecessary or superfluous functions inside VMs are disabled"
info : "Disable all system components that are not needed to support the application or service
running on the VM. VMs often don't require as many functions as ordinary physical servers,
so when virtualizing, you should evaluate whether a particular function is truly needed.
Rationale:
By disabling unnecessary system components, you reduce the number of potential attack vectors, which reduces the likelihood of compromise.
NOTE: Nessus has not performed this check. Please review the benchmark to ensure target compliance."
solution : "To disable unneeded functions, perform whichever of the following steps are applicable:
1. Disable unused services in the operating system.
2. Disconnect unused physical devices, such as CD/DVD drives, floppy drives, and USB adaptors.
3. Turn off any screen savers.
4. If using a Linux, BSD, or Solaris guest operating system, do not run the X Windows system unless it is necessary."
reference : "CSCv7|9.2,LEVEL|1NS"
see_also : "https://workbench.cisecurity.org/files/2392"
description : "8.3.2 Ensure use of the VM console is limited"
info : "The VM console enables you to connect to the console of a VM, in effect seeing what a
monitor on a physical server would show. The VM console also provides power
management and removable device connectivity controls. Instead of the VM console, use
native remote management services, such as terminal services and ssh, to interact with
VMs. Grant access to the VM console only when needed, and use custom roles to provide
fine-grained permissions for those people who do need access. By default, the vCenter roles
\"Virtual Machine Power User\" and \"Virtual Machine Administrator\" have the \"Virtual
Machine.Interaction.Console Interaction\" privilege.
Rationale:
The VM console could be misused to eavesdrop on VM activity, cause VM outages, and
negatively affect the performance of the console, especially if many VM console sessions
are open simultaneously.
NOTE: Nessus has not performed this check. Please review the benchmark to ensure target compliance."
solution : "To properly limit use of the VM console, perform the following steps:
1. From the vSphere Client, navigate to vCenter --> Administration --> Roles.
2. Create a custom role and choose Edit to enable only the minimum needed effective privileges.
3. Next, select an object in the inventory.
4. Click the Permissions tab to view the user and role pair assignments for that object.
5. Remove any default \"Admin\" or \"Power User\" roles, and assign the new custom role as needed."
reference : "CSCv7|16.1,LEVEL|1NS"
see_also : "https://workbench.cisecurity.org/files/2392"
description : "8.3.3 Ensure secure protocols are used for virtual serial port access"
info : "Serial ports are interfaces for connecting peripherals to the VM. They are often used on
physical systems to provide a direct, low-level connection to the console of a server. Virtual
serial ports allow VMs to communicate with serial ports over networks. If virtual serial
ports are needed, they should be configured to use secure protocols.
Rationale:
If virtual serial ports do not use secure protocols, the communications with those ports
could be eavesdropped on, manipulated, or otherwise compromised, giving attackers
sensitive information or control to unauthorized parties.
NOTE: Nessus has not performed this check. Please review the benchmark to ensure target compliance."
solution : "To configure all virtual serial ports to use secure protocols, change any protocols that are
not secure to one of the following:
. ssl - the equivalent of TCP+SSL
. tcp+ssl - SSL over TCP over IPv4 or IPv6
. tcp4+ssl - SSL over TCP over IPv4
. tcp6+ssl - SSL over TCP over IPv6
. telnets - telnet over SSL over TCP"
reference : "CSCv7|12.4,LEVEL|1NS"
see_also : "https://workbench.cisecurity.org/files/2392"
description : "8.3.4 Ensure templates are used whenever possible to deploy VMs"
info : "Use a hardened base operating system template image to create application-specific
templates, and use the application-specific templates to deploy virtual machines.
Rationale:
By capturing a hardened base operating system image (with no applications installed) in a
template, you can ensure that all your virtual machines are created with a known baseline
level of security. Manual installation of the OS and applications into a VM introduces the
risk of misconfiguration due to human or process error.
NOTE: Nessus has not performed this check. Please review the benchmark to ensure target compliance."
solution : "To change current practices so templates are used whenever possible to deploy VMs,
perform whichever of the following steps is appropriate:
. Create templates and configure them properly
. Alter standard procedures and processes to use the templates
Also, ensure that the applications do not depend on information specific to the VM to be
deployed."
reference : "CSCv7|5.1,CSCv7|5.2,LEVEL|1NS"
see_also : "https://workbench.cisecurity.org/files/2392"
type : AUDIT_VM
description : "8.4.1 Ensure access to VMs through the dvfilter network APIs is configured correctly"
info : "A VM must be configured explicitly to accept access by the dvfilter network API. Only VMs
that need to be accessed by that API should be configured to accept such access.
Rationale:
An attacker might compromise a VM by making use of the dvfilter API.
NOTE: Nessus has provided the target output to assist in reviewing the benchmark to ensure target compliance."
solution : "To configure a VM to allow dvfilter access, perform the following steps:
1. Configure the following in the 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.
2. Set the name of the data path kernel correctly.
To configure a VM to not allow dvfilter access, perform the following steps:
1. Remove the following from its VMX file: ethernet0.filter1.name = dv-filter1."
reference : "CSCv7|12.4,CSCv7|9.2,LEVEL|1NS"
see_also : "https://workbench.cisecurity.org/files/2392"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " () - : "
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " () - : "
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " () - ethernetn.filtern.name : NOT configured"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " () - ethernetn.filtern.name : NOT configured"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
severity : MEDIUM
type : AUDIT_VM
description : "8.4.2 Ensure VMsafe Agent Address is configured correctly"
info : "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. A VM must be configured explicitly to accept access by the
VMsafe CPU/memory API. This involves three parameters to perform the following:
1. Enable the API.
2. Set the IP address used by the security virtual appliance on the introspection vSwitch.
3. Set the port number for that IP address.
The second parameter must be set correctly in the vmsafe.agentAddress option in the
virtual machine configuration file for any VMs that should be protected by the API.
Rationale:
An attacker might compromise the VMs by making unauthorized use of the introspection
channel provided by the API."
solution : "To configure the VMsafe Agent Address correctly, perform the following steps:
1. If the VM is not being protected by a VMsafe CPU/memory product, remove
vmsafe.agentAddress from the virtual machine configuration file.
2. If the VM is being protected by a VMsafe CPU/Memory product, set
vmsafe.agentAddress to the correct value."
reference : "800-171|3.14.5,800-53|SI-3,CSCv7|8.3,CSF|DE.CM-4,LEVEL|1NS,NIAv2|GS17,SWIFT-CSCv1|6.1"
see_also : "https://workbench.cisecurity.org/files/2392"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " () - vmsafe.agentAddress : "
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " () - vmsafe.agentAddress : "
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " () - vmsafe.agentAddress : NOT found"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " () - vmsafe.agentAddress : NOT found"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
regex : "vmsafe\.agentAddress : "
# Note: Variable @AGENT_ADDRESS@ replaced with "192\\.168\\.0\\.1" in field "expect".
expect : "vmsafe\.agentAddress : 192\\.168\\.0\\.1$"
type : AUDIT_VM
description : "8.4.3 Ensure VMsafe Agent Port is configured correctly"
info : "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. A VM must be configured explicitly to accept access by the
VMsafe CPU/memory API. This involves three parameters to perform the following:
1. Enable the API.
2. Set the IP address used by the security virtual appliance on the introspection vSwitch.
3. Set the port number for that IP address.
The third parameter must be set correctly in the vmsafe.agentPort option in the virtual
machine configuration file for any VMs that should be protected by the API.
Rationale:
An attacker might compromise the VMs by making unauthorized use of the introspection
channel provided by the API."
solution : "To configure the VMsafe Agent Port correctly, perform the following steps:
1. If the VM is not being protected by a VMsafe CPU/memory product, remove vmsafe.agentPort from the virtual machine configuration file.
2. If the VM is being protected by a VMsafe CPU/Memory product, set vmsafe.agentPort to the correct value."
reference : "800-171|3.14.5,800-53|SI-3,CSCv7|9.2,CSF|DE.CM-4,LEVEL|1NS,NIAv2|GS17,SWIFT-CSCv1|6.1"
see_also : "https://workbench.cisecurity.org/files/2392"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " () - vmsafe.agentPort : "
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " () - vmsafe.agentPort : "
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " () - vmsafe.agentPort : NOT configured"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " () - vmsafe.agentPort : NOT configured"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
regex : "vmsafe\.agentPort : "
# Note: Variable @AGENT_PORT@ replaced with "10000" in field "expect".
expect : "vmsafe\.agentPort : 10000$"
type : AUDIT_VM
description : "8.4.4 Ensure VMsafe Agent is configured correctly"
info : "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. A VM must be configured explicitly to accept access by the
VMsafe CPU/memory API. This involves three parameters to perform the following:
1. Enable the API.
2. Set the IP address used by the security virtual appliance on the introspection vSwitch.
3. Set the port number for that IP address.
The first parameter must be set correctly in the vmsafe.enable option in the virtual
machine configuration file for any VMs that should be protected by the API. For any VMs
that should not be protected by the API, this option should not exist in the configuration
file.
Rationale:
An attacker might compromise the VMs by making unauthorized use of the introspection
channel provided by the API."
solution : "To configure the VMsafe Agent correctly, perform the following steps:
1. If the VM is not being protected by a VMsafe CPU/memory product, remove vmsafe.enable from the virtual machine configuration file or set it to a value of FALSE.
2. If the VM is being protected by a VMsafe CPU/Memory product, set vmsafe.enable to the correct value.
Default Value:
The prescribed state is the default state."
reference : "800-171|3.14.5,800-53|SI-3,CSCv7|9.2,CSF|DE.CM-4,LEVEL|1NS,NIAv2|GS17,SWIFT-CSCv1|6.1"
see_also : "https://workbench.cisecurity.org/files/2392"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " () - vmsafe.enable : "
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " () - vmsafe.enable : "
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " () - vmsafe.enable : NOT found"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " () - vmsafe.enable : NOT found"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
regex : "vmsafe\.enable : "
expect : "vmsafe\.enable : FALSE$"
type : AUDIT_VM
description : "8.4.24 Ensure VM Console Copy operations are disabled"
info : "VM console copy operations should be disabled.
Rationale:
VM console copy operations are disabled by default (not explicitly specified); however, explicitly disabling this feature enables audit controls to check that this setting is correct."
solution : "To explicitly disable VM console copy operations, run the following PowerCLI command:
# Add the setting to all VMs
Get-VM | New-AdvancedSetting -Name \"isolation.tools.copy.disable\" -value $true
Default Value:
Disabled"
reference : "800-171|3.4.6,800-171|3.4.7,800-53|CM-7,CSCv7|9.2,CSF|PR.IP-1,CSF|PR.PT-3,ITSG-33|CM-7,LEVEL|1S,NIAv2|SS15a,SWIFT-CSCv1|2.3"
see_also : "https://workbench.cisecurity.org/files/2392"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " () - isolation.tools.copy.disable : "
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " () - isolation.tools.copy.disable : "
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " () - isolation.tools.copy.disable : NOT configured"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " () - isolation.tools.copy.disable : NOT configured"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
regex : "isolation\.tools\.copy\.disable : "
expect : "isolation\.tools\.copy\.disable : TRUE$"
type : AUDIT_VM
description : "8.4.25 Ensure VM Console Drag and Drop operations is disabled"
info : "VM console drag and drop operations should be disabled.
Rationale:
VM console drag and drop operations are disabled by default (not explicitly specified);
however, explicitly disabling this feature enables audit controls to check that this setting is
correct."
solution : "To explicitly disable VM console drag and drop operations, run the following PowerCLI command:
# Add the setting to all VMs
Get-VM | New-AdvancedSetting -Name \"isolation.tools.dnd.disable\" -value $true
Default Value:
Disabled"
reference : "800-171|3.4.6,800-171|3.4.7,800-53|CM-7,CSCv7|9.2,CSF|PR.IP-1,CSF|PR.PT-3,ITSG-33|CM-7,LEVEL|1S,NIAv2|SS15a,SWIFT-CSCv1|2.3"
see_also : "https://workbench.cisecurity.org/files/2392"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " () - isolation.tools.dnd.disable : "
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " () - isolation.tools.dnd.disable : "
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " () - isolation.tools.dnd.disable : NOT configured"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " () - isolation.tools.dnd.disable : NOT configured"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
regex : "isolation\.tools\.dnd\.disable : "
expect : "isolation\.tools\.dnd\.disable : TRUE$"
type : AUDIT_VM
description : "8.4.26 Ensure VM Console GUI Options is disabled"
info : "VM console and paste GUI options should be disabled.
Rationale:
VM console and paste GUI options are disabled by default (not explicitly specified); however, explicitly disabling this feature enables audit controls to check that this setting is correct."
solution : "To explicitly disable VM console and paste GUI options, run the following PowerCLI command:
# Add the setting to all VMs
Get-VM | New-AdvancedSetting -Name \"isolation.tools.setGUIOptions.enable\" -
value $false
Default Value:
Disabled"
reference : "800-171|3.4.6,800-171|3.4.7,800-53|CM-7,CSCv7|9.2,CSF|PR.IP-1,CSF|PR.PT-3,ITSG-33|CM-7,LEVEL|1S,NIAv2|SS15a,SWIFT-CSCv1|2.3"
see_also : "https://workbench.cisecurity.org/files/2392"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " () - isolation.tools.setGUIOptions.enable : "
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " () - isolation.tools.setGUIOptions.enable : "
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " () - isolation.tools.setGUIOptions.enable : NOT configured"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " () - isolation.tools.setGUIOptions.enable : NOT configured"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
regex : "isolation\.tools\.setGUIOptions\.enable : "
expect : "isolation\.tools\.setGUIOptions\.enable : FALSE$"
type : AUDIT_VM
description : "8.4.27 Ensure VM Console Paste operations are disabled"
info : "VM console paste operations should be disabled.
Rationale:
VM console paste operations are disabled by default (not explicitly specified); however, explicitly disabling this feature enables audit controls to check that this setting is correct."
solution : "To explicitly disable VM console paste operations, run the following PowerCLI command:
# Add the setting to all VMs
Get-VM | New-AdvancedSetting -Name \"isolation.tools.paste.disable\" -value $true
Default Value:
Disabled"
reference : "800-171|3.4.6,800-171|3.4.7,800-53|CM-7,CSCv7|9.2,CSF|PR.IP-1,CSF|PR.PT-3,ITSG-33|CM-7,LEVEL|1S,NIAv2|SS15a,SWIFT-CSCv1|2.3"
see_also : "https://workbench.cisecurity.org/files/2392"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " () - isolation.tools.paste.disable : "
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " () - isolation.tools.paste.disable : "
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " () - isolation.tools.paste.disable : NOT configured"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " () - isolation.tools.paste.disable : NOT configured"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
regex : "isolation\.tools\.paste\.disable : "
expect : "isolation\.tools\.paste\.disable : TRUE$"
type : AUDIT_VM
description : "8.4.28 Ensure access to VM console via VNC protocol is limited"
info : "Minimize access to the Virtual Machine via VNC protocol.
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. This console is also available via the VNC
protocol. Setting up this access also involves setting up firewall rules on each ESXi server
the virtual machine will run on."
solution : "To implement the recommended configuration state, run the following PowerCLI command:
# Add the setting to all VMs
Get-VM | New-AdvancedSetting -Name \"RemoteDisplay.vnc.enabled\" -value $false
Impact:
Configuring VM settings and opening up the firewall means multiple steps to be configured and monitored."
reference : "800-171|3.4.6,800-171|3.4.7,800-53|CM-7,CN-L3|7.1.3.5(c),CN-L3|7.1.3.7(d),CSCv7|9.2,CSF|PR.IP-1,CSF|PR.PT-3,ITSG-33|CM-7,LEVEL|1S,NIAv2|SS13b,NIAv2|SS14a,NIAv2|SS14c,NIAv2|SS15a,SWIFT-CSCv1|2.3"
see_also : "https://workbench.cisecurity.org/files/2392"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " () - RemoteDisplay.vnc.enabled : "
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " () - RemoteDisplay.vnc.enabled : "
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " () - RemoteDisplay.vnc.enabled : NOT configured"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " () - RemoteDisplay.vnc.enabled : NOT configured"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
regex : "RemoteDisplay\.vnc\.enabled : "
expect : "RemoteDisplay\.vnc\.enabled : FALSE$"
type : AUDIT_VM
description : "8.6.2 Ensure virtual disk shrinking is disabled"
info : "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."
solution : "To implement the recommended configuration state, run the following PowerCLI command:
# Add the setting to all VMs
Get-VM | New-AdvancedSetting -Name \"isolation.tools.diskShrink.disable\" -value $true
Impact:
Inability to shrink virtual machine disks in the event that a datastore runs out of space.
Default Value:
The prescribed state is not the default state."
reference : "800-171|3.4.6,800-171|3.4.7,800-53|CM-7,CSF|PR.IP-1,CSF|PR.PT-3,ITSG-33|CM-7,LEVEL|1S,NIAv2|SS15a,SWIFT-CSCv1|2.3"
see_also : "https://workbench.cisecurity.org/files/2392"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " () - isolation.tools.diskShrink.disable : "
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " () - isolation.tools.diskShrink.disable : "
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " () - isolation.tools.diskShrink.disable : NOT configured"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " () - isolation.tools.diskShrink.disable : NOT configured"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
regex : "isolation\.tools\.diskShrink\.disable : "
expect : "isolation\.tools\.diskShrink\.disable : TRUE$"
type : AUDIT_VM
description : "8.6.3 Ensure virtual disk wiping is disabled"
info : "Wiping a virtual disk reclaims all 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. If virtual
disk wiping is done repeatedly, it can cause the virtual disk to become unavailable while
wiping occurs. In most datacenter environments, disk wiping is not needed, but normal
users and processes--without administrative privileges--can issue disk wipes unless the
feature is disabled.
Rationale:
Virtual disk wiping can effectively cause a denial of service."
solution : "To disable virtual disk wiping, run the following PowerCLI command:
# Add the setting to all VMs
Get-VM | New-AdvancedSetting -Name \"isolation.tools.diskWiper.disable\" -value $true"
reference : "800-171|3.4.6,800-171|3.4.7,800-53|CM-7,CSF|PR.IP-1,CSF|PR.PT-3,ITSG-33|CM-7,LEVEL|1S,NIAv2|SS15a,SWIFT-CSCv1|2.3"
see_also : "https://workbench.cisecurity.org/files/2392"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " () - isolation.tools.diskWiper.disable : "
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " () - isolation.tools.diskWiper.disable : "
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " () - isolation.tools.diskWiper.disable : NOT found"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " () - isolation.tools.diskWiper.disable : NOT found"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
regex : "isolation\.tools\.diskWiper\.disable : "
expect : "isolation\.tools\.diskWiper\.disable : True$"
type : AUDIT_VM
description : "8.7.2 Ensure the number of VM log files is configured properly"
info : "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 MB. 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.
Rationale:
Log files should be rotated to preserve log data in case of corruption or destruction of the
current log file, and to avoid the likelihood of logging issues caused by an overly large log
file."
solution : "To set the number of log files to be used to 10, run the following PowerCLI command:
# Add the setting to all VMs
Get-VM | New-AdvancedSetting -Name \"log.keepOld\" -value \"10\"
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."
reference : "800-53|AU-4,CSCv7|6.4,CSF|PR.DS-4,CSF|PR.PT-1,ITSG-33|AU-4,LEVEL|1S,NESA|T3.3.1,NESA|T3.6.2"
see_also : "https://workbench.cisecurity.org/files/2392"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " () - log.keepOld : "
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " () - log.keepOld : "
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " () - log.keepOld : NOT found"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " () - log.keepOld : NOT found"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
regex : "log\.keepOld : "
expect : "log\.keepOld : 10$"
type : AUDIT_VM
description : "8.7.4 Ensure VM log file size is limited"
info : "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 MB. If the maximum number of log
files already exists, when a new one is created, the oldest log file is deleted.
Rationale:
Virtual machine users and processes can abuse logging either on purpose or inadvertently
so that large amounts of data flood the log file. Without restrictions on maximum log file
size, over time a log file can consume enough file system space to cause a denial of service."
solution : "To properly limit the maximum log file size, run the following PowerCLI command:
# Add the setting to all VMs
Get-VM | New-AdvancedSetting -Name \"log.rotateSize\" -value \"1024000\"
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."
reference : "800-53|AU-4,CSCv7|6.4,CSF|PR.DS-4,CSF|PR.PT-1,ITSG-33|AU-4,LEVEL|1S,NESA|T3.3.1,NESA|T3.6.2"
see_also : "https://workbench.cisecurity.org/files/2392"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " () - log.rotateSize : "
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " () - log.rotateSize : "
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " () - log.rotateSize : NOT found"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : " () - log.rotateSize : NOT found"
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
xsl_stmt : ""
regex : "log\.rotateSize : "
expect : "log\.rotateSize : 1024000$"