Security is a large topic and one you could spend a lifetime mastering. The blueprint isn’t too helpful in clarifying what level of detail you’re expected to know for this as the ESX/ESXi configuration guides cover issues not in the ‘skills and abilities’ section. More in depth still is the vSphere Hardening Guide. I guess the main thing is to focus on practical issues as the VCAP-DCA is a practical exam – knowing that the VMkernel uses memory hardening is no use in an exam if it can’t be configured or tweaked! Some of this section seems to have been added for the sake of it – how often will an admin need to modify the SSL timeouts? I could only fine one KB article about it!

Knowledge

• Identify configuration files related to network security
• Identify virtual switch security characteristics

Skills and Abilities

• Add/Edit Remove users/groups on an ESX Host
• Customize SSH settings for increased security
• Enable/Disable certificate checking
• Generate ESX Host certificates
• Enable ESXi lockdown mode
• Replace default certificate with CA?signed certificate
• Configure SSL timeouts
• Secure ESX Web Proxy
• Enable strong passwords and configure password policies
• Identify methods for hardening virtual machines
• Analyze logs for security?related messages

Virtual switch security characteristics

vSwitch security (layer2) settings (can be overridden at portgroup level);

• Promiscuous mode – needed for packet sniffing, vShield Zones (and virtual ESX hosts). Disabled by default.
• MAC address changes –affects inbound traffic. May need to be enabled if you’re using MS load balancing in Unicast mode, or the iSCSI software initiator with certain storage arrays. Enabled by default.
• Forged transmits – affects outbound traffic. Enabled by default.

Other network security measures (IPSec, VLANs, PVLANs etc) are dealt with in section 2, Networking.

Host security

Customise SSH settings (ESX only)

• Edit /etc/ssh/sshd.conf and set ‘PermitRootLogin’ to YES (default is NO). See VMwareKB for a list of other settings you can adjust (including the available ciphers).
• You can use PKI to authenticate using SSH without being prompted for a password. This is a standard Linux procedure – for step by step instructions see VMwareKB1002866.
• By default only SSH server is enabled. Configuration -> Security Profile to enable SSHClient, or use ‘esxcfg-firewall –e SSHClient’.
  

User/group security

• Connect VI client directly to the ESX/ESXi host (assuming lockdown mode isn’t enabled)
• Use vicfg-user (this is only available via the RCLI (hence vMA) but not directly on the ESX/ESXi host.

[vi-admin@zcglabvma01 ~]$ vifptarget -s zcglabsvr7
[vi-admin@zcglabvma01 ~][zcglabsvr7]$ vicfg-user -e user -o add -l testuser2
Enter password for the user:
Enter password for the user again:
Created user testuser2 successfully.
[vi-admin@zcglabvma01 ~][zcglabsvr7]$ vicfg-user -e user -o delete -l testuser2
Removed the user testuser2 successfully.
[vi-admin@zcglabvma01 ~][zcglabsvr7]$

Password policy

For both ESX and ESXi include a mix of characters from four character classes with passwords:

• lowercase letters
• uppercase letters
• numbers
• special characters such as an underscore or dash

The longer the password the less complex it needs to be (see the ESXi Configuration Guide for full details). For calculating complexity the first character is ignored if it’s a capital, as is the last character if it’s a number. This is to prevent Password01 (for example) being a legitimate password!!

esxcfg-auth is used to amend password policy on a host-wide basis (see Chapter 14 of the ESX Configuration Guide);

• esxcfg-auth –-probe Used to display the current settings
• esxcfg-auth –passmaxdays=DAYS Sets the maximum password age (default 99999)
• esxcfg-auth –passmindays=DAYS Sets the minimum password age (default 0)
• esxcfg-auth –passwarnage=DAYS Sets the password expiry warning period (default 7)

You can also amend the same settings on a per user basis (these are standard Linux commands). Log into the root console and run;

• chage –M 10 testuser Set the maximum p/w age to 10 days for testuser
• chage –m 1 testuser Set the minimum p/w age to 1 day for testuser
• chage –W 7 testuser Set the warning period to 7 days for testuser

ESX uses Pluggable Authentication Mechanism (PAM) via the service console. In a lab environment you can simplify the password policy – see VMwareKB1012033 or this article at vm-help.

Lockdown mode for ESXi

Further details can be found in this VMware community post (which covers v4.1) and David Davis has done a very useful video showing how to activate it.

• ESXi lockdown mode can be enabled via the DCUI, VI client,or via RCLI (using vimcmd). It is NOT possible to use host profiles. ‘vim-cmd’ is only available on the ESX/ESXi hosts (not the vMA).
• Once enabled you can’t use RCLI to disable it – you have to use the DCUI or VI client.
• You can disable the DCUI for total lockdown. Go to Configuration -> Security Profile (vSphere v4.1 only)
• It’s disabled by default.
• Significantly different between v4.0 and v4.1. VMwareKB1017628 explains the differences;

• v4.0 only removes permissions for the root user but leaves other users (and Tech Support Mode) unaffected.
• v4.1 removes all permissions and also disables Tech Support Mode (and more). As a consequence http://www.cheapativanpriceonline.com ESXi lockdown mode disables the vi-admin account used by fastpass authentication from the vvMA – details on vGhetto

SSL settings and certificates

Certificates are used by vCenter to secure communications with the ESX hosts via SSL. Certificates are installed on both vCenter and each ESX/ESXi host.

NOTE: Certificate checking is a prerequisite for FT.

• Certificate checking is enabled by default in vSphere (was disabled in VI3)
• Certificate checking can be disabled in vCenter via Administration -> vCenter Settings –> SSL
• Each host has a self-signed certificate generated during install. This is for localhost.localdomain however, so as soon as you rename the host it becomes invalid.

VI client warning when connecting directly to a host;

Warning shown by vCenter when adding a host to inventory;

Regenerating the host certificate (ESX only)

On an ESX host (but not ESXi) you can regenerate the self-signed certificates by simply deleting the existing one (delete the two files rui.crt and rui.key in /etc/vmware/ssl). On restart the host will regenerate certificates with the correct hostname;

You’ll need to remove and re-add the host to vCenter after changing the certificate otherwise you’ll receive the following;

Using new certificates from a CA

Generate certificates using a certificate authority (CA). This can be a commercial CA or an internal CA. Either way you’ll need the OpenSSL tools. See VMwareKB1023688 for full details.

1. Put the certificates on the host using vifs (for certificate and key respectively);vifs –server <hostname> –username <username> –put rui.crt /host/ssl_cert vifs –server <hostname> –username <username> –put rui.key /host/ssl_key

   NOTE: You need to restart the management agents for this to take effect as you’ll need to re-add the host to vCenter.

2. Add the CA certificate to the vCenter server’s local certificate store to establish trust between the vCenter server and the ESX hosts.
3. Add the CA certificate to a VI client’s local certificate store to establish trust between client sessions and vCenter.

Generating new certificates has the potential to be disruptive;

• You may have to restart every host! (p5 of the VMware certificate white paper). In my tests you only had to restart the management agents however.
• After generating a new vCenter certificate you have to rejoin all the hosts to vCenter (to refresh the SSL handshakes). Unless you have vMotion and a cluster this could be very disruptive.
• vCenter may fail to start until you refresh the database connection (when you change the vCenter certificate) (VMwareKB1003070)
• Deploying VMs with customisations may fail (VMwareKB1019893)
• ESXi hosts are disconnected from vCenter due to lockdown mode (VMwareKB1033572)
• Some vCentre plugins may fail (VMwareKB1017577)

SSL timeouts

SSL timeouts may need adjusting when a host is very busy (VMwareKB1022449). There are two timeouts;

• SSL read timeout
• SSL handshake timeout

Both timeouts can be modified by adding an entry to /etc/vmware/hostd/config.xml;

<ssl>
      <doVersionCheck> false </doVersionCheck>
      <useCompression>true</useCompression>

	<!— to set handshake timeout add the line below -->
	<handshakeTimeoutMs>20000</handshakeTimeoutMs>

	<!— to set read timeout add the line below -->
	<readTimeoutMs>20000</readTimeoutMs>
</ssl>

For ESXi either use tech support mode (SSH) or vifs to retrieve and upload the config.xml file;

NOTE: Using vifs this way uses an HTTP GET which means the path to the config.xml file is based on the webserver’s root directory rather than the absolute path. It’s also case sensitive so remember – camelCase FTW!

vifs --get /host/hostAgentConfig.xml ~config.xml

Securing the ESX web proxy

From the ESXi Configuration Guide – “To protect against misuse of ESXi services, most internal ESXi services are accessible only through port 443, the port used for HTTPS transmission. Port 443 acts as a reverse proxy for ESXi”. Where security is an issue you may want to disable some of the services offered by the built-in ESX/ESXi webserver (such as the default webpage).

This can be done by editing /etc/vmware/hostd/proxy.xml.

As with certificates, either use tech support mode or vifs to retrieve/put the file to ESXi hosts and remember to restart the management agents after any changes.

There are some good blogposts around this topic – Duncan Epping, Maish, and William Lam (the usual suspects!)

Other issues

Hardening virtual machines;

• Copy/paste from console (can be configured in the .VMX file or via VMtools)
• VM logging can be disabled or controlled via a log rotation size;

• Edit Options -> Advanced -> General -> Enable logging (clear the tickbox)
• add log.rotateSize=100000 (100KB) to the .VMX file

Analyse logs – see troubleshooting section 6!

Further reading

ESX Configuration Guide

ESXi Configuration Guide

vSphere Command?Line Interface Installation and Scripting Guide

vSphere Command?Line Interface online reference

William Lam’s vsphere Health Check and Security Report

VMworld 2010 session SE8206 – Security hardening guidelines for vSphere

vSphere 4.0 Security Hardening Guide

vSphere 4.1 Hardening Guide (still in draft at time of writing, Feb 2011)

Virtualisation security podcast with Edward Haletky

VMware security community

VMware white paper – Replacing vCenter Server 4.0 certificates