ICMP flood: the attack that punishes a careless fix

The mechanism behind that answer is described on attack layers: this traffic does not reach the stage where requests exist.

ICMP is the protocol systems use to report problems and to test reachability. An echo request asks a host to confirm it is there; an echo reply confirms it. Both are small, and neither requires a connection.

A flood exploits two properties of that exchange.

The reply doubles the cost. A host answering echo requests spends outbound bandwidth in proportion to what arrives. Where the inbound flood is already near capacity, the replies compete with your own traffic for the remaining room.

Source addresses can be forged. As with any protocol that needs no session, what appears in your counters is not necessarily the sender, and replies may be travelling to a host that never asked. That second case makes your machine a participant rather than only a victim.

The technique is old and remains in use because it needs nothing sophisticated. It is closest in shape to the UDP flood, and the two are frequently combined in the same event.

The names get used interchangeably, and the distinction decides what you should worry about.

A ping flood is a volume problem: well-formed messages in quantities that exhaust a link. The historic vulnerability known as ping of death was not about volume at all. It involved a single malformed message assembled in a way that overflowed buffers in network stacks of that era, crashing the host outright. It was a software defect, it was fixed in every mainstream system a long time ago, and there is nothing to configure about it today.

The practical consequence: if someone proposes disabling diagnostics because of ping of death, they are protecting against a defect that no longer exists, at the cost of the trade-off described below.

Systems negotiate the largest packet size a path can carry by sending traffic and being told, through ICMP, when something is too large to pass. Remove those messages and the sender learns nothing: packets vanish silently, connections establish and then stall, and the failure appears only for clients whose path has a smaller limit somewhere. Typical symptoms are a page that starts loading and never finishes, or transfers that work from one network and hang from another.

The effect is worse for modern connections, where routers do not fragment traffic on the sender's behalf and the notification is the only mechanism available.

So the rule is narrow rather than absolute: limit echo traffic, keep the messages that report problems.

Three signals, and the third is the one people miss.

Interface counters rise while the application is idle. The same picture as any volumetric attack: traffic arrives, nothing is served.

Outbound volume rises alongside inbound. Distinctive to this family. If your egress graph mirrors your ingress graph during an outage, something is being answered at scale.

Diagnostics stop being useful. The tools you would reach for to investigate use the same protocol being flooded, so their results become unreliable precisely when you need them.

Four measures, in order of usefulness.

Rate limit echo traffic, do not discard the protocol. Answering a reasonable number of requests and dropping the excess preserves diagnostics while removing the lever. This is the correct default and it belongs as far upstream as possible.

Filter before your link. As with every volumetric attack, traffic removed after it crosses your connection has already done its work. Your connectivity provider can drop by protocol and rate at their edge.

Keep the messages that report problems. Specifically the ones that report a packet was too large to pass. These are not optional, and treating them as noise is what produces the failures described above.

Do not answer on behalf of things you do not run. Where a network is configured to respond to messages addressed to it as a group rather than individually, a single forged request can produce many replies toward a victim. Current defaults suppress this, so confirm it rather than assuming.

What does not help: request rules, challenges, and anything that inspects traffic after it has arrived, for the same reason as every other attack in this category.

Two things to do in the moment, and neither is a permanent change.

Ask upstream for a rate limit rather than making one locally. A limit applied on your own equipment still receives the traffic and still spends the link. The same limit applied by whoever carries your connectivity removes it before the cost is paid, and they can usually put one in place quickly on request.

Write down what you changed. Emergency measures against this attack are the kind that survive it: a protocol discarded wholesale, a diagnostic tool silenced, a filter added at three in the morning. Each one looks harmless afterwards and each one degrades something later. A note saying what was changed and why is what makes removal possible.

Neither step requires knowing who is sending the traffic, which is convenient, because you probably cannot find out.

Bridge WAF operates on requests, so it does not address this attack, and saying otherwise would be inaccurate. What applies is where traffic terminates: when visitors reach your site through the platform's edge, the addresses being flooded are not your origin's, and the capacity absorbing volume is the platform's. Which component covers which layer is a fair question to put to any provider. See what the platform offers at Bridge CDN.