http ddos mitigation by tarpitting

By way of the SecuriTeam blog, I see Joe Stewart has posted a quick technical article about thwarting an HTTP DDoS attack using iptables tarpitting. I also like the cite to a report by Jordan Wiens [pdf] about tarpitting DDoS worms (I’ve not read it yet). I especially like the graph showing the effects of no action, connection dropping, and tarpitting. As a question to myself, I wonder if the attacked system needs to keep track of those sessions as well, and if that might bleed the server a bit over time? Obviously, this is still better than having the server fall over in the first 5 minutes, while tarpitting likely can allow the server to hold out far longer, even if it still bleeds.

One thing that Joe leaves unspoken is tarpitting is not to be used for all HTTP requests. Some of those requests are legitimate users and you certainly don’t want to tarpit them. Tarpitting should be triggered after a connection is determined to be part of the DDoS, so there is some front-end work to be done. I expect Wiens covers this in the longer paper.

5 thoughts on “http ddos mitigation by tarpitting

  1. Yup! Most of those topics get covered in the paper. I don’t remember how much detail I go into alternate mechanisms for tracking the sessions to not bog down the server, but I do mention the downsides to using straight iptables since they basically do a linear search on all incoming traffic and it only takes a couple thousand entries to really bog the server down. We implemented a really crappy temporary hack to hold us over during the netsky incident, but better solutions would be to either:
    1) Rewrite iptables to optimize search through a long list of ips to match using a more efficient search operation.
    2) If the worm has characteristics detectable from the first syn packet, use a specific sequence number range that can be matched to initiate tarpitting, vaguely similar to syncookies.
    3) Build the tarpit code into the detection mechanism that distinguishes worm traffic in the first place (in our case it was blindingly obvious: netsky’s requests looked like: “GET / HTTP/1.0\nHOST: hostname\n\n”. No real browser ever sends such a bare request. Anyway, start tarpitting the traffic as you do the detection and you don’t have to do any tracking of IPs or tagging of packets for later matching.

  2. Thanks! I hope you didn’t read /all/ of it, much was pretty boring but had to be included due to the submission requirements. 😉
    Not to be bitter (much!), but it was actually failed for the SANS certification I was going for. Didn’t meet their exact formatting requirements (they wanted me to make up sections that didn’t happen in real life so that I could “properly” follow their incident response plan — like a reconnaissance phase).
    I was too stiff necked to just change it the way they wanted it and never resubmitted.

  3. Hehe, yeah I didn’t read every part word for word, but I did end up going through most of it.
    Sucks that they would fail it, but I guess that’s just a difference of purpose between the paper and what they wanted. No matter, I really liked it!

Comments are closed.