DoS attack in the wild

István leccine at gmail.com
Mon Jun 22 16:40:59 MSD 2009


I wasn't able to raise the load above 0,1 with nginx-0.6.32 on freebsd.
What did I wrong if nginx is affected "much stronger"?

Regards,
Istvan

On Mon, Jun 22, 2009 at 11:51 AM, Weibin Yao <nbubingo at gmail.com> wrote:

> w3wsrmn at 2009-6-20 8:09 wrote:
>
>> A look at the script reveals it keeps connections open with invalid
>> headers (note the appended "\r\n"):
>>
>> "GET /$rand HTTP/1.1\r\n"
>>          . "Host: $sendhost\r\n"
>>          . "User-Agent: 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)\r\n"
>>          . "Content-Length: 42\r\n";
>>
>> As by default the (undocumented?) ignore_invalid_headers directive is
>> enabled in nginx, isn't this attack a non-issue, unless one disables the
>> directive?
>>
>> Sending such headers to an nginx server with the directive enabled results
>> in a "400 Bad Request".
>>
>>
>>
> When using telnet to send above header, I received the 400 response.
> But when I tested the slowloris.pl script in nginx_0.7.59. The
> ignore_invalid_headers directive is useless, Nginx treate the header_line
> 'X-a: b\r\n' as valid header.
> The debug log is like this:
>
> 2009/06/22 16:58:58 [debug] 25864#0: *1 accept: 172.19.1.209 fd:9
> 2009/06/22 16:58:58 [debug] 25864#0: *1 event timer add: 9: 60000:120682241
> 2009/06/22 16:58:58 [debug] 25864#0: *1 epoll add event: fd:9 op:1
> ev:80000001
> .
> .
> .
> 2009/06/22 16:58:58 [debug] 25864#0: *1 http process request line
> 2009/06/22 16:58:58 [debug] 25864#0: *1 recv: fd:9 236 of 1024
> 2009/06/22 16:58:58 [debug] 25864#0: *1 http request line: "GET / HTTP/1.1"
> 2009/06/22 16:58:58 [debug] 25864#0: *1 http uri: "/"
> 2009/06/22 16:58:58 [debug] 25864#0: *1 http args: ""
> 2009/06/22 16:58:58 [debug] 25864#0: *1 http exten: ""
> 2009/06/22 16:58:58 [debug] 25864#0: *1 http process request header line
> 2009/06/22 16:58:58 [debug] 25864#0: *1 http header: "Host:
> edu-9.space.163.org"
> 2009/06/22 16:58:58 [debug] 25864#0: *1 http header: "User-Agent:
> 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)"
> 2009/06/22 16:58:58 [debug] 25864#0: *1 http header: "Content-Length: 42"
> 2009/06/22 16:58:58 [debug] 25864#0: *1 recv: fd:9 -1 of 788
> 2009/06/22 16:58:58 [debug] 25864#0: *1 recv() not ready (11: Resource
> temporarily unavailable
> .
> .
> .
> 2009/06/22 16:58:58 [debug] 25864#0: *1 http process request header line
> 2009/06/22 16:58:58 [debug] 25864#0: *1 recv: fd:9 8 of 788
> 2009/06/22 16:58:58 [debug] 25864#0: *1 http header: "X-a: b"
> 2009/06/22 16:58:58 [debug] 25864#0: *1 recv: fd:9 -1 of 780
> 2009/06/22 16:58:58 [debug] 25864#0: *1 recv() not ready (11: Resource
> temporarily unavailable)
> .
> .
> .
> 2009/06/22 16:59:48 [debug] 25864#0: *1 http process request header line
> 2009/06/22 16:59:48 [debug] 25864#0: *1 recv: fd:9 8 of 780
> 2009/06/22 16:59:48 [debug] 25864#0: *1 http header: "X-a: b"
> 2009/06/22 16:59:48 [debug] 25864#0: *1 recv: fd:9 -1 of 772
> 2009/06/22 16:59:48 [debug] 25864#0: *1 recv() not ready (11: Resource
> temporarily unavailable)
> .
> .
> .
> 2009/06/22 16:59:58 [debug] 25864#0: *1 event timer del: 9: 120682241
> 2009/06/22 16:59:58 [debug] 25864#0: *1 http process request header line
> 2009/06/22 16:59:58 [info] 25864#0: *1 client timed out (110: Connection
> timed out) while reading client request headers, client: 172.19.1.209,
> server: _, request: "GET / HTTP/1.1", host: "edu-9.space.163.org"
> 2009/06/22 16:59:58 [debug] 25864#0: *1 http close request
> 2009/06/22 16:59:58 [debug] 25864#0: *1 http log handler
> 2009/06/22 16:59:58 [debug] 25864#0: *1 close http connection: 9
>
> The default timeout value is 60 seconds. But you can set with
> client_header_timeout(
> http://wiki.nginx.org/NginxHttpCoreModule#client_header_timeout), This
> directive is much useful。
>
> I think Nginx is also effected by such DoS attack, but much stronger than
> apache.
>
> --
> Weibin Yao
>
>
>


-- 
the sun shines for all
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nginx.org/pipermail/nginx/attachments/20090622/445a24c7/attachment.html>


More information about the nginx mailing list