Welcome back to part 2 of our discussion of the vSphere 5.0 Hardening Guide! If you missed part 1, you can find it here. Let’s get back to it!

• Guideline Title: Communication Configure the ESXi host firewall to restrict access to services running on the host
  • Title: config-firewall-access
  • Discussion: The process of hardening a production server involves stopping unnecessary services and protecting services that need to remain running, and ESXi is no different. Unnecessary services should be disabled. Necessary services can be protected by defining allowed IPs that are allowed to connect. These IPs can be set under “Configuration -> Security Profile -> Firewall -> Properties”. Select a service then click “Firewall”, choose “Only allow connections from the following networks” and specify the IPs or ranges that will be allowed to connect.
    
  • Official VMware documentation
• Guideline Title: Configure NTP time synchronization
  • Title: config-ntp
  • Discussion: NTP serves two purposes. First,  in the event of a security breach, having your ESXi system logs synchronized will lend itself to an effective incident postmortem, which can, in turn, help increase the security of your environment and further remediate vulnerabilities. Second,  NTP will be used by any VMs that utilize the VMware Tools time synchronization. When the host has accurate time, the VMs using it as a time source will also. I prefer to pick a single device inside the firewall (possibly the firewall itself) to serve as my internal NTP source. Then I have all my other hosts sync against that device. This means that if the internet connection goes down, only one system notices and the rest of the systems all stay in sync with each other, though not necessarily with the rest of the world. So set an NTP server choose ”Configuration -> Time Configuration -> Options -> start the NTP service and select “Start and stop with host”". Click ‘Add’ and specify your site’s NTP servers.
  • Official VMware documentation
• Guideline Title: Ensure proper SNMP configuration
  • Title: config-snmp
  • Discussion: SNMP is a protocol for monitoring network resources (hosts, servers, switches, etc). If your environment is not using SNMP, it should be disabled to avoid disclosing ESXi host status information to malicious observers. (Of course, if you’re following along, you’ve already locked down which IPs and ranges can reach the SNMP agent!) The ESXi SNMP agent is disabled by default. To confirm this, run “vicfg-snmp <conn_options> –show”, or to disable it in environments where it is not used, run “vicfg-snmp <conn_options> –disable”. If SNMP is being used, make sure the parameters are properly configured using either vCLI or PowerCLI, or using an API client.
  • Official VMware documentation
• Guideline Title: Disable Managed Object Browser (MOB)
  • Title: disable-mob
  • Discussion: I can’t put it any better than the VMware-provided description for this vulnerability already has. I’ll quote it below directly from the Hardening Guidelines.
    • “The managed object browser (MOB) provides a way to explore the object model used by the VMkernel to manage the host; it enables configurations to be changed as well. This interface is meant to be used primarily for debugging the vSphere SDK but because there are no access controls it could also be used as a method obtain information about a host being targeted for unauthorized access. To determine if the MOB is enabled run the following command on the ESXi shell: “vim-cmd proxysvc/service_list”. To disable the MOB run the following command: “vim-cmd proxysvc/remove_service “/mob” “httpsWithRedirect”". Note: You cannot disable MOB while in lockdown mode. The MOB will no longer be available for diagnostics. Some 3rd party tools use this interface to gather information. Testing should be done after disabling the MOB to verify 3rd party applications are still functioning as expected. To re-enable the MOB: ~ # vim-cmd proxysvc/add_np_service “/mob” httpsWithRedirect”
  • Official VMware documentation
• Guideline Title: When adding ESXi hosts to Active Directory use the vSphere Authentication Proxy to protect passwords
  • Title: enable-auth-proxy
  • Discussion: In environments that use both ESXi Autodeploy and Active Directory to manage hosts, the password used to join Active Directory is sent in cleartext to each host as it boots up, which puts that password at great risk of interception. Instead, VMware provides a vSphere Authentication Proxy to help keep this communication secure. Here are the official deployment instructions.
  • Official VMware documentation

We’ll pick this back up tomorrow and knock out another 5 ESXi hardening checks!

VMware released the vSphere 5.0 Hardening Guide this month and I wanted to take the opportunity to blog my way through it in order to increase my familiarity, heighten its visibility, and provide a forum for discussion of the recommendations and methods to implement an assessment in your own environment.

Since the hypervisor is the heart of your datacenter, let’s start with the ESXi guidelines:

• Guideline Title: Use Active Directory for local user authentication
  • Title: enable-ad-auth
  • Discussion: The credentials to your ESXi hosts are among the most sensitive in your entire datacenter. The root password should only be given to personnel that have an explicit need for it. Other users that need to login to hosts outside of vCenter can have permissions granted to their Active Directory account. David Davis has a great video demonstrating the process. By default, an AD group names “ESX Admins” is checked for and all members will have full rights to all hosts.
  • Official VMware documentation
• Guideline Title: Establish a password policy for password complexity
  • Title: set-password-complexity
  • Discussion: This setting is used to enforce strong passwords for local accounts. You know, the local accounts you’re not using since all your hosts are joined to AD, right? But seriously, this is a great setting to use to force users to pick strong passwords, even if your hosts have no local users. Configuration drift happens, so let’s plan ahead and make sure these users will have strong passwords. Using vi, you’ll edit the file /etc/pam.d/passwd and modify the third line. The default value is “password requisite /lib/security/$ISA/pam_passwdqc.so retry=3 min=8,8,8,7,6″. The retry value controls how many attempts users get to pick a strong password. The last 5 numbers control your desired complexity settings, in the following order and referencing four character classes (uppercase letters, lowercase letters, numbers, and symbols/special characters):
    • The first digit is the minimum length for passwords containing characters from 1 of the classes (least complex, e.g. using “password” as your password). You’ll want this to be a very large number.
    • The second digit is the minimum length for password containing characters from 2 of the classes. You’ll also want this to be a very large number.
    • The third digit is the minimum length of SSL certificate passphrases
    • The fourth digit is the minimum length for password containing characters from 3 of the classes. Now were getting into reasonable passwords, so allow whatever reasonable length your organization permits.
    • The fifth digit is the minimum length for password containing characters from 4 of the classes (most complex, e.g. using “p4$wOrd” as your password”). Same as the previous line.
  • Official VMware documentation
• Guideline Title: Verify Active Directory “ESX Admin” group membership.
  • Title: verify-admin-group
  • Discussion: now that our hosts are joined to AD (first bullet point above), we want to audit the membership of “ESX Admins” since those users will automatically have root-level permissions to our hosts. This is a manual check, but you’ll also want to automate it so that it can run regularly. You can write a scheduled Powershell script to read the group membership and email you the contents on a schedule, or products like ADAudit Plus from ManageEngine are perfect for this task and can email you only when group membership changes.
  • Official VMware documentation
• Guideline Title: Ensure that vpxuser auto-password change meets policy.
  • Title: vpxuser-password-age
  • Discussion: ESXi contains a built-in user account called vpxuser. This account has Administrator-level permissions to the local host and is used by vCenter to execute tasks. vCenter sets this password and changes it automatically every 30 days. If your organization requires more frequent password changes, you can change this from the vSphere client by selecting “Administration -> vCenter Server Settings -> Advanced Settings” and changing VirtualCenter.VimPasswordExpirationInDays to your desired interval.
  • Official VMware documentation
•  Guideline Title: Ensure that vpxuser password meets length policy.
  • Title:vpxuser-password-length
  • Discussion: Similar to the guideline above, this check confirms that the password length for the vpxuser password is long enough to comply with your organization’s security policy. By default it is set to 32 characters. To increase this password length, modify the “vpxd.hostPasswordLength” value in the vpxd.cfg file. On Windows this file is located at C:\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter\vpxd.cfg  or on the vCenter Server Appliance you’ll find it at /etc/vmware-vpx/vpxd.cfg.
  • Official VMware documentation

That’s it for today! I’ll see you all back here tomorrow to continue our discussion on the vSphere 5.0 Hardening Guide.

eGroup, Inc. is among the first of partners in the southeast to become certified as part of EMC’s virtualization and cloud initiative, and first to offer customers complete spectrum of choice when moving to cloud computing.

May 22, 2012 – Mt. Pleasant, SC – eGroup, Inc. today announced its EMC VSPEX Proven Infrastructure certification.  EMC’s VSPEX Proven Infrastructure is a simple, efficient, and flexible reference architecture comprised of EMC’s award-winning storage systems and next-generation backup products, along with best-of-breed virtualization, server, and network technology from EMC alliance partners Brocade, Cisco, Citrix, Intel, Microsoft, and VMware. Read more >>

VMware has released several patches that address vulnerabilities in older ESX and ESXi versions. These patches should be installed as soon as possible to preserve the security of VMware installations.

• ESX 3.5-4.1 and ESXi 3.5-4.1 should install available patches to address a ROM Overwrite vulnerability that allows privilege escalation in Windows 2000 through 2003 R2 guests (CVE-2012-1515).
• ESX 4.0 should install available patches to update the service console to kernel-400.2.6.18-238.4.11.591731 and fix multiple inherited vulnerabilities (
  CVE-2011-2482, CVE-2011-3191, and CVE-2011-4348). The patch for ESXi 4.1 is still pending.
• ESX 4.0 should install available updates to patch Kerberos vulnerabilities (CVE-2011-4862).

As always, the easiest way to patch your VMware hosts is with VMware’s vSphere Update Manager. Update Manager, combined with VMware vMotion, lets you safely patch your critical virtual hosts without maintenance windows, service interruptions, or costly downtime.

To be alerted of security advisories as they are released, you can sign up for email notifications. Advisories are also published on the VMware website.

When building out a rocking cloud over this past weekend, the topic of networking specific to NFS on vSphere came up. One of the questions that was asked was if the “Management traffic” checkbox on a vmkernel needed to be ticked in order of that specifc vmkernel to communicate to the NFS export. I didn’t believe this to be the case, and after some quick testing, we confirmed its as not needed.

The next question that came up is an important one to consider in your implementations of NFS on vSphere– and it was the question of “which vmkernel will be used to communicate to the NFS export?”. It’s important to keep in mind that once the connection to an NFS mount is made, it will continue over the same vmkernel AND NIC that was used to establish the connection, so if you get it wrong the first time, it’ll stay that way until you break the connection and re-establish it (which in our case, we tested by unmounting the export, making our changes, and then remounting).

What I had learned a ways back that I believed to still be true was that the the IP of the NFS server would determine which vmkernel would be used by using the vmkernel’s route table, and if no specific route (or same subnet vmkernel interface), the default route/gateway would be used.

Read more >>