Knowledge Base

The VMware Knowledge Base provides support solutions, error messages and troubleshooting guides
 
Search the VMware Knowledge Base (KB)   View by Article ID
 

Advanced GSX Server Security Recommendations (1042)

Details

How can I improve security for my GSX Server host and the virtual machines I run on it?

Solution

Below are some suggestions on how to improve security for your GSX Server host and virtual machines.

Preventing a Virtual Machine from Impersonating Another Virtual Machine's Network Identity

As is the case with physical network adapters, a virtual network adapter is able to impersonate another network adapter, to either send network packets as if it were the actual source of the traffic and to receive network packets destined for the impersonated adapter.

Note: There are legitimate situations where you would want more than one adapter to have the same MAC address on a network. One such situation is if you are using Microsoft Network Load Balancing.

Unlike the case with physical adapters, GSX Server or ESX Server can prevent virtual network adapters from impersonating other virtual network adapters. GSX Server and ESX Server do this without the awareness of the guest operating system responsible for the impersonation.

Each network adapter (whether virtual or physical) has its own MAC address. A virtual network adapter's MAC address is assigned to the virtual machine when it is created. This MAC address is called the initial MAC address.

Each network adapter has an effective MAC address that filters out incoming network traffic with a destination MAC address different from the effective MAC address. The effective MAC address of the adapter is initially the same as the initial MAC address, but the guest operating system can change the adapter's effective MAC address to another value at any time.

When an operating system sends information over the network, it places its network adapter's initial MAC address in the source MAC address field of the Ethernet frame and places the destination MAC address — the MAC address for the network adapter that is the intended recipient — into the destination MAC address field. A network adapter accepts network packets when its effective MAC address matches the destination MAC address in a network packet.

The effective MAC address can be changed by an operating system to allow the network adapter to impersonate another adapter on the network. However, the initial MAC address is static. If an operating system changes the effective MAC address, the network adapter can send and receive network traffic as if it were another adapter on the network.

Further, by default, all host and guest operating systems that share the same physical network adapter are allowed to view each other's network traffic. This arrangement, known as promiscuous mode, is similar to using a network hub to connect the virtual machines, and is thus subject to traffic "sniffing" as with a physical hub.

Use of promiscuous mode may be problematic, as an administrator or root user within a virtual machine can view and potentially manipulate traffic destined to other guest or host operating systems. You can disable promiscuous mode, which effectively creates a "switched" environment. It is similar to using a network switch rather than a hub to connect virtual machines. However, disabling promiscuous mode causes some slight network performance impact due to the extra processing required.

VMware has developed a three-pronged approach for preventing a virtual network adapter from impersonating any network adapter on the same network. The approach involves adding three options to each virtual machine's configuration (.vmx) file. When used together, the three options do the following:

  • Prevent the guest operating system from sending and receiving network traffic that use any MAC address other than the initial MAC address assigned when the virtual machine was created.
  • Prevent the guest operating system from sending network packets that use a source MAC address different than the virtual machine's effective MAC address.
  • Disable promiscuous mode.

Preventing a Virtual Machine from Using a MAC Address Other than the Initial MAC Address

To prevent a guest operating system from sending and receiving any traffic if the effective MAC address is set in the guest operating system to anything but the virtual network adapter's initial MAC address, add the following line to the virtual machine's configuration file:
ethernet<n>.downWhenAddrMismatch = TRUE

Where <n> is the number of the appropriate virtual network adapter. ethernet0 is the default.

You must add a similar line for each configured virtual network adapter, if your server has more than one network adapter enabled.

The guest operating system is unaware that its virtual network adapter cannot send and receive packets using the impersonated MAC address. It still sends packets using the impersonated address, but GSX Server or ESX Server intercepts these packets before they get delivered to their destination. The guest simply thinks that its network packets have been dropped on the way to their destination.

Note: If this option only is used, then all inbound and outbound network traffic is dropped by GSX Server or ESX Server until the effective MAC address is changed to match the initial MAC address.

Preventing a Virtual Machine from Sending Packets Using an Impersonated Source MAC Address

To prevent a guest operating system from sending network packets with a source MAC address that is different than the virtual network adapter's effective MAC address, add the following line to the virtual machine's configuration file:
ethernet<n>.noForgedSrcAddr = TRUE

Where <n> is the number of the appropriate virtual network adapter. ethernet0 is the default.

You must add a similar line for each configured virtual network adapter, if your server has more than one network adapter enabled.

The guest operating system is unaware that its virtual network adapter cannot send packets using the impersonated MAC address. It still sends packets using the impersonated address, but GSX Server or ESX Server intercepts these packets before they get delivered to their destination. The guest simply thinks that its network packets have been dropped on the way to their destination.

Note: If this option only is used, then all outbound network traffic using a forged MAC address is dropped by GSX Server or ESX Server.

Disabling Promiscuous Mode for the Virtual Machine's Ethernet Adapter

To disable promiscuous mode in the virtual machine, add the following line to the virtual machine's configuration file:
ethernet<n>.noPromisc = TRUE

Where <n> is the number of the appropriate virtual network adapter. ethernet0 is the default.

You must add a similar line for each configured network adapter, if your server has more than one network adapter enabled.

The guest operating system on its own cannot detect that it is not receiving all the network packets for which it asked.

Disabling Guest Operating System Logging

Virtual machines can log troubleshooting information into a virtual machine log file stored on the host operating system. Normal, non-root or non-administrator users and processes in the virtual machine can abuse this logging process and cause large amounts of data to be logged. Over time, a log file can eventually consume all the file system space on the host disk used to store the VMware log file, leading to a denial of service.

To disable logging of virtual machine messages, add the following line to each virtual machine's configuration (.vmx) file:
isolation.tools.log.disable = TRUE

Caution: If you disable logging, you may not have adequate logs to troubleshoot a future software problem. VMware cannot offer technical support without logging enabled.

However, this option disables logging from the guest operating system only, it does not interfere with logging generated by GSX Server. Debugging settings are at the application level, not the guest operating system level, for example.

Enabling SSL for Console and Management Interface Sessions

By default, GSX Server 3 has SSL enabled for VMware Virtual Machine Console and VMware Management Interface connections. To keep your network traffic secure, keep SSL enabled for console and management interface connections.

By default, GSX Server 2.5.1 does not use SSL to secure VMware Remote Console and VMware Management Interface sessions. If you are concerned about someone eavesdropping on your network traffic during a remote console or management interface session, you should enable SSL.

To enable SSL for your remote console and management interface sessions, follow the steps at www.vmware.com/support/gsx25/doc/manage_secure_remote_gsx.html.

Providing Host Operating System Login Accounts to Trusted Users Only

Due to the additional security requirements of GSX Server and the potential for local users in the host operating system to degrade virtual machine performance, host operating system login accounts should be limited to trusted users only.

Restricting Which Users Can Create Virtual Machines and Virtual Disks

By default, any user with access to the GSX Server host can create virtual machines and virtual disks on the host. If you are running GSX Server 3.1, you can restrict the ability to create virtual machines and virtual disks to a specific set of users or groups. To do so, complete the following steps.

  1. On the GSX Server host, create a file and give it a name (referred to hereafter as <name>). Assign Write (w) permissions to the file only to the users and or groups that you want to allow to create virtual machines on the host.

  2. In a text editor, edit the GSX Server configuration file. On a Windows host, this file is C:\Documents and Settings\All Users\Application Data\VMware\VMware GSX Server\config.ini; on a Linux host, this file is /etc/vmware/config.

  3. Add the following lines to the configuration file:
    serverd.doCreateCheck = "TRUE"
    serverd.createCheckFile = "<name>"
    where <name> is the name of the file you created in step 1.

  4. Save and close the file.

  5. Restart the VMware Registration Service (Windows hosts) or vmware-serverd (Linux hosts).

    On a Windows host, access the Services console. Choose Start > Programs > Administrative Tools > Services. Right-click the VMware Registration Service and choose Restart.

    On a Linux host, kill the vmware-serverd process.
    kill -TERM `pidof vmware-serverd`

    The vmware-serverd process restarts automatically. If it does not restart, reboot your GSX Server host.

With the GSX Server configuration file modified, only users with write access to the specified file (<name>) can create virtual machines and virtual disks.

If you modify which users you want to be able to create virtual machines, you need to modify the file permissions of <name>, then restart the VMware Registration Service or vmware-serverd, as described in step 5 above.

Disabling Copy and Paste in the Guest Operating System

When VMware Tools is running in a virtual machine, you can copy and paste text to and from the guest operating system. The VMware Virtual Machine Console/VMware Remote Console user's clipboard is accessible to normal (non-root and non-administrator) users and processes within the virtual machine as soon as the console window gains focus. If the console user happened to copy sensitive information to the clipboard prior to using the console, the sensitive data is — perhaps unknowingly — exposed to the virtual machine.

To disable copy and paste for a virtual machine, add the following options to the virtual machine's configuration file:
isolation.tools.copy = FALSE
isolation.tools.paste = FALSE

These options override the settings made in the guest operating system's VMware Tools control panel. They also override the setting in the Preferences dialog box (Edit > Preferences > Input).

Managing Removable Devices for Virtual Machines

Normal (non-root or non-administrator) users and processes within virtual machines have the capability to connect or disconnect devices, such as network adapters and CD-ROM drives.

For example, by default, a rogue user within a virtual machine can:

  • Connect a disconnected CD-ROM drive and access sensitive information on the media left in the drive.
  • Disconnect a network adapter to isolate the virtual machine from its network, which is a denial of service.

In general, you should use the virtual machine settings editor/Configuration Editor to remove any unneeded or unused hardware devices. However, you may want to use the device again, so removing it is not a good solution. In this case, you can prevent a user or running process in the virtual machine from connecting or disconnecting a device from within the guest operating system by adding the following option to the virtual machine's configuration file (.vmx):
<device name>.allowGuestConnectionControl = FALSE

You must specify a device name for <device name> (for example, ethernet0).

GSX Server for Windows Hosts: Securing IIS Used by the Management Interface

The VMware Management Interface is hosted in Microsoft's Internet Information Server (IIS). In order to maintain security and still be able to use the management interface, normal IIS security best practices should be followed. VMware recommends you:

  • Ensure the host operating system is always kept up to date with security patches.
  • Consider using IP address restrictions to limit who can access the management interface.
  • Do not host other Web sites on the GSX Server host machine.
  • Remove all Web, FTP and SMTP services listed in the IIS Manager, with the exception of the VMware Management Interface Web site.
  • Consider following Microsoft's published IIS security baseline checklist, located at www.microsoft.com/technet/security/chklist/iis5cl.asp.

GSX Server for Windows Hosts: Increasing VMware Management Interface Application Protection in IIS

The VMware Management Interface application is hosted in IIS. The application protection option defaults to Low (IIS Process). A proactive security approach would be to change the application protection option to High (Isolated). This setting drastically reduces the risk of compromise by any potential, unforeseen vulnerability within the management scripts.

  1. Open the Internet Information Services (IIS) Manager.
  2. In the Web Sites directory, right click the VMware Management Interface Web site and select Properties.
  3. Click the Home Directory tab.
  4. Set the value for Application Protection to High.
  5. Click OK to confirm your settings.
  6. Stop, then start the IIS service.

This change does not affect any functionality of the VMware Management Interface.

GSX Server for Windows Hosts: Verifying Management Interface Scripts in IIS

The configured IIS file extensions used by the VMware Management Interface scripts do not check to see if the request script file exists before attempting to execute it. This configuration allows for information disclosure via the display of the full GSX Server installation directory path in the error message upon request for a management script that does not exist.

In addition, there may be unforeseen ramifications to allowing remote users to invoke the script interpreter (Perl) without needing to specify a legitimate file. A proactive security approach would enable the Check that file exists option in the file extension mappings for .pl and .xvm.

  1. Open the Internet Information Services (IIS) Manager.
  2. In the Web Sites directory, right click the VMware Management Interface Web site and select Properties.
  3. Click the Home Directory tab, then click Configuration.
  4. Under Application Extensions, select .pl, then click Edit. Check Check that file exists then click OK.
  5. Under Application Extensions, select .xvm, then click Edit. Check Check that file exists then click OK.
  6. Click OK to confirm your settings.
  7. Stop, then start the IIS service.

This change does not affect any functionality of the VMware Management Interface.

GSX Server for Linux Hosts: Prevent Virtual Machines from Running in Full Screen Mode

The vmware-remotemks binary — the program that allows the VMware Virtual Machine Console to connect to a GSX Server host remotely — runs as root with the setuid bit set. This allows a virtual machine to enter full screen mode. Administrators concerned about the program running as root can disable the setuid bit.

To disable the setuid bit, switch user to root (su -), change to the directory where you installed vmware-remotemks (by default, /usr/bin) and type the following at a terminal:
chmod -Xs vmware-remotemks

The only side effect to disabling the setuid bit is that virtual machines on the server cannot enter full screen mode.

Keywords

1042; Neohapsis; best; practices; NLB

Request a Product Feature

To request a new product feature or to provide feedback on a VMware product, please visit the Request a Product Feature page.

Feedback

  • 2 Ratings

Did this article help you?
This article resolved my issue.
This article did not resolve my issue.
This article helped but additional information was required to resolve my issue.
What can we do to improve this information? (4000 or fewer characters)
  • 2 Ratings
Actions
KB: