Building a virtual fortress

With virtualization entering the computing mainstream, it’s time to start thinking about securing virtual infrastructure. By Harshal Kallyanpur

Security threats have always been a key concern for IT managers in the case of traditional IT infrastructure, which has largely been physical. The growing use of virtualization is starting to change this as the boundaries defined by a physical server, or by physical network devices, disappear due to the level of abstraction that a virtualized infrastructure brings about.

In the physical world, every physical server is a unit in itself, with its own hardware, operating system and applications, network interface card and IP address that uniquely identifies it as a physical entity. Even if compromised, to a great extent, the problem can always be mitigated by isolating the machine from the rest of the network and quarantining it until the threat has been eliminated.

In a virtualized environment, however, you have several physical servers being used to host dozens of virtual machines (VM). In this scenario, each physical unit is a single point of entry for attacks and exploits on all of the VMs that it hosts. Therefore, a different approach is required to secure a virtualized environment.

At the hypervisor

The hypervisor is the backbone of any virtualized infrastructure. Interactions between the virtual machines, storage and networks happen via this layer. It is the mothership for all of the virtual machines that are hosted on it and any attack on the hypervisor can potentially bring down the entire virtual server infrastructure.

Giridhar LV, General Manager and Head, VMUnify, MindTree, commented, “The hypervisor forms the common layer for compute, storage and networking to the operating system on each virtual machine. Someone with access to the hypervisor can see what is happening at each layer and, by using the right tools, can exploit it.”

According to Giridhar, a virtual machine running on a hypervisor, with malicious tools or applications would give an attacker the ability to sniff data packets flowing on the hypervisor, between virtual machines and thereby help him in launching an attack on the virtualized server infrastructure.

Bipin Kumar Amin, Principal Consultant, Borderless Networks – Security, Cisco India, mirrored this viewpoint. He said, “A lot of attacks on the hypervisor can be launched via the host OS or the operating system on the physical server that hosts the hypervisor or from the guest OS of the virtual machines running on top of the hypervisor.”

As opposed to this, bare metal virtualized environments, where the hypervisor is running a bootable image directly on the physical server, tend to be more secure, as virtualization vendors ensure that the hypervisor layer is hardened to protect it against potential security threats here. There have not been any attacks reported on virtualized environments that employ bare metal virtualization.

Hypervisor vendors are constantly working towards ensuring that the surface area or the footprint of the hypervisor is smaller, leaving lesser room for attacks. They also focus on hardening the hypervisor layer in order to ensure optimal protection against vulnerability exploits. Most virtualization software providers have EAL certified their hypervisors to assure users that they have taken care of the security requirements.

Vivek Sehgal, Product Specialist – Server Virtualization & Cloud Computing, Citrix Systems India, said, “We made the surface attack area on our hypervisor as small as possible by removing unwanted agents and services that were running on it. For instance, features such as ZenMotion or distributed dynamic workload balancing, which are core to the virtualization environment, are part of the virtualization layer. Features such as dynamic virtual switching can be kept out of the hypervisor kernel.”

By doing so, the enhanced capabilities are kept outside the hypervisor and offered as a virtual appliance in such a way that even if these capabilities or the appliance is exploited, they do not affect the hypervisor kernel. Vendors also release hypervisor hardening guides. Amin of Cisco was of the view that not much stress was given to following this guide religiously, despite it being essential from the perspective of hypervisor security.

Kartik Shahani, Country Manager, RSA India & SAARC, was of the view that getting access to other resources through a VM in a hypervisor environment, where the hypervisor is hardened and the code optimized, was harder than breaking into a physical server.

As there have been no credible attacks on the hypervisor yet, virtualization solution vendors have not yet opened up their hypervisors for third party solution providers to embed security features. Attackers too, have largely focused on exploiting vulnerabilities at the network or the virtual machine level as attacks at these layers in the virtual world can be similar to those launched at a network and server layer in the physical world.

Preetham Gopalaswamy, Director of Product Management for Virtualization, McAfee, felt that this situation could change once attackers began actively looking at exploiting the hypervisor for launching an assault on the virtual server environment.

Networks: Guarding the doorways

For a virtualized environment, the network forms the critical point in the infrastructure that needs to be monitored as it forms a single point of entry into virtual server infrastructure and, therefore, becomes a favorite among attackers looking to exploit vulnerabilities in the system. However, the network architecture in the case of virtualized infrastructure, differs from that of a physical server, adding a certain level of complexity to enforcing security mechanisms.

In the case of traditional physical server infrastructure, every server is mapped to an actual switch or network device that monitors and routes all data flowing into the server and out of it into the network. The server, at its end, has its own IP address and set of ports for communication.

In the virtual world, several virtual machines with their own set of virtual ports, communicate with a single server via virtual switches that, in turn, talk to a physical switch. Within the hypervisor, the virtual machines communicating with each other form their own internal virtual network which has no interface with the physical switch unless data from these VMs is flowing out of the network. This makes network monitoring for VMs a complex process.

“A lot of data traveling between the VMs does not come into direct contact with the physical network. This creates a blind spot, as data traveling from a VM that communicates directly with the physical switch can be monitored, while data flowing between virtual switches on virtual machines is not available at the physical level for monitoring,” commented Sehgal of Citrix.

According to Sehgal, Citrix’s Xen hypervisor featured a Distributed Virtual Switch, which allowed access to virtual switches of each of the VMs hosted on the hypervisor. It also included a firewall that could be enforced at the virtual switch level or even at an individual VM level. The feature also allowed defining access controls for each VM at the port level. Sehgal said that these features helped detect vulnerabilities and block attacks at the level of the virtual network created between the virtual machines.

Seema Ambastha, Director – Technology, VMware India, was of the view that the network had to be secured, as all access to virtualized infrastructure took place through it. Therefore, wherever a VM moves, its network attributes and policies should move with it in order to prevent any kind of intrusion into the VM in question.

VMware, through its vShield Edge solution, provides a stateful inspection firewall that monitors both inbound and outbound traffic on the virtual server infrastructure. The application also allows you to define and enforce access control policies at the network level. These policies can be custom defined or based on predefined templates or they can be integrated with other solutions that provide access control policies through APIs.

vShield also offers port mirroring, which means that the communication between the ports of two VMs is replicated on a separate set of ports that interface with the physical switch allowing anomalies to be detected by network intrusion prevention solutions even at the VM level. Many security vendors offer solutions that work in tandem with such features of virtualization solutions and offer intrusion detection and prevention at the network level.

The vShield App solution monitors network traffic at the VM level at a virtual NIC level. It monitors communication for every VM at the port level and secures it against attacks launched from one VM to another. It also allows for grouping VMs into various security groups based on the business criticality of a particular VM, with access control features at the user group or individual level.

Amin of Cisco suggested that enterprises such as IT/ITeS companies, which had a variety of VM environments, could look at grouping these into zones based on the type of customer. On the other hand, an enterprise which has only a few types of VMs could go in for edge-based virtual security, which focuses on all traffic that goes through.

Protecting virtual machines

The virtual machine forms the most sensitive part of a virtual server infrastructure from a security standpoint. A virtual machine can be broken into, from the network, and used to launch a malicious attack on the remaining virtual machines. It can also be used to break into the hypervisor, which can eventually bring down the entire virtual server infrastructure. Therefore, a virtual machine must be protected at all times.

In the physical world, every OS on a physical server would have an endpoint security application running on it to scan for malware during boot up and run time. In principle, the same concept applies to the virtual world wherein you can have an anti-malware/anti-virus application running on a virtual machine, scanning it for malicious code or applications. However, it is impractical to do so, in the real world.

Gopalaswamy explained, “Protecting a virtual machine should be similar to protecting a physical one. The challenge, however, is that where you used to have one image running on one server, you now have anywhere between 10 to 20 virtual server images running on a single server. In the case of virtual desktops, there are instances, wherein organizations are hosting up to two hundred virtual desktop images on a single server.”

Running an endpoint security solution on each of these VMs would result in tremendous resource utilization. So much so that it could even bring the infrastructure to its knees.

Ambastha of VMware India concurred, “An endpoint security solution running on thousands of virtual desktop machines can cause a bootstorm. When the desktops boot up, each security application will start scanning causing the system to hog memory and compute resources, making it difficult to run other applications. In some cases, it can even bring down the physical server.”

In this case, if the user aborts scanning, it might leave room for vulnerabilities. To avoid such situations virtualization vendors such as VMware, offload virus scanning functions to a secure virtual appliance, which is a separate virtual machine interfacing with an agent on every VM image. The appliance works with a third party endpoint security solution in an offload capacity and all data scanning and monitoring is done on this appliance.

While it reduces the overheads associated with having a copy of the same security solution running across every VM, the flipside is that data has to be sent to the virtual appliance each time that it needs to be scanned. However, it is said to considerably reduce malware scanning overheads.

For instance, McAfee offers Management for Optimized Virtual Environments or MOVE, which integrates with virtualized infrastructure from vendors such as VMware and Citrix and offers malware scanning capabilities in offload mode. The solution also offers caching capabilities such that, attributes such as OS and configuration data which are common to a set of, say, similar virtual desktop images, are scanned only once and cached. The next scan only looks at incremental changes. It only scans files if changes have made to them or are being attempted.

This means that clones made from a parent virtual desktop image will not be scanned unless specific changes have been made to them.

Ambastha of VMware India added, “Security solutions for virtualized environments are just as mature as those for physical ones.”

Access Control: Entry Restricted

One of the ways of ensuring maximum security for a virtualized environment is effective access control.

According to Frank Feldmann, Director, Strategic Sales & Field Enablement, Red Hat Asia Pacific, virtualized infrastructure, which form the basis of private or public Clouds, is being thrown open for use to the public. As end-users gain control of the infrastructure, stronger access controls are needed.

Feldmann commented, “Giving self control to a lot of users is like giving a Ferrari to a ten year old. Not only do organizations need robust access control, they also need training and education.”

The ability to quickly create VMs based on free templates provided by many Cloud manufacturers can led to a scenario where orphan VMs or those that haven’t been patched exist. If such VMs gain access to an enterprise infrastructure, it can spell trouble. Such situations can be avoided through better access control and proper education.

The management console for a virtual infrastructure provides access to all VMs so that changes can be made at any level such as configuration or resources. VMs can be moved between physical hosts based on assigned policies. However, unauthorized access to the management console can compromise the virtual infrastructure.

According to Giridhar of MindTree, if an organization does not put too much of stress on approvals when creating a VM, it could end up with a VM sprawl that’s difficult to manage. He said, “VMs can be created quickly and easily. If an organization ends up running a large number of VMs, it will be hard to trace a VM, which has a sniffer recording packets.”

“There should be policies and mechanisms to track the storage and movement of VMs. If a VM with a source code repository for a production app leaves the organization, then it could end up in the wrong hands,” he added.

“Organizations need to apply common sense when consolidating their physical servers. Instead of putting critical application servers alongside non-critical ones, it would be a good idea to have policy-based provisioning to group critical application VMs into one group and non-critical ones into another,” said Feldmann of Red Hat.

Red Hat has extended features from its Security Enhanced Linux solution to its virtualized environments. E.g. host security is set to the highest level. It then provides the user organization with the ability to set security levels and policies based on their requirements.

MindTree recently released an identity-based solution called VMUnify that helps manage a virtualized environment. According to Giridhar, the solution enforced multi-tenancy at a network level by enabling organizations to isolate VMs into network groups based on various parameters. Each VM is provided with a key which allows it to be identified as a part of a particular group of VMs. Any new VM wanting to be a part of the infrastructure must first be authorized. If the VM is moved to an unauthorized infrastructure, even one based on the same virtualization platform, it will not boot up.

Furthermore, it stores VM images in an encrypted format that’s decrypted on the fly when booting up. The solution also imposes granular access controls so that a particular user or user group cannot perform or access parts of the VM that lie outside his or her role.

Sehgal concluded that Citrix offered public and private key-based access controls, while the complete communication between the management console and the physical hosts was SSL-encrypted. Access to the management console is role-based such that a particular user for the management console cannot use the console to make any changes to the VM beyond what his role defines or even take control of the VM or resources. The company also allows defining access control policies at the VM level to restrict a VM to a specific host. VMs can be associated with specific CPUs such that they do not draw resources from any other CPU on that host. Access policies can be defined at the VM file level to prevent deletion, copying or moving of VMs without the necessary permissions.

harshal.kallyanpur@expressindia.com

Comments (0)
Add Comment