The Misconception: "We Have a Firewall, We're Protected"
This is one of the most common assumptions in network security. When someone says "we have DDoS protection," they often mean they have a firewall with rate limiting rules, or a cloud security group with restrictive ingress policies. In their mental model, the firewall sits at the edge and blocks bad traffic. Attack stopped. Problem solved.
The reality is far more complicated. Firewalls are critical infrastructure for access control, segmentation, and stateful packet inspection. They are excellent at enforcing policies like "only allow TCP port 443 from the internet" or "block all traffic from this IP range." But DDoS attacks are not an access control problem. They are a resource exhaustion problem. And that distinction changes everything.
A DDoS attack does not need to bypass your firewall rules. It needs to overwhelm the resources your firewall depends on: connection tracking tables, CPU cycles, memory, and most critically, the bandwidth of the link that sits in front of your firewall. If the attacker can exhaust any one of those resources, your firewall becomes the bottleneck rather than the solution.
A firewall that drops 100% of attack packets is still useless if the attack saturates the network link before packets reach the firewall. The traffic already consumed your bandwidth. The damage is done.
Problem 1: Connection Tracking Table Exhaustion
Stateful firewalls maintain a connection tracking table (conntrack) that records every active connection passing through the firewall. Each entry consumes memory and must be looked up for every packet. This table has a finite size, and that size becomes your vulnerability.
On a default Linux system with iptables, the conntrack table maximum is typically 65,536 entries. On enterprise firewalls, it might be 1 million or even 10 million entries. Regardless of the number, it is finite, and a SYN flood can exhaust it in seconds.
# Check your current conntrack limits cat /proc/sys/net/netfilter/nf_conntrack_max 65536 # See current conntrack table usage cat /proc/sys/net/netfilter/nf_conntrack_count 12847 # What happens when the table fills up: # kernel: nf_conntrack: table full, dropping packet # Every new connection — legitimate or not — gets dropped
A SYN flood attack sends millions of SYN packets per second, each one creating a half-open connection entry in the conntrack table. The firewall faithfully tracks each one, waiting for the three-way handshake to complete. It never does. Within seconds, the table fills up, and the firewall starts dropping every new connection attempt, including legitimate users trying to reach your services.
The numbers are brutal
A modest botnet of 10,000 nodes, each sending 100 SYN packets per second, generates 1 million SYN packets per second. A conntrack table with 1 million entries fills up in about one second if the SYN timeout is set to the default 60 seconds. Even if you increase the table size to 10 million entries, you have bought yourself 10 seconds at most.
- Default conntrack max: 65,536 entries. Exhausted in under 0.1 seconds by a moderate SYN flood.
- Tuned conntrack max: 1,000,000 entries. Exhausted in roughly 1 second.
- Enterprise firewall: 10,000,000 entries. Exhausted in roughly 10 seconds.
- Each entry consumes: approximately 300 to 400 bytes of kernel memory. 10 million entries means 3 to 4 GB of RAM consumed by conntrack alone.
You can tune conntrack timeouts to reduce exposure. Lowering nf_conntrack_tcp_timeout_syn_recv from 60 seconds to 10 seconds helps, but it does not solve the fundamental problem. The attacker simply sends more packets per second to keep the table full.
# Tuning conntrack timeouts (reduces exposure but doesn't solve the problem) sysctl -w net.netfilter.nf_conntrack_tcp_timeout_syn_recv=10 sysctl -w net.netfilter.nf_conntrack_max=2097152 # Even with aggressive tuning, a large SYN flood # will still exhaust the table
Conntrack bypass is not a solution either. Some guides suggest using -j NOTRACK rules in the raw table to bypass connection tracking for certain traffic. This works for specific use cases, but it means giving up stateful inspection entirely for that traffic, which defeats the purpose of having a stateful firewall.
Problem 2: The Firewall Sits at the Wrong Point in the Network
This is the most fundamental issue, and the one that no amount of firewall tuning can fix. Your firewall sits behind your network link. Traffic must traverse your uplink, enter your network, and arrive at the firewall before any rules can be applied. If the attack volume exceeds your link capacity, the firewall never even sees the packets.
Consider a typical setup: you have a 10 Gbps uplink from your ISP, and a firewall sitting at the edge of your network. An attacker launches a 15 Gbps UDP amplification flood. The traffic arrives at your ISP's router and is forwarded toward your link. Your 10 Gbps link can only carry 10 Gbps. The remaining 5 Gbps is dropped at the ISP's router due to interface congestion. But the 10 Gbps that does arrive completely saturates your link. Every service behind that link is unreachable, regardless of what your firewall rules say.
Your firewall could have a perfect rule that drops 100% of attack traffic with zero false positives. It does not matter. The bandwidth is consumed before the firewall can act. Legitimate traffic is crowded out by the flood and either dropped at the ISP's congested interface or delayed beyond usability.
The bandwidth problem in numbers
- Average enterprise uplink: 1 to 10 Gbps
- Average DDoS attack size (2025): 5 to 15 Gbps
- Large DDoS attacks: 100 Gbps to 1+ Tbps
- Conclusion: Even an average attack can saturate most enterprise links
This is why effective DDoS mitigation must happen upstream of your network, at the ISP edge, at a scrubbing center, or in the cloud before the traffic ever reaches your link. A firewall cannot filter traffic that never arrives at its interface.
Problem 3: Static Rules vs. Dynamic Attacks
Firewall rules are static by nature. You write a rule, deploy it, and it stays in place until someone changes it. DDoS attacks are dynamic. They shift source IPs, change protocols, rotate ports, and morph attack vectors mid-stream. A rule that blocks today's attack vector is useless against tomorrow's variant.
Modern DDoS attacks commonly use multiple vectors simultaneously. An attacker might launch a SYN flood on port 443, a UDP amplification flood on random high ports, and an HTTP slow-read attack against your application, all at the same time. Each vector requires different firewall rules to address. By the time you have identified and written rules for the first vector, the attacker has added two more.
Even automated rule generation has limits. Writing effective firewall rules requires understanding the attack pattern, which requires analysis time. The attack is causing damage during that analysis window. And if the attack morphs after you deploy rules, you start the cycle over.
Problem 4: Cloud Firewalls Have API Rate Limits
If you run infrastructure in AWS, GCP, or Azure, your "firewall" is likely a security group, network ACL, or cloud-native firewall service. These are managed through APIs, and those APIs have rate limits that become a critical constraint during an attack.
AWS security group modifications, for example, are subject to API throttling. During a fast-moving DDoS attack where source IPs change every few seconds, you might need to update rules hundreds of times per minute. The API will throttle you long before you can keep up with the attack. GCP and Azure have similar constraints.
- AWS EC2 API: Security group rule modifications are throttled at roughly 10 to 50 requests per second depending on the API action and account limits.
- GCP: Firewall rule insertions are limited and subject to eventual consistency delays.
- Azure: NSG rule updates have rate limits and can take 30 seconds or more to propagate.
This means that even if you have automation that detects attack source IPs and pushes firewall rules, the cloud provider's API throttling prevents you from responding fast enough. The attack changes faster than you can update rules.
Problem 5: Next-Gen Firewalls Add Latency and Have Throughput Ceilings
Next-generation firewalls (NGFWs) from vendors like Palo Alto, Fortinet, and Check Point add deep packet inspection, TLS decryption, intrusion prevention, and application-layer filtering. These features are valuable for security, but they come at a cost: every packet must be inspected, which adds latency and limits throughput.
An NGFW rated for 10 Gbps throughput with all features enabled might only achieve 3 to 5 Gbps in practice when TLS decryption and IPS are active. Under a DDoS flood, those inspection engines become the bottleneck. The firewall's CPU spikes to 100%, legitimate traffic slows to a crawl, and the device either starts dropping packets indiscriminately or crashes entirely.
Some NGFW vendors offer "DDoS protection" modules, but these are typically basic rate limiting and threshold-based blocking. They lack the behavioral analysis and traffic profiling needed to distinguish sophisticated attack traffic from legitimate spikes. A flash sale that triples your traffic looks the same as a DDoS attack to a simple rate limiter.
Problem 6: WAFs Only See Layer 7
Web Application Firewalls (WAFs) inspect HTTP and HTTPS traffic at Layer 7 of the OSI model. They are excellent at blocking SQL injection, XSS, and application-layer attacks. But they are completely blind to Layer 3 and Layer 4 volumetric attacks.
A UDP amplification flood never reaches the WAF because it is not HTTP traffic. A SYN flood may reach the WAF's TCP stack, but the WAF has no mechanism to mitigate it beyond what the underlying OS provides. An ICMP flood, a GRE flood, a DNS amplification flood — none of these are visible to a WAF.
This creates a dangerous blind spot. Organizations that deploy a WAF and consider themselves "protected against DDoS" are only protected against one category of DDoS: application-layer HTTP floods. The other 70 to 80% of DDoS attack volume, which consists of volumetric L3 and L4 floods, bypasses the WAF entirely.
According to industry reports, volumetric L3/L4 attacks account for roughly 75% of all DDoS attacks by volume. A WAF-only strategy leaves you exposed to three-quarters of the threat landscape.
What You Actually Need: Upstream Detection and Mitigation
The solution is not to replace your firewall. Your firewall is still essential for access control and security policy enforcement. The solution is to add DDoS detection and mitigation that operates upstream of your firewall, before attack traffic consumes your bandwidth and overwhelms your stateful inspection.
Detection at the host level, mitigation at the network edge
Effective DDoS protection requires two capabilities that firewalls lack: real-time traffic analysis that can distinguish DDoS floods from legitimate traffic spikes, and the ability to trigger mitigation upstream where bandwidth is abundant.
Flowtriq takes this approach. The Flowtriq agent runs on your servers and analyzes traffic patterns in real time. When it detects an attack, it does not just add firewall rules locally. It triggers upstream mitigation through BGP FlowSpec, RTBH, or cloud scrubbing, stopping the attack before it reaches your link. The local firewall rules serve as a first line of defense for smaller attacks, but the real protection comes from pushing filtering upstream.
- Local firewall rules (iptables/nftables): Handle small attacks under your link capacity. Deployed in under 2 seconds.
- BGP FlowSpec: Push surgical filtering rules to your upstream router. Stops volumetric attacks at the network edge.
- RTBH (Remote Triggered Black Hole): Sacrifice one IP to save the network. Drops all traffic at the provider edge.
- Cloud scrubbing: Reroute traffic through a scrubbing center for attacks that exceed all local capacity.
This layered approach means your firewall does what it does best — stateful inspection and access control — while upstream mechanisms handle the volumetric problem that firewalls were never designed to solve.
Automated response is essential
Even if you understand that mitigation must happen upstream, manual response is too slow. DDoS attacks reach peak volume in 10 to 30 seconds. A human cannot detect the attack, analyze it, decide on a mitigation strategy, and deploy upstream rules in that window. Automated detection and escalation is the only way to respond at attack speed.
Flowtriq's auto-escalation chain handles this automatically. Detection triggers local firewall rules within 2 seconds. If the attack exceeds local capacity, the system escalates to BGP FlowSpec within 5 seconds, then to RTBH or cloud scrubbing within 10 seconds. No human intervention required. Your team gets notified, but the attack is already being mitigated.
Your firewall is still important. Nothing in this article suggests removing your firewall. Firewalls remain essential for access control, segmentation, and stateful inspection of legitimate traffic. The point is that firewalls should not be your only line of defense against DDoS. They need to be part of a layered strategy that includes upstream detection and mitigation.
Stop relying on your firewall alone for DDoS protection. Try Flowtriq free for 7 days and add upstream detection and automated mitigation to your existing infrastructure.
Back to Blog