VMware ESX 3 Virtual Center

41procedures

Search filters the loaded procedure list locally. Separate terms must all match (use quotes for an exact phrase). Cached STIG Search results apply when you arrive from Search.

Severity
CurrentPublished Fri Jul 22 2016
Objective ID
Severity
Discussion
V-15785
medium
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.
V-15786
medium
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.
V-15788
medium
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.
V-15789
medium
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."
V-15792
medium
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.
V-15802
medium
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.
V-15803
low
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.
V-15806
medium
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.
V-15807
medium
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.
V-15808
medium
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.
V-15809
medium
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.
V-15810
medium
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.
V-15812
medium
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.
V-15813
medium
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.
V-15815
high
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.
V-15817
high
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.
V-15818
high
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.
V-15859
medium
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.
V-15860
medium
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.
V-15864
medium
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.
V-15865
medium
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.
V-15866
medium
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.
V-15867
low
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.
V-15868
low
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.
V-15869
medium
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.
V-15870
medium
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.
V-15871
medium
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.
V-15872
medium
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.
V-15873
medium
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.
V-15880
medium
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.
V-15890
medium
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.
V-15893
medium
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.
V-15894
medium
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.
V-15895
medium
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.
V-15896
low
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"
V-15897
medium
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.
V-15899
medium
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.
V-15975
medium
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.
V-15984
medium
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.
V-17020
medium
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.
V-68725
high
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.