Low-rate TCP-targeted Denial of Service Attack Defense

Transcription

1 Low-rate TCP-targeted Denial of Service Attack Defense Johnny Tsao Petros Efstathopoulos University of California, Los Angeles, Computer Science Department Los Angeles, CA {johnny5t, ABSTRACT Low-rate TCP targeted denial of service attacks are a subset of DoS attacks that exploit the retransmission timeout (RTO) mechanism of TCP. In doing so, such an attack can drastically reduce throughput while producing little traffic relative to traditional DoS attacks. Since it produces only periodic traffic, a low-rate attack is difficult to detect and prevent. Another property of the periodic traffic, however, is that a low-rate attack s success depends on synchronization with the victim s RTO. A proposed defense to this attack is to randomize the RTO. In doing so, information can still be transmitted while the attacker is waiting and a connection will be able to avoid timing out successively. In this paper, we evaluate the effectiveness of randomizing the retransmission timeout in defending against low-rate TCP targeted denial of service attacks. Through experiments we show that such a defense can prevent a TCP flow from being throttled by a low-rate attack and still achieve respectable throughput. In addition, we will analyze the effectiveness of a low-rate DoS attack on the implementation of TCP.. INTRODUCTION As the prevalence and use of networks grow, so too will the number of people attempting to exploit them, whether for personal gain or simply malicious intent. Therefore, the issue of network security and protection will only gain importance in today s society and the future. A Denial-of-Service (DoS) attack is one such exploit/attack present in networks today. A DoS generally floods a network or link with traffic with the goal of denying other users access to specific nodes, resources, or services. Such resources include memory, bandwidth, or CPU cycles. The problem with traditional DoS attacks is that their network behavior of flooding links does not correspond with regular network traffic. Therefore, one can often detect a DoS attacker by analyzing the network traffic. In addition to detection, mechanisms can be added to routers to prevent DoS attacks from affecting a network by blocking such traffic. A different type of DoS attack was introduced in []. A low-rate TCP targeted DoS attack produces the negative effects of a typical DoS attack, except it targets TCP flows and can often elude detection since it sends traffic at a relatively low average rate. It does so by exploiting TCP s retransmission timeout mechanism. TCP s retransmission timeout mechanism is intended to deal with cases of severe congestion and multiple losses. If a sender fails to receive an ACK after the timeout period, it reduces its congestion window to one and retransmits the packet. In correspondence with the recommendation made by [3], many systems implement a minimum RTO of second. It is this implementation that puts these systems at risk since a low-rate DoS attack can exploit it. A low-rate DoS attack will flood the network with an initial burst of packets. This burst fills up the queues and results in packet loss for legitimate TCP connections. These connections, after waiting the timeout for an ACK, reduce their windows and retransmit. While the TCP connections wait for ACKs that aren t coming, the low-rate attacker does not need to attack. It can simply wait the RTO (one second) and start flooding the network again, exactly when the TCP connections try to retransmit their packets. In doing so, a low-rate attack can throttle a TCP connection s throughput to nearly zero.

2 In this paper, we will study the effectiveness of randomizing the RTO in defending against a low-rate TCP targeted DoS attack. We will first give an overview of related work on this topic. In section 3, we shall take a closer look at TCP s timeout mechanism. We will analyze the timeout mechanism to find out why it exists and how it works. This will give us insight as to how it is exploited. Section 4 will go over the low-rate DoS attack. We will study the properties of such an attack and see how it takes advantage of the timeout mechanism. We will present the proposed solution of randomizing the RTO in section 5. We will then look at the changes we had to make to the kernel in section 6. After, section 7 will present and analyze our experimental results showing the effectiveness of the randomized RTO defense. Section 8 will present our conclusion and a summary of our results. Lastly, section 9 will discuss future work. 2. RELATED WORKS Our work is mostly based on two papers. The first one is Low-Rate TCP-Targeted Denial of Service Attacks by Kuzmanovic and Knightly. This paper introduced the low rate attack and proposed randomizing the RTO as a solution. The second paper is Randomization: Defense against Low-Rate TCP-Targeted Denial-of-Service Attacks by Yang, Gerla, and Sanadidi. In this paper, they researched both randomization of RTO and probing as defenses against a low rate attack. Both papers do simulations to back up their work. For our paper, we have implemented the randomized RTO defense in. We then run experiments to confirm the results seen in these other works. In addition, we see how the regular kernel behaves under a low rate attack. 3. TCP TIMEOUT MECHANISM 3. TCP Congestion control: Timeout Mechanism Congestion control is essential for TCP. TCP congestion control operates in two timescales depending on the degree of the link s congestion. On smaller timescales of round trip times (RTT) TCP performs additive-increase multiplicative-decrease (AIMD) control with the objective of having each floe transmit at the fair rate of its bottleneck link. At times of severe congestion in which multiple losses occur, TCP operates on longer timescales of Retransmission Time Out (RTO). In this study we are interested in the timeout mechanism of TCP which what the Low-Rate DoS attack tries to exploit. The TCP congestion control mechanism uses the notion of congestion window (cwnd). Each TCP sender uses the congestion window to regulate the rate of transmission based on the feedback it gets from the network. The congestion window is the TCP sender s estimate of how much data can be outstanding in the network without packets being lost. Each receiver can advertise a window size. The sender takes into account this advertised window size and chooses as window size the minimum of the two: advertised window and congestion window. This mechanism helps avoid congestion since both the receiver s capabilities and the networks characteristics are taken into account. After a period of congestion TCP enters the slow-start phase: it shrinks its congestion window to segment and increases it by one every time an acknowledgement is received. If on the other had less than three duplicate ACKs are received before RTO expires, TCP shrinks its congestion window to segment (slo start), doubles the value of the RTO (exponential backoff) and retransmits the lost packet. Under heavy congestion, TCP reduces its congestion window size to segment and sets the RTO to its minimum value. The recommended minimum value for the RTO is sec, as proposed by the study presented in [3]. This mechanism was chosen for dealing with cases of heavy congestion since it is the most conservative sender behavior. If the RTO expires and the packet is lost again the exponential backoff continues and the sender doubles the value of RTO (RTO=2) and retransmits the packet. The sender then waits for the 2sec RTO to expire and if the packet still hasn t been transmitted successfully the exponential backoff continues (RTO is set to 4sec and so on). 3.2 Vulnerability Although this mechanism is well suited for dealing with high congestion, it has a

3 fundamental flaw. The values of RTO are predefined constants. The minimum value is sec and the possible RTO values during exponential backoff are multiples of sec. This property of the algorithm makes the system vulnerable to attacks that use a short high rate burst of packets to fill the bottleneck buffers, right before the RTO expires. An attacker that knows the timing of the sender can use a square wave attack (high rate, short duration bursts) and force the sender to repeatedly enter the retransmission timeout state, while the throughput achieved by the sender will be nearzero. 4. THE LOW-RATE ATTACK A low-rate TCP-Targeted denial of service attack has three properties: a send rate, a burst length, and an inter-burst period. The send rate is obviously the rate at which the attacker sends packets into the network. This rate must be higher than the bandwidth of the bottleneck link in order to produce packet loss and cause TCP flows to timeout. The burst length is how long the attacker floods packets for each burst. This depends on the send rate, RTT of the flows, and bandwidth of the bottleneck. If the burst length is too long, then the attacker risks being detected. It was suggested in [] that a burst length less than 3ms would allow the low-rate attacker to go relatively undetected. Our own experiments show that a burst length of 2ms is sufficient to produce zero throughput with the proper interburst period, so we do not have to worry about going over this threshold. The inter-burst period dictates the frequency at which the attacker floods packets. An attacker would want to pick an inter-burst period that corresponds exactly to the RTO. In this way, the attacker can throttle the throughput while transmitting the least amount of data possible to reduce the chances of detection. The low-rate DoS attack can be viewed as a square wave like in Figure. It bursts packets at a set rate for a set time and then waits out the inter-burst period before bursting again. It does so in the hopes that subsequent bursts will occur just as victim flows begin retransmission. rate burst length inter-burst period Figure : a low-rate attack can be approximated as a square wave 5. RANDOMIZED RTO DEFENSE One possible defense against low-rate TCP-targeted DoS attacks is proposed by []. If the minimum value of the RTO is not set to sec, but instead it is randomized around sec, we could expect the effect of the attack on the throughput to be less severe. Simulation results by [2] show that randomization of the RTO is indeed a possible solution. When the value of RTOmin is randomized around sec, it is more difficult for the attacker to synchronize its square wave attack with the RTO expiration intervals. Thus the attacker can no longer predict the time the new packets will arrive and flood the buffers with a properly timed burst. Although TCP uses predefined backoff values for the RTO (,2,4,8,,64), randomized backoff intervals are used in other protocols, especially link layer protocols that use similar exponential backoff schemes (e.g. Ethernet). Such protocols use a random timeout value within a certain range. There are three different ways one could choose to randomize RTOmin. Each one uses a different range of possible values. The most conservative approach would be to pick a number in the range [t, t+). This will overestimate the RTO. Alternatively, we could choose a value within the ranges [t-, t+) and [ t,.5 t). Simulations and analysis done by [2] show that the range of randomization does not affect the results significantly. For the rest of this paper we assume that any randomization of the timeout is done using a value within the [t-, t+) range.

4 6. THE LINUX KERNEL 6. TCP congestion control The kernel currently implements TCP New Reno. Although many optimizations have been incorporated in the TCP stack, the congestion control mechanism is essentially as defined by TCP New Reno. One issue of great interest to our study is the fact that allows a minimum value of 2ms for the RTO. This deviates from the standard approach of sec RTOmin and makes it harder for potential Low-Rate attacks to succeed. This is because in order to attack effectively using the Low-Rate attack model, one would have to generate an attack square wave with inter-burst period of 2ms. In order to fill the bottleneck buffers using such a short IBP, the attacker would have to use a very high rate. Such an attack is difficult to achieve and the average attack rate would be high enough for DoS defense mechanisms to detect. 6.2 kernel changes Although is less vulnerable because of its 2ms RTOmin, the vulnerability in the design of the TCP timeout mechanisms is existent and other systems may be susceptible to this attack. We wanted to test the effectiveness of the attack on real systems and try to reproduce the results of the simulations. In order to do this we had to do a series of modifications to the kernel. We used two versions of the kernel. The first version was modified so that the minimum value of RTO was bounded to sec. Bounding RTOmin to sec was necessary to test the effectiveness of the attack. RTOmin is defined in the kernel as 2ms. Changing this definition triggers a series of unwanted changes, the most important of which being the improper initialization of rttvar (round trip time variance). In order to bound the minimum value of RTO we had to make sure that it adjusted every time RTO is calculated from the values of srtt (smoothened RTT) and rttvar. Also the function that is used by to check the upper bound of the RTO (tcp_bound_rto()) had to be modified so as to included lower bound checking as well. The second version of the kernel is based on the sec RTO kernel with the addition of randomization. We modified the previous version so that the value of RTO is randomized within the range [t-, t+). The minimum value of the RTO is first adjusted so that it is not below sec. Afterwards a random number is generated using the kernel s random number generator. This number is then combined with the value of RTO to produce the effective timeout that is randomly selected from the desired range. We must note that the values of RTO, RTT, rttvar etc are measured in jiffies. One jiffy is the resolution of the software timer and for the x86 architecture it is ms. The minimum value of RTO was bounded to jiffies (sec) and it was randomized in the range of [5,5) jiffies. The randomized kernel was used to measure the effectiveness of the attack and compare it with the results from the measurements taken with the sec RTO kernel. 7. EXPERIMENTAL RESULTS 7. Experimental Setup We conducted our experiments on a TCP test-bed. We had a sender, receiver, and attacker. We connected the sender and attacker to the receiver through an intermediate node running DummyNet. We used DummyNet to simulate the internet. The setup looks like Figure 2. Figure 2: Test-bed setup

5 The sender and receiver are implemented by running Iperf as a client and server in order to generate TCP traffic. The pipes connecting the sender, attacker, and receiver have a bandwidth of.5mbits/s and a queue of 5 slots. In addition, the RTT was 4ms. We programmed a custom attacker to produce a low-rate attack. It generates 3Mbits/s of traffic in periodic bursts of specified lengths and inter-burst periods. We ran a set of tests for each kernel variation: regular, second RTO, and second randomized RTO. We ran each test for 2 seconds. We allowed the sender to transmit for 2 seconds before starting the attacker. The attacker transmitted at 3 Mbits/s for 2ms while we varied the inter-burst periods. The important inter-burst period values are at and second. This is because they coincide with the RTO of second that was proposed in [3]. 7.2 Results The first test we ran tested how the regular kernel reacted to a low-rate attack. We expect the attack to be less effective since the attacker is specifically aimed at systems with an RTO of second while has an RTO of 2ms. It is interesting to see how it will react under an attack. The throughput graph is presented in Figure Figure 3: Kernel Attack No Attack We see that the throughput is similar to what we would expect to see for a regular DoS attack. As the burst frequency gets higher (lower inter-burst period), the throughput drops. The reason that the throughput never drops to zero is because our attacker is geared toward a system with a minimum RTO of second. We could produce an attacker that attacks with an interburst period of 2ms, but it would have to have a much shorter burst length and much higher burst rate. With such a short inter-burst period, such an attacker may not be stealthy. The next test we ran was on our modified kernel with a second RTO. Figure 4 shows the results of this test Figure 4: s RTO Kernel Attack No Attack With this kernel, we see that there is a major drop in throughput for inter-burst periods of and second. These results agree with the simulation results reported by [] and [2]. Since the retransmission timeout is set to second, each retransmission encounters packet loss because the attacker is transmitting at the same time. If the inter-burst period is not synchronized with the RTO, however, we see that throughput can be achieved. This is evident in the throughput values for inter-burst periods that are not even divisors of second. One thing we must clarify is the fact that we did see a very small throughput at the and s inter-burst periods. This is simply due to the fact that we allowed the sender to transmit for 2 seconds before engaging the attacker. Once the attack began, throughput was throttled to zero for both of these cases. After, we tested our modified kernel which randomizes the RTO between t- and t+ seconds. This produces RTOs that average to t seconds, yet do not allow a low-rate attack to know when it will try retransmitting. The results are shown in figure 5.

6 Attack No Attack Figure 5: Randomized RTO Kernel As you can see, the throughput for the randomized RTO kernel is dramatically better than the s RTO kernel for attacker inter-burst periods of and second. In fact, at the second inter-burst period, we see that the randomized RTO kernel produced a throughput of nearly 4%. This is very good considering that the attacker is flooding the network 2% of the time. In addition, it is a significant improvement from the s RTO kernel which had zero throughput at this point. Figure 6 shows how the different RTO implementations stack up against each other s RTO Random RTO Figure 6: Comparison Again we see that by using a randomized RTO, we do not suffer throughput throttling. In order to throttle the throughput of our modified kernel, an attacker would simply have to resort to a standard DoS attack that constantly transmits. This would not be stealthy since it could be detected relatively easily. Therefore, we see that randomization is a very effective defense against a low-rate DoS attack. burst rate at 3Mbits/s for each test run. The results can be seen in figures 7 through Burst Length (ms) s Kernel Randomized Figure 7: s Inter-burst Period s Kernel Randomized Burst Length (ms) Figure 8: s Inter-burst Period s Kernel Randomized Burst Length (ms) Figure 9: Averaged of s and s From these tests we see that using a burst length of 2ms is just about right to throttle throughput in the s RTO kernel. In addition, we see that the randomized RTO performs better than a s RTO in these zero throughput cases. We conducted one last test. We looked at inter-burst periods of and s and varied the burst lengths from 5 to 2ms. We kept the

7 8. CONCLUSION The design of TCP congestion control mechanism incorporates a statically defined timeout mechanism. Although other protocols use randomization techniques when choosing the value of the retransmission timeout, TCP uses multiples of sec. during its exponential backoff stage. This design makes TCP vulnerable to a Low-Rate attack. Current DoS attack defense mechanisms can not detect this kind of attack since the average attack rate is very low. Using our implementation we were able to test the effectiveness of this attack for three different platforms: the standard kernel, the modified sec RTOmin kernel and the randomized RTO kernel. Our experimental results confirm the simulation results. Systems using a minimum value of sec for the RTO can be heavily affected by a Low-Rate attack. When the attacker is synchronized with the sender (Inter-burst periods of s and s), the throughput is throttled. Experiments using the randomized RTO kernel show that the proposed defense against this type of attack can greatly improve performance. Randomizing the value of RTO eliminates the throughput throttling problem for IBPs of s and s. In the s IBP case in particular we achieve 4% of the link s maximum throughout, while under attack. 9. FUTURE WORK Our first experiments showed that randomizing the value of RTO provides defense against the Low-Rate attack. For our experiments we had to modify the kernel so that the lower bound for the value of RTO is s, instead of 2ms. We would like to test our approach with other operating systems and verify whether any of the popular TCP stack implementations uses RTOmin of s and thus is vulnerable to the attack. Experiments with BSD, Solaris and Microsoft Windows would show to what extend this attack is a threat for real systems. Our next set of experiments will focus on the fairness of the randomized kernel. Changing the value of RTO may affect the fairness of the system when multiple connections are present. We should also test the effectiveness of the randomized kernel defense against the attack with multiple long-term TCP flows as well as dynamic highly variable flows such as HTTP traffic. Finally, we would like to implement an alternative solution to this attack, using probing. A comparison between the effectiveness of the two defense mechanisms would be of great interest.. REFERENCES [] A. Kuzmanovic and E. Knightly. Low-Rate TCP-Targeted Denial of Service Attacks. In Proceedings of ACM SIGCOMM 3, Karlsruhe, Germany, August 23. [2] G. Yang, M. Gerla, and M.Y. Sanadidi. Randomization: Defense Against Low-Rate TCP-Targeted Denial of Service Attacks. Internal draft, 23. [3] M. Allman and V. Paxson. On Estimating End-to-End Network Path Properties. In Proceedings of ACM SIGCOMM 99, Vancouver, British Columbia, September 999. [4] P. Sarolathi and A. Kuznetsov. Congestion Control in TCP. [5] D. Bovet and M. Cesati. Understanding the kernel, O Reilly Press, 23. One issue that we need to look into, is to whom exactly is this attack targeted to. We need to consider what are the real-life scenarios where the Low-Rate attack can actually be launched, what is the target going to be and to what extent will it affect network performance.