In-Depth

Shield Hyper-V with Microsoft's Host Guardian Service

The new Windows Server 2016 is the most secure version of Microsoft's server OS with the introduction of the Host Guardian Service for Hyper-V Shielded VMs. Learn about this critical new feature and how to configure and implement it.

• By Michael Otey
• 11/01/2016

In this era of hybrid cloud infrastructure, security is becoming more challenging than ever given the distributed nature of workloads and data. Many businesses are running critical workloads in virtual machines (VMs) both on-premises and, in the cloud, which places even greater importance on protecting the data in those VMs. By their very nature, VMs are inherently more difficult to secure than physical systems and with the increasing use of the cloud and multi-tenant deployments, businesses need to be able to protect their VMs from external malicious attacks, as well as restrict the accessibility of those VMs from Hyper-V administrators.

The new Shielded VMs feature and Host Guardian Service in Windows Server 2016 are among the new security upgrades released last month. Shielded VMs and the Host Guardian Service enable administrators to block access to the onslaught of attacks against tenant VMs and their data from malware, as well as potentially malicious host administrators. I'll provide an overview of how the Host Guardian Service works and then describe how to configure it to enable you to deploy Hyper-V Shielded VMs.

Shielded VM Components
The Host Guardian Service has a number of working parts that can make it difficult to get started using the service. The main components are:

• Host Guardian Service (HGS): A Windows Server role that's typically installed on a cluster of bare-metal servers. The HGS is able to release keys to trusted Hyper-V hosts to power on or live migrate Shielded VMs. The HGS is composed of the Attestation Service and Key Protection Services.
• Guarded Host: A Hyper-V host that can run shielded VMs. The host must be approved by the HGS Attestation Service. Shielded VMs cannot be powered on or live migrated to a Hyper-V host that hasn't passed attestation.
• Guarded Fabric: The Hyper-V hosts that can run shielded VMs and the HGS. The Guarded Fabric is composed of Code Integrity, Virtual Secure Mode, TPM v2 and the HGS. Code Integrity ensures the host code is doing what it's intended to do by checking what the host does when it boots up. Virtual Secure Mode is a portion of protected memory in a VM that contains trustlets that handle the encryption operations. The virtual TPM is used to secure disks using BitLocker.
• Shielded VM: A shielded VM is a generation 2 VM that has a virtual TPM. The virtual hard disk is encrypted using BitLocker and can only run on healthy and approved hosts in the fabric.

If you look at Figure 1, you can see an overview of how Shielded VMs and the HGS work.

First, a user requests to start a specific shielded VM from a guarded host. The first thing the guarded host does is send a key request to the HGS. The HGS then sends a response to the guarded host requiring attestation. The guarded host sends its TCG log, which contains the system's boot events and what the OS did when it started. These are converted to a TPM. HGS Attestation Service evaluates that request and checks with the guarded host to ensure that the TCG log events and the guarded host TPM are the same.

Then the guarded host sends its Code Integrity policy to ensure it can only run the code that's deemed healthy. If the host passes the validation by the Attestation Service, then the Attestation Service sends an attestation certificate to the guarded host indicating that the host is healthy and approved.

Next, the host resends a key request to the HGS along with the current health certificate. The HGS examines the health certificate to determine its validity. If the health certificate is valid it decrypts a portion of the state of that VM and then re-encrypts it to the Virtual Secure Mode of the guarded host and sends the key to the guarded host's Virtual Secure Mode.

The guarded host's Virtual Secure Mode decrypts the key and uses it to start the VM. If the VM is moved to another host and attempted to start without the key, it will not start. Likewise, if a user or administrator attempts to start a VM and the Attestation Service determines that they're not authorized, then the VM will not be decrypted and it will not start.

There are two types of attestation modes you can use with the host guardian service:

• Admin-trusted attestation: Allows hosts that you have designated as guarded hosts in Active Directory to decrypt and start shielded VMs. You designate hosts as guarded by placing them in a global security group that is created in AD. A trust relationship must be set up between the fabric AD and the HGS forest. This mode will probably be used by most businesses.
• TPM-trusted attestation: Allows hosts that you've designated as guarded hosts and that are running code that you've identified as trusted to start shielded VMs. Host hardware and firmware must include TPM 2.0 and UEFI 2.3.1 with secure boot enabled. This mode is more complicated to set up, but it's more secure. TPM-trusted attestation is likely to be used by hosting providers.

Requirements and Limitations
There are several requirements for using Shielded VMs and the HGS:

• One bare metal host: You can deploy the Shielded VMs and the HGS with just one host. However, Microsoft recommends that you cluster HGS for high availability.
• Windows Server 2016 Datacenter Edition: The ability to create and run Shielded VMs and the HGS is only supported by Windows Server 2016 Datacenter Edition. This is a big change from Windows Server 2012 where the Standard and the Datacenter editions essentially had feature parity. This is no longer the case.
• For Admin-trusted attestation mode: You only need to have server hardware capable of running Hyper-V in Windows Server 2016 TP5 or higher.
• For TPM-trusted attestation: Your servers must have TPM 2.0 and UEFI 2.3.1 and they must boot in UEFI mode. The hosts must also have secure boot enabled.
• Hyper-V role: Must be installed on the guarded host.
• HGS Role: Must be added to a physical host.
• Generation 2 VMs.
• A fabric AD domain.
• An HGS AD, which in Windows Server 2016 TP5 is a separate AD infrastructure from your fabric AD.

At this point Microsoft Azure doesn't support Shielded VMs. However, Azure does provide disk encryption for compliance purposes.

Deploying the Host Guardian Service
The first step to using Shielded VMs is to add the HGS Role and configure the HGS domain. You can add the HGS using either Windows PowerShell or the Add Roles option in Server Manager (see Figure 2).

To add the HGS role with PowerShell, open an elevated PowerShell console and enter the following Install_WindowsFeature command:

Install-WindowsFeature –Name HostGuardianServiceRole –IncludeManagementTools -Restart

Once the HGS server role is added, the next step is to run the Install-HgsServer cmdlet. This command will set up the Active Directory forest for HGS and configure the HGS service and its dependencies. With the Windows Server 2016 TP5 (the final technical preview prior to last month's release), you need to be sure that the HGS machine isn't joined to a domain before performing these steps. When this cmdlet is run on the first HGS node it promotes the node to the primary domain controller for the specified domain. When it's run on an additional HGS node it promotes the node to a secondary domain controller. The Install-HgsServer command will require that you reboot the system:

$adminPassword = ConvertTo-SecureString -AsPlainText '<password>' –Force
Install-HgsServer -HgsDomainName <"YourHGSdomain.com"> -SafeModeAdministratorPassword $adminPassword –Restart

The -HgsDomainName parameter specifies the HGS AD domain name. The password only applies to the Directory Services Restore Mode password for AD and will not change the password for your administrator's login.

Creating Self-Signed Certificates
Next, you need to create certificates for the HGS service to use for encryption and signing purposes. There are three ways to use certificates with the HGS:

• Your own PKI certificate and a PFX file
• Via a certificate backed by a Hardware Security Module
• With self-signed certificates

For testing and evaluation, it's easiest to use self-signed certificates. However, they're only recommended for testing and proof-of-concept projects. To create a self-signed certificate using PowerShell open an elevated PowerShell console and run the New-SelfSignedCertificate command. Here, the -DNSName can be whatever you choose or you can keep the values. You can use the Export-PfxCertificate command to export the self-signed certificate:

$certificatePassword = ConvertTo-SecureString -AsPlainText '<password>' –Force
$signingCert = New-SelfSignedCertificate -DnsName "signing.relecloud.com"  
Export-PfxCertificate -Cert $signingCert -Password $certificatePassword -FilePath 'C:\signingCert.pfx'

Next, create and export the encryption certificate by running the following PowerShell commands:

$encryptionCert = New-SelfSignedCertificate -DnsName "encryption.relecloud.com"
Export-PfxCertificate -Cert $encryptionCert -Password $certificatePassword -FilePath 'C:\encryptionCert.pfx'

Initialize the HGS Server Using Admin-Trusted Attestation
The next step to using Shielded VMs is to initialize the HGS and set the type of attestation that will be used. Most businesses will probably elect to use Admin-trusted attestation while hosting providers will most likely choose TPM-trusted attestation. You can change the attestation mode later if you need to. To set the HGS to use Admin-trusted attestation, open an elevated PowerShell prompt and run the Initialize-HGSServer cmdlet using the exported signing and encryption certificates. For simplicity the following example uses the same password for the signing and encryption certificates:

$certificatePassword = ConvertTo-SecureString -AsPlainText '<password>' -Force
Initialize-HGSServer -LogDirectory c:\temp -HgsServiceName <YourHGSServiceName> -HTTP -TrustActiveDirectory -SigningCertificatePath C:\signingCert.pfx -SigningCertificatePassword $certificatePassword -EncryptionCertificatePath C:\encryptionCert.pfx
 -EncryptionCertificatePassword $certificatePassword

You may run into the following error while running this command:

New-ScheduledTaskTrigger : Method "NewTriggerByDaily" not found

If so, running the following command should resolve the problem:

mofcomp C:\Windows\System32\wbem\SchedProv.mof

Setting Up DNS Resolution and Creating a Security Group
For Admin-trusted attestation you typically need to set up necessary DNS forwarding from the HGS domain to the fabric domain. You also need to create a one-way forest trust from the HGS domain to the fabric domain. This is because Admin-trusted attestation identifies legitimate hosts through a global AD security group in the fabric DNS domain. You can use theAdd-DnsServerConditionalForwarderZone PowerShell command to create a DNS forwarder on the HGS system. You can add multiple DNS servers separated by commas. The netdom command can be used to setup the trust relationship:

Add-DnsServerConditionalForwarderZone -Name "<YourDomain.com>" -ReplicationScope "Forest" -MasterServers <DNSserverAddress1>
netdom trust relecloud.com /domain:<YourDomain.com>/userD:fabrikam.com\Administrator /passwordD:<password> /add

You also need to set up a DNS forwarder from the fabric domain to the HGS domain. To set up a DNS forwarder you can run the Add-DnsServerConditionalForwarderZone cmdlet on the fabric DNS server:

Add-DnsServerConditionalForwarderZone -Name 'relecloud.com' -ReplicationScope "Forest" -MasterServers <IP addresses of HGS server>

Admin-trusted attestation identifies trusted hosts through a designated AD security group. To create the security group, go to the fabric domain and use Active Directory Users and Computers to create a new global security group. This security group will be used to identify the hosts that are trusted to run shielded VMs. Then on the HGS server use Add-HgsAttestationHostGroup to register the group with HGS:

Add-HgsAttestationHostGroup -Name "<GuardedHostGroup>" –Identitifier "<SID>"

The <GuardedHostGroup> is a friendly name for the guarded host group in HGS. You cannot use spaces or other common punctuation except hyphens as part of the name. You can get the SID by running the Get-ADGroup command on the fabric AD:

Get-ADGroup '<GuardedHostGroup>'

To verify that the guarded host group was successfully added you can run the Get-HgsAttestationHostGroup command. Last, you can use the Get-HgsTrace cmdlet to check if the HGS has been configured correctly. The cmdlet checks for common misconfiguration problems,l as well as best practices:

Get-HgsAttestationHostGroup
Get-HgsTrace -RunDiagnostics

For production environments Microsoft recommends that HGS should be set up in a high-availability cluster. This enables you to ensure that shielded VMs can be powered on even if one of the HGS nodes goes down. Additional HGS nodes can be installed using the same procedures described earlier.

Deploying Shielded VMs
Once the HGS has been configured you can use it to manage shielded VMs. There are several different methods you can use to deploy shielded VMs. Microsoft has built-in support for HGS into System Center Virtual Machine Manager 2016 (VMM). You can also deploy a shielded VM using the Windows Azure Pack or by manually importing the guardian metadata into an existing Hyper-V VM. Microsoft recommends using a VMM Service Template to create new shielded VMs because this ensures there's no suspect code running in the VM like there could be with an existing VM.

Solving the VM Protection Problem
Controlling access to VMs is a problem no matter what hypervisor you use. Hyper-V, VMware vSphere and KVM all share the same security issues. The new HGS in Windows Server 2016 Hyper-V with its Shielded VMs offers a unique solution to the problem of securing VMs from all unauthorized access. Although the HGS has quite a few moving parts and is somewhat complex to set up, it does enable you to restrict VMs to only running on trusted hosts, as well as prevent malware and unauthorized admins from compromising your VMs.