Tip

Top 10 ways virtualization threatens security

Edward L. Haletky, contributor
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

    Requires Free Membership to View

  1. can trust who is on the network. In addition, use good VPNs to access the administrative network from outside the network.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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.

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

  8. 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.

This was first published in November 2008

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

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.