15 Core Hyper-V Security Best Practices
Security is a major concern for IT organization nowadays. Before implementing any new technology in the production environment, IT administrators must work on the security part of the technology and ensure the attack surface is minimized. Today we'll reveal fifteen key Security Best Practice items you should follow for Hyper-V Server and VMs to ensure your Hyper-V environment runs securely.
- Navigating Your IT Career
- Exploring the Private Cloud for Your Organization
- IT Manager's Guide to Social Networking
Install Hyper-V Role on Server Core
As a security best practice, always install the Hyper-V Role on a Server Core Operating System instead of using a full version of Windows Operating System. Since Server Core doesn't have a GUI, the attack surface is minimized. The Hyper-V management client files are not installed, and this reduces the file attack surface. Using Server Core for the Hyper-V physical computer provides three primary security benefits:
- A minimized attack surface for the management operating system.
- A reduced computer footprint.
- Improved system uptime because there are fewer components that require windows updates.
Login Credentials of Hyper-V Services
You should never change the default security context of the Hyper-V Services. Alerting may cause Hyper-V to stop functioning. Changing the security context for Hyper-V Services may allow anyone to control the complete hypervisor.
Blocking Unnecessary Ports
There is no need to implement any other role/services on a Hyper-V server. Installing Client/Server applications will result in listening on a static port. Always review the ports listening on the Hyper-V Server and block them if required.
Hyper-V Default Configuration
Always check the default configuration of Hyper-V before rolling out to a production environment. By default, Hyper-V configures the virtual machine files to be stored on the local drives. It is always recommended to change this to a drive that is secure.
Using BitLocker Encryption on Parent Partition
Since BitLocker is built into the Windows Operating System, it is recommended to enable BitLocker on volumes where Hyper-V and Virtual Machine files are stored. BitLocker-based physical protection is present even when the server is not powered.
The data is protected even if a disk is stolen. BitLocker also protects data if an attacker uses a different operating system or runs a software hacking tool to access disk contents.
Note: Use BitLocker Drive Encryption in the Hyper-V management operating system only. Do not run BitLocker Drive Encryption within a virtual machine. BitLocker Drive Encryption is not supported within virtual machines.
Do Not Use Built-in Administrators Account
You should not use the default local administrator account to manage Hyper-V and Virtual Machines. Instead, create new Active Directory groups and use the Authorization Manager to delegate the virtual machine tasks.
Always Install an Antivirus Product on Hyper-V Server
Installing an antivirus product ensures that malicious activities are captured on the Hyper-V Server. You must also configure the antivirus utility to receive updates regularly.
Always Install Latest Integration Components
Integration components provide VMBUS and VSP/VSC design, which help in securing communication between virtual machines and the hypervisor. Integration components are updated with every release of Hyper-V. You need to ensure you download the latest integration components from the Microsoft site and update all the virtual machines.
Do Not Install Applications on the Hyper-V Parent Partition
You must not install applications on the Hyper-V Server. Hyper-V Server must be used for Hyper-V activities only. Installing unnecessary applications on a Hyper-V Server may interfere with Hyper-V processes and could result in a security risk.
Protect Hyper-V and Virtual Machine files
You must protect Hyper-V and virtual machine files. Since the virtual machine contents are stored in a VHD file, anyone who has access to the VHD files can mount VHD files and access the contents.
Disconnect Virtual Machines Not in Use
You should not deploy virtual machines that lack any true business function. If you install any of these VMs, you must make sure to disconnect them from the Hyper-V Virtual switches that other virtual machines are connected to. Anyone having access to non-functional virtual machines can access the production environment via networking or some other means.
Always Enable Windows Firewall and Block Unnecessary Firewall Rules
When you enable the Hyper-V role on a Windows Server, the Server Manager also enables required Hyper-V firewall rules for communication. You must make sure that no other firewall rules are enabled on the Hyper-V Server. Review the Windows Firewall on the Hyper-V Server to ensure there aren't any firewall rules enabled other than the required ones.
Securing Snapshot/Checkpoint Files
A snapshot is a "point in time" image of a virtual machine's state that you can return the machine to later. It is recommended to store any snapshots/checkpoints you create together with their associated VHDs in a secure location.
Harden the Virtual Machine Operating System
You must deploy virtual machines from a hardened base operating system image template so that you can ensure all virtual machines are deployed with a known baseline of the security. You must also ensure a antivirus product is installed in the operating system and any unnecessary components are disabled.
File system security can prevent unauthorized access to critical virtual machine VHD files. Enabling object access auditing can help detect potentially harmful activity by users.
Nirmal Sharma is a MCSEx3, MCITP and Microsoft MVP in Directory Services. He has specialized in Microsoft Technologies since 1994 and has followed the progression of Microsoft Operating System and software. In his spare time, he likes to help others and share some of his knowledge by writing tips and articles on various sites and contributing to Solution IDs for www.Dynamic-SpotAction.com. Nirmal can be reached at firstname.lastname@example.org.
Read more on "Server Virtualization Spotlight" »