The Growing Threat of DDoS Attacks
A Distributed Denial of Service (DDoS) attack is one of the most disruptive threats a server can face. Unlike other cyberattacks that try to steal data or inject malicious code, a DDoS attack has a single, brutal objective: overwhelm your server with so much traffic that it cannot serve legitimate users. Your website goes offline, your business loses revenue, and your reputation takes a hit.
DDoS attacks have grown both in frequency and sophistication. What used to require botnets of thousands of compromised machines can now be launched by a single person using cheap "DDoS-as-a-service" tools. Attacks regularly exceed 1 Tbps (terabit per second), and even small attacks of 1-10 Gbps can take down an unprotected server in seconds.
This guide covers the different types of DDoS attacks, defense strategies at every layer of the network stack, and practical configurations you can implement today to protect your server.
Understanding DDoS Attack Types
DDoS attacks are classified into three categories based on which layer of the network stack they target. Understanding this classification is essential for choosing the right defense strategy.
Layer 3/4: Volumetric and Protocol Attacks
These attacks flood your server's network connection with raw traffic, attempting to saturate your bandwidth or exhaust connection state tables.
SYN Flood Protocol
Sends thousands of TCP SYN packets without completing the three-way handshake. Each half-open connection consumes server memory until the connection table is exhausted and no new connections can be accepted.
UDP Flood Volumetric
Sends massive volumes of UDP packets to random ports. The server wastes resources checking for listening applications and sending ICMP "destination unreachable" responses for each packet.
DNS Amplification Volumetric
Sends small DNS queries to open resolvers with the victim's spoofed IP address. The resolvers send large responses (50-70x amplification) to the victim, flooding their bandwidth.
NTP Amplification Volumetric
Exploits NTP's monlist command for 200x amplification. A 1 Gbps attack source becomes a 200 Gbps attack at the victim. This is one of the most powerful amplification vectors.
Layer 7: Application-Layer Attacks
These are the most dangerous attacks because they look like legitimate traffic. Instead of flooding bandwidth, they target resource-intensive endpoints that consume CPU, memory, or database queries.
| Attack Type | Method | Why It is Dangerous |
|---|---|---|
| HTTP Flood | Thousands of seemingly valid HTTP requests | Hard to distinguish from real users |
| Slowloris | Opens connections, sends headers slowly, never completes | Ties up all available connection slots |
| RUDY (R-U-Dead-Yet) | Sends POST body data one byte at a time | Keeps connections open for minutes |
| WordPress xmlrpc.php | Pingback requests as amplification vector | Each request triggers expensive DB queries |
| Login brute force | Thousands of login attempts per second | Each attempt requires password hashing (CPU-intensive) |
Defense Layer 1: Kernel-Level Mitigations
The first line of defense is the Linux kernel itself. These sysctl parameters help your server handle connection floods without crashing:
Defense Layer 2: Firewall Rate Limiting (nftables)
nftables (the modern replacement for iptables) can rate-limit connections and drop packets from abusive IPs before they reach your application:
Using iptables (Legacy)
If your server still uses iptables, here are equivalent rules:
Defense Layer 3: Fail2ban Auto-Blocking
Fail2ban monitors log files for abusive patterns and automatically bans offending IPs. It is one of the most effective tools against application-layer DDoS because it can detect behavior patterns that simple rate limiting misses.
HTTP Flood Protection
This configuration bans any IP that makes more than 300 requests in 60 seconds for one hour. Adjust the thresholds based on your normal traffic patterns.
WordPress xmlrpc Protection
Defense Layer 4: Nginx Rate Limiting
Nginx's built-in rate limiting module provides application-layer protection directly at the web server level. It is effective against HTTP floods and brute force attacks:
Apply the rate limits in your server blocks:
burst parameter allows temporary spikes above the rate limit. Without nodelay, burst requests are queued and served gradually. With nodelay, burst requests are served immediately but excess requests above the burst are dropped. For DDoS protection, nodelay is usually what you want.
Defense Layer 5: Cloudflare Protection
For serious DDoS protection, a CDN/proxy like Cloudflare sits in front of your server and absorbs attack traffic before it reaches your infrastructure. Cloudflare's network can handle multi-terabit attacks that would overwhelm any single server.
Essential Cloudflare Settings
| Setting | Recommended Value | Purpose |
|---|---|---|
| SSL/TLS Mode | Full (Strict) | Encrypts traffic between Cloudflare and your server |
| Under Attack Mode | Off (enable during attack) | Shows JavaScript challenge to all visitors |
| Bot Fight Mode | On | Challenges known bot signatures |
| Browser Integrity Check | On | Blocks requests with suspicious headers |
| Challenge Passage | 30 minutes | How long a solved challenge remains valid |
| Security Level | Medium or High | Controls challenge threshold for suspicious IPs |
Restricting Direct Server Access
When using Cloudflare, your server should only accept connections from Cloudflare's IP ranges. This prevents attackers from bypassing Cloudflare by connecting directly to your origin IP:
Defense Layer 6: ModSecurity WAF
A Web Application Firewall (WAF) inspects HTTP request content and blocks malicious patterns. ModSecurity with the OWASP Core Rule Set (CRS) provides a comprehensive layer of defense against application-layer attacks:
Monitoring During an Attack
When a DDoS attack hits, you need real-time visibility into what is happening. Here are the essential commands for monitoring an active attack:
Emergency Response: Under Active Attack
When you detect an active DDoS attack, follow this response procedure:
Building a DDoS Defense Strategy
Effective DDoS defense is layered. No single tool stops all attack types. Here is the recommended defense stack:
Absorbs volumetric
SYN cookies, conntrack
Rate limiting
Pattern detection
Application layer
Request inspection
DDoS Prevention Checklist
- SYN cookies enabled in kernel
- Connection tracking limits tuned
- Reverse path filtering enabled
- nftables/iptables rate limiting configured
- Fail2ban monitoring access logs
- Nginx rate limiting on all endpoints
- Login/admin pages have strict rate limits
- WordPress xmlrpc.php blocked
- Cloudflare proxying all traffic
- Origin server only accepts Cloudflare IPs
- ModSecurity WAF with OWASP CRS enabled
- Monitoring and alerting configured
- Incident response plan documented and tested
Wrapping Up
DDoS protection is not a single configuration change — it is a layered defense strategy that covers every level of the network stack. The kernel handles SYN floods with SYN cookies, the firewall rate-limits connections, fail2ban detects behavioral patterns, Nginx limits application-layer requests, ModSecurity inspects request content, and Cloudflare absorbs volumetric attacks before they reach your server.
The most important takeaway is to prepare before an attack happens. Configure your defenses, test them, document your response procedure, and know who to contact (hosting provider, Cloudflare support) when an attack exceeds what your server can handle alone. A prepared server can survive most DDoS attacks with minimal downtime; an unprepared one will go down in seconds.