4 ms·

New slow-motion DoS attack: just a few PCs, little fear of detection

45 points by tilt 15y ago

sarnowski 15y ago
This remembers me of the really cool spamd application from OpenBSD just the other way around: "When a sending host talks to spamd, the reply will be stuttered. That is, the response will be sent back a character at a time, slowly." http://www.openbsd.org/cgi-bin/man.cgi?query=spamd&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html http://www.openbsd.org/cgi-bin/man.cgi?query=spamd&aprop...
fijal 15y ago
Sounds like just a lot of people on GPRS accessing a website :)
- derleth 15y ago
  Precisely. If you get too aggressive with combating this, you're locking out everyone whose machine or connection isn't up to some arbitrary technical standard. You might decide that dial-up no longer matters to you, but what about mobile?
  - fijal 15y ago
    my connection is sometimes below any arbitrary technical standard and I still want to get my bytes through if possible.
  - wisty 15y ago
    You can combat this a little with good architecture, by making sure the attacks won't stack. One part of the attack is finding a difficult-to-serve request. The other part is being very slow at receiving the response, keeping the request alive. The impact is multiplied if you keep dozens exceptionally high-memory processess alive while the clients slowly the response that those processors generated. If you have the right architecture, it won't matter if the difficult-to-serve request takes a long time to send - you backend processes it, sends the response to your web server, and frees the resources (not holding resources until the client is happy).
    - joshu 15y ago
      It's a good idea to make sure this happens anyway.
bch 15y ago
This sounds coceptually identical to any number of tarpits, like "labrea", for example. That was produced by Tom Piston et. al in 2001. This isn't really new. [edit: links -- http://labrea.sourceforge.net/labrea-info.html http://labrea.sourceforge.net/labrea-info.html, http://en.wikipedia.org/wiki/Tarpit_%28networking%29 http://en.wikipedia.org/wiki/Tarpit_%28networking%29]
x86dev 15y ago
This isn't really new as others have said. Maybe someone publicly released a tool to do this finally. but basically how this works: You have a malicious client figure out a transaction(s) that are easy for the client to request, but difficult for the server to fulfill (ideally). The client initiates the TCP connection. Three way handshake happens. Client sends in the whole request. Client immediately sends in a tcp window update with a very small or zero window size. The server processes the entire request and goes to send it. The server's TCP stack says "Oops, I need to send to that client but he has a small or zero window size. I can only send packets of X size, or I can't send at all. This data is going to sit in my TCP Send Buffer until I can send it". Two things happen here. The TCP send buffer is full (taking up memory) and 2, if the amount of data needed to be sent > TCP Send Buffer size, you now have a Server thread blocked trying to send the data. The client delays for some amount of time and then sends another TCP window update "Hey, I can take X bytes of data now". The server sends X bytes of data. The client can now play a game of sending random small window sizes and or zero windows to essentially slow the connection to a crawl and consume resources on the server side. Edit: Formatting
- wiradikusuma 15y ago
  Is there any tool to simulate this attack (and other common attacks), so I can hit my own server and tweak it until it's bullet proof?
  - zokier 15y ago
    TFA mentions slowhttptest: http://code.google.com/p/slowhttptest/ http://code.google.com/p/slowhttptest/
ww520 15y ago
Combined with a per ip connection limit, async-IO style server like Node.js would alleviate the problem somehow by using smaller amount of memory per connection.

45 points by tilt 15y ago

This remembers me of the really cool spamd application from OpenBSD just the other way around: "When a sending host talks to spamd, the reply will be stuttered. That is, the response will be sent back a character at a time, slowly." http://www.openbsd.org/cgi-bin/man.cgi?query=spamd&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html http://www.openbsd.org/cgi-bin/man.cgi?query=spamd&aprop...

fijal 15y ago

Sounds like just a lot of people on GPRS accessing a website :)

derleth 15y ago
Precisely. If you get too aggressive with combating this, you're locking out everyone whose machine or connection isn't up to some arbitrary technical standard. You might decide that dial-up no longer matters to you, but what about mobile?
- fijal 15y ago
  my connection is sometimes below any arbitrary technical standard and I still want to get my bytes through if possible.
- wisty 15y ago
  You can combat this a little with good architecture, by making sure the attacks won't stack. One part of the attack is finding a difficult-to-serve request. The other part is being very slow at receiving the response, keeping the request alive. The impact is multiplied if you keep dozens exceptionally high-memory processess alive while the clients slowly the response that those processors generated. If you have the right architecture, it won't matter if the difficult-to-serve request takes a long time to send - you backend processes it, sends the response to your web server, and frees the resources (not holding resources until the client is happy).
  - joshu 15y ago
    It's a good idea to make sure this happens anyway.

bch 15y ago

This sounds coceptually identical to any number of tarpits, like "labrea", for example. That was produced by Tom Piston et. al in 2001. This isn't really new. [edit: links -- http://labrea.sourceforge.net/labrea-info.html http://labrea.sourceforge.net/labrea-info.html, http://en.wikipedia.org/wiki/Tarpit_%28networking%29 http://en.wikipedia.org/wiki/Tarpit_%28networking%29]

x86dev 15y ago

This isn't really new as others have said. Maybe someone publicly released a tool to do this finally. but basically how this works: You have a malicious client figure out a transaction(s) that are easy for the client to request, but difficult for the server to fulfill (ideally). The client initiates the TCP connection. Three way handshake happens. Client sends in the whole request. Client immediately sends in a tcp window update with a very small or zero window size. The server processes the entire request and goes to send it. The server's TCP stack says "Oops, I need to send to that client but he has a small or zero window size. I can only send packets of X size, or I can't send at all. This data is going to sit in my TCP Send Buffer until I can send it". Two things happen here. The TCP send buffer is full (taking up memory) and 2, if the amount of data needed to be sent > TCP Send Buffer size, you now have a Server thread blocked trying to send the data. The client delays for some amount of time and then sends another TCP window update "Hey, I can take X bytes of data now". The server sends X bytes of data. The client can now play a game of sending random small window sizes and or zero windows to essentially slow the connection to a crawl and consume resources on the server side. Edit: Formatting

wiradikusuma 15y ago
Is there any tool to simulate this attack (and other common attacks), so I can hit my own server and tweak it until it's bullet proof?
- zokier 15y ago
  TFA mentions slowhttptest: http://code.google.com/p/slowhttptest/ http://code.google.com/p/slowhttptest/

ww520 15y ago

Combined with a per ip connection limit, async-IO style server like Node.js would alleviate the problem somehow by using smaller amount of memory per connection.