Carpet Bombing DDoS: Detect and Mitigate Prefix-Wide Attacks

A carpet bombing DDoS attack spreads traffic across many IP addresses in a prefix, often an entire /24, so that no single host crosses a per-IP alert threshold while the prefix as a whole is saturated. The fix is to detect on aggregated per-prefix bps/pps (plus destination-spread signals) and to mitigate at the prefix level with FlowSpec or scrubbing, not by blackholing individual IPs.

What carpet bombing looks like

Classic volumetric attacks hit one victim IP with a large flood. Your detector sees one destination with a huge bps/pps number, fires, and you blackhole or filter that /32.

Carpet bombing changes the shape of the traffic. The attacker sends a modest amount to every address in a range, for example all 254 hosts in 203.0.113.0/24, often rotating through reflection vectors such as NTP, DNS, memcached, CLDAP or SSDP, plus UDP floods and SYN floods.

Illustrative math:

Every host is far below its threshold. Your uplink, your router's line card, or your upstream port is not. Customers see packet loss across the whole /24 and your per-IP dashboard stays green.

The attack is common against hosting providers and ISPs because they have dense customer ranges, and because it is built to evade detection that was tuned for single-target floods.

Why per-IP thresholds miss it

Per-IP thresholds answer the question "is this host getting too much traffic?" Carpet bombing asks a different one: "is this prefix getting too much traffic, from too many sources, spread over too many destinations?"

Three common reasons the per-IP approach fails:

1. Thresholds are sized for the host. A 1 Gbps customer VPS may have a threshold of several hundred Mbps. Multiply that tolerance by 254 and you have more than your uplink.
2. Sampling hides low-rate flows. With 1:1000 sampling, a 40 Mbps stream to one IP produces few sampled packets per interval. Per-IP numbers are noisy and can look like background. Aggregating over a prefix gives you enough samples to be statistically meaningful.
3. Automatic actions are aimed at /32s. Even if one IP trips, blackholing it removes one victim and leaves 253 under attack. The attacker can also shift the range.

Detection: what to measure

You need to export flow data from your edge and analyze it on more than one level.

1. Per-prefix aggregate thresholds

Define thresholds for each customer or announced block (/24, /23, /22, or your own allocation sizes), not only per host. Typical groups:

• Each customer assignment
• Each announced prefix
• Each router/interface (to catch saturation regardless of target)

Set the prefix threshold based on the real capacity of what it sits behind, such as the uplink, the customer's commit or the downstream device, and based on its normal baseline. See our guide on NetFlow DDoS detection thresholds, baselines and sampling for how to derive baselines.

2. Destination spread

Watch the count of unique destination IPs receiving inbound traffic from a given source set or protocol/port in the same window. Normal traffic has a few hot destinations. Carpet bombing shows a flat distribution: many destinations with similar rate and the same protocol/port signature.

Useful indicators:

• Number of distinct destination IPs in a prefix receiving UDP from a single source port (123, 53, 11211, 389, 1900)
• Share of prefix traffic that is one protocol/port pair
• Sudden jump in packets per second to destinations that were previously idle

3. Protocol and port signatures

Reflection traffic has fixed source ports. Aggregating by prefix, protocol and source port gives you a clean signature to filter on, even when no single IP is loud.

4. Short windows

Carpet bombing campaigns often pulse. Use short analysis intervals and fast export timers so you do not average a 60-second burst into a quiet five-minute graph.

Exporting flows from your edge

Any of NetFlow v5/v9, IPFIX or sFlow works, as long as you export ingress traffic on your transit, peering and upstream interfaces. A few reference configurations (collector 192.0.2.10, UDP 2055):

Juniper (inline IPFIX)

set services flow-monitoring version-ipfix template ipv4 flow-active-timeout 10
set services flow-monitoring version-ipfix template ipv4 flow-inactive-timeout 10
set services flow-monitoring version-ipfix template ipv4 ipv4-template
set chassis fpc 0 sampling-instance SAMPLE-1
set forwarding-options sampling instance SAMPLE-1 input rate 1000
set forwarding-options sampling instance SAMPLE-1 family inet output flow-server 192.0.2.10 port 2055
set forwarding-options sampling instance SAMPLE-1 family inet output flow-server 192.0.2.10 version-ipfix template ipv4
set forwarding-options sampling instance SAMPLE-1 family inet output inline-jflow source-address 192.0.2.1
set interfaces xe-0/0/0 unit 0 family inet sampling input

MikroTik (RouterOS)

/ip traffic-flow set enabled=yes interfaces=sfp-sfpplus1 active-flow-timeout=30s inactive-flow-timeout=15s
/ip traffic-flow target add dst-address=192.0.2.10 port=2055 version=9

Cisco IOS-XE (Flexible NetFlow)

flow exporter NIXMON
 destination 192.0.2.10
 transport udp 2055
 export-protocol ipfix
flow record DDOS-REC
 match ipv4 source address
 match ipv4 destination address
 match ipv4 protocol
 match transport source-port
 match transport destination-port
 collect counter bytes long
 collect counter packets long
flow monitor DDOS-MON
 exporter NIXMON
 record DDOS-REC
interface TenGigabitEthernet0/0/0
 ip flow monitor DDOS-MON input

Linux (softflowd on a mirror or edge host)

softflowd -i eth0 -n 192.0.2.10:2055 -v 9 -t maxlife=60

Check that the export reflects traffic entering your network. If you export only egress or only a few interfaces, an attack arriving on an unmonitored transit link is invisible.

Mitigation: what works and what hurts

Do not blackhole the whole prefix by reflex

RTBH of a /32 stops traffic to that address, which completes the attacker's goal for that host. Blackholing an entire /24 takes all 254 customers offline to save the link. That can be a valid last resort when the link is already down, but treat it as an emergency brake, not a standard response.

If you must use RTBH, limit it to the specific addresses that are most affected, and automate removal. Our RTBH communities guide covers that workflow.

Use FlowSpec to filter by signature

When the attack is reflection-based, a FlowSpec rule that matches destination prefix, protocol and source port removes the junk and keeps legitimate traffic flowing:

set routing-options flow route CARPET-NTP match destination 203.0.113.0/24
set routing-options flow route CARPET-NTP match protocol udp
set routing-options flow route CARPET-NTP match source-port 123
set routing-options flow route CARPET-NTP then rate-limit 10m

Prefer rate-limit over discard when the port is also legitimate for some customers (DNS on 53 is the classic example). Always check what your routers support: FlowSpec implementation and limits for rule counts vary between platforms and software versions. See the FlowSpec safety guide for guardrails.

Scrub upstream when filters are not enough

Randomized UDP floods, SYN floods and attacks that fill your transit ports cannot be fixed on your own edge. Once the link is saturated, anything you configure on your router is too late. The traffic needs to be cleaned before it reaches your port.

This is where a BGP-based scrubbing service helps: your prefix is announced from the scrubbing edge, bad traffic is dropped there, and clean traffic is returned to you over a tunnel. NixGuard Edge works this way for networks with their own ASN and at least one /24, delivering clean traffic over a GRE tunnel with a BGP session inside it. It can run always-on or on-demand, and prefix filtering can use your AS-SET. Because the whole prefix is diverted, it suits carpet bombing, where the target is the range and not a host.

On-prem filtering

If the attack stays below your link capacity but threatens servers or stateful devices, an on-prem firewall such as NixGuard can apply rate limits and signature filters closer to the hosts.

A practical response plan

1. Export flows from every transit, peering and upstream interface.
2. Set thresholds per host, per customer block and per announced prefix.
3. Add destination-spread and protocol/port signature rules to your alerts.
4. Automate a first action, such as FlowSpec for known reflection ports, with a time limit.
5. Define an escalation path: on-demand diversion to scrubbing if the link utilization passes a set level.
6. Test the full chain (detection, BGP announcement, rollback) before an attack, not during one.

Common mistakes

• Only monitoring /32 thresholds. This is the main reason carpet bombing slips through.
• Using the same threshold for every prefix. A /24 of shared hosting is not a single enterprise server.
• Exporting too few interfaces. The attack arrives on the link you did not monitor.
• Long averaging windows. Pulsing attacks get smoothed into noise.
• No automatic expiry. Forgotten FlowSpec or blackhole announcements create their own outages.
• Filtering port 53 or 123 with discard everywhere. You may take down legitimate resolvers or time services.

Where NixMon fits

NixMon analyzes NetFlow v5/v9, IPFIX and sFlow with sub-second traffic analytics and supports per-IP and per-prefix bps/pps thresholds, so you can alert on a whole /24 and not only on single hosts. Mitigation actions include BGP blackhole, BGP FlowSpec, the NixGuard on-prem firewall and NixGuard Edge. Other detectors, including FastNetMon (open-source Community and commercial Advanced editions), can also act on flow data and trigger BGP actions, so whichever you evaluate, test it against a prefix-wide scenario with the thresholds above. You can try NixMon with the 15-day free trial, no credit card required.