Recent Development in DDoS research Jose Costa-Requena Helsinki University of Technology Networking Laboratory
[email protected] Abstract This paper presents the recent development against the Distributed Denial of Service (DDoS) attacks. The problem of detecting a traffic flow, as part of a Distributed Denial of Service attack, is rather difficult since it can be hidden and considered as normal Internet traffic. This document enlightens current techniques to avoid the DDoS actions. The existing research to detect a traffic pattern of a Denial of Service (DoS) flow is also described. Finally, the document examines different techniques for minimizing the impact of the DDoS attack. These techniques try to find the origin of the cause using existing traced back methods. Keywords: DDoS, Firewall, Flow, Trace back, IP spoofing.
1
Introduction
The Internet was originally designed for openness and flexibility, not for security. It was engineered to be robust against network failure. The Internet can automatically re-route network traffic concerning problems in connecting systems, and bypassing nodes to keep the network functioning. At the beginning, the key of the Internet was to connect research centres to create a collaborative research consortium where everybody knew and trusted each other. Unfortunately, this initial open-architecture creates security breaches in current networks. A good example of the security weakness is the basic Denial of Service (DoS) attack. The goal of the DoS attack is not to gain unauthorised access to machines or data, but to prevent users from using their legitimate service. The attack can be performed in many ways. It can be done sending large volumes of data to oversupply the resources or manipulating the data in transit to derive an inoperative service. The former version of the DoS attack derives in an overflow, which blocks the network connections and disrupts the normal functioning to the real users. The latter case can be considered as "a man in the middle" attack. In this case, the attacker modifies the original data coming from a real user either to obtain the security credentials, or just to force an unusable service by altering the original information. This attack can be performed at any point in the path between the user and the destination, or just at the source of the message delivery. This attack is executed at the source using malicious-code resident in the real-user terminal. On the other hand, a more sophisticated version of the DoS attack is widely extended. It is called Distributed Denial of Service (DDoS) attack. It is a difficult problem to solve
HUT TML 2001
T-110.501 Seminar on Network Security
because of its multiple and unexpected origins. The DDoS attack consists of launching multiple DoS attacks from several origins. The attacks can be initiated even without the knowledge of the real user. The malicious code that performs the "man in the middle" and the DDoS attacks includes Trojan horses, viruses, worms, logic bombs, and so on. The code is usually hidden in standard programs or files that attackers modify to allocate the inappropriate code. The undesired code is run and spread with or without user intervention, and it is installed in many unlucky new terminals inadvertently. Therefore, under an intelligent design these malicious programs will perform new attacks to common sources spreading the problem to other users. As it was mentioned, the attack can also be performed from a single origin using IP spoofing addresses. The only means to improve the security against the DDoS attack is detecting the mess as soon as possible and taking the pertinent actions. The problem with DDoS attack resides in the difficulty to distinguish a legitimate traffic from an attack. Therefore, this paper proposes a mechanism to detect a DDoS attack on its early state. Additionally, a flexible strategy is needed to follow the changing environment and keep permanent vigilance. After detecting the minimum sign of a potential DDoS attack, the strategy has to manage a well-defined policy and procedures to trace back the origin of the attack. It has to verify if it is a real attack, and in that case execute a robust defence to avoid it. The available strategies try to recognise the traffic flow and identify the DDoS pattern from the normal IP flow to immediately initiate the attack control and defence. The Internet community needs to be organised against these attacks. Otherwise, the Internet world would suffer from the lack of security and its credibility as a platform for future services. An example of a simple and terrible attack was reported in the "Network World Fusion" [1] where a 15-year-old hacker lay down for few hours the CNN web site. He apparently triggered the attacks by manipulating compromised servers at universities and elsewhere which were infected with the DDoS attack code. The following sections describe the DDoS attack as well as the current mechanism for detecting and solving the attack. Finally, the conclusions for further discussion and future work are pointed out.
2
The DDoS attacks
This section describes the basis of the DDoS attack, analyses the main problems, and explains the cause of DDoS attacks [2]. The starting point of the DDoS attack resides in the big success of the Internet and its vulnerable characteristics. People use Internet for everything all the time more. Therefore, Internet is becoming a de facto technology being deployed worldwide and extended to the wireless environment. Currently there are millions of vulnerable systems connected to the Internet [3]. Systems are formed by open-machines that can be easy and simple targets for any intruder. The intruder takes the advantage of the Internet powder to exploit its own weaknesses and overcome defences.
2
HUT TML 2001
T-110.501 Seminar on Network Security
Due to the enormous market competition, many organisations sacrifice the security of their software products for getting them ready in the market as quickly as possible. This behaviour brings up many products that do not control and act properly against security attacks. Unfortunately, users are more interested in software with new features than in very well protected software. The industry has to answer to the users' demand offering software that is easily a target for computer viruses, data theft, and source for originating DDoS attacks [4]. New technologies and effective tools, in combination with the explosion of using the Internet worldwide, make the attacks easily realisable from multiple sites, and even in coordination with several intruders simultaneously. The number of directly connected homes, schools, libraries and other public entities, without trained system administration and security staff, is rapidly increasing [5]. These badly protected systems allow intruders to set down their seeds to be ready when they decide to initiate a DDoS attack. Hence, the DDoS is a problem that does not have an easy solution due to the public and insecure nature of Internet. It is a paradise for the attackers to set a wide mesh of "Zombies". This concept identifies any computer system infiltrated by hackers for the purpose of launching DoS attacks. Once a hacker gains the control of a "zombie", she installs a daemon program that listening to the requests starts or stops attacks against a victim (Figure 1). Due to the weakness in many systems over Internet, a hacker can be in charge of many zombies and -controlling them remotely- can launch huge attacks making difficult to the authorities to track the hacker's real location.
VICTIM
ZOMBIE
ZOMBIE
ZOMBIE
ZOMBIE ZOMBIE
HACKER
(1)To perform the attack, the Hacker can send directly the commands to the zombies. (2) The attack can be run using an intermediary zombie, which will flood the commands to the rest of the zombies on the network. The second procedure is more effective than the first one, and it makes more difficult to traceback the Hacker.
Figure 1: Using zombies for performing a DDoS attack
3
HUT TML 2001
2.1
T-110.501 Seminar on Network Security
Type of DDoS attacks
This section presents and defines some of the most common attacks [3]. There are a few common attack methods known by all the communities. They can be easily solved getting the latest patches to the Operating Systems (OS) and Firewalls. These methods can be divided in two categories: Flood Attack and Malformed Packet Attack.
2.1.1 Flood Attack The flood attack is a common type of DoS attacks that aim to saturate the bandwidth of a network link or crash network devices such as routers or switches. As the name reveal, a flood attack consists of attacking a victim with more traffic than the victim or its network is able to handle. To succeed, it does not require complex tools and there are several protocols that can be used to launch this kind of attack. There are different types of flood attacks: •
Smurf Flood Attack is a common DDoS attack known as a reflector attack. An attacker sends a relatively small number of Internet Control Message Protocol (ICMP) echo packets to a broadcast address that defines a set of several machines (potentially hundreds). Those ICMP echo packets are broadcast to known vulnerable networks. As it was explained in the above paragraph, there are plenty of systems with minimum secure requirements. Thus, all those systems reply to the victim with ICMP echo replies. This rapidly exhausts the bandwidth available for the target denying its services to legitimate users. A Fraggle attack is identical to a smurf attack but it uses User Datagram Protocol (UDP) echo packets rather than ICMP echo packets.
•
TCP SYN Flood Attack takes the advantage of the flaw of the Transmission Control Protocol (TCP) three-way handshaking behaviour. To set up a normal TCP connection, the source (client) first sends a SYN packet to the destination (server); the destination acknowledges by sending back a SYN ACK packet, and waits for the source to send a final ACK packet. The attacker makes connection requests at the victim server with packets with unreachable source addresses. The victim will then reply with SYN ACK packets, and will wait in vain for a few minutes for ACK packets from the fake addresses. Thus, the server is not able to complete the connection request and the victim wastes all of its network resources. A relatively small flood of bogus packets will tie up memory, CPU, and applications, resulting in shutting down a server.
•
UDP Flood Attack (Fraggle) is possible when an attacker sends a UDP packet to a random port on the victim system. UDP is a connectionless protocol and it does not require any connection setup procedure to transfer data. When the victim system receives a UDP packet, it will determine what application is waiting on the destination port. When it realises that there is no application that is waiting on the port, it will generate an ICMP packet of destination unreachable to the forged source address. If enough UDP packets are delivered to ports on victim, the system will go down. It is a relatively common attack, and can be made more difficult to filter or trace through the use of spoofed source addresses.
4
HUT TML 2001
•
T-110.501 Seminar on Network Security
ICMP Flood Attack consists of an attacker sending a huge number of ICMP echo request packets to the victim and, as a result, the victim cannot respond promptly since the volume of request packets is high and have difficulty in processing all requests and responses rapidly. The attack will cause the performance degradation or system down.
From this attacks some of them, such as the ICMP flood attack and the Smurf flood attack are similar and they can be fixed adding the pertinent software patches. The UDP flood is more difficult to defend since there are multiple applications running on UDP listening to their own ports. Thus, those applications are a target for this attack and it cannot be solved unless additional security procedure is implemented for checking the incoming packets. Nevertheless, including an additional security checking implies that it has to be light to avoid overhead to recognise the wrong messages.
2.1.2 Malformed Packet Attack The malformed packet attack is another wide spread type of DoS attacks. It aims to exhausts the networks resources by sending a bunch of packets that will launch several processes in the computers to process their content. These attacks overload the victim with packets of no use but that have to be processed consuming the resources. There are different types of malformed packet attacks: •
Ping of Death Attack. An attacker sends an ICMP echo request packet that is much larger than the maximum IP packet size (64KB) to the victim. Since the received ICMP echo request packet is bigger than the normal IP packet size, the victim cannot reassemble the packets. This causes the OS may be crashed or rebooted as a result. It also makes certain TCP/IP implementations to fail -notably, those of Windows 95 and NT-, crashing the server that they are running on.
•
Chargen Attack is a variant of UDP Flood Attack explained in section 2.1.1. The attacker sends forged UDP echo request packets to intermediary system's UDP port 19 (chargen). Then the system receives the packets on its chargen service port and responds by generating a string of characters to the victim system. The victim system receives the packets on its echo service port and responds back to the chargen service system with an echo of the character string. Once this loop begins then the loop rapidly exhausts the bandwidth between the victim and the intermediary system.
•
TearDrop Attack. An attacker sends two fragments that cannot be reassembled properly. The packets have the offset value manipulated, causing reboot or halt of the victim system. There are many other variants such as targa, SYNdrop, Boink, Nestea Bonk, TearDrop2 and NewTear.
•
Land Attack. An attacker sends a forged packet with the same source and destination IP address. The victim system will be confused and crashed or rebooted.
•
WinNuke Attack. Attackers send Out-of-band data to a specific port on Windows machine and the data cause a system crash.
5
HUT TML 2001
3
T-110.501 Seminar on Network Security
Solutions for the DDoS attacks
This section describes possible solutions for the DoS attacks based on IP Trace back and Firewalls filtering [7]. The DoS attacks can result in significant losses for many private entities and organizations. The solutions against DDoS attacks can be divided in prevention and response measures.
3.1
Prevention measures
These measures consist of establishing a set of tools and mechanisms to avoid the attack. Some of the current guidelines are listed [7]. •
Implementing router filters [8]. The solution would be to apply ingress filters to each customer to allow only those packets with source addresses within the customer assigned netblocks. Apply also filters to all the upstream flows. Those filters can be egress and ingress. The former allows to transverse packets with source addresses within the local network to protect other users. This will prevent users on the local network from effectively launching certain DoS attacks. The latter filter denies those packets with source addresses within the local network. Those ingress/egress routers filtering are defined as a way to use routers to defend against DDoS attacks in the Internet Standard RFC 2267.
•
Defining a set of control lists to prevent ICMP echo requests to enter the local network, disable directed broadcasts and turn off the replies for ICMP echoes to broadcast addresses.
•
Disabling any unused or unneeded network services. This can limit the ability of an intruder to take advantage of those services to execute a DoS attack over them. Basically, it means to limit the set of services that are required and disable the rest since they are not used, and can become a potential target for a DDoS attack.
•
Defining a handshake mechanism for ensuring the authenticity of the incoming requests. This section relates to the problem of DDoS attacks in e-commerce sites that implement Transport Layer Security (TLS). The Secure Sockets Layer (SSL)/TLS protocol allows the client to request the server to perform a RSA decryption that implies a costly operation. Thus, if a partial SSL handshake takes 200 bytes, then 800Kb/s is sufficient to paralyze an e-commerce site. There are some proposals to solve this DoS attack using puzzles [9]. The client puzzle is used to slow down the attacker sufficiently so that a DoS is not longer possible.
•
Identifying the potential weakness of the OSs by classifying the potential points that can be targeted for DDoS attacks. Based on these classifications, the purpose is to separate critical functions from other activity that can suffer any attack more often. It has to be identified the set of machines that can be placed into service quickly in the event that an attack is performed, the system is disabled and certain machines have to be replaced. Furthermore, it has to be defined a redundant and fault-tolerant network configurations. It needs to be established and maintain regular backup schedules and policies, particularly for important configuration information.
6
HUT TML 2001
•
T-110.501 Seminar on Network Security
Observing the system performance and establishing baselines for ordinary activity. The baseline is used to measure unusual levels of disk activity, CPU usage, or network traffic. This will identify any abnormal usage of the system as a possible attack. Setting a routinely exam of the network traffic and the physical security will help also in identifying the attacks from a normal traffic flow. Security is a network management issue, and the right set of tools needs to be in place to protect systems. Different intrusion-detection products cannot share attack information directly with each other due to lack of interoperability across vendor boundaries.
There are some products that can capture basic data to be shared with other service providers and law enforcement for triggering a security alert and starting the process to track the attacker through multiple networks. The problem is the interoperability issues and the lack or co-operation and organisation among ISPs or sites.
3.2
Response Measures
Response measures consist of actions that can be performed to solve and act against the DDoS attack. Based on the above prevention measures, a possible attack can be detected due to the abnormal usage of resources and alteration of normal usage guidelines. Thus, after detecting the attack, it is necessary to define a set of rules to combat the attack. Many Internet Engineering Task Force (IETF) security drafts have been proposed, including the ICMP Traceback Messages (iTrace) that does not prevent DDoS attacks but helps to trace DDoS attacks to their source. The concept of these solutions and the recent mechanism defined for this purpose is described in next section.
4
Recent solutions
Internet was originally meant to be an easy and an efficient protocol but it is now turning to be more complicated. Furthermore, new features must be implemented for security, routing and load balancing, resulting in the overloading of the network with management procedures. Therefore, it is inevitable that new solutions for solving the DDoS attacks need to be designed. Any solution that implies the modification of kernel in the exiting routers or any element on the core network is reluctant to be globally accepted and it implies a malfunctioning of this approach. Thus, it turns out in loading the systems with new heavy procedures instead of beneficial. This section presents various alternatives for the security DDoS solution and introduces some suggestions to use existing mechanisms that can efficiently help to solve the DDoS attacks. The main solutions consist in an early detection of a potential DDoS attack based on the flow classification. Therefore, the router identifies a flow that by default is considered a DDoS and initiates a trace back searching. This approach consists in using a packet counter mechanism to detect a DoS attack. This mechanism is normally used at the routers to identify traffic flows and assign certain Quality of Service (QoS) to those flows.
7
HUT TML 2001
T-110.501 Seminar on Network Security
The methods used to recognise the packet belonging to the same flow are based in counting the packets addressed to the same IP and port. This methodology uses the interarrival time, the destination IP address and port to classify and differentiate the traffic that belongs to the same flow. There are some methods, which use the Learning Vector Quantization (LVQ) algorithm to perform a traffic classification and detect specific flows from the whole traffic. The rest of the section describes the packet trace back, and early detection of the attack. Firstly, it covers what are the recent developments for traces back a DDoS. The second part analyses the mechanism for detecting the attack. In this part it is described a system that uses the early detection and then actives the trace back mechanism to apply a DDoS defense.
4.1
DDoS packet Trace back
This section describes various solutions for tracing back the packet that pertain to a DDoS attack. Table 1 summarizes the main characteristic of each solution and compares them. The latest developments to improve the Trace mechanisms are presented at the end.
4.1.1 ICMP Traceback Messages (iTrace) This mechanism [10] consists of tracing back the origin of the attack, and tries to indicate the route to drop all the packets. It can even indicate the source of the attack to initiate any further action to catch the attacker. This method is based on using the ICMP with code 30 for tracing the route of the IP packet. ICMP messages are sent in several situations: (1) when a datagram cannot reach its destination, (2) when the gateway does not have the buffering capacity to forward a datagram, (3) when the gateway can direct the host to send traffic on a shorter route. The Internet Protocol is not designed to be absolutely reliable. The purpose of these control messages is to provide feedback about problems in the communication environment, not to make IP reliable. There are still no guarantees that a datagram will be delivered or a control message will be returned. Some datagrams may still be undelivered without any report of their loss. The ICMP messages typically report errors in the processing of datagrams, but with code 30 it can trace back the IP packet. The presence of this option in an ICMP packet will cause a router to send the newly defined ICMP Trace route message to the originator of the Outbound Packet. In this way, the Originator will log the path of the Outbound Packet that in this case was identified as part of a DDoS attack.
4.1.2 Intention-Driven ICMP Trace-Back This mechanism [11] is based on the previous iTrace but optimized. The problem with the iTrace message generation is that according to the current draft, the router will generate about 1 over 20,000 packets. The intention was to avoid the overhead introduced by the iTrace messages. The drawback is that if each DDoS slave or "zombie" produces small amount of attack traffic then it will take a long time for the nearby router to generate an iTrace packet. Thus, the router near to the victim that will concentrate all the packets originated from the DDoS certainly will generate iTrace messages. The routers closer to
8
HUT TML 2001
T-110.501 Seminar on Network Security
the slaves in an isolate way do not generate enough amounts of packets to trigger the iTrace packets. A mechanism named "intention-driven" iTrace is proposed to enhance the performance of the normal iTrace behaviour. This approach consists in generating iTrace messages towards DDoS victims, based on a specified probability. Thus the destinations will have more than 1/20,000 probability to get iTrace messages during a DDoS attack. Every router will have assigned a probability for Intention iTrace, and when a packet is selected through the standard iTrace scheme based on the mentioned probability the router will invoke the "intention" iTrace mechanism. Normally, the router has two tables; routing information table and packet forwarding table. According to this mechanism the routing entry will be extended with a new "iTrace intention bit" and the forwarding table will include the "iTrace execution bit". The former bit will indicate that the destination network under that entry desire to receive iTrace messages. The latter bit indicates that the packet that is going through that forwarding entry must be iTraced. This information is distributed among the routers with routing information with protocols such as BGP. This extension is quite simple and the processing overhead is small but the iTrace trigger process is more expensive than the original one. Thus, the aim of this scheme is to enhance the probability of receiving iTrace messages closer to the DDoS slaves and to facilitate the trace back of DDoS attacks.
4.1.3 Algebraic approach for IP Traceback This proposal [12] defines the traceback problem as a polynomial reconstruction problem and uses algebraic techniques to provide a method of path reconstruction. The problems with the DDoS attacks are that they are difficult to track because the source address of the packet can be forgotten. The Ingress filtering mentioned in the above paragraph is helping to erase this problem by avoiding a packet from leaving the network without a source address from the local network. In many cases the attackers can select randomly the appropriate address to masquerade the attack. This scheme provides a traceback mechanism by adding the routers some information in the packets to trace the path. The added traceback data encodes path information as points on polynomials and then at the destination it uses algebraic models to reconstruct the path. This scheme is based on reconstructing a polynomial in a prime filed. Thus, the packet travels along the path and is accumulating the computational result based on the 32-bit IP address from each router along the way. When enough packets from the same path reach the destination, then the path can be reconstructed by interpolation. This approach aims to recover a path of length d receiving only d packets. The traceback data is inserted in the ID field of 16 bits in the IP packet structure. The performance of this method in the router is rather efficient since it only requires normal arithmetic operations. The reconstruction performance depends on the implementation of the algorithm and the number of packets required reconstructing the path. Other alternatives include similar information in the ID field of the packet and including also a distance field to allow the victim to determine the distance from the host.
9
HUT TML 2001
T-110.501 Seminar on Network Security
Comparing the performance of this method with the ICMP traceback (iTrace), the algebraic approach requires less processing power than iTrace method. The iTrace method uses an encryption algorithm to guarantee the authenticity of the packets. The algebraic mechanism uses a Random number generator and an accumulator at every router that adds its information in the packet. The end terminal can use any algorithm for decoding Reed-Solomon codes. The inconvenience is the combinatorial explosion of this method. Another packet marking scheme defining a map of the upstream routers to the attackers. This solution requires that all the routers in the attack path have to be active participants. In general this mechanism requires some computational overhead in both the router and the victim. It was indicated previously that this kind of solutions has some implementation constrains since it has to be supported by many routers already established in the core network. Thus, such technology would need to be rolled out across the entire Internet backbone and all trace routers and it will encounter some difficulties. Solution S-1: ICMP Traceback Messages (iTrace) S-2: Intention-Driven ICMP Trace-Back
S-3: Algebraic approach for IP Traceback
Characteristics The use of the ICMP with code 30 for tracing the route of the IP packet. S-2 generates iTrace messages towards DDoS victims, based on a specified probability. It avoids the overhead introduced by the iTrace messages. Based on S-1 but optimized and more expensive. S-3 defines the traceback problem as a polynomial reconstruction problem, and uses algebraic techniques to provide a method of path reconstruction. Performance in the router is efficient. Reconstruction depends on the algorithm and the number of packets required reconstructing the path.
Table 1: Comparing the different tracing approaches
4.2
DDoS Early Detection
After describing the traceback solutions, this section analyses different mechanisms to implement the DDoS detection approach. This part includes the recent solutions to detect and differentiate traffic that pertain to a DDoS from any normal traffic flow. Afterwards, it describes the mechanism the uses this DDOS detection and launches one of the previous trace back method for blocking the DDoS on its origin .The optimal defense against a DDoS would require setting the following steps previous to any action. 1. Define a network topology based on Firewalls geographical location to facilitate the attack path discovery and locate the attacker, considering multiple or single sources for the attack.
10
HUT TML 2001
T-110.501 Seminar on Network Security
2. Create a normal flow graph pattern to identify the attack and upon detecting an alteration using any of the previous methods to trace back the attack Taking the second step into account, the DDoS attack is considered as a congestion problem, where the main issue is to identify the subset of traffic (named aggregate) [13] responsible if the congestion. The ideal solution would reside in adding some extra functionality to the routers to be able to identify the flows that do not obey the TCP-like congestion control and drop it. Furthermore, the routers after the identification could back-propagate the announcement towards the sources of the traffic to enhance the service for the legitimate flows in the shared links.
4.2.1 Pushback: Router-based defense against DDoS attacks This approach [14] considers that due to the DDoS attack, the packets arriving do not obey end-to-end congestion control algorithms because their objective is to bombard the victim causing the resources starvation. By default the routers cannot determine whether a packet pertain to a legitimate flow or an attack. Thus, the routers will need a heuristic to identify the malicious packet and not interfere in the legitimate one. In this methodology, it is defined the concept of Aggregate-based Congestion Control [13] (ACC), where an aggregate is defined as a subset of traffic with some specific characteristic (Ex. Packets to the same destination, TCP SYN packets, packets with a bad checksum, etc). Based on this concept the malicious packets sent by the attackers are characterised by their own attack signature, which helps to segregate from the normal traffic. The pushback mechanism consist in after identifying the attack signature and assigning the congestion signature the routers send messages to the upstream routers to indicate them to limit the rate of the traffic with the congestion signature for the downstream link. Furthermore, this process is repeated in the upstream till it reaches the routers closer to the origin of the attack. This method consists in maintaining a daemon process at the router that does the traffic shaping. This process periodically updates the parameters for the rate limiter and informs the upstream daemons in other routers about the dropped packets. Thus, a large amount of dropped packets indicates congestion. Now it has to be determined if there is an attack going on, and whether to respond to it. Initially, it is considered a representative sample of the dropped packets. Afterwards, for detecting the aggregate this method analyses the destination IP address (the source address cannot be trusted) and starts deciding whether the congestion level is enough (depending on the level of packets dropped) to alert the preferring dropping. After the alert it starts the identifier of the congestion signature, which consists in selecting the longest prefix matching in destination address from the dropped subset. Once the congestion signature has been identified, the code must decide the rate-limit assigned to the flow pertaining to the supposed attack. Then after the pushback daemon has identified the prefix (congestion signature) and its rate-limit, it communicates that information to its upstream links. The daemon also gets information about source and destination for each packet and then it can compute the bandwidth that the aggregate is
11
HUT TML 2001
T-110.501 Seminar on Network Security
consuming on each link. The daemon also has to listen for messages from its downstream routers to interpret the received rule and apply the rate limiter.
4.2.2 Resource allocation techniques There are other alternatives similar to the previous one that consists in applying resource allocation techniques on network bandwidth. Integrated Services and Differentiated Services [15] are two approaches aimed to isolating flows with specific quality of service requirements for lower-priority traffic. The inconvenience in this approach is that the web traffic will remain as best effort traffic and it will be not protected by QoS requirements. Furthermore, it is possible that the attackers fake the traffic to look like protected flows that require QoS treatment. In general there are many congestion control mechanism that can alleviate the effects of congestion due to DDoS attacks (Random Early Detect, Fair Queuing, Class-based queuing). These controls aim to allocate the available bandwidth to each flow so they get served with the appropriate quality. The problem is that the packets belonging to the DDoS attacks do not have a clear identification and then they cannot be identified by those mechanisms and will be prioritised like a legitimated flow.
4.2.3 Automated Intrusion Detection Recently, there are new advances in developing a new infrastructure network-based intrusion detection systems[16], firewalls and routers to attacks back to their source and block the attacks close to that source. prototypes of this approach named Cooperative Intrusion Traceback Architecture (CITRA)[17] developed under the DARPA sponsorship.
for integrating trace back the There are new and Response
This infrastructure is developed to help in automating the tasks for the intrusion analysis and response. The purpose of automate this tasks [18] is to facilitate taking quick measures immediately when the attack is taking place. Otherwise, while the human administrator tries to analyse the intrusion can take long period and during that time the damage caused by the intrusion can be huge. To analyse and respond to intrusions it is necessary to gather a lot of information from traffic snifters, network management systems, routers and switches diagnostics [19] and other systems. Thus, all that information has to be processed and merged to identify correctly the attack and CITRA is one concrete approach for implementing this mechanism. CITRA is composed by a set of multiple modules and the Intruder Detection and Isolation Protocol (IDIP) is one of them. IDIP defines the information that enable CITRA to exchange messages to detect the attack. Therefore the aim of the system is to define an infrastructure that enables the integration of diverse components into a cooperative and self-protecting network. This infrastructure needs to be supported by many components and it has to keep the knowledge about the status of the Network topology – routers, VLANs, bandwidth and the operating systems – UNIX/LINUX. Thus it has to keep taking Metrics, packets collected at each client. As part of the latest improvements there are some tests when it is proved the efficiency of the automatic detection and trace back against DDoS attacks.
12
HUT TML 2001
T-110.501 Seminar on Network Security
Figure 2 shows an example of test case [20] where the attacker remotely launches a DDoS attack and the automated mechanism takes care of detecting the intrusion. After identifying the assault, the system traces back the origins of the attack and send the orders to the routers for slow down the traffic flow that pertains to the detected strike. Attack Agent LAN Agents attacking server
Attack Agent LAN
Attack Agents
Router1
Attack Agents
Rate Limit
Client 3
Attack Agent LAN Attack Agents
Rate Limit
Rate Limit
Router2
Router3
ROUTER LAN (Simulated INTERNET Cloud)
Router4
Router5
Rate Limit Detector detects the flood and signal routers to Rate Limit
Master sends attack signal
Attack Master
Client 2
Client 1 Detector Server
Attack Master LAN
Server LAN
Figure 2: Test framework for automatic intrusion detection and tracebak.
5
Conclusions
The paper gives a completely overview of the DoS attacks. It describes varios examples of attacks that have been performed along the Internet existence. Furthermore, the paper includes the initial solutions to combat this problem using filtering and adding the recent patches to the obsolete software. This paper also has covered the latest developments in terms of detecting, differentiate a DoS attack and try to solve it. Those improvements apply more complicated methodologies and at some point the core network routers have to be involved. In this solution has been defined new mechanism to trace back the attack and then apply the defense closer to the origin of the attack. This type of solutions will have a major impact when trying to defend against a DDoS and it would require bigger effort to solve this problem. The latest approach is presented when combining all the presented mechanism such as detection, trace back and defense. In the last part of the paper is presented a proposed infrastructure that applies the mentioned propositions presented in the paper. Therefore, in the near future it will appear new types of DDoS attacks and new patches to the software that solves those attacks. While the DDoS attack there is no defense and the more effective way to act against those attacks is to deploy a common infrastructure. This infrastructure will apply all the recent development for trace back and block the attack in a cooperative way among multiple networks and vendors. Thus, the outcome of this paper is that no matter how complicated the Distributed DoS attack can be the best solution is to apply a Distributed DoS defense globally implemented among multiple networks.
13
HUT TML 2001
T-110.501 Seminar on Network Security
REFERENCES [1] Brian Sullivan. Canadian Mounties nab MafiaBoy. Computerworld Magazine. http://www.nwfusion.com/news/2000/0419mafiaboy.html, April 2000. [2] Kevin J. Houle and George M. Weaver. Trends in Denial of Service Attack Technology v.01. CERT Coordination Center -Software Engineering Institute. Carnegie Mellon University. http://www.cert.org/archive/pdf/DoS_trends.pdf, October 2001. [3] Rik Farrow. Distributed Denial of Service Attacks. Network Magazine, March 2000. [4] Shon Harris. DoS Defense. Information Security magazine, September 2001. [5] Marcel Dekker. Security of the Internet. The Froehlich/Kent Encyclopedia of Telecommunications, vol. 15 pp 231-255, New York, 1997. [6] Dennis Fisher. Mazu Filters DDoS Attack Packets. eWeek magazine, 17 October 2001. [7] Defense Tactics for Distributed Denial of Service Attacks. Federal Computer Incident Response Center (FedCIRC). http://www.fedcirc.gov/, 2000. [8] Paul Ferguson and Daniel Senie. Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing. RFC 2827, IETF Network Working Group, May 2000. [9] Drew Dean and Adam Stubblefield. Using Client Puzzles to Protect TLS. In 10th USENIX Security Symposium, Washington D.C., USA, 13–17 August 2001. [10] Steve M. Bellovin, Markus Leech, and Tom Taylor. ICMP Traceback Messages. http://search.ietf.org/internet-drafts/draft-ietf-itrace01.txt, October 2001. [11] S. Felix Wu, Lixia Zhang, Dan Massey, and Allison Mankin. Intention-Driven ICMP Trace-Back. http://search.ietf.org/internet-drafts/draft-ietfitrace-intention-00.txt, November 2001. [12] Drew Dean, Matt Franklin, and Adam Stubblefield. An Algebraic Approach to IP Traceback. In Network and Distributed System Security Symposium (NDSS'01), San Diego, California, 7-9 February 2001. Internet Society. [13] Sally Floyd et al. Aggregate-Based Congestion Control (ACC) and Pushback project. AT&T Center for Internet Research at ICSI. http://www.aciri.org/pushback/
14
HUT TML 2001
T-110.501 Seminar on Network Security
[14] John Ioannidis and Steven M. Bellovin. Pushback: Router-Based Defence Against DDoS Attacks. http://www.research.att.com/~smb/papers/pushbackimpl.pdf, February 2001. [15] Steven Blake, David L. Black, Mark A. Carlson, Elwyn Davies, Zheng Wang, and Walter Weiss. An architecture for Differentiated Services. RFC 2475, IETF Network Working Group, December 1998. [16] Stefan Savage, David Wetherall, Anna Karlin, and Tom Anderson. Practical Network Support for IP Tracebak. In the 2000 Association for Computer Machinery (ACM) SIGCOMM Conference, pp. 295-306, Stockholm, Sweden, 28 Aug.-1 Sept., 2000. [17] Dan Schnackenberg, Kelly Djahandari, and Dan Sterne. Infrastructure for intrusion detection and response. In DARPA Information Survivability Conference & Exposition (DISCEX) Volume II of II, South Caroline, 25-27 January 2000. [18] Daniel Sterne, Kelly Djahandari, Brett Wilson, Bill Babson, Daniel Schnackenberg , Harley Holliday , and Travis Reid. Autonomic Response to Distributed Denial of Service Attacks. In Fourth International Symposium on Recent Advances in Intrusion Detection (RAID 2001), Davis, CA, 10-12 October 2001. [19] Ratul Mahajan, Steven M. Bellovin, Sally Floyd, John Ioannidis, Vern Paxson, and Scott Shenker. Controlling High Bandwidth Aggregates in the Network. AT&T Centre at Internet Research at ICSI (ACIRI), July 2001. [20] Steve Ying. IA0126 DDoS Automated Response Re-Run. BBN Technologies, Information Assurance (IA) Program, 29 September 2000.
15
