It's no secret that in today's interconnected world, servers require extra security. Now Microsoft Hyper-V virtualization adds another layer of concern, since you are running a host operating system where multiple servers run virtually.
The attack surface is widened from many physical machines to a single one with multiple virtual machines (VMs). Not only do you need to follow your standards for those VMs as if they were standalone servers, but you also have to consider the hosts they are sitting on.
One can argue the virtues of security features between the various hypervisor implementations, but let's focus on what you should be doing when it comes to Hyper-V installations, specifically.
The first thing to consider is the network. Hyper-V virtual machines are actually running through a virtual network switch on the host machine. Three virtual networks are created on all Hyper-V hosts; external virtual networks, internal virtual networks, and private virtual networks. This extension of your physical network into a separate device inside of the Hyper-V host means you can't just leave network security up to the network administrators; you'll have to consider how the network topology affects your machines.
Best practice: You should separate any administrative or management functions to a separate network entirely. Its common practice with VMware hosts to put the management network on a separate physical network, and it should be the same with Hyper-V hosts. This method allows you to run management traffic over a virtual LAN that can only be accessed by administrators.
This is important because it limits the exposure of the host machine to a single network without bleeding that traffic to the same network your virtual machines are using.
When you install the Hyper-V role, you are requested to reserve a network adapter for the management operating system. To be effective, this adapter should be separated by its own VLAN for management traffic that is accessible only by the proper staff and systems, such as System Center Virtual Machine Manager or other third-party VM host management systems.
If you use VLAN separation for your physical servers, you can extend that to your virtual servers as well. For example, you may have a front-end network where your production servers live, but a separate one for development machines. The VLAN properties are accessible from the settings for the virtual machine.
Virtual hard disks (VHDs)
Just as you would lock down permission to the hard disk of a server, you have to also protect the virtual disk of your virtual machines. The VHD files need to be in a protected location on your host. By default they are stored in %users%\Public\Documents\Hyper-V\Virtual Hard Disks and the permissions are setup properly there. The problem is, most administrators will want to store VHD files in a separate directory to move them to a different partition for performance reasons, or to allow for additional space away from the partition containing the host operating system.
Best practice: Whatever location you choose for the VHD files, make sure you assign the correct permissions to that folder:
- Administrator and System need Full Control set to the folder, subfolders, and files.
- Creator Owner should have Full Control set to the subfolders and files.
- Interactive, Service, and Batch need special permissions that include Create files/write data, Create folders/append data, Delete, Delete subfolders and files, Read attributes, Read extended attributes, Read permissions, Write attributes, and Write extended attributes.
The virtual machine configuration file is also important to keep under tight lock and key. These are normally stored in %programdata%\Microsoft\Windows\Hyper-V, which is a fine place for them since the files are so small. However, If you need to store them in an alternate location (to simplify backups, for example), then make sure you have the same permissions in the new folder as I described for the VHD files.
What are the VMs doing?
One thing you should think about when deploying virtual machines is what these virtual machines are actually doing.
You'll want to consider this so that you don't expose other virtual machines to an unnecessary risk because a shoddy virtual machine is also running on that same host. For example, you would not want to host a Forefront firewall server on the same machine as your back-end database server. In the event that the firewall is compromised and the host is as well, you'll be left with exposure via the host network connection to your back-end network or to other virtual machines that would physically exist on a completely different subnet.
Best practice: Place virtual machines with similar risk levels or application roles on the same physical host in order to reduce potential vulnerability.
The Server Core option
A dedicated Hyper-V is the perfect candidate for a Server Core installation, which is a version of Windows Server 2008 that runs with a command-only interface and is designed to be managed remotely. In theory, this is a great idea because many of the possible attack surfaces are removed and only essential services are installed.
So, why wouldn't you implement this kind of server? In most organizations it's a matter of manageability and training. Server Core requires a brand new approach to server management and some organizations may not be willing to make the investment in time and training required to supporting it. In a security-only decision, a Server Core Hyper-V host is the better choice, but it will be up to each IT organization if this kind of implementation makes sense.
These are some of the first things you should consider when looking at security for your Hyper-V installation. Of course, there are always more -- and I haven't even discussed delegation of administrative duties -- but for starters, make sure these best practices are covered in your implementation of Hyper-V.
ABOUT THE AUTHOR
Eric Beehler has been working in the IT industry since the mid-90's, and has been playing with computer technology well before that. His experience includes over nine years with Hewlett-Packard's Managed Services division, working with Fortune 500 companies to deliver network and server solutions and, most recently, I.T. experience in the insurance industry working on highly-available solutions and disaster recovery. He currently provides consulting and training through his co-ownership in Consortio Services, LLC.