Apache HTTP DoS tool released

[joshu]

Put a reverse proxy in front. You should do this anyway. Modem and other pokey connections effectively do the same as this DOS.

http://joshua.schachter.org/2008/01/proxy.html

[gojomo]

There's really nothing new about this sort of depletion attack, and it's easy to launch in dozens of different ways in a line or two of code. (As far as a 'tool' to do it, I think the 'ab' benchmarking utility bundled with Apache suffices.)

In response, you block/throttle origin IPs, and decrease timeouts so zombie connections are dropped more quickly, and increase the capacity to serve or shake-off troublesome connections without locking out legitimate traffic. An inbound reverse proxy, as joshu suggests, often makes this easier -- and keeps such enforcement cruft from complicating the primary server.

[rbanffy]

I think ab will send a full set of headers and not tie the server connection indefinitely.

[defied]

More info about this attack is available on http://ha.ckers.org/blog/20090617/slowloris-http-dos/

[pmjordan]

After reading the main article and the link you provided, my interpretation/understanding is:

* The idea is to trick the web server into keeping a connection open and waiting for data, e.g. by keeping on sending pointless headers, not sending enough (< content-length bytes of) data in the body, etc. Unlike a SYN flood or so, this doesn't require much traffic from the attacker.

* The reason this works is that apache has a limit of one thread or process per active connection, and there is typically an upper bound on

* The way to fix this once and for all in apache et al would be to handle socket I/O asynchronously, thus lifting the 1:1 ratio of connections to threads/processes.

Is that accurate? I'm mostly curious so that I can try to avoid any such pitfalls in any server software I might write.

One way to fix this in apache without breaking too many existing modules and extensions might be to use fibers to hide the asynchronicity and schedule them in the "blocking" I/O functions which would actually use non-blocking I/O underneath. (I don't actually know the apache architecture, so I might be wrong about the blocking I/O)

[eli]

So... you basically just hold open all the TCP connections at once? How anticlimactic.

[pmjordan]

In fairness, it does involve some HTTP, so it's not a pure TCP DoS. Anything other than apache on the same system is unaffected.

[rbanffy]

Yes, but since it's Apache, anything like this is big news.

[jsn]

And this is news somehow? Color me unimpressed. First time we'd been subjected to this kind of attack was, what, a year ago? Maybe two. It's a trivial next step after the old boring flood of http get requests.

[Locke1689]

It's also not that difficult to counter. The easiest way is to just do packet inspection - if something looks wrong (repeated bad/incomplete headers), just blacklist the IP for however many minutes. Repeat ad nauseam. Any IDS worth its salt shouldn't even hiccup at this.

[pibefision]

what if we use NGINX as a reverse proxy in front of apache? could this be a good workaround?

[jimmyrcom]

It's a pretty short code written in perl. I'd be scared if it was modified from curl or written in erlang. The author admits being corrected about the type of attack not being new but claims thats the first tool. I don't see how its new though. Whether you keep alive by incomplete requests, by valid requests or by sending post data very slowly, it doesn't seem to make a difference. Just eat up as many connections as possible.

[gojomo]

That perl script is about 100x longer than it needs to be (even disregarding the embedded docs and ASCII graphics). This is a super-simple (and old) attack; many DoS attacks based on large amounts of traffic first cause problems by depleting this same limited pool of threads/connections.

[foppr]

woohoo!