0) Be prepared Be proactive. Plan for the solutions below in advance, not when traffic is hitting your servers and SSH along with everything else is unresponsi

0) Be prepared Be proactive. Plan for the solutions below in advance, not when traffic is hitting your servers and SSH along with everything else is unresponsive. 1) Availability for investigation Renice sshd to make sure you can get to your servers when they are hit with CPU usage due to the DDOS. Reserve some connections for the root user on your SQL server (Postgresql already defaults to 3 for this) so you can still connect, investigate and analyse what's happening. 2) Pattern matching Every solution against DDOS can be described more or less as "pattern matching". There are two steps involved: -> identify a pattern associated with DDOS requests. -> match them as early as possible (iptables, upstream provider, hardware firewall) and reject them. Easiest is to match offending IPs, those that make repeated queries (i.e. once every second). Set the threshold in the right spot - too high and you'll ban valid users, to low and you fail to ban enough in order to restore service availability. Other things to watch for are at the connection level: either SYN flood behaviour ( http://en.wikipedia.org/wiki/SYN_flood http://en.wikipedia.org/wiki/SYN_flood , deploy http://en.wikipedia.org/wiki/SYN_cookies http://en.wikipedia.org/wiki/SYN_cookies ) or KeepAlive connections that keep httpd busy (always reserve in httpd.conf for example a number of connections that aren't KeepAlive enabled). Identify pages on your website that are slow to load or generate large, time-consuming SQL-queries. Those are the main target during DDOS attacks; pattern-match their URLs and disable them during attacks if they're not critical for your website, or have a fall-back for them. Check for errors in the attackers' requests: either they have the same weird-looking user-string, or lack the referrer, or something else that you might be able to find. Pattern-match and reject based on that. Pattern-match clients that keep requesting the .html without loading the corresponding .css or images -- most probably they are attackers calling the GET API (corresponding to wget-ing the HTML) but don't parse and download the corresponding images on the page. Sure, you'll ban text-browser users but that's a small price to pay in order to restore your website. Have a low-resource version of the website where you can turn off the requests for CSS, images and so on and just serve plain functional HTML. Pattern-match, if any, those IPs that keep requesting CSS and images previously associated with non-cache-able HTML pages. And lastly... be proactive, be prepared, have a plan.