Search
StarWind is a hyperconverged (HCI) vendor with focus on Enterprise ROBO, SMB & Edge

VMware vSphere 7 Security Configuration Guide: 15 Things to Know About

  • January 6, 2022
  • 18 min read
Virtualization Architect. Alex is a certified VMware vExpert and the Founder of VMC, a company focused on virtualization, and the CEO of Nova Games, a mobile game publisher.
Virtualization Architect. Alex is a certified VMware vExpert and the Founder of VMC, a company focused on virtualization, and the CEO of Nova Games, a mobile game publisher.

Introduction

As many VMware vSphere admins know, this company has a quite useful document called “Security Configuration Guide.” It is the primary guide for virtual environment protection and hardening. Its latest version consists of 87 settings and configurations, one way or another affecting security of both the virtualization platform and virtual machines with their guest OSs.

Security Configuration Guid

The document is all about the “Secure by design”. It means that the VMware vSphere environment is designed most efficiently security-wise, which is why you ought to make changes only if there are some requirements specific to your particular infrastructure.

You need to understand, though, that configuring a virtual environment to increase security always implies some kind of compromise between protection and usability (as it is with any other IT environment). The platform itself, vCenter server, and VMs are configured out of the box in a way that guarantees a comfortable user experience with an appropriate safety level.

Please remember that toying with security settings is a dangerous thing that requires obligatory documenting of changes and notification for system admins. That requirement is important to follow because otherwise, an admin may encounter problems with separate infrastructure components without knowing their source. The latter is sometimes even worse than a hypothetical malware attack caused by changes in the settings.

Today we are looking at 15 really useful recommendations and settings that won’t affect usability as much but will increase security a little, and that means a lot in the long run.

Structure

First things first, let’s take a look at an Excel spreadsheet with the list of settings and recommendations for your virtual infrastructure:

Structure

  • Guideline ID – recommendation identification name
  • Description – short description of this recommendation
  • Discussion – explanation on how exactly this setting affects environment configuration; discussing aspects regarding the usability of managing tools due to the change in settings.
  • Configuration Parameter – the name of the advanced setting of a respective component that you can always change. Of course, this column is not always filled since some recommendations are regulated by topology or approach to organizing environment, not by specific settings
  • Desired value – recommended value (often default, if it’s not site specific)
  • Default value – value set by default
  • Is Desired Value the Default? – just for understanding (and reference in the future) whether the desired value was set by default
  • Action Needed – type of action needed to change the settings, check configuration or topology, add or delete something, etc
  • Setting Location in vSphere Client – a handy material that allows you to find a necessary setting in the vSphere Client
  • Negative Functional Impact in Change From Default? – information on how the change of this particular setting will affect the system functionality
  • PowerCLI Command Assessment – PowerCLI command to determine the current value of this setting
  • PowerCLI Command Remediation Example – PowerCLI command to set the setting
  • Hardening – points that this setting requires attention during configuration
  • Site Specific Setting – points that in this case, the user must set the configuration according to his requirements
  • Audit Setting – points that this setting needs to be kept in check regularly to make sure that value was not changed unreasonably

The guide itself is divided into four categories that every admin knows:

  • VMware ESXi
  • VMware vCenter Server
  • Virtual Machines
  • In-Guest

Also, there’s a “Deprecated” tab in this document, consisting of settings that are no longer required. What’s important, is that there’s info on why they were recognized as obsolete, too (Discussion column).

So, it’s time to check those most interesting and efficient settings that you can set. Also, there are certain recommendations to increase the virtual environment security within your infrastructure.

VMware ESXi

  • Configure remote logging

Now that is one good recommendation! ESXi hosts must send their logs to the remote Syslog server. The easiest way to do that is using the VMware vRealize Log Insight solution as a Syslog. If an intruder were to attack the ESXi server successfully, all local logs will be deleted afterward, so there’s no proof at all. Now, deleting logs from a centralized external server? That’s a bit harder. Also, this configuration doesn’t affect the environment and its functions at all.

  • Ensure ESXi management interfaces are isolated on their own network segment

Obvious measure, although not always popular. Naturally, you need to make sure that all out-of-band hardware management interfaces are on a separate network segment (VLAN) dedicated only to hardware management, accessible only for admins. The same goes for vMotion and vSAN networking.

  • esxi-7.shell-interactive-timeout and esxi-7.shell-timeout (Set a timeout to automatically terminate idle ESXi Shell and SSH sessions)

When the ESXi Shell or SSH services are enabled on a host they will run indefinitely, being a potential target. To avoid having these services left running and vulnerable, set the ESXiShellTimeOut for about 600 seconds.

  • Only run binaries delivered via VIB

This setting enables you to only execute binaries that originated from a VIB governed by the Acceptance Level. Turn it on only when you are not using custom-made external libraries, but all these changes should be documented just in case.

  • Enable bidirectional/mutual CHAP authentication for iSCSI traffic

CHAP authentication must be set if you wish to prevent interception attacks on traffic. It’s not too long to set, and your data will be more secure.

VMware vCenter Server

  • Ensure vCenter Server management interfaces are isolated on their own network segment or as part of an isolated ESXi management network

Pretty much the same thing that goes for ESXi servers. Just make sure that vCenter interfaces are isolated on their own network segment (VLAN, etc).

  • Ensure that port mirroring is being used legitimately

This particular setting is disabled by default, but this doesn’t mean you shouldn’t observe vSphere Distributed Switch traffic (vSphere Client -> Networking -> Distributed Switch -> Configure -> Settings -> Port Mirroring). Such a way to attack is probably the simplest one to implement. Of course, that is if an adversary has access to VDS settings (usually no one bothers to check them after the initial configuration). Same goes for NetFlow traffic that you can manage as follows: vSphere Client -> Networking -> Distributed Switch -> Configure -> Settings -> NetFlow.

  • Limit access to vCenter Server by restricting DCLI / SSH

Reasonable recommendation to prevent the adversary from logging into the virtual appliance console either directly or via SSH. By reducing attack surface, you are making the whole environment more secure altogether. Don’t forget to update your documentation, though.

  • Configure File-Based Backup and Recovery

Find time for configuring and maintaining your vCenter Server configuration backup. It both serves security purposes and will help you recover quickly in case of failure.

  • Configure remote logging

Same thing as with ESXi. You do need remote logging, so it will be useful to take some time to configure it.

Virtual Machines

  • Limit the number of console connections

More often than not, giving access to a VM console for more than one admin is a little overkill. In this case, the default number of 40 is better to pin down to 1. You can do that here: VM -> Edit Settings -> VM Options -> VMware Remote Console Options.

  • Encrypt VMs during vMotion

Very important setting. By default, a VM uses “opportunistic” vMotion encryption (if available). However, if you possess enough computing resources and a fast enough network, you can set this to “required.” This measure will protect the traffic which contains important data from VM’s guest OS from being stolen.

  • Lock the VM guest session when the remote console is disconnected

My advice is to start using this setting if you don’t want your session running on the remote OS to be intercepted by an intruder. Overall, it has little effect on systems usability. You can change it here: VM -> Edit Settings -> VM Options -> VMware Remote Console Options.

In-Guest

  • Ensure that VMware Tools are updated

Just another friendly reminder that the VMware tools, like any other software, need to be updated to the latest version (preferably, all machines should be on the same level). This package goes with a lot of components (you don’t need to install all of them, by the way), and if one is under attack, the whole body of virtual machines may be compromised. The same goes for the Virtual Hardware updates, don’t miss them.

  • Disable Appinfo information gathering

Appinfo is a powerful mechanism to get information about running processes inside the guest OS and their parameters. Various solutions like vRealize Operations Manager use it to help monitor an environment. Although it may a better decision to disable it if you don’t work with such tools within your virtual environment. If we are to consider the number of security bugs found lately within various components of the infrastructure software, it becomes evident that it’s simpler to shut Appinfo down altogether (it’s enabled by default for all guests right after you have the VMware Tools packages installed). And be sure to document this change!

Conclusions

Of course, there’s a multitude of other settings in the vSphere 7 Security Configuration Guide and I haven’t even scratched the surface here. They all will be useful for you and configuring them will eventually help you in the long run. Sometimes it has to do with regulatory requirements or specifics of the internal policies of an organization. That’s why my advice to you is to take special attention to configurations marked as Site Specific and those that have values different from the default ones. And I’ll repeat it once more, it’s not good for your environment to perform these changes without proper documentation. Regular audit of the most important configurations also won’t hurt. Good luck on your journey!

Found Alex’s article helpful? Looking for a reliable, high-performance, and cost-effective shared storage solution for your production cluster?
Dmytro Malynka
Dmytro Malynka StarWind Virtual SAN Product Manager
We’ve got you covered! StarWind Virtual SAN (VSAN) is specifically designed to provide highly-available shared storage for Hyper-V, vSphere, and KVM clusters. With StarWind VSAN, simplicity is key: utilize the local disks of your hypervisor hosts and create shared HA storage for your VMs. Interested in learning more? Book a short StarWind VSAN demo now and see it in action!