Apache HTTP DoS tool released

http://isc.sans.org/diary.html?storyid=6601

by timf • 17 years ago

37 31 17 years ago

isc.sans.org

defied• 17 years ago

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

pmjordan2• 17 years ago

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)

ryah• 17 years ago

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

If you start a thread for each connection, you're doing it wrong.

foppr• 17 years ago

woohoo!

joshu• 17 years ago

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

eli• 17 years ago

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

pmjordan2• 17 years ago

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.

rbanffy7• 17 years ago

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

moe2• 17 years ago

It was big news 10 years ago (literally, 2001ish) when these kind of attacks were initially discussed. Nowadays it's more of a big yawn as the script kiddies rediscover old playgrounds.

gojomo3• 17 years ago

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.

rbanffy7• 17 years ago

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

gojomo3• 17 years ago

Yes, but with concurrency/repetition/keep-alive, you can still tie up essentially all of the connections. (And it's plenty easy to open any number of hanging connections without 'ab', too -- a few lines of shell script, at most.)

jsn6• 17 years ago

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.

Locke16892• 17 years ago

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.

jsn6• 17 years ago

It's trivial to counter indeed; you don't need any packet inspection for that. The main anomaly is not in the header structure, it's in the number of sessions opened simultaneously by one host. This particular tool uses broken headers for some reasons; other ones don't. But they all open sessions excessively.

So you just use iptables connlimit match block the clients with more than e.g. 10 connections.

jimmyrcom• 17 years ago

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.

gojomo3• 17 years ago

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.

pibefision• 17 years ago

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

Apache HTTP DoS tool released

Related Stories