Cyber Trackr - Free Compliance Library
Cyber Trackr
The Free Compliance Library

VMware ESX 3 Virtual Center

  • Version/Release: V1R2
  • Published: 2016-05-03
  • Expand All:
  • Severity:
  • Sort:
Compare

Select any two versions of this STIG to compare the individual requirements

View

Select any old version/release of this STIG to view the previous requirements

The VMware ESX 3 Virtual Center Security Technical Implementation Guide (STIG) is published as a tool to improve the security of Department of Defense (DoD) information systems. Comments or proposed revisions to this document should be sent via e-mail to the following address: [email protected].
b
VMotion virtual switches are not configured with a dedicated physical network adapter
Medium - V-15785 - SV-16724r1_rule
RMF Control
Severity
Medium
CCI
Version
ESX0030
Vuln IDs
  • V-15785
Rule IDs
  • SV-16724r1_rule
The security issue with VMotion migrations is that the encapsulated files are transmitted in plaintext. Plaintext provides no confidentiality, and anyone with the proper access may view these files. To mitigate this risk, a dedicated VLAN will be used for all VMotion migrations. Configuring a dedicated VLAN requires that VMotion virtual switches are configured with one physical network adapter on a separate VLAN. This will ensure that VMotion traffic is separate from production traffic. The preferred method to transfer these encapsulated files is to encrypt them with a FIPS 140-2 encryption algorithm. System AdministratorInformation Assurance Officer[Virtual Server Administrator]
Checks: C-15971r1_chk

1. Log into VirtualCenter with the VI Client and select the server from the inventory panel. The hardware configuration page for this server appears. 2. Click the Configuration tab, and click Networking. 3. Examine the virtual switches and their respective VLAN IDs. A separate and dedicated physical network adapter should be configured for VMotion migrations to and from VMFS volumes. If there is no dedicated physical network adapter for these transfers, this is a finding. To illustrate a dedicated physical network adapter the figure below shows the service console configured on a separate physical network adapter. Caveat: This check is Not Applicable if all the network adapters are configured as a NIC Team.

Fix: F-15726r1_fix

Configure a dedicated physical network adapter for all VMotion virtual switches.

b
There is no dedicated VLAN or network segment configured for virtual disk file transfers.
Medium - V-15786 - SV-16725r1_rule
RMF Control
Severity
Medium
CCI
Version
ESX0040
Vuln IDs
  • V-15786
Rule IDs
  • SV-16725r1_rule
The transfer of virtual disk files and VMotion migrations to and from VMFS volumes is sent in plaintext. This type of traffic provides no confidentiality for the data. Due to this vulnerability, at a minimum, virtual disk file transfers and VMotion migrations will be sent over a dedicated VLAN. The preferred method for these transfers is to encrypt this traffic with a FIPS 140-2 encryption algorithm.System AdministratorInformation Assurance Officer[Virtual Server Administrator]
Checks: C-15972r1_chk

1. Log into VirtualCenter with the VI Client and select the ESX server from the inventory panel. The hardware configuration page for the server appears. 2. Click the Configuration tab, and click Networking. 3. Examine the virtual switches and their respective VLAN IDs. A separate and dedicated VLAN should be configured for virtual disk transfers and VMotion migrations to and from VMFS volumes. The administrative VLAN or Out of Band VLAN is acceptable for compliance. If there is no dedicated VLAN for these transfers, this is a finding.

Fix: F-15727r1_fix

Implement a dedicated VLAN for all virtual disk file transfers to and from VMFS volumes.

b
iSCSI VLAN or network segment is not configured for iSCSI traffic.
Medium - V-15788 - SV-16727r1_rule
RMF Control
Severity
Medium
CCI
Version
ESX0060
Vuln IDs
  • V-15788
Rule IDs
  • SV-16727r1_rule
Virtual machines may share virtual switches and VLANs with the iSCSI configuration. This type of configuration may expose iSCSI traffic to unauthorized virtual machine users. To restrict unauthorized users from viewing the iSCSI traffic, the iSCSI network should be logically separated from the production traffic. Configuring the iSCSI adapters on separate VLANs or network segments from the VMkernel and service console will limit unauthorized users from viewing the traffic. System AdministratorInformation Assurance Officer[Virtual Server Administrator]
Checks: C-15975r1_chk

1. Log into VirtualCenter with the VI Client and select the server from the inventory panel. The hardware configuration page for this server appears. 2. Click the Configuration tab, and click Networking. 3. Examine the virtual switches and their respective VLAN IDs. A separate and dedicated VLAN should be configured for all iSCSI connections. If there is no dedicated VLAN for iSCSI, this is a finding.

Fix: F-15730r1_fix

Configure a dedicated VLAN or network segment for iSCSI connections.

b
CHAP authentication is not configured for iSCSI traffic.
Medium - V-15789 - SV-16728r1_rule
RMF Control
Severity
Medium
CCI
Version
ESX0070
Vuln IDs
  • V-15789
Rule IDs
  • SV-16728r1_rule
ISCSI connections are able to be configured with Challenge Handshake Authentication Protocol (CHAP) authentication and IP security (IPSec) encryption. “ESX Server only supports one-way CHAP authentication for iSCSI. It does not support Kerberos, Secure Remote Protocol (SRP), IPSec, or public key authentication methods for iSCSI authentication.” For both software and hardware iSCSI initiators, configuring CHAP for iSCSI connections will ensure proper authentication. “After the iSCSI initiator establishes the initial connection with the target, CHAP verifies the identity of the initiator and checks a CHAP secret that the initiator and the target share. This can be repeated periodically during the iSCSI session.”System AdministratorInformation Assurance Officer[Virtual Server Administrator]
Checks: C-15976r1_chk

To check the authentication method, perform the following within VirtualCenter: 1. Log into VirtualCenter with the VI Client and select the ESX server from the inventory panel. 2. Click the Configuration tab and click Storage Adapters. 3. Select the iSCSI adapter to check and click the Properties to open the iSCSI Initiator Properties dialog box. 4. Click CHAP Authentication. If the CHAP Name shows a name, often the iSCSI initiator name, the iSCSI SAN is using CHAP authentication, and this is Not a Finding. 5. If the CHAP Name shows Not Specified, then the iSCSI SAN is not using CHAP authentication, and this is a finding.

Fix: F-15731r1_fix

Enable CHAP authentication for iSCSI SAN connections.

b
Static discoveries are not configured for hardware iSCSI initiators.
Medium - V-15792 - SV-16731r1_rule
RMF Control
Severity
Medium
CCI
Version
ESX0100
Vuln IDs
  • V-15792
Rule IDs
  • SV-16731r1_rule
ESX Server uses two types of methods to determine what storage resources are available for access by the iSCSI initiators on the network. These methods are dynamic discovery and static discovery. With dynamic discovery, the initiator discovers iSCSI targets by sending a SendTargets request to a specified target address. The target device responds by forwarding a list of additional targets that the initiator is allowed to access. The static discovery method uses the SendTargets request and returned is the list of available targets. Targets are listed on the static discovery list. This list may be modified by the storage administrator by adding or removing targets. The static discovery method is available only with the hardware-initiated storage. Hardware iSCSI initiators will use static discovery since it reduces the likelihood of connecting to some rogue target since all the targets are defined in the static list.System AdministratorInformation Assurance Officer[Virtual Server Administrator]
Checks: C-15979r1_chk

This check only applies if hardware iSCSI initiators are used. If they are used, then perform the following steps to verify static discovery is being used. 1. Log into VirtualCenter with the VI Client and select a ESX server from the inventory panel. 2. Click the Configuration tab and click Storage Adapters in the Hardware group. The list of available adapters (initiators) appears. The iSCSI initiator appears in the list of storage adapters. 3. Under HBA, choose the initiator to review. 4. Click Properties, and the click the Static Discovery tab to verify that iSCSI targets are configured. If none are configured, this is a finding. 5. Next verify that the dynamic discovery tab has no listings. If it does, this is a finding.

Fix: F-15734r1_fix

Configure hardware initiators to use static discovery only.

b
The service console and virtual machines are not on dedicated VLANs or network segments.
Medium - V-15802 - SV-16741r1_rule
RMF Control
Severity
Medium
CCI
Version
ESX0130
Vuln IDs
  • V-15802
Rule IDs
  • SV-16741r1_rule
Virtual machine traffic destined for a physical network should always be placed on a separate physical adapter from service console traffic. It is appropriate to use as many additional physical adapters as are necessary to support virtual machine networks. It may be sufficient to place the service console and virtual machine networks on separate VLANs connected to the same adapter, but connecting them to separate physical networks provides better isolation and more configuration control than is available using VLANs alone. The ESX Server VLAN implementation provides adequate network isolation, but it is possible that traffic could be misdirected due to improper configuration or security vulnerabilities in external networking hardware. It is safer to keep them physically separate.System AdministratorInformation Assurance Officer[Virtual Server Administrator]
Checks: C-16019r1_chk

1. Log into VirtualCenter with the VI Client and select the ESX server from the inventory panel. The hardware configuration page for the server appears. 2. Click the Configuration tab, and click Networking. 3. Examine the virtual switches and their respective VLAN IDs. A separate VLAN ID should be configured for the service console and virtual machine traffic. If the virtual machines and service console are on the same VLAN ID, this is a finding.

Fix: F-15745r1_fix

Configure separate VLANs or network segments for the service console and virtual machine traffic.

a
Notify Switches feature is not enabled to allowfor notifications to be sent to physical switches.
Low - V-15803 - SV-16742r1_rule
RMF Control
Severity
Low
CCI
Version
ESX0140
Vuln IDs
  • V-15803
Rule IDs
  • SV-16742r1_rule
One option in NIC Teaming is Notify Switches. Whenever a virtual NIC is connected to a virtual switch or whenever a virtual NIC’s traffic would be routed over a different physical NIC due to a failover event, a notification is sent. This notification is sent out over the network to update the lookup tables on physical switches. Configuring this to ’Yes’ sends out these notifications while providing the lowest latency of failover occurrences and migrations with VMotion.System AdministratorInformation Assurance Officer[Virtual Server Administrator]
Checks: C-16021r1_chk

1. Log into VirtualCenter with the VI Client and select the ESX server from the inventory panel. The hardware configuration page for the server appears. 2. Click the Configuration tab, and click Networking. 3. Select a vSwitch and click Properties. 4. In the vSwitch Properties dialog box, click the Ports tab. 5. Select the vSwitch and click Edit. 6. Click the NIC Teaming tab. 7. Verify that Notify Switches is set to “Yes”. If not, this is a finding.

Fix: F-15746r1_fix

Enable Notify Switches feature to allow for notifications to be send to physical switches.

b
Virtual machines are connected to public virtual switches and are not documented.
Medium - V-15806 - SV-16745r1_rule
RMF Control
Severity
Medium
CCI
Version
ESX0170
Vuln IDs
  • V-15806
Rule IDs
  • SV-16745r1_rule
Public virtual switches are bound to physical NICs providing virtual machines connectivity to the physical network, whereas connecting physical servers to the LAN usually requires a cable. Virtual network configuration is much easier since once a virtual machine is attached to a virtual switch, these machines are able to send and receive packets. Care must be taken as to which virtual machines have access to the physical network through the public virtual switches. The master configuration file for virtual switches is the esx.conf file.System AdministratorInformation Assurance Officer[Virtual Server Administrator]ECSC-1
Checks: C-16029r1_chk

1. Request the documentation for all virtual machines connected to public virtual switches. If no documentation exists or the documentation is not accurate, this is a finding. 2. Log into VirtualCenter with the VI Client, and select the ESX server from the inventory panel. The hardware configuration page for the server appears. 3. Click the Configuration tab, and click Networking. 4. Review all virtual switches that have virtual machines connected to them that may access the external network. Compare the actual configuration to the documentation and verify that no discrepancies exist. If so, this is a finding.

Fix: F-15749r1_fix

Document all virtual machines that need access to public virtual switches.

b
Virtual switch port group is configured to VLAN 1
Medium - V-15807 - SV-16746r1_rule
RMF Control
Severity
Medium
CCI
Version
ESX0180
Vuln IDs
  • V-15807
Rule IDs
  • SV-16746r1_rule
The VLAN ID restricts port group traffic to a logical Ethernet segment within the physical network. Port groups may have a VLAN ID of 0 to 4095. VLAN ID values of 1 to 4094 place the virtual switch in VST mode. However VLAN 1 will not be enabled for port groups since ESX Server does not support virtual switch port groups configured to VLAN 1. VLAN 1001 through 1024 are Cisco reserved VLANs. VLANs 1, 1001 to 1024, and 4095 will be not be used for virtual switch port groups since they may cause unexpected operation. System AdministratorInformation Assurance Officer[Virtual Server Administrator]
Checks: C-16034r1_chk

1. Log into VirtualCenter with the VI Client and select the server from the inventory panel. 2. Click the Configuration tab and click Networking. Virtual switches are presented in a layout that shows an overview and details. 3. On the right side of the window, click Properties for a network. 4. Click the Ports tab. 5. In the Properties dialog box for the port group, click the General tab to check the VLAN ID. If the VLAN ID is set to 1, this is a finding.

Fix: F-15750r1_fix

Do not configure virtual switch VLAN IDs s to be VLAN 1, 1001-1024, and 4095.

b
Virtual switch port group is configured to VLAN 1001 to 1024.
Medium - V-15808 - SV-16747r1_rule
RMF Control
Severity
Medium
CCI
Version
ESX0190
Vuln IDs
  • V-15808
Rule IDs
  • SV-16747r1_rule
The VLAN ID restricts port group traffic to a logical Ethernet segment within the physical network. Port groups may have a VLAN ID of 0 to 4095. VLAN ID values of 1 to 4094 place the virtual switch in VST mode. However VLAN 1 will not be enabled for port groups since ESX Server does not support virtual switch port groups configured to VLAN 1. VLAN 1001 through 1024 are Cisco reserved VLANs. VLANs 1, 1001 to 1024, and 4095 will be not be used for virtual switch port groups since they may cause an unexpected operation. System AdministratorInformation Assurance Officer[Virtual Server Administrator]
Checks: C-16050r1_chk

1. Log into VirualCenter with the VI Client and select the ESX server from the inventory panel. 2. Click the Configuration tab and click Networking. Virtual switches are presented in a layout that shows an overview and details. 3. On the right side of the window, click Properties for a network. 4. Click the Ports tab. 5. In the Properties dialog box for the port group, click the General tab to check the VLAN ID. If the VLAN ID is set to 1001 to 1024, this is a finding.

Fix: F-15752r1_fix

Do not configure virtual switch VLAN IDs s to be VLAN 1, 1001-1024, and 4095.

b
Virtual switch port group is configured to VLAN 4095.
Medium - V-15809 - SV-16748r1_rule
RMF Control
Severity
Medium
CCI
Version
ESX0200
Vuln IDs
  • V-15809
Rule IDs
  • SV-16748r1_rule
The VLAN ID restricts port group traffic to a logical Ethernet segment within the physical network. Port groups may have a VLAN ID of 0 to 4095. VLAN IDs that have VLAN ID 4095 are able reach other port groups located on other VLANs. Basically, VLAN ID 4095 specifies that the port group should use trunk mode or VGT mode, which allows the guest operating system to manage its own VLAN tags. Guest operating systems typically do not manage their VLAN membership on networks. VLAN 1001 through 1024 are Cisco reserved VLANs. VLANs 1, 1001 to 1024, and 4095 will be not be used for virtual switch port groups since they may cause an unexpected operation. System AdministratorInformation Assurance Officer[Virtual Server Administrator]
Checks: C-16051r1_chk

1. Log into VirtualCenter with the VI Client and select the ESX server from the inventory panel. 2. Click the Configuration tab and click Networking. Virtual switches are presented in a layout that shows an overview and details. 3. On the right side of the window, click Properties for a network. 4. Click the Ports tab. 5. In the Properties dialog box for the port group, click the General tab to check the VLAN ID. If the VLAN ID is set to 4095, this is a finding. Caveat: This check is Not Applicable if the number of VLANs needed for the virtual machine exceeds 4 VLANs, and it is documented with the IAO/SA.

Fix: F-15753r1_fix

Do not configure virtual switch VLAN IDs s to be VLAN 1, 1001-1024, and 4095.

b
Port groups are not configured with a network label.
Medium - V-15810 - SV-16749r1_rule
RMF Control
Severity
Medium
CCI
Version
ESX0210
Vuln IDs
  • V-15810
Rule IDs
  • SV-16749r1_rule
Port Groups define how virtual machine connections are made through the virtual switch. Port groups may be configured with bandwidth limitations and VLAN tagging policies for each member port. Multiple ports may be aggregated under port groups to provide a local point for virtual machines to connect to a network. The maximum number of port groups that may be configured on a virtual switch is 512. Each port group is identified by a network label and a VLAN ID. Network labels identify the port groups with a name. These names are important since they serve as a functional descriptor for the port group. Without these descriptions, identifying port groups and their functions becomes difficult as the network becomes more complex.System AdministratorInformation Assurance Officer[Virtual Server Administrator]
Checks: C-16053r1_chk

1. Log into VirtualCenter with the VI Client and select the ESX server from the inventory panel. 2. Click the Configuration tab and click Networking. Virtual switches are presented in a layout that shows an overview and details. 3. On the right side of the window, click Properties for a network. 4. Click the Ports tab. 5. In the Properties dialog box for the port group, click the General tab to check the Network Label. If no Network Label is configured, this is a finding.

Fix: F-15754r1_fix

Configure a network label for all virtual switches.

b
Virtual switches are not labeled.
Medium - V-15812 - SV-16751r1_rule
RMF Control
Severity
Medium
CCI
Version
ESX0230
Vuln IDs
  • V-15812
Rule IDs
  • SV-16751r1_rule
Virtual switches within the ESX Server require a field for the name of the switch. This label is important since it serves as a functional descriptor for the switch, just as physical switches require a hostname. Labeling virtual switches will indicate the function or the IP subnet of the virtual switch. For instance, labeling the virtual switch as “internal” or some variation will indicate that the virtual switch is only for internal networking between virtual machines private virtual switch with no physical network adapters bound to it.System AdministratorInformation Assurance Officer[Virtual Server Administrator]
Checks: C-16100r1_chk

To check to see if virtual switches have labels, perform the following within VirtualCenter: 1. Log into VirtualCenter with the VI Client and select the ESX server from the inventory panel. The hardware configuration page for this server appears. 2. Click the Configuration tab, and click Networking. Ensure that all virtual switches have a label. If they do not, this is a finding.

Fix: F-15765r1_fix

Label all virtual switches.

b
Virtual switch labels begin with a number.
Medium - V-15813 - SV-16752r1_rule
RMF Control
Severity
Medium
CCI
Version
ESX0240
Vuln IDs
  • V-15813
Rule IDs
  • SV-16752r1_rule
Virtual switches within the ESX Server require a field for the name of the switch. This label is important since it serves as a functional descriptor for the switch. The labels of the virtual switches will not contain a number as the first character, since there have been known issues in the past that have caused erratic behavior. This has been especially true when renaming or removing the virtual switch. Labeling virtual switches will indicate the function or the IP subnet of the virtual switch. For instance, labeling the virtual switch as “internal” or some variation will indicate that the switch is only for internal networking between virtual machines private virtual switch with no physical network adapters bound to it.System AdministratorInformation Assurance Officer[Virtual Server Administrator]
Checks: C-16103r1_chk

To check to see if virtual switches have labels, perform the following within VirtualCenter: 1. Log into VirtualCenter with the VI Client and select the ESX server from the inventory panel. The hardware configuration page for this server appears. 2. Click the Configuration tab, and click Networking. Ensure that all virtual switches have a label that does not start with a number. If the virtual switches begin with a number, this is a finding.

Fix: F-15766r1_fix

Do not begin virtual switch labels with a number.

c
The MAC Address Change Policy is set to “Accept” for virtual switches.
High - V-15815 - SV-16754r1_rule
RMF Control
Severity
High
CCI
Version
ESX0250
Vuln IDs
  • V-15815
Rule IDs
  • SV-16754r1_rule
Each virtual NIC in a virtual machine has an initial MAC address assigned when the virtual adapter is created. Each virtual adapter also has an effective MAC address that filters out incoming network traffic with a destination MAC address different from the effective MAC address. A virtual adapter’s effective MAC address and initial MAC address are the same when they are initially created. However, the virtual machine’s operating system may alter the effective MAC address to another value at any time. 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 adapter authorized by the receiving network. System administrators can use virtual switch security profiles on ESX Server hosts to protect against this type of attack by setting two options on the virtual switches. These options are MAC Address Changes and Forged Transmits. MAC address changes are set to accept by default meaning that the virtual switch accepts requests to change the effective MAC address. The MAC Address Changes option setting affects traffic received by a virtual machine. To protect against MAC impersonation this option will be set to reject, ensuring the virtual switch does not honor requests to change the effective MAC address to anything other than the initial MAC address. Setting this to reject disables the port that the virtual network adapter used to send the request. Therefore, the virtual network adapter does not receive any more frames until it configures the effective MAC address to match the initial MAC address. The guest operating system will not detect that the MAC address change has not been honored. System AdministratorInformation Assurance Officer[Virtual Server Administrator]
Checks: C-16105r1_chk

1. Log into VirtualCenter with the VI Client and select the ESX server from the inventory panel. The hardware configuration page for the server appears. 2. Click the Configuration tab, and click Networking. 3. Click Properties for the virtual switch whose layer 2 policy you want to review. 4. In the Properties dialog box for the virtual switch, click the Ports tab. 5. Select the virtual switch item and click Edit. 6. In the Properties dialog box for the virtual switch, click the Security tab. 7. Verify the MAC Address Changes is set to Reject. If it is not, this is a finding. Caveat: This is not applicable for legacy applications, clustered environments, and licensing issues if documented and approved by the IAO/SA.

Fix: F-15768r1_fix

Configure the MAC Address Changes Policy to “Reject”.

c
Forged Transmits are set to “Accept” on virtual switches
High - V-15817 - SV-16756r1_rule
RMF Control
Severity
High
CCI
Version
ESX0260
Vuln IDs
  • V-15817
Rule IDs
  • SV-16756r1_rule
Each virtual NIC in a virtual machine has an initial MAC address assigned when the virtual adapter is created. Each virtual adapter also has an effective MAC address that filters out incoming network traffic with a destination MAC address different from the effective MAC address. A virtual adapter’s effective MAC address and initial MAC address are the same when they are initially created. However, the virtual machine’s operating system may alter the effective MAC address to another value at any time. 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 adapter authorized by the receiving network. SAs can use virtual switch security profiles on ESX Server hosts to protect against this type of attack by setting two options on virtual switches. These options are MAC Address Changes and Forged Transmits. Forged transmissions are set to accept by default. This means the virtual switch does not compare the source and effective MAC addresses. The Forged Transmits option setting affects traffic transmitted from a virtual machine. If this option is set to reject, the virtual switch compares the source MAC address being transmitted by the operating system with the effective MAC address for its virtual network adapter to see if they are the same. If the MAC addresses are different, the virtual switch drops the frame. The guest operating system will not detect that its virtual network adapter cannot send packets using the different MAC address. To protect against MAC address impersonation, all virtual switches will have forged transmissions set to reject. System AdministratorInformation Assurance Officer[Virtual Server Administrator]
Checks: C-16107r1_chk

1. Log into VirtualCenter with the VI Client and select the ESX server from the inventory panel. The hardware configuration page for the server appears. 2. Click the Configuration tab, and click Networking. 3. Click Properties for the virtual switch whose layer 2 policy you want to review. 4. In the Properties dialog box for the virtual switch, click the Ports tab. 5. Select the virtual switch item and click Edit. 6. In the Properties dialog box for the virtual switch, click the Security tab. 7. Verify the Forged Transmits is set to Reject. If it is not, this is a finding.

Fix: F-15769r1_fix

Configure the Forged Transmits Policy to “Reject”.

c
Promiscuous Mode is set to “Accept” on virtual switches.
High - V-15818 - SV-16757r1_rule
RMF Control
Severity
High
CCI
Version
ESX0270
Vuln IDs
  • V-15818
Rule IDs
  • SV-16757r1_rule
ESX Server has the ability to run virtual and physical network adapters in promiscuous mode. Promiscuous mode may be enabled on public and private virtual switches. When promiscuous mode is enabled for a public virtual switch, all virtual machines connected to the public virtual switch have the potential of reading all packets sent across that network, from other virtual machines and any physical machines or other network devices. When promiscuous mode is enabled for a private virtual switch, all virtual machines connected to the private virtual switch have the potential of reading all packets across that network, meaning only the virtual machines connected to that private virtual switch. By default, promiscuous mode is set to Reject, meaning that the virtual network adapter cannot operate in Promiscuous mode. Promiscuous mode will be disabled on the ESX Server virtual switches since confidential data may be revealed while in this mode. Promiscuous mode is disabled by default on the ESX Server; however there might be a legitimate reason to enable it for debugging, monitoring, or troubleshooting reasons. To enable promiscuous mode for a virtual switch, a value is inserted into a special virtual file in the /proc file system. System AdministratorInformation Assurance Officer[Virtual Server Administrator]
Checks: C-16108r1_chk

1. Log into VirtualCenter with the VI Client and select the ESX server from the inventory panel. The hardware configuration page for the server appears. 2. Click the Configuration tab, and click Networking. 3. Click Properties for the virtual switch whose layer 2 policy you want to review. 4. In the Properties dialog box for the virtual switch, click the Ports tab. 5. Select the virtual switch item and click Edit. 6. In the Properties dialog box for the virtual switch, click the Security tab. 7. Verify the Promiscuous Mode is set to Reject. If it is not, this is a finding. Note: If promiscuous mode is turned on for troubleshooting purposes, then it must be documented and approved with the IAO/SA.

Fix: F-15770r1_fix

Configure the Promiscuous Mode Policy to “Reject".

b
VirtualCenter server is hosting other applications such as database servers, e-mail servers or clients, dhcp servers, web servers, etc.
Medium - V-15859 - SV-16800r1_rule
RMF Control
Severity
Medium
CCI
Version
ESX0600
Vuln IDs
  • V-15859
Rule IDs
  • SV-16800r1_rule
VirtualCenter availability is critical since it controls and manages the entire virtual infrastructure. ESX Server will still function without VirtualCenter, however, management of the virtual machines is lost. VirtualCenter should be installed on a dedicated physical server or virtual machine, since running multiple applications on a VirtualCenter server poses an availability risk. Application programs such as web servers, databases, or messaging systems require a significant number of installed programs, active processes, and privileged users defined. These applications may provide a simple means by which a privileged user unintentionally introduces malicious code. Therefore, VirtualCenter servers will only run those necessary applications that are required to run the VirtualCenter service. System AdministratorInformation Assurance Officer[Virtual Server Administrator]ECSC-1
Checks: C-16216r1_chk

On the VirtualCenter Server perform the following. 1. Go to Start>Programs>VMware 2. All VirtualCenter components should be listed under the VMware directory. The VMware Infrastructure Management default installation includes the following components: - VMware VirtualCenter Server – A Windows service to manage ESX Server hosts. - VI Client – A client application used to connect directly to an ESX Server or indirectly to an ESX Server through a VirtualCenter Server. - Microsoft.NET Framework – Software that the VirtualCenter Server, the Database Upgrade wizard, and VI Client users. - Microsoft or Oracle Database - VMware license server – A Windows service allowing all VMware products to be licensed from a central pool and managed from one console. - VMware Update Manager (Optional) – A VirtualCenter plugin that provides security monitoring and patching support for ESX Server hosts and virtual machines. - VMware Converter Enterprise for VirtualCenter (Optional) – A VirtualCenter plugin that enables the conversion of physical machines to virtual machines. - 3. Next go to Start> Programs> 4. Review all the progams listed to ensure no email servers, office programs, messaging programs, etc. are installed. If so ask the IAO/SA what they are for. If they are unrelated to the VirtualCenter Server, this is a finding.

Fix: F-15819r1_fix

Run only the necessary applications for VirtualCenter.

b
Patches and security updates are not current on the VirtualCenter Server.
Medium - V-15860 - SV-16801r1_rule
RMF Control
Severity
Medium
CCI
Version
ESX0610
Vuln IDs
  • V-15860
Rule IDs
  • SV-16801r1_rule
Organizations need to stay current with all applicable VirtualCenter Server software updates that are released from VMware. If updates and patches are not installed, then security vulnerabilities may be open. Open vulnerabilities may provide an access point for an attacker to use to gain access to the system.System AdministratorInformation Assurance Officer[Virtual Server Administrator]
Checks: C-16217r1_chk

Go to the VirtualCenter Server and perform the following. 1. Login to the VirtualCenter Server with the VI Client. 2. At the top of the menu select Help>About Virtual Infrastructure. 3. Review the Virtual Infrastructure Version and Build number and compare it the latest patches listed below. If Internet access is available, the reviewer should check for the latest patches on VMware’s website to verify the VirtualCenter patches have not been updated recently. The website location is http://www.vmware.com/download/vi/. If the version build number is older than the listed ones below, this is a finding. If the version is not listed or is older than version 2.0.1, this is a finding as well. VMware VirtualCenter 2.5 Latest Version: 2.5 | 7/10/2009 | Build:174768 VMware VirtualCenter 2.0.2 Update 3 Version: 2.0.2 Update 3 | 2/15/2008 | Build: 75762 VMware VirtualCenter 2.0.2 Update 2 Version: 2.0.2 Update 2 | 11/8/2007 | Build: 62327 VMware VirtualCenter 2.0.2 Update 1 Version: 2.0.2 Update 1 | 10/29/2007 | Build: 61426 – End of support 11/08/2008 VMware VirtualCenter 2.0.2 Version: 2.0.2 | 7/19/2007 | Build: 50618 – End of support 10/29/2008 VMware VirtualCenter 2.0.1 Version: 2.0.1 | 10/02/2006 | Build: 32042 – End of support 7/19/2008

Fix: F-15820r1_fix

Apply all the latest patches to VirtualCenter.

b
VirtualCenter virtual machine is not configured in an ESX Server cluster with High Availability enabled.
Medium - V-15864 - SV-16805r1_rule
RMF Control
Severity
Medium
CCI
Version
ESX0650
Vuln IDs
  • V-15864
Rule IDs
  • SV-16805r1_rule
If the ESX Server hosting the VirtualCenter virtual machine fails, the single point of central administration to the entire virtual infrastructure is gone. To mitigate this potential scenario, High Availability (HA) will be configured through VMware HA. If one ESX Server host fails within a VMware HA cluster, another ESX Server will restart the VirtualCenter virtual machine. System AdministratorInformation Assurance Officer[Virtual Server Administrator]
Checks: C-16221r1_chk

1. Log into the VirtualCenter Server with the VI Client. 2. Verify that there is a cluster configured by reviewing the inventory panel. If no cluster is configured, this is a finding. 3. Select the cluster and choose Edit Settings from the right-click menu. 4. In the Cluster Settings dialog box, verify Enable VMware HA is selected. If it is not selected, this is a finding.

Fix: F-15824r1_fix

Enable High Availability on ESX Server clusters for all VirtualCenter virtual machines.

b
VirtualCenter virtual machine does not have a CPU reservation.
Medium - V-15865 - SV-16806r1_rule
RMF Control
Severity
Medium
CCI
Version
ESX0660
Vuln IDs
  • V-15865
Rule IDs
  • SV-16806r1_rule
Virtual machine settings affect the availability of the VirtualCenter virtual machine as well. If the virtual machine is not configured with resource reservations, there is no guarantee that the resources will be available. System AdministratorInformation Assurance Officer[Virtual Server Administrator]ECSC-1
Checks: C-16222r1_chk

1. Log into VirtualCenter with the VI Client. 2. In the Inventory panel on the left, select the host that has the VirtualCenter virtual machine. 3. Select the Resource Allocation Tab and view the reservation for the virtual machine CPU. Under View: Select CPU. 4. If the virtual machine reservation says 0, this is a finding.

Fix: F-15825r1_fix

Reserve CPU resources for the VirtualCenter virtual machine.

b
VirtualCenter virtual machine does not have a memory reservation.
Medium - V-15866 - SV-16807r1_rule
RMF Control
Severity
Medium
CCI
Version
ESX0670
Vuln IDs
  • V-15866
Rule IDs
  • SV-16807r1_rule
Virtual machine settings affect the availability of the VirtualCenter virtual machine as well. If the virtual machine is not configured with resource reservations, there is no guarantee that the resources will be available. System AdministratorInformation Assurance Officer[Virtual Server Administrator]ECSC-1
Checks: C-16223r1_chk

1. Log into VirtualCenter with the VI Client. 2. In the Inventory panel on the left, select the host that has the VirtualCenter virtual machine. 3. Select the Resource Allocation Tab and view the reservation for the virtual machine Memory. Under View: Select Memory. 4. If the virtual machine reservation says 0, this is a finding.

Fix: F-15826r1_fix

Reserve Memory resources for the VirtualCenter virtual machine.

a
VirtualCenter virtual machine CPU alarm is not configured.
Low - V-15867 - SV-16808r1_rule
RMF Control
Severity
Low
CCI
Version
ESX0680
Vuln IDs
  • V-15867
Rule IDs
  • SV-16808r1_rule
To ensure that system administrators are notified if there is a resource problem on the VirtualCenter virtual machine, alarms should be configured to email the administrator. If alarms are not configured, system administrators will not be aware of any resource issues. If resources are unavailable on the VirtualCenter virtual machine, scheduled tasks may not be performed, and the potential denial of service on the VirtualCenter virtual machine.System AdministratorInformation Assurance Officer[Virtual Server Administrator]
Checks: C-16224r1_chk

1. Log into VirtualCenter with the VI Client. 2. In the Inventory panel on the left, select the host that has the VirtualCenter virtual machine. 3. Click the Alarms tab. 4. To view alarms that have been defined, click Definitions. A list of defined alarms appears. Double click an alarm definition to display Alarm settings dialog box and view. If no Alarm exists that notifies the administrator when the VirtualCenter virtual machine CPU hits 90%, this is a finding.

Fix: F-15827r1_fix

Configure an alarm to notify the administrator when the VirtualCenter CPU hits 90%.

a
VirtualCenter virtual machine memory alarm is not configured.
Low - V-15868 - SV-16809r1_rule
RMF Control
Severity
Low
CCI
Version
ESX0690
Vuln IDs
  • V-15868
Rule IDs
  • SV-16809r1_rule
To ensure that system administrators are notified if there is a resource problem on the VirtualCenter virtual machine, alarms should be configured to email the administrator. If alarms are not configured, system administrators will not be aware of any resource issues. If resources are unavailable on the VirtualCenter virtual machine, scheduled tasks may not be performed, and the potential denial of service on the VirtualCenter virtual machine.System AdministratorInformation Assurance Officer[Virtual Server Administrator]
Checks: C-16225r1_chk

1. Log into VirtualCenter with the VI Client. 2. In the Inventory panel on the left, select the host that has the VirtualCenter virtual machine. 3. Click the Alarms tab. 4. To view alarms that have been defined, click Definitions. A list of defined alarms appears. Double click an alarm definition to display Alarm settings dialog box and view. If no Alarm exists that notifies the administrator when the VirtualCenter virtual machine Memory hits 90%, this is a finding.

Fix: F-15828r1_fix

Configure an alarm to notify the administrator when the VirtualCenter Memory hits 90%.

b
Unauthorized users have access to the VirtualCenter virtual machine.
Medium - V-15869 - SV-16810r1_rule
RMF Control
Severity
Medium
CCI
Version
ESX0700
Vuln IDs
  • V-15869
Rule IDs
  • SV-16810r1_rule
Virtual machines may be accessed by anyone with the proper permissions. If the VirtualCenter virtual machine is accessed by a normal virtual machine user, specific settings in the virtual infrastructure may be changed or modified. Modifications may include permissions, object groupings, installing malicious software, etc. To mitigate this, access to the VirtualCenter virtual machine will be restricted to only authorized users. System AdministratorInformation Assurance Officer[Virtual Server Administrator]
Checks: C-16226r1_chk

1. Request a copy of the authorized VirtualCenter administrator user documentation. If no documentation exists, this is a finding. 2. Log into the VI Client as a user with Administrator privileges. Work with the system administrator to access the system with these privileges. 3. In the Inventory panel on the left, select the VirtualCenter virtual machine. 4. Click the Permissions tab. 5. Review the permissions and verify that they match the documentation provided. If there is a discrepancy, this is a finding.

Fix: F-15829r1_fix

Restrict access to the VirtualCenter virtual machine to only authorized users.

b
No dedicated VirtualCenter administrator created within the Windows Administrator Group on the Windows Server for managing the VirtualCenter environment.
Medium - V-15870 - SV-16811r1_rule
RMF Control
Severity
Medium
CCI
Version
ESX0710
Vuln IDs
  • V-15870
Rule IDs
  • SV-16811r1_rule
By default, the local administrator or domain administrator is allowed to log on to VirtualCenter. These administrators are allowed since VirtualCenter requires a user with local administrator privileges to run. To limit the local administrative access, a dedicated VirtualCenter account will be created. This VirtualCenter account is an ordinary user that is a member of the local administrators group. This configuration avoids automatically giving administrative access to domain administrators, who typically belong to the local administrators group. This also provides a way of getting into VirtualCenter when the domain controller is down, because the local VirtualCenter administrator account does not require remote authentication.System AdministratorInformation Assurance Officer[Virtual Server Administrator]ECCD-1, ECCD-2
Checks: C-16227r1_chk

1. On the VirtualCenter Server, go to Start>Administrative Tools>Computer Management>Local Users and Groups>Groups 2. Open the Administrators group. 3. Verify that a VirtualCenter administrator is listed. Work with the system administrator to identify the user. If no VirtualCenter administrator is listed, this is a finding.

Fix: F-15830r1_fix

Create a VirtualCenter administrator user in the Windows Administrator Group.

b
No logon warning banner is configured for VirtualCenter users.
Medium - V-15871 - SV-16812r1_rule
RMF Control
Severity
Medium
CCI
Version
ESX0720
Vuln IDs
  • V-15871
Rule IDs
  • SV-16812r1_rule
Once users are authenticated by VirtualCenter, users should be presented with a warning message. presenting a warning message prior to user logon may assist the prosecution of trespassers on the computer system. Guidelines published by the US Department of Defense require that warning messages include at least the name of the organization that owns the system, the system is subject to monitoring and that such monitoring is in compliance with local statutes, and that use of the system implies consent to such monitoring.System AdministratorInformation Assurance Officer[Virtual Server Administrator]
Checks: C-16228r1_chk

1. Log into VirtualCenter with the VI Client. 2. Select the Administration Menu at the top of the page. 3. Select the Edit Message of the Day. 4. Review the contents and verify the following are listed: You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only. By using this IS (which includes any device attached to this IS), you consent to the following conditions: -The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations. -At any time, the USG may inspect and seize data stored on this IS. -Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USGauthorized purpose. -This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy. -Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content ofprivileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details. OK OR I've read & consent to terms in IS user agreem't. If the banner does not contain these items, this is a finding.

Fix: F-15831r1_fix

Configure a logon banner in VirtualCenter.

b
VI Client sessions with VirtualCenter are unencrypted.
Medium - V-15872 - SV-16813r1_rule
RMF Control
Severity
Medium
CCI
Version
ESX0730
Vuln IDs
  • V-15872
Rule IDs
  • SV-16813r1_rule
User sessions with VirtualCenter should be encrypted since transmitting data in plaintext may be viewed as it travels through the network. User sessions may be initiated from the VI client and VI Web Access. To encrypt session data, the sending component, such as a gateway or redirector, applies ciphers to alter the data before transmitting it. The receiving component uses a key to decrypt the data, returning it to its original form. To ensure the protection of the data transmitted to and from external network connections, all VI client and web access sessions with VirtualCenter will be encrypted with a FIPS 140-2 encryption algorithm.System AdministratorInformation Assurance Officer[Virtual Server Administrator]
Checks: C-16229r1_chk

1. On the VirtualCenter Server go to Start> Program Files>VMware>Infrastructure>Virtual Infrastructure Client>Launcher. 2. Open the VpxClient.exe.config file with Notepad. 3. Verify https:443 is configured. (appSettings) (add key = “protocolports” value = “https:443”/) (/appSettings) If this setting is not set, this is a finding.

Fix: F-15832r1_fix

Encrypt all VI Client sessions to the VirtualCenter Server.

b
VI Web Access sessions with VirtualCenter are unencrypted.
Medium - V-15873 - SV-16814r1_rule
RMF Control
Severity
Medium
CCI
Version
ESX0740
Vuln IDs
  • V-15873
Rule IDs
  • SV-16814r1_rule
User sessions with VirtualCenter should be encrypted since transmitting data in plaintext may be viewed as it travels through the network. User sessions may be initiated from the VI client and VI Web Access. To encrypt session data, the sending component, such as a gateway or redirector, applies ciphers to alter the data before transmitting it. The receiving component uses a key to decrypt the data, returning it to its original form. To ensure the protection of the data transmitted to and from external network connections, all VI client and web access sessions with VirtualCenter will be encrypted with a FIPS 140-2 encryption algorithm.System AdministratorInformation Assurance Officer[Virtual Server Administrator]ECCT-1, ECCT-2
Checks: C-16230r1_chk

1. Login to VirtualCenter through the VI Client. 2. Select an ESX Server host from the inventory panel. 3. Select the configuration tab. 4. Select advanced settings in the software section. 5. Verify the “Config.Defaults.security.host.ruissl” is checked. This requires SSL to be used when communicating with the host over 902. If this is not checked, this is a finding.

Fix: F-15833r1_fix

Encrypt all VI Web Access sessions with VirtualCenter.

b
VirtualCenter does not log user, group, permission or role changes.
Medium - V-15880 - SV-16821r1_rule
RMF Control
Severity
Medium
CCI
Version
ESX0810
Vuln IDs
  • V-15880
Rule IDs
  • SV-16821r1_rule
VirtualCenter Servers not configured to log user, group, permission and role changes will not have the ability to review past system and user events. Recording these events is critical to establishing a recorded history of system events, enabling system administrators to diagnose intermittent system problems, suspicious user activity, and assisting with investigations. Log events also verify that the established policies configured on the system are in fact working as configured.System AdministratorInformation Assurance Officer[Virtual Server Administrator]ECAR-1, ECAR-2, ECAR-3
Checks: C-16239r1_chk

1. Log into VirtualCenter with the VI Client. 2. Select the Administration Menu at the top of the page. 3. Select VirtualCenter Management Server Configuration. 4. Select Logging Options. 5. Verify that VirtualCenter Logging is configured to Info(Normal Logging) or higher (Verbose or Trivia)

Fix: F-15840r1_fix

Configure VirtualCenter Logging to Info or higher.

b
Nonpersistent disk mode is set for virtual machines.
Medium - V-15890 - SV-16831r1_rule
RMF Control
Severity
Medium
CCI
Version
ESX0940
Vuln IDs
  • V-15890
Rule IDs
  • SV-16831r1_rule
The security issue with nonpersistent disk mode is that attackers may undo or remove any traces that they were ever on the machine with a simple shutdown or reboot. Once the virtual machine has been shutdown, the vulnerability used to access the virtual machine will still be present, and the attacker may access the virtual machine in the future at a point in time of their choice. The danger is that administrators may never know if they have been attacked or hacked. To safeguard against this, nonpersistent disk mode will be only used for test and development virtual machines. Production virtual machines will be set to persistent disk mode only.System AdministratorInformation Assurance Officer[Virtual Machine Administrator]
Checks: C-16249r1_chk

Pick one or two virtual machines to verify for compliance. 1. Log into the VirtualCenter Server with the VI Client and select the server from the inventory panel. The hardware configuration page for the server appears. 2. Expand the inventory as needed, and select the virtual machine that you would like to check. 3. Click the Edit Settings link in the Commands panel to display the Virtual Machine Properties dialog box. 4. Select the Hardware tab. 5. Click the appropriate Hard Disk in Hardware list, and verify that Nonpersistent mode is not selected. If nonpersistent mode is selected, this is a finding. Caveat: Nonpersistent disk mode may be used if it has been documented and approved by the DAA.

Fix: F-15850r1_fix

Configure all virtual machines to use persistent disk mode only, which is the default.

b
Clipboard capabilities (copy and paste) are enabled for virtual machines.
Medium - V-15893 - SV-16834r1_rule
RMF Control
Severity
Medium
CCI
Version
ESX0970
Vuln IDs
  • V-15893
Rule IDs
  • SV-16834r1_rule
Several security issues arise with the clipboard. The first is that the system administrator might turn on the clipboard transfer and use it. However, deselecting the clipboard check box will not turn off the function, since a reboot is required. So, the clipboard function is still active. Therefore, transferring text objects, such as a password from one clipboard to another, in any direction between the virtual machine and the host operating system is possible. Secondly, this breaks the virtual machine isolation. This may cause information leakage and potentially infect other operating systems if the text is a string that can be run as a command or URL. As a result of these behaviors, all clipboard capabilities should be disabled within the virtual machine.System AdministratorInformation Assurance Officer[Virtual Machine Administrator]ECSC-1
Checks: C-16252r1_chk

1. Login to VirtualCenter with the VI Client and select a virtual machine from the inventory panel. The configuration page for the virtual machine appears with the Summary tab displayed. 2. Click Edit Settings. 3. Click Options > Advanced > Configuration Parameters to open the Configuration Parameters dialog box. 4. The result should appear as follows: Isolation.tools.copy.disable true Isolation.tools.paste.disable true Isolation tools.setGUIOptions.enable false If these are not configured, this is a finding.

Fix: F-15853r1_fix

Disable the clipboard capabilities in all virtual machines.

b
VMware Tools drag and drop capabilities are enabled for virtual machines.
Medium - V-15894 - SV-16836r1_rule
RMF Control
Severity
Medium
CCI
Version
ESX0980
Vuln IDs
  • V-15894
Rule IDs
  • SV-16836r1_rule
The drag and drop operation may be used to transfer files from the guest virtual machine to the computer connecting to the virtual machine via the VI Console. Files may be moved from the guest virtual machine to the VI Console computer through the drag and drop functionality. This functionality has several potential damaging consequences. The file moved to the VI Console computer may be so large that it fills the hard disk on the system, may contain sensitive information, or may contain malicious code. These scenarios could potentially cause a denial of service to the VI Console computer, expose sensitive information to unauthorized users, or run malicious code. System AdministratorInformation Assurance Officer[Virtual Machine Administrator]
Checks: C-16254r1_chk

1. Login to VirtualCenter with the VI Client and select a virtual machine from the inventory panel. The configuration page for the virtual machine appears with the Summary tab displayed. 3. Click Options > Advanced > Configuration Parameters to open the Configuration Parameters dialog box. 4. Verify the following is displayed in the result: isolation.tools.dnd.disable true If this is not present, this is a finding.

Fix: F-15855r1_fix

Disable drag and drop in VMware Tools.

b
The VMware Tools setinfo variable is enabled for virtual machines.
Medium - V-15895 - SV-16837r1_rule
RMF Control
Severity
Medium
CCI
Version
ESX0990
Vuln IDs
  • V-15895
Rule IDs
  • SV-16837r1_rule
The virtual machine operating system sends informational messages to the ESX Server host through VMware Tools. These messages are setinfo messages and typically contain name-value pairs that define virtual machine characteristics or identifiers that the ESX Server stores. For instance, a setinfo message may be ipaddress=10.10.15.224. A setinfo message has fixed formats and lengths. Therefore, the amount of data passed to the ESX Server this way is limited. However, the data flow provides an opportunity for an attacker to stage a DoS attack by writing software that mimics VMware Tools by flooding the ESX Server with packets, and consuming resources needed by virtual machines. To mitigate this, the virtual machine administrator should disable the setinfo variable. This will prevent the guest operating system processes from sending messages to the ESX Server.System AdministratorInformation Assurance Officer[Virtual Machine Administrator]ECSC-1
Checks: C-16255r1_chk

1. Login to VirtualCenter with the VI Client and select a virtual machine from the inventory panel. The configuration page for the virtual machine appears with the Summary tab displayed. 3. Click Options > Advanced > Configuration Parameters to open the Configuration Parameters dialog box. 4. The result should appear as follows: isolation.tools.setinfo.disable true If the isolation.tools.setinfo.disable is not configured to true, this is a finding.

Fix: F-15856r1_fix

Disable the setinfo variable.

a
Configuration tools are enabled for virtual machines.
Low - V-15896 - SV-16838r1_rule
RMF Control
Severity
Low
CCI
Version
ESX1000
Vuln IDs
  • V-15896
Rule IDs
  • SV-16838r1_rule
There are other settings that should be specified in the configuration files for virtual machines. The connectable setting disables connecting and disconnecting removable devices from within the virtual machine. The diskShrink setting shrinks the virtual disk. The diskWiper defragments virtual disks. These last two settings could effectively cause a DoS by having the virtual disk defragmented and shrunk on demand. The commands that should be disabled are listed: isolation.device.connectable.disable = “TRUE” isolation.tools.diskShrink.disable = “TRUE” isolation.tools.diskWiper.disable = “TRUE” System AdministratorInformation Assurance Officer[Virtual Machine Administrator]ECSC-1
Checks: C-16256r1_chk

1. Login to VirtualCenter with the VI Client and select a virtual machine from the inventory panel. The configuration page for the virtual machine appears with the Summary tab displayed. 3. Click Options > Advanced > Configuration Parameters to open the Configuration Parameters dialog box. 4. Verify the following is displayed in the result: isolation.device.connectable.disable true isolation.tools.diskShrink.disable true isolation.tools.diskWiper.disable true If these are not configured, this is a finding.

Fix: F-15857r1_fix

Disable configuration tools for the virtual machine.

b
Virtual machines are not time synchronized with the ESX Server or an authoritative time server.
Medium - V-15897 - SV-16839r1_rule
RMF Control
Severity
Medium
CCI
Version
ESX1010
Vuln IDs
  • V-15897
Rule IDs
  • SV-16839r1_rule
The accuracy of time within the virtualization environment is difficult due to the timer interrupt issue. Time drifts may be as dramatic as 5-10 minutes. Inaccurate time causes other inaccuracies within the virtualization environment, which may include event logs, domain synchronization, session timeouts, etc. Virtual machine time synchronization may be achieved through an external time source or through the ESX Server operating system. System AdministratorInformation Assurance Officer[Virtual Machine Administrator]ECSC-1
Checks: C-16257r1_chk

1. Ask the IAO/SA how virtual machines are time synchronized. If they synchronized to an external server, then go to step 2. If configured to the ESX Server host, go to step 3. 2. Time servers are configured in the /etc/ntp.conf file on UNIX systems. Once they are configured with an atomic clock, the ntpd daemon should be configured to start at the runlevels 3, 4, and 5. Windows servers are configured via the command line using the net time /setsntp:clock.isc.org. The w32time service will need to be configured to start after the change. Unix Systems: # less /etc/ntp.conf Verify a valid time server is listed. If not, this is a finding. Windows systems: Start, run, cmd C:\>net time /querysntp If no results are displayed to use a valid SNTP server, this is a finding. 3. Login to VirtualCenter with the VI Client and select a virtual machine from the Inventory panel. 4. Click the Edit Settings link in the Commands panel. The Virtual Machine Properties dialog box is displayed. Select the Options tab. 5. Select VMware Tools in the Settings list. 6. Verify the guest operating system is configured to synchronize time with the host ESX Server. This is enabled when the “Synchronize guest time with host” option is checked. If it is not checked, then this is a finding.

Fix: F-15858r1_fix

Synchronize the virtual machine with an external time source or the ESX Server host.

b
Test and development virtual machines are not logically separated from production virtual machines.
Medium - V-15899 - SV-16841r1_rule
RMF Control
Severity
Medium
CCI
Version
ESX1030
Vuln IDs
  • V-15899
Rule IDs
  • SV-16841r1_rule
Test and development can be defined by using the folllowing definitions from the Enclave STIG. Testing is a process of technical investigation intended to reveal quality-related information about the product with respect to the context in which it is intended to operate. This includes, but is not limited to, the process of executing a program or application with the intent of finding errors. Development is the process by which something passes by degrees to a different stage. Test and development virtual machines will be logically separated from the production virtual machines. Logically separating test and development virtual machines ensures that any test and development traffic does not traverse the production LAN. This separation applies to Zone A and B only as referenced the Enclave STIG. Zone C and D should be completely isolated from any production network. This traffic separation will enhance the availability of the production servers. The preferred logical configuration is for the test and development VLAN to be assigned a dedicated physical network adapter on the ESX Server. If this is not feasible, then a separate VLAN on the production physical network adapter is acceptable. System AdministratorInformation Assurance Officer[Virtual Machine Administrator]
Checks: C-16259r1_chk

Ask the IAO/SA if test and development virtual machines are are configured on the same ESX Server farm as production virtual machines. If the answer is "No", then this is not applicable. If the answer is "Yes", then ask what type of zone the test and development virtual machines are in? If they are in Zone A or B, then proceed to step 1. If they are in Zone C or D, this is a finding. 1. Log into VirtualCenter with the VI Client and select the server from the inventory panel. The hardware configuration page for this server appears. 2. Click the Configuration tab, and click Networking. 3. Examine the virtual switches and their respective VLAN IDs. A separate and dedicated VLAN ID should be configured for test and development virtual machines. If there is no VLAN ID defined for test and development virtual machines, this is a finding.

Fix: F-15860r1_fix

Assign a dedicated VLAN ID for all test and development virtual machines in Zone A and B as referenced in the Enclave STIG.

b
VirtualCenter Server assets are not properly registered in VMS.
Medium - V-15975 - SV-16917r1_rule
RMF Control
Severity
Medium
CCI
Version
ESX0869
Vuln IDs
  • V-15975
Rule IDs
  • SV-16917r1_rule
The Vulnerability Management System (VMS) was developed to interface with the DoD Enterprise tools to assist all DoD CC/S/As in the identification of security vulnerabilities and track the issues through the lifecycle of the vulnerabilities existence. To ensure both the emerging and known vulnerabilities are addressed on a system, VMS tracks the existence of all potential vulnerabilities based on the posture of an asset. As a result, all vulnerabilities are tracked through their lifecycle. Vulnerability Management is the process of ensuring that all network assets that are affected by an IAVM notice are addressed and corrected within a time period specified in the IAVM notice. VMS will notify commands, services, and agencies of new and potential security vulnerabilities. VMS meets the DoD mandate to ensure information system vulnerability alert notifications are received and acted on by all SAs. Keeping the inventory of assets current allows for tracking of virtualization servers and resources, and supports a successful IAVM process. The ability to track assets improves the effective use of virtualization assets, information assurance auditing efforts, as well as optimizing incident response times. System AdministratorInformation Assurance Officer[Virtual Server Administrator]VIVM-1
Checks: C-16606r1_chk

Use VMS and navigate to the site’s assets. Ensure the VirtualCenter Server(s) are registered within VMS. If they are not registered, this is a finding.

Fix: F-15974r1_fix

Register VirtualCenter Servers in VMS.

b
VirtualCenter Server assets are not configured with the correct posture in VMS.
Medium - V-15984 - SV-16926r1_rule
RMF Control
Severity
Medium
CCI
Version
ESX0872
Vuln IDs
  • V-15984
Rule IDs
  • SV-16926r1_rule
Correctly configuring the VirtualCenter Server asset in VMS will ensure that the appropriate vulnerabilities are assigned to the asset. If the asset is not configured with the correct posture, vulnerabilities may be open on the asset. These open vulnerabilities may allow an attacker to access the system. System AdministratorInformation Assurance Officer[Virtual Server Administrator]VIVM-1
Checks: C-16618r1_chk

If check ESX0869 is a finding, this should be marked a finding also. If the assets are registered, verify that the following postures are registered. The database may be SQL or Oracle. Use the appropriate database entry when applying the posture for the database. If any of the postures are not registered this is a finding. For instance, the SQL Server 2005 posture will look as follows: Win2k3 Database SQL Server Installation 2005 Database SQL Server Database 2005 – Model Database SQL Server Database 2005 – Master Database SQL Server Database 2005 – MSDB Database SQL Server Database 2005 – TempDB Database SQL Server Database 2005 – VCDB Antivirus Tomcat 5.x VirtualCenter

Fix: F-15975r1_fix

Register VirtualCenter Server with the correct posture in VMS.

b
VirtualCenter is not using DoD approved certificates.
Medium - V-17020 - SV-18021r1_rule
RMF Control
Severity
Medium
CCI
Version
ESX0725
Vuln IDs
  • V-17020
Rule IDs
  • SV-18021r1_rule
User sessions with VirtualCenter should be encrypted since transmitting data in plaintext may be viewed as it travels through the network. User sessions may be initiated from the VI client and VI Web Access. To encrypt session data, the sending component, such as a gateway or redirector, applies ciphers to alter the data before transmitting it. The receiving component uses a key to decrypt the data, returning it to its original form. To ensure the protection of the data transmitted to and from external network connections, all VI client and web access sessions with VirtualCenter will be encrypted with a FIPS 140-2 encryption algorithm.System AdministratorInformation Assurance Officer[Virtual Server Administrator]
Checks: C-17720r1_chk

1. Go to the following location to review the certificates on the VirtualCenter Server. C:\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter\SSL\ If no valid DoD certificate and private key are present here, this is a finding. This directory should contain a DoD certificate and key only (server.crt and server.key). Validate the certificate is listed in the InstallRoot3.12_SAG.pdf document. The DoD certificates that are listed in the InstallRoot3.12_SAG.pdf document are listed in Section 1, Appendix B. If the certificate is not listed here, this is a finding. Note: The InstallRoot3.12_SAG.pdf document may have been replaced with a newer version. If so, use the most current version listed on the DoD PKE site. Note: The InstallRoot3.12 _SAG.pdf document can be downloaded from the following links: (Note: These links may have changed since the release of the checklist.) https://www.us.army.mil/suite/page/474113 OR https://www.us.army.mil/suite/portal/index.jsp. Select Files and search for the InstallRoot folder. Select the InstallRoot folder and select the InstallRoot3.12_SAG.pdf document to download.

Fix: F-16829r1_fix

Employ signed DoD certificates on VirtualCenter. To create SSL/TLS certificates, the server administrator should use the site certificate ordering processes to obtain DoD PKI certficiates. Typically, the system administrator must use the Web Server or Web Server operating system tools as appropriate to generate the Public Key Cryptography Standard (PKCS) #10 certificate request. However, the following programs may be used to create and retrieve the signed certificate. 1. Serveral programs are needed to create the openssl certificates. These include Activestate Perl, openssl for Win32, and Visual C++ 2008 Redistribute. To get these programs go to the following websites and download them: Note: These URL links may have changed since the release of the checklist. a. Activestate Perl - Use http://www.activestate.com/activeperl/ and click on "ActivePerl Download Now". b. Openssl for Win32 – Use http://www.slproweb.com/products.htm c. Visual C++ 2008 Redistribute - Use http://www.microsoft.com/downloads/details.aspx?familyid=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en 2. Navigate to the OpenSSL directory (c:\openssl\bin\) on the VirtualCenter Server. 3. Generate the RSA key for the server and the certificate signing request (CSR): openssl req -new -out filename.csr When prompted enter the following: (Do not type the quotations) For Country Name, type “US” For State or Province Name, type “.” For Locality Name, type “.” For Organization Name, type “U.S. Government” For Organizational Unit Name, type “OU=DISA, OU=PKI, OU=DoD” For Common Name, type your Fully Qualified Domain Name of your server (i.e. server.disa.mil) For Email Address, type your email address 4. The output from this command will yield two files: filename.csr and privkey.pem 5. Upload/Copy the filename.csr to the Regular SSL Server Enrollment Form for the DoD PKI site. You may use either of the two sites below. Note: These Certificate Authorities may have been decommissioned since the release of the checklist. If so, please use the most current Certificate Authority for enrolling your certificate request. CA-17 URL - https://ca-17.c3pki.chamb.disa.mil/ca CA-18 URL - https://ca-18.c3pki.den.disa.mil/ca 6. You will be emailed that your certificate is ready and you will retrieve your signed certificate from the CA. 7. In addition, you must create a PFX-formatted certificate file specific for Windows. The filename.pfx file is a concatenation of the server’s certificate and private key, exported in the PFX format; this file is then copied to the sub-directory on the VirtualCenter Server. Perform the following command: (filename is the name of your certificate file) C:\openssl\bin\Openssl pkcs12 –export in filename.crt –inkey privkey.pem –name filename –passout pass:testpassword –out filename.pfx 8. Put the new signed certificate, private key, and filename.pfx in the C:\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter\SSL\ directory. Move the old certificates from the directory and put them somewhere safe for backup purposes.

c
VMware ESX management software that is no longer supported by the vendor for security updates must not be installed on a system.
High - V-68725 - SV-83303r1_rule
RMF Control
Severity
High
CCI
Version
ESX0005
Vuln IDs
  • V-68725
Rule IDs
  • SV-83303r1_rule
VMware ESX operating systems, virtual machines, and associated management software that are no longer supported by VMware for security updates are not evaluated or updated for vulnerabilities leaving them open to potential attack. Organizations must transition to a supported ESXi operating system, virtual machines, and associated management software to ensure continued support.
Checks: C-69217r1_chk

VMware support for ESX versions 3 and 4 ended 21 May 2016. If ESX version 3 or 4 management software, such as VirtualCenter or vCenter, is installed on a system, this is a finding.

Fix: F-74847r2_fix

Upgrade ESX version 3 and 4 management software to supported versions.