VMware vSphere Compliance Scanning Frequently Asked Questions
Many customers employ security & compliance scanning tools to assist them during audits of their environments. This is a collection of common questions posed to VMware about this process.
Have a question to add, comment, or suggestion? See the “Feedback” section below.
Can VMware recommend a vulnerability scanning tool?
In short: no. VMware cannot make a recommendation for a particular scanning tool. While we do not support scanning tools directly, we do support use of approved APIs and clients. We do recommend choosing a solution that specifically lists vSphere as a supported scanning target because it helps show that the maker of the tool understands how vSphere is delivered.
We also suggest using scanning tools that acknowledge the differing ways a compliance goal can be implemented, such as through compensating controls. Compliance frameworks rarely specify implementation details; they tell you what you need to do, but not how. In contrast, scanners only check how you did something, and they do this by comparing your environment to an arbitrary baseline from the scanner vendor. Your solution may be compliant but not meet the vendor baseline, per se. There needs to be room in the scanning process for interpretation & flexibility in meeting the compliance goal, which is allowed by most compliance frameworks to accommodate application and design constraints.
VMware vRealize Operations Manager offers downloadable compliance packs for a variety of compliance & regulatory frameworks, but the scope of these checks is the virtual infrastructure itself. Still, they can be a useful way for vSphere Admins to audit and detect changes that might place them out of compliance during their next formal audit.
My scanning tool is asking me whether ESXi is Linux or UNIX. Which one should I pick?
Neither – VMware ESXi is its own operating system and is neither Linux nor UNIX. If your tool does not specifically support VMware vSphere components you should avoid using it on your environment or use network-based scanning only (checking TLS and such). Scanning VMware ESXi as a Linux or UNIX host will, at best, result in false positives and lost staff time interpreting the false positives.
What is the best way to scan ESXi via SSH?
SSH and command shells (ESXi Shell) on vSphere components, like ESXi and vCenter Server, are maintenance & support tools designed for use only in temporary circumstances, at the guidance and instruction of VMware Global Support Services (GSS) staff. ESXi ships with SSH & the ESXi Shell disabled and off and raises alarms in vCenter Server if it is enabled and running. Neither are intended to be operational on the host. There are no customer-serviceable or replaceable components inside ESXi. ESXi is delivered and maintained as a single software image and altering permissions or software inside that image may affect availability and will jeopardize support for the product. As such, we strongly recommend SSH be left disabled, and that scanning tools examine the version information of ESXi and reports from Update Manager to determine if an update is available.
Similarly, vCenter Server and other vSphere components are delivered as virtual appliances. Altering them in any way outside the guidance of VMware Global Support Services is unsupported. To ensure it is updated use the patching and update mechanisms inside the Virtual Appliance Management Interface (VAMI) and compare the version & build of vCenter Server reported in the VAMI to the versions available as patches on my.vmware.com.
Put simply: leave SSH disabled.
vCenter Server appears to be based on Linux, and my scanner says it has vulnerabilities in some of the software installed on the appliance. How do I fix those?
VMware tracks all software installed and in use as part of our products. If a security or functional issue is reported to an external project VMware will assess its impact to vSphere according to the VMware Security Response Policy. If needed, a subsequent update to the product will be made available through the supported update mechanisms (for example, the VAMI and/or Update Manager) according to the response policy schedule. There are no user-serviceable components in the virtual appliances, and replacing or altering components will jeopardize the availability, functionality, and support for the system. If you have questions please reach out to your account team, TAM, or VMware Global Support Services.
My scanning tool discovered serious permission problems when scanning ESXi via SSH, is it okay to fix those?
ESXi is not Linux or UNIX and does not follow the permission models of those operating systems. Because SSH and the ESXi Shell are intended for maintenance only, and ESXi is not a traditional multiuser OS, all users logging into ESXi via those mechanisms intentionally have administrator/root-level permissions. Changes made to file permissions or software components without the explicit guidance of VMware Global Support Services are not supported and may affect availability, serviceability, and supportability of your infrastructure. VMware is committed to the security and stability of our products and customers, and if there are issues or concerns please begin by opening a support case with VMware Global Support Services.
My scanning tool discovered serious vulnerabilities in a vSphere component, and I replaced the package with one from the CentOS Linux distribution. Now things don’t work right. How do I fix this?
Changing components manually is not supported and can lead to serious availability and functional problems. Please open a support case with VMware Global Support Services for assistance.
If I shouldn’t use SSH how will I configure my ESXi host?
There are a variety of supported methods for configuring ESXi and vCenter Server, through the GUI interfaces and through API & CLI interfaces. Host Profiles, PowerCLI, and the esxcli are common mechanisms for doing so. The code.vmware.com site has many examples and options in numerous scripting and programming languages. By interacting with ESXi via vCenter Server you also take advantage of the fully featured role-based access control (RBAC) in vCenter Server.
Can I disable SSH if it is enabled?
Yes, and we recommend doing so because it improves security and reduces audit scope. Please consult the vSphere documentation for your version.
Are there any problems with network-based scanning?
vSphere is a very robust and mature infrastructure product and can withstand routine network scanning. It is recommended that you test your scanner on a test environment first (nested ESXi is a great way to test), then on a subset of production hosts (maintenance mode), before scanning everything. This builds confidence and lets you assess the results more quickly.
My scanning tool discovered issues with TLS. How do I fix this?
TLS 1.2 is the default in VMware vSphere 6.7 and newer, and we recommend upgrading to take advantage of that and many other default security & functional improvements, both in vSphere and in vSAN. For other vSphere 6.x versions you can install and run the TLS Configuration Utility to customize the versions of TLS.
Is there a way to limit users logging in to ESXi?
Yes, consult the product documentation around the DCUI.Access advanced option. We recommend limiting ESXi shell access only to staff that are directly involved with support of the underlying hardware, but also taking care to mind dependencies so that systems can be brought online by the support team if an incident is occurring. In most cases it is recommended that staff interact with ESXi through vCenter Server where the robust role-based access control (RBAC) model can be applied.
Are there default accounts created on vCenter Server or ESXi?
Yes, the email@example.com (or the domain you specify) account is created as part of the installation of vCenter Server, with a password that is specified at the time of installation. Similarly, ESXi creates the 'root' account with a password specified at installation, as well as a ‘dcui’ account for privilege separation for the console application. Beyond that, compliance auditors often enquire about additional accounts that are present on these systems, specifically vCenter Server or the Platform Services Controllers because they are based on Linux.
A good security practice is to follow the principle of "least privilege" meaning that a user or an application should not be given any more permissions than are required to do their jobs. Because VMware follows industry-standard security best practices this is true of applications and services running as part of vCenter Server, too, wherein there are additional accounts internal to vCenter Server to practice least-privilege and protect the services and appliance. If you do inspect /etc/passwd and /etc/shadow you will note that any Linux system default accounts and any additional accounts that support vCenter Server are set to prevent logins, with the passwords locked and shells set to /sbin/nologin or /bin/false.
As with other answers in this document we recommend leaving SSH disabled and off, as it is delivered in vCenter Server and ESXi, to greatly reduce audit scope and attack surface. It is also the case that both ESXi and vCenter Server are to be treated as "black-box" appliances. Modifications to the virtual machine itself or the software inside without the guidance of VMware Global Support Services (GSS) or Engineering is likely to endanger the supportability of the installation and/or cause operational issues.
If you feel that you have found a security issue with a VMware product please follow the process outlined in the VMware Security Response Policy.
My compliance folks are insisting that they be granted SSH access to vSphere. What do I tell them?
In short: if SSH is off then continue reading for how to say ‘no’ in a nice way. If SSH is enabled and running you aren’t following best practices and may have to make some adjustments.
First, SSH is a troubleshooting and support interface, not enabled as part of the default installation of the product, and not intended to be enabled unless troubleshooting is occurring (and then immediately disabled again).
Second, vendor best practices, product documentation, and recommendations unequivocally state that SSH be disabled to reduce attack surface and management complexity. If you are following these best practices you have kept SSH disabled, and you are unwilling to reduce the security and supportability of the infrastructure by enabling it.
Third, there are no user-serviceable components accessible via SSH. You cannot replace individual components and remain supported, and so vCenter Server and ESXi must be evaluated as a whole unit. Any product updates will come through Update Manager or the VAMI and need to be checked externally against VMware Security Advisories and patch release information. This is no different than scanning a storage array’s controller, where the storage array vendor does not permit access even though it may be running SSH for support. Done correctly, auditing & remediating vSphere is very similar to auditing & remediating a network switch’s firmware.
Fourth, granting access to a scanner tends to find issues that aren’t issues, wasting large amounts of staff time and increasing billable hours by auditors, with zero net gain.
Last, because of the intentional permission model of SSH and the ESXi Shell, there is no way to limit what a scanner can access, which is a violation of the least-privilege principle that is a foundation of information security best practices. Enabling SSH and intentionally giving a scanner root/administrator access is a big security problem, but it is a process & implementation problem, not an issue with vSphere itself.
It is paradoxical for a security auditor and/or information security professional to insist on drastically reducing security, especially since their audit will then list the results as findings that need to be fixed. The findings are only the result of their requests and would not be present otherwise. Leave SSH off and scan as-is with a tool that explicitly supports vSphere.
If we still want to scan vCenter Server and/or ESXi via SSH, what's the best way?
We always recommend customers have a test environment. It is easy to deploy a secondary, non-production copy of vCenter Server, as well as to install ESXi inside a virtual machine (nested ESXi). If you must scan in this fashion this is how we recommend doing it, to limit damage and reduce the likelihood of operational & support incidents in your production environments. Use the same software build versions as what you have deployed, in representative configurations. If you shut the nested test environment down you can safely snapshot it, providing flexibility for reverting changes during testing.
Please note that while nested vSphere is possible, and is how the Hands-on Labs works, it is not supported by VMware Global Support Services. There are many community resources for creating these types of environments.
Summary and Additional Resources
Please visit the Compliance resources at https://core.vmware.com/compliance.
Migrated from original vSphere Central content.
About the Authors
This Frequently Asked Questions list is maintained by Bob Plankers, Senior Technical Marketing Architect, VMware.
The purpose of this document is to answer questions that may fall outside the scope of product documentation and system design guidance. Your feedback is valuable. To comment on this document please contact Bob Plankers at firstname.lastname@example.org. Thank you.