ICMP Flood

The ping flood is the attack everyone learns first, and the one whose defence is most often overdone. It has no leverage, no handshake, no state to exhaust: it is simply packets, sent as fast as the attacker can send them.

That simplicity makes the mitigation straightforward and the over-mitigation expensive.

At a glance

Appliance	ICMP message	Attack use	Safe to block?
Echo request and reply	The classic ping flood	Rate-limit rather than block; diagnostics depend on it
Destination unreachable	Rarely useful to an attacker	No: it carries path MTU information
Time exceeded	Not a flood vector	No: traceroute and loop detection depend on it
Redirect	Can be abused to alter routing	Generally yes, at the network edge
Malformed or truncated	Fragmentation and parser attacks	Yes: no legitimate counterpart

Only two rows are safe to block outright. The reflex to drop ICMP as a category treats the whole protocol as if it were the first row.

What it exhausts

Bandwidth, if the attacker has enough of it, in which case the contest is decided upstream of your circuit like any other volumetric attack.

Packet-processing budget, which is the more common outcome. Small ICMP packets at high rate produce per-packet work on every device in the path, and a device can saturate on packet rate well below the bit rate that would trouble the link.

Reply generation, where hosts answer echo requests. Each request produces a response, so an unprotected host spends outbound capacity as well as inbound.

There is no amplification in a direct flood: the attacker sends what the attacker has. That places it firmly among the attacks bounded by the uplink, and it is why the arithmetic in capacity sizing settles the question quickly.

How it differs from similar attacks

A UDP flood behaves almost identically at the network layer, and the two are frequently generated by the same tools in the same campaign. The difference that matters operationally is that ICMP is a control protocol: some of its messages are load-bearing for ordinary connectivity, and UDP to a closed port is not.

That asymmetry is the whole reason this page exists. The mitigation is the same; the cost of getting it wrong is much higher.

Observable telemetry

• ICMP packet rate rising sharply against a low bit rate.
• Echo requests dominating the ICMP mix, where normally they are a small fraction.
• Outbound echo replies rising in step, on hosts that answer.
• Source distribution either very narrow, indicating a simple tool, or very wide, indicating forged sources.
• Device CPU rising with no change in session counts.

Common false positives

Monitoring systems. Availability monitoring is built on ping, and a system checking many targets frequently produces a legitimate ICMP rate that per-source limits will refuse. Whitelist them before setting limits, not after.

Traceroute and diagnostics. Ordinary troubleshooting produces bursts of ICMP that look anomalous against a quiet baseline.

Path MTU discovery. Legitimate packet-too-big messages arrive in bursts when a path changes, which is precisely when discarding them causes the most damage.

Mitigation by layer

Rate-limit by message type, not by protocol. Echo requests get a ceiling derived from your measured monitoring traffic; control messages are left alone.

Never block the control messages. Destination unreachable and time exceeded carry information that TCP and applications depend on. RFC 4890 sets out the ICMPv6 case explicitly, and the reasoning applies to IPv4.

Disable directed broadcast, which is default on modern equipment and worth confirming rather than assuming.

Upstream rate limiting where the volume approaches the circuit, because at that point nothing on your premises can help. FlowSpec can express a protocol-and-rate match cleanly.

Ingress filtering at network edges reduces the forged sources these floods usually carry — the BCP 38 argument in its simplest application.

Operational pitfalls

Blocking ICMP as a category. The single most common over-correction in this field. It produces intermittent, hard-to-diagnose application failures weeks later, attributed to everything except the firewall rule.

Setting the echo limit from a quiet period. Monitoring systems produce a steady legitimate rate that a limit derived from an idle window will refuse.

Forgetting IPv6. Blanket ICMPv6 filtering breaks neighbour discovery, which breaks the segment rather than degrading it.

Safe validation

Generate an echo flood at increasing rate against a lab target and record the packet rate at which device CPU saturates, the frame size used, and whether legitimate monitoring traffic survived. Then repeat with your intended rate limit in place and confirm the monitoring survived that too.

The second run is the one that matters, because the failure mode of this attack’s defence is refusing your own systems rather than admitting the attack. Isolation requirements are in the test lab guide.