Re: [web-devel] questions about ResponseEnumerator

On Sun, Oct 23, 2011 at 11:37 AM, Gregory Collins wrote:

...

Apache is considered vulnerable to slowloris because it has a limited

...

pool. Nginx is not considered vulnerable to slowloris because it uses an evented architecture and by default drops connections after 60 seconds

On Sun, Oct 23, 2011 at 6:55 PM, Greg Weber wrote: thread 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.

Good point. The equation for number of nodes needed to pull off a slowloris attack becomes: process file descriptor limit / connections per ip address With a 60 second request timeout (like nginx), each slowloris request must be finished in 60 seconds. This also means the log will be writing information about the attack as it is in progress. Stopping Slowloris * 60 second hard timeout * reject partial GET/HEAD requests * require all the headers for any request be sent at once * increase ulimit for the web server. * limit requests per ip address limiting per ip can be done with iptables, but i don't think iptables would know about the http request method. Limiting the number of post requests per ip address to something small seems like an easy way to stop a simple Slowloris attack without having to worry much about the proxy/gateway issue. We will need to add a deploy instruction about increasing the ulimit. If we wanted to, as a final precaution, we could try to detect when we are at the ulimit and start dropping connections.

...

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.

G -- Gregory Collins