Latest posts by Vladan Seget (see all)
- VMware vSphere Replication (VR) 8.2 limitations - Fri, Feb 21 2020
- Install and activate Windows subsystem for Linux (WSL) 2 on Windows Server - Fri, Feb 14 2020
- Upgrade from FRS 2008R2 to DFSR 2019 SYSVOL replication - Fri, Feb 7 2020
One must consider securing the infrastructure not only from the hardware perspective (BIOS, boot, and physical access) but also from the "software" (at the guest OS level) and virtualization layer (VMs and VMKDs) perspective.
Physical CPU vulnerabilities and their mitigation ^
Since 2018 there have been many CPU security flaws you need to patch at the BIOS level of the host or at the VMware level (virtualization layer). Both ways usually result in a more secure system but with a loss of performance.
While these patches might result in a loss of performance, it's certainly very important to follow best practices and the recommended patching and microcode updates. VMware has released these patches on purpose to protect your environment, and you should apply them to mitigate these speculative execution vulnerabilities.
You should also update your physical host's BIOS and firmware to the latest version.
Host access limit ^
VMware ESXi has a special mode called "lockdown mode" that can help secure the ESXi host access levels by limiting access and restricting remote login capability.
Via lockdown mode, you can specify whether to enable the direct console user interface (DCUI) or not and whether is it possible to log in directly to your host or only via the vCenter Server.
You might only want to enable the normal lockdown mode, which does not stop the DCUI service. This lets you still log into your ESXi host if the connection to the vCenter Server is lost.
Imagine that you activate the strict lockdown mode and your vSphere Web Client loses its connection. In this case, before activating, you must define privileged accounts that can log into the ESXi host's DCUI and exit the lockdown mode. Only these accounts can access the DCUI.
If the connection to the vCenter Server is lost and the vSphere Web Client is no longer available, the ESXi host becomes unavailable (with the exception that the ESXi Shell and SSH services are enabled and exception users are defined). If you cannot restore the connection to the vCenter Server, the only way to reconnect with your host is via reinstallation.
You should also configure a firewall rule to restrict access to the host and thus limit the traffic that can reach your ESXi hosts (for example, by excluding all other networks).
Virtualization-based security ^
Virtualization-based security (VBS) is a feature of the Windows 10 and Windows Server 2016 OSes. You cannot protect Linux servers or VMs with another OS. A performance hit might occur as well.
VBS uses hardware and software virtualization to enhance Windows system security by creating an isolated, hypervisor-restricted, specialized subsystem. It also uses hardware virtualization features to create and isolate a secure region of memory from the OS.
It uses the underlying hypervisor to create this virtual secure mode, so as such, it enforces restrictions that protect system and OS resources and local user login password credentials.
Another post on 4sysops details VBS in VMware vSphere environments.
Remember, you'll need to create a VM that uses hardware version 14 or later and have Windows Server 2016, 2019, or Windows 10 as an OS.
VMware vSphere 6.7 introduced VBS, which you can enable via the vSphere client. Basically, it is a two-step process. First, you must enable the feature at the VM level.
Once you've done this, turn on VBS inside of the Windows OS by editing the group policy and choose other VBS-related security options.
You'll need to open the local group policy editor. You can use a shortcut by typing "gpedit.msc" from a command prompt. Then navigate to Computer Configuration > Administrative Templates > System > Device Guard > Turn on Virtualization Based Security. Set the policy to Enabled.
VM encryption ^
You can apply virtual disk encryption at the virtual infrastructure level to protect your VMDKs and prevent the data from being copied and extracted.
You can create an encrypted VM from the vSphere Web Client. You can choose which disks to encrypt. Later, you can also add disks and set their encryption policies.
You can encrypt only certain virtual disks or all VM disks. It applies a per-VM (and per-virtual disk) encryption policy.
To use virtual disk encryption, you'll need to set up a key management server (KMS) cluster, which VMware does not provide, but many third-party partners do. It is however a paid add-on option necessary for setting up VM encryption and virtual disk encryption within your environment.
Patch your guest OS ^
This best practice does not differ from traditional physical environments. You always need to patch your OSes. When running hundreds or thousands of VMs within your environment, you'll have more work, but it is a necessity.
With Linux or Windows VMs, you can use automatic patch installation and schedule rebooting your server or desktop VMs outside of business hours.
Larger organizations can manage the patches with Group Policy Objects (GPOs) at a domain level.
If you back up your infrastructure on a daily basis, it's best to schedule the patch installation just after your daily backup job. If anything goes wrong, just quickly restore the VM from your latest backup.
VMware Tools update ^
For VMware environments, you can use the VMware vSphere Update Manager (VUM), which can help you automate maintaining the up-to-date level of VMware Tools.
The advantage of using VUM is that you can set it up to create a snapshot before installing any patches. In this way, you can easily and rapidly revert and discard any changes a "bad" patch caused. In some cases in the past, patches to Microsoft OSes caused problems or even deleted files, but Microsoft corrected these issues rapidly. However, it's always better to have your own solution and be independent of Microsoft's solution when it comes to security and backup of your environment.
Final words ^
We could go on and on, and even beyond. For example, by using two-factor authentication (2FA) on your domain controller (DC) servers, you could perhaps avoid unwanted internal access or even a ransomware attack. In the past, we have seen ransomware on the rise, leaving administrators with no solution but to pay the ransom to decrypt their files. To mitigate such attacks, 2FA with offline backups and an air gap might be a suitable way to stay protected.