59 CHAPETR 3 DISTRIBUTED DEPLOYMENT OF DDoS DEFENSE SYSTEM 3.1. INTRODUCTION The last decade has seen many prominent DDoS attack on high profile webservers. In order to provide an effective defense against a DDoS attack it is crucial for the defense system to be deployed at critical points in the network where it can quickly identify the onset of a DDoS attack and efficiently differentiate attack traffic from legitimate traffic, to determine the strength or severity of an ongoing attack. DDoS attack detection systems can be broadly categorized as anomaly based detection and signature based detection. In anomaly based detection, a model is developed by training it with information about normal activity. Once trained, the model will be able to identify normal activity and anything that is unidentifiable is flagged as potentially malicious. Anomaly based detection model is capable of identifying new or novel attacks, but has a very high false positive rate and in reality training a defense model for normal behavior is very difficult. Signature based detection searches for frequently occurring pattern in the behavior or payload exhibited by malicious programs. These patterns, also known as rules or signature, are compared against the network traffic.
60 When a pattern is matched, it is reported or flagged as attack. Signature based detection may fail to detect novel attacks, as the pattern of such attacks are unknown. Even with this drawback signature based detection are more popular compared to anomaly based detection. Once an attack has been identified, the Response Model of a defense system can be programmed to execute a predefined set of activities to relieve the impact of the attack on the victim and limit the damage to legitimate clients. Defense system can either be passive or active. A passive defense system will issue an alert and /or log entries in response to the alert. An active defense system may take actions such as drop the packet, send reset packet to the connection, add IP address to the block or filter list and so on. Based on the type of response, defense systems can also be categorized as proactive or reactive defense systems. A proactive defense system attempts to eliminate the possibility of DDoS attacks altogether and failing that, if an attack has initiated, enable target victims to endure the attack without denying services to legitimate clients. A reactive defense system, on the other hand, initiates after the onset of an attack only. It attempts to detect the source(s) of a DDoS attack and the attack stream as early as possible and then quickly alleviate the impact of the attack on the victim. The DDoS network Attack Recognition and Defense (DWARD) system proposed by Mirkovic et al. (2005) is an anomaly based proactive defense system. Some of the drawbacks of the DWARD defense system are discussed below.
61 3.2. DRAWBACKS - DWARD DEFENSE SYSTEM The major limitations of the DWARD defense system proposed by Mirkovic et al. (2005) are the positioning of the defense system in the network, the computational and memory overhead involved and the rate liming strategy. 3.2.1 Source End Defense DWARD is a source end defense which has to be deployed at the exit router of a network and requires wide range of deployment and cooperation between ISPs for the defense system to be effective. DWARD uses a Police Address Set, which is the set of addresses of all machines in the stub network or all customers of an ISP and monitors traffic originating from the source network only. It does not take traffic traversing from other network via the source network into consideration. 3.2.2 Computational Overhead DWARD monitors and logs information about every packet, irrespective of the presence or absence of an attack and updates its aggregate flow and connection flow List continuously. This increases the computational and memory overhead. 3.2.3 Rate Limiting DWARD implements an exponential decrease and linear increase approach to rate limiting similar to TCP congestion control mechanism. When a potential attack is identified it decreases the rate of flow exponentially. If the flow responds to the rate limit by decreasing its transmission rate, the rate limit is increased linearly. In case of false positive alarm legitimate flow is
62 seriously affected since its flow rate is drastically reduced at first and then on positive verification is increased very slowly only. In order to overcome the limitations of the DWARD system proposed by Mirkovic et al. (2005) this thesis proposes a Dynamic DDoS Defense with an adaptive Spin Lock Rate control mechanism (D3SLR) to defend against DDoS flooding attacks. 3.3. DYNAMIC DDoS DEFENSE WITH AN ADAPTIVE SPIN LOCK RATE CONTROL MECHANISM Dynamic DDoS Defense with an adaptive Spin Lock Rate control mechanism is a reactive autonomous defense system which can be installed at any node in the network on the path of a malicious DDoS traffic towards the victim machine. D3SLR identifies such malicious traffic flow towards a target system based on the volume of traffic flowing towards the victim machine and responds to the onset of the attack by rate limiting the malicious traffic passing through that system towards the victim. The proposed D3SLR defense system is based on the fact that a successful DDoS attack requires many susceptible and compromised machines to generate an extremely large volume of malicious traffic capable of overwhelming the target system for a duration long enough to cause sufficient damage to the target system in terms of availability to its legitimate users. 3.4. ASSUMPTION AND DEFINITION The most distinct features of a DDoS attack are 1. The huge volume of malicious traffic generated to overwhelm the victim machine
63 2. The use of relatively minimal number of compromised systems to generate the malicious traffic and 3. High degree of similarity of DDoS attack traffic to legitimate traffic. Under such circumstances, it is much easier to identify a small number of attacking machines generating a large volume of malicious traffic towards a victim machine than to identify and protect individual legitimate connections between source networks and the victim machine. The proposed defense system assumes the presence of a security mechanism at exit routers of a network, to filter all spoofed IP packets with illegitimate IP address. DDoS attack generates a huge volume of traffic without any consideration for the network state and does not decrease its transmission rate even if congestion occurs in the network. Legitimate traffic on the other hand adapts the transmission rate based on the network state. In the absence of any malicious activities at a router, the router has sufficient resources to handle the volume of traffic arriving at its interface. When malicious activities are initiated, they quickly consume all the resources at the router. The time between the launch of malicious activity and the complete consumption of the resources at the router is very small. This necessitates a sensitive response system capable of detecting the onset of an attack within this time frame and deploying an effective defense to protect the resources against the DDoS attack.
64 3.5. LOCATION OF DEFENSE SYSTEM Location of the defense system in the network is one of the crucial factors which influence the efficiency and effectiveness of the proposed system. Location of the DDoS defense system can be at source end, victim end or distributed in intermediate nodes in the network. 3.5.1 Source End Defense Systems Ideally, DDoS attacks should be stopped as close to the sources as possible. Source end DDoS defense has several advantages over intermediate network and victim end defense approaches. It can avoid the overall congestion caused by the DDoS attack in the network, by filtering the attack traffic close to the sources. Also, it will have more resources to deploy compared to the intermediate and victim end defense system since it is monitoring a lower volume of traffic. This facilitates the use of more complex detection and response strategies. However, source end defense also faces many challenges primarily due to attack distribution. In a highly distributed attack like DDoS the number of source networks involved and the hence the number of defense systems required is very high. Also it requires the cooperation of all ISPs for deployment which is virtually impossible to achieve. 3.5.2 Victim End Defense Systems The major advantage of a victim end defense system is the single point of defense. It is usually deployed in the firewall of the victim network to be guarded and does not require the cooperation of others.
65 However placing the defense point close to the victim allows the malicious traffic to pass unhindered through the network affecting all other users. The amount of resources that can be deployed is limited and load to be handled by the defense system is also too high. Also, threat of single point failure is always present. If the defense system is breached, the victim will be totally defenseless. 3.5.3 Distributed Defense Systems Placing the defense system at intermediate points in the network overcomes the problems faced in source and victim end defense systems. In distributed defense systems the number of defense points required is relatively smaller than the source end defense systems. It also avoids the single point of failure threat in the victim end defense system. If one of the defense systems fails the others can still function adequately. The amount of resources required is higher than the source end defense systems, but the load is distributed among more systems than the victim end defense system. The success of the distributed defense system however depends on the effective positioning of the defense system in the network. The number of defense points should be sufficient enough to handle the load when a DDoS attack is going on and large enough to cover all the critical points in the network. 3.6. DISTRIBUTED DEPLOYMENT OF DEFENSE SYSTEM The Cooperative Association for Internet Data Analysis (CAIDA) is a collaborative undertaking among organizations in the commercial, government and research sectors aimed at promoting greater cooperation in
66 the engineering and maintenance of a robust, scalable global Internet infrastructure. CAIDA datasets are primarily used by researchers for scientific analysis of Internet traffic, topology, routing, performance and securityrelated events. The CAIDA "DDoS Attack 2007" Dataset contains approximately one hour of anonymized traffic traces from a DDoS attack on August 4, 2007. Flooding type DDoS attack was launched to block access to the targeted server by consuming computing resources on the server and by consuming all of the bandwidth of the network connecting the server to the Internet. The one-hour trace comprises only of traffic to the victim machine and the responses to the attack from the victim machine. Traffic towards other hosts and payload has been removed. The IP addresses of the hosts were prefix anonymized the network address was kept the same while the host addresses were changed. An analysis of the CAIDA dataset revealed more than 8000 individual source machines involved in the DDoS attack traces. Further analysis of the IP addresses of the dataset revealed the following two independent observations. 1. 39% of the compromised machines involved in the attack were hosts under the control of American Registry for Internet Numbers (ARIN) for North America, 32% from RIPE Network Coordination Centre (RIPE NCC) for Europe, the Middle East and Central Asia and 17% from the Asia-Pacific Network Information Centre (APNIC) for Asia and the Pacific region.
67 2. A breakdown on the IP source address showed that while many of the attackers were individual hosts from different networks, more machines originated from the same network. The result of the observation is shown in Table 3.1. Table 3.1 Compromised Machines In Subnets. Number of compromised host systems per subnet Number of subnets 1 1915 2 to 5 1677 6 to 10 188 11 to 25 106 26 to 50 39 Greater than 50 6 Greater than 100 3 The observations and data from Table 3.1 clearly show that only around 16% of compromised machines originate from subnets having only one compromised host in the subnet. 67% of compromised machines originate from subnets having between 2 to 25 compromised hosts and 17% of compromised machines originate from subnets having more than 26 compromised hosts originating from the same subnets.71% of compromised systems are found in the North American and European continent. Deploying more number of defense systems at these regions will result in more efficient deployment of the proposed architecture.
68 3.7. IMPLEMENTATION OF DEFENSE SYSTEM The proposed Dynamic DDoS Defense with an adaptive Spin Lock Rate control mechanism was implemented in a Linux router in two modules a Network Intrusion Detection System (NIDS) hosting the user level implementation of the attack detection, mitigation and response modules and a Firewall at the kernel level implementation which performs the actual rate limiting on the malicious traffic. Among the broad range of Network Intrusion Prevention and Detection Systems (NIPS and NIDS) available today, Snort is the most favored system among researchers and is used in this thesis for data collection and flood detection. Snort is a free, cross platform, open source light weight NIPS and NIDS, created by Martin Roesch in 1998 and is currently managed by Sourcefire.inc. It can be deployed to monitor TCP / IP networks and can detect a wide variety of suspicious and malicious network activities. Snort can be configured to run in three different modes 1. Sniffer mode in which Snort simply reads the packets off the network and displays them in a continuous stream on the console. 2. Packet Logger mode in which packets are read off the network and logged to disk. 3. Network Intrusion Detection System (NIDS) mode in which Snort analyzes network traffic to find matches against a user defined rule set and performs several possible actions based on what it finds. This mode is very complex and has many configurable options.
69 Snort is capable of performing real time protocol analysis, content searching and matching and can generate real time alerts. Snort combines signature, protocol and anomaly based inspection for identifying malicious events. Snort has a modular plugin architecture for sophisticated behavior analysis. 3.8. SNORT ARCHITECTURE Snort architecture is focused on performance, simplicity and flexibility. Internally, Snort is made up of five major components that are each critical to intrusion detection data acquisition and decoder, preprocessor, detection engine, rule set and an alert / logging module. A simplified representation of the dataflow within Snort is as shown in Figure 3.1. Figure 3.1 Snort Architecture
70 3.8.1 Data Acquisition And Decoder For packet acquisition, Snort uses an external packet capturing library the Libpcap. Libpcap is a popular, platform independent packet analyzer that can intercept and display TCP / IP and other packets being transmitted or received over a network to which the host is attached. The raw captured packets are passed into the packet decoder which translates specific protocol elements into an internal data structure and forwards the packet to the preprocessor. 3.8.2 Preprocessor 1. Examining packets for suspicious activity These types of preprocessors are indispensable in discovering non-signaturebased attacks; and 2. Modifying packets so that the detection engine can properly interpret them and normalizes traffic so that the detection engine can accurately match the signatures. Preprocessor parameters are configured and tuned via the snort.conf file which allows users to add, remove or modify preprocessors as required. 3.8.3 Rule Set Rules are split into two functional sections: the rule header and the rule option. The rule header contains information about the conditions for applying the signature. This includes the Rule Action (alert, log, pass, activate, dynamic, drop, reject and sdrop), Protocol of packet analyzed for
71 suspicious behavior (TCP, UDP, ICMP and IP), Source and Destination IP address / ranges, Source and Destination Ports and the Direction Operator (<>, <-, ->) which indicates the orientation or direction of traffic that the rule applies to. The rule option contains the alert message (specifies the message to be printed along with the alert), content (specifies the keyword(s) to be searched in the packet payload), sid (unique Snort rule identifier), reference (reference to external attack identification systems), priority level and classtype. Classtype categorizes an alert as per default set of Snort attack classes. Classtype related to DDoS are attempted-dos (Attempted Denial of Service), denial-of-service (Detection of Denial of Service) and successful- DoS (Denial of Service). itype, icmp_id and icmp_seq fields of rule options refers to ICMP type, ICMP ID and ICMP sequence value.seq, ACK, flow and flags fields checks for specific TCP sequence number, acknowledgement number, TCP stream reassembly and TCP flag bits. An example of Snort alert is as below: Alert icmp $EXTERNAL_NET any -> $HOME_NET any (msg:"ddos TFN client command BE"; itype:0; icmp_id:456; icmp_seq:0; reference:arachnids,184; classtype:attempted-dos; sid:228; rev:1;) 3.8.4 Detection Engine The detection engine is the primary Snort component. It has two major functions: rules parsing and signature detection. The detection engine builds attack signatures by parsing Snort rules. Snort rules are read line by line and are loaded into an internal data structure, as per their priority. The detection engine runs traffic through the now loaded rule set in the order that it loads them into memory, until the packet either matches an attack signature
72 (the detection engine will trigger the action specified in the rule definition), or tests clean (packet is forwarded). If a malicious activity is detected, Snort writes the intrusion data to the output plugin(s). 3.8.5 Alert / Logging Snort is flexible in the formatting and presentation of output to its manage intrusion data. The purpose of the output plugins is to dump alerting data to another resource or file. The logging module receives the alert and the associated rule that has triggered the alert. It then writes the alert and rule information to a log file or a database. 3.9. SNORT AND DDoS Snort's Vulnerability Research Team has published a set of rules named ddos.rules. This file contains a small set of signatures for detecting the activity caused by older DDoS tools like Tribe Flood Network, Shaft, Trin00 and Stacheldraht. The complete list of rules packaged in ddos.rules is given in Appendix 1. For example, a potential Stacheldraht DDoS detection is based on two signatures that match message strings contained in communication messages sent between attack Agents and their Handler. The Agents send messages to inform the Handler that the Agent machine is alive and ready to the Handler commands the Agents to launch attack requests with a message that contains the string "ficken". Two Snort rules are created to detect the presence of
73 1. alert icmp $EXTERNAL_NET any <> $HOME_NET any (msg:"ddos Stacheldraht agent->handler (skillz)"; content:"skillz"; itype:0; icmp_id:6666; reference:url,staff.washington.edu/dittrich/misc/stacheldraht.an alysis; classtype:attempted-dos; sid:1855; rev:2;) 2. alert icmp $EXTERNAL_NET any <> $HOME_NET any (msg:"ddos Stacheldraht handler->agent (ficken)"; content:"ficken"; itype:0; icmp_id:6667; reference:url,staff.washington.edu/dittrich/misc/stachldraht.anal ysis; classtype:attempted-dos; sid:1856; rev:2;) While Snort signature based rules can effectively protect resources from DDoS related activities it cannot deflect or mitigate bandwidth consumption attacks. When deployed as an offline, passive device, there is little or nothing Snort can do to stop or reduce a bandwidth-consuming flood attack. For example, during a SYN flood attack, Snort can potentially rules packaged in ddos.rules are designed to either detect DDoS Agent command-and-control or possibly identify certain types of attacks that subvert but do not breach a target. When deployed as an inline, active device, Snort acts as a so-called intrusion prevention system and can, in some cases, stop DDoS attacks by identifying and filtering the malicious packet, thereby "protecting" the router. If the intruder switched to a SYN flood or other bandwidth consumption attack against the router, however, Snort would most likely not be able to counter the attack.
74 3.10. SNORT AND D3SLR The steps to install and execute D3SLR as a Snort Plugin Module can be briefly summarized as below: 1. Setting up Snort files a. File snort.conf is configured b. The network being monitored is specified c. The host system name and port number parameter for the rate limiter are configured 2. The D3SLR Flood Detection Preprocessor and Rate Limiting Preprocessor plugin modules are created and placed in the preprocessor directory. 3. The D3SLR preprocessor plugins are integrated with the Snort plugin base programs. 4. Snort system and the rate limiting program are started. The DDoS defense system is launched. 3.11. CONCLUSION The success of the DDoS attack against a defense system and in turn the victim is defined by the volume of legitimate traffic that can be successfully stopped from reaching the target system.d3slr can be implemented at critical points in the network as autonomous distributed defense systems working independently to limit the amount of malicious traffic flowing towards the victim machine and to ensure better service to legitimate traffic even during an ongoing attack. The following chapter discusses the architecture of D3SLR, the DDoS flood attack detection strategy and implementation of the detection component as Snort Flood Detection Preprocessor.