Discover. Determine. Defend.
The Impact of Virtualization on Network Security
EXECUTIVE SUMMARY
Virtualization is a concept that has become highly visible in the last few years because of its
perceived benefits in reducing costs, enabling rapid deployment, and improving system
availability. These benefits are rooted in the ability of virtualization to separate a physical host into discrete sub-environments known as virtual machines. Virtual machines operate like physical machines in that they run their own operating system and applications. Yet virtual machines exist as file images and can be quickly provisioned, copied, moved, and restored.
With all of its benefits, however, virtualization also creates new security risks. For example, an attacker who gains access to one virtual machine can potentially compromise every other virtual machine on that host by exploiting the virtual machine monitor, or hypervisor, on that host. Other risks are created by “virtual machine sprawl,” where virtual machines are scattered throughout a network because of a lack of coordination in provisioning and updating them. Security risks become more tangible because a virtual machine that is not properly tracked and managed may not have updated patches or proper configuration control, leading to vulnerabilities that can be exploited.
INTRODUCTION
Virtualization has been receiving significant attention because of the various benefits it offers to organizations. Examples include reducing costs, improving system availability, and enhancing speed of infrastructure deployment. According to a survey conducted by Symantec in late 2007, 90 percent of the survey respondents have
implemented or are considering virtualization for their data centers, and 50 percent have actually implemented it. Virtualization projects range from server consolidation and disaster recovery to the simplification of provisioning for desktops and associated applications.
Security is a relevant issue, however. Industry analysts are now saying that virtualization actually creates new attack opportunities. Unfortunately, there is not a lot of awareness about what these new
opportunities may be. An
InformationWeek poll conducted in 2007 revealed that 43% of
virtualized hardware was just as secure as
physical hardware, and only 12% had put in formal strategies to protect their virtualized systems. This paper seeks to address various questions that may arise about the impact of virtualization on security:
• What new risks are created by implementing virtualization?
• What steps need to be taken to secure a virtual system or network?
• How can I leverage my existing investment in security to protect virtual systems?
Guidance on protecting virtualized environments and best practices will also be provided.
VIRTUALIZATION DEFINED
Market leader VMware describes virtualization as “the separation of a resource or request for a service from the underlying physical delivery of that service.” There are various types of
virtualization from a technical standpoint, but the one discussed in this paper is known as server or full virtualization, which is the most prevalent type used for production.
Server virtualization divides a physical host into discrete sub-environments known as virtual machines or VMs. Each VM is a true representation of a physical host with its own processor, memory, storage, and network connections. A control program, also known as a virtual machine monitor (VMM) or a hypervisor, abstracts and coordinates access to the physical host hardware (i.e.,
processor, memory, storage, etc.) so it can be used simultaneously by multiple VMs.
Server virtualization can be further divided into Type 1 and Type 2 virtualization. Figure 1
illustrates the differences between the two types. Type 1 relies on a hypervisor that runs directly on the physical host hardware or with a stripped-down, streamlined operating system.
The hypervisor is therefore running closer to the “bare metal” of the physical host because it does not rely on an intermediary general-purpose operating system such as Linux or UNIX.
Examples of Type 1 virtualization include VMware ESX Server and Citrix XenServer.
Type 2 virtualization uses a hypervisor that runs as a standard application on a physical host’s
operating system. The hypervisor therefore does not have the direct access to the physical
hardware that a Type 1 hypervisor has. Examples of Type 2 virtualization include VMware Server, VMware Workstation, Microsoft Virtual PC, and Parallels.
Virtualization has several properties that provide the foundation for many of its benefits. These properties are partitioning, isolation, and encapsulation and each is defined below:
• Partitioning: Each virtual machine has its own respective processor, memory, network connection, and storage so it can run a completely separate operating system and applications from other VMs on the same physical host. Physical resources such as memory and disk space can be potentially pooled and shared among VMs.
• Isolation: Virtual machines are isolated from each other and from the host machine. Any crash or corruption on a VM should not affect any other VM.
• Encapsulation: Each virtual machine is
encapsulated as a single file that can be easily copied or moved to another host. The state of a VM can be preserved as a snapshot that can be quickly restored.
Other examples of virtualization that will not be explored here are operating system virtualization (operating system is separated into virtual OS partitions that share a common kernel) and application virtualization (an application runs in a small virtual environment with its own registry entries, files, and global objects). Examples of operating system virtualization are Solaris zones and User Mode Linux, while examples of application virtualization are the Java Virtual Machine and the Common Language Runtime used by Microsoft’s .NET.
ADDITIONAL CAPABILITIES
Three additional terms also require explanation because they are involved in the discussion of how virtualization affects network security.
Virtual Infrastructuredescribes a set of management services that help to optimize utilization of virtual resources and better meet availability, maintenance, and service-level
objectives. Virtual infrastructure includes the ability to create and manage pools of resources, as well as the ability to dynamically relocate virtual machines from one physical machine to another without downtime.
Virtual Networksinvolves hypervisor-layer support for virtual switches and virtual network interfaces. A virtual network makes it possible for multiple VMs to operate on a single physical server and directly communicate with each other. In addition, virtual LANs (VLANs) are typically supported, enabling the formation of broadcast segments within a virtual network or even across a combination of virtual and physical systems.
Virtual Appliancesare similar to “soft appliances.” A soft appliance is an application packaged along with its operating system and any other components that it needs to function. Upon booting from the appliance CD, the application self-installs on to the hard drive and effectively converts a physical server into a dedicated system for the given application (e.g., a firewall). A virtual appliance is similar to a soft appliance but with a few key differences. A virtual appliance runs as a virtual machine image so it requires the presence of a hypervisor and is not directly installed on the hard drive. Also, it is much more mobile because it is an ordinary file and can be copied or migrated to another physical host.
BUSINESS BENEFITS FOR
VIRTUALIZATION
Virtualization solutions have tremendous benefits for businesses. They can help control costs, reduce energy consumption, improve system availability, and enable organizations to respond to new business opportunities more quickly. They also help to avoid failure and infection scenarios and simplify ongoing system administration. Systems can now be deployed and restored almost instantly, and they can be migrated to other parts of the network with only a few mouse clicks to minimize downtime due to maintenance. Organizations have been therefore taking the initiative to launch various virtualization projects:
• Consolidate and optimize server infrastructure by reducing the number of dedicated, low-utilization systems
• Simplify test and development (e.g., for patches, applications, operating systems) by enabling rapid provisioning and reset of test systems and eliminating the need for dedicated test hardware • Improve infrastructure agility and business
continuity by rapidly provisioning new systems and dynamically repurposing existing ones
SECURITY CONSIDERATIONS
With all of these benefits, however, there may also be new security risks. Organizations must take care not to have the benefits of virtualization eroded because they fail to recognize and respond to these risks.
For example, the presence of a hypervisor creates the possibility of new vulnerabilities. Researchers have already proven that it is possible to perform “VM escape,” or access the physical host operating system from a VM. For example, Ed Skoudis and Tom Liston of Intelguardians, a security consulting company, demonstrated at a 2007 SANS conference the ability to exploit a hypervisor vulnerability from a VM and execute arbitrary code on the host operating system. Other research has shown that it is possible to crash a hypervisor from a VM by sending random data sequences to a VM’s virtual hardware such as the network card, video driver, or floppy disk
controller.
“Hyperjacking” is the practice of using an exploit from a VM to gain control of the hypervisor. Hyperjacking would also enable a malicious user to compromise all the other VMs on that host because the hypervisor has privileged access to those VMs. The compromised hypervisor could then function as a rootkit in disguising its
presence from security tools running either in the VMs or externally. It could also modify any VM traffic sent to or received from other hosts on the network. This has significant implications from a data integrity standpoint.
Even if a hypervisor is not compromised, a malicious user who gains access to a single VM could potentially launch attacks against other VMs on the same physical host without detection. Traditional security tools such as firewalls and intrusion detection/prevention systems typically do not have visibility into traffic between VMs on the same host. Even if the user has legitimate access to one VM, there is no visibility into any traffic sent to other VMs on the same host.
Other security risks are caused more directly by poor management practices than by
vulnerabilities. The phenomenon known as “VM sprawl” is the propagation of VMs without adequate coordination or oversight. VM sprawl originates from multiple causes:
• System administrators deploy new VMs without sufficient planning. Little attention is paid to such lifecycle elements as support, patching,
configuration, and end of life because of the ease and speed in provisioning the VMs. Sprawl is intensified further in decentralized
environments where there is lack of coordination in VM deployment among IT groups.
• Administrators and users copy VMs to new hosts throughout the network because the VMs exist as file images and can be easily transferred via portable USB drives or network transfer. • Users create or copy VMs to their laptops or
desktops for development and testing purposes without coordination with the IT group. These VMs often do not meet configuration standards or security requirements.
• Snapshots enable a VM to be rolled back to a previous state, which means that patches can now be undone.
• VMs that are powered off or suspended are likely to be ignored and not receive updated patches and configuration changes.
The result of VM sprawl is that VMs are distributed across multiple physical hosts, in various states of patching and configuration. No single group tracks where a VM is located, what its patching and configuration status is, or what its purpose is.
Security risks become more tangible because a VM that is not properly tracked and managed may not have updated patches or proper configuration control, leading to vulnerabilities that can be exploited. Organizations usually employ patch management or configuration management tools to mitigate these types of security risks. It is difficult to use these tools effectively, however, when the locations, patch states, and
configurations of systems are constantly changing. Also, the number of systems to manage increases by an order of magnitude because of
virtualization’s ability to quickly provision new hosts.
BEST PRACTICES FOR SECURITY
It is possible to mitigate against this new set of risks by adopting a set of best practices:
1. Use standard security practices where it makes sense. For example, practice defense-in-depth strategies to layer multiple security technologies such as firewalls and intrusion detection/prevention systems. Also, apply traditional host-based security mechanisms such as antivirus and antispyware agents on virtual hosts as if they were physical hosts.
2. In a similar fashion, practice the same configuration controls on both physical and virtual machines alike, and regularly audit VMs for compliance.
3. Monitor traffic to and from VMs. This topic will be explored in a subsequent section of this paper. 4. Protect the hypervisor, if possible. This is most effectively done with hypervisor vendor or third-party products that can protect against stack and heap overflows and other vulnerabilities.
Mechanisms that can help verify code integrity, such as the Trusted Platform Module (TPM) standard, are also useful.
5. Consider using an embedded hypervisor that does not include a general-purpose operating system to minimize the possibility of hypervisor vulnerabilities.
6. Implement segmentation when determining how to deploy VMs on physical hosts. Ensure that VMs on the same host are at equivalent trust levels so if one host is compromised, gaining control on the other VMs would not result in a significant security breach. Do not implement a VM that crosses trust zones, such as a virtualized firewall.
7. Guard against VM sprawl by maintaining an inventory of VMs and the physical host they reside on. All migrations should be documented and potentially subject to an approval process. Avoid overly complex environments by keeping operating systems and applications consistent for VMs on the same host. Retire VMs when they are no longer being accessed.
8. Develop a system to uniquely identify VMs by criteria other than hostname, IP address, or current host placement. VMs can be moved around the network far too easily for IP address and host placement to be useful identifiers, and the hostname is not reliable unless a naming scheme for VMs is strictly enforced. MAC address may be reliable (unless it is deliberately altered) because vendors such as VMware may use distinctive MAC addresses for VMs. This identification system should also be used to identify rogue VMs that are created by users on desktops or laptops.
9. Apply patching and content update processes to both operational and offline VMs. Snapshots should contain the latest set of patches and the process of restoring a snapshot should be documented and potentially subject to approval. Some patch vendors may provide integrations with virtualization vendors to patch offline VMs automatically.
10. Manage VMs as both files and systems
simultaneously. Prevent unauthorized access to or tampering with offline VMs, because walking away with an entire disk volume can now be as easy as copying a single file to a high-capacity USB drive.
11. When creating VMs and snapshots,
cryptographically sign the VM file images so when they are distributed and deployed, the user can verify their integrity.
MONITORING VIRTUAL MACHINE
TRAFFIC
Best practices in intrusion detection and
prevention recommend that sensors be deployed in various monitoring zones such as inside the firewall in the DMZ, between an enterprise’s wireless and wired segments, between partner networks, and in front of highly valuable assets. There are no concrete rules of sensor placement but in general, sensors should be placed at the various ingress and egress points on a network. Malicious traffic can only be detected if it passes through a sensor, and more sensors should provide better visibility into network traffic than fewer.
One of the potential security risks created by virtualization is losing visibility into traffic between VMs on the same host. Even if there are only a handful of VMs deployed on a host, a malicious user who compromises one VM can launch attacks against the other VMs without the attack traffic being detected. Even if a user has
legitimate access to one VM, this user is free to launch attacks, illegitimately access data, or commit other policy violations against the other VMs without being detected.
A user with access to one VM can reach even more systems over time as hosts become increasingly capable of hosting a large number of VMs. This is due to a number of factors: greater hypervisor efficiency in resource allocation, more direct access between VMs and hardware because of hardware virtualization support, and more powerful CPUs and larger amounts of memory per host.
There are three general approaches that enterprises can take when monitoring traffic to and from virtual machines:
1. Deploy VM-based sensors
2. Deploy sensors on hosts used for VMs 3. Deploy existing physical sensors
Deploy VM-based sensors. The most compelling reason to deploy sensors as virtual machines on hosts is to gain further visibility into VM traffic. Traffic can be examined to both search for
possible exploits as well as conduct flow analysis and evaluate if a user on one VM is accessing a service on another VM that is not permitted. A VM sensor can either be deployed passively so it can monitor traffic between VMs and other physical hosts, or inline so it can block traffic. Figure 2 shows the difference between a VM sensor deployed to monitor traffic and one deployed to block traffic.
Deployment of a VM sensor requires the hypervisor to support virtual networking
capabilities such as switching, promiscuous mode, and bridging. The hypervisor’s features may constrain deployment options. For example, it may be possible to only monitor traffic between VMs on the same host and not block it.
Another advantage could be greater granularity of sensors. If an organization follows the
recommended practice of keeping all VMs on a host at the same trust level, then some VM sensors could be considered more critical than others because of the hosts they are running on. This permits a prioritization of alerts generated by sensors.
Despite these advantages, however, there are a number of disadvantages to using VM sensors:
• SSeeccuurriittyy.. If a malicious user gains access to the hypervisor from a VM, all other VMs on that host including the sensor are now vulnerable to compromise. The malicious user could either disable the sensor or configure the sensor to ignore any attack traffic sent by that user. • MMaannaaggeemmeenntt.. The number of sensors to manage
could increase by an order of magnitude as sensors are placed on physical hosts. Each sensor also generates its own set of alerts and the overall count of false positives could increase as well.
• PPeerrffoorrmmaannccee.. The sensor VM consumes resources such as CPU and memory that could be used by other VMs, so performance for these other VMs could be adversely impacted. • TTuunniinngg.. Ideally, the sensor VM will be tuned
appropriately to the other VMs on the host. It will support rules and signatures appropriate to the operating systems and applications running on these other VMs. If VMs are migrated between physical hosts without updating the sensor VM intrusion policies, then the sensor will not run optimally and could cause further performance issues. The only exception to this is if the sensor can automatically determine the operating systems and applications running on the other VMs.
• CCoonnffiigguurraattiioonn ccoommpplleexxiittyy. Deploying a sensor VM requires additional network configuration changes so the sensor can monitor or block traffic from other VMs. These changes may include setting up a virtual switch or switches and enabling promiscuous mode. These changes must be tracked and possibly monitored for troubleshooting purposes. All of this adds to overall complexity.
Deploy sensors on hosts used for VMs. An alternative to running an intrusion sensor as a virtual machine is to run the sensor directly on the host. This approach has the same
advantages as running the sensor as a VM, especially because the sensor can monitor or block all VM traffic. The sensor is also simpler to deploy and maintain in that it does not require the additional network configuration changes required for a sensor VM. Figure 3 illustrates how the sensor can monitor all VM traffic without running as a VM itself.
On the other hand, this approach has many of the disadvantages of the VM approach including security, management, performance, and tuning. It also requires a hypervisor implementation that supports a host operating system on which to install the sensor. This includes all Type 2
deployments, as well as Type 1 deployments with a service console, such as VMware ESX 3.x. Virtualization vendors such as VMware and Citrix (Xen) have announced that they are moving to more of a true Type 1 virtualization model. Their embedded hypervisor products run close to the physical hardware without a full intermediary operating system. As this model becomes more prevalent, a sensor formerly installed on the host operating system will now run as a VM and leverage a hypervisor API to access VM traffic. Such an API may or may not exist today but it becomes an important component of the monitoring solution.
Deploy existing physical sensors. As one can see with the other approaches, there are clearly pros and cons to deploying sensors either as VMs or on a host supporting VMs. All of this does
not automatically imply that existing physical sensors are now obsolete. If virtualization is used to increase the number of hosts per subnet but does not change how traffic enters or exits the network, then the organization should be able to detect any intrusion with its existing sensor network.
For example, an enterprise may currently deploy sensors between zones such as the wireless segment, VPN concentrators, DMZ, internal corporate network, and data center. It uses
virtualization to increase the number of systems in the data center, but all traffic leaving and entering the data center is already being monitored by sensors. Figure 4 illustrates this concept. In this scenario, malicious traffic should be detected by the existing sensors as it enters the data center network segment. There may not be any additional benefit to deploying a virtual sensor within a host in the data center.
Relying on existing physical sensors has some significant advantages. Existing investments in security infrastructure can be leveraged. Also, clear boundaries for system ownership can be maintained. In other words, a physical sensor is clearly owned by the security group, while it is not as clear who owns a sensor VM that is running in a host managed by the server group.
The disadvantages of physical sensors have already been mentioned in passing, but they focus on the inability to monitor traffic between VMs. Any attack traffic sent between VMs cannot be detected. Even if physical sensors are monitoring
all of the ingress and egress points on the network, the sensors cannot detect exploit traffic or policy violations sent by a legitimate user on one VM to the other VMs on the host.
Figure 4. Deploying physical sensor to monitor VM traffic
Figure 3. Deploying sensor on host operating system to monitor VM traffic
The advantages and disadvantages of all three approaches are summarized in Table 1.
CONCLUSION
With a compelling and seemingly assured set of benefits to be realized, it seems obvious that virtualization solutions are poised to take today’s enterprises by storm. As this occurs, however, consideration will need to be given to the impact that virtualization will have on security. Changes will inevitably need to be made to ensure that the resulting hybrid environment of virtual and
physical computing systems remains sufficiently protected.
It is important for organizations to take the following steps as they move to virtualization:
• Understand what virtualization is and how it will offer concrete benefits for your organization. Provide a clear business case of these benefits. • Assess the impact of virtualization on your
organization’s security. Follow the best practices mentioned here, such as continuing to use traditional security practices where applicable, implementing a segmented trust model, and avoiding VM sprawl with careful management. • Investigate where existing security technologies
may be sufficient and where they may need to be supplemented with new virtual technologies. Have a clear understanding of the pros and cons. of various approaches.
For more information about Virtualization, or the Sourcefire 3D System, visit Sourcefire’s web site at www.sourcefire.com or contact Sourcefire today.
About Sourcefire
Sourcefire, Inc., a world leader in intrusion prevention, is transforming the way organizations manage and minimize network security risks with its 3D Approach - Discover, Determine, Defend - to securing real networks in real-time. The company's ground-breaking network defense system unifies intrusion and vulnerability management technologies to provide customers with superior network security. Founded in 2001 by the creator of Snort®,
Sourcefire is headquartered in Columbia, MD and has been consistently recognized for its innovation and industry leadership by customers, media, and industry analysts alike – with more than 18 awards and accolades since January 2005 alone. Recently, the company was positioned in the Leaders Quadrant of Gartner’s “Magic Quadrant for Network Intrusion Prevention System Appliances” report and the Sourcefire 3D System was named “Best Security Solution,” at the 2006 SC Magazine Awards. At work in leading Fortune 1000 and government agencies, the names Sourcefire and founder Martin Roesch have grown synonymous with innovation and intelligence in network security.
Table 1. The advantages and disadvantages of sensor VM configuration approaches
MONITORING APPROACH ADVANTAGES DISADVANTAGES
VM-based sensors • Gain visibility into traffic between VMs • Vulnerable to hypervisor exploit • More sensors to manage • Impacts VM performance • More tuning required • Configuration complexity Sensors on host • Gain visibility into traffic between VMs
• Simpler to configure than VM-based sensors
• Vulnerable to hypervisor exploit • More sensors to manage • Impacts VM performance • More tuning required
• May not support embedded hypervisors Physical sensors • Preserves existing security investments
• Clear boundaries for system ownership
