CS244 ’13: Low Rate TCP-Targeted DoS Attack

Joseph Wen (tywen@stanford.edu)  and Tim Hiseh(timhsieh@stanford.edu)

Introduction

Denial of Service attack (DoS) works by forcing a victim host to waste its finite resources (computational power, network bandwidth, …) on useless tasks, thus denying legitimate requests from being processed. Usually, attackers implement this attack by employing a large number of “zombie” computers to send garbage requests. While this approach is effective, the attack will leave noticeable clues such as large throughput and large number of trash packets. Therefore, the attack may be identified and mitigated.

In the paper “Low-Rate TCP-Targeted Denial of Service Attacks”[1], the authors proposed a low rate DoS attack without these side effects by exploiting the standard TCP congestion control mechanism. More specifically, the attacker overflows the bottleneck link only when the sender is re-transmitting. As a result, the re-transmitted packets will be dropped, and sender’s packets will not reach the receiver. Therefore, attacker’s overall attack traffic rate can potentially be significantly lowered by selecting the correct time to stop re-transmission. This property makes TCP targeted attack more difficult to detect than “regular” Dos attack. The administrator can no longer look for traffic spike to determine the presence of DoS attack.

The original authors demonstrated this attack on networks with: a single TCP flow, a set of TCP flows with same RTT, a set of TCP flows with different RTT, and a set of HTTP flows. They also showed that variants of TCP such as New Reno and Sack are also vulnerable to this attack. Due to time constraint, we chose the following experiments to reproduce.

• A single TCP flow
• A set of TCP flows with a same RTT
• A set of HTTP flows

They are representative in demonstrating the effectiveness of the attack.

Experiment Setup

In theory, the same concept should work regardless of which simulator we use. Therefore, to save time, we decided to use our already installed simulator: Mininet. Our simulator is running on Amazon’s EC2 with at least *.medium size instances.

Topology:

All of the following experiments use the above topology. All data  flows from left to right. The link between the two switches is the bottleneck link that we want to overflow.

Experiments

Single flow

This experiment tests whether the low-rate DoS attack proposed in the paper can disrupt a single long lived TCP flow. This test shows that the basic concept behind low-rate attack is possible.

Experiment is run roughly as follow:

for period in [0.5 0.6 0.7 ...]:
  - Start a long lived TCP flow from Good Sender 
    to Good Receiver
  - baseline = Measure TCP speed for 3 seconds
  - Start "Attack" by having Bad Sender send UDP 
    packets to Bad Receiver(p = period, 
    burst = 0.3sec)
  - Attacked = Measure Attacked for 30 seconds

The paper’s graph is on top, and our graph is on the bottom

The x-axis is the inter-burst period, and the y-axis is the throughput normalized with respect to the bottleneck link capacity. In both graphs, there is a visible declined in throughput when the period of attack reaches 1 second in both graphs. In addition, both graphs show the effectiveness of attack reduces as we increase the period of attack to more than 1 second.  Based on the graphs above, we believe we have reproduced the paper’s result.

Homogeneous TCP Flows

This experiment tests a scenario is closer to real world. More specifically, the original authors attempt to attack 10 TCP flows instead of 1 flow. The experiment is run in the same way as before. The only difference is the number of TCP flows we start. All TCP flows use the same initial RTO.

The paper’s graph shows the aggregated throughput of the TCP flows normalized with respect to the bottleneck link rate capacity, over a range of attack periods. In this test, we expect the TCP flows to behave similarly as the single flow case. Since all flows have the same initial RTO and start at the same time. If an attack works for one flow, it should in theory works for all flows as shown in the paper’s graph.

In our graph, the general shape is similar to the paper’s graph. Throughput increases as we increase the periods of attack. Even though we did not see a near zero throughput near 1 second period, our graph showed a visible decrease in throughput at that time. A possible explanation is that our version of BIC TCP increases RTO slightly differently than the paper’s TCP Reno. The paper’s RTO is max(minRTO, SRTT+ max(G, 4RTTVAR)). However, our tests with minRTO = 1sec, SRTT = 0.1sec. G = 0.1sec, and RTTVAR = 0.1sec gives us an RTO of greater than 1. Due to this difference, it is not deterministic whether our attack would succeed.

HTTP Flows

This experiment resembles the real world even more than the last case. The original authors attempt to attack a set of TCP flows that represents HTTP connections. The test is run as follow.

def get_baseline(obj):
  for 10 times:
    - Start N TCP connections to download these 
      objects from Good Sender to Good Receiver 
       and return the times it takes for each. 

  - Return the average to download each object size

def get_times(obj):
  for 10 times:
    - Start N TCP connections to download these 
      objects from Good Sender to Good Receiver and 
      return the times it takes for each.

  - Return the time to download each object 
    separately

def main():
  - Randomly choose N objects with different sizes
  - Get Baseline to download N objects. 
    (get_baseline)
  - Start "Attack" by having Bad Sender send UDP 
    packets to Bad Receiver(period = 0.9sec, 
    burst = 0.3sec)
  - Measure the times to download N objects. 
    (get_times)

The paper’s graph is on top, and our graph is on the bottom.

The paper’s graph shows that in general all TCP connections are slowed down due to attack. Some connections speed up due to other connections backed off.

We were not able to reproduce the graph shown in paper.  We interpret our results as follows: The low-rate UDP attack regularly occurs once every  1 second and last for 0.3 seconds. Any flow (regardless of file size) that starts sending when attack is present will be DoS’d . This is because all subsequent re-transmissions will be dropped since re-transmissions are synchronized with our attack.  However, the flows that start when the attack is not present may or may not be affected since re-transmissions are not synchronized with our attack.

It is unclear how the paper tests the attack when testing with HTTP flows. More details on the methodology may make the attack more effective.

Challenges

The biggest challenge that we encountered was that it was difficult to accurately take measurements. For example, In our first attempt to measure the link rate, we take system time, read amount of data transferred by each of the link, and take the time stamp again. This method proves to be incaccurate since the it takes too long to read each link’s transferred bytes. The time calculated for the first link would seem significantly larger than it actually is. We mitigated the problem by taking the time stamp separately for each link. This solution allows us to produce sufficient accurate result but does not completely eliminate the problem. In addition, our simulation is run on EC2, which means our instance of VM can be swapped out and delayed for an arbitrary amount of time. When we used t1.micro for early testing, these arbitrary delays resulted in random time spikes in our tests. We solved this problem by using a larger instance (*.medium or higher).

Another problem we faced was that the TCP described in the paper behaves differently from  the version that we tested with.  As mentioned before, in the paper a TCP sender’s RTO is max(minRTO, SRTT+ max(G, 4RTTVAR)). However, our tests with minRTO = 1sec, SRTT = 0.1sec. G = 0.1sec, and RTTVAR = 0.1sec gives us an RTO of greater than 1. As a result, we were not able to attack successfully initially. We mitigate this problem by manually decrease the RTO by 0.1 second rather than set it to 1 second as specified in the paper. Another example, our version of TCP defaults minRTO to 300ms. However, the paper’s TCP has 1sec as minRTO. As shown in the additional graph section, this difference causes our attack to fail.

Discussion

We feel that while the paper provides a novel approach to DoS attack. The approach does not seem practical in real world and thus poses little threat. In order to DoS a website, one must first find a bottle link that all clients to that website will flow through. Then, attacker must be able to hold a connection over this link. Typically, attacker cannot achieve either of the conditions. End users do not know the typology of the Internet. In addition, attackers have no control over the which path the packets will travel to ensure sending packets over the bottleneck link. Even if the attacker is able to achieve both conditions, the attack would not be effective against most of the Internet traffic : short flows. In comparison, the traditional DDoS attack is much easier to use and much more effective. The victim’s IP address is public. One thousand zombie machines costs only $25 [2]. Given the low cost and simplicity, traditional DDoS attack is a more attractive option than the low-rate DoS attack.

Replication

Instruction

1. Visit https://github.com/wenjoseph/TCPDoS
2. Follow the instruction on README.md

Note that a single run takes ~1 hour.

Graphs

In addition to the three graphs presented above, the replication script will generate three additional graphs (Not shown in this post. “Figure X” refers to the numbering in the replication output.):

Figure 1 and Figure 3 – These two graphs show our earlier experiment result, when we use the default minRTO = 0.3 seconds. It is clear that the attack was not effective.

Figure 6 – This graph show how the attacked TCP’s RTO changes with respect to our attack. TCP’s RTO (in red) increases exponentially as the retransmission packet drop. Thus, TCP’s throughput (in green) stays near zero when RTO increases. Note that RTO increases when UDP’s attack (in blue) is occurring.

References

[1] Kuzmanovic and Knightly. Low-Rate TCP-Targeted Denial of Service Attacks (2003)

[2]http://www.nbcnews.com/id/50997806/ns/technology_and_science-tech_and_gadgets/t/us-botnet-zombie-pcs-fetch-top-dollar/#.UT66xhyG2Ak