Sep 11 2016 07:50 PM
Our design and deployment teams were having a debate on the most secure way to deploy HyperV, particularly with respect to Ransomware attacks and protecting from encryption.
There seems to be two camps, one to deploy standalone and one to join to Active Directory. I would like to know what the best practice is for securing the hypervisor.
Cheers,
Jason
Sep 12 2016 12:51 PM
Sep 12 2016 04:06 PM
Here is a nice spreadsheet of current best practices for preventing ransomware
https://docs.google.com/spreadsheets/d/1TWS238xacAto-fLKh1n5uTsdijWdCEsGIM0Y0Hvmc5g/pubhtml
Consider application whitelisting if you really want to go uber protection.
Sep 12 2016 10:41 PM - edited Sep 12 2016 10:42 PM
I think it depends on your infrastructure scale and architecture. Having domain joined Hyper-V Host allows centralized management with ease but it definitely cannot stop user that has admin privileges to make a silly mistake to take down the environment.
In a large environment, we can have an infrastructure.contoso.com forest and corporate.contoso.com forest with forest trust between forests, review and lock down the privileges but this can be complex arhitecture for small environment.
I suppose for small environment, it will be best to review the privileges and ensure that there is limited privileges for average user to access the Hyper-V Host storage through shared folders or UNC paths so that ransomware initiation cannot reach those files and encrypt them. If possible, get the Hyper-V host into Server Core mode and as for Windows Server 2016, deploy Nano Server with Hyper-V role because its the way to go.
Sep 13 2016 03:25 AM
Sep 13 2016 04:52 PM
Hi Jason,
I will suggest to get the Operating System to comply to OS Hardening first.
After that not sure if you have already read these documentations, there are some resources on Hyper-V hardening below:
Hope it helps and pave way for you to have a good start.
Sep 13 2016 10:10 PM
Oct 01 2016 07:48 AM
For big hyper-v farm, I suggest to have separate network, with it's own AD Forest (without any trust), protected by a firewall. To manage the farm, admin use a TS connection on an admin server (each admin as is own login). No direct access from office computer to Hyper-V servers. It's the best way to secure Hyper-V and other service (SOFS cluster, SCVM ...), but if you have less than 10 servers it is not the best solutions.
Oct 01 2016 01:28 PM
Is this for protecting the host itself against ransomware or the VMs running on the hosts? We've seen instances of users who have access to SMB file shares manage to get the file shares encrypted even though they dont have admin access to the VM. Active Directory joined servers + proper group policy management would be the best approach (Policies to disable autorun, script execution....). Also, if you're talking about protecting the hosts themselves, there should be network policies in place to prevent users from accessing the hosts themselves. I can't think of a situation where an end user would need to be able to get to anything on a Hyper-V host.
Feb 28 2017 10:52 AM
To keep it as short as possible, here my 2 cents:
Cheers,
Michael
Mar 09 2017 06:13 AM - edited Mar 09 2017 06:16 AM
In a properly designed infraestructure, you should have Hyper-V AD integrated and even if a VM get its files compromised by ransomware, it doesn't afect the Hosts.
Feb 23 2021 03:13 AM
@Jason Childs
Hi Jason.
I know this is a old post - but just wanted to give you my advice here, from a lesson learned in 2020 :)
Anti-malware does not belong inside Host Management OS.
Someone, at our company - decided to install Bitdefender for protection, and my oh my - what a pain.
I regret it tenfold, that I wasn't able to avoid it from being installed on our Server 2019 Core with Hyper-V, even though I fought hard and long.
It caused a massive Cluster breakdown - and it took us long, before we were able to identify Bitdefender as the real reason for the breakdown.
So, there are plenty of other suggestions on how to protect your Hyper-V Servers - but Anti-Malware software is surely not one of the ways.