7 Keys to Hyper-V Security

For most small institutions, securing Hyper-V is often just a matter of just letting domain admins control the hypervisor. This post will examine ways you can harden your Hyper-V deployment beyond the basics.

1. Manage Access to Virtual Machine Functions

In the past, AzMan (Authorization Manager) was the tool of choice for managing specific virtual machine functions (Shut Down, etc.). AzMan was deprecated in 2012 and no longer works for Hyper-V Server 2012 R2. The MMC console and the XML file for Hyper-V are still there, but they won’t control Hyper-V Server 2012 R2. If you’re using 2012 or earlier and want to work with AzMan, this is the document that you want. I would recommend not getting too attached, since AzMan has reached the end of the road. The replacement is System Center Virtual Manager (VMM), which installs its own WMI path and has its own control mechanisms. Unfortunately, there is no longer any free, built-in way to manage control of virtual machines like this.

The “new” method is called simplified authorization. This fancy-sounding term actually just means that there is a new Hyper-V Administrators group created on each computer with the Hyper-V role enabled. Members of this group can control most anything related to Hyper-V (storage locations outside the default can still be an issue) but otherwise have no special powers on the Hyper-V host.

In all honesty, I find this to be of limited use. In small organizations, it’s normal that administrators are administrators; there’s not a huge amount of distinction between who can control what. In larger organizations, the Hyper-V administrator is probably responsible for the management operating system as well and is probably in the local administrators group anyway. If you’re mixing roles and applications on your Hyper-V host, then this might come in handy. However, you’re not supposed to be running anything else on the host other than Hyper-V-related software. If you do go against the recommendation and add other roles, then this group might be of some value.

Remember that you still control access to any given guest operating system just as you would if it were a physical machine. Users with local administrative access can still perform reboots, software installations, etc. They will not be able to turn them on, snapshot them, change virtual hardware, or anything of that nature without some level of administrative access on the host.

2. Group Policy

Group Policy is a great way to manage your systems, and is one of my top favorite reasons to use domain membership in the first place. If you’ve decided not to join your Hyper-V hosts to your domain for whatever reason, you can still do most of this in local policy on one system, then export it, then import the exported policy on each unjoined Hyper-V host.

I highly recommend that you be extremely judicious when using any setting under Computer ConfigurationWindows SettingsSecurity SettingsUser Rights Assignment. This isn’t just a suggestion for Hyper-V, this is for your domain. I’m sure many of you already understand why. If you don’t, let me tell you a story about what I did. Back in 2000, when I was still learning, I was frustrated that my personal account couldn’t log on to our test lab’s domain controller. So, I went into Group Policy for the Domain Controllers OU and added my user account to the Allow logon locally GPO. Do you know what happened? I didn’t. In Group Policy, when there is a parent-child conflict, the OU closest to the object (child) takes precedence. In Group Policy security lists, entries are exclusive. So, once I did this, the only account that could log in to the DC was mine. That account didn’t have domain admin powers. So, that was that. Good thing it was a test lab.

So, what people often do is go in and try to harden Hyper-V through Group Policy by manipulating these lists by following regular Windows procedures. What problem I see a lot of (and ran afoul of myself) is that there is a local special account on systems with Hyper-V enabled called Virtual Machines. This account is not visible at the domain level, so it cannot be added to domain group policy without some wizardry. So, people following a hardening guide will go in and tinker with Create symbolic links, and all of a sudden they can’t Live Migrate or build new VMs or do all sorts of things. They’ll get Access Denied errors and spend a lot of time playing with ICACLS on their virtual machine storage folders, all to no avail. The lesson here is, if you absolutely must set these security policies at the domain level, make sure that you don’t follow generic Windows hardening guides on a Hyper-V system.

Fortunately for you, there is a Group Policy hardening tool with settings just for Hyper-V Server. Download Microsoft Security Compliance Manager. In the interest of brevity, I won’t spend a lot of time on this. Install the application on something other than your Hyper-V hosts. I’d say to use your management workstation, but it does want to use a local SQL database. If you’re uncomfortable with having that on your desktop/laptop, find a suitable location.

Once you’ve got it installed, expand Windows Server 2012 on the left (it hasn’t yet been updated to 2012 R2, but settings from the earlier version are fine). Underneath that, click on WS2012 Hyper-V Security 1.0. You’ll be presented with a list of all the settings Microsoft thinks you should use to harden Hyper-V. These apply equally well whether you are running Hyper-V Server or Windows Server with Hyper-V as a role. You could pick and choose what you like, or you can use the export features at the right to save a GPO backup which can then be imported using Group Policy Management Console or Import-GPO. If your Hyper-V hosts aren’t domain-joined, the included LocalGPO tool can be used, although you’ll need to research that on your own (in the help files) as it’s a usage I have not tried myself.

Security Analyzer – Hyper-V

Importing into GPMC is pretty straightforward, but in order for it to work as expected, your Hyper-V hosts need to be in their own OU. Do not allow them to inherit from another OU with hardening settings, especially one with the regular Windows Server hardening settings. If you’ve made any of your Hyper-V systems into a domain controller, sorry!

First, create a new Group Policy Object:

Group Policy Management – GPO List

Don’t make any changes to it; they’ll be lost. Then, right-click on it and choose Import Settings. This will take you to a wizard that’s really easy to figure out. When prompted, point it to the folder you exported from SCM. Remember that it wants the folder that actually contains the manifest.xml file, not the GUID sub-folder. The only screen that might give you pause is the Migrating References screen. Just leave it on Copying them identically from the source and keep going. After a bit, you should receive a Success notification and you can close the wizard. Then just link the GPO to the OU for your Hyper-V hosts and continue on. If you want to hurry things up a bit, you can run gpupdate on the systems.

This section was specifically about applying group policy to your hosts. If you’re after VMs, you’re in luck, as Ben Armstrong wrote an article about this very topic while I was drafting this post. He uses WMI to locate Hyper-V guests.

3. File, Folder, and Share Security

With Hyper-V storing almost everything in the traditional file and folder format, many administrators are led into a false sense of familiarity. So, some jump into hardening things at that level and run straight into unforeseen consequences. Sometimes, this shows up when using the tools. They’ll try to perform some function in Hyper-V Manager and receive an “Access denied” message. Their first response is, “But I’m a domain administrator!”

Remember that Hyper-V Server is an always-on server, not a user-mode application. You may be running the interface as a user, but it contacts the background server with your request, and the server carries them out. Some other servers, such as IIS, can use a security model that includes impersonation, where the server attempts to carry out requests by a user by pretending to be that user. Hyper-V Server doesn’t operate on that security model. Instead, it carries out its functions in the context of the management operating system’s Local System account. When it tries to talk to other computers, that means that it is trying to authenticate using the management operating system’s computer account. In a domain, that computer account exists in Active Directory and can be used in inter-computer security operations. In a workgroup, you have to use something like CredSSP. For some uses, you also have the option to partially disable security checks by adding an entry to WinRM TrustedHosts (which means, “blindly, absolutely, and unquestioningly trust any computer that uses a name that appears in this list”). The possible uses for CredSSP and TrustedHosts are limited, which is why many things require domain membership.

For a Hyper-V system that only operates locally, NTFS permissions are your concern. The big thing is to create a folder or use the default location and let Hyper-V manage the security right from the start. Don’t come back later and start turning screws. This also applies to storage on block-level remote storage, specifically iSCSI and Fibre LUNs. If you absolutely must change permissions, stay away from modifying inheritance patterns. You could easily wind up stripping required privileges away from an account you weren’t even aware of. As a prime example, the virtual machine object needs control over its own files.

Remember that Virtual Machines account I talked about in the last section? Well look here:

Virtual Machines Account NTFS Permissions

I did not manually put that there. So, do you know what happens when you go fiddling with NTFS permissions and inheritance and whatnot? Bad Things, that’s what. Go ahead. Try to manually add the Virtual Machines account to the ACL of a folder. If you don’t want to experiment, I’ll just show you what you can expect to see:

Virtual Machines Account Not Found

Don’t bother browsing for it, either. If you’ve inadvertently removed it, the world has ended! Except, not really. It’s just not a lot of fun to put it back. Go read this post, and don’t ever do that again.

For virtual machines hosted on SMB, there’s a bit more to think about. First, domain membership is not optional. All involved physical machines must be domain members (I assume SMB will operate over an inter-domain trust, but I have not tried). Beyond that, you add in share permissions and protocol access restrictions on top of the NTFS permissions. Of the two, share permissions are probably the easiest. The computer account(s) of the Hyper-V system(s) that will host virtual machines on the share need to have Full Control on this share. That’s enough to get your SMB 3-based VM hosting working.

If you’ve got those VMs on an SMB 3 share, then you’ve opened the door to having VMs that can move between Hyper-V Servers. First, there’s the traditional failover cluster. For that, you don’t really have to do anything else (assuming the cluster already exists). If you want to migrate SMB-hosted VMs in Shared Nothing fashion, there might be a bit more work to do. If you will be using a remote machine to initiate a Shared Nothing Live Migration (you almost certainly will at some point), you need to enable delegation. What delegation means is that you can use your credentials from computer A to tell computer B to perform a function on computer C. Sometimes, computer C is actually computer A, but the basic issue is that your credentials are being used in a remote location. Because this can be a pretty severe security risk, it is advised that you not just open the floodgates on such delegation. Instead, use constrained delegation. This is configured on the Active Directory computer object for the machine to be controlled, and delegation is extended to the computers that might be used to control it. The following screenshot shows a computer object with two other machines granted delegation:

Sample constrained delegation configuration

The CIFS entry controls SMB access. CIFS stands for Common Internet File System, which was the first iteration of the technology that eventually became SMB. The two terms are not interchangeable in most other contexts. The Microsoft Virtual System Migration Service should be self-explanatory. Be aware that this delegation is only necessary if you’ve set the migration model to use Kerberos delegation instead of CredSSP. You could also opt to set Trust this computer for delegation to any service (Kerberos only), but doing so opens the gates a lot wider than is necessary.

4. The Network

Network access is your first line of defense against Bad Things coming from attackers. If you have the hardware, the expertise, and the budget, network security is best done in the networking hardware. If you don’t, then you still have the Windows Firewall. This poor software is much maligned, which is sad because it’s a whole lot better than nothing, and a lot less troublesome than many third-party software firewalls I’ve come across. It does sometimes get in the way (because that’s what firewalls are for), but that doesn’t mean you should just jump straight to turning it off. That’s like saying, “My scarf made it harder to breathe, so I stopped wearing clothes.”

What I’ve noticed as I tinker with 2012 R2 is that I can do a great many management tasks without ever touching the firewall at all. If it’s been your go-to practice to disable the firewall and you aren’t confident in your hardware-level network security, you might consider revisiting this practice. If you do find an activity being blocked by the firewall, selectively open it.

The Windows Firewall does not interfere with guest traffic in any way, shape, or form. The adapter for the Hyper-V virtual switch is completely unbound from anything that the Windows Firewall has access to. Packets will pass through it without ever being inspected by the management operating system’s firewall. Making changes to the firewall in Hyper-V to restrict or free traffic in the guests is a wasted effort.

There are, however, extensions to the Hyper-V switch available that do allow for packet processing at this level. As far as I know, only third parties are taking advantage of extensions for that purpose. I’ll leave it to your research skills to investigate further, if you’re interested.

You can also get a measure of protection for the host through network isolation. Usually, this will be by employing VLANs and placing the Hyper-V host in its/their own or in a VLAN that’s restricted to infrastructure systems. If you haven’t got networking equipment that understands VLANs, you can still place certain systems in their own IP subnet(s). Without VLANs, they’ll still be reachable by broadcast and non-TCP/IP discovery methods, but anything is better than nothing. Of course, you’ll also need a router any time you have disparate subnets. The big takeaway from this paragraph should be that the Hyper-V host does not need to be on the same IP subnet or VLAN as any of its guests or any other system.

5. The Guests

Hypervisor design is built around the idea of isolation. Just like modern operating systems isolate application processes so that one (theoretically) can’t wreck another, hypervisors are designed to isolate guest operating systems. Historically, these have been called “partitions”, although you don’t see that terminology often in the x86/x64 world (you will, however, see it in some Hyper-V Event Logs). Every time you create a virtual machine, Hyper-V defines a partition for it. The management operating system also lives inside a partition. Like all technologies, this partitioning has its limitations. Regardless of design goals and processes, these guests are, in fact, accessing the same resource pool. There’s always a danger that someone will figure out how to trample one partition from another. If you’re using Intel chips, that’s already happened.

What you need to do then, is secure your guests. You can treat them like isolated sandboxes when you’re dealing with known quantities, like beta software from your (least) favorite vendor. You cannot treat them the same way if you’re working with completely unknown software. For instance, back in the day, a company I worked for used a Windows 98 computer that only had a modem connection and a floppy drive for external access. We’d put little things on it to see if they were infected. It seems like a virtual machine would be a perfect corollary… except for the risk outlined in that article.

Securing a guest is mostly like securing a physical machine. Anyone who has console access might as well have full administrative powers, because you really just need an Internet search engine to figure out how to get into an operating system from its console. It needs its network connections protected, and any relevant antimalware software installed.

6. Antimalware

Installing antimalware on your hosts isn’t as easy a decision as installing it on your guests. Your host should be pretty much isolated from user activity anyway; their traffic passes over the Hyper-V switch while your host’s traffic moves over the management adapter. If you’re using a fully converged design in which the management adapter is on the virtual switch, you still have a good degree of separation. I have not found any indication of a known compromise of the Hyper-V switch.

The hard drive data in the guests is also similarly isolated from the host. This means that a virus lurking in a VHDX is not a meaningful threat to the host. The same should go for guest memory.

However, because of the break-out attack linked in #5, you can’t just assume the natural isolation of the hypervisor will be sufficient.

If you’re going to run antimalware, be aware that it is a threat to the proper operation of Hyper-V. Most of them seem to dislike the XML files that define your virtual machines. If antimalware strikes them, your virtual machines will just disappear. You need to make sure that you’ve got your exclusions configured properly. For Hyper-V alone, this wiki article lists the critical exclusions to make. Unfortunately, it’s not quite the whole story for cluster-joined systems. This KB article is of some help. Pay very special attention to what it says about the shared disk model. My employer uses McAfee VirusScan Enterprise, and after experiencing a number of issues, I finally stumbled across a very helpful blog post. The exclusion list exceeds what Microsoft recommends, but made our problems go away. You’ll also notice that he talks about a “low risk process”. McAfee, like many other vendors, doesn’t necessarily not scan something just because you’ve set an exclusion. A lot of times, “exclusion” means something a little bit more like, “scan it, but don’t tell me about any problems you find” (don’t be too hard on McAfee; just about everyone does it). Find out your vendor’s method for actually excluding files and processes, and get these items added.

7. Patches and Hotfixes

I know, you’re a little gunshy about patching after the serial system killers that came out of Microsoft last year. They’re really going to have to work to earn all of our trust back. But, that doesn’t mean you should just stop patching, either. Keep an eye out and keep as up-to-date as is sensible. The community at large usually knows within a couple of days. Just use the search engine of your choice for any given KB article number and you’ll find out pretty quickly how deployment is going.

Usually, I go into my favorites and round up all the various links for you. I don’t have to do that anymore. Thomas Maurer has given us all a simple page to go look at that links to all the Hyper-V and Failover Cluster patches and hotfixes for the last three versions.

Summary

Security in Hyper-V is a many-faceted and complex thing. No one can give you a single magic bullet solution. This list is by no means all-inclusive; I didn’t talk about common sense things like “don’t write your password down or e-mail it to anyone”. Do your research, do your due diligence, and keep your systems safe.