DDoS defense mechanisms: a state of the art research

Transcription

1 DDoS defense mechanisms: a state of the art research C.J.H. Weeïnk c.j.h.weeink@student.utwente.nl ABSTRACT The tools for launching a Distributed Denial-of-Service (DDoS) attack are widely available but there is still a lack of effective mechanisms that defend against such attacks in a reasonable amount of time. This paper presents a research that analyzed the security techniques currently available to reduce the result of DDoS attacks and identifies the technique or combination of techniques that is the most promising. We concluded from our analysis that none of the techniques analyzed fully meet our requirements. A cooperative distributed defense technique with multiple local detection techniques is the most effective. Keywords DDoS, attacks, flooding, defend, traceback, overlay 1. INTRODUCTION With a typical Distributed Denial-of-Service (DDoS) attack, a large number of attacking hosts send useless network packets to crash a victim s computer or to jam his internet connection. If the magnitude of attack traffic is large enough, it has been observed to have noticeable impact in different areas of the Internet [Gar00]. The impact of DDoS attacks has been shown by attacks on Yahoo, CNN, Amazon and several other major sites in February 2000 [Gar00], on GRC.com in January 2002 [Gib02] and on the root DNS servers in In fact, DDoS attacks occur more frequently then reported, because a lot of companies are afraid of bad publicity and more DDoS attacks [GLLR06]. The reason that DDoS attacks occur that frequently is on one hand, the tools for launching a DDoS attack are widely available and on the other hand there still seems to be a lack of effective mechanisms that defend against such attacks in a reasonable amount of time. Therefore, it isn t weird that DDoS attacks are one of the major threats in the Internet and are one of the toughest security problems to solve. This paper presents a state of the art research that analyzes currently used Distributed Denial-of-Service (DDoS) attacks and defense techniques that can be used to prevent or reduce the consequences of such attacks. This is particularly interesting, because no real comparison of different DDoS defense mechanisms can be found in existing literature. The goal of this research is to provide an analysis of security mechanisms currently available to reduce the result of DDoS attacks and to identify which technique or combination of techniques is the most promising for the future. From the goal, we can derive the following research question: Which security methods are currently available to prevent, or reduce, the result of, DDoS attacks and which one is the most promising?. A literature study will be performed to reach the goal. We chose a literature study because this was the most feasible form of research to perform in the amount of time available. Based on the literature, we identify the different types of DDoS attacks that are currently performed and the characteristics of such attacks in general in chapter 2. The DDoS defense mechanisms, that we are going to compare, are listed in chapter 3 along with their advantages and disadvantages. Based on the characteristics from chapter 2, we determine in chapter 4 the requirements DDoS defense mechanisms need to meet in order to offer good protection. In chapter 4 we will also perform an analysis of the previous listed defense mechanisms based on the requirements, their advantages and disadvantages that have been identified earlier. We will conclude this paper with some future topics in chapter 5 and the conclusions in chapter DDOS ATTACKS In this chapter we will describe in section 2.1 how a DDoS attack is constructed in general, then we will discuss different types of DDoS attacks in section 2.2, followed by the characteristics of DDoS attacks in general in section Background In general the DDoS attack network is a hierarchical one. The network contains one or more attacking hosts, a number of handlers and a large number of agents. The attacking hosts are compromised machines that are used for scanning other vulnerable hosts to be added to the network and equip the vulnerable hosts with DDoS attack programs like Trinoo, Tribe Flood Network (TFN), Stacheldraht and Shaft [DM04]. Each attacking host controls a number of handlers, which on their turn control a large number of agents. Handler Attacker Handler Agent Agent Agent Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission. 6th Twente Student Conference on IT, Enschede, 2nd February, 2007 Copyright 2007, University of Twente, Faculty of Electrical Engineering, Mathematics and Computer Science Victim Figure 1. DDoS attack network With the attack network, an attacking host can start an attack by sending an attack command to the handlers. The attack command contains information about the victim and the type

2 and duration of the attack. If the handlers have received the attack command, they will propagate it to the agents, which send the attack data packets to the victim. Currently available DDoS attack tools can launch multiple attacks against multiple victims at the same time and use various types of attack packets. A typical DDoS attack network is listed in Figure 1, a more detailed description of a DDoS attack network can be found in [DLD00]. 2.2 Attack types DDoS attacks can be classified into two categories: bandwidth depletion and resource depletion attacks, according to [ZP04], [DM04] and [DM03]. A bandwidth depletion attack is designed to flood the victim s network with unwanted traffic that prevents legitimate traffic from reaching the victim s system. Bandwidth attacks can be divided in flood attacks and amplification attacks. With flood attacks, attacking hosts send a large amount of traffic directly to the victim in order to jam his internet connection. Instead of sending the attack traffic directly to the victim, amplification attacks use legacy intermediate hosts to amplify and reflect attack traffic for a certain victim [DM04]. Such legacy intermediate hosts are called reflectors and can be any host that returns a packet when it receives one [Pax01]. A resource depletion attack is an attack that is designed to tie up the resources of a victim s system. This type of attack can be divided in protocol exploit attacks and malformed packet attacks. Protocol exploit attacks try to tie up the resources of a victim s system by exploiting a certain feature of a protocol, or a bug in a certain protocol implementation. Malformed packet attacks try to crash a victim s system by sending incorrect data packets. 2.3 Characteristics From the information gathered so far, we are able to extract a couple of general characteristics of DDoS attacks. These characteristics are used in the next chapter to identify the requirements that DDoS defense mechanisms should meet. The most important characteristic of DDoS attacks is that they send a large amount of traffic to the victim, in the hope that the victim cannot handle it and will be overwhelmed. During a DDOS attack, a single agent only sends a small amount of packets which may be small enough not to be marked as suspicious. Because there a large number of agents, together they cause the victim to receive a lot of traffic. For defense mechanisms it is difficult to distinguish attack packets from normal packets, as the amount of packets send to the victim is the only thing that counts. If the packets exploit certain Internet protocols or if they are malformed, it is easier to detect them as are violating certain protocol rules. However, this detection should take place at several nodes in a network, which is hard to do in the Internet. A lot of DDoS attacks use spoofed IP addresses to hide the identity of the attacker or the attacking hosts, or in the case of a reflector attack to specify the victim s address. DDoS attack traffic that has been generated by widely available tools often has some identifying characteristics, which make it possible to perform a statistical analysis on the traffic. But as these tools evolve, they will become more advanced and identifying them will become harder [ZP04]. In comparison with other Internet threats and attacks, like viruses, DDoS attacks do not infiltrate the victim s computer. Rather, they try to overwhelm the network connections of the victim, making the level of defense on the victim s computer irrelevant [GW00]. 3. DDOS DEFENSE MECHANISMS In this section we will discuss the various DDoS defense mechanisms that we will analyze in this paper. For each mechanism a description and its advantages and disadvantages will be listed. While quite a few mechanisms based on IP traceback are available, we won t discuss all of them in this paper because the major drawback of path reconstruction is that a high number of routers have to participate in packet marking. D-WARD [MPR02] extends MULTOPS [GP01] with UDP and ICMP attack detection and is constructed similar as MULTOPS. Because D-WARD can detect a broader range of DDoS attacks and has less collateral damage [MPR02], we will not consider MULTOPS in this paper. 3.1 Secure Overlay Service (SOS) The Secure Overlay Service (SOS) by [KMR04] introduces a secure overlay network around a target to be protected. The target is protected by the network around it, which is aggressively blocking all traffic to the target that hasn t been marked as approved. The list of nodes which are approved by the filter are kept secret, these nodes are the servlets. If a sender wants to send packets to a destination that is protected by a secure overlay network, he must authenticate itself at an access point of the secure overlay network. If the sender is authenticated successfully, the access point routes the packets to a beacon. The only function of a beacon is to route a packet to a servlet known to the beacon or to another beacon if it doesn t know the servlet for the target. A servlet decides, based on a hash function, which beacons are allowed to communicate with it. As a single access point, beacon or secret servlet doesn t provide a strong protection, redundancy should be added to the network. An advantage of this approach is that it is possible for the architecture to heal itself. If a node is attacked, it can exit the overlay and the path determination algorithm will provide a new path in the secure overlay. Another advantage is that it is possible to create a route to the target which isn t known to an external attacker who wants to attack that target. A major disadvantage of this system is that the security of the system is determined at its border. If an attacker manages to authenticate himself successfully at an access point, he can perform a DDoS attack to a victim protected by the secure overlay, because the nodes after an access point assume that the packets they receive are authenticated and are from a valid sender. Another disadvantage is that the path from the sender to the target is rerouted through the nodes in the overlay network. In some cases this can cause the latency to be ten times larger than it would have been in the case of a direct connection [KMR04]. 3.2 Pi The Pi technique described by [YPS03] adds a fingerprint to each data packet of the path traversed through the Internet. Packets that are received via the same path contain the same path fingerprint. While the data packets traverse the Internet, each router they visit updates a certain part of the fingerprint. When the data packets arrive at the victim, a filter checks if the fingerprints are

3 on a packet marking list and drops the marked packets if that is the case. The packet marking list is constructed during a learning phase, where an algorithm running at the victim determines if a certain marking has to be added to the packet marking list or not. An advantage of this technique is that different filters can be implemented and used at the same time, offering protection to different types of attacks. A major disadvantage of this approach is that a lot of nodes in the Internet must be deployed with the packet marking algorithm. Because that means that a lot of network administrators should add this algorithm to their routers, this is unlikely to happen. Another disadvantage of this approach is that a machine close to the victim has to decide which packets should be dropped and which not. If the attack traffic volume is big enough, it will be possible to fill the network connection of that machine. As a result, the level of quality of legitimate traffic will be affected if the number of attackers increases or if the amount of attack traffic increases. A third disadvantage is that the Pi filter doesn t automatically calculate the severity of the attack. If the severity of the attack increases, the victim has to change the acceptance threshold of the filter. If the victim doesn t do this, a lot of legitimate packets will also be dropped. 3.3 D-WARD D-WARD as described by [MPR02] is an autonomous DDoS defense system that filters DDoS attack packets close at the source. In order to offer a good protection, D-WARD needs to be installed on all gateways that connect the deploying network with the Internet. The system monitors the two-way traffic between the deploying network and the Internet, looking for communication difficulties like a reduction in the number of response packets or an increase of the packet arrival times. The observed values are periodically compared with a predefined model. When anomalies are detected, the system will respond by rate limiting the outgoing suspicious flow in proportion to its aggressiveness. If subsequent observation confirms the hypothesis, the rate of the flow will be limited more, if that is not the case the rate will be increased slowly. The quality of flows that are not marked as suspicious will stay at a good level. An advantage of this system is that it offers protection against DDoS attacks both from the Internet to the protected network as from the protected network to the Internet. Another advantage of this system is that it can autonomously run on different nodes, which connect the network to the Internet. That means, that if DDoS attack traffic is routed via different gateways, the D-WARD system has to handle less packets then it would have had if it was processed in a single point of the network. But at the same time this is also a disadvantage in that D- WARD must be deployed at one border router, which is very unlikely in today s Internet structure. Another advantage of this system is that only a small amount (1% - 1.5%) of good traffic is being dropped [MPR02]. However if legitimate connections are made during the beginning of the attack, they may suffer poor quality because the DDoS attack traffic hasn t been limited properly yet. Another disadvantage is that D-WARD can t recognize flooding periods of a pulsing attack as one attack, rather the system sees it as separate attacks. Neither does the system provide good protection against DDoS attacks that use UDP. As the system currently only detects UDP attacks that use spoofed IP addresses or generates high-rate floods. 3.4 Cooperative DDoS detection approach The cooperative DDoS detection approach by [ZP04] describes a technique that uses multiple distributed systems to detect DDoS attacks by looking for anomalies in network traffic profiles constructed by certain algorithms. A single detection node communicates with its neighbors via a gossip-based protocol [GBR02]. The neighbors of a certain node are determined by the overlay network that is constructed. An advantage of this approach is that if one of the detection systems is hit by a DDoS attack itself, the nodes in the network can reorganize themselves in such a way that the attacked detection system is circumvented in the communication. The detection systems are deployed on the gateways that connect the deploying network with the Internet, to monitor a certain part of the network. The system keeps track of destinations whose traffic occupies more than a certain fraction of the capacity of the outgoing link. If a certain detection node detects anomalies in the traffic statistics, it sends the detection information for a certain destination to a couple of neighbor nodes in the overlay network. At any time it will send the information to the node that is on the path to the destination, other nodes will receive the information with a certain probability. An advantage of this technique is that the communication overhead is kept low, while maintaining a high accuracy. Only detection systems that are next on the path to the destination receive the information immediately with a high priority, other nodes receive the same information after a while. Another advantage of this technique is that compromised detection nodes have little impact on the total detection. If a detection node sends malicious information to hide an ongoing attack, only a small number of other nodes will receive this information. As these nodes combine the malicious information with received information from other nodes in the network, the combined information will not trigger the attack notification to other nodes. A disadvantage of this system is that a single detection node doesn t know a lot of the topology of the detection network, it only knows its direct neighbors. If a single node knows more about the topology, the number of messages exchanged can be decreased even more. Another disadvantage of this technique is that it hasn t been tested with real network data yet, only simulations. Therefore, it is unknown how this technique will perform in a real environment. 3.5 IP traceback-based packet filtering The IP traceback-based packet filtering technique by [MJ03] is a technique that uses IP traceback to reconstruct the attack paths to decide which packets should be dropped. A set of upstream routers, which are passed by traffic before the gateway of the victim s network is reached, collaboratively inspect packets going through them. A module running on the victim or on the border gateway of the victim site decides if certain packets are part of a DDoS attack and reconstructs the attack path based on the traceback information in the data packet headers. The module running on the victim, will report the decision to the upstream routers. During the inspection of the data packets

4 passing through these routers, certain packets will be dropped if the path fingerprint matches one of the fingerprints reported from the victim s module. The communication between the module running on the victim and the upstream routers is about 5%. Given today s fast network connections, this is an acceptable fraction and as such, it can be seen as an advantage. While this technique does improve the throughput of legitimate traffic, a lot of legitimate traffic is still being dropped. This is a major disadvantage, as a result one has to use other, more effective techniques combined with this technique to provide an effective defense. Another major disadvantage of this technique is that it requires a lot of Internet routers to participate in the path marking of the packets, just like the Pi method mentioned previously. 3.6 Pushback The Pushback technique, as discussed by [IB02], is a technique where routers work together to handle the congestion created by DDoS attacks by applying rate limits on links going to congested routers. If the Pushback algorithm detects congestion on an outgoing link from the router it is running on, it will apply a rate limit to that link and drop packets that satisfy the congestion signature. At the same time, information about traffic that matches the signature, will be send to upstream routers telling them to rate-limit that traffic. The major advantage of Pushback is that it tries to prevent scarce upstream bandwidth from being wasted on packets that will be dropped downstream. In order to do so, Pushback can control the rate-limit itself. If it finds congestion on a link, it will ask the other routers to apply a rate limit, but if the congestion is gone, it will send a cancel message to the routers on the incoming links. Another advantage of this technique is that at each round only one message is send to each router that has an outgoing connection to the router that is the sender of the message. Because the messages could also be sent from nodes other than neighboring routers, these messages are secured via a TTL number of 255. This is sufficient, because any message coming from an attacker will have a lower TTL. If an attacker has compromised a router, there are more serious concerns to be resolved. A disadvantage of this technique is that a certain number of routers should be deployed with it. If a router doesn t have Pushback deployed, it will discard the Pushback messages. As a result, it doesn t put a rate limit on its outgoing connection, something where the sender of the message did ask for. Another disadvantage is that administrators of network domains have to create an agreement on how Pushback between their domains has to be realized in order to provide a more effective defense. 4. ANALISYS In this section we will analyze the DDoS defense mechanisms introduced in section 3. In section 4.1 we will determine the requirements which the techniques have to meet in order to be effective. In section 4.2 we will discuss all the DDoS defense mechanisms described in chapter 3 based on the requirements. We conclude this section by a comparison of the best technique or combination of techniques. 4.1 Requirements In order for a DDoS defense mechanism to be effective, it should meet a couple of requirements. Based on the characteristics of DDoS attacks discussed in section 2.2, we will discuss the requirements for DDoS defense mechanisms in this section. The major requirement that an effective DDoS defense mechanism should meet, is that it should be able to reduce the attack traffic volume to such a level that it becomes manageable again. This requirement is very important because, if DDoS defense mechanisms don t reduce the attack volume enough, the victim will still have problems coping with the huge amount of traffic. Another major requirement is that the false ratios should be low. If the false positives ratio is high, a lot of legitimate packets will be recognized as being attack packets and will be dropped. If the false negatives ratio is high, a lot of attack packets will be recognized as being legitimate traffic and will still be sent to the victim. It is important to keep these values as low as possible in order to provide a good quality of service to legitimate clients. The third requirement is that the performance impact should be low. This includes both the time it takes to process a packet, as well as the resources needed to perform the processing. We included this as a requirement, because a defense mechanism may be very good, but if it takes very long to process a packet, the victim can t provide a good service. The fourth requirement is that not most or all routers in a network should be deployed with the defense mechanism. A subset of all the routers in a network must be able to provide an effective defense. In our opinion this is an important requirement as it is infeasible to equip all routers with a certain defense structure for a couple of reasons. The most important reason is that it is unlikely that administrators of connected network domains are going to create an agreement on how a DDoS defense mechanism between their domains has to be realized, due to the fact that they would have to create an agreement for each connected network. The final requirement is that the DDoS defense mechanism must be transparent to users. This means that legitimate clients must not have to manually perform an action in order to have their data be recognized by the system. Neither should the network administrators have to configure the defense mechanism again after or at the beginning of a DDoS attack, as this would be too time consuming. 4.2 Mechanisms We will now discuss all the DDoS defense mechanisms described in chapter 3 based on the requirements described in the previous section Secure Overlay Service (SOS) The Secure Overlay Service (SOS) described in [KMR04] reduces the attack traffic very good if the attacker is outside the SOS network. If a packet hasn t been authenticated on an access point, it will be dropped on all overlay nodes. However, if an attacker managed to authenticate himself to the access point, all his packets are sent to the victim without any filtering. In that case the number of false negatives is very high. Also, if the number of the different types of overlay nodes is small, an attacker can easily prevent legitimate traffic from reaching the target by successfully attacking any of these nodes.

5 The performance impact of the overlay network on the data packets is quite high compared to a direct connection, the latency increases by a factor The latency of a packet is determined by the number of nodes participating in the SOS, the speed of the links between the different nodes, and the number of hops a packet has to take. Combined, these factors make it possible that the latency of packets can become very high. However, if shortcuts are used in the routing algorithm, it is possible to decrease the latency to about a factor of 2. The performance of the healing capability of the network is quite good however. If a couple of nodes are under attack and leave the network, the network can recover itself in about 10 seconds. As stated before, the more nodes in the network, the better the protection will be. This however will also lead to an increased latency, as we saw before. Because the overlay nodes don t have to be routers necessarily, the deployment of SOS is not restricted to a certain number of nodes and can be determined by the administrator of the network domain. The only requirement on the deployment, is that the nodes should be located as close to the Internet core as possible, because higher speeds can then be achieved. Maintenance of the overlay nodes is easy to perform, as one can simply take down a certain node, as the overlay will recover itself. The transparency of the system is a different story however. Where the victim only needs to configure a couple of routers so that they accept traffic from a couple of servlets and drop the rest, clients of the victim s service need to authenticate them. Depending on the type of authentication used, it may require a lot of user intervention Pi The Pi technique described in [YPS03] doesn t reduce the traffic that good. A packet is only dropped if its identifier is on a packet marking list, otherwise it is allowed to pass to the victim. The packet marking list is constructed during a learning phase, so if an attacker starts sending attack traffic after the learning phase, the attack packets will still be received by the victim. Because the Pi marking algorithm overwrites a couple of bits of the IP Identification field in the packet s IP header, the attacker should at least be a certain number of hops away, to make sure that all bits in the IP Identification field have been overwritten. If an attacker is less than that number of hops away, some of the bits provided by the attacker make it to the victim, allowing the attacker to use markings that are not on the list. If one of those two conditions is met, too much attack traffic is seen as legitimate traffic, which doesn t comply with our requirement that the false ratios should be low. The performance impact of this technique is quite low, so this does meet our requirements. Each router that has to update a small number of bits of the IP Identification field just has to execute a small number of bit-wise operations. The performance impact at the victim or its gateway is also quite low, as it just has to iterate through the packet marking list to see if a certain packet should be dropped or not. Our deployment requirement isn t met either. This technique requires a lot of routers to participate, if less than half of all routers participate, the performance is too low to be effective [YPS03]. If a lot of routers participate, the performance doesn t improve that much either. This is due to the probability that a certain bit of the IP Identification field is overwritten by a router has been written before by another router. If the number of routers increases, this probability also increases. Neither is this technique very transparent to users and network administrators. The victim first has to go through a learning phase in which it has to determine which packets may pass and which not. The network administrators also have to specify a couple of settings at each router. These settings include the number of bits that are written, and at which router the marking should stop (by specifying the minimum number of routers there should be between the victim and the last router to mark the packet). The number of bits written at each router should also be the same on all routers that participate in this technique D-WARD The D-WARD technique described in [MPR02] reduces the attack traffic volume very well. During the beginning of an attack, a lot of attack traffic will still make it to the victim, because D-WARD is still gathering statistics of the attack traffic. However, during this phase it does already reduce the volume a bit based on the amount of traffic received so far. If the newly gathered statistics confirm the attack again, the attack flow will be reduced very fast. Due to the detection phase at the beginning of an attack, a lot of attack traffic will not yet be detected being attack traffic in the beginning. So in the beginning of an attack, it doesn t meet our requirement of low false ratios. A couple of seconds after the beginning of an attack, if the detection phase has ended, the ratios will be at an acceptable level around 1%. However, if a protocol contains a lot of asymmetry, like UDP does, it is harder for D-WARD to detect an attack, as a result more attack traffic will reach the victim than it would have with more symmetric protocols. As a result we can say that it doesn t meet the requirement as it fails at a couple of important points. The impact of the performance does meet our requirements. The latency added by this technique is in the range of a couple of milliseconds and the memory usage is less than a couple of megabytes, even during heavy attacks. Because this technique has to see all traffic that passes along, it has to be deployed on the border routers of the network. Because D-WARD runs autonomously on a single router and doesn t contain the ability to cooperate with other D-WARD systems, there is a problem deploying this technique in today s networks as most of them have multiple gateways. Nonetheless, D-WARD doesn t require a lot of routers participating in the defense and as such it does meet our requirement. D-WARD does also meet our final requirement that it should be transparent to users. The administrator of the deploying network domain only has to specify the set of IP addresses that should be protected Cooperative DDoS detection approach The Cooperative DDoS detection approach described in [ZP04] reduces the attack traffic quite well. Just as the D-WARD technique described above, this technique also has a detection phase in which it gathers statistics about the attack. If a certain node detects an attack, it will start to take counter measures and in about a minute more nodes will start to do the same so that the attack traffic rapidly reduces. Again, during the detection phase a lot of attack packets will still make it to the victim. If the detection phase is over however, not much packets will be incorrectly marked because of the cooperative element. This does meet our requirement that the false ratios should be low. The performance impact is also quite low. During a DDoS attack the nodes exchanges a small amount of messages each

6 round. If a node detects a DDoS attack, it will directly send a message to its neighbor nodes on the path to the victim. All other neighbors will receive the same message immediately with a certain probability. The latency added by the detection algorithm depends on the algorithm used, but we assume that an algorithm will be chosen that only requires a small amount of time and resources. Based on this assumption, we can say that the performance requirement is met by this technique. Because this technique uses an overlay network, not every router in the network has to be deployed with a detection system, so it does meet our deployment requirement. Because the nodes of the overlay don t have to be physical neighbors and because they use their own protocol, legacy routers don t provide any difficulties for the deployment. This technique is also very transparent. The only thing that has to be configured on a node is the set of addresses that form the neighbors of a certain node. So it does also meet our final requirement IP traceback-based packet filtering The IP traceback-based packet filtering technique in [MJ03] reduces the attack traffic quite good too. Because the module on the victim reconstructs the attack path and reports this path to be blocked to the upstream routers if a DDoS attack is being detected, legitimate traffic traveling via those paths will also suffer a lot of collateral damage. Because of the collateral damage, a lot of legitimate packets will be detected as being attack traffic, which increases the false negative ratio. As a result, it doesn t meet our requirement that the false ratios should be low. The performance of this system is not that bad anyway. Just 5% of the available bandwidth is used for communication between the different modules, resulting in a slightly slower attack path reconstruction that normally would happen in an IP traceback algorithm. Because packets are dropped if they are not in a list, the performance of the filtering algorithm in the upper stream routers is good too, meeting our requirement. The deployment of this technique is also a problem just like the Pi technique described in section Because the module running on the victim s site has to reconstruct the path, a lot of routers need to participate in marking the packets. Otherwise a lot of so-called gaps will occur in the mark, allowing the attacker to have influence in the decision to drop a packet or not. So our deployment requirement isn t met either. Neither does this technique meet our transparency requirement, as a user has to specify the markings that should be blocked Pushback The Pushback technique described in [IB02] reduces the attack traffic quite good. However, if the attacking hosts are distributed equally across the different incoming links, Pushback can hardly tell the difference between legitimate and attack packets, increasing the false positives ratio. As a result it doesn t meet our requirement that the false ratios should be low. The performance impact on the other hand is very low. Because Pushback was implemented on a software router, a lot of the actions happened at kernel level. As a result, the performance wasn t degraded very much. On a hardware router the performance can be a lot worse, because traffic is handled on a couple of fast-switching paths. One can overcome this problem by using the information report functionality which is built into a lot of routers already, a dedicated machine can then execute the Pushback algorithm. Assuming that hardware routers use a dedicated machine to execute this technique, it does meet our requirement that the performance impact should be low. The deployment of this technique is a bit problematic, because Pushback requires a lot of routers to participate. If a lot of routers participate, the rate-limiting and dropping of packets can happen as far from the victim as possible. Otherwise it might be possible that Pushback lowers the quality of its connection with the Internet. Because Pushback basically requires all routers to be deployed with it, it doesn t meet our deployment requirement. 4.3 Comparison Based on the information discussed in section 4.2, we can conclude that none of the techniques listed fully meet our requirements. Techniques like Pi, IP traceback-based packet filtering and Pushback, require a lot of routers to participate in the defense in order to be effective. Such techniques are unlikely to be deployed in practice, because that would mean that a lot of network domain administrators would have to create agreements how the techniques between their domains have to be realized, in order to provide an effective defense. Techniques that rely on a single authentication point, like SOS, are also unlikely to be deployed, because if an attacker manages to authenticate himself, all his traffic will be assumed as being legitimate and will make it to the victim. On the other hand, techniques that build large-scale, selforganizing and resilient overlay networks on top of the Internet, can deliver attack information with speed and reliability between the nodes of the overlay network [ZP04]. In today s networks, finding a larger network with a single entry point is very rare. As a consequence, detection mechanisms that only autonomously run on a single access point and inspect the data they receive are very error prone because they can t get a total view of all the traffic going in and out [MPR02]. A single detection point is also an easy target for attackers. If they manage to successfully attack it, the defense of the whole network will be gone. That s why it is better to have a distributed defense system that is deployed on different points in the network, as it can also cover diverse choices of agents and victims [MR04]. If nodes of the distributed system also have the possibility to communicate with each other, errors will be reduced even more [ZP04]. Based on this information, a technique that would fulfill most of the requirements will be a cooperative distributed defense mechanism, like the Cooperative DDoS detection approach, that uses multiple lightweight local detection techniques, like D- WARD. The Cooperative DDoS detection approach hasn t been tested in practice yet, so it is possible that it doesn t perform that good as it did in the simulations. Even if it doesn t perform that well in practice, a cooperative distributed defense mechanism is still the best solution, as we pointed out above. The D-WARD technique on the other hand has a problem with asymmetric protocols. Because we recommend using multiple lightweight local detection techniques, it s necessary to add a technique which doesn t have this problem, in order to make an effective local detection technique. 5. FUTURE WORK In this section we will discuss the items that we can expect to happen in the future related to the techniques and attacks discussed in this paper. While attackers don t sit still and keep evolving their tools, researchers don t sit still either. As we discussed in this paper,

7 not all techniques were tested in a realistic environment, while a couple of techniques used traces recorded during network traffic experiments, others were tested with small-scale experiments. However, no large-scale test beds are currently available to perform an extensive analysis. But it is possible that this will change in the near future, as the US National Science Foundation is currently funding development of a large-scale cyber security test bed and has sponsored research efforts to design measurement methodology for security systems evaluation [MR04]. Such a test bed also enables a more thorough analysis of DDoS defense methods, because it is then possible to compare the performance of the different methods in the same environment. The techniques we discussed here, also require some further research. For example, the Cooperative DDoS detection approach has only been tested on simulations. While the results are quite promising, it hasn t been tested in practice yet, further research is needed to see if it works in practice. The D-WARD technique also needs further research as it can t properly handle asymmetry that might occur, at the beginning of an attack or in legitimate UDP traffic. 6. CONCLUSIONS The goal of this research was to analyze the security mechanisms currently available to reduce the result of DDoS attacks and to identify which technique or combination of techniques is the most promising for the future. We first identified a couple of DDoS defense mechanisms available and discussed them with their advantages and disadvantages in chapter 3. Based on the requirements DDoS defense mechanisms should fulfill, we performed an analysis in chapter 4. The conclusion we draw from our analysis in chapter 4, is that none of the techniques listed fully meet our requirements. As a result a combination of different mechanisms should be used in order to meet our requirements from section 4.1. From the comparison in section 4.3 we learned that a cooperative distributed defense mechanism is the most effective for defending against DDoS attacks. The new technique should consist of the Cooperative DDoS detection approach, which uses multiple lightweight local detection techniques, like D- WARD. However, both of these techniques still require an amount of future research as we described in chapter 5. To conclude, as long as the defense of computers in the Internet will be bad, it will be possible to perform DDoS attacks [GW00]. While it is hard to achieve a completely safe Internet, all small pieces can make a difference. While a couple of DDoS defense mechanisms can be deployed very easily, it isn t completely free of problems as we have shown in this paper. Most of these problems arise from the fact that the Internet is deployed as a lot of small networks maintained by different companies in different countries. REFERENCES [Gar00] L. Garber, Denial-of-service attacks rip the internet, Computer, vol. 33:4, pp , [Gib02] S. Gibson, Distributed Reflection Denial of Service: Description and Analysis of a Potent, Increasingly Prevalent, and Worrisome Internet Attack, February 22, 2002, Retrieved September 17, 2006, from [GLLR06] L. A. Gordon, M. P. Loeb, W. Lucyshyn, and R. Richardson, 2006 CSI/FBI Computer Crime and Security Survey, Computer Security Institute [DM04] C. Douligeris and A. Mitrokotsa, DDoS attacks and defense mechanisms: classification and state-of-theart, Computer Networks, vol. 44:5, pp , [DLD00] S. Dietrich, N. Long, and D. Dittrich, Analyzing Distributed Denial of Service Tools: The Shaft Case, in Proceedings of the 14th USENIX Conference on System Administration, New Orleans, Louisiana, United States of America, 2000, pp [DM03] C. Douligeris and A. Mitrokotsa, DDoS attacks and defense mechanisms: a classification, in Proceedings of the 3rd IEEE International Symposium on Signal Processing and Information Technology, Darmstadt, Germany, 2003, pp [Pax01] V. Paxson, An analysis of using reflectors for distributed denial-of-service attacks, ACM Computer Communications Review, vol. 31:3, pp , [ZP04] G. Zhang and M. Parashar, Cooperative Mechanisms for Protection against Distributed Network Attacks, p. 14, [GW00] X. Geng and A. B. Whinston, Defeating distributed denial of service attacks, IT Professional, vol. 2:4, pp , [MPR02] J. Mirkovic, G. Prier, and P. Reiher, Attacking DDoS at the source, in Proceedings of the 10th IEEE International Conference on Network Protocols, Paris, France, 2002, pp [GP01] T. M. Gil and M. Poletto, MULTOPS: a datastructure for bandwidth attack detection, in Proceedings of the 10th USENIX Security Symposium, Washington, D.C., United States of America, 2001, pp [KMR04] A. D. Keromytis, V. Misra, and D. Rubenstein, SOS: an architecture for mitigating DDoS attacks, IEEE Journal on Selected Areas in Communications, vol. 22:1, pp , [YPS03] A. Yaar, A. Perrig, and D. Song, Pi: a path identification mechanism to defend against DDoS attacks, in Proceedings of the 2003 IEEE Symposium on Security and Privacy, Berkeley, California, United States of America, 2003, pp [GBR02] I. Gupta, K. P. Birman, and R. van Renesse, Fighting fire with fire: using randomized gossip to combat stochastic scalability limits, Special Issue Journal Quality and Reliability Engineering International: Secure, Reliable Computer and Network Systems, vol. 18:3, pp , May/June [MJ03] [IB02] S. Minho and X. Jun, IP traceback-based intelligent packet filtering: a novel technique for defending against Internet DDoS attacks, IEEE Transactions on Parallel and Distributed Systems, vol. 14:9, pp , J. Ioannidis and S. M. Bellovin, Implementing Pushback: Router-Based Defense Against DDoS Attacks, in Proceedings of the 9th Symposium of Network and Distributed Systems Security, San Diego, California, United States of America, [MR04] J. Mirkovic and P. Reiher, A taxonomy of DDoS attack and DDoS defense mechanisms, SIGCOMM Computer Communication Review, vol. 34:2, pp , 2004.