How did the IPv4 Smurf attack use ICMP echo and directed broadcasts to amplify a flood, and what stopped it?
answer
- a third party does the sending
- forged source is the victim
- network-prefix-directed broadcast
- one request, many replies
- RFC 2644 flipped the default
basics
~20 sA Smurf attacker sends ICMP echo requests, forged with the victim's address as source, to a network's directed-broadcast address; every host there replies to the victim. RFC 2644 made routers refuse directed broadcasts by default, removing most amplifiers.
solid answer
~40 sSmurf is ICMP reflection with amplification. The attacker forges echo requests (type 8) whose source address is the victim's and whose destination is a network-prefix-directed broadcast, such as `198.51.100.255` for `198.51.100.0/24`. If that network's router forwards directed broadcasts, every host on the subnet receives the request and sends an echo reply (type 0), carrying the same data, to the victim. One request becomes as many replies as there are responders, and the attacker's address never appears. RFC 1812 had required routers to forward directed broadcasts by default; RFC 2644 (BCP 34, 1999) reversed that, so receiving and forwarding them must be off unless configured. RFC 1122 also lets hosts silently discard echo sent to a broadcast address, and filtering forged source addresses at the attacker's own network stops the spoofing.
go deeper
Recall the three parties: attacker, amplifier subnet, victim. Know that the attacker forges the victim's address as the source and sends echo to a broadcast address.
Explain why one request becomes many replies, why only the subnet's own router can recognise a directed broadcast, and what RFC 2644 changed about the router default.
Show you can audit for it: check that routers refuse directed broadcasts, hosts ignore broadcast echo, and the edge drops traffic to internal broadcast addresses, and say why the victim cannot fix it alone.
Use Smurf as the pattern for reflection risk: any service that answers unverified sources with more than it received makes you someone else's amplifier, so defaults and egress filtering are a duty to other networks.
## The three parties A Smurf attack involves three networks, and only one of them belongs to the attacker: 1. The **attacker** builds ICMP **echo requests** (type 8) with the **source address forged** to the victim's, say `203.0.113.10`, and the **destination set to a directed broadcast**: the all-ones host address of someone else's subnet, such as `198.51.100.255` for `198.51.100.0/24`. 2. The requests cross the Internet like any unicast datagram. Under RFC 1812, a transit router cannot tell that `198.51.100.255` is a broadcast, because it does not inspect the host part of a remote prefix; only the router attached to that subnet knows. 3. That last router, the **amplifier's** router, receives a datagram addressed to its own subnet's broadcast address. If it forwards directed broadcasts, it delivers the request as a link-layer broadcast to **every host on the subnet**. 4. Each host that runs an echo server sends an **echo reply** (type 0) to the address it believes asked: the victim's. 5. The **victim** receives a flood of replies from many real, innocent hosts and never sees the attacker's address. ## Where the amplification comes from Echo semantics make the reply about as large as the request: RFC 1122 and RFC 1812 require that the data received in an echo request be returned entirely in the reply. So each request yields **one reply per responding host**, each about the same size. With 100 responding hosts, 1 Mbit/s of forged requests becomes roughly 100 Mbit/s at the victim. The amplifier network's own uplink carries the same load in the outbound direction, so it is a second victim. ## Why ICMP's own safety rules did not help - RFC 1122 §3.2.2 forbids sending an ICMP **error** in response to a datagram addressed to a broadcast or multicast address. That rule prevents error storms, but an echo reply is a **query response**, not an error, so it does not apply. - RFC 1122 deliberately left echo to broadcast as a **MAY discard**, recording a "passionate debate" between those who valued it for diagnostics and those who feared packet storms. Many hosts answered. - RFC 1812 §5.3.5.2 required routers to have an option to disable forwarding directed broadcasts, but that option had to **default to permit** receiving and forwarding them. ## The fixes, layer by layer | Where | Control | Source | |---|---|---| | Amplifier's router | Receiving and forwarding network-prefix-directed broadcasts must **default to off** | RFC 2644 (BCP 34), updating RFC 1812 §4.2.2.11 and §5.3.5.2 | | Hosts on the amplifier subnet | Silently discard echo requests sent to a broadcast address | RFC 1122 §3.2.2.6 (MAY) | | Routers as echo servers | May decline to answer echo addressed to broadcast or multicast | RFC 1812 §4.3.3.6 (MAY) | | Attacker's own network | Drop outbound datagrams whose source address does not belong there (ingress filtering) | Referenced by RFC 2644 | | Edge firewall of any site | Drop inbound packets addressed to internal broadcast addresses | Local policy | RFC 2644's own discussion is blunt: directed broadcasts on the Internet backbone appeared to be used almost entirely for attacks, and networks that permitted them from outside became "Smurf amplifiers". Changing the **default** mattered because newly installed routers no longer joined the problem unless someone deliberately enabled the feature. The victim, by contrast, has no protocol-level fix: by the time replies reach its edge, its uplink is already full. That is a flood-absorption problem for upstream capacity, not something an ICMP rule at the victim can solve. ## IPv6 and the legacy - IPv6 has **no broadcast**, so the directed-broadcast form does not exist there. RFC 4443 does say a node SHOULD answer an echo request sent to a multicast address, so a site should not let outside echo requests reach internal multicast groups. - Smurf itself is largely historical, but its shape is the template for every later **reflection attack**: a forged source, a responder that answers without verifying who asked, and a reply set larger than the request. ## Common misconceptions - That the replies come from the attacker's machines: they come from innocent hosts on the amplifier subnet. - That turning off ICMP **error** generation stops it: echo replies are not errors. - That RFC 1812 always told routers to drop directed broadcasts: it required forwarding by default until RFC 2644 changed it.
- What decides the amplification factor of an IPv4 Smurf attack?The number of hosts on the amplifier subnet that answer an echo request sent to its broadcast address. Each echo reply returns the request's data, so replies are about the same size as the request, and the factor is roughly the count of responders. With RFC 2644 defaults on the router and hosts discarding broadcast echo, the factor falls toward zero.
- Could an attacker on the victim's own IPv4 subnet run a Smurf-style attack against a neighbour?Yes. On the local link no router decision is involved: an echo request sent to the subnet's broadcast address with a neighbour's address as the forged source reaches every host directly, and each that answers replies to the neighbour. The router default from RFC 2644 does not help on-link; hosts discarding echo sent to a broadcast address, which RFC 1122 permits, is the control that does.
Smurf is like posting a letter to an office's all-staff mailbox with someone else's return address and a request to reply: every employee answers, and the pile of replies lands on the person whose address you wrote. The lasting fix was for office mailrooms to stop accepting all-staff letters from outside, just as routers stopped forwarding directed broadcasts by default.
saying these in an interview costs you the question
- Smurf replies come from the attacker's own machines.
- Disabling ICMP error generation on routers stops Smurf.
- RFC 1812 always told routers to drop directed broadcasts by default.
- IPv6 is exposed to Smurf through its subnet broadcast address.
- Blocking echo replies at the victim's firewall frees the victim's uplink.