Faculty of Science, Macquarie University, Sydney, Australia. {udaya, vijay, naveen}@ics.mq.edu.au. Abstractâ Today, cloud computing is one of the increasingly.
2011 IEEE Ninth Ninth IEEE International Conference on Dependable, Autonomic and Secure Computing
Intrusion Detection Techniques for Infrastructure as a Service Cloud Udaya Tupakula
Vijay Varadharajan
Naveen Akku
Information & Networked Systems Security Research, Department of Computing Faculty of Science, Macquarie University, Sydney, Australia {udaya, vijay, naveen}@ics.mq.edu.au
system itself, they are vulnerable to attacks by the attacker. The network based tools detect the attacks by monitoring the incoming and outgoing traffic from the monitored machines. They have poor visibility into the state of monitored machines but offer high attack resistance. Hence for efficient detection of attacks, it is desirable to have good visibility of the monitored system while at the same time the tool should offer high resistance to the attacks. The limitations of the existing tools can be overcome by implementing the security tools [6, 7] using Virtual Machine Monitors [8]. A VMM [8] is an additional software layer which has complete control on the physical resources and enables to run multiple operating systems on a scalable computer. Since the VMM has complete control on the resources, good visibility into the internal state of the virtual machines and isolated from the virtual machines, they can be used [7] for improving the attack detection/prevention efficiency of the security tools. In this paper, we consider the design choices for comprehensive attack detection and propose a novel architecture based on the virtual machine monitor to efficiently deal with the attacks on the customer virtual machines in the IaaS cloud. We discuss techniques to capture the dynamic updates to the operating systems and applications in virtual machines and thereby helping to reduce the semantic gap. We also develop techniques to identify each virtual machine separately and efficiently deal with the attacks. The paper is organized as follows. Section II presents some of the related work. In Section III, we consider the design choices for comprehensive attack detection and propose techniques for securing customer virtual machines in the IaaS cloud environment. Section IV presents the analysis of our model and Section V concludes.
Abstract— Today, cloud computing is one of the increasingly popular technology where the customer can use the resources of the cloud services providers to perform their tasks and only pay for the resources they use. The customer virtual machines in the cloud are vulnerable to different types of attacks. In this paper we propose techniques for securing customer virtual machines from different types of attacks in the Infrastructure as a Service cloud and describe how this can be achieved in practice. Our model enables to differentiate attack traffic originating from each virtual machine even if multiple virtual machines on a VMM are sharing a single IP address. Keywords – IaaS, Cloud Security, Virtual machine based Security, Intrusion detection
I.
INTRODUCTION
Today, cloud computing [1-4] is one of the increasingly popular technology where the cloud services providers provide computing resources to the customers to host their data or perform their computing tasks. Cloud computing can be categorized [2] into different services such as Software as a Service (SaaS), Platform as a Service (PaaS), and Infrastructure as a Service (IaaS). In this paper we consider techniques for securing customer virtual machine in IaaS cloud environment. Virtualisation is one of the key technologies for the IaaS cloud. Since the customer can be running different operating systems and applications in their virtual machines, it is difficult task for the cloud service provider to secure their customer virtual machines. Furthermore due to extremely large size of the operating systems and inherent weakness in the TCP/IP stack, the attacker can easily exploit their weakness and generate different types of attacks on the customer virtual machines. Also several new (zero day) attacks are appearing on a daily basis and techniques such as polymorphism and metamorphism make it extremely difficult to detect and prevent the attacks. Furthermore, it is shown [5] that it is not a difficult task for the attacker to obtain information regarding the victim machine in the IaaS cloud and perform attack by colocating a malicious virtual machine with the victim virtual machine. Although there are specific tools such as intrusion detection systems, honey pots, antivirus, anti malware there are some limitations for such tools to detect and prevent such attacks. The host based tools have good visibility of internal state of the monitored system and can efficiently detect the attacks. However since the tools are implemented on the monitored 978-0-7695-4612-4/11 $26.00 © 2011 IEEE DOI 10.1109/DASC.2011.128
II.
RELATED WORK
In this section, we present some of the important techniques that are related to our proposed architecture. Dunlap et al [6] proposed ReVirt architecture for secure logging by placing the logging tool inside the VMM. ReVirt claims to log enough information such as real time clock, keyboard, mouse events, user inputs and system calls, which enables the administrator to replay the execution of virtual machine. Since the logs are isolated from the virtual machine, they can be used to replay the logged information and analyse the attacks in case of compromise of the virtual machines.
745 744
Garfinkel [7] proposed a Livewire intrusion detection system which makes use of the VMM to obtain the state of the virtual machine with additional commands for inspection, monitoring and administration. Livewire has two important components: OS interface library and policy engine. VMM manages state strictly at the hardware level. However for detecting intrusions, there should be some mechanism to interpret low machine state from the VMM in terms of the higher level OS semantics. The OS interface library uses the knowledge about the guest OS implementation to interpret the VM’s machine state, which is exported by the VMM and provides the policy engine with an interface for making high level queries about the OS of the monitored host. The OS interface library must be matched with the guest OS. The policy engine interprets system state and events from the VMM interface and OS interface library and decides whether or not the system is compromised. Lares [9] considers techniques for active monitoring by placing hooks in the virtual machine that needs to be monitored. When a program that needs to be monitored reaches the hook, the control is taken and passed to the security tool to ensure the safety of the system. The main advantage of this technique is that since the hooks are placed in the virtual machine that needs to be monitored, it has more clear view of the state and hence the semantic gap is reduced. Lycosid [10] detects hidden process in the virtual machines. The idea is to obtain a high level report with the list of process running in the guest virtual machine and then obtain low level report with the list of processes that are actually running in the memory allocated to the virtual machine. If the number of processes listed in the guest VM and the number of processes that are detected by the VMM are different then there is a hidden process. Vigilante [11] is a collaborative approach for the end to end detection/prevention of the worms. Each host runs specific software which captures the information regarding the exploit of the worm and distributes a Self Certifying Alert (SCA) to warn other hosts regarding the spread of the worm. The end hosts can use the information in the SCA to identify if it is vulnerable to the worm and apply a host based filter to prevent the worm. Spyware collects the sensitive information of the user and sends it to the attacker without the user’s knowledge. Most of the existing anti-spyware tools monitor the applications by matching it with the known spyware instances. Egele et al [12] proposed dynamic spyware analysis tool which can monitor the flow of the sensitive data when it is proposed by the web browser and the browser help objects. The tool can analyze the behavior of the suspicious browser help objects and generates a detail report on what data is being sent and to which location it is sent. Elbadawi et. al [13] has proposed to use TimeVm with log replay to achieve high availability of some services like HTTP, FTP, and SMTP. The services that need high availability are implemented on the virtual machines and each service is cloned into several virtual machines. The traffic to each server is recorded and replayed to the cloned virtual machines at different time intervals. Depending on the importance of the service, there may be several clone virtual machines that are running in parallel at different time intervals. If an attack on a particular virtual machine is detected after time period T, then it excludes the attack traffic and performs a fast replay to all the
virtual machines with time lag greater than T for fast recovery of the service. III.
OUR ARCHITECTURE
A. Design Choices In this section we first consider the design choices for comprehensive intrusion detection system using Virtual Machine Monitors. •
•
•
•
745 746
There can be different types of attacks on the virtual machines. One of the requirements to deal with the attacks efficiently is to follow a preventive or proactive approach. In order to achieve this goal, the model should be capable of detecting and preventing the attack traffic from the well known attacks and there should be a mechanism to deal with the zero day attacks. However it may not be possible to prevent the attack in the first place due to several reasons. Already there are several hundreds of known attacks and it is not an easy task to monitor the systems for all the well known attacks and prevent them. In addition there is an increased activity of zero day attacks in the current Internet. Some of the reasons for increased zero day attacks are due to extremely large size of the current operating systems, which often leads to software errors as well as inherent weaknesses in the TCP/IP protocol stack. The efficiency of the security tool to detect and prevent the attacks is based on the knowledge of the OS semantics and the applications running in each virtual machine. However due to continuous updates (e.g. patches) to the operating systems and its applications, there is a need for techniques to keep track of the dynamic changes and also to capture the behavior of the applications within each virtual machine. Although the VMM has complete control on the virtual resources and has access to the contents of different registers, it may not be always possible to differentiate between applications or processes which leads to the so called semantic gap. Each virtual machine has some unique features that need to be captured by the VMM (or the IaaS service provider) to efficiently detect and prevent the attacks. For example even if multiple virtual machines running on the VMM have same operating system, they can have different configuration, different applications and different amount of resources allocated to them by the virtual machine monitors. Hence the attack characteristics (and attack surface) can considerably vary for each virtual machine. For example, if very few resources are allocated to a particular VM, the attack traffic threshold for that particular VM should be set to low. In addition, attack signature should be defined to be specific to each virtual machine. The attacks should be identified with minimal false positives and false negatives. False negative is a case where an attack is not detected by the security tool and false positive is a case where a legitimate event is detected as attack. One of the requirements to achieve this property is dependent on the knowledge of the OS semantics and the applications running in each virtual machine and also depends on the resources allocated to each virtual
•
•
•
•
machine. As the semantic gap increases the number of false positives and false negatives increases. The existing tools detect the attacks at the VMM that is hosting the source virtual machine or at the VMM that is hosting the destination virtual machine. There are several challenges for detecting the attacks only at a single point i.e. at the source end or at the destination end. There should be mechanism to detect and prevent the attack by capturing the information from a single or multiple locations such as at the source, at the destination, by combining the information at the source and the destination, and by combining the information from multiple sources. For example, in the case of distributed denial of service (DDoS) attacks, each compromised machine may only contribute to small amount of attack traffic and it may not be possible to detect the attack at the source. In such cases, the attacks can be efficiently detected at the destination. In case of worms, the attacks can be efficiently detected by combining the information captured from multiple machines or infected hosts. Attacks should be identified at a fine granular level so that only these attacks can be prevented while all the other traffic is not affected. In some cases, due to shortage of IP addresses, multiple virtual machines can be using/sharing a single IP address. In such cases, if a single virtual machine is compromised and if attack signatures are identified based on the source address, this can result in denial of service for all the virtual machines that are sharing the IP address. In such cases, there should be mechanism to differentiate traffic originating from each virtual machine and isolate only the traffic from the malicious virtual machine. Multiple applications or processes can be running in each virtual machine. In such cases, it is necessary to identify the malicious application/process and dynamically isolate only such application/process. The time taken for the spread of malware is continuously decreasing. Hence there should be mechanisms for automatic detection of spread of malware. There is a need for techniques for automated identification of new attack signatures. Furthermore, once attack signatures are identified, there should be mechanism to enforce dynamic filters or policies. In some cases the attacks can be efficiently prevented by applying dynamic filter at a single location whereas in other cases such as spread of worms, filters need to be placed at multiple locations. For example, there should be possibility to drop the attack packets at the attacking (source) virtual machine or at the destination (victim) virtual machine or in the case of spread of worms, there should be mechanism for distributed filtering. It can be of considerable overhead if each packet transmitted or received by the virtual machine has to be monitored for intrusions. Hence the model should support variable security levels with different overhead for different applications. For example, if a banking application is running in a virtual machine then there should be possibility to provide highly secure services for this application. In case of online games and voice over IP (VoIP) applications, performance and quality of service
(QoS) could be of higher priority. In some cases, the packets needs to be validated at the source and at the destination, whereas in others, just at the source or at the destination. In this paper we consider developing security architecture for comprehensive attack detection by considering some of the above design issues. B. Overview The architecture of the commercial IaaS service providers [1] is not publicly available. So let us consider generic IaaS architecture [3] as shown in Figure 1 and discuss techniques for intrusion detection on the customer virtual machines. The Cloud Controller (CLC) is the main interface for the customers and it is the top level management for the IaaS cloud. It can query other controllers such as the cluster controllers (CC) and Node Controllers (NC), Walrus Storage Controller (WS3) and makes high decision on the implementation of the virtual machines and storage of the data and has the policies for the IaaS infrastructure. It also handles the authentication of the users and in most of the cases the initial user registration is an offline process. Walrus Storage Controller provides storage for the VM images, and user data. Node controller is implemented on each physical server and is responsible for managing the customer virtual machines and a group of node controller report to the Cluster Controller. The Elastic Block Storage (EBS) runs on the same machine as the cluster controller. As shown in Figure 1, let us consider that the customer virtual machines are hosted on the virtual machine monitors which are integrated with the Node Controller for the management of the customer virtual machines. One of our aims is to integrate the IDS architecture into each physical server in addition to the Node Controller (NC) as shown in Figure 1. The zero day attack analyzer can be used to perform detail analysis on the suspicious customer virtual machines in an isolated environment. Zero Day Attack Analyzer VM VM NC & Victor
VM VM NC & Victor
VM VM NC & Victor
VM VM NC & Victor
VM VM NC & Victor
VM VM NC & Victor
VM VM NC & Victor
VM VM NC & Victor
CC & EBS
CC & EBS
CLC & WS3 Figure 1: IaaS Architecture
746 747
VM1
Customer Virtual Machines
VM2
VMn
Analyzer
VICTOR
OS Library and Repository
VMM Packet Differentiator
Detection/ Prevention Engine
Shared Packet Buffer
Physical Devices Figure 2: VICTOR Architecture Figure 2 shows the architecture of Virtual machine Intrusion deteCTOR (VICTOR) system which is integrated into the VMM. We will first present a high level overview of the VICTOR and then discuss each component of the architecture in detail. One of the main aims of VICTOR is to identify the malicious entity that is generating the attack flow and dynamically isolate the malicious entity. The entity can be very broad such as a compromised virtual machine or an application or a process that is running in a virtual machine. In order to deal with the attacks efficiently, the entity has to be defined at fine granular level. If the entity is very broad such as virtual machine, and when an attack is detected then that virtual machine has to be isolated from other machines. This can cause denial of service for all the legitimate applications running in that particular virtual machine. On the other hand if the entity is very narrow such as application or a process running in the virtual machine, then only the malicious application or the process can be isolated and it will be very efficient to deal with the attacks by isolating the malicious entities at a fine granular level. Since VICTOR has control on the physical resources it can monitor all the interactions between the virtual machines and detect the attacks. However in this paper, the focus of our work is to deal with the attacks and isolate/prevent them at the network layer. So we consider that all intra-VM and inter-VM communication is through IP packets and is passing through the VICTOR. This is reasonable since some of the IaaS providers [1] only permit network level communication even for the virtual machines that belong to the same customer. Since VICTOR is integrated into all the VMM’s, all the packets generated by the virtual machines and all the packets destined to the virtual machines pass through VICTOR and are monitored for intrusions. Hence attacks can be detected at the source virtual machine or at the destination virtual machine.
1) Packet Differentiator The packets generated by the virtual machines are received by the packet differentiator. The packet differentiator can query the virtual machine to report the operating system or application or process that is responsible for generating the packet. Detecting the entity at fine granular level is dependent on the operating system in the virtual machine. The details of the entity that generated the packet are passed to the OS Library and repository component. The packet differentiator also ensures that the packet generated by the virtual machine has the correct source address. If the packet generated by the entity has spoofed source address then the packet and the corresponding entity that generated the packet is reported to the detection/prevention engine. The packet differentiator can also be considered as a proxy, which keeps a track of all the requests originating from the virtual machines and passes the corresponding reply messages to the virtual machines. After updating the OS library and repository with the entity that generated the packet, the packet differentiator passes the packet to the detection/prevention engine. Since several virtual machines can be running on a single VMM and due to shortage of the IP addresses, different types of addressing schemes can be used in the Virtual Machine Monitors. In some cases, a unique IP address is issued to each virtual machine and in some cases a single IP address can be shared among multiple virtual machines. It is easy to identify packets destined to each virtual machine which has unique IP address. However if multiple virtual machines share a common IP address then there is need to differentiate traffic originating from each virtual machine uniquely. In this case, the packet differentiator assigns a unique ID for each virtual machine and marks the packet with the unique ID in the ToS field or fragment ID field of an IP packet. Such marking has been previously considered [14] for tracing the DDoS attacks in the Internet. The unique ID can be hash of the private address used by the virtual machine. This marking enables the destination VICTOR to differentiate between traffic originating from each virtual machine and identify unique attack signature for each attacking virtual machine at the source VICTOR end. In Section IV we will discuss how this
C. VICTOR Components Now let us consider each component of the VICTOR architecture in detail.
747 748
packet marking will be useful for detecting and preventing the attacks efficiently.
remote VICTOR reports a suspicious packet/flow, the malicious entity that generated the packet can be determined by querying the OSLR and dynamically isolated.
2) OS Library and Repository The OS library and repository (OSLR) component has a generic knowledge of the operating system when the customer virtual machines are initially hosted on the cloud service provider infrastructure. As discussed in Section III.A there is a need to have good knowledge of the operating system and the applications to detect the attacks efficiently. This should include details such as configurations, applications running in each OS, types of traffic generated by each application, and resources allocated to each virtual machine. Also there is a need to update the knowledge dynamically during updates to the operating systems and applications. Hence the information in the OSLR is an important component for the VICTOR to detect and prevent the attacks. When the packet differentiator reports the entity that generated the packet, the OSLR can verify if the received information is correct since it has complete access to physical devices and can easily determine the state of the virtual machine. Techniques such as Lycosid [10] can be used to determine if the reported process is actually running in the virtual machine. If the reported application or process cannot be identified by the OSLR, then the packet can be considered to be malicious. However that particular packet could be the last packet generated by the recently terminated legitimate application. In such cases, this can be determined by observing the previous packets generated by that particular application. In some cases the packet could have been generated by a hidden process. In such cases the OSLR will not have any particular application to assign the data. In such cases, the virtual machine can be considered as compromised. Now the OSLR generates an alert to the detection/prevention engine for further analysis. The decision will be made by the detection/prevention engine and/or the analyzer. One of the design issues in this case is to ensure that the OSLR sends an alert to the detection/prevention engine before the packet can be sent out by the detection/prevention engine to the actual destination. In our architecture, the main idea is to capture the behavior of applications in the customer virtual machines. Also, when new applications are installed in the virtual machine, such details are captured when the applications communicate with other virtual machines. Hence the knowledge in the OSLR is dynamically updated. Also since all the packets are stored in the OSLR, this information can be used over different time periods and checked to see if some of the previous traffic needs to be analyzed. The information stored in the OSLR is useful for defining the attack signatures for each virtual machine. This will enable the system administrators to define attack signatures based on the unique properties of each virtual machine. In addition as the knowledge in the OSLR increases, the anomaly detection engine can be trained to differentiate between legitimate and suspicious traffic for each application or virtual machine. This knowledge will be useful for the detection/prevention engine and the analyzer to efficiently deal with the attacks with minimal false positives and false negatives. Also, when a
3) Detection/prevention Engine The detection prevention engine has a database of all the known attack signatures and is also capable of anomaly intrusion detection. One of the main functions of the detection/prevention engine is to ensure that any traffic that is entering or leaving the VMM does not contain any malicious content. To minimize the overhead, the VMM administrator can configure the attacks that are relevant to each virtual machine. Since the OSLR has the details of resources allocated to each virtual machine and applications running on each virtual machine, the detection/prevention engine can use these details to uniquely specify attack signature for each virtual machine. The anomaly intrusion detection is enabled for all the virtual machines. When CPU is idle, the anomaly based engine applies machine learning techniques on the OSLR data to differentiate between legitimate and malicious behaviour for each virtual machine. This enables VICTOR to capture the dynamic changes for each virtual machine and identify the attacks with minimal false positives and false negatives. If the packet matches with any of the known attack signature then the packet is dropped. If the packet does not match with any of the signatures but is found to be suspicious, then a copy of the packet and the details of the virtual machine which generated the packet are stored in the shared packet buffer; a copy of the packet is also sent to the analyzer. Some of the events that can make the detection/prevention component to identify packet as suspicious are: sudden burst of traffic, abnormal usage of resources (CPU, memory, network) by single entity, random packet to the same/multiple destination, packets with spoofed source address, and packets destined to non standard port numbers. While the decision is made by the analyzer on the suspicious packet/flow stored in the shared packet buffer, the packets from the suspicious virtual machine can be dropped, rate limited or passed to the destination virtual machine. If a packet matches with the details of virtual machine stored in the shared packet buffer then there are three different ways for the packet to be processed by the detection/prevention engine. In the default pass mode, a copy of the packet is sent to the analyzer and the actual packet is passed to the destination. In the default drop mode, a copy of the packet is sent to the analyzer and the actual packet is dropped. In the decision pending mode, the packet is sent to the analyzer and it makes the decision if the packet has to be dropped or forwarded (rate limitation) to the actual destination. 4) Shared Packet Buffer The shared packet buffer stores the details of the virtual machine that is suspicious. If the details of particular virtual machine are stored in the shared packet buffer, then the detection/prevention engine passes all the traffic to/from that suspicious virtual machine to the analyzer. The difference between the shared packet buffer and analyzer is that the analyzer can store all the incoming and outgoing packets from suspicious virtual machine and may request additional
748 749
information from the OSLR. The shared packet buffer is a passive component which serves as reference for detection/prevention engine. For each virtual machine details stored in the shared packet buffer there are three different modes. The modes are set by the analyzer when a decision is being made on the suspicious packet. The modes are used to minimize the delays caused to the packet and also to identify the attacks with minimal false positives and false negatives. One of the reasons to identify the complete virtual machine as suspicious is due to the polymorphism and metamorphism properties exhibited by the current attack trends. The other important property is that the details of the suspicious virtual machine are entered into the shared buffer by the detection/prevention engine but the details are cleared by the analyzer after a decision is made on the suspicious packet or virtual machine.
IV.
ANALYSIS
We have implemented the prototype with two physical servers running Xen VMM and each VMM hosting three guest virtual machines as shown in Figure 3. The client virtual machines of customer 1 are implemented on VMM1 and the server virtual machines of customer 2 are implemented on VMM2. We have used Xen 3.1.2 VMM and Centos 5.1 operating system virtual machine with 4GB RAM and 2.4 GHz dual core processor with virtual machines running different operating systems and applications. The device drivers in Xen have a front end module which are implemented in the virtual machine and a back end module in the Dom 0. The guest VM send the packets using the front end drivers and the host machine sends the packets to the guest virtual machines using the back end drivers. The policy engine is placed between the front end and back end drivers. We have analysed our model for different types of attacks such as hidden processes and worms. In this section we will discuss some of the results from our analysis.
5) Analyzer The analyzer determines if the reported packet is actually malicious or benign with the help of OSLR, and by analyzing the subsequent packets generated and the packets received by the suspicious virtual machine. While a decision is being made by the analyzer on the suspicious packet all the traffic from that suspicious virtual machine is either dropped or passed or rate limited based on the properties exhibited by the suspicious packet. If the suspicious packet exhibits serious properties such as spoofed source address or if hidden processes are detected in the virtual machine, then the packets are dropped. On the other hand if there is sudden burst of traffic and the application that is generating the traffic can be identified, then traffic can be forwarded to the destination or rate limited. Some of the attacks exhibit different types of malicious behavior depending on time. Such attacks can be detected by the time based analysis which will be discussed in Section IV. After the analysis, if the analyzer identifies the packet to be malicious, the malicious entity that generated the packet can be identified by querying the OSLR and can be dynamically isolated. The analyzer also identifies a new attack signature based on the properties exhibited by the malicious packet and updates the attack signature database in the detection prevention engine. Now the analyzer removes the details of the suspicious virtual machine from the shared packet buffer. If the details are removed from the shared packet buffer then the future traffic from the virtual machines will be monitored only against the attack signature database and for anomalies by the detection/prevention engine. Since new attack signature is identified for the new attack, even if any other virtual machines send similar suspicious packet in the future, this can be easily detected and prevented by the detection/prevention engine. After the analysis, if the analyzer identifies the packet to be benign, the details of the suspicious virtual machine are removed from the shared packet buffer so that the further packets from/to the virtual machine will not be sent to the analyzer by detection/prevention engine. Some of the analysis requires considerable resources and time. In such cases, the analyzer can suspend the suspicious virtual machine and request the zero day analyzer to perform further analysis in an isolated environment (see Figure 1).
DOM 0
DOM 0
PD
PD
OSLR
OSLR
DPE SPB
GVM1 GVM2 GVM3
Anlzr
DPE SPB Anlzr
GVM4 GVM5 GVM6 Web Server
DNS Email Server Server
VMM1
VMM2
Hardware
Hardware
Figure 3: Attack Scenario In some cases, multiple virtual machines can be sharing single IP address. In such cases, there is need to differentiate traffic originating from each virtual machine to deal with the attacks efficiently. Let us consider an example scenario as shown in Figure 3, where virtual machines that belong to customer 1 are hosted on VMM1 and virtual machines that belong to customer 2 are hosted on VMM2. We have configured Web, DNS and Email services for customer 2 virtual machines. Also we have used customer 1 virtual machines to access the services from the customer 2 virtual machines. In this case we have used a public IP address only for the Virtual Machine Monitors and all the virtual machines of customer virtual machine share the IP address of their VMM. Hence the packets generated by any of the virtual machines which are hosted on the VMM1 will have similar IP address of the VMM1. So during attack times it will be difficult for the destination VICTOR on VMM2 to differentiate between the packets originating from VM1, VM2 and VM3 since they have the same IP address. Now we have used VM2 to flood the customer 2 virtual machines on VMM2. Since single IP address is shared by all the virtual machines, the destination VICTOR cannot differentiate between the traffic originating from each virtual machine on VMM1. Hence, this will also result in dropping of
749 750
the legitimate traffic from virtual machines VM1 and VM3. Figure 4 shows the traffic received at VMM2 for case of unmarked traffic. As shown in Figure 4, once the flooding starts, all the traffic from virtual machines hosted on VMM1 will be dropped.
Unmarked Packets 1000 900 800
# of Packets
700 600 500 400
Figure 7: Detecting time based attacks
300 200 100
Some of the attacks are configured to exhibit different malicious behavior with time. For example, code red is configured to spread the worm during 1st to 19th day of the month, launch denial of service attack during 20th- 27th day of the month and sleep from 28th to end of the month. Now let us consider how the analyzer can be used to detect attacks that are triggered at some event. Consider the sample code of a worm in Figure 6, which is configured to be activated on 12th November and the current date is 10th November. Let us consider how such attacks can be detected in before the configured time. The analyzer can be used for time travel to detect if any of the application has malicious code that will be activated at a future date. This is shown in Figure 7. In this case, the time for the virtual machine is configured to accelerate with a speed of 100x. Hence when the date in the virtual machine changes to 12th November, the code is activated and the message bomb exploded is displayed on the screen. Hence VICTOR can be used to detect attacks that can be triggered by some specific events.
0 1
12 23 34 45 56 67
78 89 100 111 122 133 144 155 166 177 188 199 210 221 232 243 254 265 276 287 298 Time
Figure 4: Unmarked Packets Now for the same scenario consider the case with packet marking. In this case the traffic from VM1 is marked with ToS = 1 in the ToS filed and the traffic from VM2 will is marked with ToS =2 and the traffic from VM3 is marked with ToS=3. In this case, the destination VICTOR will be able to differentiate traffic originating from each virtual machine. This is shown in Figure5. In this case the destination VICTOR will be able to differentiate the traffic originating from each virtual machine. Hence when the VM2 starts flooding the customer 2 virtual machines, only the traffic from VM2 will be dropped by the destination VICTOR. Hence legitimate traffic from VM1 and VM3 can still access the customer 2 services.
V. Marked Packets
In this paper we have considered the design choices for securing customer virtual machines in the cloud and proposed techniques to deal with the attacks. Our model enables to differentiate traffic from each virtual machine even if multiple virtual machines on a VMM are sharing a single IP address.
VM2 VM3 All 1000 900 800 700 # of Packets
CONCLUSION
VM1
600 500 400
REFERENCES Amazon Web Services. Creating HIPAA-Compliant Medical Data Applications with Amazon Web Services. White Paper, http://awsmedia.s3.amazonaws.com/AWS_HIPAA_White paper_Final.pdf, April 2009 [2] L. Youseff, M. Butrico, and D. Da Silva, "Towards a Unified Ontology of Cloud Computing", In Grid Computing Environments Workshop, Nov 2008. [3] Daniel Nurmi, Rich Wolski, Chris Grzegorczyk, Graziano Obertelli, Sunil Soman, Lamia Youseff, Dmitrii Zagorodnov, "Eucalyptus : A Technical Report on an Elastic Utility Computing Archietcture Linking Your Programs to Useful Systems" UCSB Computer Science Technical Report Number 2008-10, Available at: http://open.eucalyptus.com/documents/nurmi_et_aleucalyptus_tech_report-august_2008.pdf
300 200
[1]
100 0 -100
1
13
25
37
49
61
73
85
97 109 121 133 145 157 169 181 193 205 217 229 241 253 265 277 289 Time
Figure 5: Marked Packets 1. GetDateFormat( ) 2. if (day>12&& month=11), AttackVictim( );
Figure 6: Conditional activation of attack
750 751
[4]
[5]
[6]
[7]
[8]
Stefan Berger, Ramón Cáceres, Kenneth Goldman, Dimitrios Pendarakis, Ronald Perez, Josyula R Rao, Eran Rom, Reiner Sailer, Wayne Schildhauer, Deepa Srinivasan, Sivan Tal, Enriquillo Valdez, “Security for the cloud infrastructure: Trusted virtual data center implementation”, IBM Journal of Research and Development, Vol 53, No 4, 2009. Thomas Ristenpart, Eran Tromer, Hovav Shacham, Stefan Savage, “Hey, You, Get off my cloud: Exploring Information leakage in third-party compute clouds”, Proceedings of ACM CCS 2009. George W. Dunlap, Samuel T. King, Sukru Cinar, Murtaza A. Basrai, Peter M. Chen, “ReVirt: Enabling Intrusion Analysis through Virtual-Machine Logging and Replay”, Proceedings of OSDI, 2002. T. Garfinkel and M. Rosenblum, “A virtual machine introspection based architecture for intrusion detection”, Proceedings of Network and Distributed Systems Security Symposium, February 2003. G. Popek and R. Goldberg. “Formal Requirements for Virtualizable 3rd Generation Architectures”, Communications of the ACM., 17(7), 1974.
[9]
[10]
[11]
[12]
[13]
[14]
751 752
Bryan D. Payne, Martim Carbone, Monirul Sharif, Wenke Lee “Lares: An Architecture for Secure Active Monitoring Using Virtualization”, Proceedings of the IEEE Symposium on Security and Privacy, 2008. Stephen T. Jones , Andrea C. Arpaci-Dusseau , Remzi H. Arpaci-Dusseau, “VMM-based hidden process detection and identification using Lycosid”, Proceedings of ACM VEE 2008, Seattle, March 2008. Manuel Costa, Jon Crowcroft, Miguel Castro, Antony Rowstron, Lidong Zhou, Lintao Zhang and Paul Barham, “Vigilante: End-to-End thcontainment of Internet Worms”, Proceedings of the 20 ACM Sympoium on Operating Systems Principles, Oct 2005. M. Egele, C. Kruegel, E.Kirda, H.Yin, and D.Song, “Dynamic Spyware Analysis”, Proceedings of 2007 Usenix Annual Conference. Khalid Elbadawi, Ehab Al-Shaer, “TimeVM: A Framework for online intrusion mitigation and fast recovery using multi-time-lag traffic replay”, ACM ASIACCS 2009, Australia, March 2009. S.Savage, D.Wetherall, A.Karlin, and T. Anderson, “Network support for IP traceback”, ACM/IEEE Transaction on Networking, June 2001.
