Apache attacked by a "slow loris"

Posted Jun 28, 2009 20:43 UTC (Sun) by pphaneuf (guest, #23480)
In reply to: Apache attacked by a "slow loris" by mjthayer
Parent article: Apache attacked by a "slow loris"

Oh, and Squid uses a single thread with non-blocking I/O (asynchronous), yet it is affected, and IIS uses a thread-per-connection (if I recall correctly), just like Apache with the threaded MPM, but it is unaffected.

I think the key difference is how timeouts are handled. If the 300 seconds timeout in Apache is reset at every header (or worse, at every packet received, which could be one character each!), then you could stretch something for a long time. Maybe lighttpd and IIS do something like give it 300 seconds to get all the headers, and after that, too bad, you're just cut off (freeing the TCP port for another connection). You could still mount some sort of DoS attack, but the attacker would have to keep it up more intensively, so that very few legitimate clients manage to slip by as well as Slowloris does for affected servers (which is eventually a 100% effectiveness, with next to zero difficulty for the attacker).

(Log in to post comments)

Apache attacked by a "slow loris"

Posted Jun 28, 2009 22:05 UTC (Sun) by dlang (guest, #313) [Link]

this is exactly the problem. they have one timeout variable that's used for many different things, and while some of the things need long timeouts, others don't, and could be set much shorter.

hopefully this will force the apache team to tackle this issue and seperate the timeouts, but from the article it sounds like they are not responding well.

they are right that the basic attack approach of having a botnet of servers connect to an apache server and tie it up is an old attack that has been possible forever. fixing the timeout issues will not address that, and even after fixing the timeouts the attackers can kill the apache server by making legitimate requests that take time to process, but fixing the timeouts will go a long way towards leveling the playing field again, right now it's tilted heavily in favor of the attackers.

Apache attacked by a "slow loris"

Posted Jun 29, 2009 1:20 UTC (Mon) by njs (guest, #40338) [Link]

> Oh, and Squid uses a single thread with non-blocking I/O (asynchronous), yet it is affected

The original report said that Squid was affected, but the Squid maintainers can't reproduce it (http://www.squid-cache.org/bugs/show_bug.cgi?id=2694); looks like a mistake in the original report to me.

> and IIS uses a thread-per-connection (if I recall correctly)

The article here claims that IIS does not use thread-per-connection, but rather some sort of asynchronous state-machine design (like lighttpd or squid) plus a thread pool to parallelize that state-machine.

> Maybe lighttpd and IIS do something like give it 300 seconds to get all the headers, and after that, too bad, you're just cut off

No -- they just handle the slow connection as normal. The difference is that for them, an idle connection costs a few bytes of memory describing that connection, and one can easily have thousands of these data structures sitting around without anyone noticing. For Apache, an idle connection ties up an entire server process, and for various reasons you can't have thousands of server processes sitting around.