2012 IEEE Sixth International Conference on Software Security and Reliability
Security Impacts of Virtualization on a Network Testbed Yu-Lun Huang, Borting Chen, Ming-Wei Shih, Chien-Yu Lai Department of Electrical and Computer Engineering National Chiao-Tung University Hsinchu, Taiwan Email:
[email protected], {bortingchen, windheart120, gavin09}@gmail.com Abstract—Modern virtualization technologies provides an optimal use of underused hardware resources by sharing them among virtual machines hosted on the same physical machine. These technologies hence have been broadly adopted in many areas, such as server consolidation, virtualized network testbeds, etc. A large-scale network testbed is considered one of the useful tools for evaluating or verifying advanced networking technologies. To construct a network testbed that matches as much as a real setup, the testbed should meet requirements of isolation, fidelity, repeatability, scalability, containment and extensibility. Among these requirements, scalability can be realized by the modern virtualization technology, whereas vulnerability and security weakness brought along with virtualization can also be harmful to the other requirements of a network testbed, like isolation and fidelity. This paper reviews the modern virtualization technologies, their resource management mechanisms, and the known attacks of these virtualization technologies. Then, we discuss the requirements of existing network testbeds and the security impacts when introducing such modern virtualization technologies into a network testbed.
I. I NTRODUCTION Virtualization technologies have been massively adopted in many areas, such as cloud computing [1], server consolidation [2] and high performance computing [3], for their multitudinous benefits. With such modern technologies, multiple virtual machines can be launched and executed on a single physical machine. Each virtual machine is independent of the other and is able to run its own operating system. Hence, greater scalability and better resource utilization can be achieved with the aids of virtualization technologies. Virtualization can also be applied to a network testbed. Traditionally, a physical device supports a network node in an emulation-based testbed. The functionalities of a network testbed are then restricted by the limitations of the physical device. With the advance of modern virtualization technologies, scalability of a network testbed has been improved dramatically. A physical device, running multiple virtual machines, can be used to represent multiple virtual network nodes in a network testbed. Hence, the testbed is also advanced to support larger and more complex emulated networks at the same time. In the past few years, some prior research has adopted virtualization technologies in their network testbeds; for example, FreeBSD jail in Emulab [4], Linux-VServers in PlanetLab [5] and OpenVZ in ORBIT [6] [7] [8]. In these “virtualized” testbeds, the research teams mainly focus on the performances of their testbeds, and rarely discuss the security issues and vulnerabilities of modern virtualization technologies (such as VM Hyperjacking, 978-0-7695-4742-8/12 $26.00 © 2012 IEEE DOI 10.1109/SERE.2012.17
VM Escape, VM Hopping, VM Monitoring and VM Denial-of-Service (DoS) attacks). However, attacking virtual machines in a ”virtualized” testbed may potentially break the fundamental requirements of a network testbed. In this paper, we review the modern virtualization technologies and the existing network testbeds, and discuss the security issues of a network testbed when applying the modern virtualization technologies. The paper is organized as follows. Section II briefly explains the characteristics of virtualization technologies, and Section III presents the fundamental requirements and challenges to designing a network testbed. In Section IV, we explain the security requirements and known attacks of modern virtualization technologies. We also discuss the security impacts on building up a virtualized network testbed. In the end, we conclude the paper in Section V. II. V IRTUALIZATION T ECHNOLOGIES Advance of the dramatic growth of computing power, resources of computing systems are usually underused. Modern virtualization technologies provide an optimal use of hardware to consolidate resources and reduce costs. The scalability and resource reusability are hence improved. Virtualization allows resource abstraction and environment isolation. However, there is not just one way to virtualize a system. Virtualization technologies can be further classified into two types: container-based virtualization and hypervisor-based virtualization. The following paragraphs depict the existing container-based virtualization technologies [9]. A. Container-based Virtualization With container-based virtualization, a host machine and its virtual machines, running at OS-level, share the same OS kernel. The container-based virtualization isolates the guest OSes, but does not virtualize the underlying hardware. Each virtual environment created by the containerbased virtualization is called a container. Applications running in one container (virtual machine) can be isolated from applications running in other containers. Based on a single patched Linux kernel, OpenVZ [10] allows a physical machine to run multiple virtual machines (containers). Each container is represented by a directory of files that can be isolated using chroot and can be launched as a userspace process running in the host operating system. When applying OpenVZ to create a virtual environment, it is restricted to run the same operating system on both host and guest virtual machines. OpenVZ, as a container-based virtualization 71
implementation, claims a performance advantage since no extra abstraction layer (such as hypervisor) is introduced between the virtual machines and physical resources. According to the official website of OpenVZ, only a 1-3% performance penalty is paid for running such a containerbased virtual machine [11]. FreeBSD jail [12], also an OS-level virtualization implementation, allows users to partition a FreeBSDbased host system into several guest systems (called jails). Each jail has a customized virtual root filesystem. Again, the virtual filesystem can be isolated from other virtual filesystems by using the command chroot. Linux-VServer [13], a jail-like virtualization implementation, provides multiple isolated userspace instances on a single host. Like other container-based virtualization technologies, Linux-VServer also uses a chroot-like tool to descend one system into several “vServer instances. These instances share resources in the host system, including CPU, memory and network bandwidth. Since programs executed on top of a vServer instance share the same system call interfaces with the host operating system, the operating systems of guest virtual machines must be the same as the host machine.
Figure 1.
KVM Hypervisor
hypervisor [15] to provide virtual disks and virtual network adapters for the unprivileged guest virtual machines hosted on the same machine. To support full virtualization which no kernel modification is required for guest OSes, Xen adopts QEMU to emulate the physical hardware. As a result, various OSes can be executed in guest virtual machines.
B. Hypervisor-based Virtualization
C. Resource Management of Hypervisor-based Virtualization
Different from container-based virtualization, hypervisor-based virtualization is able to create and execute multiple types of guest OSes simultaneously. A hypervisor (also called a virtual machine monitor) is designed to control the CPU scheduling and memory partitioning of these guest OSes. An extra abstraction layer between the OS-level software and physical hardware is introduced when running a hypervisor, which means performance may take a slight hit. However, the best part of hypervisor-based solutions is that they allow a user to run a wide range of operating systems (guest OSes) on a variety of host OSes. KVM [14] and Xen [15] [16] [17] [18] are two of the most popular hypervisor-based virtualization technologies at present. KVM is implemented as a Linux kernel module. By adopting QEMU [19], KVM is able to emulate physical hardware such as hard disks, CD drives or network interface cards for guest virtual machines. In KVM, three modes (guest, kernel and user modes) are designed to execute guest codes in userspace, handle I/O and signals, and manage interrupts. A device node, /dev/kvm, is exposed to create guest virtual machines through a set of ioctl() calls. For memory access, the mmap() or malloc() calls can be used by a userspace process to directly access the physical memory. Similar to a normal program, at the time when a guest virtual machine invokes mmap() or malloc(), no physical memory mapping or allocation is performed for the guest virtual machine before the memory area is actually touched. Xen takes a different approach by creating a special privileged guest virtual machine, called Domain-0 (abbreviated as Dom0) [20] [17] [18], to manage the access to the physical hardware. Dom0 helps load the device drivers to access storage devices and network adapters. In addition, Dom0 also helps control and manage the Xen
In container-based virtualization technologies, like OpenVZ and Linux-VServer, a set of controls are used to manage the amount and capabilities of physical resources for different containers. For most hypervisor-based virtualization technologies, hardware of a virtual machine is virtualized and managed by a hypervisor or a virtual machine monitor. Namely, hypervisor-based virtualization may create an abstraction layer (hypervisor or virtual machine monitor) between the OS and hardware, such that the physical hardware becomes a resource pool shared by the guest virtual machines. Such an abstraction layer intends to (1) map virtual resources to physical devices, and (2) multiplex physical resources across guest virtual machines according to the policies specified by the administrator. Since the abstraction layer may slightly hurt the system performance, it is essential to monitor and manage the utilization of shared resources, including CPU, memory, I/O peripherals, etc. Failure to optimize the shared resources may lead to further degradation of virtualization performance. In the following, we list several well-known designs of hypervisors: • KVM Hypervisor KVM, a full virtualization solution for Linux, creates multiple virtual machines running Linux or Windows guest OSes. Each KVM virtual machine has privately virtualized hardware: a network card, hard drive, display card, etc. These resources are controlled and managed by a userspace management process (i.e. QEMU), as illustrated in Fig. 1. QEMU, a generic emulator, can emulate the physical hardware for virtual machines. It runs an operating system for a guest virtual machine on a host machine. In KVM, QEMU can achieve a near native performance by executing the guest programs directly on the host CPU. 72
•
Figure g 2.
Xen Hypervisor yp
•
Figure 3. •
•
•
VMWare vSphere Hypervisor
Xen Hypervisor Xen Hypervisor is a free open source virtual machine monitor that can manage physical resources, including CPU, memory and I/O. The paravirtualization technique adopted in Xen makes certain optimizations in the virtualized OSes to maintain a near native performance. Hence, each Xen virtual machine (VM1 , VM2 , ... VMN ) runs as an idependent operating system instance and is being executed on top of the Xen hypervisor, as illustrated in Fig. 2. Through the Xen hypervisor, a virtual instance can access the physical resources shared with other virtual machines running on the same host. Also, by packing applications in one virtual machine, Xen can isolate the failure in another virtual machine hosted on the same physical hardware. VMWare vSphere Hypervisor Taking the VMWare ESXI hypervisor architecture as a basis, VMWare vSphere hypervisor, shown in Fig. 3, runs directly on the hardware layer and acts as an independent operating system. The vSphere kernel helps isolate guest virtual machines, allocate physical hardware and balance the loads of virtual resources.
is an emulation platform for research in distributed systems and networks. In Emulab, a set of experiment nodes are flexibly connected in a network topology. By configuring different VLANs (virtual local area networks), experiments running on the Emulab testbed can be isolated from each other. DETER [23], built on top of Emulab, provides an infrastructure for conducting repeatable experiments in computer security, especially those involving malicious codes. Since DETER is designed to support security-related experiments [24] [25] [26], containment and security are the basic requirements in developing such a testbed. The design of the DETER testbed is an effective compromise of the goals of experimental fidelity, repeatability, programmability and research functionality. ORBIT [6] [7] [8] is a two-tier wireless testbed designed for 3G and 802.11 networks. The testbed comprises a grid of 802.11 nodes and can dynamically interconnect these nodes into specified topologies. Each ORBIT radio node is a real device (PC) with two Ethernet ports and two 802.11 network interfaces, rather than an emulated device. PlanetLab [5] offers an open platform to serve as a testbed for overlay networks. Researchers are able to conduct experiments under real-world conditions, and at a large scale. A original (unmodified) software package, including a Linux-based OS, bootstrapping mechanism, software updates and management tools, can be executed on all PlanetLab experiment nodes.
Public network testbeds typically use a time-sharing model to guarantee the availability of experiment nodes during the reservation period. The conventional requirements for building a wired or wireless network testbed are to: (1) avoid interference and provide isolation, (2) keep fidelity in emulating a network, (3) guarantee repeatability of experiments, (4) ensure scalability, (5) offer containment; and (6) provide extensibility (if wireless networking technologies are considered). •
•
III. N ETWORK T ESTBEDS Network testbeds give researchers and system developers a variety of testing environments in which to develop, debug and evaluate the newly proposed protocols, systems and products. In this section, we briefly introduce the existing testbeds: Emulab, DETER, ORBIT radio grid testbed and PlanetLab. • Emulab [21] [22], developed by University of Utah,
•
73
Isolation Interference may come from a numerous sources, including attacks across experiments, performance degradation due to other experiments, information disclosure, inter-experiment data pollution, etc. Perexperiment isolation hence becomes one of the critical security problems when designing a network testbed. Fidelity Fidelity, as one of the most important challenges to building up a network testbed, refers to the degree to which a simulation reproduces the behavior of a real world object or a real world condition. A simulated testbed must maintain fidelity to “real” networks. Repeatability A critical objective of constructing a network testbed is to support repeatable experiments. General network testbeds ideally can handle issues of network scale, topology, available bandwidth, traffic type, and a variety of host operating systems. Wireless testbeds must additionally be able to handle radio
•
•
•
interference, fading, and attenuation. Scalability In addition to fidelity, scalability is also a critical challenge to designing a network testbed. Real networks show emergent behavior as the scale increases, so testbeds must also scale up gracefully. Scalability represents the ability of a network testbed to be enlarged to accommodate the growing amount of work. Containment To prevent interference from external machines, secure containment is needed to prevent the transmission of viruses or other attacks from a testbed onto an operational network. Although, existing IT security can help prevent a network testbed from external attacks by installing firewalls and VPN gateways, security for a testbed is more than just blocking an external hacker. It is also critical to consider the internal pollution from out-of-control experiments or contagious programs. Extensibility Extensibility should be further considered when designing a wireless testbed. A wireless testbed must support different protocols and emulate their associated hardware interfaces to provide a heterogeneous network experiment environment. However, supporting heterogeneous network emulation require rapidly changing the network interfaces, which increases the cost of deployment.
Among the above requirements, isolation, fidelity and scalability become more challenging when applying modern virtualization technologies to virtualize the existing network testbeds. Considering the performance regression introduced by a hypervisor, most existing network testbeds adopt container-based virtualization technologies to scale up their testbeds: •
•
•
The earlier version of ORBIT supports only a single experimenter, therefore, virtualization is essential for improving the scalability of the testbed. OpenVZ is considered for virtualizing the ORBIT wireless testbed. Adopting OpenVZ helps ORBIT boost the user mode Linux in terms of system overhead, isolation and fidelity. Emulab takes FreeBSD jail for realizing the virtualization on top of the existing testbed. Considering the requirements of the Emulab testbed, including the resource isolation and scalability on low-end experiment nodes, a lightweight virtualization technology (FreeBSD jail) should be selected. Since the primary FreeBSD jail only supports a single IP assignment to a jail, the Emulab research team empowered FreeBSD jail to assigning a set of IP addresses to a jail and enabling the network emulation accordingly. Linux-VServer is adopted by PlanetLab to provide a scalable experimental environment. With LinuxVServer, the global computing resources of PlanetLab can be divided into groups of vServer instances, and experimenters can allocate the instances to conduct their experiments. Each instance represents an experiment node in the experiment. Linux-VServer
brings the improvement of scalability and isolation. IV. S ECURITY A NALYSIS OF V IRTUALIZATION When adopting virtualization technologies to the existing testbeds, the vulnerabilities of the existing virtualization technologies may damage the security of the whole testbed. In this section, we briefly discuss the security requirements of virtualization technologies, their known attacks, and the security impacts on network testbeds when adopting these virtualization technologies. A. Security Requirements The security requirements of virtualization technologies are basically similar to IT systems, including confidentiality, integrity and availability: • Confidentiality is imperiled when confidential information is leaked or disclosed to unauthorized users. If an attacker on one virtual machine gains access to another victim virtual machine, the attacker may be able to access the data, configuration files, and system status (e. g. resource utilization) of the victim virtual machine. The confidentiality of the victim virtual machine is hence compromised. • Integrity is injured if any data, message or asset is executed, modified, suspended, cloned, replayed or deleted by an illicit user. Again, if an attacker gains the access to a victim virtual machine, the attacker is able to modify temporary data and configuration files, and hurt the integrity of the victim virtual machine. • Availability, ensuring the survivability of a network service, is endangered if service/server is spoofed, penetrated or suspended, and cannot provide service as expected. If an attacker compromises a victim virtual machine, the attacker may suspend the service running on the victim virtual machine and decreases the availability of the victim virtual machine. Since virtualization enables multiple virtual machines to share the same physical resources (CPU, memory disk, network bandwidth, etc.), the availability of a virtual machine may also be affected by improper resource management. Instead of breaking into a virtual machine, an attacker may damage the availability of the virtual machine by either attacking its host machine or by making one virtual machine occupy all available physical resources such that no more virtual machines can be created. B. Known Attacks Although security is considered at the design stage, virtualization technologies can still be potentially vulnerable to several common software attacks: • VM Hyperjacking [27] A hyperjacking attack is targeted at exploiting a system from outside to subvert or inject a rogue module into the system, as illustrated in Fig. 4. If the rogue module is injected, an attacker can control the virtual machines running on top of the same host and monitor their network traffic. Moreover, malicious codes may taint other experiments and damage the isolation requirement. 74
Figure 4.
Table I ATTACKS VS . S ECURITY R EQUIREMENTS
Known Attacks
VM VM VM VM VM VM
VM Hyperjacking Attack
VM Escape [28] VM Escapeis an exploiting process that enables a hacker to access the host OS (or the virtual machine manager) from a virtual machine. These attacks leverage the vulnerability or misconfiguration of the host OS and penetrate through the virtualization layer. Since the host machine is root privileged, an attacker escaping from a virtual machine can gain access over the host OS, and attack the other virtual machines or alter their configurations. • VM Hopping [28], [29] VM Hopping is an attack that an attacker on one virtual machine hops to another virtual machine sitting on the same host. The prerequisite of the attack is to obtain the IP addresses of the victim virtual machines so that the attacker can break the isolation control through the internal network bridge. • VM Monitoring [30], [31] Isolation is considered to be the primary characteristic when designing a virtualization technology. However, without proper configurations, a virtual machine may obtain the access permission and monitor the resource utilization of other virtual machines residing on the same host. • VM DoS [31] Generally, a virtualization technology is designed to share physical resources among multiple virtual machines and improve the utilization of physical resources. In this attack, an attacker may launch a Denial of Service (DoS) attack in one virtual machine and try to exhaust all available resources. It can result in a situation that other virtual machines running on the same host starve for resources. • VM Mobility [32] With the existing virtualization technologies, a virtual machine can be saved as an image file such that the virtual machine can be transferred to other host machine easily. The mobility of a virtual machine enables the quick deployment and helps balance the workload of a system. However, such trend of mobility also leads to quick spreading of vulnerable configurations of a virtual machine. An attacker can then exploit the vulnerable configurations to compromise the security of the new host. Table I summarizes the impacts of these attacks on the security requirements of virtualization: •
C. Security Impacts Threats to a virtualized network testbed become complicated, especially when physical machines and virtual machines are mixed in conducting an experiment. Here, we discuss the possible security impacts on network testbeds running with different virtualization technologies.
Affected Security Requirements of Virutalization C, I, A C, I, A C, I, A C A N/A∗
Hyperjacking Escape Hopping Monitoring DoS Mobility
C: Confidentiality; I: Integrity; A: Availability The VM Mobility attack speeds up the spread of erroneous configurations or vulnerabilities.
Figure 5.
VM Escape Attack
Even container itself can be guaranteed secure, the testbeds are still vulnerable to attacks like VM Hyperjacking, VM Escape, VM Hopping, VM Monitoring and VM DoS. An attacker may try to obtain root access of the host OS, inject virus or malware and damage the fundamental requirements of the network testbeds, such as isolation, fidelity, scalability, security, etc. Hypervisorbased virtualization technologies introduce a hypervisor to manage and control the resource allocation, but make the hypervisor a new attacking target. Hence, the network testbeds with hypervisor-based virtualization technologies have no way but enhance themselves to deal with the new challenges of these new VM attacks. VM Hyperjacking attacks can be launched to attack both container-based and hypervisor-based virtualization systems. Such attacks may leverage any vulnerability of a general OS and exploit the host OS to damage the isolation of a network testbed. In a VM Escape attack, more than two experiments may be tainted, if these experiments allocate different virtual machines running on the same host. Fig. 5 shows an example of a VM Escape attack on a testbed running two experiments on the same host machine. In the example, the host machine runs several virtual machines (V M1 , V M2 , · · · V Mn ). The first experiment allocates virtual machines V M1 , V M2 , · · · V Mi , while the second takes V Mi+1 , V Mi+2 , · · · , V Mn . The VM Escape attack is mainly launched to attack a hypervisor-based virtualized system. In addition, a container-based virtualized system may also suffer from such an attack, especially when chroot-like utilities are used to isolate virtual filesystems for virtual machines. VM Hopping attacks are possible in both containerbased and hypervisor-based virtualized systems, especially in a testbed running container-based virtualization technologies. Similar to a VM Escape attack, the home 75
Table II ATTACKS VS . I MPERILLED R EQUIREMENTS OF N ETWORK T ESTBEDS
Known Attacks VM Hyperjacking VM Escape VM Hopping VM Monitoring VM DoS VM Mobility
Imperilled requirements Isolation, Fidelity Isolation, Fidelity Isolation, Fidelity Isolation Fidelity, Scalability N/A∗
*The VM Mobility attack speeds up the spreading of erroneous configurations or vulnerabilities.
directory can be disclosed if an attacker breaks into the privileged chroot-like system calls. With a successful VM Hopping attack, an attacker can monitor the behaviors of other virtual machines, and hurt the confidentiality, integrity and availability of the victim virtual machines. VM Monitoring attacks damage the confidentiality of another virtual machine running on the same host. Ristenpart et al. showed a cross-VM side-channel attack (one of the VM Monitoring attacks) to extract the memory information from a victim virtual machine [30]. An alternative way to launch VM attacks is to manipulate the ARP cache of the virtual switch within a hypervisor (ARP poisoning) and redirect traffic from the victim virtual machine to the attacker. VM DoS attacks damage the scalability and fidelity of a virtualized network testbed. Once malicious virtual machines exhaust all computing resources of the host machine, the availability and performance of virtual machines allocated by an experiment cannot be guaranteed. Hence, the scalability and fidelity are spoiled. As mentioned in the Section IV-B, mobility of a virtual machine (storing in an image file) leads to quick spread of vulnerable configurations of a virtual machine. In such a case, an attacker can exploit the vulnerable configurations and compromises the security of new host machine by launching the VM Mobility attack in virtualized systems. Table II lists the security impacts on a network testbed caused by different virtualization attacks.
the system performance is likely to take a light hit, since an extra layer of abstraction (i.e. hypervisor) is inserted between the operating system and physical hardware. Choosing the best virtualization solution for a network testbed is not an easy job. The decision depends on the hardware specification, management overhead, compliance, and testbed requirements. When adopting those modern virtualization technologies, network testbeds face new threats, such as accessing unauthorized virtual machines, gaining control over a hypervisor, or abusing the shared resources, etc. In this paper, we present the security requirements of virtualization technologies and the known attacks found in a virtualized system. We also analyze the impacts on virtualization and virtualized network testbeds in terms of different attacks. The analysis shows the modern virtualization technologies are still vulnerable to security attacks. When adopting these technologies to network testbeds, an attacker can take advantage of the network bridging functionality to attack the testbed, which can further imperil the isolation, fidelity and scalability of the network testbed. To minimize such risks, correct configurations, proper optimization and conscientious connectivity management must be applied to enhance the security of a network testbed. ACKNOWLEDGMENT This effort was partially supported by Taiwan Information Security Center (TWISC), sponsored by National Science Council under the grants NSC100-2219-E-009-005, NSC-100-2218-E-009-003, and NSC100-2218-E-009-017.
R EFERENCES [1] M. Armbrust, A. Fox, R. Griffith, A. Joseph, R. Katz, A. Konwinski, G. Lee, D. Patterson, A. Rabkin, I. Stoica et al., “A view of cloud computing,” Communications of the ACM, vol. 53, no. 4, pp. 50–58, 2010. [2] P. Apparao, R. Iyer, X. Zhang, D. Newell, and T. Adelmeyer, “Characterization & analysis of a server consolidation benchmark,” in Proceedings of the fourth ACM SIGPLAN/SIGOPS international conference on Virtual execution environments. ACM, 2008, pp. 21–30. [3] W. Huang, J. Liu, B. Abali, and D. Panda, “A case for high performance computing with virtual machines,” in Proceedings of the 20th annual international conference on Supercomputing. ACM, 2006, pp. 125–134.
V. D ISCUSSIONS With container-based virtualization technologies, several virtual machines (jails or containers) can be executed on top of one host machine. In contrast to hypervisorbased virtualization technologies, a container does not run a complete operating system, but rather a partial operating system running with the virtualization layer in the host OS kernel. In a container-based virtualized system, only a single operating system can be installed in containers. In most cases of Linux virtualization solutions, a user is limited to run Linux guests on a Linux host. For hypervisor-based virtualization technologies, a full operating system can be installed in a guest virtual machine running on top of a host operating system. Each guest virtual machines have a complete OS stack, from kernel to libraries and applications. Additional storage overhead and memory cost are required to run these guest OSes entirely isolatedly. In general, hypervisorbased technologies support a variety of guest OSes, but
[4] M. Hibler, R. Ricci, L. Stoller, J. Duerig, S. Guruprasad, T. Stack, K. Webb, and J. Lepreau, “Large-scale virtualization in the emulab network testbed,” in USENIX 2008 Annual Technical Conference on Annual Technical Conference. USENIX Association, 2008, pp. 113–128. [5] B. Chun, D. Culler, T. Roscoe, A. Bavier, L. Peterson, M. Wawrzoniak, and M. Bowman, “Planetlab: an overlay testbed for broad-coverage services,” ACM SIGCOMM Computer Communication Review, vol. 33, no. 3, pp. 3– 12, 2003. [6] D. Raychaudhuri, I. Seskar, M. Ott, S. Ganu, K. Ramachandran, H. Kremo, R. Siracusa, H. Liu, and M. Singh, “Overview of the ORBIT Radio Grid Testbed for Evaluation of Next-Generation Wireless Network Protocols,” in IEEE Wireless Communications and Networking Conference, vol. 3. IEEE, 2005, pp. 1664–1669. 76
[7] G. Bhanage, I. Seskar, Y. Zhang, and D. Raychaudhuri, “Evaluation of openvz based wireless testbed virtualization,” Tech. Rep. WINLAB-TR-331, Rutgers University, Tech. Rep., 2008.
[23] T. Benzel, R. Braden, D. Kim, C. Neumana, A. Joseph, K. Sklower, R. Ostrenga, and S. Schwab, “Experience with DETER: A Testbed for Security Research,” in Proceedings of Tridentcom. IEEE, 2006, pp. 10–10.
[8] G. Bhanage, I. Seskar, Y. Zhang, D. Raychaudhuri, and S. Jain, “Experimental evaluation of openvz from a testbed deployment perspective,” ICST Tridentcom, 2010.
[24] J. Mirkovic, B. Wilson, A. Hussain, S. Fahmy, P. Reiher, R. Thomas, and S. Schwab, “Automating DDoS Experimentation,” in DETER: Proceedings of the DETER Community Workshop on Cyber Security Experimentation and Test 2007. USENIX Association, 2007, pp. 4–4.
[9] S. Soltesz, H. P¨otzl, M. E. Fiuczynski, A. Bavier, and L. Peterson, “Container-based operating system virtualization: a scalable, high-performance alternative to hypervisors,” SIGOPS Oper. Syst. Rev., vol. 41, no. 3, pp. 275–287, Mar. 2007. [Online]. Available: http://doi.acm.org/10.1145/1272998.1273025 [10] K. Kolyshkin, “Virtualization in linux,” White paper, OpenVZ, 2006. [11] “Openvz linux containers.” [Online]. Available: http: //wiki.openvz.org/Main Page [12] P. Kamp and R. Watson, “Jails: Confining the omnipotent root,” in Proceedings of the 2nd International SANE Conference, vol. 43, 2000, p. 116. [13] B. des Ligneris, “Virtualization of linux based computers: the linux-vserver project,” in High Performance Computing Systems and Applications, 2005. HPCS 2005. 19th International Symposium on. IEEE, 2005, pp. 340– 346. [14] A. Kivity, U. Lublin, and A. Liguori, “kvm : the linux virtual machine monitor,” Proceedings of the 2007 Linux Symposium, vol. 1, no. 1465-6914 (Electronic) LA ENG PT - JOURNAL ARTICLE, p. 225V230, 2007. [Online]. Available: http://www.kernel.org/doc/ols/2007/ ols2007v1-pages-225-230.pdf [15] P. Barham, B. Dragovic, K. Fraser, S. Hand, T. Harris, A. Ho, R. Neugebauer, I. Pratt, and A. Warfield, “Xen and the art of virtualization,” SIGOPS Oper. Syst. Rev., vol. 37, no. 5, pp. 164–177, Oct. 2003. [Online]. Available: http://doi.acm.org/10.1145/1165389.945462 [16] B. Clark, T. Deshane, E. Dow, S. Evanchik, M. Finlayson, J. Herne, and J. Matthews, “Xen and the art of repeated research,” in Proceedings of the annual conference on USENIX Annual Technical Conference. USENIX Association, 2004, pp. 47–47.
[25] J. Mirkovic, P. Reiher, S. Fahmy, R. Thomas, A. Hussain, S. Schwab, and C. Ko, “Measuring Denial of Service,” in Proceedings of the 2nd ACM Workshop on Quality of Protection. ACM, 2006, pp. 53–58. [26] J. Mirkovic, E. Arikan, S. Wei, S. Fahmy, R. Thomas, and P. Reiher, “Benchmarks for DDoS Defense Evaluation,” in Proceedings of MILCOM. IEEE, 2006, pp. 1–10. [27] A. A. Semnanian, J. Pham, B. Englert, and X. Wu, “Virtualization technology and its impact on computer hardware architecture,” in Information Technology: New Generations (ITNG), 2011 Eighth International Conference on, 2011, pp. 719–724. [28] K. Owens, “Securing virtual compute infrastructure in the cloud,” white paper, Savvis Communications Corporation, Tech. Rep., 2009. [29] A. Jasti, P. Shah, R. Nagaraj, and R. Pendse, “Security in multi-tenancy cloud,” in Security Technology (ICCST), 2010 IEEE International Carnahan Conference on, 2010, pp. 35–41. [30] T. Ristenpart, E. Tromer, H. Shacham, and S. Savage, “Hey, you, get off of my cloud: exploring information leakage in third-party compute clouds,” in Proceedings of the 16th ACM conference on Computer and communications security, 2009, pp. 199–212. [31] J. Kirch, “Virtual machine security guidelines,” The Center for Internet Security, Tech. Rep., 2007. [32] H.-Y. Tsai, M. Siebenhaar, A. Miede, Y. Huang, and R. Steinmetz, “Threat as a service?: Virtualization’s impact on cloud security,” IT Professional, vol. 14, no. 1, pp. 32– 37, 2012.
[17] I. Pratt, K. Fraser, S. Hand, C. Limpach, A. Warfield, D. Magenheimer, J. Nakajima, and A. Mallick, “Xen 3.0 and the art of virtualization,” in Linux Symposium. Citeseer, 2005, p. 65. [18] I. Pratt, “Xen roadmap,” urlhttp://downloads.xen.org/Wiki/XenRoadmap/, 7 2006. [19] “Qemu open source processor emulator.” [Online]. Available: www.qemu.org/ [20] T. Abels, P. Dhawan, and B. Chandrasekaran, “An overview of xen virtualization,” Dell Inc., Tech. Rep., 8 2005. [21] G. Judd and P. Steenkiste, “Repeatable and Realistic Wireless Experimentation Through Physical Emulation,” SIGCOMM Comput. Commun. Rev., vol. 34, no. 1, pp. 63–68, 2004. [22] ——, “A Software Architecture for Physical Layer Wireless Network Emulation,” in WiNTECH ’06: Proceedings of the 1st International Workshop on Wireless Network Testbeds, Experimental Evaluation & Characterization. New York, NY, USA: ACM, 2006, pp. 2–9.
77
