VMware vSphere best practices

Security is a prime consideration for today’s organizations using technology solutions for business-critical services. Most businesses today are running most if not all of their production infrastructure inside of virtual environments. Despite the rise of container-based solutions, virtual machines are still the primary method of consuming resources for today’s production environments.

VMware vSphere is still the enterprise leader virtualization platform running most of today’s enterprise virtual machines. With the release of VMware vSphere 6.7, VMware continues to push the innovation of enterprise virtualization. With VMware vSphere 6.7, there are new technologies related to virtualization security in the realm of the VMware virtual machine.

Let’s take a look at securing VMware vSphere 6.7 Virtual Machine Best Practices and see what recommended actions should be taken to ensure security in the virtual machine itself.

Securing VMware vSphere 6.7 Virtual Machine Best Practices

When it comes down to the purpose of a hypervisor, it is to run virtual machines. The virtual machine generally speaking performs the primary role of serving out production data and services. These may include serving out files, databases, email services, or applications. Aside from securing the hypervisor itself, there are virtual machine security considerations to be made in VMware vSphere 6.7 that need to be taken into account and implemented to ensure the virtual machine itself is properly secured.

Let’s take a look at the following points for consideration with virtual machine security in VMware vSphere 6.7.

• General Virtual Machine Protection
• Deploying VMs using Templates
• Securing the VM Console in vSphere
• Limiting VM resource usage
• Disabling unnecessary VM functions
• Use Virtualization-Based Security and vTPM 2.0

Let’s examine each of these in a bit more depth to understand how they allow for better security at the virtual machine level.

General Virtual Machine Protection

When we thinking about a virtual machine, there can be a misconception in perception that a VM is a totally different entity than a physical server. However, this is generally not the case when it comes to general best practices within the guest operating system. This includes making sure the following are in place:

• Guest operating system patching – The guest operating system running inside a virtual machine, like a physical server, needs to be patched regularly with Windows or Linux guest operating system patches. Applying operating system patches is one of the best protections against many exploits which tend to compromise known vulnerabilities that these patches resolve. Keeping pates up to data ensures the best security within the guest VM from an operating system perspective
• Antimalware Software – VMs like physical nodes typically need to have some type of antimalware software in place to ensure scanning and remediation of any malware that may be found on the guest operating system. Ensuring the antimalware software is up-to-date and scanning properly is also a priority when thinking about security
• Controlling Serial port access – Serial ports allow for connecting physical devices to virtual machines and can be connected via passing these devices from the host to the VM. Serial port connecting can allow low-level access to a VM which may be concerning from a security standpoint. Limiting VMs that have serial port access and those to have access to connect these devices to VMs certainly is a best practice from a security standpoint

Deploying VMs using Templates

In thinking about the security of virtual machines, deploying virtual machines via templates may not rank high on the list of security objectives. However, using templates to deploy virtual machines is a security best practice.

Why? Each time an operating system is loaded by hand manually and applications are installed in this way, there is a risk that something can get missed on each subsequent system that is provisioned. In using a virtual machine template, you are creating a “master” generalized image of a VM and then deploying each subsequent VM from that master image. As long as the master image is verified from an installation and security standpoint, you can be confident that each VM provisioned from the master VM, will contain the same installed software, applications, security patches, and other configuration that makes for verifying the resulting VM is configured correctly and secured.

Securing the VM Console in vSphere

The VM Console is a powerful mechanism for managing a virtual machine inside of VMware vSphere. The VM Console is equivalent to having a monitor connected to a server. In the VMware vSphere environment, users with access to the console, also have access to the power management as well as the ability to connect and disconnect devices, media, etc. So, it can truly be a dangerous vehicle for administration in the wrong hands.

What is recommended from a security best practices standpoint?

• Use remote management software to access guest operating systems running inside a virtual machine. These may include Microsoft Remote Desktop for Windows virtual machines or SSH for virtual machines running Linux
• Grant VM Console access only when necessary and limit the access of the VM Console to only 1 connection per the security configuration best practice recommendation

Procedure to limit the number of VM Console connections:

• Find the virtual machine in the vSphere Web Client inventory

1.                   1. To find a virtual machine, select a datacenter, folder, cluster, resource pool, or host
2.                   2. Click the Related Objects tab and click Virtual Machines

• Right-click the virtual machine and click Edit Settings
• Select VM Options
• Click Advanced and click Edit Configuration
• Add or edit the parameter RemoteDisplay.maxConnections and set the value to 1
• Click OK

Limiting VM resource usage :

By default, in VMware vSphere, a virtual machine can take as many resources as needed by using the configured hardware that is contained on the virtual machine. All VMs share resources equally. If a particular virtual machine is able to consume so many resources that other virtual machines on the host have degraded performance or are no longer able to function, a Denial of Service attack using a VM could happen.

To circumvent this as a possibility, Shares and resource pools can be used to prevent a denial of service attack that could allow one virtual machine to consume all available resources. To do this:

• Right-size virtual machines with only the needed resources in the vSphere environment
• Use shares to guarantee resources to critical VMs
• Group virtual machines with similar resources requirements into resource pools
• Within each resource pool, leave the shares set to the default value to ensure each VM has the same resource priority
• This will ensure that a single VM will not be able to monopolize resource usage on the vSphere ESXi host

Disabling unnecessary VM functions

In the context of security, disabling unnecessary VM functions serves a meaningful purpose. When looking at a virtual machine when compared to a physical server, one of the differences is a virtual machine generally does not require as many functions or services as a physical server. Eliminating anything that is not needed within a VM lessens the attack surface and the security vulnerabilities that may be attached to those unnecessary functions.

What may be included in unnecessary functions?

• Unused services – Common services such as file services or web services should not be running inside a VM unless they are needed
• Unused physical devices – Attached CD/DVD drives, floppy drives, USB, serial and other ports should be disconnected or removed unless they are being used/needed
• Unused functionality – VMware shared folders and copy/paste operations should be disabled unless needed
• Screensavers – Disable screensavers
• Do not run X Windows on top of Linux if not needed – This creates security vulnerabilities unless it is needed

By lessening the attack surface and eliminating unnecessary functions, the security posture of the virtual machine is greatly increased.

Use Virtualization-Based Security and vTPM 2.0 :

New with vSphere 6.7 is the ability to utilize Virtualization-Based Security which allows vSphere virtual machines to be compatible with Microsoft’s new VBS security in Windows 10 and Windows Server 2016 and higher. This allows for a hypervisor protected space where credentials and other sensitive information are stored which makes it exponentially more difficult for an attacker to steal credentials.

Virtual TPM is now possible with vSphere 6.7 VMs which allows greatly enhancing the security features of a guest VM. The vTPM functionality allows adding a virtualized TPM 2.0 compatible module to a VM running inside vSphere 6.7. The guest OS uses the vTPM module to store sensitive information, provide cryptographic operations and attest to the integrity of the VM platform.

Concluding Thoughts :

Security is one of the key elements of today’s infrastructure and must be considered in each layer of today’s business-critical systems. VMware vSphere 6.7 provides key new security features that allow taking the security of today’s infrastructure to the next level. In considering securing VMware vSphere 6.7 Virtual Machine Best Practices, there are many great ways to ensure the maximum security posture of vSphere VMs running production workloads. Many of these security best practices align with traditional physical security and guest operating system security. However, there are new features in vSphere 6.7 such as virtualization-based security and Virtual TPM 2.0 that allow taking advantage of new security technology to greatly enhance security across the landscape of the virtual machines running in production. By implementing both the traditional virtual machine security methodologies and the new technology found in VMware vSphere 6.7, organizations can have a secure virtual machine platform that can bolster confidence in data security.