On Sun, Oct 23, 2011 at 11:37 AM, Gregory Collins
<greg@gregorycollins.net> wrote:
On Sun, Oct 23, 2011 at 6:55 PM, Greg Weber <
greg@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.
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.