loading...

Windows Server 2019 – Shielded VMs

Installing an FTP server

If your day job doesn’t include work with Hyper-V, it’s possible that you have never heard of shielded VMs. The name does a pretty good job of explaining this technology at a basic level. If a VM is a virtual machine, then a shielded VM must be a virtual machine that is shielded or protected in some way, right?

A shielded VM is essentially a VM that is encrypted. Rather, the hard drive file itself (the VHDX) is encrypted, using BitLocker. It sounds simple, but there are some decent requirements for making this happen. In order for the BitLocker encryption to work properly, the VM is injected with a virtual Trusted Platform Module (TPM) chip. TPMs are quickly becoming commonplace at a hardware level, but actually using them is still a mysterious black box to most administrators. Shielded VMs can also be locked down so that they can only run on healthy and approved host servers, which is an amazing advantage to the security-conscious among us. This capability is provided by a couple different attestation options, which we will discuss shortly.

In order to explain the benefits that shielded VMs bring to the table, we are going to look at an example of what happens when VMs are not shielded. Keep in mind that the idea of shielded VMs is quite a bit more important when you think in the context of servers being hosted in the cloud where you don’t have any access to the backend, or hosted by some other division inside your company, such as inside a private cloud. Unless you have already taken the time to roll out all shielded VMs in your environment, what I am about to show you is currently possible on any of your existing VMs.

You already know that I am running a Hyper-V host server and on that host I have a virtual machine called WEB3. Now, let’s pretend that I am a cloud-hosting provider, and that WEB3 is a web server that belongs to one of my tenants. I have provided my tenant with a private virtual switch for networking, so that they can manage the networking of that server and I don’t have access to that VM at the networking level. Also, it is a fact that this WEB3 server is joined to my tenant’s domain and network, and I as the cloud host have absolutely no access to domain credentials, or any other means that I can utilize to actually log in to that server.

Sounds pretty good so far, right? You, as a tenant, certainly wouldn’t want your cloud provider to be able to snoop around inside your virtual machines that are being hosted in that cloud. You also wouldn’t want any other tenants who might have VMs running on the same cloud host to be able to see your servers in any way. This same mentality holds true in private clouds as well. If you are hosting a private cloud and are allowing various companies or divisions of a company to have segregated VMs running in the same fabric, you would want to ensure those divisions had real security layers between the VMs, and between the VMs and the host.

Now, let’s have a little fun and turn into a villain. I am a rogue cloud-host employee, and I decide that I’m going to do some damage before I walk out the door. It would be easy for me to kill off that WEB3 server completely, since I have access to the host administrative console. However, that would probably throw a flag somewhere and the tenant would just spin up a new web server, or restore it from a backup. So even better than breaking the VM, I’m going to leave it running and then change the content of the website itself. Let’s give this company’s clients something to talk about!

To manipulate my tenant’s website running on WEB3, I don’t need any real access to the VM itself, because I have direct access to the virtual hard drive file. All I need to do is tap into that VHD file, modify the website, and I can make the website display whatever information I want.

First, I log into the Hyper-V Server (remember, this is owned by me since I am the host), and browse to the location of the VHD file that WEB3 is using. This is all on the backend, so I don’t need any tenant credentials to get here. Furthermore, nothing is logged with these actions and the tenant will have no way of knowing that I am doing this. I simply right-click on that VHD and select Mount:

Now that the VHD has been mounted to the host server’s operating system directly, I can browse that VM’s hard drive as if it were one of my own drives. Navigate to the wwwroot folder in order to find the website files, and change the default page to display whatever you want:

When I’m finished playing around with the website, I can open up Disk Management, right-click on that mounted disk, and select Detach VHD to cover my tracks:

And then, just for the fun of it, I copy the entire VHD file onto a USB so that I can take it with me and mess around with it more later.

How do you feel about hosting virtual machines in the cloud now? This example cuts to the core of why so many companies are scared to take that initial step into cloud hostingthere is an unknown level of security for those environments. Thankfully, Microsoft is taking steps to alleviate this security loophole with a new technology called shielded VMs.

Encrypting VHDs

The idea behind shielded VMs is quite simple. Microsoft already has a great drive-encryption technology, called BitLocker. Shielded VMs are Hyper-V VMs that have BitLocker drive encryption enabled. When your entire VHD file is protected and encrypted with BitLocker, nobody is going to be able to gain backdoor access to that drive. Attempting to mount the VHD as we just did would result in an error message, and nothing more:

Even better is that; when you set up your infrastructure to support shielded VMs, you also block Hyper-V Console access to the VMs that are shielded. While this in itself isn’t as big a deal as drive encryption, it’s still important enough to point out. If someone has access to the Hyper-V host server and opens up Hyper-V Manager, they will generally have the ability to use the Connect function on the tenant VMs in order to view whatever was currently on the console. More than likely, this would leave them staring at a login screen that they, hopefully, would not be able to breach. But if that VM’s console had somehow been left in a logged-in state, they would have immediate access to manipulating the VM, even if the drive was encrypted. So when you create a shielded VM, it not only encrypts the VHD using BitLocker technology, it also blocks all access to the VM’s console from Hyper-V Manager.

Does this hardcore blocking have the potential to cause you problems when you are trying to legitimately troubleshoot a VM? What if you need to use the Hyper-V Console to figure out why a VM won’t boot or something like that? Yes, that is a valid point, and one that you need to consider. Shielded VMs make the security of your VMs much higher. So much so that you could, in fact, lock yourself out from being able to troubleshoot issues on that server. As is often the case with everything in the IT world, we are trading usability for security.

Infrastructure requirements for shielded VMs

There are a couple of important pieces in this puzzle that you need to be aware of if you are interested in running shielded VMs.

Guarded hosts

You will need to run one or more guarded host servers in order to house your shielded VMs. Guarded hosts are essentially Hyper-V servers on steroids. They will host VMs like any other Hyper-V Server, but they are specially crafted and configured to host these encrypted shielded VMs, and to attest their own health as part of this overall security strategy.

Guarded hosts must be running Server 2016 Datacenter or Server 2019 Datacenter, and generally you want them to boot using UEFI, and to contain a TPM 2.0 chip. While TPM 2.0 is not a firm requirement, it is certainly recommended.

These guarded host servers then take the place of your traditional Hyper-V Servers. It is their job to host your VMs.

Host Guardian Service (HGS)

HGS is a service that runs on a server, or more commonly a cluster of three servers, and handles the attestation of guarded hosts. When a shielded VM attempts to start on a guarded host server, that host must reach over to HGS and attest that it is safe and secure. Only once the host has passed the HGS attestation and health checks will the shielded VM be allowed to start.

HGS is critical to making a guarded fabric work. If HGS goes down, none of your shielded VMs will be able to start!

There are different requirements for HGS, depending on what attestation mode your guarded hosts are going to utilize. We will learn about those modes in the next section of this chapter. HGS will have to be running Server 2016 or Server 2019, and most commonly you want to use physical servers running in a three-node cluster for this service.

I also want to point out a capability related to HGS that is brand new in Windows Server 2019: HGS cache. A previous limitation of Server 2016 Shielded VMs was that HGS needed to be contacted every time any guarded host wanted to spin up any shielded VM. This can become problematic if HGS is unavailable for some temporary reason. New in Server 2019 is HGS cache for VM keys so that a guarded host is able to start up approved VMs based on keys in the cache, rather than always having to check in with a live HGS. This can be helpful if HGS is offline (although HGS being completely offline probably means that you have big problems), but HGS cache has a more valid use case in branch-office scenarios where a guarded host might have poor network connection to HGS.

Host attestations

Attestation of the guarded hosts is the secret to using shielded VMs. This is the basis of security in wanting to move forward with such a solution in your own environment. The ability for your hosts to attest their health and identity gives you peace of mind in knowing that those hosts are not being modified or manipulated without your knowledge, and it ensures that a malicious host employee cannot copy all of your VM hard drive files onto a USB, bring them home, and boot them up. Those shielded VMs are only ever going to start on the guarded hosts in your environment, nowhere else.

There are two different modes that guarded hosts can use in order to pass attestation with HGS. Well, actually there are three, but one has already been deprecated. Let’s take a minute to detail the different modes that can be used between your guarded hosts and your HGS.

TPM-trusted attestations

This is the best way! TPM chips are physical chips installed on your server’s motherboards that contain unique information. Most importantly, this information cannot be modified or hacked from within the Windows operating system. When your guarded host servers are equipped with TPM 2.0 chips, this opens the door to do some incredibly powerful host attestation. The host utilizes Secure Boot and some code-integrity checks that are stored inside the TPM in order to verify that it is healthy and has not been modified. HGS then crosschecks the information being submitted from the TPM with the information that it knows about when the guarded host was initially configured, to ensure that the requesting host is really one of your approved guarded hosts and that it has not been tampered with. If you are configuring new Hyper-V Servers, make sure they contain TPM 2.0 chips so that you can utilize these features.

Host key attestations

If TPMs aren’t your thing or are beyond your hardware abilities, we can do a simpler host key attestation. The ability for your guarded hosts to generate a host key that can be known and verified by HGS is new with Windows Server 2019. This uses asymmetric key-pair technology to validate the guarded hosts. Basically, you will either create a new host-key pair or use an existing certificate, and then send the public portion of that key or cert over to HGS. When guarded hosts want to spin up a shielded VM, they reach out to attest with HGS, and that attestation is approved or denied based on this key pair.

This is certainly a faster and easier way to make shielded VMs a reality in your network, but is not as secure as a TPM-trusted attestation.

Admin-trusted attestation – deprecated in 2019

If your environment is new and based on Server 2019, don’t pay any attention to this one. However, there are folks who are running shielded VMs within a Windows Server 2016 infrastructure, and in that case, there was an additional option for attestation. Commonly known as admin-trusted attestation, this was a very simple (and not very secure) way for your hosts to attest to HGS that they were approved. Basically, you created an Active Directory (AD) security group, added your guarded hosts into that group, and then HGS considered any host that was part of that group to be guarded and approved to run shielded VMs.

Comments are closed.

loading...