vSphere Security – Protecting your Virtual Infrastructure
One of my goals for VMworld 2014 was to attend sessions surrounding vSphere security and learn additional ways to deploy secure and safe environments. I was able attend both a group discussion with Mike Foley (@MikeFoley) and other participants as well as Mike’s “vSphere Security: Fact vs. Fiction” session regarding vSphere Security. Both were very informational and I was able to bring back many important key facts.
First and foremost, as with many types of environments, the biggest threats to security originate from the inside (read – your own employees). Whether they are disgruntled, leaving the company, or accessing data they shouldn’t be, you need to be auditing the actions of all administrators and users within the infrastructure. This allows you to log all changes and modifications for each user and alert of suspicious activities. A quick Google search for VMware auditing software will yield you many options to consider. You might also, if applicable, focus on applications that tie directly into your SIEM product.
Another critical step, which ties in directly with internal threats, is practicing the principle of Least Privilege. This principle dictates that users get access to only the data and functionality they require to do their job. For example, why give the helpdesk crew full administrator access to the virtual infrastructure when they are only requesting access to view the console on their ticketing servers? Why give the backup service account (you are using service accounts, right?!?) full admin privileges to vCenter when it only needs a limited number of permissions to properly back up your VMs. Giving full administrator access to users can be an easy and quick resolution but it could cause issues for you down the road. If you must give full admin access, please refer to the previous paragraph and audit them. It’s for your own good.
If you follow any white-hat security professionals, it’s likely you know that account credentials are the new “stuff”. Gaining access to administrative credentials is much easier and cheaper for maliciously accessing systems than exploiting vulnerabilities over the internet. Humans are creatures of habit and we, as IT professionals, typically make it easy for malicious users to navigate throughout our systems without realizing. More often then not we’ll use the same password, albeit complicated, throughout multiple systems for convenience. However, this approach also creates convenience for the malicious users as well. I’m guilty of it and I’d bet you are too. Take this scenario as an example:
A malicious user accesses a Windows system through a outdated, vulnerable application. They’re able to dump the hashes, run the hashes through rainbow tables, and effortlessly crack the administrator password. With this newly founded password, they are able to quickly traverse the network, servers, desktops, firewall management interfaces, and more.
In short, use different passwords for different systems, even among ESXi hosts within the same datacenter and clusters. Even better, utilize an application that rotates passwords for the root account. Remember, vCenter server only uses the root account once when initially connecting a host to vCenter. Upon adding, vCenter creates its own local account on the ESXi hosts (vpxuser) to communicate with the host moving forward. And, by default, the vpxuser account’s password is rotated every 30 days. Additionally, you should only be logging in as the local root account as a last ditch effort for management. There are, of course, a few exceptions such as looking at performance metrics utilizing ESXTOP and iscsiStats.
Below are additional security tips in helping secure your environment in both small and larger corporations.
- Never allow access to your ESXi server or vCenter directly from the internet.
- Utilize lockdown mode where possbile.
- Utilize Active Directory accounts on ESXi servers rather than logging in as ‘root’
- Disable SSH on hosts, where applicable.
- Scan and patch your ESXi hosts as part of your monthly maintenance plan. Enormous up-time numbers are not a badge of honor, they’re a sign of unpatched (vulnerable) hosts and/or a broken change control policy.
- Disallow datastore browsing if user accounts don’t require it. This removes the ability to mass download .vmdk files and steal data.
- Consider a vCO or vCAC workflow for deleting VMs rather than allowing users to directly delete VMs.
- Consider a vCO or vCAC workflow to create VMs. This would lock them down to the desired template, datastore, and other settings that would prevent any malicious intentions.
- Utilize micro-segmentation if possible to restrict network traffic between systems. Think NSX.
- Isolate management interfaces from other systems.
Last but not least, make sure to check out VMware’s own security hardening guides they provide to customers. These are written by Mike Foley and provide modifications using risk profiles for securing your environments. They can be found here: http://www.vmware.com/security/hardening-guides. Please make sure to test settings in a lab environment if possible before implementing in production.