A Router-Based Defense Against Ddos Attacks

Pushback Mechanism A Router-Based Defense Against DDoS Attacks

Submitted by Suma Iyli & Kanthi Rekha ii Pushback Mechanism A Router-Based Defense Against DDoS Attacks

1.0 Introduction

Distributed Denial of Service (DDoS) attacks have become an increasingly frequent disturbance of the global Internet. They are very hard to defend against because they do not target specific vulnerabilities of systems, but rather the very fact that the target is connected to the network. The Distributed Denial of Service (DDoS) attacks are slightly different from the Denial of Service (DoS) attacks. DoS attacks come from one or more hosts directed at some resource of the network such as a link or a web server whereas in the Distributed Denial of Service (DDoS) attacks the attacking traffic comes from large number of disparate sites.

DDoS may be caused by flash crowds or malicious hosts. Flash crowds occur when large numbers of users try to access the same server simultaneously. The site www.olympics.com triggered such an event during Olympics-2000. DDoS caused due to malicious hosts take advantage of the large number of unsecured hosts on the Internet; the perpetrators break into such hosts, install slave programs, and at the right time instruct thousands of these slave programs to attack a particular destination. The attack does not have to exploit a security hole at the target to cause a problem. So, there is almost nothing the victim can do to protect itself.

While the intent and triggering mechanisms for the DDoS due to flashcrowds and the DDoS due to malicious hosts are quite different, from the networks perspective these two events are quite similar. The persistent congestion is neither due to single well-defined flow, nor due to an undifferentiated overall increase in traffic. Instead the congestion is caused by aggregates (defined as a subset of the traffic with an identifiable property) that cannot be controlled by the conventional flow based protection mechanisms (TCP/IP flow control).

This paper describes a network-based solution, called Pushback, to address the question of whether anything can be done inside the network to defend against DDoS attacks

1.1 Overview of Pushback

If the router can detect all the bad packets and just drop those then the problem would be simple. But the routers cannot be 100% sure whether the packet belongs to bad traffic or good traffic. The goal of the pushback is to find the bad packets as far as possible and drop those without interfering with the good ones. To fulfill this mission Pushback uses Aggregate Congestion Control (ACC). The challenge here is to identify aggregates responsible for congestion and drop them at routers. "Packets to a particular host/server”, “TCP SYN packets”, or even “IP packets with a bad checksum” are all few examples of aggregates. Pushback can be explained with the help of the figure below.

1 R R R R 1 2 3 4

R R R 5 6 7

Figure 1. A DDoS attack in progress.

Consider the network in Figure 1. The server D is under attack and all the traffic to D is coming from routers R1 to R8. The red lines show links with bad or attack traffic and the green lines show links with no bad or non-attack traffic. In the absence of any special measures, hardly any non-attack traffic would be reaching the destination. Even though the links R2-R5, R3-R6 R5-R8, R6-R8, and R8- D are red there may be some non-attack traffic flowing through them but most of it is dropped due to congestion in R8-D.

The term's bad traffic, poor traffic, good traffic are referred frequently in this paper. Bad traffic contains bad packets sent by the attackers. Bad traffic is characterized by an attack signature or congestion signature (defined as a set of properties of the aggregate identified as causing problems), which we strive to identify. Poor traffic consists of packets that match the congestion signature, but are not really part of an attack. They are just the unlucky ones, which have the same properties (for ex: the IP destination address) as the Bad packets, which put them into the black list. Good traffic does not match the congestion signature, but shares links with the bad traffic and may thus suffer.

In the figure above there is both good and bad traffic are entering routers R2, R3, R4 whereas only bad traffic is entering R1. Links R2-R5, R3-R6 might consist of both good and bad traffic but the good traffic will suffer depending on how congested the links are. Some of the good traffic entering R7 from R4 goes to R8 and some of it exits through the right link. Since the link R8-D is already congested even though the filters of R8 work properly the good traffic coming from R7 cannot enter R8.

When the Pushback mechanism is used R8 sends a message to R5 and R6 telling them to rate limit traffic for D even though the links downstream from R5 and R6 are not congested. This is because the router R8 is going to drop packets destined for D anyway so it is better not to waste the bandwidth of the upstream links for these packets. In turn the routers R5 and R6 propagate the request up to

2 R1, R2, and R3, telling them to rate-limit the bad traffic, allowing some of the ‘poor’ traffic, and more of the good traffic, to flow through.

2.0 Architecture

Figure 2 shows the architecture of the router. The input queues shown here are the various input links to the router. First the packet is checked whether it matches the congestion signature or not. If the congestion signature is not matched then the packet is sent to the output queue, otherwise it is sent to the rate limiter. The rate limiter decides whether the packet is to be dropped or forwarded. The dropped packets are sent to the Pushback daemon, pushbackd. The daemon, in turn, periodically updates the parameters of the rate limiter, and also informs the upstream daemons to update theirs. Pushback daemon may not reside on the router itself, but rather on an external ancillary piece of equipment.

Input queues

Output queue Match N P Congestion Signature?

Rate Limiter

Update Congestion Adjust D Signature local ACC Pushbackd

pushback

Figure 2. Partial view of a router.

The rate limiter sends the information shown in fig-3 to the Pushback daemon. This information is called as the dropped packet report. The magic number provides some protection against synchronization problems between the kernel and the user-level process. The timestamp is expressed in nanoseconds since the router was last booted, and its purpose, along with the packet size, is to allow the code to estimate the bandwidth that would have been consumed by the dropped packets. The ‘reason’ field indicates whether this was a tail-queue drop, a RED (Random Early Detect) drop, and so on. Only packets dropped because of queue discipline restrictions are logged; packets dropped because, for example, they were not routable, or even because no buffer space could be allocated for them at the driver may not even reach this part of the code, so they are not reported at all. Since the nature of DDoS change rapidly, the routers are designed such that the information about the dropped packet is sent to a computer or a CPU that is attached to the routers local interface. In that way they could be easily replaced.

3 Magic Number

IP Destination address

Input interface

Output interface

Timestamp

Packet size

Reason

Figure 3. Dropped packet report

2.1 Aggregate Detection

The pushback daemon (pushbackd) periodically processes the saved drop-set (set of packets dropped by the rate limiter) to try to detect congestion. The pushback daemon can now determine if there is an attack going on, using the algorithm described here. This algorithm detects aggregates based only on IP destination address because the source addresses cannot be trusted as the attackers send IP packets with random contents to create congestion. The algorithm follows the following steps,

Step1: In this step the algorithm determines if the congestion level is high. First it checks if the bandwidth wo of the output link is exceeded by more than an acceptable drop rate, say, 20% of the traffic i.e., wi > 1.2 * wo, where wo is the total incoming bandwidth from all input links. If the above equation holds good then it means that there is congestion.

Step2: The destination address of each dropped packet is compared against the routing table, and the longest matching prefix is selected. Then the dropped packets are grouped according to their eventual destination address.

Step3: The drop set is then sorted with the prefix as the key. The sorting has complexity O(nlogn), where n is the size of the drop set. Then the prefix with the highest count is determined. The counting and determination of the most frequent prefix is, of course, linear in n.

Step4: Now, for the subset of the drop set that matches this selected prefix, we perform another scan to see if the destinations of the dropped packets match a longer prefix than the routing prefix. If, for example, a single machine has been targeted, even though the prefix gathered from the routing table will be shorter than 32 bits (in case of IPv4) or 128 bits (in the case of IPv6), the address of the selected aggregate will be the full 32 or 128 bits. The selected prefix constitutes the congestion signature.

4 In order to determine if there is more than one attack happening at the same time, the drop set is scanned to compute the fraction of the bandwidth wb for which the identified congestion signature is responsible. Now, if removing the traffic identified by the congestion signature does not bring the output traffic below the previously described acceptable level, that is, if wi – wb > 1.2 * wo still holds, then the algorithm is repeated from Step2 in the hope of adding more prefixes to the congestion signatures.

2.2 Rate Limiting

After the congestion signature has been identified, the code must decide what to rate-limit it to. If wb > wl where wl = wi – 1.2 * wo, then we simply rate-limit the aggregate down to wl and pass the rest of the traffic on. If wb < wl then we eliminate all traffic belonging to the congestion signature, and let the rest of the excess traffic be limited by the output queue. Just because a packet was not dropped by the rate limiter does not mean that it will be preferentially treated and not dropped if it must at the output queue. The pushback daemon gets dropped packets from both the rate limiter and the output queue; if the rate of the attack stays constant, the daemon will get the same number of dropped packets, but it will be getting more of them from the rate limiter. This means that, as long as the attack is going on, the pushback daemon will keep telling the rate limiter to drop packets; when it stops, no special action needs to be taken; at the next update, no attack will be identified, and the rate limiting will stop.

2.3 Pushback

Once the Pushback daemon has identified the congestion signature or prefix to rate- limit, it communicates that information to its upstream links. There are 3 kinds of messages exchanged by routers implementing Pushback. They are request, response and status. The pushback request is shown in the figure 4 below.

Various header fields

RLS-ID

Maximum depth

Depth of Requesting Node

Bandwidth Limit

Expiration Time

Congestion Signature

Figure 4. Pushback request

5 Rate-Limiting Session Identifier (RLS-ID), field in the pushback request is used to match responses to requests. The Depth field is used to set a limit to the propagation of the pushback requests. The maximum depth field indicates how many daemons it can pass through. The maximum depth field is set by the originating router to some value and the depth field is set to 0 by the originating router. The upstream daemons increment the depth by 1 as it passes along by each subsequent router. Pushback uses soft state – which means that the state information about the pushback requests is erased when the router resets. The expiration time is used to manage this soft state – if a Refresh message does not arrive before the expiration time has elapsed, the entry is deleted. The congestion signature field consists of a list of destination prefixes. The bandwidth limit applies to the destination prefixes in the pushback request.

Authentication in Pushback requests is done by checking the TTL field in the IP header. A cancel message is used to instruct the upstream router to stop rate- limiting. The Pushback daemon not only sends requests, but it also listens for requests from its downstream routers. Once it receives a pushback request (or refresh), it adds the appropriate rule to the rate limiter, and keeps track of the dropped packets it gets from it. The pushback daemon also sends status messages downstream which contains the depth field that limits the message to a number of downstream routers.

3.0 Implementation

Pushback was implemented under FreeBSD operating system. The tests were conducted on a Testbed network. Bad, good and poor traffic were allowed to flow through the network and all of them were destined to the same router. The test hardware used was (300MHz PentiumII generic PCs with 100Mbps Ethernet interfaces, running FreeBSD 4.2). The test was successful.

There are some aspects that are easy to simulate, but real code running on real machines needs exploration of the details of a real system. How much memory and computing power is needed to actually run Pushback is to be found out to implement Pushback in the real routers. Investigation and experiments are still going on to successfully deploy Pushback in the real routers even in the absence of explicit support from router vendors.

4.0 Conclusion

Pushback ACC (aggregate based congestion control) mechanism prevents network bandwidth from being wasted on bad packets. Pushback protects other traffic from bad traffic. When the network is under attack it can rate limit malicious traffic. Implementation becomes complex as it requires lot of resources.

6 5.0 References:

 R. Mahajan, S. M. Bellovin, S. Floyd, J. Ioannidis, V. Paxson, and S. Shenker. Controlling High Band-width Aggregates in the Network – Extended Version. http://www.aciri.org/pushback/

 http://www.silicondefense.com/research/itrex/archive/tracing- papers/ioannidis01pushback.pdf

 http://www.research.att.com/~smb/papers/pushback-impl.pdf

 http://www.isoc.org/isoc/conferences/ndss/02/proceedings/papers/ioanni.pdf