Anti-DDoS Virtualized Operating System - CiteSeerX

Anti-DDoS Virtualized Operating System Sanjam Garg

Huzur Saran

Indian Institute of Technology, Delhi {sanjam, saran}@cse.iitd.ac.in

Abstract—It is easier to detect a DDoS attack near the victim but it is of little use to do so. Many researchers believe that it would be best to handle DDoS attacks closer to the computers which host these attacks and have propounded various strategies for packet filtering at edge-routers. This paper makes three contributions over earlier work. First, we propose that it is best to track illegitimate packets suspected to cause a DDoS at the source computer itself. Secondly, we come up with a secure and efficient implementation (ADVOS: Anti-DDoS Virtualized Operating System) for packet filtering at the source computer itself. Security dependency on the integrity of the source operating system is removed by using virtualization to isolate the modules providing the protection capabilities. Different models of traffic characterization could possibly be used in curtailing malicious traffic, we justify the effectiveness of symmetry based model at source computers. Thirdly, we demonstrate that such an anti-DDoS operating system using virtualization can be implemented practically and efficiently. In our prototype over native Linux system 2.4% overhead was observed in the attained network throughput. Less than 1% of the total attack traffic generated was allowed to pass through on attack. Finally, we discuss the scalability and deployment issues for ADVOS.

I. I NTRODUCTION Distributed Denial of Service attacks involve breaking into hundreds or thousands of machines all over the Internet. Then the attacker installs DDoS software (we refer to it as a worm) on the commandeered hosts, allowing him to control all these hijacked machines, also called zombies to launch coordinated attacks on victim sites. These attacks typically exhaust bandwidth, router processing capacity, or network stack resources, breaking network connectivity to the victim. A lot of defense techniques proposed have concentrated on auditing network traffic received by the victim but these techniques have not been very effective because of the enormity of number of packets that need to be handled. Recently, researchers have come up with strategies for packet filtering which have been deployed at the edge-routers, closer to the sources of attack packets. In this technique, known as egress filtering [1] the packets going out of a network are monitored and the ones suspected to have DoS attack as intent are identified and filtered. These solutions have limited applicability because of the extremely large number of the packets that need to be handled and the limited memories and computational capabilities these edge routers have available. We propose a new solution to solve the problem of DDoS by doing packet analysis and filtering at the source computers themselves. The security of this system would then depend on the integrity of the kernel of the operating system. Once the system has been infected by a root-kit or trojan, running

Fig. 1.

Abstract Architecture for packet filtering.

with the same privilege as the operating system, then such an attack module could easily temper with any of the security capabilities that interfere with its malicious intent. We make our architecture free from this dependency by limiting user interaction with just a virtual machine and embedding protection modules as part of the host operating system. This mechanism allows us to pull the anti-DDoS capabilities “outside” of the host, it is trying to prevent from misbehaving, to an independent domain, providing better protection from the attacker’s malicious code. It is assumed that the user on the system is not malicious and it is because out of his ignorance that his computer is being used as a zombie. The deployment of filtering techniques at hosts equips the filtering modules with more computational power than available at routers. Filtering at hosts also allows for more information gathering than what is possible at routers. In a large network where the amount of legitimate traffic is quite high, small amounts of attack traffic can be easily smuggled along with legitimate traffic. However, the aggregate effects of small amounts of traffic from numerous networks could easily cripple a victim. The use of virtualization in its crude form has significant performance overheads. We advocate the use of paravirtualization [2] for providing isolated environment for secure

execution of the modules providing the anti-DDoS capabilities. Para-virtualizating involves modifying the guest and the host operating systems for achieving virtualization at a lower performance cost. We use a popular open-source paravirtualization technology - Xen [3] in order to provide the isolation capabilities. Xen has been shown to have very low performance overheads. The security of our architecture will depend on the security threats that Virtual Machine Monitor (VMM/hypervisor) itself faces. Because of the limited functionality that a VMM is supposed to provide it has a small trusted code base that could be relied upon. Different models of traffic characterization could be used in defining legitimate traffic. We justify the effectiveness of symmetry based model [4] in curtailing malicious traffic at hosts by analyzing data we collected on a heavily used server. The deployment of anti-DDoS capabilities on computers has many potential legal and social incentives for users and organizations. If an organization uses systems with anti-DDoS capabilities then it can claim to be network friendly and could demand uninterrupted resources from Internet Servers and Internet Service Providers(ISP) on the basis of the built trust. Organizations also face legal responsibilities for the attack packets generated from their network. Use of anti-DDoS capabilities in operating systems could help achieve standards in the prevention of DDoS. We build a working prototype - ADVOS to provide protection capabilities to a Linux guest running on Xen [3] a popular open-source VMM. In our prototype 2.4% overhead over native Linux system was observed in the attained network throughput. It allows less than 1% of the total attack traffic to pass through. The rest of this paper is organized as follows: section II presents the related work. Section III describes the framework for providing anti-DDoS capabilities to an operating system and section IV focuses on the implementation details. Section V presents some experimental results obtained for ADVOS and Section VI discuss some security aspects of ADVOS. In section VII we discuss some practicality issues and conclude giving a note on future work.

DDoS Many solutions [9] have been proposed to counter the problem of DDoS attack. To meet constraints of space we will discuss only a few techniques most relevant to our work. • MULTOPS - This technique uses a data-structure MULTOPS (Multilevel Tree for Online Packet analysis) [10] that is basically a tree of nodes that contains packet rate statistics for subnet prefixes at different aggregation levels. The tree expands and contracts to get the focus of exact IPs which seem to generate illegitimate traffic. The packets are considered to be malicious if they are destined for a host from which too few packets are coming back. • D-WARD - This technique [11] does traffic profiling based on connections to a particular destination and imposes rate limits on the traffic based on the comparison between the observed incoming & outgoing packet statistics and the model of legitimate traffic. • SynKill - The synkill [12] algorithm classifies source IP addresses as never seen, good, new or bad. This classification is based on the observed network traffic and other inputs. Each packet is then analysed and suspected attack packets are dropped. • SynDefender - SYNDefender [13] Relay prevents a SYNflood attack by mediating the start of every connection. Whenever a SYN packet reaches the gateway it is intercepted and corresponding SYN/ACK reply is sent. The actual SYN packet is sent to the requested server only when an ACK reply packet from the same requesting client is heard. III. F RAMEWORK FOR ADVOS In this section we bring out the design goals of a system with anti-DDoS capabilities and come up with the architectural specifications for implementing it securely and efficiently. A. Design Goals •

II. R ELATED W ORK Two trends have come up in the hardware-level virtualization strategies: full system virtualization, where a virtual machine is deployed as a complete copy of the underlying hardware e.g. VMware [5] and Virtual server [6] and paravirtualization in which the guest and the host operating systems are modified to support virtualization with lower performance penalties e.g. Denali [7], User Mode Linux [8] and Xen [3]. The VMMs have been used for there ability to create and destroy virtual machine instances, run potentially vulnerable applications in isolated virtual execution environments, and to roll back machines to clean states in case of problems.

•

Integrity of the Operating System - In order to prevent an infected computer from generating attack traffic we need to filter the packets that the worm on the computer generates. A worm with administrator privileges on a system could temper with any utility intended to protect the system. So there is a need to ensure that the protection modules receive perfect isolation from all other processes running on the system. We establish this by allowing user interaction with only a virtual machine executing as a guest operating system, and ensuring isolated execution of the anti-DDoS modules in the host operating system itself. Flexibility - It needs to be ensured that the user on the system, has complete flexibility allowing executions of all applications which may require the use of complex network configurations (e.g. applications which use of more that one IP address). Hence simple filtering mechanisms can not be adopted. The system therefore requires sophisticated controls over the network flows that can consider

•

•

•

•

•

state information from past and current connections and can provide extensive auditing capabilities. Effective yet Computationally Inexpensive - The system should have the ability to marginalize the number of attack packets that can pass through even if the rate of an attack is very small but at the same time it should be computationally inexpensive. Architecturally Simple - The system on implementation should involve minimum changes in the VMM. The increasing complexity of the VMM makes it more vulnerable due to potential implementation bugs. Dispensable Update Capabilities - The mechanisms providing anti-DDoS protection capabilities should not depend on regular updates for their operations, so that the system does not become vulnerable in the event of failure to update. Protected Host - The communication of the host operating system with the external world should be limited. The communication of the guest operating system with the host operating system should be secured so that any infection after having infected the guest operating system, can not percolate to the host operating system. Alerts, Information Gathering & Recuperation - In case the host system detects some DDoS attack from itself and filters packets then it should alert the guest domain about the infection it expectedly has so that the user knows about it and some steps for its treatment could be taken. It would be of great significance to gather more information about the worms responsible for these attacks. Virtual Machine Introspection [14] provides a potential mechanisms for gathering this information. A recover mechanism to cure the system form the infection could help prevent future attacks by the same worm.

B. Flow Classification For a system to filter attack traffic it should have the ability to distinguish between legitimate and attack traffic. Many techniques to distinguish traffic flows have been proposed. Any of these could potentially be used to provide the distinguishing capabilities. A multiplicity of some of these techniques could also be used. In order to demonstrate the effectiveness of doing packet filtering at the computers sourcing attack traffic, we use a specific model to detect DDoS based attacks in our implementation. The model we use in our implementation is very simple. But our modular design allows use of any classification scheme. Legitimate TCP Traffic Model Considered in Our Implementation: The TCP flow is characterized by a constant reverse flow of acknowledgments. For every packet sent to a particular destination there is a corresponding reply packet. Legitimate flow is found to be bounded by an upper limit tcpratio max on the term tcpratio defined by the equation number of packets sent tcpratio = number of packets sent and received where the sent and received packets are the packets sent and received in a particular interval of time. Moving averages of

tcpratio are maintained to give an idea of the current traffic characteristics and initiate recovery processes in case the traffic seems to behave well. The outgoing packets are allowed to pass as long as they continue to obey the above limit. In situations where the flow fails to meet these requirements the flow is classified as attack flow and a rate limit is imposed on the network flow so as to drop the illegitimate packets and prevent DDoS attack from happening. This is similar to the heuristic suggested in DWARD [11]. This symmetry model [4] of characterization has been proved to very effective in curtailing malicious traffic, but this paper explains about the validity of symmetry on an edgerouter. We validate the same model for host systems by analyzing data we collected on a heavily used server. Using tcpdump, we collected the data from the server pushpa.cse.iitd.ac.in (an internal server at IIT Delhi) hosting a squid proxy server supporting wide range of content types (including multimedia content) for a period of 5 hours and got a trace file of 2.7 Gb. This trace was analyzed (as in Fig. 2) for relation between incoming and outgoing packets on a per flow basis over ranges of time periods varying from 5 seconds to 30 seconds.

Fig. 2.

Linear Curve for 5 sec, 10 sec and 30 sec curves.

Symmetry parameter is defined [4] as follows S = log

sent packets + 1 received packets + 1

(1)

The curve in Fig. 3 represents the frequency distribution of symmetry parameter. This analysis brings out the fact that for network traffic containing highly varied content ranging from plain http and ftp to multimedia the deviation beyond a symmetry parameter of 2 is rarely observed. This indicates that such heuristics are bound to work well on individual hosts. C. Architecture The architecture of the system has been divided into two components- Observation and Filtering on the basis of functionality.

B. Filtering Component The packets are analyzed and a destination is considered to be under attack if tcpratio > tcpratio max

(2)

Ideally the value of tcpratio max should be 0.5 but larger values are taken to account for packet losses that may happen on the network. Rate limit is defined as the upper bound on the ratio of the number of packets allowed to pass through and the total number of generated packets1 . rate =

Fig. 3.

Symmetry Parameter distribution

The observation component captures all packets entering the system (incoming packets) and those leaving the system (outgoing packets) and maintains a database of various parameters that are important for the classification of the packets as attack. The filtering component on comparison of these parameters with the defined legitimate flow model determines if some particular destination host is under attack and rate limits the network flows to that particular destination. This rate limiting helps to reduce the attack traffic to the victim. If after the imposition of this rate limit the flow still continues to show the characteristics of attack then the rate of flow is further marginalized. A recovery mechanism can also be initiated in case the flow indicates to behave well. A notification is sent to guest domain about the expected infection the computer has and the user is advised to treat it using an updated version of an anti-virus. But this strategy of notifications can not be relied upon. Different strategies for recuperation have been discussed in section VII.

number of packets sent number of packets generated

(3)

If the number of outgoing packets is out of proportion to the incoming packets then a rate limit is imposed which causes some generated packets to be dropped. But if the traffic continues to show attack characteristics then more stringent rate-limits are imposed. The decrement function characterizes the profile of exponential decrease in the rate limit. ratenew =

rateold fdecrement f unction

(4)

Recovery from Misclassification: Decrease in tcpratio indicates that the flow is behaving well. In case the module finds that the flow is indeed well behaved after having classified it as illegitimate, then the module starts increasing the rate limit. ratenew = rateold ∗ fincrement f unction

(5)

The increment function characterizes the profile of exponential increase in the rate limit. This allows for a rapid recovery from the false positive. If a slow recovery is desired then an incremental rate increase function as defined by equation 6 could be used.

IV. I MPLEMENTATION D ETAILS Both the operations of observation and filtering are done at the kernel level for efficiency reasons. The default Xen configuration uses a bridged-network within Dom0 (host operating system as defined for Xen) to allow all domains to appear on the network [15] as separate individual hosts. A. Observation Component Observation is done by allowing all incoming and outgoing packets to pass through a loadable kernel module. A hash table is constructed that stores values corresponding to particular destination IP addresses. Corresponding to each destination IP address it contains the following parameters psent - number of packets sent to that IP preceived - number of packets received from that IP pdrop - number of packets destined to that IP dropped pin/out - value of ratio of in to out packets before last update attack - an attack is expectedly going on to that IP rate - present allowed sending rate

ratenew = rateold + fslow increment f unction

(6)

Latency Increment: To ensure that network traffic from applications which are bandwidth hungry especially on networks that suffer from high latency is not misclassified as attack traffic, instead of using the actual number of packets received as the value for variable received number of packets we use a theoretically incremented value in the calculation of the ratio tcpratio

theoretical value = actual number + latency increment (7) 1 “Generated packets” are defined as the packets generated by the user domain. Some of these packets are filtered, while others are allowed to pass. The packets which are allowed to pass through the VMM are called the “sent packets” or “outgoing packets” while the packets which are filtered are called the “dropped packets”.

C. Alerts In case an attack is observed, then it is filtered but it is not enough just to block the attack packets because the worm infecting the computer could cause more attacks later on. So a notification about the probable infection is sent by the host operating system to the guest operating system. But such a system of alerts can not be relied upon because a worm in the guest could modify the operating system internals and could fool this alerting strategy. V. E VALUATION With each system designed to enhance some security capabilities there are trade-offs in performance and the level of security provided. A. Performance Evaluation To measure the overall performance overhead we compare Xen-Guest with ADVOS capabilities with Xen-Guest and native Linux. All measurements were performed on a 3.20GHz Intel(R) Pentium(R) 4 processor with 512 MB RAM. During network evaluations, other systems with the same hardware configuration were used. All systems used had network interfaces of 100Mbps. The version of Linux used is 2.6.16.29 and the version of Xen VMM is 3.0.3. The Fedora Core 5 distribution was used in the implementation of ADVOS. It was installed on ext3 file system. 128 MB of RAM was allocated to the guest operating system. For these measurements we used guest image corresponding to Fedora Core 5 from jaltime.org as it is one of the most mature virtual OS and readily available online. 1) Operating System Performance: Extensive performance analysis has been performed [2] and all those results indicate that the overheads are acceptable. The kernel modules corresponding to ADVOS capabilities do not introduce measurably significant performance overheads. 2) Network Performance: Since tools like iperf etc. which measure BTC (Bulk Transfer capacity) are themselves intrusive [16] they are not suitable for measuring network performance of ADVOS capable systems. So we use average network throughput achieved as the parameter for comparing network performances. To measure network performance overhead a file of size 2501 MB was transferred over an isolated network from a XenGuest with ADVOS capability, Xen-Guest and native linux to another system file transfer application and average network throughput was compared. The Xen-Guest with ADVOS capabilities suffered a performance degradation of 0.08% and 2.37% over Xen-Guest and native linux respectively. Unvirtualized System Virtualized System Virtualized System with ADVOS capabilities

0.0461 ms 0.0647 ms 0.0648 ms

TABLE I L ATENCY - WITH AND WITHOUT ANTI -DD O S CAPABILITIES .

Fig. 4.

Network throughput - with and without anti-DDoS capabilities.

To measure the overheads on latency in the system Netperf was used and TCP Request/Response tests were performed, with the default request size of 1 byte and a default response size of 1 byte. The one way-round trip latencies were estimated. The results have been reported in table I. The XenGuest with ADVOS capabilities showed an increase in latency by 0.18% over Xen-Guest. With the ongoing research on network optimization [17] these overheads are bound to decrease. B. Security Evaluation For the use of ADVOS establishing its effectiveness against DDoS is of utmost importance. In this section we demonstrate the ability of ADVOS to detect a DoS attack and diminish its effects. A custom tool was implemented to generate SYN flood attack traffic. It can be used to generate traffic at different rates and configure the type of attack that is intended to be launched: continuous or pulsating. The attack packets generated used spoofed source IP addresses. P arameter tcpratio max latency incremnt increment f unction decrement f unction

V alue used in Experiments 0.7 10 2 2

TABLE II VALUES OF DIFFERENT PARAMETERS USED IN EXPERIMENTS .

1) Continuous Attack: In continuous attacks the attack rate is achieved immediately after the attack is launched and is maintained until the attack is stopped. The attack rate of 100 packets/sec was established for this test. Legitimate traffic at almost constant rate was generated throughout the connection period. The rate of legitimate traffic for the test was 75 packets/sec . A continuous attack was launched at 25 sec that generated SYN packets with spoofed source IP addresses. These packets were sent to the victim. Observations about the generated traffic and the traffic allowed to pass have been shown in figure 5. As can be seen the attack traffic was quickly discovered and crippled to a very low value. The small rate that sustains itself after the attack

Fig. 6. Pulsating Attack (a) Traffic Generated (b) System with anti-DDoS capabilities throttles the attack traffic.

Fig. 5. Continuous Attack (a) Traffic Generated (b) System with ADVOS capabilities throttles the attack traffic.

has been identified once is to allow for recovery in case of misclassification. It can be configured as per need. 2) Pulsating Attack: In pulsating attacks the attack rate reaches its maximum value for a small period of time but is brought to zero for some intervals in order to delude the detection systems. The maximum attack rate of 100 packets/sec was used for this test. Legitimate traffic at almost constant rate was generated throughout the connection period. The rate of legitimate traffic for the test was 75 packets/sec . A continuous attack was launched at 37 sec that generated SYN packets with spoofed source IP addresses and were sent to the victim. Observations about the generated traffic and the traffic allowed to pass have been shown in figure 6. The attack is identified before the fist peak of attack traffic and the rate of attack traffic allowed to pass through is marginalized each time a burst in the attack traffic is observed. In both cases the attack traffic was reduced to less than 1% of its original traffic values. 3) False Alarms: In a machine with ADVOS capabilities the legitimate traffic, directed to machines which have been identified to be under attack would face the same rate limit as is imposed on the attack traffic causing the misclassification of traffic. But since the user in domU (guest domain in Xen) is notified about the infiltration which he is expected to treat, it does not seem unreasonable that he is denied network access to the victim machine till the domU is freed of the infections it suffers from. When the attack subsides the

recovery mechanism will initiate automatically. But it must be noted here that an attacker could easily temper with the messaging mechanism making it ineffective, but in all such cases ADVOS would continue to remain effective against DDoS. 4) Limitations: In cases when a host bears huge amounts of legitimate traffic with some destination IP addresses, then ADVOS may be used to smuggle some amounts of attack traffic to those particular hosts, under the pretext of dropped packets. The amount of traffic that can be smuggled will depend on the value of tcpratio max . VI. S ECURITY C ONSIDERATIONS Compromising the host operating system (the domain hosting the anti-DDoS modules) of a system with anti-DDoS capabilities could allow an infection to penetrate it and make a DDoS attack possible. This would cause anti-DDoS capabilities to be rendered ineffective against DDoS, but such a security breach is a rare possibility. If an attacker is able to send spoofed packets from some machines on the Internet to a machine with anti-DDoS capabilities then he can smuggle illegitimate packets out of the antiDDoS capable machine as well. But for using an anti-DDoS capability machine for DDoS attacks an attacker would need to own another machine without anti-DDoS capabilities, thus making the use of the machine with anti-DDoS capabilities redundant. If an attacker performs a DoS attack on a machine with antiDDoS capabilities then the legitimate traffic directed towards this machine will not reach it. Seeing the reduced number of replies the machine with anti-DDoS capabilities would start to filter outgoing packets. This would allow the attacker to

prevent the host from sending legitimate packets outside, thus causing a DoS on the host machine itself. This will be no worse than a system without anti-DDoS capabilities because a well behaved connection in a system without anti-DDoS capabilities will automatically back off on the non receival of legitimate packets because of lack of network connectivity. VII. D ISCUSSION A. Motivation for Deployment The deployment of anti-DDoS capabilities on computers has many potential legal and social incentives for users and organizations. • In case the payment for internet usage is on the basis of bandwidth consumed then the user whose computer is being used as a zombie faces financial losses. Use of anti-DDoS capabilities helps in the avoiding such losses. • If an organization uses systems with anti-DDoS capabilities then it can claim to be network friendly and could demand uninterrupted resources from Internet Servers and Internet Service Providers(ISP) on the basis of the built trust. Remote attestation could be used to prove the use of xen based hypervisors to remote parties. • Use of anti-DDoS capabilities in operating systems could help achieve standards, and ISPs and organizations could require users or other organizations to follows those standards if some services are desired. • User holds the social and legal responsibilities for the network traffic generated by his computer. In future various laws will come up which will hold those organizations, who did not take reasonable steps to secure their systems, responsible for attacks. • The private networks to which the computers belong also suffer form degradation of performance due to the generation of the attack packets. B. Scalability and advantages over edge routers ADVOS capabilities can be cheaply and easily integrated with current operating systems. If this is done people would end up using them. Vendors for commercial operating systems like Microsoft could employ it in there products, leading to a large scale deployment of packet filtering mechanism, helping to combat DDoS. The deployment of filtering technique at host systems allows for better auditing capabilities than those available at the edge-routers, because the edge-routers are constrained in their processing power and there is a substantial increase in queuing delays if all these packets are analyzed. Our architecture allows for a highly distributed defense against DDoS thus enabling the use of processing power on many systems for packet filtering. The filtering at source host also has the advantages of alerting the user of the intrusions on his system and also saving on bandwidth available to the user. C. Practicality and Cost Virtualization is gaining importance at every level of operating systems and it would soon become an integral part of every desktop. Virtualization is being used to provide

live update [18] functionality in systems, which allows users to update system’s kernel with patches without rebooting their systems. It is also being used for checkpointing virtual machine [19] states so that older machine states can be restored in case the user wants to. It has also helped in the development of more sophisticated Host Intrusion Detection Systems (HIDS) based on Virtual Machine Introspection [14]. Virtualization has also been used to develop more reliable logging (and replay) [20] systems and systems resilient against code-injection attacks [21]. All these functionalities improve security [22] and usability tremendously and mandate the use of virtualization as part of every operating system. So the addition of anti-DDoS capabilities to an operating system already using virtualization to address other issues would be without any costs. D. Recuperation Strategies In this section we discuss the various steps that can be taken to provide recovery solutions, and also bring out the limitations these systems would inherit. One of the important questions that needs to be answered is about the recovery of data and other system files from the infection that has occurred. There is a need to cure the system of the infections as quickly as possible. One of the possible solutions would be to checkpoint systems in realtime, which may have other benefits as well, and restore older versions of the system state on the detection of an ongoing attack. Frequency at which checkpointing is done governs the involved computational overheads, disk space needed and ability to restore user data. If a system is found to generate attack traffic then from the generated traffic and using the technique of Virtual Machine Introspection (VMI) [14] it could be possible to identify the exact processes/programs that seem to have malicious intent. If such processes can be identified, this would help provide great details about the worms in action. VMI is the technique of inspecting the memory of guest operating system or other resources from the VMM, with the virtual machine having no knowledge of the undergoing inspection. But it must be kept in mind that any information that is obtained from the monitored host could be tainted so as to mislead detection and recovery. The obtained information may also be damaging and may cause the security of the virtual machine monitor itself to be breached. VIII. F UTURE W ORK Development of better algorithms for analysis could help in improving attack detection, reduce false alarms and remove other limitations that the system suffers from. The filtering designed here is to meet TCP related attacks. Heuristics to deal with other traffic forms will help to enhance the capabilities of the system. DDoS attacks which overwhelm the victims only by legitimate traffic have come up recently, these have been a serious security threat and it is very difficult to deal with such attacks near the victim. At the source computer, closer to the origin

of the attack the possibilities of enhancement in ADVOS to deal with TCP friendly attacks are bright. IX. S UMMARY This paper has described a defense strategy against Distributed Denial of Service attack using virtualization. • A lot of work is being done to address various security problems using virtualization. But all the work done has been to strengthen the security of the host on which it is employed. This paper has been one of the first efforts in bringing out the role of virtualization in strengthening the security of the complete internet infrastructure. • In this paper we have successfully established the benefits of packet filtering at the source computer itself. • We implemented a system-ADVOS to prevent DDoS at the source computer itself. The implementation has been made secure using virtualization technology. • Different models of traffic characterization could possibly be used in curtailing malicious traffic, we justify the effectiveness of symmetry based model at source computers. • The implementation was found to be very efficient and negligible performance overhead was observed. In our prototype over native Linux system 2.4% overhead was observed in the attained network throughput. • We verified the effectiveness of the ADVOS by using a custom DDoS attack tool and it was found to be very effective against different types of attacks. It was able to throttle attack traffic rates to less than 1% of the original values in all cases. X. ACKNOWLEDGMENTS We would like to thank Murtaza J Masalawala and Sambuddho Chakravarty for helping in dealing with the technical difficulties faced during the project. We would also like to thank Pankaj Thakkar from VMware and Chandrakumar Veeraraghavan from Solidcore for the guidance they provided during the course of the project. We acknowledge with thanks the support from National Technical Research Organization (NTRO) for this work. R EFERENCES [1] C. Brenton, “What is Egress Filtering and How can I Implement it?” Feb 2000, the SANS Institute. [Online]. Available: http: //www.sans.org/rr/paper.php?id=1059 [2] B. Dragovic, K. Fraser, S. Hand, T. Harris, A. Ho, I. Pratt, A. Warfield, P. Barham, and R. Neugebauer, “Xen and the art of virtualization,” in Proceedings of the ACM Symposium on Operating Systems Principles, October 2003. [Online]. Available: citeseer.ist.psu.edu/dragovic03xen.html [3] “Xensource,” http://www.xensource.com/products/xen/. [4] C. Kreibich, A. Warfield, J. Crowcroft, S. Hand, and I. Pratt, “Using packet symmetry to curtail malicious traffic,” Proc. ACM HotNets 2005. [5] “Vmware,” http://www.vmware.com/. [6] “Virtual Server,” http://www.microsoft.com/servers/default.mspx. [7] A. Whitaker, M. Shaw, and S. D. Gribble, “Scale and performance in the denali isolation kernel,” SIGOPS Oper. Syst. Rev., vol. 36, no. SI, pp. 195–209, 2002. [Online]. Available: http://portal.acm.org/citation. cfm?id=844147

[8] J. Dike, “A user-mode port of the Linux kernel,” 2000. [Online]. Available: http://www.usenix.org/publications/library/ proceedings/als2000/dike.html [9] C. Douligeris and A. Mitrokotsa, “DDoS attacks and defense mechanisms: classification and state-of-the-art,” vol. 44, no. 5, pp. 643–666, Apr. 2004. [10] T. M. Gil and M. Poletto, “MULTOPS: A Data-Structure for bandwidth attack detection,” pp. 23–38. [Online]. Available: citeseer.ist.psu.edu/ gil01multops.html [11] J. Mirkovic, “D-WARD: Source-end defense against distributed denial-of-service attacks,” Ph.D. dissertation. [Online]. Available: citeseer.ist.psu.edu/mirkovic03dward.html [12] C. L. Schuba, I. V. Krsul, M. G. Kuhn, E. H. Spafford, A. Sundaram, and D. Zamboni, “Analysis of a denial of service attack on TCP,” in Proceedings of the 1997 IEEE Symposium on Security and Privacy, IEEE Computer Society. IEEE Computer Society Press, May 1997, pp. 208–223. [Online]. Available: citeseer.ist.psu.edu/article/ schuba97analysis.html [13] “CHECKPOINT INC. 1996. TCP SYN flooding attack and the firewall1 SYNDefender. CheckPoint Inc..” [14] T. Garfinkel and M. Rosenblum, “A virtual machine introspection based architecture for intrusion detection,” in Proc. Network and Distributed Systems Security Symposium, February 2003. [15] “Xen networking,” http://wiki.xensource.com/xenwiki/XenNetworking. [16] R. Prasad, M. Murray, C. Dovrolis, and K. Claffy, “Bandwidth estimation: Metrics, measurement techniques, and tools,” 2003. [Online]. Available: citeseer.ist.psu.edu/prasad03bandwidth.html [17] A. Menon, A. L. Cox, and W. Zwaenepoel, “Optimizing network virtualization in xen,” in USENIX Annual Technical Conference, May 2006, pp. 15–28. [18] H. Chen, R. Chen, F. Zhang, B. Zang, and P.-C. Yew, “Live updating operating systems using virtualization,” in VEE ’06: Proceedings of the 2nd international conference on Virtual execution environments. New York, NY, USA: ACM Press, 2006, pp. 35–44. [19] A. Cunei and J. Vitek, “A new approach to real-time checkpointing,” in VEE ’06: Proceedings of the 2nd international conference on Virtual execution environments. New York, NY, USA: ACM Press, 2006, pp. 68–77. [20] G. W. Dunlap, S. T. King, S. Cinar, M. A. Basrai, and P. M. Chen, “Revirt: enabling intrusion analysis through virtual-machine logging and replay,” SIGOPS Oper. Syst. Rev., vol. 36, no. SI, pp. 211–224, 2002. [Online]. Available: http://portal.acm.org/citation.cfm?id=844148 [21] W. Hu, J. Hiser, D. Williams, A. Filipi, J. W. Davidson, D. Evans, J. C. Knight, A. Nguyen-Tuong, and J. Rowanhill, “Secure and practical defense against code-injection attacks using software dynamic translation,” in VEE ’06: Proceedings of the 2nd international conference on Virtual execution environments. New York, NY, USA: ACM Press, 2006, pp. 2–12. [22] T. Garfinkel, M. Rosenblum, and D. Boneh, “Flexible os support and applications for trusted computing,” in Proceedings of the 9th Workshop on Hot Topics in Operating Systems (HotOS-VIII), May 2003. [Online]. Available: citeseer.ist.psu.edu/garfinkel03flexible.html