As administrators, we try to do our best to balance security versus usability scale, locking things down without...
disrupting the same business that gives us a paycheck. At times, this can be a tough task -- especially with so many different technologies that co-exist within today's data center. Thankfully, when it comes to vSphere, VMware has released what's called a hardening guide with every released version since version 4.0.
Why does vSphere require a hardening guide?
Out of the box, vSphere is not unsecure. But, like the systems administrator, VMware also needs to balance security versus usability.
Take a feature such as lockdown mode. Lockdown mode disables local access to ESXi hosts to all users except the vCenter service account for a more secure deployment of the hypervisor; but this is something that isn't enabled by default. VMware leaves that choice up to its customers.
Lockdown mode, along with more than 150 other recommendations, is outlined in the hardening guide -- an Excel document with a list of vSphere components that can be adjusted for tighter security. Most of the document does not require administrators to make changes but to ensure that default values stay the same.
There are items that don't require any adjustments, but are more of an operation change or process to follow, such as right-sizing VMs upon creation. As far as the scope of the guide goes, there is information that deals with ESXi -- including our virtual networks and VMs -- and the core vCenter components such as vCenter Server, the Web client, SSO and Update Manager.
Is this for a security team or a vSphere admin?
If you have a security team in place, they should definitely look at the hardening guide. If you don't, and depend on the vSphere administrator to take care of security, look at the hardening guide. Everyone responsible for access, monitoring, security and vSphere should at least read the guide. Whether or not you decide to implement any of the suggestions is at the discretion of you and the business.
Some businesses may have compliance regulations around how secure its hypervisors need to be. They will decide what they can and cannot do and stick to a certain Risk Profile as defined by the guide. Some companies may just implement a few of the recommendations from each profile to better secure the environment. I firmly believe anyone dealing with a vSphere environment, whether it's administration or security, should read the hardening guide.
How should I interpret and implement the hardening guide?
There is no right or wrong way to use the guide. It's simply a set of recommendations you can choose to apply or not. There is a lot of information in the document, but it is all consistently displayed in the following outline.
- ID -- A simple identifier for the recommendation.
- Product -- The product it applies to, normally vSphere.
- Version -- The version of the product.
- Component -- The component of the product it applies to, such as vCenter or ESXi.
- Subcomponent -- Further breaking down of the component, such as communication, access and host.
- Title -- A more descriptive title than ID (such as configure NTP time synchronization).
- Vulnerability Description -- A description of the task, why you may or may not apply the setting.
- Risk Profile -- Relative to the desired level of security.
- Profile 1 -- Environments with strict security guidelines/compliances.
- Profile 2 -- Environments with sensitive information/compliances.
- Profile 3 -- Most, if not all, vSphere environments.
- Control Type -- Parameter (a system-level parameter), Configuration (a hardware or software configuration or group of settings), or Operational (monitoring or ongoing operational process to follow).
- Assessment Procedure -- Description of how to validate the guideline.
- Configuration File/Parameter, Desired Value/Is Default -- Columns describing where to find the parameter to change, what to change it to, and whether or not the desired value was the default value.
- Change Type -- Whether we are adding a new value, removing a value, or modifying an existing value.
- vSphere API -- Documentation of where this value can be accessed utilizing API calls.
- ESXi Shell/vCLI/PowerCLI Command Assessment/Remediation -- How we can retrieve, set and verify the setting utilizing various CLI commands.
- Negative Functional Impact -- How the modification may negatively affect the environment or prevent normal vSphere functionality.
- Reference -- Where to get more information for the setting.
- Able to set using Host Profile -- Whether or not the value can be specified within a host profile.
- Covered by VCM -- Whether or not vCenter Configuration Manager can set the value.
This is a lot of information to have on one specific setting but it is all required to successfully audit and change the vSphere environment to make it more secure. Not only does the guide let us know exactly how to change any values -- sometimes with a script example to automate the change -- but it also lets the administrator know exactly what is going to happen, what negative functional impacts there may be, as well as where we can go to get more information.
To help us understand a few things in more detail, let's take a look at a few examples within the guide.
- disable-hgfs -- This is a component built in to vSphere to allow the transfer of files between the hypervisor and VM. This is labeled as Risk Profile 1 only, meaning only the most secure environments should disable this. The guide warns disabling it will cause the VMX process to disregard commands from the tools process, so actions such as an automated VMware Tools upgrade will not function. With a Change Type of modify and an Is Default value of no, we can conclude that to implement this setting we must change the default value to that of our Desired Value, which is true.
- restrict-host-info -- This is an advanced setting that allows the VM to obtain information about the host it is currently running on. Although this isn't an immediate threat, the information could be used to construct attacks against a host, therefore False is the recommended setting. This belongs to Risk Profile 1 and Risk Profile 2, meaning highly secure and sensitive environments should apply this setting. With an Is Default value of yes, we can conclude that we need to verify the setting is set to the Desired Value, which is false.
- minimize-console-use -- This is not a setting we need to change as its Control Type is operational, meaning it's more of a recommendation of how to manage our environment. Essentially, it states that instead of using the VM console in the vSphere client, an administrator should use native remote management services, such as RDP and SSH; this helps prevent possible security issues, such as allowing users to mount removable devices or change power operations. This applies to Risk Profile 3, which includes 2 and 1, and means just about all vSphere environments should limit VM console access.
The guide serves as a helpful prod
With the most recent exploits, such as Heartbleed and ShellShock, attention to security has become a priority in many organizations. Administrators go to great measures to protect applications and data within the VMs from a guest OS perspective, and should give that same attention to the hypervisors and management tools that VMs depend on. The hardening guide is a great way to give your environment an audit. I'm certain most administrators will find at least one item they will want to implement. At the very least, looking over the guide and checking the various settings can give many administrators the confidence to say they have made an effort to make vSphere more secure.
Best practices for VMware security
The ins-and-outs of vSphere’s built-in security features