Public Draft (Revision A) of the vSphere 5.1 Security Hardening Guide

Public Draft (Revision A) of the vSphere 5.1 Security Hardening Guide

Public Draft (Revision A) of the vSphere 5.1 Security Hardening Guide available.

This is a Draft revision. The guidelines in the VM section underwent no change from 5.0 to 5.1, as the guidance has not changed.  The guidelines for ESXi have undergone a preliminary test for correctness in vSphere 5.1.  However, not all guidelines for vNetwork and vCenter have been tested.   A "Draft Status" column is added to these two sections indicating test status for that guideline. "Tested" indicates that the steps in the "Assessment Procedure" field of the guideline have been verified for vSphere 5.1 in a live environment or through VMware documentation. If the assessment guidance is operational and non-specific, it is too generic to test, so status is N/A.  The API and CLI fields have NOT been updated from the 5.0 version for any guideline in this revision.

A future draft revision will include guidance pertaining to SSO and the vCenter Server Virtual Appliance.

We welcome your comments on this draft.

Attachments
Comments

For ESXi AD authentication the guide should include a recommendation to

  • either set "Config.HostAgent.plugins.hostsvc.esxAdminsGroupAutoAdd" to false or
  • set "Config.HostAgent.plugins.hostsvc.esxAdminsGroup" to something else than the default ("ESX Admins")

Anyway the AD group that is used for this purpose should be secured in a way that only authorized people can change its members. In large organizations it is pretty common that AD administrators and VMware administrators are separate groups, but keeping the default settings would enable an AD admin to make himself an ESX admin quite simply.

Andreas Peetz

VMware Front Experience Blog

Since I've been implementing restricted VMX parameters recommended in the Hardening Guide a while ago, here are a couple of questions or inconsistencies I noticed in this new draft (which were present in the 5.0 final document too). I appreciate feedback and explanations to these points.

1.
limit-setinfo-size
"The configuration file containing these name-value pairs is limited to a size of 1MB. This 1MB capacity should be sufficient for most cases, but you can change this value if necessary. You might increase this value if large amounts of custom information are being stored in the configuration file. The default limit is 1MB;
this limit is applied even when the sizeLimit parameter is not listed in the .vmx file.  Uncontrolled size for the VMX file can lead to denial of service if the datastore is filled."
tools.setInfo.sizeLimit
Desired Value => 1048576
Is desired value the default? => NO

The description says there is an implicit default value of 1MB already, so why is this parameter listed as not having the desired value by default? (I assume the value represents Bytes, right?)


2.
A couple of parameters like
disable-console-copy
disable-console-dnd
disable-console-gui-options
disable-console-paste
have the following description:
"Copy and paste operations are disabled by default however by explicitly disabling this feature it will enable audit controls to check that this setting is correct."
Is desired value the default? => YES

Why is it implied that explicitly setting these parameters to false enables some sort of audit controls? I mean isn't it sufficient to check whether the parameters are not present/not set to true?
Also, these items have the same description but are based on different parameters. I'd prefer it if distinct differences were explained in more detail.


3.
These VMX parameters are listed for disabling "unexposed features" and without negative impact:
disable-unexposed-features-autologon
disable-unexposed-features-biosbbs
disable-unexposed-features-getcreds
disable-unexposed-features-launchmenu
disable-unexposed-features-memsfss
disable-unexposed-features-unitypush

If disabling these unexposed features doesn't have a negative impact and wouldn't function on ESXi anyways, why is setting these parameters recommended only in profile 1 with the highest security measures? (IMO ESXi should treat these features as disabled by default unless defined through VMX parameters and not vice-versa, but that's another discussion.)


4.
These VMX parameters are listed for disabling "unexposed features" but allegedly come with some negative impact:
disable-unexposed-features-protocolhandler
disable-unexposed-features-shellaction
disable-unexposed-features-toporequest
disable-unexposed-features-trashfolderstate
disable-unexposed-features-trayicon
disable-unexposed-features-unity
disable-unexposed-features-unity-interlock
disable-unexposed-features-unity-taskbar
disable-unexposed-features-unity-unityactive
disable-unexposed-features-unity-windowcontents
disable-unexposed-features-versionget
disable-unexposed-features-versionset

These parameters have a negative functional impact listed as "Some automated tools and process may cease to function". What exactly would that be when running on ESXi where these features are supposedly unexposed in the first place?
I have all these parameters except "isolation.tools.ghi.protocolhandler.info.disable" set on a couple of VMs and couldn't notice any negative impact. (Except for a few unity warnings in the eventlogs on system logon like here: http://communities.vmware.com/message/2191985#2191985)

5.
disable-autoinstall
Description: "Tools auto install can initiate an automatic reboot, disabling this option can will prevent tools from being installed automatically and prevent automatic machine reboots"

Is this another unexposed hosted feature or does this just apply to the reboot by Tools Upgrades initiated from outside the Guest via ESXi/vCenter? Because I'm not aware that one can install VMware Tools automatically on an ESXi Guest from scratch as implied.


6.
disable-vix-messages
Description: "The VIX API is a library for writing scripts and programs to manipulate virtual machines. If you do not make use of custom VIX programming in your environment, then you should consider disabling certain features to reduce the potential for vulnerabilities.  The ability to send messages from the VM to the host is one of these features.  Note that disabling this feature does NOT adversely affect the functioning of VIX operations that originate outside the guest, so certain VMware and 3rd party solutions that rely upon this capability should continue to work."
Negative Impact: " Guest will no longer be able to send messages via VIX API"

Can this point be explained more in-depth with examples? I can't really think of anything, what kind of messages would a Guest send to the host via the VIX API?


7.
restrict-host-info
Description: "If enabled, a VM can obtain detailed information about the physical host. The default value for the parameter is FALSE. This setting should not be TRUE unless a particular VM requires this information for performance monitoring. An adversary potentially can use this information to inform further attacks on the host."
tools.guestlib.enableHostInfo
Desired Value => FALSE
Is desired value the default? => NO

The description is contradicting the desired default value.

When will a 5.1 Compliance Checker be available?


It's taken a long time for the 5.1 Hardening Guide itself to get to DRAFT, so seems unlikely to get the CC itself until end of Q2 2013, these long delays hold back customers from deployment.

Will the new CC also increase it's capacity to more than 5 VM's too and better still be a plugin to vCenter.

Any view on whether the vCenter Server Appliance will be consider for inclusion when the guide is officially released?

It was called "out of scope" during the public draft period for the vSphere 5.0 hardening guide but it was indicated that it would be considered in later versions.

Given the encouragement of customers to consider and use appliances for a number of VMware products, it would be reassuring to see vCSA covered in an upcoming Security Hardening Guide.

The guidance in ESXi-limit-cim-access appears odd.

The vulnerability discussion describes as a “back door” the potential for abuse of the root or an administrator account if it is used for CIM-based applications (including for hardware monitoring).

The assessment procedure describes a limited privilege configuration where the service account is provisioned no host level access, but may directly connect to the host’s CIM interfaces with read / write access using a ticket obtained through vCenter and the CIM Interaction privilege.

In that configuration, the service account will not have access to compromise security of the host via the host’s vSphere API interface(s). But the service account could conceivably use the read / write access to the CIM interfaces to compromise security by abusing ticketed access.

It is difficult to understand how a unique back door is created in respect of CIM services as described. A monitoring or 3rd party tool granted administrator level access (e.g. root) and using the vSphere API instead would have the same problems.

Effectively the vulnerability discussion describes a simple “front door” problem of an excessive level of access. This could be addressed through applying the principal of least privilege more generally.

It is conversely easy to see how the CIM Interaction privilege and CIM interfaces could be a back door if the guidance is followed.

What is the nature of the back door mentioned in the vulnerability discussion?

It is odd that the guidance does not discuss the vCenter Hardware Status plug-in which, although not programmatically equivalent, offers an even more limited privilege option (associated with vCenter System.Read).

I noticed when going through this document, there no new sections for SSO and/or the vCenter Webclient. Should I take this to mean that the Webclient is already hardened to the nth degree from the factory (doubtful) or that the Hardening Guide is still a work in progress and it will be addressed in a later rev?

Sheet VM - Line 21 - disable-console-paste. The desired and default value is "True", however the provided PowerCLI remediation command sets the value to "$false". This should say "$true" instead.

Thanks,

Chase Dafnis

In relation to esxi-verify-kernel-modules, could some guidance be given about measured and trusted boot when Intel trusted execution technology (TXT) is available?

If the use of such a technology as a means to address hypervisor integrity were described, it may be appropriate to also note considerations for installation and implications for detecting and preventing wider tampering (for example, in critical configuration files or during system boot prior to kernel load).

Hi Andreas,

I went thru the docs and the guide after reading your excellent post. I think much of what you are saying is in the guide. Do you think a suggestion to rename the AdminsGroup to something other than "ESX Admins" would bring better security? The guide does state to limit membership to highly trusted users and groups and to monitor the group. I'm happy to to chat more about this if you'd like. Feel free to email me mfoley at vmware

@MKguy

Awesome feedback and I've incorporated some into the guide. Thank you!

RE: VIX messages

I'm working on getting clarification for that and hope to have it into the final guide.

RE: unexposed stuff: Profile 1, as you know, is for the ultra-cautious. Listing these settings so they can be disabled addresses that type of customer who want all settings that may or may not be exposed to be controled and audited.

@utopianmirage @sfolsson As mentioned above: "A future draft revision will include guidance pertaining to SSO and the vCenter Server Virtual Appliance."

t-g

Hello, Charu

just one report.

I couldn't find the entry "<enableHttpDatastoreAccess>" to disable the vCenter web-based datastore browser in vCenter5.1 vpxd. The location changed maybe?

Other than that, thanks for excellent document Smiley Happy

t-g,

That setting is in the guide. Look for disable-datastore-web. This is a "Profile 1" setting. The next version will have a new control called "restrict-datastore-web" that discusses using RBAC to control access to datastores. This would be more applicable to Profiles 2 & 3 (more enterprise-friendly)

mike

Version history
Revision #:
1 of 1
Last update:
‎02-11-2013 01:05 PM
Updated by: