Distributed Denial-of-Service (DDoS) attack has turned into one of the major security threads in recent years. Usually the only solution is to stop the services or ...
IDR: An Intrusion Detection Router for Defending against Distributed Denial-of-Service (DDoS) Attacks∗ Eric Y. K. Chan1 , H. W. Chan1 , K. M. Chan1 , Vivien P. S. Chan1 , Samuel T. Chanson2 , Matthew M. H. Cheung1 , C. F. Chong1 , K. P. Chow1 , Albert K. T. Hui2 , Lucas C. K. Hui1 , Luke C. K. Lam1 , W. C. Lau1 , Kevin K. H. Pun1 , Anthony Y. F. Tsang1 , W. W. Tsang1 , Sam C. W. Tso1 , Dit-Yan Yeung2 and K. Y. Yu1
Abstract Distributed Denial-of-Service (DDoS) attack has turned into one of the major security threads in recent years. Usually the only solution is to stop the services or shut down the victim and then discard the attack traffic only after the DDoS attack characteristics (such as the destination ports of the attack packets) are known. In this paper, we introduce a generic DDoS attack detection mechanism as well as the design and setup of a testbed for performing experiments and analysis. Our results showed that the mechanism can detect DDoS attack. This enable us to proceed to the next steps of packet classification and traffic control.
1 Introduction Denial-of-Service (DoS) attack [8] is an incident in which a user or organization is deprived of the legitimate use of services of some resources (such as the computers or network resources) that they would normally expect to have. In a typical DoS attack scenario there are usually three parties - the attacker, the zombie and the victim. The attacker is the computer that issues commands to order the zombie which is a compromised computer to start the DoS attack. The zombie then starts the DoS attack by sending tremendous packets to the victim which is the computer that provides services to the users. The number of the attack packets overwhelms the number of the legitimate packets from ordinary users and therefore much of the resources is wasted in handling the attack packets but not the legitimate one and thus the services are denied from ordinary users. * This work is supported by the Areas of Excellence
Scheme established under the University Grants Committee of the Hong Kong Special Administrative Region, China (Project No. AoE/E-01/99) 1 Department of Computer Science and Information Systems, University of Hong Kong 2 Department of Computer Science, Hong Kong University of Science and Technology
Distributed Denial-of-Service (DDoS) attack [8], as the name implies, is a kind of DoS attack where there are more than one zombie distributedly attacking the victim. DDoS attack starts gaining attention after several successful DDoS attacks on major commercial Internet sites like Amazon, CNN, eBay, Yahoo and even FBI in year 2000. Some specific detection schemes [19] and several defensive schemes focus on protocol development [15][17][18] have been proposed. However, a generic DDoS attack defensive scheme is not common and we propose to implement an intrusion detection mechanism in routers to achieve this goal (see also [11]). We call a router equipped with DDoS protection mechanism an Intrusion Detection Router (IDR). In this paper we introduce a router architecture that can detect DDoS attack. This lay down the foundation of further protection of the network by packet classification and traffic control. We will show that the DDoS attack detection mechanism using Bloom filter [3] can successfully detect DDoS attack and identify the suspicious packets. To enable us to perform realistic experiments, we have built a large-scale testbed for this purpose. The remainder of this paper is organized as follows. Section 2 gives an overview of IDR architecture in which the DDoS attack detection using Bloom filter will be the main subject. Section 3 introduces the testbed for performing experiments and analysis of IDR. Section 4 introduces the background traffic and DDoS attack traffic running on the testbed. Section 5 describes a case on the DDoS attack detection mechanism. Section 6 gives the summary and future work.
2 Intrusion Detection Router: IDR 2.1 Overview The goals of IDR is to provide technologies to detect and harden existing Internet infrastructure from large-scale
Proceedings of the 7th International Symposium on Parallel Architectures, Algorithms and Networks (ISPAN’04) 1087-4089/04 $ 20.00 © 2004 IEEE
filter, a two-dimensional bin table of k levels by m bins with k independent hash functions is used to keep track of the recent arrival rates of packets of different destination IP addresses passing through a router within a sampling period t. When a packet arrives its destination IP address is hashed into k values and map to one of the m bins in each of the k levels using k independent hash functions. The counter, cij (where 0 ≤ i ≤ k and 0 ≤ j ≤ m), kept in the corresponding bins are then incremented by 1. These counters are reset for every sampling period t. If the number of packets mapped to a bin goes above a certain threshold h, i.e. the arrival rate of certain packet with this particular destination IP address is exceptionally high, then the bin is considered as overflowed. A particular flow of traffic is classified as exceptional heavy if it causes all of the bins it maps to overflow. Destination IP address k = 4 levels of hash functions
network intrusions and attacks concentrating on DDoS attacks. IDR aims to provide the following features: (1) Detect any traffic that consumes exceptionally high network bandwidth (e.g. DDoS attack). (2) Analysis and discard those highly suspicious packets (3) React on attack by back tracking the source of attack and by controlling their flows among the routers. These functionalities would be developed as add-on modules and incorporated into open source software router (Linux). The overall architecture of IDR is shown in Figure 1. IDR monitors the traffic passing through the router and detects any exceptional heavy volume of packets going to the same destination (a strong evidence that a DDoS attack is launched). Once suspicious DDoS attack packets are found, the DDoS attack detection module will pass them to the packet classification module for analysis which will identify highly suspicious packets to be discarded and pass less suspicious packets to the traffic control module to rate limit the bandwidth of these packets. Thus the legitimate packets are protected. In this paper, we will focus on the successful detection of DDoS attack which corresponds to the first module in Figure 1. The other two modules will be considered in future work and will be reported in sequel papers.
hash0 ()
1
0
0
0
0
0
1
0
0
0
2
0
0
0
1
0
0
0
5
0
0
0
0
0
0
0
0
0
hash1 ()
0
0
0
1
0
0
0
1
0
hash2 ()
0
1
0
0
0
0
0
0
0
0
2
2
0
0
0
3
0
0
0
0
0
1
0
0
0
0
0
0
0
9
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
hash3 ()
1
0
0
0
1
2
0
0
1
0
0
1
0
0
0
0
2
0
0
0
0
2
0
0
0
0
0
0
m = 28 bins of counters
Incoming packets Software router DDoS attack detection module (by Bloom Filter)
Outgoing packets Packets going to other destinations pass through the router as normal
Exceptional heavy volume of packets going to the same destination
Figure 2. Using Bloom filter to detect DDoS attack. This figure shows the value of the counters in each bin each level after 10 destination IP addresses are hashed into the table.
Packet classification Highly suspicious module packets are discarded Less suspicious packets Traffic Control module
Rate limited
Figure 1. Overview of the IDR architecture.
The advantage of this DDoS attack detection mechanism is that it reduces the space from using a counter for each of the 232 possible IP addresses with zero error to k × m counters with allowable errors. With reference to the IDR architecture in Figure 1, IDR will pass the suspicious DDoS attack packets detected for analysis in the next module to further reduce the error rates.
2.2 DDoS attack detection
2.3 Case-studies on the allowable errors
IDR detects DDoS attack passing through a router by employing Bloom filter to locate the exceptional heavy volume of packets going to the same destination. Bloom filter is originally designed to test a series of messages oneby-one for memberships in a given set of messages in 1970. It is used to reduce the disk access to differential files in 1980’s [7][14] and other applications [12][16] and is now extended to detect DDoS attack. The idea is that during a DDoS attack an exceptional heavy volume of packets are attacking the victim - the same destination IP address, thus the focus is on the destination IP addresses of the packets. In the Bloom
There are two cases to consider in this DDoS attack detection mechanism. The first case is that under a certain overflow threshold, a group of legitimate packets going to the same destination IP address will be mis-classified as attack packets as other legitimate packets with different destination IP addresses are hashed to the same bin in any of the k levels. For example, let the overflow threshold h be 5000 packets and there is a group of 3000 legitimate packets targeting the same destination within the sampling period t (see Figure 3). Overflow occurs and this group of legitimate packets will be mis-classified as attack packets because in all the k levels the sum of the number of packets
Proceedings of the 7th International Symposium on Parallel Architectures, Algorithms and Networks (ISPAN’04) 1087-4089/04 $ 20.00 © 2004 IEEE
E(x) =
232 232 = mk 2klog2 m
k = 4 levels of hash functions
Destination IP address
hash1 () hash2 ()
3000 + 12000
3000 + 5000
3000 + 17000
hash3 ()
3000 + 7000
m bins of counters
3000 + x
3000 packets with the same destination IP address + x packets with different destination IP addresses happened to hash into the same bin
Figure 3. The Bloom filter used in IDR showing a group of 3000 legitimate packets mis-classified as DDoS attack packets using the overflow threshold set at 5000 packets.
The second case is that assuming a good estimation of overflow threshold is set (say 7000 packets) and a DDoS attack has occurred and has been detected (see Figure 4), the probability to hash a different IP address to the same bin as the attack packet’s destination IP address in all k levels is given by P = (1/m)k
hash0 () hash1 () hash2 ()
15000
8000
20000
hash3 ()
10000
m bins of counters
Figure 4. The Bloom filter used in IDR showing an DDoS attack has occurred with the overflow threshold set at 7000 packets.
(1)
It is preferable to have E(x) ≤ 1 to reduce the chances of hashing different IP addresses into the same bin in all k levels. One of the possible setting is to use k = 4 and m = 232 256 which gives E(x) = 256 4 = 1.
hash0 ()
Destination IP address k = 4 levels of hash functions
of this group plus the number of other packets with different destination IP addresses hashing to the same bin are greater than the overflow threshold 5000. This error occurs as the overflow threshold is set too low. We should consider the number of packets in the background traffic, the flash crowds and the DDoS attack when setting the overflow threshold. In this case, we can set the overflow threshold to ≥ 20000(= 3000+17000). Note that different IP addresses can be hashed to the same bin in all k levels. Let E(x) be the expected number of different IP addresses hashed to the same bin in all k levels:
(2)
If we use k = 4 levels of hash functions and m = 256 bins of counters, P = (1/256)4 ≈ 2.328−10. Therefore the probability that a legitimate packet will be mis-classified as attack packet in this case is very low. The false positive and false negative of this DDoS attack detection mechanism is a function of the dimensions of the Bloom filter k and m, the sampling period t, the overflow threshold h and the arrival rate of the packets n in t which is under investigation.
3 Testbed 3.1 Design Overview A large-scale testbed, HARNET-II, is built in order to provide a realistic network environment for various experiments over network simulation. HARNET-II consists of computers connected among 3 universities in Hong Kong - The Chinese University of Hong Kong (CUHK), The Hong Kong University of Science and Technology (HKUST) and The University of Hong Kong (HKU). Experiments such as DDoS, QoS and distributed programming can be performed. According to Faloutsos et al. [5], the inter Autonomous System (AS) topology exhibits a power-law vertex degree distribution. However it is not feasible to setup such a topology using limited computers and therefore the testbed does not setup according to the power laws of the AS topology. Another limitation is that it is not possible to scale down everything in the Internet to the testbed, such as ratio of the number of hosts and the link bandwidth. One of the goals of the network topology design is to increase the difficulty in packets traceback by setting many equal-length shortest paths between the routers (see Figure 5). Thus the testbed is designed in a hexagonal structure. A better structure in the form of grid (with more connectivities) is not used due to hardware limitation the number of network interfaces in the software routers. Our experiments involved DDoS attack uses a subset of HARNET-II. For convenience we refer this subset as the testbed in this paper.
3.2 Hardware and software The testbed consists of 86 computers (see Figure 5) including 21 rack servers Dell PowerEdge 1650, 25 Dell Optiplex TM GX240 and 40 ordinary desktops for generating background traffic (see Table 1).
Proceedings of the 7th International Symposium on Parallel Architectures, Algorithms and Networks (ISPAN’04) 1087-4089/04 $ 20.00 © 2004 IEEE
10 19
11 4
12
1 5
17 8
21
3
18
C
13
9
2
16
6
7
14
15
x
Linux-based software router x in subnet x
C
Cisco router connected to other parts of HARNET-II
20
Linux hosts in the subnet 100 Mbits link
Figure 5. Testbed network topology.
Model:
CPU:
cache: RAM: HD: NIC:
Software routers × 21 Dell PowerEdge 1650 R Intel R Pentium III 1.4 GHz ×2 256 KB 512 MB SCSI 40 GB 100 Mbits/s × 4, 1 Gbits/s × 2
Main servers × 25 Dell Optiplex TM GX240 R Intel R Pentium 4 1.7 Ghz
Hosts × 40
256 KB 256 MB IDE 40 GB 100 Mbits/s
32 KB 128 MB IDE 20 GB 100 Mbits/s
LEMEL PC48100715 AMD Duron TM 800 MHz
the traffic composition is relatively stable on a daily basis, but can be very different in different locations. Therefore only the most common traffic type including FTP, SMTP, HTTP, NNTP, and UDP stream are generated using scripts or programs on the testbed and the composition are tuned to be relatively stable with surge occasionally. Other types of traffic such as ICMP, SSH, NIS, DNS, NTP and OSPF are also generated as a result of daily operations and interactions between the computers on the testbed. The methods to generate background traffic on the testbed are listed in Table 2 and the location is shown in Figure 6. Type FTP SMTP
HTTP NNTP UDP stream Others
Method Scripts to download files from different FTP servers randomly. Scripts to send emails with attachments to several recipients randomly. Surge [1] modified to send requests to different HTTP servers randomly. Feeding news to the clients regularly. IPerf [6] sending UDP streams with random bandwidth. Generated on the testbed through interactions between the computers.
Table 2. Background traffic generation on the testbed.
Table 1. Hardware configurations of the computers on the testbed. 10
11
19
The OS RedHat Linux 7.3 with newer kernel 2.4.18-177, the latest stable version at the time when the testbed is setup, is installed on all computers (The latest version of RedHat Linux is now 9.0). Provided with source codes, linux allows kernel development and RedHat is one of the most popular brand of Linux.
4
12
x C
4.1.1 Overview The Internet is changing rapidly with new applications and protocols invented in a short time. Thus it is impossible to generate background traffic that resemble exactly the same as the Internet traffic. According to Liu [13], TCP is the dominant protocol which takes about 90% of the bytes of the Internet traffic. The study also reveals that
Servers: DNS, NIS, NTP and NNTP
1
21
3
18
5
C
9
13
2
16
4 Traffic Generation 4.1 Background Traffic Generation
17 8
Software router x in subnet x
6
7
14
15
Cisco router connected to other parts of HARNET-II
20
Server/client not installed
FTP server
SMTP server
HTTP server
NNTP server
UDP server
FTP client
SMTP client
HTTP client
NNTP client
UDP client
Server/client for background traffic
Figure 6. Background traffic generation on the testbed.
Proceedings of the 7th International Symposium on Parallel Architectures, Algorithms and Networks (ISPAN’04) 1087-4089/04 $ 20.00 © 2004 IEEE
One of the most famous DDoS attack tool, Tribe Flood Network 2000 (TFN2K) is used to generate DDoS attack on the testbed. The source code can be downloaded freely from the Internet. TFN2K can generate several common DDoS attacks including UDP flood, TCP/SYN flood, ICMP/PING flood, ICMP/SMURF flood and a mix of these attacks, which are real attacks described in CERT advisories [10]. TFN2K consists of a daemon and a client programs. The attacks are generated by using the client to send commands to invoke the daemon running on the zombies to start the DDoS attack. The DDoS attack traffic volume can be tuned by the number of zombies (TFN2K daemon) attacking the victim. TFN2K does not provide any parameters for tuning the traffic volume. A full analysis on TFN2K is published on March 2000 [2].
4.3 Traffic management
5 A DDoS attack detection case study An experiment is performed by running the DDoS attack detection module of IDR on a one hour traffic trace on the testbed including the background traffic and DDoS attack traffic (UDP flood). During the DDoS attack there are 2 zombies in each of the subnet 10, 17 and 19 attacking the victim h12102 in the subnet 20 (see Figure 7). The DDoS attack traffic volume is heaviest in subnet 20. 2 zombies at subnet 10
2 zombies at subnet 17
10
19
11 4
12
17 8
1 5
21
3
18
C
13
9
2 6
16 7 x
14 victim h12002 at subnet 20
DDoS attack detected by IDR 100 90 80 70 60 50 40 30 20 10 0 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
Software routers
Figure 8. DDoS attack detected by IDR.
The background traffic and DDoS attack traffic are controlled by scripts and can be started and stopped at the gateway on the testbed. The traffic on the testbed is monitored by the tool Multi Router Traffic Grapher (MRTG) [9]. MRTG generates graphs of the traffic of each link of the computer by getting data from SNMP.
2 zombies at subnet 19
Figure 8. The ratio of traffic volume detected is different in different routers due to the different ratio of the background traffic volume to the DDoS attack traffic volume in different routers. The DDoS attack traffic volume passing through router 1 and 4 are low and therefore only a small portion of the attack traffic is detected. In particular the DDoS attack traffic does not pass through router 3, 8 and 11 and therefore no DDoS attack is detected.
DDoS attack detected (%)
4.2 Attack Traffic Generation
15 20 IDR enabled at software router 20
C
Software router x in subnet x
Cisco router connected other parts of HARNET-II Other hosts in the subnet
100 Mbits link
Figure 7. DDoS attack on the testbed. The DDoS attack detection module in IDR can detect exceptionally heavy traffic volume successfully as shown in
6 Summary and Future Work In this paper, we have introduced IDR for detecting DDoS attack and the testbed for performing experiments and analysis. We have shown that the DDoS attack detection mechanism using Bloom filter can successfully detect DDoS attack and identify the suspicious packets. This concludes that the first step in the IDR (Figure 1) has been successfully implemented. The currently IDR operates on traffic traces and we will port it into kernel modules and study the real time performance [4]. In future work, we will also investigate the classification of the detected traffic into legitimate and illegitimate traffic using statistical approaches and the possible reactions to these traffic. We will also perform experiments on different kinds of DDoS attacks, using different number of zombies and in different locations.
References [1] Paul Barford and Mark Crovella. Generating representative web workloads for network and server performance evaluation. In SIGMETRICS ’98 / PERFORMANCE ’98, Joint International Conference on Measurement and Modeling of Computer Systems, pages 151–160, Madison, Wisconsin, USA, June 1998. [2] Jason Barlow and Woody Thrower. Tfn2k an analysis. Information Security Bulletin, CHI Publihsing Ltd, March 2000.
Proceedings of the 7th International Symposium on Parallel Architectures, Algorithms and Networks (ISPAN’04) 1087-4089/04 $ 20.00 © 2004 IEEE
[3] Burton H. Bloom. Space/time trade-offs in hash coding with allowable errors. Communications of the ACM (CACM), 13(7):422–426, July 1970. [4] Eric Y. K. Chan and et al. Ddos attack detection and defense using routers (submitted to 13th usenix security symposium (security ’04)). [5] Michalis Faloutsos, Petros Faloutsos, and Christos Faloutsos. On power-law relationships of the internet topology. In Proceedings of the conference on Applications, technologies, architectures, and protocols for computer communication, pages 251– 262, Cambridge, Massachusetts, United States, August 1999. ACM Press. [6] National Laboratory for Applied Network Research (NLANR) http://dast.nlanr.net/Projects/Iperf, 2003. [7] Lee L. Gremillion. Designing a bloom filter for differential file access. Communications of the ACM (CACM), 25(9):600–604, September 1982. [8] Kevin J. Houle, George M. Weaver, Nell Long, and Rob Thomas. Trends in denial of service attack technology. CERT(R) Coordination Center, October 2001. v1.0. [9] Multi Router Traffic Grapher (MRTG) http://people.ee.ethz.ch/ oetiker/webtools/mrtg. [10] Comoputer Emergency Response Team (CERT) http://www.cert.org. [11] Yoohwan Kim, Wing Cheong Lau, Mooi Choo Chuah, and Jonathan H. Chao. Packetscore: Statistical-based overload control against deistributed denial-of-service attacks. In Proceedings IEEE INFOCOM 2004, The 23rd Annual Joint Conference of the IEEE Computer and Communications Societies, Hong Kong, China, March 2004.
[15] Kihong Park and Heejo Lee. On the effectiveness of probabilistic packet marking for ip traceback under denial of service attack. In Proceedings IEEE INFOCOM 2001, The Conference on Computer Communications, Twentieth Annual Joint Conference of the IEEE Computer and Communications Societies, Twenty years into the communications odyssey, volume 1, pages 338–347, Anchorage, Alaska, USA, April 2001. IEEE. [16] Jih-Kwon Peir, Shih-Chang Lai, Shih-Lien Lu, Jared Stark, and Konrad Lai. Bloom filtering cache misses for accurate data speculation and prefetching. In ICS 2002, Proceedings of the 2002 International Conference on Supercomputing, pages 189–198, New York City, NY, USA, June 2002. [17] Stefan Savage, David Wetherall, Anna R. Karlin, and Tom Anderson. Practical network support for ip traceback. In Proceedings of the ACM SIGCOMM 2000 Conference on Applications, Technologies, Architectures, and Protocols for Computer Communication, pages 295–306, Stockholm, Sweden, August 2000. ACM Press. [18] Alex C. Snoeren, Craig Partridge, Luis A. Sancheq, Christine E. Jones, Fabrice Tchakountio, Stephen T. Kent, and W. Timothy Strayer. Hash-based ip traceback. In Proceedings of the ACM SIGCOMM 2001 Conference on Applications, Technologies, Architectures, and Protocols for Computer Communication, pages 3–14, San Diego, CA, USA, August 2001. [19] Haining Wang, Danlu Zhang, and Kang G. Shin. Detecting syn flooding attacks. In Proceedings IEEE INFOCOM 2002, The 21st Annual Joint Conference of the IEEE Computer and Communications Societies, New York, USA, June 2002. IEEE.
[12] Abhishek Kumar, Li Li, and Jia Wang. Space-code bloom filter for efficient traffic flow measurement. In Proceedings of the conference on Internet measurement conference, pages 167–172, 2003. [13] Danielle Liu and Frank Huebner. Application profiling of ip traffic. In 27th Annual IEEE Conference on Local Computer Networks (LCN 2002), pages 220– 229, Tampa, Florida , USA, November 2002. [14] James K. Mullin. A second look at bloom filters. Communications of the ACM (CACM), 26(8):570– 571, August 1983.
Proceedings of the 7th International Symposium on Parallel Architectures, Algorithms and Networks (ISPAN’04) 1087-4089/04 $ 20.00 © 2004 IEEE
