| |||||||||||||
Apache attacked by a "slow loris"Apache attacked by a "slow loris"Posted Jun 24, 2009 14:49 UTC (Wed) by hppnq (guest, #14462)In reply to: Apache attacked by a "slow loris" by michaeljt Parent article: Apache attacked by a "slow loris" That would not solve anything, but simply create another consumable, scarce resource.
(Log in to post comments)
Apache attacked by a "slow loris" Posted Jun 24, 2009 15:13 UTC (Wed) by michaeljt (subscriber, #39183) [Link]
I'm sure you're right, but I don't quite follow. What is the scarce resource here? Obviously several threads can be spread over several CPUs, but otherwise why are multiple threads handling sockets superior to one thread handling incoming packages asynchronously?
Apache attacked by a "slow loris" Posted Jun 24, 2009 15:49 UTC (Wed) by hppnq (guest, #14462) [Link] You would run out of memory, I guess. My comment was mostly inspired by the observation that the DoS is caused by Apache's rather relaxed handling of the HTTP protocol, which in principle makes the lower-level data processing irrelevant. But of course the DoS would appear differently.You may want to take a look at network channels, by the way: your idea is really not crazy at all. :-)
Apache attacked by a "slow loris" Posted Jun 28, 2009 20:23 UTC (Sun) by pphaneuf (guest, #23480) [Link]
The scarce resources here are TCP ports and memory. Maybe you can make things more memory efficient, or add memory, but the number of TCP ports is both fixed by TCP itself and inconveniently small.
No matter how you implement it, there's a fixed cap on the number of TCP connections per IP address. You could add IP addresses to a server, but that would be a waste of another precious resource, since during normal usage, most web servers can't handle the maximum number of connections of a single IP.
Apache attacked by a "slow loris" Posted Jun 28, 2009 21:59 UTC (Sun) by dlang (✭ supporter ✭, #313) [Link]
TCP ports don't get used up on servers when you have lots of connections.
the limit is that you cannot duplicate the set
when connecting to a server the destination port and destination IP are fixed, so a client can make lots of connections and make it so that no other connections could be made from that source IP, but that doesn't hurt anyone else.
that also isn't the attack that's happening here.
Apache attacked by a "slow loris" Posted Jun 28, 2009 20:43 UTC (Sun) by pphaneuf (guest, #23480) [Link]
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).
Apache attacked by a "slow loris" Posted Jun 28, 2009 22:05 UTC (Sun) by dlang (✭ supporter ✭, #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.
|
|||||||||||||