shielded vms logo

How to protect Virtual Machines hosted in Data Centers

In today’s age of Cloud Computing, each user has their own cloud storage for photos and an ever increasing number of companies rent cloud servers. This raises critical questions about the security of the stored information. Users can trust the cloud or crypto containers to protect their data, but companies are in a much worse position, because they are transferring not only data, but also computation to the cloud.

Virtual machines are especially vulnerable, since hackers can easily access VMs if the host is compromised. Until recently, existing hypervisors, including VMware, Xen, and Hyper-V hypervisors, have not been able to offer comprehensive VM protection.

If an attacker acquires physical access to the server, then disk encryption is the only hope, but even that is not always enough. Certainly, a data center assumes some responsibility for security when it leases a server, but then you must trust the data center’s administrators.

After Windows Server 2016 was released, Microsoft decided to pay more attention to the security of host and virtual infrastructure. Now it is possible to isolate VMs from a Hyper-V host administrator. Virtual TPM encryption enables data encryption using BitLocker.

Thus, new technologies make it possible to put virtual machines on secondary servers or in corporate data centers while simultaneously increasing security by separating roles for physical and virtual access.

Used technologies

Shielded VM is a technology to isolate virtual machines from the host and protect VMs from accidental or deliberate actions by a host administrator and malware.

Shielded VM requires a Host Guardian Service (HGS) server which provides an access key and checks the health of the Hyper-V host.

HGS supports two types of attestation:

HGS supports attestation

  1.  TPM-trusted attestation, where verification is based on the TPM identity, OS boot sequence, and code integrity policy. So, you can be sure that the hosts are running only approved code.
  2.  Admin-trusted attestation, where verification takes place according to AD security group membership.

When launching the virtual machine, the protected host is attested by the HGS server, which decides whether to grant an access key for the virtual machine.

Admin-trusted attestation should be used within an enterprise when you want to isolate administrators from VM access.

TPM-trusted attestation is best used when placing a VM on a server to isolate the data and VM from the data center’s employees.

The connection between the HGS server and the protected host is carried out via HTTP/HTTPS protocol. HTTPS is not required for secure communication, but if you want to enable HTTPS, you will need an additional certificate. In case of AD certification, you need to configure a one-way domain trust.

Virtual Secure Mode (VSM) is a technology based on virtualization which allows you to isolate security-critical operations into a mini OS.

There are two other technologies that work in VSM:

technologies that work in VSM

  1.  Device Guard – data validation of UEFI firmware and kernel-mode drivers (code integrity monitoring);
  2.  Credential Guard – isolation of the user authentication process (LSA).

How VSM works:

The main OS runs in a virtual environment. A hypervisor acts as a host OS, thereby limiting access to RAM. As a result, malicious software running on the host cannot access the VSM memory, even with administrator rights. Also, this arrangement should protect against DMA attacks.

How to deploy Shielded VM

Ordering Shielded VM assumes that the Hyper-V host and HGS server are located in the data center facilities (as in Microsoft Azure). In this case, a shielded virtual machine can be created independently or using a provided template.

To create a Shielded VM independently, a customer deploys and configures a virtual machine on his or her PC, and then encrypts it with a key issued by the data center. After that, the VM is transferred to the data center.

In the second case, the customer only creates a PDK file, which protects the VM created from a template. The PDK file connects the template file with the HGS server. But you need to make sure that the template does not contain any malware.

The first method appears more secure, since a VM file arrives on the host already encrypted. In any case, data center admins will not receive open access to the VM.

The HGS server is the only place exposed to attacks because:

  • The HGS administrator can relax the requirements of the security policy;
  • An attacker with administrative privileges can try to get access keys;
  • HGS requires AD but TPM is not mandatory, so keys are most likely to be stored in the clear.

Considering this, we came up with an idea to check how Shielded VM would work if the HGS server is located in its infrastructure. This will protect virtual machines even better. This method can also be used if the data center does not provide Shielded VM service. The disadvantage of this approach is that this structure must be administered manually.

The question of a hypervisor administrator replacing an HGS server may arise – after all this simply requires setting a new address. Protection against this is implemented in a rather simple way. The created VM is encrypted using the HGS’s public key, so a different HGS server cannot issue a key to start it.

You should also understand that Shielded VM only encrypts VM configuration files. The VHDX file remains unencrypted. To encrypt it, you must enable vTPM and encrypt the disk using BitLocker.

This combination of new technologies provides reliable protection:

  • The human factor is eliminated;
  • Keys are transmitted in encrypted form;
  • Servers are protected by new technologies that check code integrity;
  • Allowed applications are whitelisted;
  • The VM is isolated from the host.

All these aspects make it possible to protect against malicious software targeting the Hyper-V host and grant access to a virtual machine only to the owner, safeguarding it from the actions of administrators or anyone who has obtained administrator privileges.

Requirements for Hyper-V and HGS servers

The following requirements are specified for TPM attestation. AD attestation is less demanding, but it provides much less protection.

HGS:

  • Window Server 2016

Hyper-V:

  • Windows Server 2016 Datacenter Edition
  • UEFI Secure Boot
  • TPM v2
  • IOMMU (VT-d)

How to setup

Suppose you have leased a dedicated server and want to protect it. TPM attestation will be used. The connection between the host and HGS will be established through HTTP. If the HGS server does not have a white IP address, you will need to use port 80 or a reverse proxy.

Server HGS role setup and configuration

HGS Setup and Domain Creation

Install-WindowsFeature -Name HostGuardianServiceRole -IncludeManagementTools -Restart

HGS requires a domain. It can be connected to an existing domain, but it is recommended to create a separate domain to improve security. Before executing the following commands, be sure the computer is not connected to a domain.

$adminPassword = ConvertTo-SecureString -AsPlainText '' -Force
Install-HgsServer -HgsDomainName 'relecloud.com' -SafeModeAdministratorPassword $adminPassword -Restart

HGS Setup and Domain Creation

Creating self-signed certificates

For testing purposes, we created self-signed certificates, but in the real environment it is better to use a PKI.

$certificatePassword = ConvertTo-SecureString -AsPlainText '' -Force

$signingCert = New-SelfSignedCertificate -DnsName "signing.relecloud.com"

Export-PfxCertificate -Cert $signingCert -Password $certificatePassword -FilePath 'C:\signingCert.pfx'

$encryptionCert = New-SelfSignedCertificate -DnsName "encryption.relecloud.com"

Export-PfxCertificate -Cert $encryptionCert -Password $certificatePassword -FilePath 'C:\encryptionCert.pfx'

Creating self-signed certificates

Creating self-signed certificates

Initializing the HGS server

Specify the encryption certificates and signatures. Select the attestation method.

$certificatePassword = ConvertTo-SecureString -AsPlainText '' -Force

Initialize-HgsServer -HgsServiceName '' -SigningCertificatePath 'C:\signingCert.pfx' -SigningCertificatePassword $certificatePassword -EncryptionCertificatePath 'C:\encryptionCert.pfx' -EncryptionCertificatePassword $certificatePassword [-TrustActiveDirectory | -TrustTPM]

Initializing the HGS server

Initializing the HGS server

Adding a protected Hyper-V host

Get the TPM identity

This procedure must be performed for each protected host.

(Get-PlatformIdentifier -Name '').InnerXml | Out-file .xml -Encoding UTF8

Get the TPM identity

Add the resulting file to the HGS server.

Add-HgsAttestationTpmHost -Path .xml -Name  -Force

Get the TPM identity

Create and apply a Code Integrity policy

While creating a policy, all the installed programs are scanned and added to the whitelist. Before creating a policy, make sure that:

  • The system is free from viruses and malware;
  • The required software is reliable and already installed.

We recommend checking the policy in audit mode first. In doing so, executables prohibited by the policy will be displayed in a log.

Note that this scanning takes time.

New-CIPolicy -Level FilePublisher -Fallback Hash -FilePath 'C:\temp\HW1CodeIntegrity.xml' -UserPEs
ConvertFrom-CIPolicy -XmlFilePath 'C:\temp\HW1CodeIntegrity.xml' -BinaryFilePath 'C:\temp\HW1CodeIntegrity.p7b'

Code Integrity policy

Code Integrity policy

Rename the .p7b file to SIPolicy.p7b and copy it to the C:\Windows\System32\CodeIntegrity\SIPolicy.p7b folder.

Reboot the PC and check the system performance under an expected typical load. Turn off audit mode after a successful check.

Set-RuleOption -FilePath 'C:\temp\HW1CodeIntegrity.xml' -Option 3 -Delete

ConvertFrom-CIPolicy -XmlFilePath 'C:\temp\HW1CodeIntegrity.xml' -BinaryFilePath 'C:\temp\HW1CodeIntegrity_enforced.p7b'
Copy-Item -Path '' -Destination 'C:\Windows\System32\CodeIntegrity\SIPolicy.p7b'

Restart-Computer

If you are planning to defend multiple identical hosts, you can create just one CI policy.

We recommend saving the original XML file to eliminate the need to rescan if you make changes to the policy.

When the policy is applied, be careful while updating or adding kernel-mode drivers, as this can result in system boot failure.

Register the policy on the HGS server

Add-HgsAttestationCIPolicy -Path  -Name ''

Register the policy HGS server

Create a TPM baseline policy

This policy is based on PCR registers (Platform Configuration Registers) located in the TPM module. They store values to check the integrity of system metrics, from loading the BIOS to system shutdown. For example, if the boot order is changed by a rootkit, this will be reflected in the PCR registers.

A policy is created for a class of identical hardware hosts. You must have Hyper-V installed.

To execute the following command, you must enable Secure Boot, IOMMU (VT-d), and Virtualization Based Security:

Install-WindowsFeature Hyper-V, HostGuardian -IncludeManagementTools -Restart

Get-HgsAttestationBaselinePolicy -Path 'HWConfig1.tcglog'

You can use the -SkipValidation flag, which runs the command without correcting errors.

Create a TPM baseline policy

Add TCGlog on the HGS server

Add-HgsAttestationTpmPolicy -Path .tcglog -Name ''

Add TCGlog on the HGS server

Check the HGS server status

This is the final step for HGS server configuration. To check if everything is correct, run diagnostics.

Get-HgsTrace -RunDiagnostics

Check the HGS server status

Check the HGS server status

Connect the Hyper-V host to the HGS server

To connect a protected host to the HGS server, it is sufficient to specify the server URL.

Set-HgsClientConfiguration -AttestationServerUrl 'http:///Attestation' -KeyProtectionServerUrl 'http:///KeyProtection'

Hyper-V host to the HGS server

Correct configuration output should display:

  • IsHostGuarded: true
  • AttestationStatus: passed

If configuration fails, AttestationStatus will display the error details.

How to create a shielded virtual machine

Get the HGS description file required to bind the Virtual Machine to the server.

Invoke-WebRequest http://<"HGSServer">FQDN>/KeyProtection/service/metadata/2014-07/metadata.xml -OutFile C:\HGSGuardian.xml

create a shielded virtual machine

You need to create a VM on a standalone machine running Windows Server 2016, which is not configured to use HGS.

Create a new 2nd generation virtual machine and install the operating system on it. Configure RDP settings, ensure it works properly, and encrypt it with BitLocker.

create a shielded virtual machine

Creating a Shielded VM

Enter the VM name:

$VMName = 'SVM'

Stop the VM:

Stop-VM –VMName $VMName

Create an owner certificate:

$Owner = New-HgsGuardian –Name 'Owner' –GenerateCertificates

Import the server certificate:

$Guardian = Import-HgsGuardian -Path 'C:\HGSGuardian.xml' -Name 'TestFabric' –AllowUntrustedRoot

Create a Key Protector:

$KP = New-HgsKeyProtector -Owner $Owner -Guardian $Guardian -AllowUntrustedRoot

Enable Shielding:

Set-VMKeyProtector –VMName $VMName –KeyProtector $KP.RawData
Set-VMSecurityPolicy -VMName $VMName -Shielded $true

Enable the vTPM on the virtual machine:

Enable-VMTPM -VMName $VMName

Creating a Shielded VM

After you finish the configuration and the VM protection is turned on, move the VM to a secure host. To do this, export the machine, move the files to the host, and import it in the Hyper-V console.

At this stage the setup is complete, the VM is shielded.

Check the Shielded VM

When attempting to connect to the VM via the Hyper-V console, you will see this message:

Check the Shielded VM

Also, VM settings will display a warning that it is impossible to change the security policy:

Check the Shielded VM

The virtual machine is protected by BitLocker:

Check the Shielded VM

Thus, we have configured Shielded VM, which provides higher security for virtual machines. If you have any questions, feel free to post them in the comment section below.

More articles at Servilon

Amazon cloud storage failure causes widespread disruption

Amazon.com Inc (AMZN.O) blamed human error for the disruption in its cloud services that resulted in widespread glitches for its clients from news sites to government services on Tuesday.

An incorrect command led to the removal of a larger set of servers than intended, the company said in a blog post on Thursday.

The disruption in the company’s Simple Storage Service, or Amazon S3, lasted for more than 3-1/2 hours and impacted sending and receiving clients’ data.

The company said it will make changes to improve the recovery time of its key S3 subsystems.