This document is the official release of the vSphere 4.1 Security Hardening Guide. This version is based on feedback collected during the public draft comment period. We will still be collecting feedback on this document -- if there are any typos, errors, or changes, please add them to the comments below.
PLEASE NOTE: the latest version of this guide may be found here: http://www.vmware.com/resources/techresources/10198 .
Hi, you need to change code for "Set a timeout for Tech Support Mode" policy. HCN06 is used twice. Draft version has HCN07 code for this policy
Thanks for pointing this out. I made this correction and uploaded a new version of the PDF.
I have a few general comments reference the hardening guide.
Nice to have items:
EXAMPLE: A nice feature in vCenter could be allowing users to be
shadowed by having a "PROMPT" popup.
Parting Advice - secure by default, not by exception should always be the standard. Get off the old MSDE SQL 2005 installs, you place systems at risk and cause extra work.
MSDE SQL 2005 is a classic FAIL on your behalf. Deploying old unpatched database instances by default is shameful. C'mon guys, you follow security best practices, right?
Otherwise, kudos on the 4.1.x product, I like it better then what Microsoft has to offer.
I didn't see any password policy modifications for ESXi. Granted, most admins will configure the ESXi Servers for Active Directory Authentication, followed by Lockdown Mode. I was still surprised to see that there were no modifications to the local password policies in /etc/pamd.d/system-auth. In our environment, we add one additional local account for DCUI access. We used to modify the /etc/pam.d/common-password file in ESXi 4.0, but now I guess we will modify /etc/pam.d/system-auth in ESXi 4.1.
*edit* sorry for replying to Robert321, I just noticed the add comment link on the upper left.
Drew
How important is it to turn off vix? code VMX30.
Several products will fail if vix is turned off such as vcb and vum.
Can you confirm that VUM and VCB fail when VMX30 is implemented? I was told by the developers that this would not happen.
I have the impression that there are support hooks for AD in 4.1--are there support hooks within the hypervisor for other applications as well? Oracle, SAP, SharePoint 2010, Lync 2010 perhaps. Thanks so much.
For HTM20 is there any file or powercli cmdlet that will let me check the password aging policy for ESXi (not ESX) hosts? I did not find a login.defs file in the ESXi hosts /etc dir.
I just got done working with VMware support. In ESXi4.1u1, changes to the /etc/pam.d/system-auth file will not persist after two reboots, even if you chmod +t the file. This is a known problem that may get fixed in 4.1u2. I have requested that VMware update the hardening guide and produce a KB article.
Drew
Can your provide clarification regarding VSH07?
Namely: which log file to monitor and what the message should look like.
To monitor (or have a tool monitor for me) I need to know where to go and what to look for. Can anyone provide any help here?
Thanks.
VSC07 (Disable managed object browser) has a typo:
I think that's better to use vim-cmd command to disable MOB: vim-cmd proxysvc/remove_service "/mob" "httpsWithRedirect" instead of manual cfg file editing. What do you think?
That's what I did for the individual hosts, however the line above was for vCenter.
oh, sorry. you're right. I didn't draw attention to the code and your last note.
Charu,
Is it anywhere in future VMware dev roadmaps to make an ESXi deployment secure by default versus after action hardening?
Example:
1. Boot ESXi during installation it asks what baseline you follow.
2. User selects baseline from options such as DISA STIG, PCI, or whatever supported hardening configuration VMware fully supports - eliminates all those silly supported versus non-supported questions.
3. User responds DISA STIG or whatever selected baseline they choose
4. ESXi initial deployment is security by default IAW best practices - NO MORE BOLT-ONS
5. Remainder of VMware vSphere, DB, VUM, and ESXi Auto Deploys follows DISA template by default and sample scripts are provided whenever necessary.
6. New built in health check tool self-audits vSphere architecture for STIG compliance and auto reports on itself for non-compliance.
Makes for a Happy User Community
Apply same workflow concept to VM's to include policy based deployment of VMware tools and OS hardening.
Btw, I beta test for Microsoft but they don't listen too well. Let's see how well VMware listens to some really good advice of what user's want out for out of the box experiences. Certainly willing to beta test for VMware if you can point me in the right direction.
Hardening issues today:
"Something too often added after the fact because few understand it"
"Panic'd work frequently performed after an audit, and then turned off because they didn't understand what they broket"
"The guides vendors always develop after the fact because they were so busy cramming in one more insecure feature or widget"
Just a follow-up report to note that the /etc/pam.d/system-auth issue is still present in 4.1u2, I tested it today.
Hi all.
Can somebody comment VMX30 setting. It recommends to set "guest.command.enabled=FALSE". I was confused a little with "enableD". Is it correct or typo?
Most of parameters use ".disable" without "d". So question is "guest.command.enabled=FALSE" correct? Moreover "Security Hardening" has next note: "You can also use any vSphere API-based tool such as PowerCLI to view and modify VMX parameters. In many instances, a VMX parameter has two versions:
So what do you think?
At the following link it has guest.commands.enabled -
http://kb.vmware.com/kb/1010103
I have previously used guest.command.enabled and the VM did manage to power on.
Yes, thanks. I checked with Guest Console. Yes, parameter "guest.command.enabled=FALSE" and only it alone works. Confused...
Well, last note is wrong. You need to use guest.commands.enabled=FALSE" to disable VIX in real life. NOTE char S at the end of "commandS".
Doc contains wrong parameter name. KB describes correct one.
The current version 3 of this document is missing an update for recommendation HCM05 (Disabling the Welcome Page) in the field "Effect on Functionality" contains "The welcome web page will no longer be accessible." That effect is not complete. The correct text is: "The welcome web page will no longer be accessible. If the ESX/ESXi 4.1 host is managed by vCenter Server 5.x then VMware HA and log file collection will not work for this host. For details see KB 1016039 (http://kb.vmware.com/kb/1016039)".
This recommendation will be dropped from the upcoming hardening guide for vSphere 5.
Guys,
make sure you are using the latest version of this document available at:
http://www.vmware.com/support/support-resources/hardening-guides.html
Also take a look on the following KB