Manage Learn to apply best practices and optimize your operations.

Top 10 ways virtualization threatens security

With virtual technologies, you can unknowingly compromise your architecture's security. In this tip, we present system admins' top 10 security mistakes.

While researching virtualization security for my next book, I discovered some common areas where system administrators may be unknowingly undermining their computing architecture's security and causing vulnerabilities to possible future attacks. These issues range from improperly secured networks to trusting that technologies such as SSL and VLANs are fool-proof. Here are the top ten issues I've uncovered.

  1. Virtualization administrators are not security administrators
    Virtualization administrators aren't security administrators, nor do they always consult or listen to their security administrators. This problem can be mitigated by educating security administrators about the realities of virtualization and also educating the virtualization administrators in the language the security administrators use.

  2. The management appliances for virtualization servers are within improperly secured or unsecured networks
    I have found service consoles on the Internet, on production and on DMZ networks. The service console and all management tools should be on their own administrative network.

  3. Trust in SSL is absolute
    SSL is not the be all and end all to security. There is an attack against SSL that is easy to do and takes less than two seconds. Do not assume SSL is secure enough. Unless pre-shared certificates are in use, SSL is at risk. If you must use SSL-based management tools, use the Administrative network for this work where you can trust who is on the network. In addition, use good VPNs to access the administrative network from outside the network.

  4. Virtual machines (VMs) are not considered a hostile environment
    VMs within a demilitarized zone (DMZ) or otherwise Internet-facing are a hostile environment, but all VMs are hostile when it comes to virtualization. An attack on one VM should never directly or indirectly lead to the virtualization host.

  5. NFS and iSCSI storage networks are not segregated from all other networks
    NFS, iSCSI, and SAN storage pass data in clear text, which implies disk data can be read by others. If a VM has mounted an iSCSI target from the same storage network as used to hold virtual disks, then this is a possible attack point.

  6. VirtualCenter is placed on the outside of the administrative network
    While VMware ESX is firewalled, VirtualCenter is on the wrong side of the firewall. It should be as protected as the virtualization hosts. Access to VirtualCenter or hosts using the VMware Infrastructure Client (VI Client), Remote CLI or SDK should only be attempted from within the administrative network.

  7. Extra service console ports exist
    When attaching a NFS server to ESX, a service console (SC) port is also created. This is a mistake; iSCSI needs service console participation, not ESX. The service console should access the storage network through a router, gateway and preferably a firewall. For every service console port you add, you double your existing attack vectors.

  8. Service console is placed within the DMZ or hostile environment
    This is a common mistake as the service console should absolutely never be placed within a hostile environment. This includes hanging off the Internet or within a DMZ.

  9. Trusting that VLANs will protect the network
    While the use of a vSwitch does protect from VLAN attacks originated by the VMs and some attacks going to the VMs, the use of virtualization will not protect you from VLAN attacks outside the virtualization host. You need very good switching hardware to protect from most of the known VLAN attacks. The VLAN RFC does not mention VLANs as a way of implementing security. Also, the use of VLANs introduces data co-mingling over the wire.

  10. Not understanding security within the hypervisor
    If you do not understand the security within the hypervisor, you will be hard pressed to define how to secure your virtualization environment.

These ten issues are by no means the only areas of concern when analyzing virtualization and potential security threats. I recently raised 28 specific security questions to VMware for comment. I have gotten answers back on each of these questions but two. I recommend asking any and all security questions to a reputable source to get the best security for your environment. The bottom line: security should never be an add on, it should be part of the design from the beginning.

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, 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

Join the conversation

1 comment

Send me notifications when other members comment.

Please create a username to comment.

How to help me understand the security within the hypervisor?