I recently used nginx as a reverse proxy in front of apache to successfully fend off a medium-grade DDoS attack. The hardware was 8 years old, with 1GB or RAM and a single-core 1.2GHz processor, running Fedora core 1.

The one thing all the DDoS traffic had in common was the User-Agent string. So by dropping traffic with that UA string and proxying the rest to apache, i assumed I could keep the load down and bring the site back up.

The attack went on for a week. During that time, the site averaged around 6000 requests per second, with lulls around 4000 and peaking at 10000 per second for maybe a half hour at a time. Note that these statistics don't really count as "requests handled" since almost all of the requests were simply dropped after the headers were parsed. However, the numbers are well above any statistics I've ever heard about nginx in the past, and are very promising.

I had to turn off iptables (though probably just had to turn off connection tracking) in order to keep the server from crashing. The server also had to run with TCP Syncookies enabled just to keep up with the connection state, and I fiddled with a number of other kernel parameters which may not have made a difference. However, through it all, nginx took no more than 10% to 40% of the CPU time and very little memory. The actual site loaded in a browser in under 100ms even during the peak attack periods. The numbers seemed to suggest that nginx could have easily handled significantly more traffic if necessary, assuming the network could hold up.

Anyway, kudos to Igor and crew for making such a robust and efficient application. I only wish it could be generalized into a framework for serving other types of protocols as well.

The configuration looked roughly like this:
[code]
worker_processes 10;
events {
worker_connections 10000;
}
http {
default_type application/octet-stream;
sendfile on;
server {
listen 1.2.3.4:80
if ($http_user_agent = "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US)") {
return 444;
}
location / {
proxy_pass http://1.2.3.4:81/;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
}
[/code]

This is pretty impressive. Were you able to get a bandwidth report for the attack? Attacks I've seen typically saturate the server's uplink, so regardless of how battened down the hatches are, whoever's on the server is still screwed.