What is a ping flood (ICMP flood)?

02Why you should not block ICMP outright

The tempting reaction is to drop all ICMP at the firewall. Do that and you break things that are not optional. ICMP carries the control messages TCP/IP relies on, and two of them in particular must get through.

Path MTU discovery depends on the "fragmentation needed" message. When a packet is too big for a link and has the Don't Fragment bit set, a router replies with ICMP type 3 code 4 (IPv4) or ICMPv6 type 2, "Packet Too Big". If you filter those, large packets vanish into a black hole: the connection establishes, then hangs the moment it tries to send a full-size segment. Tunnels make this more likely because they lower the MTU; the tunnel MTU and MSS calculator works out the sizes and the MSS clamp that keeps TCP from depending on these messages. RFC 4890 lists Destination Unreachable and Packet Too Big among the ICMPv6 messages that must not be dropped.

03Rate-limit ICMP safely

The right posture is: permit the load-bearing ICMP messages, cap echo requests per source and in aggregate, and drop the overflow. The ruleset below was syntax-checked and run in an isolated network namespace, where a 200-packet burst at high rate was trimmed to the configured allowance. It is illustrative, not a tuned policy.

• The kernel also rate-limits some outbound ICMP itself: `net.ipv4.icmp_ratelimit` (minimum milliseconds between messages to one target) and `net.ipv4.icmp_msgs_per_sec` (a host-wide per-second cap). Both apply only to the types in `icmp_ratemask`, which by default covers error messages such as destination unreachable and time exceeded, not echo replies
• `net.ipv4.icmp_echo_ignore_broadcasts` defaults to 1 and should stay there — it is what stops your host amplifying a smurf attack
• `net.ipv4.icmp_echo_ignore_all = 1` stops the host answering pings entirely; it hides you from simple probing but does nothing about the inbound bandwidth a flood still consumes
• For IPv6, `net.ipv6.icmp.ratelimit` applies the same idea; do not block ICMPv6 wholesale, as neighbour discovery itself rides on it

table inet icmp_guard {
    set ping4_src { type ipv4_addr; flags dynamic, timeout; timeout 60s; }

    chain input {
        type filter hook input priority filter; policy accept;

        # never rate-limit what PMTUD and neighbour discovery need
        icmp type destination-unreachable icmp code frag-needed accept
        icmpv6 type { packet-too-big, nd-neighbor-solicit,
                      nd-neighbor-advert, nd-router-advert } accept

        # per-source cap, then a global cap, then drop the rest
        icmp type echo-request update @ping4_src \
            { ip saddr limit rate over 5/second burst 10 packets } counter drop
        icmp type echo-request limit rate 100/second burst 200 packets accept
        icmp type echo-request counter drop
    }
}

04How to detect a ping flood

The pattern is a surge of echo requests, often with a narrow set of packet sizes and a wide, frequently spoofed set of sources. These capture filters were validated against a crafted packet set on Debian 12.

• Inbound echo-request rate climbs far above your normal monitoring baseline
• Source addresses are numerous and often do not repeat — the spoofing tell
• Outbound echo-reply volume mirrors it, if the host is answering
• Packet sizes cluster tightly, a sign of a single generator rather than organic diagnostics

# IPv4 echo requests (the inbound ping flood)
tcpdump -ni eth0 'icmp[icmptype] == icmp-echo'

# echo replies leaving you (reflected flood, or you answering a flood)
tcpdump -ni eth0 'icmp[icmptype] == icmp-echoreply'

# oversized echo requests (> ~1000 bytes on the wire)
tcpdump -ni eth0 'icmp[icmptype] == icmp-echo and greater 1000'

# IPv6 echo requests (packets without extension headers)
tcpdump -ni eth0 'icmp6 and ip6[40] == 128'

05Can a small ICMP flood take down a firewall?

Yes, if the device handles one ICMP type expensively. In 2016 analysts at TDC, the Danish operator, documented BlackNurse: a flood of ICMP type 3 code 3 (port unreachable) messages that pinned the CPU of several firewall models at rates no uplink would notice. A sustained 37 kpps — about 21 Mbit/s — was enough to stop vulnerable devices forwarding traffic. The write-up named models from Cisco, Fortinet, Palo Alto Networks, SonicWall and Zyxel, some affected only under particular configurations.

The researchers advised against simply denying type 3, because that disables path MTU discovery and can halt tunnelled traffic. Their recommendation was to rate-limit incoming ICMP on an upstream router, so the vulnerable device never sees the full rate — rate-limiting rather than blocking, applied one hop before the box that would otherwise saturate.

06What filtering can and cannot do

A ping flood is volumetric, so the only place to deal with a large one is upstream, on a network with far more capacity than the attack. Absorbed there, the echo requests never reach your link. Host rules and kernel knobs handle small floods and stop your box amplifying anything, but they cannot widen a saturated uplink — the packets are already consuming it by the time the host sees them, the same lesson as how to stop a DDoS attack. That is the ceiling a host firewall runs into whenever a flood is bigger than the link.

What edge filtering cannot do: nothing protects an address the attacker can reach directly. ICMP floods against web properties are handled as part of DDoS protection; for raw IP services the same absorption happens through routed transit rather than a proxy. Blocking ICMP on the host is not protection — it only changes whether you answer, not whether the flood arrives.