[web-devel] questions about ResponseEnumerator

Gregory Collins greg at gregorycollins.net
Sun Oct 23 20:37:22 CEST 2011

On Sun, Oct 23, 2011 at 6:55 PM, Greg Weber <greg at gregweber.info> wrote:
> Apache is considered vulnerable to slowloris because it has a limited thread
> pool. Nginx is not considered vulnerable to slowloris because it uses an
> evented architecture and by default drops connections after 60 seconds that
> have not been completed. Technically we say our Haskell web servers are
> using threads, but they are managed by a very fast evented system. So we can
> hold many unused connections open like Nginx and should not be vulnerable if
> we have a timeout that cannot be tickled. This could make for an interesting
> benchmark - how many slowloris connections can we take on? The code from
> Kazu makes just one connection - it does not demonstrate a successful
> slowloris attack, just one successful slowloris connection.

Slowloris causes problems with any scarce resource -- threads in a
pool, as you mentioned, but a bigger problem for us is running out of
file descriptors. If the client is allowed to hold connections open
for long enough, an attacker should be able to run the server out of
file descriptors using only a handful of machines.

> If we limit the number of connections per ip address, that means a slowloris
> attack will require the coordination of thousands of nodes and make it
> highly impractical. Although there may be a potential  issue with proxies
> (AOL at least used to do this, but I think just for GET) wanting to make
> lots of connections.

Yep -- this is one possible solution, although you're right about the
proxy/NAT gateway issue potentially being a problem for some
applications. Ultimately I think to handle this "well enough", we just
need to be able to handle timeouts properly to deter low-grade script
kiddies with a couple of machines at their disposal. Attackers with
real botnets are going to be hard to stop no matter what.

Gregory Collins <greg at gregorycollins.net>

More information about the web-devel mailing list