240 likes | 341 Views
Low-Rate TCP Denial of Service Defense. Johnny Tsao Petros Efstathopoulos Tutor: Guang Yang UCLA 2003. What is a Low-Rate DoS Attack?. Floods bottleneck with packets to overflow queues and produce dropped packets
E N D
Low-Rate TCP Denial of Service Defense Johnny Tsao Petros Efstathopoulos Tutor: Guang Yang UCLA 2003
What is a Low-Rate DoS Attack? • Floods bottleneck with packets to overflow queues and produce dropped packets • TCP connections senses congestion and waits retransmission timeout (one second) • While TCP connections are waiting the timeout, the attacker does not need to attack • It then resumes attacking after waiting the RTO • The attacker has a low throughput relative to traditional DoS attackers so it can avoid detection
Proposed Solution • Randomize the RTO so that we start retransmitting in between attacks • This should help improve throughput • Various possible randomization techniques: simulations show that choice doesn’t make significant difference
Related Works • A. Kuzmanovic and E. W. Knightly, Low-Rate TCP-Targeted Denial of Service Attacks (The Shrew vs. the Mice and Elephants), In Proceedingsof ACM SIGCOMM 2003, Karlsruhe, Germany, Aug. 2003 • G.Yang, M.Gerla and Y.Sanadidi, Randomization and Probing: Defense against Low-rate TCP-targeted DoS Attacks, UCLA Computer Science Department, Internal Draft • These papers run simulations only, we will test their findings with experiments
Our Task • Analyze the effectiveness of randomized RTO against a low-rate TCP DoS attack • Evaluate effectiveness by performing experiments on a TCP testbed using DummyNet to simulate an internet bottleneck • Compare experimental results to simulation results
The Linux Kernel • Linux implements TCP New Reno • The Linux kernel actually uses a minimum RTO of 200ms (max is 120sec) • This reduces the effectiveness of a low-rate attack since it must transmit more often, leaving it more susceptible to detection
The Linux Kernel (cont) • Linux uses the value of RTOmin to initialize the value of rttvar when a new connection is establised • Setting RTOmin to 1sec heavily affected rttvar • Solution: bound the value of RTO dynamically without changing the defined values that affect rttvar
Linux Kernel Modifications • Kernel 1: make minimum RTO = 1sec in order to match the papers by Knightly and Yang • Kernel 2: Randomize RTO around 1sec to see if randomization can defend against a low rate attack
Experiment Setup • Sender, Receiver - iperf client and server to produce TCP traffic • Attacker - Custom UDP traffic generator: 3MBit/s attack, 50 byte packets • DummyNet simulates internet bottleneck - 1.5MBit/s link - 40ms propagation delay - 50 slot queue
The Square Wave Attack(approximates a Low-rate TCP DoS Attack) Burst Length Inter-burst Period
Experiments • 4 sets of experiments • Set 1: standard Linux kernel behavior • Set 2: modified “1sec” Linux kernel behavior • Set 3: modified “1sec – randomized RTO” Linux kernel behavior For each set we measured throughput for interburst periods (IBPs) ranging from 0.3sec to 5sec (burst length and network parameters were kept constant) • Set 4: all kernels measured under attack for different burst lengths
Experimental Results – I • The standard Linux kernel is vulnerable, but a high rate attack is needed (minRTO is 200ms)
Experimental Results – II • Changing the minimum value of RTO to 1sec makes the attack very effective!
Experimental Results – III • Randomizing the value of RTO in the “1sec” kernel (randomization ranges from -0.5 to +0.5) significantly improves performance (connection NOT throttled for IBPs of 0.5s and 1s)
Experimental Results – IV • Randomization eliminates the throughput throttling problem for IBP values of minRTO/2 and minRTO • Experimental results confirm simulation results
Experimental Results – V • The burst length greatly affects the effectiveness of the attack
Our Findings • Low-Rate TCP DoS attack relies heavily on RTO synchronization • Attack targets low RTT connections • Randomization of RTO improves throughput greatly (especially in the vulnerable cases of 0.5s and 1s)
Our Findings - II • The effectiveness of the attack depends a lot on the synchronization of the sender and the attacker • Performance results for certain cases fluctuated greatly for consecutive runs of the same experiment. Possible reasons: Dummynet buffer management, synchronization issues between the attacker and the sender
Conclusions • The experimental results coincide with the findings of papers by Knightly and Yang • Randomization is an effective way to reduce the damage done by a Low-Rate TCP DoS attack • Such an attack may not be realistic if modern systems implement a low RTO (ie. Linux’s 200ms RTO)
Future Work • Determine the fairness of the RTO randomization scheme • Explore probing as a defense against a Low Rate TCP DoS attack • Examine the attack and defense results with multiple TCP flows
References • A. Kuzmanovic and E. W. Knightly, Low-Rate TCP-Targeted Denial of Service Attacks (The Shrew vs. the Mice and Elephants), In Proceedingsof ACM SIGCOMM 2003, Karlsruhe, Germany, Aug. 2003 • G.Yang, M.Gerla and Y.Sanadidi, Randomization and Probing: Defense against Low-rate TCP-targeted DoS Attacks, UCLA Computer Science Department, Internal Draft • Pasi Sarolathi, Alexey Kuznetsov, Congestion Control in Linux TCP • D. Bovet and M. Cesati, Understanding the Linux kernel, O’Reilly press 2003