What Is a Carpet Bombing Attack?
In a traditional DDoS attack, the attacker picks a single target IP and throws everything at it. A 100 Gbps UDP flood hits one server, the monitoring system sees a massive spike on that destination, and an alert fires within seconds. The attack is obvious and the response is straightforward.
Carpet bombing flips this model. Instead of concentrating 100 Gbps on one IP, the attacker distributes the traffic across hundreds or thousands of destination IPs within a target network prefix. A /22 contains 1,024 addresses. Spread 100 Gbps evenly across all of them and each IP receives roughly 100 Mbps. That is enough to degrade service on every host in the range, but far below the threshold that most detection systems consider an attack on any individual IP.
The effect is devastating. The aggregate traffic saturates the upstream link or transit interface serving that prefix. Every server in the range experiences packet loss, increased latency, and connection timeouts. But because no single destination crosses a per-IP alert threshold, the attack can persist for hours before anyone identifies it as a coordinated DDoS event rather than a vague "network issue."
How Carpet Bombing Traffic Looks
Carpet bombing attacks share several characteristics that distinguish them from both legitimate traffic surges and traditional focused DDoS. The per-destination packet rate is relatively low, often in the range of 10,000 to 50,000 PPS per IP. The per-destination bandwidth typically sits between 50 Mbps and 200 Mbps. However, the aggregate bandwidth across the targeted prefix is enormous, often 50 Gbps to 200 Gbps or more.
The attack traffic is overwhelmingly UDP. Attackers favor amplification vectors because they provide bandwidth multiplication without requiring a large botnet. DNS amplification (source port 53), NTP monlist (source port 123), CLDAP reflection (source port 389), and memcached amplification (source port 11211) are the most common protocols observed in carpet bombing campaigns. The attacker spoofs the source IP of each target in the prefix, and the amplifiers respond with large payloads directed at every address in the range.
Here is a simplified view of how traffic distributes across a /24 during a carpet bombing attack compared to a focused attack:
Focused DDoS (single target): 192.168.1.1 ████████████████████████████████████████ 98 Gbps 192.168.1.2 ▏ 12 Mbps 192.168.1.3 ▏ 8 Mbps ... 192.168.1.254 ▏ 14 Mbps Carpet Bombing (distributed across /24): 192.168.1.1 ████ 390 Mbps 192.168.1.2 ████ 385 Mbps 192.168.1.3 ████ 392 Mbps 192.168.1.4 ████ 388 Mbps 192.168.1.5 ████ 391 Mbps ... 192.168.1.254 ████ 387 Mbps ───────────────────────────────────────────────────────────────── Aggregate: ~100 Gbps
In the focused scenario, any per-IP threshold above 1 Gbps would detect the attack instantly. In the carpet bombing scenario, a per-IP threshold set at 500 Mbps would not trigger on any individual destination. The aggregate link is saturated, every host is impacted, and the detection system reports nothing.
Why Carpet Bombing Is Increasing
Carpet bombing attacks have grown significantly over the past several years. Radware's Global Threat Analysis Report documented a sharp increase in carpet bombing campaigns, noting that they accounted for a growing share of all volumetric DDoS events targeting service providers. Netscout's Threat Intelligence Report similarly highlighted carpet bombing as one of the most challenging attack patterns for ISPs and hosting providers to detect and mitigate.
Several factors drive this trend. First, carpet bombing is harder to detect with conventional tools, which means attacks last longer and cause more damage before mitigation kicks in. Second, the attack is harder to mitigate because blackholing a single IP does not help when the entire prefix is under fire. Blackholing the whole /22 takes every customer offline, which is exactly what the attacker wants. Third, the proliferation of open amplification reflectors on the internet gives attackers access to massive bandwidth multiplication without needing correspondingly large botnets.
ISPs, hosting providers, and cloud platforms are the primary targets because they host the large contiguous IP prefixes that make carpet bombing effective. A company with a single /32 server cannot be carpet bombed. A hosting provider with a /16 is an ideal target.
Why Traditional Detection Fails
Most DDoS detection systems were designed for focused attacks. Their core assumption is that attack traffic concentrates on a small number of destination IPs, and detection works by identifying destinations that exceed a traffic threshold. This assumption breaks completely under carpet bombing. There are three specific failure modes.
Per-IP Threshold Detection
The most common detection method uses per-destination-IP thresholds. If inbound traffic to any single IP exceeds a configured value (say 500 Mbps or 100,000 PPS), an alert fires. In a carpet bombing attack, no individual IP exceeds this threshold. The attack traffic per destination might be 100 Mbps or 20,000 PPS, well within the range of "heavy but plausible" traffic for many server types. The detection system evaluates each IP independently and concludes that everything is normal.
Flow-Based Sampling
NetFlow and sFlow are the standard protocols for network traffic analysis. Most routers are configured with sampling rates of 1:1000 or 1:2000, meaning only one in every thousand packets generates a flow record. At these sampling rates, the per-IP traffic volumes in a carpet bombing attack may not produce enough flow records per destination to trigger statistical anomaly detection. The sampled data looks like a slight increase in UDP traffic spread across many destinations, which could easily be dismissed as normal variation.
SNMP Polling Intervals
Many monitoring systems rely on SNMP interface counters polled at 5-minute intervals. SNMP can detect that the total link utilization spiked, but it provides no breakdown by destination IP or protocol. The NOC sees a saturated link but has no immediate visibility into whether this is a DDoS attack, a legitimate traffic surge, or a routing issue. By the time someone pulls up flow data and correlates it, the attack may have shifted to a different prefix or stopped entirely.
The fundamental problem is that carpet bombing exploits a gap between per-IP analysis and aggregate link monitoring. Per-IP tools miss it because each IP looks normal. Aggregate tools detect the link saturation but cannot attribute it to a DDoS attack without additional context.
Detection Strategies That Actually Work
Detecting carpet bombing requires approaches that bridge the gap between per-IP analysis and aggregate monitoring. Here are four strategies that are effective against this attack pattern.
Prefix-Level Monitoring
Instead of setting thresholds per destination IP, aggregate traffic for entire subnets. Monitor total inbound traffic to each /24, /23, and /22 prefix in your infrastructure. A carpet bombing attack that distributes 100 Gbps across a /22 will show as a massive spike at the prefix level even though no individual /32 crosses its threshold. This requires your detection system to maintain prefix-level counters and baselines, which adds computational overhead but dramatically improves visibility.
Baseline Deviation on Uplink Interfaces
Monitor the total utilization of transit and peering interfaces using dynamic baselines rather than static thresholds. When the aggregate inbound traffic on an interface spikes 3x above its rolling baseline, that is an anomaly worth investigating regardless of how the traffic distributes across destinations. This approach catches carpet bombing because the aggregate impact is always visible at the interface level, even when per-IP analysis shows nothing unusual.
Per-Protocol Anomaly Detection
Carpet bombing attacks typically use a single amplification protocol. A sudden spike in UDP traffic from port 53 (DNS) or port 123 (NTP) hitting hundreds of destinations simultaneously is not normal traffic behavior. Monitoring protocol distributions at the prefix level and alerting on sudden shifts in the UDP/TCP ratio or on spikes in specific source port volumes is an effective detection signal. If your /22 normally sees 15% UDP traffic and it suddenly jumps to 85% UDP from port 53, that is a carpet bomb using DNS amplification.
Host-Based Detection
This is where the problem becomes much simpler. When every server in the target prefix runs a lightweight detection agent, each host independently observes its own share of the carpet bombing traffic. A server that normally handles 20 Mbps of inbound traffic suddenly receiving 120 Mbps of unsolicited UDP from port 123 does not need prefix-level aggregation to know something is wrong. The detection happens at the host level, where the signal-to-noise ratio is highest.
This is the approach Flowtriq uses. Each node running the Flowtriq agent monitors its own inbound traffic against dynamic baselines. When the carpet bombing traffic arrives, every node in the affected prefix detects its individual share of the attack independently. The per-node alert threshold does not need to account for aggregate prefix traffic because each node only needs to detect its own anomaly.
How Flowtriq Detects Carpet Bombing
Flowtriq's detection model is inherently resistant to carpet bombing because it operates at the host level rather than the network perimeter. Here is how the detection chain works in practice.
Each Flowtriq agent continuously monitors inbound packets per second, bytes per second, and protocol distribution on its host. It maintains dynamic baselines using exponentially weighted moving averages that adapt to the normal traffic profile of that specific server. When a carpet bombing attack begins, the agent on each targeted host detects a deviation from its local baseline. A server that normally sees 15,000 PPS inbound is now seeing 65,000 PPS, with 90% of it being UDP from port 53. The agent classifies this as a DNS amplification attack and reports an incident to the Flowtriq dashboard.
The dashboard then aggregates these per-node incidents. When 50 nodes in the same /22 all report DNS amplification incidents starting within the same 30-second window, the correlation is unmistakable. The dashboard presents this as a carpet bombing event, showing the affected prefix, the attack vector, the per-node and aggregate traffic volumes, and the timeline. The operator sees the full picture without needing to manually correlate flow data across hundreds of destinations.
This approach has several advantages over traditional network-level detection. There is no sampling error because the agent sees every packet on its host. There is no polling delay because detection runs continuously. And there is no threshold tuning problem because dynamic baselines adapt to each node's individual traffic profile automatically.
Mitigating Carpet Bombing Attacks
Detection is only half the problem. Mitigating a carpet bombing attack is significantly more complex than mitigating a focused attack because standard blackhole routing (RTBH) does not apply. Blackholing a single IP is pointless when hundreds of IPs are targeted, and blackholing the entire prefix takes all your customers offline.
The most effective mitigation strategies for carpet bombing include:
- BGP FlowSpec rules: Deploy FlowSpec rules that match the attack signature (protocol, source port, packet size) across the entire affected prefix. A FlowSpec rule that drops UDP traffic from source port 53 with packets larger than 512 bytes will eliminate DNS amplification traffic across all destinations without affecting legitimate DNS responses. Flowtriq can generate and deploy these FlowSpec rules automatically through its BGP adapter integrations.
- Upstream scrubbing for the prefix: Route the entire affected prefix through a scrubbing center using BGP announcements. The scrubbing center filters the attack traffic and forwards clean traffic back to your network. This is more expensive than blackholing but preserves service availability for every host in the prefix.
- Source-based filtering: If the amplification reflectors are concentrated in a small number of ASNs or IP ranges, applying ACLs that drop traffic from those sources at your border routers can reduce the attack volume. This is a blunt instrument but can provide immediate relief while more precise mitigation is configured.
- Rate limiting by protocol: Apply per-prefix rate limits for the specific protocol used in the attack. Rate limit inbound UDP from port 123 to 10 Mbps per /24 prefix. This caps the attack impact without completely blocking the protocol for legitimate use.
Speed matters in mitigation. A carpet bombing attack that persists for 30 minutes before detection and another 15 minutes before mitigation deploys has caused 45 minutes of degraded service across your entire prefix. Automated detection and automated FlowSpec deployment can reduce this to under 60 seconds from attack start to mitigation active.
Key Takeaways
Carpet bombing is not a theoretical concern. It is one of the most common attack patterns targeting ISPs, hosting providers, and any organization with large IP allocations. The attack works precisely because it exploits the per-IP detection model that most monitoring systems rely on.
- Carpet bombing distributes attack traffic across hundreds or thousands of IPs in a prefix, keeping per-IP volumes below detection thresholds while saturating the aggregate link.
- Per-IP threshold detection, sampled NetFlow, and SNMP polling all fail to reliably detect carpet bombing in time to prevent service impact.
- Effective detection requires prefix-level aggregation, interface baseline monitoring, or host-based detection that catches each node's share of the attack independently.
- Mitigation requires prefix-wide approaches like FlowSpec rules or upstream scrubbing rather than per-IP blackholing.
- Host-based detection (the Flowtriq approach) sidesteps the per-IP threshold problem entirely because each agent detects its own anomaly without needing visibility into the broader prefix.
Ready to detect carpet bombing? Flowtriq's per-node agents detect each host's share of a carpet bombing attack independently, then correlate across your infrastructure to show the full picture. Start your free trial and deploy across your prefix in under 5 minutes.