WilliamLam.com

Updated vSphere Security Hardening Report Script for vSphere 4.1

by // 5 Comments

VMware released earlier this week the first draft copy of the vSphere 4.1 Security Hardening Guide which provides several changes to the vSphere 4.0 version released last year. Unfortunately there was no change list provided and you have to manually go through both documents to get the differences. Luckily I did the heavy lifting for you and here are the changes in 4.1 version:

Edit: It looks like Charu of VMware has already posted a "diff" of the 4.0 and 4.1 version here.

Added Checks (14):

  • VSH07 (Enterprise) - Check for privilege re-assignment after vCenter Server restarts
  • VSH10 (Enterprise) - Clean up log files after failed installations of vCenter Server
  • VUM06 (Enterprise) - Do not use default self-signed certificates
  • VMX23 (Enterprise) - Use secure protocols for virtual serial port access
  • VMX24 (DMZ) - Disable certain unexposed features
  • VMX56 (Enteprise) - Restrict access to VMsafe network APIs
  • HIN02 (Enterprise) - Keep ESX/ESXi system properly patched
  • HCM05 (DMZ) - Disable Welcome web page
  • HMT12 (Enterprise) - Prevent unintended use of VMsafe network APIs
  • HMT15 (Enterprise) - Audit for loading of unauthorized kernel modules (ESXi only)
  • HMT20 (DMZ) - Ensure that vpxuser auto-password change meets policy
  • HMT21 (DMZ) - Ensure that vpxuser password meets length policy
  • HCN05 (SSLF) - Disable DCUI to prevent all local administrative control
  • HCN06 (Enterprise) - Disable Tech Support Mode unless needed for diagnostics and break-fix

Removed Checks (10):

  • VMX03 (Enterprise) - Disable copy/paste to remote console
  • VMX51 (Enterprise) - Restrict access to VMsafe CPU/memory APIs
  • VMX54 (Enterprise) - Restrict access to VMsafe network APIs
  • HCM04 (Enterprise) - Ensure that ESX is configured to encrypt all sessions
  • HMT10 (Enterprise) - Prevent unintended use of VMsafe CPU/memory APIs
  • HMT11 (Enterprise) - Prevent unintended use of VMsafe network APIs
  • HCN01 (Enterprise) - Ensure that only authorized users have access to the DCUI
  • HCN03 (Enterprise) - Avoid adding the root user to local groups
  • HCN04 (SSLF) - Disable tech support mode
  • COP06 (DMZ) - Ensure that vpxuser auto-password change in vCenter meets policy

Note: Some of the removed checks may have been replaced with newer and updated information and shows up in the added checks.

To help with your vSphere validation, here is the latest version of the vSphere Security Hardening Report script 1.5 script. There have been a few enhancements to the script which only validates a check based on whether it it is applicable to classic ESX or ESXi, which in the past it would display "N/A". There is also some further validation of the service endpoints for /, /ui, and /mob that may also help reduce manual verification where applicable. You can also join the new vSphere Security Hardening Report VMTN Group for new updates, bug report and discussions.

Here is an updated sample report based on vSphere 4.1:
vmwarevSphereSecurityHardeningReport-SAMPLE.html

One other thing I noticed while going through both the 4.0 and 4.1 security guide is the numbers for the code are all over the place, there are sometimes huge gaps that are unexplained (e.g. VSH6, VSH7 ... VSH10)

Ghetto Groups

by // 1 Comment

Back in December, VMware upgraded their VMTN (VMware Technology Network) forum software Jive and introduced a completely new layout of the forums that would hopefully enhance the user experience. Though it brought many new features, it also brought on several new issues. The one bug that affected me was the incorrect conversion of the ghettoVCB document, because the conversion was unsuccessful it was decided to be left alone until the issue could be resolved. If you visited the document, it would display a "Forbidden" error message. Unfortunately due to the time it took to resolve, even Google cache started to get stale and stopped serving the cached contents.

Luckily, with the help of Alex Maier (VMTN Community Manager) and her team, she was able to get the ball rolling and got the fix tested and rolled out to production. The ghettoVCB document is once again alive and hopefully in no time it will be returned as the first search result on various search engines.

Going through the pain of receiving dozen of emails, private messages, tweets, etc. per week regarding the issue, I came to realize that VMTN document itself was not the right medium to host both content and user discussions. As it stands today, there are over 1,100+ comments which is pretty significant and managing and keeping up with the conversations is a pretty daunting task. I enjoy the feedback that community provides and the collaboration that takes place and I realize that this can be solved by using the new Groups feature.

To be honest, I did not spend much time looking at Groups when the VMTN software was upgraded, but now that the ghettoVCB document has been fixed, I realized this would fit this need perfectly. With the help of categories users can now post their feedback, discussions/issues and feature request and it can be easier consumed by both new users and myself. Starting today, I will have the following groups based on the top 5 most popular and active scripts:

I have also disabled any new comments on these VMTN documents and will ask that all new comments be re-directed to respective VMware Groups. I'm currently working with Alex to see if there is an easy way to convert the existing comments into a document and attached that as a download to help minimize the complexity of the document. In the worse case, the comments will be left alone as read-only as I think the discussion that currently exists are invaluable. All other VMTN documents that I maintain in the vGhetto Repository will continue to use comments and depending on how well the groups go, I may migrate those over as well.

I hope these new groups will be beneficial for everyone and I am looking forward to the collaboration. Thanks for your support and please help spread the word!

How to extract host information from within a VM?

by // 34 Comments

From time to time, I see this question come up asking how one might be able to extract a certain piece of information from either ESX(i) or the management APIs (vSphere API) from within a virtual machine. The simple answer is you can not, by default the guest operating system has no idea of the underlying hypervisor nor does it have the access to the management APIs. This of course, assumes you are following VMware's best practices in isolated and segregating off your management network from your virtual machine network.

Having said that, there are certain bits of information that you can extract about your ESX(i) host from within the guestOS using some of the utilities that is installed with VMware Tools. The first utility is called VMware Toolbox command which can be found on both UNIX/Linux and Windows systems that have tools installed.

[Read more...]