I've been testing slowloris against nginx to understand the slowloris attack more, and I need help to make sense of it.

From the original thread comments http://ha.ckers.org/blog/20090617/slowloris-http-dos/ it seems that slowloris exhausts _some_ resource specific to the web server, and that for Apache it is max clients.

In my tests against nginx (on a debian machine http://blog.rayfoo.info/2009/10/12/testing-slowloris-against-nginx), nginx seems refuse any incoming connections when its file descriptor count hits the maximum allowed for that process. And during this time it continues to listen (for a while at least) to requests on the connections already established.

I'm not sure yet whether this is purely a kernel/process/linux limitation (I'm thinking ulimit), and this is pretty different in behaviour from how Apache dies from the slowloris attack, but I'd think that nginx is also affected by slowloris because of the nature of this attack (current connections maintained, new connections denied, web server host TCP stack not overloaded)

Anyone has any thoughts on this? Or did I misunderstand the mechanics of the Slowloris?

I think you've got a good idea of how it works. On apache it just grab all of the available processes and holds them open. We tried (limited) tests with nginx and, at least on FreeBSD, we didn't see any problems. If you're running a mildly busy website you would normally increase your ulimit -n to something quite a bit bigger (8192) or larger. Give that a try and see if it falls down.

-id



Edited 1 time(s). Last edit at 10/20/2009 04:06PM by id.

Thanks for the pointer id. Tested it out, the nginx process takes in more connections with the max file descriptors raised, which means that the limitation is no longer with nginx.

Nginx actually kicks out connections if the request is not completed within a time period (60 secs by default), regardless of whether headers are coming in slowly or not, so SlowLoris in itself is definitely useless against nginx as it is.

One interesting side effect of the kicking out connections by nginx: the access logs get written to as the connections get kicked out, so that means we can actually detect a SlowLoris attempt as it is in progress! ;)

Cool, can you post what a couple logs of a kicked connection?

-id

Some log entries that show (after hiding the IP addresses)

x.x.x.x - - [27/Oct/2009:17:58:21 +0800] "GET / HTTP/1.1" 400 0 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.503l3; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; MSOffice 12)"
x.x.x.x - - [27/Oct/2009:17:58:22 +0800] "GET / HTTP/1.1" 400 0 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.503l3; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; MSOffice 12)"
x.x.x.x - - [27/Oct/2009:17:58:22 +0800] "GET / HTTP/1.1" 400 0 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.503l3; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; MSOffice 12)"
x.x.x.x - - [27/Oct/2009:17:58:22 +0800] "GET / HTTP/1.1" 400 0 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.503l3; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; MSOffice 12)"
x.x.x.x - - [27/Oct/2009:17:58:24 +0800] "GET / HTTP/1.1" 400 0 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.503l3; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; MSOffice 12)"
x.x.x.x - - [27/Oct/2009:17:58:31 +0800] "GET / HTTP/1.1" 400 0 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.503l3; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; MSOffice 12)"
x.x.x.x - - [27/Oct/2009:17:58:37 +0800] "GET / HTTP/1.1" 400 0 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.503l3; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; MSOffice 12)"

I'm very sure the user agent would look familiar ;)