For better or worse, administrators usually accept the default VMware hypervisor security settings.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
VSphere is fairly secure, but VMware security breaches can still occur. Careless mistakes and questionable administrative decisions can weaken infrastructure security -- especially if IT pros are more concerned about management convenience than about hardening the hypervisor, hosts and virtual machines (VMs).
To help prevent snafus, here are five ways to maximize VMware hypervisor security.
Firewalls prevent VMware hypervisor security from getting burned
Physical firewalls protect servers and devices directly connected to physical networks, but they aren't always effective at protecting VMs connected to virtual networks. So use virtual firewalls in conjunction with physical firewalls to ensure that network traffic is secure at every level and nothing slips through the cracks.
Sometimes, virtual machine network traffic doesn't leave the host or travel over a physical network. Traffic between VMs on the same vSwitch and port group remains inside the host. It travels in the host's memory, through the virtual network -- rather than over the physical network. As such, it's outside the physical firewall's protection zone.
To provide maximum protection for VMs at the network layer, use security products designed for virtual infrastructures, such as VMware vShield. Virtual firewall services that use the VMsafe application programming interfaces (APIs) understand and see network traffic at the virtual network interface card level of the VM.
Judiciously distribute host resources
Implement resources controls in vSphere to prevent internal distributed-denial-of-service-like attacks. Configuring these controls can help avoid an outage from rogue VMs causing havoc with resources.
By default, a host has a limited amount of resources to which all VMs have equal rights. And VMs compete for these resources to carry out workloads. As a result, the host is like the Wild West, with no laws governing host-resource usage. Less-critical VMs may make critical VMs resource constrained -- which can cause taxed VMs to crash, much like a physical server would during a distributed denial-of-service attack.
VSphere's built-in resource controls, such as shares, limits and reservations, guarantee and prioritize VM access to host resources. The new Storage I/O Control and upcoming Network I/O Control features provide additional control of storage and network resource usage on a host.
You can segregate host resources into pools and assign them to select VMs, which prevents VMs in a resource pool from stealing resources in another pool.
In addition, resource pools can be configured to segregate all of a host resources into pools that can be assigned to select VMs. Doing this prevents VMs that are part of one resource pool from stealing resources from VMs in another resource pool.
Extend VMware hypervisor security to the remote console
Allow only one user to access a VM's console at a time. This action prevents users with low-level privileges from accessing sensitive information when multiple users are logged in.
Unlike Windows Remote Desktop, where each user gets a separate session, a VM's remote console allows multiple people to connect simultaneously. If a user with elevated privileges is logged into the remote console and another person connects to it, the second user gains access to the first user's elevated privileges -- which can be a big problem for VMware hypervisor security.
To eliminate this risk, remove the Console Interaction privilege from certain users. You can also limit the number of remote console sessions to one. Just add the RemoteDisplay.maxConnections=1 advanced configuration setting to the VM configuration.
Another risk is the copy-and-paste functionality between a VM's guest operating system and the OS of the computer connected to it via remote console. If someone connects to a VM and copies information to the VM's clipboard, that information is available to anyone who connects to the VM -- either through the remote console or other means.
To prevent this VMware hypervisor security vulnerability, disable the remote console's copy-and-paste ability to connected computers by adding the following advanced configuration settings to the VM:
isolation.tools.copy.disable=TRUE, isolation.tools.paste.disable=TRUE, isolation.tools.setGUIOptions.enable=FALSE
Limit privileges to limit VMware hypervisor security vulnerabilities
It's really easy and convenient to make a user a full administrator to objects in vSphere rather than spending time assigning more granular permissions. But you risk having a user perform dangerous actions or compromise VMware hypervisor security. Having full permissions allows users to reconfigure VMs, change network configurations, copy data to and from data stores, change permissions and much more.
Instead of assigning full permissions to users, create roles that contain only the permissions that they need. VSphere has very granular permissions, broken down into different categories that can be assigned to roles -- which you can then assign to users.
It may take trial and error to get the permissions just right, because some actions in vSphere may take more than one role to allow. It's best to start with no permissions and to add them instead of removing permissions from a fully privileged user. This process ensures that you assigned only what permissions are needed.
Before assigning permissions to users, create a test user account and assign it to a role while adding permissions. This procedure can help you test if the permissions are correct.
Enable Lockdown Mode for VMware hypervisor security
Make users access ESXi hosts through vCenter Server, which has centralized security and logging. To prevent users from by bypassing vCenter Server security when connecting to ESXi hosts, enable Lockdown Mode.
It is common for administrators to loosen VMware hypervisor security to make administration more convenient (e.g., enabling remote access to Tech Support Mode), which is the opposite of what they should do. Administrators should make ESXi more secure by reducing its attack surface and better protecting VMs.
To harden ESXi security, enable the special Lockdown Mode in the security configuration of the host through vCenter Server or the direct console user interface. Lockdown Mode prevents direct host access by any means, including though APIs (i.e.,vCLI and PowerCLI) and the vSphere Client. It also blocks local and remote access to Tech Support Mode. As a result, all access to the host must go through vCenter Server.
If you don't want to be that extreme, you can just disable both local and remote access to Tech Support Mode. Ultimately, ease of use should always take a back seat to security. Resist the urge to weaken VMware hypervisor security to ensure that VMs are well protected.