

New slow-motion DoS attack: just a few PCs, little fear of detection - tilt
http://arstechnica.com/business/news/2012/01/new-slow-motion-dos-attack-just-a-few-pcs-little-fear-of-detection.ars

======
x86dev
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
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
TFA mentions slowhttptest: <http://code.google.com/p/slowhttptest/>

------
bch
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://en.wikipedia.org/wiki/Tarpit_%28networking%29>]

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

~~~
derleth
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?

~~~
wisty
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
It's a good idea to make sure this happens anyway.

------
sarnowski
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&aprop...](http://www.openbsd.org/cgi-
bin/man.cgi?query=spamd&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html)

------
ww520
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.

