• Login
• Become a member
• RSS
• Part of the TechTarget network

VMware vShield adds a layer of protection to vSphere, which is already a fairly secure product out of the box. These 10 VMware security tips will help vShield users eliminate trivial, time-consuming errors.

VMware security tip No. 1: Practice makes perfect
VMware security is complex, and configuration errors can be costly. If you make mistakes with the vShield rules, for instance, you can shut down network traffic to virtual machines (VMs). So it's best to gain experience on noncritical hosts.

VMware security tip No. 2: Use auto startup
Set the vShield Manager, Zones and App agents to auto startup when a host boots. Until the Zones and App agents start, no VM network communication will occur on a host.

VMware security tip No. 3: Lock down vShield agents
The Manager, Zones and App VMs are important for both VM security and connectivity, so you should change their default passwords with the vShield Manager Web interface or command-line tool. Also, change the default passwords to the privileged Enabledmode.

Unfortunately, you cannot change the password for the default admin command-line interface account on the vShield Manager and agent VMs. It must be deleted, and you need to create a new one -- which won't affect anything, because other accounts (e.g., nobody and vs_comm) are used by vShield for normal operations. But you can change the Enabledmode's password. View the vShield Administration Guide (download PDF) for more instructions.

VMware security tip No. 4: Secure vShield access
Only authorized users should interact with vShield Manager and its agents in vCenter. If something happens, such as an accidental power off, you can lose network connectivity on the hosts.

VMware security tip No. 5: Beware case sensitivity
A quirk in vShield 4.1 Update 1 requires that the word "any" must appear in capital letters for Zones and App Firewall rules. Otherwise, the rules will not work properly. It's a known issue that will be fixed in the next release.

VMware security tip No. 6: Use caution when deleting disks
The vShield Manager VM has a main, 8 GB virtual disk and a secondary, 1 MB virtual disk. Do not remove the secondary disk, because it's used to deploy new App and Zones agents. It also contains important parameters, such as the IP addressing information, and it's used to bootstrap the vShield App as it's being deployed.

VMware security tip No. 7: Restart when uninstalling
Installing vShield doesn't interrupt the hosts or VMs, but you must restart the host when uninstalling vShield. To uninstall vShield from a host, move the VMs to another host or power them off. Then put the host in maintenance mode and restart it.

The host requires a restart to properly remove the vShield loadable kernel module that's installed in host's memory. The uninstall process removes everything except the special vSwitch, which isn't automatically removed, because other products may be using it.

VMware security tip No. 8: Don't touch VMware Tools
A specific version of VMware Tools is preinstalled on the vShield Manager and agent VMs. Do not update or remove it.

Virtual appliances are built and customized for the application that's running inside. Typically, you shouldn't update an appliance outside of its normal update process. VMware Tools is a collection of drivers and utilities, and the version that's preinstalled works with the vShield application. Newer versions have not been tested and could potentially cause problems.

VMware security tip No. 9: Use new alarms
VShield automatically installs new alarm types that can check for vShield-related events and conditions. Take advantage of these alarms to improve VMware security monitoring.

VMware security tip No. 10: Check resource availability
It's critical that vShield Manager and agent VMs are not resource constrained. If that occurs, vShield Manager can become unresponsive, and VMs can lose network connectivity.

VShield VMs have preconfigured memory reservations that guarantee physical-host memory. Do not change these settings or reduce the assigned memory. There are no CPU reservations configured by default, however. On a busy host, you may want to set one -- or set the CPU shares to high -- to guarantee CPU resources.

Join the conversationComment

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.