Keep your VMware ESXi warranty: Don't break the security shell

If you have enabled Dropbear SSH or used technical support mode on VMware ESXi without a VMware support representative, you may have voided your ESXi warranty. Learn sanctioned ways to manage VMware ESXi connections.

Working with VMware ESXi can be frustrating; you're not supposed to enable the Dropbear SSH client or use its technical support mode without the assistance of a VMware support representative. System administrators, however, may be tempted to use tech support mode (or enable Dropbear) to fix problems or manage connections on the fly. Cracking this security shell, however, can void the VMware ESXi warranty and break support contracts. In this tip, I'll explain alternatives that allow you to manage your ESXi virtual machines without compromising its security -- and possibly breaking a support contract.

I have been vocal about the VMware ESXi security weaknesses as compared with VMware ESX. This commentary is due to ESXi users who immediately enable the Dropbear SSH client. If you do this, you break the shell! This is not recommended and could void your VMware ESXi warranty and, therefore, your support contracts.

VMware further states that the only time you need to use the technical support mode is under the watchful eyes of a VMware support representative. System administrators, however, often need or want to access tech support mode to fix their own problems, so where is the line drawn? Will accessing this sans VMware representative void your warranty? How do you handle the case when there are intergrated Lights Out (iLO) or Dell Remote Assistant Cards (DRACs) attached to your VMware ESXi host? Before we provide some help on these questions we should go over VMware ESXi's built-in security.

VMware ESXi does have security
The security shell around ESXi is this: Unless you specifically enable SSH or log in via technical support mode, there is no current method to get to the inner workings. The other intriguing aspect of VMware ESXi security is the nature of the boot process. During the boot process ESXi creates a RAM disk that will run the OS. The data stores are then mounted to the RAM disk, and the VMs run from the RAM disk. This implies that any changes made to the OS will not survive a reboot unless they are placed on more permanent storage. Some changes, however, will survive a reboot, as we all know. Acceptable changes are made using the VMware Infrastructure Client (VI Client), Remote Command Line Interface (Remote CLI), Console, or CLI vicfg commands. Any other type of change, like adding in a new daemon, adding other files, etc. may not survive a reboot.

Managing VMware ESXi
VMware took quite a bit of effort to create VMware ESXi with a new type of console, from which you can do many configuration tasks related to security. In addition, there are changes to the VI Client to allow configuration of those actions that used to require manual modifications, such as Network Time Protocol (NTP). Lastly, they have the vicfg- commands that are part of the Remote CLI. This combination of tools makes it so you should never have to use the CLI for normal configuration. You can now control VMware ESXi remotely.

Securing ESXi
I mention quite a bit about securing VMware ESXi, in that there should be an audit trail, Defense in Depth and access to a directory service among other things we commonly use for securing VMware ESX. So how do you secure VMware ESXi? Before doing so we need to analyze what networks there are within the VMware ESXi Infrastructure. Outside what you create for your VMs, you have four major networks.

  • Management network for the management tools to contact
  • Console network for ILO, DRAC, etc.
  • VMotion network
  • Storage network

Securing VMware ESXi implies securing many of these networks as well as making the changes to your ESXi configuration recommended by the VMware v. 3.5 Hardening Guidelines.

  • Completely disable the VMware ESXi shell.

  • Enable remote logging.

  • Configure isolation tool settings for each VM to limit back-door usage, cut and paste, and other necessary items.

In addition to the above items and others within the guideline, be cognizant that access to any of these four networks could compromise your VMware ESXi environment. Things to keep in mind:

  • Console networks should be properly firewalled from the administrative network and access to them should be logged.
  • Management hosts should be well protected and on a management network.
  • Your management network should be properly firewalled from the rest of the environment.
  • If you use VirtualCenter, place it within the management network.
  • Access to the management network should be strictly controlled.
  • Consider placing a firewall between ESXi's management appliance and the management network.

These may seem like Draconian measures to some, but remember that VMware ESXi does not have its own firewall, so you need to add the capability to monitor and manage connections. A firewall does this for you.

To keep things from getting very confusing when it comes to management it is recommended that you use VirtualCenter for all but those tasks that can't use it. This way you have centralized authentication and authorization capability lacking in ESXi. For those without VirtualCenter, you will have to carefully craft roles and permissions for each user involved and add each user to ESXi, which becomes somewhat of a management headache if you have several VMware ESXi hosts.

ABOUT THE AUTHOR: Edward L. Haletky is the author of VMware ESX Server in the Enterprise: Planning and Securing Virtualization Servers. He recently left Hewlett-Packard Co., where he worked on the virtualization, Linux and high-performance computing teams. Haletky owns AstroArch Consulting Inc. and is a champion and moderator for the VMware Communities Forums.

Dig Deeper on Securing a VMware environment