Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for December 5, 2013
Deadline scheduling: coming soon?
LWN.net Weekly Edition for November 27, 2013
ACPI for ARM?
LWN.net Weekly Edition for November 21, 2013
That would not solve anything, but simply create another consumable, scarce resource.
Apache attacked by a "slow loris"
Posted Jun 24, 2009 15:13 UTC (Wed) by michaeljt (subscriber, #39183)
Posted Jun 24, 2009 15:49 UTC (Wed) by hppnq (guest, #14462)
You may want to take a look at network channels, by the way: your idea is really not crazy at all. :-)
Posted Jun 28, 2009 20:23 UTC (Sun) by pphaneuf (guest, #23480)
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.
Posted Jun 28, 2009 21:59 UTC (Sun) by dlang (✭ supporter ✭, #313)
the limit is that you cannot duplicate the set
in about a 2 min period
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.
Posted Jun 28, 2009 20:43 UTC (Sun) by pphaneuf (guest, #23480)
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).
Posted Jun 28, 2009 22:05 UTC (Sun) by dlang (✭ supporter ✭, #313)
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.
Posted Jun 29, 2009 1:20 UTC (Mon) by njs (guest, #40338)
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.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds