Server virtualization has many benefits, including savings on hardware, power, and cooling, as well as simplified management. Anyone who’s been in IT for any length of time has dealt with a computer that was infected with spyware, a virus, or possibly a rootkit. If the infected computer is a physical machine, you can at least shut it down or unplug it from the network to prevent further infection. But what if the infected computer is a virtual machine (VM)? Or worse, what if the infected computer is a VMware ESX host?
If a host is compromised, a hacker can create new rogue VMs or create a hyperstack or hyperjack attack. A hyperstack attack is similar to a man-in-the-middle attack, in which the original hypervisor is replaced with a rogue hypervisor but the legitimate hypervisor and hardware are unaware of the compromise. The rogue hypervisor is then privy to all the communication between the original hypervisor and the VMs. A hyperjack attack is a compromise of the hypervisor, similar to a rootkit infection on a physical computer. There have been a few documented hypervisor attacks, and it’s just a matter of time before an ESX attack is released into the public domain.
When a hypervisor is compromised, determining the source of attack is very difficult because the machine is a VM. The problem is even worse if the hypervisor is part of a cluster. The rogue VM could be moved from one host to another and possibly even replicated to a remote site using SAN replication. If a host gets infected in a cluster, you’ll probably have to take down your entire virtualization cluster and clean up the mess.
I hope I’ve raised enough concerns to convince you that virtualization security is indeed important. The basic tenet of virtualization security is to protect the virtualization host at all costs. If a host is compromised, you might not be able to fully recover your environment. I teach a 5-day course on this subject, so this article obviously isn’t a comprehensive tutorial on how to harden your virtualization environment. However, the suggestions I highlight in this article can be a significant help in hardening your virtualization infrastructure in a VMware environment.
Protected Management Network
The most important step you can take to protect your ESX hosts is to establish a protected management network for your hosts, as Figure 1 shows. This dedicated management network is protected from the other internal networks. In Figure 1, the only way to manage the ESX host is to access the Virtual Host Management Computer. This computer typically runs VMware vCenter Server.
Figure 1: ESX network with dedicated management network
To access the management network, the network administrator must authenticate to the SSL VPN, which is set up for two-factor authentication. After the network administrator is authenticated through Active Directory (AD), he receives a one-time password (OTP) via text message to his cell phone. (If a network administrator receives an OTP but wasn’t accessing the SSL VPN appliance, his AD username and password have been compromised.) After authenticating to the SSL VPN, the network administrator receives a shortcut for using RDP to access the vCenter server.
A firewall rule is created to allow SSL (TCP port 443) traffic to pass from the virtual server network to the dedicated management network. For further security, you can restrict the firewall rule to allow only specific IP addresses to access the SSL VPN appliance on the protected network. We typically allow all traffic to pass from the dedicated management network to the virtual server network. In the event of an attack, this dedicated network should buy you extra time to further isolate the network before any information is compromised.
This approach is consistent with protecting the host at all costs. Although this kind of strategy with a VPN appliance is somewhat uncommon, it’s appropriate for an enterprise environment with multiple ESX administrators. If you don’t want to use an SSL VPN, I still strongly suggest that you use a dedicated management network and that you open up TCP port 3389 (i.e., Terminal Server) on the firewall so that network administrators can access the vCenter server.
The concept of a dedicated management network is consistent with today’s security model of siloing. Siloing segments a network into logical subnets so that users don’t have access to computers they don’t need access to. I prefer using a firewall to implement siloing rather than using a switch or router because the logging, management, and troubleshooting tools are significantly better on a firewall. The following should also be considerations in a dedicated management network:
- HP Integrated Lights-Out (iLO)/Dell Remote Access Controller (DRAC) cards—These cards let the network administrator gain remote console access to an ESX host even when it’s turned off. However, they must be plugged in to the dedicated management network rather than the public network to prevent leaving an open back door to the host.
- Switch management—Should be accessible only from the management network.
- Firewall management—Should be accessible only from a dedicated management network.
- UPS management—If you’re running a UPS with a network-enabled management card, this card should be plugged in to the management network; otherwise, a hacker could launch a Denial of Service (DoS) attack against all the VMs by accessing the UPS management card and simulating a power failure.