5 ms·
Apache HTTP DoS tool released
- pibefision 17y agowhat if we use NGINX as a reverse proxy in front of apache? could this be a good workaround?
- defied 17y agoMore info about this attack is available on http://ha.ckers.org/blog/20090617/slowloris-http-dos/ http://ha.ckers.org/blog/20090617/slowloris-http-dos/
- pmjordan 17y agoAfter 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 17y 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 17y agowoohoo!
- joshu 17y agoPut 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 http://joshua.schachter.org/2008/01/proxy.html
- eli 17y agoSo... you basically just hold open all the TCP connections at once? How anticlimactic.
- pmjordan 17y agoIn 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 17y agoYes, but since it's Apache, anything like this is big news.
- moe 17y agoIt 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.
- gojomo 17y agoThere'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 17y agoI think ab will send a full set of headers and not tie the server connection indefinitely.
- gojomo 17y agoYes, 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.)
- jsn 17y agoAnd 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 17y agoIt'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.
- jsn 17y agoIt'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.
- rbanffy 17y agoActually, just blocking originating IPs would not stop a DDoS based on this. The simplest approach would be to timeout the connection if a credible set of headers is not received within a certain time. This attack is based on the idea the attacker commands more resources than the target server. It doesn't fly very well.
- jsn 17y agoSorry, most of that is wrong :) 1. No, it's not the simplest approach. The attacker can trivially send perfectly credible set of headers, then start receiving the response, acknowledging 1 byte per 30 minutes. It's routinely seen in the wild, too. Header-based approach completely misses the point of anomaly. 2. Blocking originating IPs is perfectly effective as soon as all existing connections from the blocked IPs time out. Which is fairly soon. 3. connlimit approach doesn't just block originating IPs, it prevents anyone from opening a lot of connections. 4. In any real DDOS scenario attacker does command an order of magnitude more resources than the target servers. [edit: formatting]
- jimmyrcom 17y agoIt'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 17y agoThat 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.