Surviving the Flood: Practical DDoS Mitigation for Small Norwegian Sites
It’s 3:00 AM. Your pager goes off. Your Nagios dashboard is a sea of red. SSH is lagging, and your latency to NIX (Norwegian Internet Exchange) has spiked from 2ms to 400ms. Congratulations, you aren't just viral—you're under attack.
In 2010, the barrier to entry for causing havoc is lower than ever. With tools like the Low Orbit Ion Cannon (LOIC) widely available, any script kiddie with a grievance can launch a decent HTTP flood. For massive enterprise networks, the answer is a $50,000 Cisco Guard appliance. For the rest of us running small to mid-sized projects in Oslo or Trondheim, we need to be smarter.
I've spent the last week scrubbing traffic for a client’s e-commerce site that got hit by a botnet. Here is the raw, unpolished truth on how to keep your server standing when the packets start flying.
1. Diagnosis: Is it a Flash Crowd or a DDoS?
Before you start panic-blocking IPs, confirm what you are dealing with. Log into your server (hopefully you have a console access method if SSH is choked) and run this:
netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n
This command lists the number of open connections per IP address. If you see hundreds of connections from a single IP, or thousands of connections in SYN_RECV state, you are being flooded. A legitimate user rarely needs more than 10-20 concurrent connections.
2. The First Line of Defense: Kernel Tuning
Your Linux kernel isn't configured for war out of the box. The default TCP stack is polite; it waits too long for handshakes to complete. In a SYN flood, the attacker sends connection requests but never replies, filling up your connection table.
Edit your /etc/sysctl.conf and add these aggressive settings to harden the stack:
# Protection against SYN flood
net.ipv4.tcp_syncookies = 1
net.ipv4.conf.all.rp_filter = 1
net.ipv4.tcp_max_syn_backlog = 2048
net.ipv4.tcp_synack_retries = 2
Run sysctl -p to apply. Enabling SYN cookies is non-negotiable in 2010. It allows your server to handle legitimate traffic even when the SYN queue is overflowing.
3. Nginx: The Heavy Lifter
If you are still serving static assets with Apache 2.2 and the prefork mpm, you are fighting a losing battle. Apache spawns a process for every request. An attacker just needs to exhaust your RAM to kill the site.
We use Nginx (specifically the 0.7 or 0.8 stable branch) for its event-driven architecture. It can handle thousands of concurrent connections with a tiny memory footprint. More importantly, it has built-in modules to rate limit abusers.
In your nginx.conf, inside the http block, define a limit zone:
limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s;
Then, in your server block:
location /login.php {
limit_req zone=one burst=5;
}
This restricts a single IP to 1 request per second. Genuine users won't notice, but a bot trying to brute-force your login or flood your backend will get dropped instantly.
4. Brute Force Blocking with Iptables
Sometimes you need to drop packets before they even hit the web server. While I usually recommend installing Fail2Ban to automate this, knowing the manual iptables commands can save your skin during an active incident.
To drop all traffic from a specific malicious IP (e.g., 1.2.3.4):
iptables -I INPUT -s 1.2.3.4 -j DROP
To limit the number of new TCP connections a client can make per second (a poor man's rate limiter):
iptables -A INPUT -p tcp --dport 80 -m state --state NEW -m recent --set
iptables -A INPUT -p tcp --dport 80 -m state --state NEW -m recent --update --seconds 60 --hitcount 20 -j DROP