Category: Hardening

Nov 02

Announcing the vSphere 6.7 Update 1 Security Configuration Guide

Back in March I released the vSphere 6.5 Update 1 Security Configuration Guide (a.k.a “The SCG”). At that time, I went in to detail on more than just the guide. I covered the topic of why some guidelines are removed or changed. I also covered how more settings were set to “secure by default” now and showed the progress between the 6.5 guide and the 6.5 Update 1 guide.

Today I’m happy to announce the release of the vSphere 6.7 Update 1 Security Configuration Guide. And like the 6.5 Update 1 guide, there’s more changes that I wanted to make you aware of. These changes are there to (hopefully!) make your life as the VI Admin easier. Download the 6.7 Update 1 SCG spreadsheet.

Deprecated Settings

The first big change is that I have come up with a new category for settings that have been fixed in the code of ESXi or vCenter and no longer need to be manipulated anymore. This new category is called “deprecated”. We recommend that you no longer change these settings. There is no active code in ESXi that these settings change. We fixed them to match previous guide values so that you can stop “managing” them. This is done to lessen the IT burden of security.

All settings fitting this category are released in a separate Excel spreadsheet. By sunsetting these settings and moving them out of the guide the SCG will now be only 50 settings in total. This is a decrease from 68 in 6.5 Update 1. Many of these settings were called out in an earlier blog from June 2017 entitled “Secure By Default – VM.disable-unexposed-features”.

Some customers may wish to consider these deprecated settings as “Audit Settings”, meaning that you may wish to check to see if someone has set them. Setting them adds no value and only increases the management burden. You can safely remove these settings from your configurations.

Risk Profiles Goes Away

The second big change is that I’m sunsetting the use of “Risk Profiles”. Now, I’m sure that this will panic many as some may consider this a big change. Honestly, it’s not. Here’s why. Of the 50 remaining settings in the guide only one was at “Risk Profile 1”. Everything else was at either 2,3 or 1,2,3. The value that Risk Profiles brought just wasn’t there anymore. The work we have been doing to deprecate settings is paying off.

The Risk Profile 1 setting was “ESXi.enable-strict-lockdown-mode”. The companion or flip side of that was the setting “ESXi.enable-normal-lockdown-mode” which was Risk Profile “2,3”. It was either one or the other. You couldn’t do both. That was confusing to some people and the first setting was really the only reason to keep Risk Profiles around. So, instead, I added content to the Vulnerability Discussion of both settings that addresses the risk discussion.

Hardening .vs. Non-Hardening Part Deux

As I mentioned in the 6.5 Update 1 blog article, in 6.5 I renamed the guide from the vSphere Hardening Guide to the vSphere Security Configuration Guide. This was done because the number of “Hardening” guidelines was eclipsed by the number of settings that VMware can’t set for you (a.k.a. “Site Specific”) or settings you should audit to ensure someone hasn’t set them to the non-default value without good reason (e.g. “SSH is enabled on ESXi. It’s off by default”).

For the 6.7 U1 SCG, one of the guidelines I changed from “Hardening” to “Site Specific” was the “vNetwork.enable-bpdu-filter” setting. Why? Because it involves coordination with a hardware switch and the use of BPDU packets within a Windows VM. This is a corner case scenario and as such should actually have been classified as “Site Specific”. Does it provide a “hardening” function? Yes, by adding protection against Spanning Tree Loops. But again, it’s not a “normal” occurrence.

Progress

See this video and you’ll see how far we’ve come.

All of this work has lessened the load on the VI Administrator. In 6.5 we had 24 settings that were considered “Hardening”. This dropped to 10 in 6.5 Update 1 and now down to just 5!

Wrap Up

Going forward, I really want to shrink that to one hardening guideline called “Apply Patches”. Unfortunately, we’re not there yet but I think the progress we’ve shown from 6.0 to 6.5 to 6.7 shows you that we are not standing still! Should any new automation functions appear you may find new settings being added to a future guide. I’m always re-evaluating the capabilities that get added to new releases and updates.

I’d like to thank the engineers that have helped me get the SCG to a better place by fixing code to match the values called out in previous “hardening” guides.

mike

If you have questions that haven’t been answered you can reply here, send them to mfoley at vmware.com or via Twitter to @vspheresecurity. @vspheresecurity is a curated list of vSphere Security specific tweets.

 

 

 

Jun 27

Secure By Default – VM.disable-unexposed-features

I’m super happy to announce that we are showing more progress in our quest for “Secure By Default” for ESXi and vCenter Server. This latest update is one that is near and dear to many of you who live and breath by the Hardening Guide (now called the Security Configuration Guide in 6.5) and its many offshoots and subsets and supersets like PCI, HIPAA, DISA STIG, etc..

In ESXi 6.0 Patch 5 (see below), many of the VM.disable-unexposed-features.* settings are now set to be “Secure By Default”. Meaning, the Hardening Guide / Security Configuration Guide desired values are the default values. (see table below) You don’t have to manually set them anymore.. Not that many of you actually did have to set them to begin with.

I know that these changes are going to bring up a LOT of questions. IT folks will have to deal with their security folks. So, this post will go into a little history to help explain things and hopefully calm any nerves.

Why were the settings there to begin with?

These settings come from the Workstation/Fusion code base. When a Workstation VM would get imported into ESXi customers would see these settings and wonder what the values should be. There’s little to no corresponding code on ESXi that use these settings.

What does “little to no” mean?  There may be entry in the code that responds to a query but there’s no code to execute. Or, if there is code, after further review, it was deemed to be not a security issue.

The main reason why these settings got added is because for many customers (finance, 3 letter agencies, etc.), they have a policy whereby “if there is a setting there must be a value” so, over time, these values got added to past iterations of the Hardening Guide.

History

When I took over the guide 4+ years ago it had become like a set of firewall rules or a Jenga tower. “Stuff” was added over the years but never removed because of a fear of doing something wrong or pulling out the piece that made the tower fall.  (I don’t have that fear. I do stuff wrong all the time.. Just ask my teenager!)

The guide had become unruly to manage and maintain so in the vSphere 6.0 timeframe I started the first of many reviews, not unlike a code review process. You can read about that process here.

For the vSphere 6.5 release I sat down with many of our engineers that maintain and develop the code you depend on every day. When I met with the group that deals with the virtual machine code on ESXi we went through every single VM setting/guideline in the guide. This was a fun and enlightening process for all of us!

What resulted out of that meeting was a bunch of bug reports that started the process of either dropping old settings completely or changing the default values for a number of settings to the value reflected in the guide. Specifically, for the purposes of this blog, the VM.disable-unexposed-features.* values. As these bugs are fixed they are assigned to patch releases. Sometime easy changes such as these can be backported to earlier releases. The settings below are in ESXi 6.0 Patch 5.

Secure By Default

Some ask (regularly), why these settings weren’t already set. The answers to that are lost in time. My goal isn’t to argue the past but to fix the future. The point driving this change is that security has now graduated to a primary interest of customers and we’re doing our part to provide you with the most secure platform available without a huge amount of management overhead. Fixing these settings is part of that effort.  If security is a pain to implement then there’s a good chance it will be implemented wrong or not at all.

Where were the settings changed?

The default values for the settings were/are changed in the ESXi code. For ESXi 6.0 there is no reason anymore to add these settings to the VMX/VM Advanced Settings starting with 6.0 Patch 5.

How do I enable them?

You don’t! It’s been done for you in ESXi. If you are using VUM to update your hosts to 6.0 Patch 5 then when VM’s are migrated to an updated host they will be running with the updated values. You don’t need to power them down in this scenario.

If you are running a standalone host you can suspend the VM’s, update the host, reboot the host and resume the VM’s and they will be running with the updated values.

Changed Settings

Below are the guideline ID’s, their new value setting set in ESXi itself and the configuration parameter. If you are manually setting any of these settings on 6.0 then apply Patch 5 and you don’t have to set them anymore!

Guideline ID New Value Configuration Parameter
VM.disable-unexposed-features-autologon TRUE isolation.tools.ghi.autologon.disable
VM.disable-unexposed-features-launchmenu TRUE isolation.tools.ghi.launchmenu.change
VM.disable-unexposed-features-protocolhandler TRUE isolation.tools.ghi.protocolhandler.info.disable
VM.disable-unexposed-features-shellaction TRUE isolation.ghi.host.shellAction.disable
VM.disable-unexposed-features-trayicon TRUE isolation.tools.ghi.trayicon.disable
VM.disable-unexposed-features-unity TRUE isolation.tools.unity.disable
VM.disable-unexposed-features-unity-interlock TRUE isolation.tools.unityInterlockOperation.disable
VM.disable-unexposed-features-unity-taskbar TRUE isolation.tools.unity.taskbar.disable
VM.disable-unexposed-features-unity-unityactive TRUE isolation.tools.unityActive.disable
VM.disable-unexposed-features-unity-windowcontents TRUE isolation.tools.unity.windowContents.disable
VM.disable-unexposed-features-unitypush TRUE isolation.tools.unity.push.update.disable

Other versions?

“Wait! You said you started this process for 6.5 but you’re talking about 6.0? What’s the deal? Are the changes in 6.5?”

Unfortunately, I’m not at liberty to talk about any unreleased versions or patch releases. I can only talk about released versions or patches.

This release for 6.0 should, however, show that we are serious in making life easier for VI Admins and Security and Compliance folks. This is a big step in the right direction.

Patching resources

Here’s the resources for updating your ESXi 6.0 hosts.

Build numbers and versions of VMware ESXi/ESX (2143832)

https://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&externalId=2143832&sliceId=1&docTypeID=DT_KB_1_1&dialogID=439816075&stateId=1%200%20439814722

Download Patches

https://www.vmware.com/patchmgr/findPatchByReleaseName.portal

ESXi 6.0 Patch 5 (ESXi600-201706001)

https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2149958

Wrap Up

I hope this shows to you that there is always progress being made to make vSphere more secure while at the same time lessening the burden on IT to maintain that security. Lets not forget that the threat landscape is constantly evolving and that there is no one solution that will make you “secure”. You can’t just press the Easy Button.  Security is an iterative process.  There is no status quo if you are doing it correctly. “This is the way we’ve always done it” is not how best to operate.

I encounter situations where some security folks are visibly upset that I have removed a setting from the guide after it’s been reviewed and found to be no longer relevant. Back to the firewall rules example. If you aren’t constantly reviewing and adjusting then you aren’t doing security right. JMHO.

Thanks

I’d like to thank all the engineers who helped me tremendously in making these changes. Kudos to Jesse, Ravindra and many others for not only making our customers jobs easier but mine as well.

mike