Filtering techniques are one of the main approaches to protect applications from Denial of Service Attacks (DoS). However filtering techniques suffer from two ...
2009 Eighth IEEE International Symposium on Network Computing and Applications
Empirical Study of Tolerating Denial-of-Service Attacks with the Fosel Architecture∗ Hakem Beitollahi, Geert Deconinck Katholieke Universiteit Leuven, Electrical Engineering Department, Kasteelpark Arenberg 10, Leuven, Belgium {Hakem.Beitollahi and Geert.Deconinck}@esat.kuleuven.be
Abstract
filtered at routers. Examples include dynamically deployed firewalls [3], and some commercial systems [1, 6]. While filtering techniques may be appropriate for several types of DoS attacks, they are not always applicable or practical because they suffer from accurate attack detection and high cost of packet processing. Fosel architecture (Filtering with the help of an Overlay Security Layer) [2] is an efficient and well-suited filter that handels these problems. For achieving this propose, the Fosel architecture utilizes an overlay network, secret green nodes, access control techniques (authentication techniques), selective filter and some pre-defined rules. We have proposed the Fosel architecture in [2]. This paper implements Fosel and provides a test-bed to evaluate the Fosel architecture from the empirical perspective. Selective filter is implemented in C++ and is installed on the target computer. The test-bed includes legitimate clients and attackers (within DoS attack toolkits). There are two possibilities to attack the system: a) attack against an application site (the target) and b) attack against overlay network and green nodes (the architecture framework). This paper discusses only attacks against the application site (the target) and it does not discuss attack against the overlay network (our near future work). These practical work confirms simulation results [2] and provides an evidence for effectiveness of the Fosel architecture. The rest of the paper is organized as follows. In the following section, we briefly discuss the Fosel architecture. Section 3 describes the experimental environment and presents results. Section 4 concludes the paper.
Filtering techniques are one of the main approaches to protect applications from Denial of Service Attacks (DoS). However filtering techniques suffer from two main challenges: a) the accuracy detection of DoS traffic and b) processing time. Fosel (Filtering with the help of an Overlay Security Layer) has been proposed to protect application sites from Denial-of-Service attacks [2]. The Fosel architecture addresses how an efficient and well-suited filter can be designed to improve the filtering challenges. This paper explores the effectiveness of the Fosel architecture by implementing an experimental testbed. Experimental study shows that by employing the Fosel architecture, DoS attacks have a negligible chance to saturate the target by malicious packets. These results confirm simulation study of Fosel [2] and provide an empirical evidence that Fosel can be used to tolerate DoS attacks.
1 Introduction Denial-of-service (DoS) attacks are one of the key threats against availability in the Internet. The increasing numbers and variety of DoS attacks and distributedDoS (DDoS) attacks have become a growing annoyance to the network administrators and Internet service providers (ISPs) [8]. Filtering techniques are one of the main approaches that reactively protect application sites from DoS attacks [7, 5]. Filtering techniques use the characterization provided by detection mechanisms to filter out attack streams. In some cases malicious packets can be identified by clearly-defined metrics, e.g. obviously wrong source addresses or other obvious errors in the packet header. Such packet flows can be
2 The Brief Description of the Fosel Architecture This section presents the Fosel architecture in brief. See [2] for full description of the Fosel architecture. The goal of the Fosel architecture is to provide a wellsuited filter that can be installed on the target’s router to protect the application site (target) from DoS attacks. For
∗ Acknowledgements: This work has been partially supported by the K.U.Leuven Research Council (project GOA/2007/09) and by the European Commission (project IST-4-27513 CRUTIAL)
978-0-7695-3698-9/09 $25.00 © 2009 IEEE DOI 10.1109/NCA.2009.22
258
3 Experimental Environment and Results
achieving this propose, the Fosel architecture utilizes an overlay network, secret green nodes, access control techniques (authentication techniques), a selective filter and some pre-defined rules. Location of overlay nodes and application sites (IP addresses) are clear to the public and to the attackers. However a certain rules that a set of overlay nodes may be having are kept secret from public and attackers. The operational procedure of the Fosel architecture as follows: any application site (a user) connects a random overlay node to send a message, a request or data for any other application site (a target). The overlay node analyses and verifies the request by authentication techniques (such as IPsec, TLS, or smart cards). If the message is authorized successfully it is allowed to enter inside the overlay, otherwise it is dropped by the overlay node. After a legitimate message was verified by the overlay node, it is forwarded and routed through the overlay nodes to the secret green node of the target. The green node delivers the message to the target (final destination) through the selective filter (Fosel filter). Green nodes are secret nodes of the architecture. Our mean from secret is that the role of green node is kept secret from public and attackers and hence nobody knows which nodes are green nodes. The green nodes of each application site are selected by random. To activate a green node, the application site sends a message to the overlay node and informs it that it has been selected as a secret green node of the application site. A green node, upon receiving a packet from the overlay, forwards it to the destination through the selective filter. In the case of DoS attack, the green node delivers multiple copies of the message, otherwise delivers just one copy of the message. The selective filter has been installed on high-powered final routers and accepts only those packets whose come from the green nodes of the application site. Hence selective filter drops all other packets whose their source address does not match the address of its green nodes. The selective filter does not need to verify the signature and decrypt the data. It just need to see IP address of the message. If it (IP address) belongs to its green nodes, the message is accepted otherwise it is dropped. Second task of the selective filter is that in case of DoS attack rather than process all arriving packets, process only a subset of the received packets and drop all other packets without any processing. To ensure that legitimate messages are not lost the green nodes of the application site delivers multiple copies of each message. The second task of selective filter in other words: when under DoS attack, the green node on one hand replicates the legitimate message to be delivered C times, on the other hand the selective filter drops messages ( both malicious and legitimate) without processing them, with a given probability (1-P).
We have conducted a series of experiments to verify the ability of the Fosel architecture to mitigate the effects of DoS attacks. As mentioned before there are two possibilities to attack the system: a) attack against an application site and b) attack against the overlay network. This section implements the Fosel filter and provides a small testbed with some nodes to verify the Fosel filter. Attacking the overlay network is not mentioned here (it is near future work). Figure 1 shows high level overview of implemented testbed. In these experiments we suppose that clients’ requests (queries from legitimate application sites) have reached the green nodes of the target via the overlay network. Now some points: • Attackers know the IP (location) of the application sites (targets) • Attackers do not know the location of green nodes in the Fosel architecture. • We use socket programming on Windows for communication.
UDP
Chord Ring
TCP (Download data.pdf)
data.pdf
UDP
: User
: DoS attacker
: Ordinary overlay node
: Green overlay node
: Selective filter
: Target (server)
Figure 1: High-level overview of implemented testbed In the following we describe the key components used in the empirical study and the resources used in the experiments.
3.1
Software Environment
The experiments use four key software components: a generic simple filter for direct connection access, selective filter, a user interface to send any type of request to the server and a DoS attack toolkit.
259
3.1.1 Simple and selective filter
shows that by selecting smaller Ps, the response time is decreased.
The operational procedure of the selective filter has been explained in the description of the Fosel architecture [2]. Just a word about the simple filter: to understand and evaluate the basic performance of the Fosel architecture, we compare performance metrics for direct connection access and the Fosel architecture. In direct connection access, clients access an application site directly and without any interface such as overlay network (no green nodes are used). Direct connection access utilizes a simple filter that verifies the signature of the packet (RSA with 2048 bit) and in case of wrong signature drops the packet. Both the simple and selective filter have been implemented using C++ and installed on the server.
Response Time (Second) 111
3.5
1 0.5
Fosel (P= 0.15)
p=0.25
Fosel (P= 0.5)
Fosel (P= 0.75) Direct connection access
No attack
Probability of Packet acceptance
Figure 2: Average response time to download a file (size=671KB) A user’s message may fail to be processed by the target due to two reasons: a) the message may be lost due to huge amount of traffic. In our experiments if a message was not accepted by the receiver’s socket within 21 seconds, it is dropped automatically. We call this, network loss. b) Any message also is dropped with probability of (1-P) where P is the packet acceptance probability (due to the Fosel policy). Figure 3 shows failure rate for different values of C (number of message copies) when attack rate varies along the x-axis. In this experiment we hold P at 0.25 (it means 1/4 of packets are processed and 3/4 of packets are dropped without any processing). The experimental result shows that when the attack rate is increased the failure rate increases as well. This is evident because traffic is increased and more messages are lost by the socket timeout (network loss). Failure rate in the Fosel architecture is far less than direct connection access. In addition by choosing bigger C, failure rate is reduced more in the Fosel architecture.
We design a simple toolkit to generate user requests. This toolkit generates any type of request (http request, FTP request, and etc.) and then measures the response time for each of the request. This allows us to evaluate user access and collect statistics which characterize user experience performance. 3.1.3 DoS Attack Toolkit UDPFlood [4] is a UDP packet sender. It sends out UDP packets to the specified IP and port at a controllable rate. Packets can be made from a typed text string, a given number of random bytes or data from a file.
Physical Resources
Legitimate client runs on a node 1.7GHz PIV with 512MB main memory. Server runs on 2.4GHz PIV with 512MB memory. Attackers run on 10 nodes (1.7 GHz PIV, 512MB memory). All machines are connected by a 100Mbps Ethernet switch.
1
Experiments and Results
.
0.9 0.8
Failure rate
3.3
2 1.5
0
3.1.2 User Interface
3.2
3 2.5
0.7
Fosel (C = 3)
0.6
Fosel (C = 5)
0.5
Fosel (C = 10)
0.4
Fosel (C = 15)
0.3
Direct connection access
0.2 0.1 0 0
In the experiments, a user tries to download a pdf file (size=671 KB) by FTP protocol. We study the performance of the system by two measurement metrics: response time and failure rate. Figure 2 shows the average response time for a user (client) to download a file of given size (671KB). The x-axis is the probability of message acceptance (P). The attack rate is fixed at 5000 packets/second (about 60 Mbps). The Fosel architecture has faster response time than direct application access. Results show that the Fosel architecture improves response time more than 60% (in average) compared to direct connection access in case of DoS attacks. The result
20
40
60
80
100
Attack rate (Mbps)
Figure 3: Failure rate vs. attack rate Figure 4 shows response time (downloading a 671KB pdf file) for different values of P when attack rate varies along x-axis. Response time is increased when attack rate is increased because more malicious packets are processed before the legitimate request is processed. It shows that response time is decreased when a smaller P is selected because less malicious packets are processed.
260
Response Time (Sec) 111
4 Conclusion
5 4.5 4 3.5 3 2.5 2 1.5 1 0.5 0
Fosel (P= 0.15) Fosel (P= 0.25) Fosel (P= 0.5) Fosel (P= 0.75) Direct connection access
0
20
40
60
80
100
Attack Rate(Mbps)
Figure 4: Response time vs. attack rate Table 1: Correlation of simulation and empirical results hhhh hhh of message copies hhhNumber hhh C=3 hhhh hhh Pearson Coefficient h rxy 0.854876
C=5
C = 10
C = 15
0.935327
0.813114
0.871521
So by selecting a suitable values for P and C, we can have an efficient and fast filter against DoS attacks.
To evaluate the performance and DoS resilience capability of the Fosel architecture, we implement a small test-bed within real DoS attack toolkits. Fosel is a fast and wellsuited filter against DoS attacks that accept data only from secret green nodes. In case of DoS attacks, it drops any packet (both malicious and legitimate) with a probability, in the other hand the green node replicates the legitimate message to be delivered multiple times. Experimental results show that the Fosel architecture is a promising technique for mitigating the effects of even large DoS attacks. Results show that the Fosel architecture improves response time more than 60% (in average) compared to direct connection access. Results also show that failure rate in the Fosel architecture is far less than direct connection access. This paper shows experimental results have strong correlation with simulation results as well.
References 3.4
Comparison of empirical and simulation results
[1] Arbor Networks, http://www.arbornetworks.com. The peakflow platform. Visited at July 2008. [2] H. Beitollahi and G. Deconinck. Fosel: Filtering by helping an overlay secure layer to mitigate dos attacks. In Proceedings of the 7th IEEE Int. Symp. on Network Computing and Applications (NCA-2008), pages 19–28, Cambridge, MA (USA), July 2008. [3] T. Darmohray and R. Oliver. Hot spares for DDoS attacks. http://www.usenix.org/publications/login/20007/apropos.html. [4] R. Kier. UDPFlood 2.00. www.foundstone.com/us/resources/proddesc/udpflood.htm. visited at July 2008. [5] J. Li, J. Mirkovic, M. Wang, P. Reiher, and L. Zhang. Save: Source address validity enforcement protocol. In Proceedings of the 21st Annual Joint Conference of the IEEE Computer and Communications Societies (INFOCOM’02), New-York, USA, June 2002. [6] Mazu Networks, http://www.mazunetworks.com/white papers. Mazu technical white papers. Visited at July 2008. [7] J. Mirkovic and P. Reiher. D-ward: Source-end defense against flooding denial-of-service attacks. IEEE Transactions on Dependable and Secure Computing, 2(3):216–232, JulySeptember 2005. [8] D. Moore, G. Voelker, and S. Savage. Inferring internet denial-of-service activity. ACM Transactions on Computer Systems (TOCS), 24(2):115 – 139, May 2006.
Fosel architecture was evaluated by simulation as well [2]. Simulation results and empirical results confirm each other. Let us to show how empirical results correlate with simulation results. In probability theory and statistics, correlation, indicates the strength and direction of a linear relationship between two random variables. A correlation coefficient indicates how much two variables are close together. Pearson correlation coefficient is one of best known coefficients that we use here. If we have a series of n measurements of X and Y written as xi and yi where i = 1, 2, ..., n, then the Pearson correlation coefficient can be used to estimate the correlation of X and Y . The Pearson correlation coefficient is written: rxy = p
nΣxi yi − Σxi Σyi p nΣyi2 − (Σyi )2
nΣx2i − (Σxi )2
(1)
Table 1 shows Pearson correlation coefficient for empirical and simulation results. Elements of table are correlation coefficients where simulation results are indicated by X set and experimental results are indicated by Y set. In the table the correlation has been shown for the experiment: failure rate is versus attack rate for different numbers of message copies. In fact table 1 shows that there is strong covariance between experimental and simulation results. Table 1 indicates that in all cases, Pearson correlation coefficient is more than 80% which means that empirical results confirm simulation results and vice versa.
261
