Latest posts by Kyle Beckman (see all)
- Managing shared mailboxes in Office 365 with PowerShell - Thu, May 5 2016
- Managing shared mailboxes in Office 365 with the GUI - Wed, May 4 2016
- Installing and configuring the Enhanced Mitigation Experience Toolkit (EMET) - Wed, Mar 16 2016
With more and more organizations moving their critical infrastructure to virtualization, planning Hyper-V security is more important than it has ever been. As attackers shift their sights to hypervisors, IT departments need to do everything they can to protect Hyper-V hosts and the virtual infrastructure running on them.
Kill the GUI ^
One of the easiest ways to reduce the attack surface of any Windows Server is by running a Server Core install that doesn’t include a Graphical User Interface (GUI). Even if you need the GUI to run the initial setup of your Hyper-V server, you can still remove the GUI by running this simple PowerShell command with Admin rights:
Remove-WindowsFeature User-Interfaces-Infra –Restart
If you still need the graphical management tools on the console, you can run the following command to remove the GUI, but leave the tools behind:
Remove-WindowsFeature Server-Gui-Shell –Restart
Keep patches current ^
Keeping all of the most recent Windows hotfixes and updates installed may sound obvious, but I know of organizations that limit their patching of hypervisors. The most common justification I’ve heard is that the hosts are segregated on the network and are only accessible by a limited number of administrators. And, since the virtual machines can’t access the hypervisor directly, the hypervisor is protected. Or is it?
In one Hyper-V vulnerability on Windows 8 and Windows Server 2012 that was published on November 12, 2013 (MS13-092), an attacker with access to a VM could cause a Denial of Service (DoS) attack on the Hyper-V hypervisor or elevate the attacker’s privileges. Even if you’re going to limit your patching activities on hypervisors, be on the lookout for these kinds of updates so your infrastructure is protected.
Limit administrators ^
Who in your organization really requires administrator privileges on Hyper-V servers? Just because someone needs access to the advanced features of Hyper-V doesn’t mean they also need full admin rights on the server. In many situations, you can put users (or groups) into the Hyper-V Administrators group and give them most of the access they need without adding them to the Administrators group.
Hyper-V Administrators group in Computer Management
Install antivirus/antimalware software ^
Antivirus/antimalware software on a Hyper-V server is a touchy subject. If you can isolate the server and limit Administrators, it isn’t really necessary. However, many corporate security departments are still going to require (or at the very least fight you on) the installation of the company antivirus/antimalware software. If you do have to discuss antivirus/antimalware with your security department, make sure you’re armed with information and have the recommended exclusions to ensure that the security software doesn’t destroy your virtual machines.
Limit software in the parent partition ^
This is another best practice that you would think would go without saying. Question every software install on a Hyper-V host. In most cases, the only software tools you should really need are management, monitoring, and other agents that serve a similar purpose. And, removing the GUI will dissuade most people from installing unnecessary software.
Some SAN vendors may have software that they’ll
force strongly encourage you to install (especially if you call support). In many cases, a light or limited version of the software may exist that you can use instead of installing the full suite of tools.
Use a dedicated management network ^
The management network for your Hyper-V servers should always be on a dedicated network/VLAN. Other servers, virtual machines, client systems, printers, and anything else that can get an IP address should go somewhere else. Period. You also shouldn’t allow virtual switches to share the network with the management adapter (like I do on my lab system). You can clear the “Allow management operating system to share this network adapter” check box in the Virtual Switch Manager.
Virtual Switch with “Allow management operating system to share this network adapter” selected
Secure Live Migration, Storage Migration, and Replica networks ^
If you’re using Live Migration, Storage Migration, or Replica, ensure that you’re securing the networks that those services are using. Live and Storage Migration can move data in the clear, unencrypted. As with the management network, you’ll want to use a dedicated network/VLAN for that traffic. Hyper-V Replica’s default configuration uses HTTP to transport data unencrypted over TCP port 80; you’ll definitely want to change that to HTTPS to secure your data.
Consider using BitLocker ^
If you’re running all your Hyper-V host servers in a data center, you probably won’t have to deal with someone physically stealing a server or pulling hard disks. However, you may still want to consider encrypting OS disks and VM storage disks as an added layer of protection. If you’re running remote Hyper-V host servers at branch locations, I would strongly encourage encrypting the disks.