Hyper visor -based VM Isolation in Cloud Yen-Chung Chen, Chien-Chuan Pan, Tien-Hao Tsai, Jhen-Li Wang, Chi-Sheng You and Kuo-Sen Chou, Information & Communication Security Lab, Chunghwa Telecom Laboratories, 32601 Taoyuan, R.O.C. {yzchen, fone, p1t1r, jeniw, kevin_yu, cksp}@cht.com.tw
Abstract. Cloud computing undoubtedly brings the computer world into a new generation while users benefits from the revolution without suffering difficulties when getting used to it. However, the new concept does not eliminate the inherent security threats, and even worse, new threats come into existence. For example, from the Infrastructure as a Service’s (IaaS) point of view, virtualization technology plays a pivotal role and threats behind the advantages of the utilization and flexibility of hardware devices should be considered in advance. Inter-VM attack, which targets at the VMs running on the same physical machine and VM image protection are two of the most critical issues people concern in the resource virtualized and shared environment. To overcome the possible inter-VM attack, in this paper we propose an IP/ARP spoofing detection and a Chinese Wall isolation policy mechanism to detect the potential malicious events or forbid deploying the competitors’ VMs on the same physical machines. Moreover, we also propose a real-time encryption/decryption mechanism for the running VM so that users would not worry about the VM images are misused. For the efficiency, those are basically working on the hypervisor level in the virtualization platform. Keywords: Cloud, Hypervisor, Virtualization, VM Isolation, Chinese Wall isolation policy, IP Spoofing, ARP Spoofing
1
Introduction
Follow the mainstream of mainframe and client-server infrastructures from 1980s, cloud computing [1] nowadays changes the way how computing resources are exposed to users: functions of applications and services are toward available on the Internet. The keys motivation behind cloud computing are the accessibility for all users with varieties of devices and on the other hand, service provider could fully utilize the hardware equipment without wasting idle resources. With the trustworthy accounting model, users only have to pay the bill for the resources they did put to use. According to the cloud security guidance [2] provided by CSA (Cloud Security Alliance), the cloud computing industry can be divided into three categories of models: IaaS, PaaS and SaaS:
• IaaS, Infrastructure as a Service. Provider, like Amazon, GoGrid and Rackspace, etc., mainly supplies the VMs to customers, and the concept is similar to the former hosting service. Customers only need to decide the required resources, for example, type of operating system, number of CPUs, size of memory and storage, and the use of firewall, etc. The customized VM then would be available in time. • PaaS, Platform as a Service. Developers could employ the development environment provided by the platform provider to develop and build up the cloud services. Google App Engine, IBM Pangoo and Windows Azure are belonging to this category. • SaaS, Software as a Service. Service provider directly utilizes the advantages of cloud to provider services with high scalability to satisfy most of the users. Many of services for this type are available nowadays, such as Google Gmail and Salesforce CRM, etc.
2
Security Threats in Cloud Environment
However, running things on the cloud does have risks. First, all the customers of a cloud service share the same underlying infrastructure, so a careful compartmentation of the infrastructure has to be engineered to ensure the absolute isolation and security for each individual customer’s applications. Second, whether the cloud service provider could be trusted entirely or not is critical, and this can turn into a serious issue when applications involve private information that is related to customers and application users. Table 1. Security issues for IaaS. Security Domain
Governance and Compliance
Network Security Host Security
Data Protection
Access Control Operation Security
Issues ISO 9001 ISO 20000 ISO 27001 CSA Certification DoS/DDoS protection IDS/IDP and Firewall Hypervisor-based security protection VM security policy migration Vulnerability scan and penetration test Data Encryption/Decryption VM image Protection Key management Data integrity assurance Multi-factor authentication Single sign on Security tunnel Security Operation Center for cloud
From the perspective of IaaS, there are numbers of security domains involved to strength the fundamental security and the related issues are shown in Table 1. Each issue takes remarkable effect to enhance the environment. We all know that virtualization plays a very important role in IaaS, and in fact, many of issues mentioned in Table 1 were already covered in former infrastructures. Those new ones are mainly introduced from VM running on the same physical machine and sharing hardware resources, like inter-VM attack, or the way to store the VM images. Therefore, how to absolutely isolate the VMs is a critical issue to guarantee the security to customers’ VM. To achieve the goal of isolation, three kinds of mechanisms we propose here: ─ IP/ARP Spoofing Detection: In the case of inter-VM, attackers may intentionally set their IP to other unauthenticated address or poison the ARP table to initiate the derivative attacks, like Man-in-the-middle attack, Session Hijacking, etc. We propose a hypervisor-based detection mechanism to detect and deny those spoofing events ─ Physical isolation: To completely eliminate the possible inter-VM attacks from competitors, we propose a centralized control mechanism based on the Chinese Wall security policy to forbid deploying and running the competitors’ VMs on the same physical machines so that absolute isolation could be achieved. ─ VM Image Protection: To support VM migration and backup, the VMs could be moved or copied to other storage easily. However, if the attackers could steal the VM images, the information that resides in VM would be in extremely high risk. To protect the VM images, here we propose a real-time VM encryption/decryption mechanism whether it is in online or offline status.
3
Related Work
In traditional ARP spoofing protection, in addition to use security appliance to build up the ARP information from all hosts to protect the LAN, the host could also employ static ARP records which bind the relation between IP and MAC, so it is unnecessary to obtain the ARP information from the broadcast and the ARP spoofing could not work. As there are a large number of virtual machines running in the virtual platform, we could implements the anti-ARP mechanism in the hypervisor instead of configuring every VM or using additional appliances. Therefore, the malicious packets are detected and blocked outside the VMs, and the attacks which derived from ARP spoofing, like Sniffer and Man-in-the middle attack, etc. could be also prevented. To achieve physical isolation, IBM's sHype [3] provides an Access Control Module (ACM) on Xen, and implements the Type Enforcement policy to control the sharing of resources among VMs on the platform. It describes the CW policy to ensure VMs with conflict of interests not to run concurrently on the same platform. For the CW policy, it checks the conflict relations when a VM is loaded on a platform. If any conflict is found, it refuses to load the VM on the platform. Since sHype does not check the conflict of interest relations among VMs in advance, it may
try to deploy the VM on different systems several times until one that does not have the conflict is found. From data encryption’s point of view, VM image protection mechanism is not supported by cloud service provider directly, users have to manually install third party applications to protect personal data if necessary. Most of the cloud service providers would encrypt the whole physical disk instead of encrypting individual VM images. However, the threat still exists if there is malicious insider. To supply individual VM image protection, implementing the encryption mechanism in hypervisor layer could protect the VM images on matter the status is on-line or off-line.
4
Hypervisor-based VM Isolation and Protection
For those isolation mechanisms mentioned in last section are practically available in the virtual platforms: Xen [4] and KVM (Kernel-based Virtual Machine) [5]. We build the internal-built experimental cloud for both virtual platforms, and each physical machine contains 4*Intel X5660(6-cores) and 96GB RAM. In each machine, 10 VMs is allowed to run without significant performance downgrade, and to consider the effectiveness and performance, the mechanisms are implemented in hypervisor. 4.1
IP/ARP Spoofing Detection
Each guest OS in VM has an APR cache table which holds the IP and MAC mapping address for other VMs in the same network and the table would be renewed whenever the guest OS receives the ARP reply packets. However, attacker makes use of this vulnerability to send amount of fake ARP packets to initiate ARP spoofing attack [6].
Fig. 1. ARP Spoofing Attack
The fake MAC addresses are updated to VMs as Fig. 1 shows. The original MAC address for VM a is updated to MAC b which belongs to VM b , so the packets cannot deliver to VM a correctly. As the result, the connection between VM a and VM c is broken or even worse, the packets would be delivered to attacker and they could initiate Man-in-the-middle attack [7], Session hijacking, etc., to forge web pages or redirect the browser to malicious sites to get more valuable information. On the other
hand, VM users may arbitrarily change the IP address. This would not only lead to IP conflict but make attack untraceable.
Fig. 2. IP/ARP Spoofing Detection Architecture
Fig. 2 shows the relationship between the detection mechanism and virtual platform. The information, like the current IP and MAC addresses for each VM could be obtained from virtual platform API [8], so that we can build up the rules from data table and manage all VMs in this cloud from the hypervisor. The mechanism keeps the IP and MAC correct all the time and need not employ extra devices. When a VM is enable/disable, the protection rules would be add/delete automatically without further manual works. Therefore, while the abnormal event is detected, we would block all packets from attacker’s VM and the rest VMs can work properly. 4.2
Chinese Wall Central Management System
Physical isolation on the other hand, surely lowers the resource sharing risk work. Our work, Chinese Wall Central Management System (CWCMS) [9], is to eliminate the possible inter-VM attacks from competitors by separating every conflicting industry which may contend for business. With centralized management, we have customers choose their business competitors while renting VMs in our cloud platform and collect these conflicting relations as a Chinese Wall policy [10] and then updating the Chinese Wall policy to each cloud platform. CWCMS is implemented on both Xen and KVM, and it consists of Chinese Wall Central Server and Chinese Wall Control Agents. It can handle the deployments all the VMs on virtualization platforms and assure the CW policy is followed. Instead of deploying VM arbitrarily on any available physical machine and then, testing whether a conflict of interest is found, CWCMS analyzes the conflict of interest relations among VMs and picks a suitable physical machine for the VM.
Fig. 3. The undirected graph shows conflict relations: A<->B, B<->C and C<->A.
When conflicting policies are allocated for VMs, it is hard to analyze the complex relations. VM deployments and migrations are restricted by the conflicting relations while the Chinese Wall security model is enable. If those relations are not placed reasonably or the deployment strategy is not well-planned, cloud provider must allocate more physical machines to deploy VMs. To satisfy the efficiency and flexibility, we adopt graph theory to analyze the conflict of interest relations among the VMs. We would regard each VM as a node (vertex), and add one edge to connect two nodes if one of the corresponding VMs belongs to the conflict of interest set of the other VM. So the conflict of interest relations among VMs can be transformed into one or more undirected graph(s). Assume VM A, B and C have the conflict relations: A<->B, B<->C, C<->A, the graph would be shown as Fig. 3. Subsequently, the graph coloring algorithm can be applied to analyze the conflict of interest relations among VMs and a solution to well distribute those VMs to appropriate physical machines could be found. The centralized control mechanism we propose makes the CW policy management much easier, and with the hypervisor-based agent that is installed in KVM, the mechanism could work more effectively. Furthermore, improper conflict of interest sets may cause mutually exclusion of VMs, and all we can do is to add more physical machines to avoid the conflicts. Accordingly, we could adopt graph theory to against the mutually exclusive relation and then, apply the graph coloring algorithm to achieve better resource utilization. 4.3
VM Image Protection
In order to protect the data in VM by encryption/decryption, there are three kinds of mechanisms. Table 2. Levels of encryption/decryption.
Guest OS level User involvement Performance Provider Cost
Yes Poor Best
Hypervisor level No Good Good
Hardware level No Best Poor
Users usually have to install an agent for encryption/decryption in Guest OS level while the others are responded by the cloud provider. The mechanism we propose
here is in virtual platform, and Table 2 shows that it could balance the cost and performance. As Xen and KVM are basically Linux-based operation system, the data encryption/decryption module supported in both is: ─ Linux disk encryption: Utilize Linux OS disk encryption module to encrypt the whole loaded disk, so all the VM images inside can be protected. ─ Linux virtual disk: Utilize Linux OS virtual disk module to encrypt and load VM image, so each VM image can be protected individually. ─ Block driver encryption: Utilize encryption module embedded block driver in the hypervisor to encrypt and load VM image, so each individual VM image can be protected. Table 3. Data encryption/decryption suppoted modules.
Linux disk Linux Block driver encryption virtual disk encryption Implementation Complexity Key Mgmt. Flexibility Access Performance Image Type Support
Best
Best
Good
Poor
Good
Best
Best
Good
Best
Best
Good
Poor
In Table 3, Linux disk encryption though has excellent results in most aspects; its key management flexibility which is critical in our point of view is not good enough. On the other hand, image type support has less impact for our usage
Fig. 4. VM Image Protection Architecture
From the previous description, we decide to follow the block driver encryption and the implementation is our way is shown in Fig. 4. In addition to the encryption module in block driver, we also arrange an individual key management server and communicate by KMIP to make user key management secure.
5
Conclusion
Resource sharing in cloud computing brings out the new challenges. In many cases, security vendors are heading their security solutions, like intrusion detection system, antivirus, etc., to support visualization from hypervisor to earn performance. In this paper, we propose isolation mechanisms for VM from three different ways: network level, physical resource sharing and VM image, to against kinds of attacks.
References 1.
P. Mell, T. Grance: Effectively and Securely Using the Cloud Computing Paradigm NIST (2009) 2. Cloud Security Alliance: Security Guidance for Critical Areas of Focus in Cloud Computing (2009), https://cloudsecurityalliance.org/csaguide.pdf 3. R. Sailer, T. Jaeger, E. Valdez, R. C’aceres, R. Perez, S. Berger, J. Griffin, and L. van Doorn: Building a MAC-based security architecture for the Xen opensource hypervisor, In Proceedings of the Annual Computer Security Applications Conference (2005) 4. P. Barham, B. Dragovic, K. Fraser, S. Hand, T. Harris, A. Ho, R. Neugebauer, I. Pratt, A. Warfield: Xen and the art of virtualization, In Proceedings of the nineteenth ACM symposium on Operating systems principles, Bolton Landing, NY, USA ( 2003) 5. A. Kivity, Y. Kamay, D. Laor, U. Lublin, and A. Liguori, “kvm: the Linux virtual machine monitor,” In OLS '07: The 2007 Ottawa Linux Symposium, pp. 225--230 (2007) 6. Gibson Research Corporation: ARP Cache Poisoning, http://www.grc.com/nat/arp.htm 7. R. Wagner: Address Resolution Protocol Spoofing and Man-in-the-Middle Attacks, SANS Institute (2001) 8. XenNetworking, http://wiki.xensource.com/xenwiki/XenNetworking 9. T.H. Tsai, Y.C. Chen, H.C. Huang, P.M. Huang, K.S. Chou: A Practical Chinese Wall Security Model in Cloud Computing. APNOMS (2011) 10. Brewer, D.F.C., Nash, M.J.: The Chinese Wall security policy, In Proceedings of the Symposium on Security and Privacy, pp. 21--228 (1989)
