DDoS mitigation is not a single technique. It is a spectrum of methods that operate at different layers of the network stack, at different scales, and with different tradeoffs. A SYN flood hitting a single server needs a different response than a 500 Gbps UDP reflection attack saturating your upstream links. Choosing the right mitigation method for each scenario is the difference between a minor alert and a major outage.
This guide covers every major DDoS mitigation method in use today, explains how each one works, and helps you understand when to apply them. We also cover how these methods chain together in a layered defense, with detection as the critical first step.
Why Detection Comes First
Before you can mitigate an attack, you need to know one is happening. This sounds obvious, but many organizations skip this step entirely, relying on their mitigation tools to both detect and respond. That approach creates blind spots and delays.
Effective mitigation depends on three things happening quickly:
- Detection - Recognizing that abnormal traffic patterns indicate an attack
- Classification - Identifying the attack type so the correct mitigation method is applied
- Response - Applying the appropriate mitigation automatically or with minimal manual intervention
Flowtriq handles steps 1 and 2 in under one second. Per-second PPS monitoring at the kernel level detects anomalies against dynamic baselines, and automatic classification identifies the attack type across 8 categories. This classification is critical because applying the wrong mitigation method can be worse than doing nothing. Blackholing a legitimate traffic spike or rate-limiting the wrong protocol will cause more damage than the attack itself.
Method 1: Kernel-Level Firewall Rules (iptables/nftables)
The fastest and most cost-effective mitigation method is dropping bad packets at the kernel level using iptables or nftables. Because filtering happens before the packet reaches userspace applications, the performance impact is minimal even at high packet rates.
How It Works
When an attack is detected, firewall rules are automatically inserted to drop packets matching the attack signature. For example, a SYN flood from a specific source range can be dropped with a simple rule:
# Drop SYN flood from specific source iptables -A INPUT -s 192.0.2.0/24 -p tcp --syn -j DROP # Rate-limit SYN packets globally iptables -A INPUT -p tcp --syn -m limit \ --limit 100/s --limit-burst 200 -j ACCEPT iptables -A INPUT -p tcp --syn -j DROP # nftables equivalent nft add rule inet filter input \ ip saddr 192.0.2.0/24 tcp flags syn drop
When to Use It
- Attacks under 1-5 Gbps that your server's NIC can handle
- Attacks with identifiable source patterns (IP ranges, specific protocols)
- As the first line of defense while cloud scrubbing activates
- For persistent low-volume attacks that do not justify cloud scrubbing costs
Flowtriq's auto-mitigation engine generates and applies these rules automatically based on attack classification. When a UDP flood is detected, Flowtriq pushes nftables rules that drop the specific attack traffic without affecting legitimate services. Rules are automatically removed when the attack subsides.
Limitations
Kernel-level filtering cannot help if the attack volume exceeds your upstream bandwidth. If you have a 10 Gbps link and a 50 Gbps flood arrives, your link is saturated before the packets even reach your firewall. For volumetric attacks that exceed your available bandwidth, you need upstream mitigation.
Method 2: Rate Limiting
Rate limiting caps the number of packets or connections from a single source (or globally) within a given time window. It is a blunt instrument, but effective against many common attack patterns.
How It Works
Rate limits can be applied at multiple levels:
- Per-source IP - Limit packets or connections from any single IP address
- Per-protocol - Limit specific protocol traffic (e.g., cap UDP to 10,000 PPS)
- Per-port - Limit traffic to specific service ports
- Global - Cap total inbound PPS regardless of source
The challenge with rate limiting is setting thresholds that block attacks without blocking legitimate traffic. Static thresholds inevitably fail because traffic patterns change throughout the day, week, and month. A threshold that works on a Tuesday morning will generate false positives during a Friday evening traffic spike.
This is why Flowtriq uses dynamic baselines instead of static thresholds. The system learns what normal traffic looks like for each node over time and flags deviations from that learned baseline. This approach avoids both false positives during legitimate spikes and false negatives during low-traffic periods when even a small attack could be damaging.
Method 3: BGP FlowSpec
BGP FlowSpec is a protocol extension that allows you to distribute traffic filtering rules to upstream routers via BGP. Instead of diverting all traffic for scrubbing, FlowSpec pushes specific drop or rate-limit rules to your upstream provider's routers, filtering attack traffic before it enters your network.
How It Works
# FlowSpec rule components match: destination: 203.0.113.10/32 # Your targeted IP source: 198.51.100.0/24 # Attack source range protocol: udp # Attack protocol destination-port: 53 # Targeted port action: rate-limit: 1000 # Limit to 1000 bps # or: discard # Drop entirely
FlowSpec rules propagate through BGP and take effect at your upstream provider's edge routers within seconds. This makes FlowSpec significantly faster than full BGP diversion for targeted attacks with identifiable signatures.
When to Use It
- Attacks with clear source or protocol signatures that can be expressed as FlowSpec rules
- When you need upstream filtering without full traffic diversion
- As an intermediate step before activating cloud scrubbing
- For amplification attacks where the source protocol (DNS, NTP, memcached) is known
Flowtriq supports automatic FlowSpec rule generation as part of its auto-mitigation pipeline. When an attack is classified, Flowtriq can push FlowSpec rules to your BGP-capable upstream, filtering the attack at the network edge without any human intervention.
Method 4: RTBH (Remotely Triggered Black Hole)
RTBH is the nuclear option. It tells your upstream provider to drop all traffic destined for a specific IP address. The targeted service goes completely offline, but the rest of your network is protected from collateral damage.
How It Works
You announce a /32 route for the targeted IP with a specific BGP community that signals your upstream to null-route the traffic. All packets for that IP are dropped at the upstream edge, protecting your links from saturation.
When to Use It
- Massive volumetric attacks that threaten to saturate your upstream links
- When the targeted IP is expendable (a single service) and protecting the rest of the network is the priority
- As an automatic last-resort escalation when other methods are insufficient
RTBH is effective but destructive. You are voluntarily taking the targeted service offline to save everything else. Flowtriq can trigger RTBH automatically as part of an escalation chain: first try local firewall rules, then FlowSpec, then cloud scrubbing, and only use RTBH if the attack threatens overall network stability.
Method 5: Cloud Scrubbing
Cloud scrubbing diverts your traffic through a provider's globally distributed scrubbing centers, where attack traffic is filtered and clean traffic is returned to your origin. This is the primary defense against attacks that exceed your local bandwidth capacity.
Major scrubbing providers include Akamai Prolexic, Imperva, Neustar, and Lumen. Their networks range from 5 Tbps to over 20 Tbps of dedicated scrubbing capacity.
When to Use It
- Volumetric attacks exceeding your upstream bandwidth
- Sustained attacks lasting hours or days
- Multi-vector attacks that combine volumetric and application-layer components
The key to effective cloud scrubbing is activation speed. Flowtriq's 1-second detection and automatic signaling via API or webhook can trigger cloud scrubbing activation almost instantly, minimizing the window between attack start and mitigation activation.
Method 6: Web Application Firewalls (WAFs)
WAFs operate at Layer 7, inspecting HTTP/HTTPS requests for malicious patterns. They are specifically designed for application-layer (L7) DDoS attacks like HTTP floods, slowloris, and request-smuggling attacks.
How It Works
WAFs analyze HTTP request patterns including headers, payloads, request rates, and behavioral signals. They can block or rate-limit requests that match known attack patterns or that deviate from expected application behavior.
When to Use It
- HTTP/HTTPS flood attacks
- Slowloris and slow-read attacks
- Application-layer attacks that bypass network-level filtering
- Bot-driven attacks that mimic legitimate user behavior
Limitations
WAFs only protect HTTP/HTTPS services. They do not help with UDP floods, SYN floods, or protocol-level attacks. They also add latency to every request, which can impact performance for latency-sensitive applications. WAFs work best as one layer in a broader defense stack, not as a standalone solution.
Method 7: CDN-Based Protection
Content Delivery Networks like Cloudflare, Akamai, and Fastly inherently provide some DDoS protection by distributing traffic across a global network of edge nodes. Attack traffic is absorbed by the CDN's massive network before it reaches your origin.
When to Use It
- Web applications that can be served through a CDN
- DNS-based attacks (CDN providers typically run large anycast DNS networks)
- As a baseline protection layer for web traffic
Limitations
CDN-based protection only covers traffic routed through the CDN. Direct-to-origin-IP attacks bypass it entirely. Non-HTTP services (game servers, VoIP, custom protocols) cannot use CDN proxying. If your origin IP is exposed, CDN protection provides incomplete coverage.
Method 8: SYN Cookies and TCP Stack Hardening
SYN cookies are a kernel-level defense against SYN flood attacks. Instead of allocating memory for half-open connections, the server encodes connection state in the SYN-ACK sequence number. This allows the server to handle massive SYN floods without running out of connection table memory.
# Enable SYN cookies on Linux sysctl -w net.ipv4.tcp_syncookies=1 # Increase SYN backlog sysctl -w net.ipv4.tcp_max_syn_backlog=65536 # Reduce SYN-ACK retries sysctl -w net.ipv4.tcp_synack_retries=2
SYN cookies should be enabled on every internet-facing server. They are essentially free in terms of performance and provide baseline protection against one of the most common attack types.
Building a Layered Defense
No single mitigation method handles every attack scenario. The most resilient architectures use multiple methods in an escalation chain:
- Always-on: SYN cookies, TCP stack hardening, basic rate limits
- Automatic (seconds): Flowtriq detects the attack in 1 second, classifies it, and applies iptables/nftables rules locally
- Automatic (seconds): If the attack matches FlowSpec criteria, Flowtriq pushes upstream filtering rules
- Automatic (minutes): If the attack exceeds local capacity, Flowtriq triggers cloud scrubbing via API
- Last resort: RTBH for the targeted IP if the attack threatens network stability
Each layer provides coverage while the next layer activates. Local firewall rules handle the first few minutes while cloud scrubbing propagates. FlowSpec provides surgical upstream filtering while full diversion completes. And RTBH is always available as the final safety net.
The most common mistake in DDoS defense is building mitigation without building detection. You can have the best scrubbing provider in the world, but if it takes 10 minutes to trigger, your servers are down for 10 minutes. Fast, accurate detection is the foundation everything else is built on.
Choosing the Right Tools
Here is a practical decision matrix:
- Every organization needs detection. Flowtriq provides 1-second detection with automatic classification at $9.99/node/month.
- Most organizations benefit from automated local mitigation (iptables/nftables), which Flowtriq handles automatically.
- Organizations with BGP-capable networks should use FlowSpec for surgical upstream filtering.
- Organizations at risk of volumetric attacks above 10 Gbps need a cloud scrubbing provider, with Flowtriq as the detection and signaling layer.
- Web-only services can use CDN and WAF protection as a primary defense, with Flowtriq monitoring the origin for bypass attacks.
Detection Is the Foundation of Every Mitigation Method
Flowtriq gives you 1-second detection, automatic classification, and auto-mitigation with iptables, FlowSpec, and cloud scrubbing escalation. $9.99/node/month.
Start your free 7-day trial →