lolloj - Fotolia


How to defend your VMs and virtualization hosts against cyberattacks

In an increasingly virtualized world, there's always the risk of falling prey to a cyberattack. The best way to prevent an attack is to have a solid security plan in place.

With the ever increasing number of high-profile hacks and security breaches, businesses are placing a greater emphasis on cybersecurity.

The key to securing VMs and virtualization hosts is to practice in-depth defense. Remember, there isn't one single security mechanism that's going to guarantee your VMs remain secure. To truly secure your VMs, you must take a multilayered approach both within the VM itself and within the virtualization stack.

Securing a VM really isn't all that different from securing a physical server. All of the standard best practices still apply, including things like keeping the OS and applications up to date with the latest patches, using strong passwords, enabling a software firewall and running antimalware software.

Securing virtualization hosts

Although similar best practices also apply, securing host servers requires some additional considerations. For starters, physical access to host servers -- and any connected storage -- must be restricted. If someone is able to gain physical access to a host server or to its storage, they can compromise the VMs running on the host. Microsoft's new Shielded VM feature can help with this problem, but it hasn't been widely deployed yet.

To truly secure your VMs, you must take a multilayered approach both within the VM itself and within the virtualization stack.

One way to improve security for virtualization hosts is to place the host servers and any virtualization management servers into a dedicated Active Directory (AD) forest. Doing so helps to protect virtualization hosts against pass-the-hash attacks, which generally begin on workstations. These attacks seek to harvest cached password hashes from the workstation and compromise the associated accounts. Those compromised accounts are then used to log into other workstations, with the goal of harvesting credentials from them. The process continues until an admin has been discovered logging onto a workstation. Once the attacker has administrative credentials, they can begin attacking servers.

Placing virtualization hosts in a separate, dedicated AD forest ensures even if an attacker does use a pass-the-hash attack to gain access to administrative credentials, those credentials will not be valid on host servers. Of course, the bigger lesson is to never log onto a workstation using an account that has administrative credentials.

Methods for increasing VM security

Another way to improve VM security is to group VMs by risk posture. In a perfect world, every virtual server is hardened to the maximum extent possible. In reality, however, some VMs tend to run a more aggressive security configuration than others. For example, the VM running an organization's payroll database might be more heavily secured than one running a collection of developer tools. As such, some organizations create multiple host clusters for the purpose of grouping VMs based on their risk posture. By using this approach, the organization can avoid placing a high-security VM on the same host as a lower-security VM.

It's also possible to improve VM security through the strategic use of network virtualization. There are some VMs, such as Exchange Server, that should never be exposed to general network traffic. Exchange Server has long relied on a front-end/back-end topology -- more commonly referred to as CAS role and Mailbox role. Put simply, users connect to Exchange through a front-end server, and the front-end server communicates with a back-end server, which contains the mailbox databases. Given the fact that a front-end Exchange Server is designed to proxy requests to a back-end server, it doesn't make any sense from a security standpoint to place a virtualized back-end Exchange Server on a virtual network segment that carries general-purpose traffic. Doing so would mitigate the security benefits of the front-end/back-end topology.

Although Exchange Server is used as an example, the basic concept of traffic isolation applies to any number of situations. For example, guest cluster traffic should be isolated to a dedicated virtual network segment. Likewise, you should never perform live migrations or other hypervisor management functions over a network segment that carries general-purpose traffic. In fact, some organizations dedicate a physical network interface card within each host to live migration traffic and a second NIC to management traffic.

As you work to secure your VMs and virtualization hosts, it's a good idea to check your hypervisor vendor's security recommendations. Although there are a number of general security best practices that you can apply, each hypervisor vendor also maintains its own list of security best practices.

Next Steps

Tips for creating a foolproof cybersecurity plan

Improve security with the right VM management software

Protect VM data from a security breach

Expanding the cybersecurity talent pool

Dig Deeper on Server virtualization risks and monitoring