On Sun, Oct 23, 2011 at 7:50 PM, Kazu Yamamoto
<kazu@iij.ad.jp> wrote:
Hello,
> 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.
I you want, I create a code to do real slowloris attack to consume the
file descriptors of a server. It's quite easy.
That depends on the file descriptor limits. If the server can take on more connections that the attacking script can produce, you will need a second machine, which I think means it is no longer quite easy. Slowloris was designed to show how easy it is to take down servers with Apache style architecture by just gradually opening 50 slow connections.
We are actually in the realm of DOS attacks now. Intentionally slowing down the connection of the attack is just a technique to make the DOS more effective, but I don't even know why it matters anymore to our situation - the attacker can just send more requests to the server - I suppose the slow connection is more effective at blocking out legitimate users competing for 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.
If we pay money, we can use a *botnet* to do this. This actually
happens in the real world. But I don't think a bad guy targets your
web server.
--Kazu