Tag: esxi

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!

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