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.
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:
- 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!
