Tag: Security

The worst security fear of any virtual environment is having a VM be able to gain access at the host level which can allow it to compromise any VM running on that host. If a VM was to gain access to a host it would essentially have the keys to the kingdom and because it has penetrated into the virtualization layer have a direct back door into any other VM. This has often been referred to as “escaping the cave” as the analogy goes that VMs all live in caves and are not allowed to escape it by the hypervisor.

Typically this concern is most prevalent with hosted hypervisors like VMware Workstation that run a full OS under the virtualization layer. Bare metal hypervisors like ESX/ESXi have been fairly immune to this as they have direct contact with the bare metal of a server without a layer in between.

A new vulnerability was recently published that allows this exact scenario, fortunately if you’re a VMware shop it doesn’t affect you. It does affect pretty much every other hypervisor though that does not support the specific function that this vulnerability exploits.

You can read more about it here and here and specifically about VMware here. If you want to know more about security with VMware here’s an article I also wrote on how to steal a VM in 3 easy steps that you might find interesting. VMware also has a very good security blog that you can read here and a great overall security page with lots of links here. And if you want to follow one of VMware’s security guru’s (Rob Randell) who is a friend of mine and a fellow Colorado resident you can follow him here.

VMware has traditionally done an awesome job keeping ESX/ESXi very secure which is just one of the many reasons that they are the leader in virtualization. Security is a very big concern with virtualization and any vulnerabilities can have very large impacts which is why VMware takes it very seriously.

Here’s also an excerpt from my first book that talks about the escaping the cave concept:

Dealing with Security Administrators
This is the group that tends to put up the most resistance to VMware because of the fear that if a VM is compromised it will allow access to the host server and the other VMs on that host. This is commonly known as “escaping the cave,” and is more an issue with hosted products such as VMware Workstation and Server and less an issue with ESX, which is a more secure platform.

By the Way

The term escaping the cave comes from the analogy that a VM is trapped inside a cave on the host server. Every time it tries to escape from the cave, it gets pushed back in, and no matter what it does, it cannot escape from the cave to get outside. To date, there has never been an instance of a VM escaping the cave on an ESX server.

ESX has a securely designed architecture, and the risk level of this happening is greatly reduced compared to hosted virtual products such as Server and Workstation. This doesn’t mean it can’t happen, but as long as you keep your host patched and properly secured, the chances of it happening are almost nonexistent. Historically, ESX has a good record when it comes to security and vulnerabilities, and in May 2008, ESX version 3.0.2 and VirtualCenter 2.0.21 received the Common Criteria certification at EAL4+ under the Communications Security Establishment Canada (CSEC) Common Criteria Evaluation and Certification Scheme (CCS). EAL4+ is the highest assurance level that is recognized globally by all signatories under the Common Criteria Recognition Agreement (CCRA).

For better or worse, administrators usually accept the default VMware hypervisor security settings.

VSphere is fairly secure, but VMware security breaches can still occur. Careless mistakes and questionable administrative decisions can weaken infrastructure security — especially if IT pros are more concerned about management convenience than about hardening the hypervisor, hosts and virtual machines (VMs).

To help prevent snafus, here are five ways to maximize VMware hypervisor security.

Firewalls prevent VMware hypervisor security from getting burned
Physical firewalls protect servers and devices directly connected to physical networks, but they aren’t always effective at protecting VMs connected to virtual networks. So use virtual firewalls in conjunction with physical firewalls to ensure that network traffic is secure at every level and nothing slips through the cracks.

Sometimes, virtual machine network traffic doesn’t leave the host or travel over a physical network. Traffic between VMs on the same vSwitch and port group remains inside the host. It travels in the host’s memory, through the virtual network — rather than over the physical network. As such, it’s outside the physical firewall’s protection zone.

Read the full article at searchvmware.com…

Security is critical in a vSphere environment. Virtual machine (VM) architecture, access methods and management is much different from that for physical servers. Because VMs are encapsulated into a single file that resides on a shared data store, additional attack vectors need to be secured. Further, any change or operation in a virtual environment can have a ripple effect on other residing VMs because all share common infrastructure components. Consequently, having proper security access controls in place is paramount to protect hosts and their VMs.

Because they have multiple components, virtual environments are secured in layers. You can do much of the work to secure an environment through vCenter Server, which provides centralized authentication and authorization services at many different levels inside vSphere. VCenter Server features four main components:

• Privileges. A privilege enables or denies users access to perform actions in vSphere.
• Roles. A role is a set of privileges that can be assigned to a user or group.
• Users and groups. Users and groups are used in permissions to assign roles from Active Directory (AD) or local Windows users/groups.
• Permissions. A permission is assigned to an object in vSphere and is composed of users/groups and a role.

Read the full article at searchsystemschannel.com…