VCP 4 Prep Objective 1.3 – Secure VMware ESX/ESXi

Objective 1.3 – Secure VMware ESX/ESXi

-Identify default security principles

ESX has four security components: the virtualisation layer, the virtual machines, the service console and the virtual networking layer.

The virtualisation layer (VMKernel) has security features, such as Memory hardening and Kernel module integrity.

Memory hardening; this features uses something similar to address space layout randomisation thus kernel components do not have a static memory address from where they’re executed. VMware also uses non-executable memory protection presented by Intel and AMD, restricting the likelihood of malicious code being executed.

Kernel mode integrity; this feature uses digital signatures to verify the authenticity and integrity of modules, drivers and applications loaded by the virtualisation layer.

Access to the virtualisation layer is restricted, the only interface being VMware defined APIs.

The virtual machine security is very handled by the VMKernel; the VMkernel isolates each virtual machine into its own world. Each world has its own memory mappings, shared processor, network and disk which is arbitrated by the VMKernel resource scheduler. The virtual machines are by default governed by resource shares, this negates one virtual machine hogging the host server resources when those resources are needed by other virtual machines. In addition to resource shares are resource limits and reservations; limits do just that, they cap the amount of resource a virtual machine can have, whereas reservations provide a minimum guaranteed amount of resource.

The virtual network layer uses security features such as VLANs, layer 2 security policies and firewalling.

Virtual switches are similar to physical switches in that they maintain a MAC table, support VLANs and IEEE 802.1q trunking. Virtual switches do not participate in spanning tree though.

By default virtual switches have safeguards in place to protect against the following threats:

  • MAC flooding
  • 802.1q and ISL tagging attacks
  • Double-encapsulation attacks
  • Multicast brute-force attacks
  • Spanning-tree attacks
  • Random frame attacks

MAC floodings is an attack on the content addressable memory (this is where the switch learns and stores the source MAC address of each packet) of a switch, once this memory is full a switch can enter a fully open state where every packet would be broadcast on every switch port. VMware vSwitches are not vulnerable to this attack due to the way they capture the MAC addresses.

802.1q and ISL tagging attacks attempt to trick the switch into trunking and broadcasting traffic to other VLANs. VMware vSwitches do not perform dynamic trunking therefore are not vulnerable.

Double-encapsulation attacks attempt to trick the switching into forwarding the packet to a different VLAN than the VLAN in the outer packet. VMware vSwitches are configured to drop any double-encapsulated frames.

Multicast brute-force attacks attempt to overload the switch causing frames to be broadcast to other VLANs. VMware vSwitches are not vulnerable to these attacks because vSwitches do not allow frames to leave their broadcast domain.

Spaning-tree attacks are negated because VMware vSwitches do not support STP.

Random frame attacks attempt to trick the switch into routing packets to a different VLAN than the one specified by randomly changing the packet header length, service type and content.

The firewalling can be configured using 3rd party appliances, vShield zones or hardware firewalls; if a hardware firewall is in used then VLANs trunking will more than likely be necessary.

The Service console is based on Red Hat Linux but with minimal services available. The Service Console is secured by default by a firewall, this firewalls default setting is high security which blocks all outbound and some inbound access (Ports required to connect via the vSphere client are open). The services running within the Service Console such as Tomcat are stripped down to limit the attack surface, SSH access is restricted to standard users by default; you would need to sudo for root access.

By default ESX uses the /etc/passwd for authentication; ESXi uses usernames and passwords authenticated by the vmware-hostd process.

The password requirements are the same across both ESX and ESXi; they are:

  • Character classes
    • Lowercase letters
    • Uppercase letters
    • numbers
    • special characters e.g. !”£$%^

The characters classes above will determine the minimum password length.

  • A minimum password length of six characters if all four classes are used.
  • A minimum password length of seven characters if at least three classes are used.
  • A minimum password length of eight characters if at least two classes are used.

If a phrase is used the phrase must contain three words, each word being eight characters in length.

By default password aging is configured as follows:

  • Passwords never expire
  • Users can change their passwords at anytime
  • Users would be notified of password expiry seven days prior, if password expiration was configured

By default the ESX administrator role is granted to the root user, if the host is managed by vCenter the vpxuser is also granted the administrator role. In regard to ESXi there is one additional user; the dcui user which is also granted the administrator role and is primarily responsible for configuring lockdown mode.

The three default roles are:

  • administrator
  • read only
  • no access

As defined above the administrator role is granted to a limited number of users. The no access role is granted to all users unless they have been explicitly defined in a custom group.

By default all network traffic is encrypted using self signed certificates; the certificates are 1024bit RSA and encryption is 256bit AES. If you change the service console firewall level (ESX only) or modify the reverse web proxy, network traffic may leave encrypted.

By default the SSH server is version two with supported 128 or 256bit AES ciphers. Root logins are disabled by default and it is recommended this be kept in place.

Copy and paste operations are disabled by default.

-Understand Service Console firewall operation

By default the Service Console firewall outbound ports are closed and the only inbound ports are those required for the vSphere client to connect; the default ports are TCP 22, 443, 902, 5988, 5989 and UDP 123, 427.

The Service Console uses 256bit AES block encryption to secure data inbound communications.

–Service Console security level

By default the Service Console firewall is configured for high security, you can if necessary change the firewall to medium or low security; medium security opens outgoing traffic fully, incoming traffic stays in the same state as high security. Low security sets the firewall state to the equivalent of off.

–Opening / closing ports in the firewall using the vSphere client / cli

To configure the firewall to allow a specific port run the following command or follow the UI workflow.

UI: Select the configuration tab > security profile > properties

CLI: esxcfg-firewall –openport Port_Number,[tcp|udp],[in|out],Friendly_Name

To configure the firewall to block a specific port run the following command or follow the UI workflow.

UI: Select the configuration tab > security profile > properties

CLI: esxcfg-firewall –closeport Port_Number,[tcp|udp],[in|out],Friendly_Name {optional}

-Set user and group accounts

To add a user or group to a local ESX or ESXi host connect to the host using the vSphere client.

To add a user click the users and group tab, then click users, click Add.

  • login [mandatory]
  • uid [optional]
  • username [optional]
  • password [mandatory]
  • group [optional]

To add a group click the users and groups tab, then click groups, click Add.

  • Group name [mandatory]
  • gid [optional]

-Determine applications needed  for accessing the Service Console in a given scenario

The Service Console is accessible from the a local terminal i.e. a monior and keyboard, an SSH session, the vSphere client or a web browser.

The local terminal access and SSH access would allow the greatest functionlity i.e. some commands are not available to the vSphere client thus they can only be run on the command line. It is worth noting you’ll need to create a standard user first as root access is disabled over SSH; once you’re connected with a standard user you can use sudo to elevate your privileges to root.

Web Access is useful for administering virtual machines; NOTE ESX/ESXi configuration is not available via Web Access.

The vSphere client should be the first port of call, all day to day tasks can be performed with this client.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.