Hardening - VM Security

1 year ago
14 October 2022
5 comments
1568 views

Userlevel 6

Viperian
Product Strategy
22 comments

VM Security

The last decade virtualization has been rapidly adopted by almost any organization in the world and became a standard industry practice. You may deploy Veeam Backup & Replication components as either a physical or virtual server. For most organizations, virtual is the recommended deployment for Veeam Backup & Replication components as the hypervisor already provides high availability, fault tolerance and great flexibility in sizing and scaling as the environment grows.

Looking at the Veeam Backup & Replication components, the only component that we advise to deploy physical are Veeam Backup Repositories, but only when you have control over the hardware. This is because you still need a physical medium to place backup data on and you do not want to store it in the environment you are protecting. There are of course cases where all components including Veeam Backup Repositories will be virtualized, think of placement in Amazon AWS, Microsoft Azure or IBM Cloud.

Enabling Windows Virtualization Based Security with vSphere 6.7 or newer is a secure way to make sure that running Windows 10, Windows Server 2016 or newer Windows virtual machines even more protected with secure memory areas being restricted. This makes attacks such as “pass-the-hash” and “pass-the-ticket” exponentially more difficult to exploit. VMware has made turning this feature on real easy with vSphere 6.7. Literally a single checkbox enables all the needed hardware emulated features to allow Windows 10/Server 2016+ to be able to setup in VBS mode using Hyper-V in a nested configuration within vSphere 6.7.

Best Practices

Protect a VM as you would do with a Physical server
Use hardened templates to Deploy Virtual Machines
Disable Unnecessary Functions Inside VMs
Minimize Access to the VMs with principle of least privilege
Leverage Virtualization-based Security (VBS)
Add a vTPM 2.0

General Virtual Machine Protection

A virtual machine is the equivalent of a physical server. Apply the same security measures for virtual machines as you would do for physical servers. Patch operating systems, software, and firmware on VMs. Most hacks succeed because there is already vulnerable software in use which is not up-to-date with current patch levels. So make sure all software and hardware where Veeam components are running are up-to-date.

One of the most possible causes of a credential theft are missing guest OS updates and use of outdated authentication protocols. To mitigate risks, follow these guidelines:

Ensure timely guest OS updates on backup infrastructure servers. Install the latest updates and patches on backup infrastructure servers to minimize the risk of exploiting guest OS vulnerabilities by attackers.
Choose strong encryption algorithms for SSH. To communicate with Linux servers deployed as part of the backup infrastructure, Veeam Backup & Replication uses SSH. Make sure that for the SSH tunnel you use a strong and proven encryption algorithm, with sufficient key length. Ensure that private keys are kept in a highly secure place, and cannot be uncovered by a 3rd party.

Use Templates to Deploy Virtual Machines

Installing operating systems and applications manually is prone to error. You introduce the risk of misconfiguration. By using a template, you can harden that template upfront and create a VM with a known baseline level of security. Every time you now deploy a new VM from that template you have a baseline level of security.

Disable Unnecessary Functions Inside VMs

Remove or disable all non-essential services, applications and utilities from the VMs where Veeam components are deployed. While these service and/or applications may offer useful features to the administrator, if they provide ‘back-door’ access to the system, they must be removed during the hardening process. Think about additional software like web browsers, java, adobe reader and such. Also think about disconnecting unused physical devices, such as CD/DVD drives, floppy drives and USB peripherals. All parts which do not belong to the operating system or to active Veeam components, remove it. It will make maintaining an up-to-date patch level much easier. Always evaluate whether a particular service, function or application is necessary.

Minimize Access to the VMs with principle of least privilege

Not all administrator users must have the Administrator role. Instead, create a custom role with the appropriate set of privileges and assign it to other administrators. Users with the vCenter Server Administrator role have privileges on all objects in the hierarchy. For example, by default the Administrator role allows users to interact with files and programs inside a virtual machine's guest operating system. Assigning that role to too many users can lessen virtual machine data confidentiality, availability, or integrity. Create a role that gives the administrators the privileges they need, but remove some of the virtual machine management privileges.

Virtualization-Based Security (VBS)

Microsoft Virtualization Based Security (VBS), is a feature of the Windows 10 and Windows Server 2016 or later (64-bit) operating systems and provides isolation of secure kernel from normal operating system. Vulnerabilities and 0-day attacks in the OS cannot be exploited because of this isolation. The Hyper-V hypervisor plays the arbiter between applications, memory pages and the permissions that applications have to write across system memory.

VBS effectively reduces the Windows attack vectors because it uses the Windows hypervisor to create this Virtual Secure Mode (VSM), and to enforce restrictions which protect vital system and operating system resources, or to protect security assets such as authenticated user credentials. Even if malware gains access to the OS kernel the possible exploits can be greatly limited and contained, because the hypervisor can prevent the malware from executing code or accessing platform secrets when VBS is enabled.

Examples of Windows security solutions enabled by VBS are:

Hypervisor code integrity policy (HVCI) blocks the execution of unsigned or improperly signed binaries. HVCI leverages VBS to run the code integrity service inside a secure environment, providing stronger protections against kernel viruses and malware.
Windows Defender Credential Guard, which will isolate and protect secrets (e.g. NTLM password hashes and Kerberos ticket-granting tickets) which prevents malware from accessing credentials by trying to pass-the-hash or pass-the-ticket.
Windows Defender Device Guard, which will lock a device down so that it can only run trusted applications that are defined in code integrity policies.
Virtual trusted platform modules (vTPMs) for shielded VMs.

Virtualization based security is a foundation technology that enables a broad range of advanced security features in Windows Server. To enable VBS within the Microsoft Windows operating system, you will need to following minimum prerequisites in hardware, firmware and software:

64-bit processor with virtualization extensions like Intel VT-X or AMD-v
Processor’s virtualization support includes Second Level Address Translation (SLAT), either Intel VT-X2 with extended Page Tables (EPT or AMD-v with Rapid Virtualization Indexing (RVI)
(Optional) A Trusted Platform Module 2.0 (TPM) - optional but highly recommended for VMs
Input-Output Memory Management Unit (IOMMU) – All I/O devices capable of DMA must be behind an IOMMU or SMMU (Intel VT-D, AMD-Vi, ARM64). An IOMMU can be used to enhance system resiliency against memory attacks.
UEFI v2.6 or newer firmware running in Native Mode with Memory Attributes Table (MAT)
EFI Page Protection - All entries must include attributes EFI_MEMORY_RO, EFI_MEMORY_XP, or both.
Secure Memory Overwrite Request (MOR) revision 2 using a UEFI secure variable
Secure Boot
Windows System Management Mode Security Mitigations Table (WSMT) specifications supported by system firmware
All drivers must be compatible with Hypervisor Enforced Code Integrity (HVCI) standards
Microsoft Windows installed with all the above settings enabled and configured correctly

IMPORTANT: If you turn on Secure Boot for a VM, it means only signed drivers are allowed in that VM.

Secure Boot

UEFI Secure Boot is a security standard that helps ensure that your PC boots using only software that is trusted by the PC manufacturer. For certain virtual machine hardware versions and operating systems, you can enable secure boot just as you can for a physical machine.

vSphere 6.7

Starting with vSphere 6.7, you can now enable Microsoft VBS on supported Windows guest operating systems. Just create a new virtual machine through vCenter server and at step 5 compatibility select ESX 6.7 or later to make sure you are at least running with virtual hardware version 14 or newer.

As guest operating system select a 64-bit Windows version like Windows Server 2016 or Windows 10 or newer.

After selecting a Microsoft Windows Server 2016 or later (64-bit) Guest OS you will be able to Enable Windows Virtualization Based Security.

NOTE: Just above the Next button you will see what virtual hardware version you selected.

After checking the checkbox enable VBS, VMware will take care of all necessary changes to the VM, like: Expose hardware assisted virtualization (Hardware virtualization), I/O MMU turned on, UEFI firmware and Secure Boot is enabled.

Now you are set from the VMware side but also within Windows you need to enable VBS.

Enabling VBS within Microsoft Windows

Ensure that virtualization-based security (VBS) has been enabled on the virtual machine. Now logon to Microsoft Windows and edit the local group policy to turn on VBS and choose other VBS security options.

Click Start > type and then click Edit group policy (gpedit.msc)

Navigate to Computer Configuration > Administrative Templates > System > Device Guard > Turn On Virtualization Based Security. Set the policy to Enabled.

Also change the following settings on the VBS Policy:

Select Platform Security Level: Secure Boot and DMA Protection
Virtualization Based Protection of Code Integrity: Enabled with UEFI lock
Tick – Require UEFI Memory Attributes Table
Credential Guard Configuration: Enabled with UEFI lock
Secure Launch Configuration: Enabled

IMPORTANT: Are you going to manage this machine remotely through policies choose the option Enabled without UEFI lock option then.

(Optional) For Microsoft Windows versions less than Redstone 4, in the Windows Features control panel, enable the Hyper-V platform.

Make sure you reboot the Virtual Machine after changes have been made. You can verify if VBS is enabled and running properly by running system information in Windows.

vTPM

The Virtual Trusted Platform Module (vTPM) feature lets you add a TPM 2.0 virtual cryptoprocessor to a virtual machine from VM hardware version 14 or newer (vSphere 6.7 or newer). It is not enabled by default when you select VBS, because it needs vSphere VM encryption and that is depended on a Key Management Server connected to vCenter Server.

A vSphere vTPM is not depended on a physical TPM and uses vSphere VM Encryption to be able to write data with very strong encryption. Data written to be secured in the vTPM is written to the “.nvram” file which is encrypted using VM encryption. By using VM Encryption the VMs stay portable and a VM with a vTPM can be vMotioned, backed up, etc. Encryption is only performed on the VM “Home” files and not the VMDK’s by default. Impact to performance is minimal because only a few hundred kilobytes/megabytes of files are being encrypted.

The VM is now marked as encrypted, which gives the possibility to leverage the “No Cryptography Administrator” role. This secures console access, prevents downloads of the VM from the datastore and enforces a “least privilege” operational model!

IMPORTANT: A physical TPM has a number of technical challenges. It’s not designed for 100’s or 1000’s of VM’s to store their credentials. It’s too small for that. Storage in a TPM is measured in kilobytes, not gigabytes. It’s also a serial device so it is very slow.

Requirements for a vTPM

To use a vTPM, your vSphere environment must meet these requirements:

VM needs EFI firmware, Hardware version 14 or higher
vCenter Server 6.7 or newer
Virtual Machine encryption to encrypt the VM home files.
KMS server configured for vCenter Server (virtual machine encryption depends on KMS)
Guest OS being 64 bit and Windows Server 2016, Windows 10 or newer