DoS attack in the wild

István leccine at
Tue Jun 23 13:22:57 MSD 2009

Yeah I agree, basically it is not easy to take down nginx with such an
attack. The question is still there, what kind of limitations do we have to
put in place to avoid such an abuser?
My consideration:

-firewall -> max connection by ips
-firewall -> syn proxy(to avoid syn attacks)
-firewall -> connection rate
-OS -> max open sockets by processes
-OS -> tcp/ip stack tuning, allocated memory
-OS -> max CPU time
-OS -> max used memory(slightly different terminology all across unixes)
-webserver-> max fds, running workers etc.

Basically you have to have a multi layer limitation to avoid resource
abusing and then you can sleep well :)


On Tue, Jun 23, 2009 at 9:09 AM, Weibin Yao <nbubingo at> wrote:

> István at 2009-6-23 15:46 wrote:
>> I am not able to reproduce this. The server is answering and serving
>> ./ -dns <> -port 80 -timeout 2 -num
>> 10000
>> The load is zero, there is not even a delay in the response time. Would
>> you mind to share your command and/or the nginx relevant
>> config, OS type and version, sysctl.conf(or equivalent).
>> It would be also nice to know what the nginx is doing in that time, do you
>> have dtrace on that node? Enable debug level logging in nginx is a really
>> bad idea if you have 5000 requests...
>> /"But if you have enough attack computers, you also can make a Nginx
>> server deny service."/
>> /
>> /
>> If you have enough computer you can take down even <
>>>, this is not relevant to this conversation, moreover
>> the slowloris is a dedicated tool to low bandwith/low amount of computers
>> attacks.
>>  I'm sorry for my misunderstanding with your last mail. My meaning is
>  that Nginx has much better performance under such attack.
> In my test case, I reduce the worker_connections to only 1024 because I
> just have one attack computer.
> And my test script is:
> ./ -dns <>  -port 80 -timeout 30 -num
> 10000 -tcpto 5
> :-P
> --
> Weibin Yao

the sun shines for all
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the nginx mailing list