Reflection and amplification attacks explained

02The amplifying protocols

The bandwidth amplification factor (BAF) is the ratio of reply bytes to request bytes. The figures below are from the US-CERT / CISA alert TA14-017A, which compiled them largely from Christian Rossow's NDSS 2014 research. Higher is worse.

03WS-Discovery: a newer reflector on UDP 3702

WS-Discovery is a multicast protocol that devices use to find each other on a local network: a probe goes to UDP port 3702 and matching devices answer with an XML description of themselves. It was never meant to face the internet, but many cameras, video recorders and printers answer probes from anywhere, and in 2019 attackers began reflecting it. It postdates the CISA alert, so it is not in the table above.

ZeroBS, which analysed an attack on one of its clients in August 2019, saw amplification factors of 30 to 100 depending on the device and cited scan data showing roughly 630,000 exposed addresses. On 18 September 2019 Akamai's SIRT described an attack on a gaming customer that peaked at 35 Gbit/s, measured replies of up to 15,300% of the probe's size, about 153 times, and found 802,115 devices answering its internet-wide probe, CCTV cameras and DVRs most often.

For a victim the tell is UDP from source port 3702, which ordinary web or game traffic has no reason to use, so an upstream filter can drop or rate-limit it by that port. To keep your own devices out of the pool, block inbound UDP 3702 at the network border; device makers can close it for good by answering only on the local multicast scope.

04A worked calculation

The amplification factor turns a small committed upstream into the flood the victim actually receives. The sum is just multiplication, but it makes the economics vivid.

Suppose an attacker can send 1 Gbit/s of spoofed NTP monlist requests, and enough open NTP reflectors are available to absorb them. At NTP's factor of 556.9, the theoretical traffic delivered to the victim is 1 Gbit/s x 556.9 = roughly 557 Gbit/s. In practice the ceiling is set by how many reflectors the attacker has and their upstream capacity, not by the factor alone — but the leverage is why a modest upstream can produce a flood hundreds of times its own size.

Not every record is amplified, though. The roughly 840-million-packet-per-second attack OVHcloud mitigated in April 2024 was 99% TCP ACK flood with a 1% DNS reflection component — reflection is often one ingredient in multi-vector campaigns rather than the whole attack.

# traffic arriving from the classic reflector source ports
tcpdump -ni eth0 'udp and (src port 123 or src port 11211
    or src port 1900 or src port 389 or src port 19 or src port 53)'

# large NTP replies specifically (source port 123, oversized)
tcpdump -ni eth0 'udp src port 123 and greater 200'

05Why spoofing and open reflectors persist

Reflection needs two preconditions, and both are matters of hygiene that someone else has to fix.

The first is source-address spoofing. If every network validated that outbound packets carry a source address it legitimately owns — the practice standardised as RFC 2827 / BCP 38 — an attacker could not forge the victim's address, and reflection would collapse. Adoption is incomplete because the benefit accrues to everyone else, not to the network doing the filtering.

The second is open reflectors: NTP servers still answering monlist, memcached exposed to the internet with UDP on, SSDP devices reachable from outside, resolvers answering recursive queries for strangers. Each one is a weapon waiting to be pointed. Closing them — restricting to local clients, disabling the abused command, firewalling the port — removes amplifiers from the pool one at a time.

06How to check your server is not a reflector

List the UDP ports listening on your machine and close or restrict any that answer strangers with more bytes than they received. The command below shows listeners on the classic amplification ports together with the process that owns each one; anything bound to a public address there deserves a second look. It was run on Debian 12 (iproute2 6.1) in an isolated network namespace with test sockets, and matched exactly the amplification ports that were open.

• Operators: implement BCP 38 ingress filtering so your network cannot emit spoofed packets
• NTP: upgrade past the monlist flaw (CVE-2013-5211) or add noquery to the default restrict line, as CISA advised
• Memcached: keep UDP off (the default since 1.5.6; it is only enabled explicitly with -U) and bind to localhost; never expose UDP 11211 to the internet
• SSDP / CLDAP / SNMP: do not expose these services to the public internet; restrict to the local segment
• Victims: you cannot fix other people's reflectors, so absorb the flood upstream — see how to stop a DDoS attack

ss -Hulnp '( sport = :19 or sport = :53 or sport = :123 or sport = :161 or' \
          'sport = :389 or sport = :1900 or sport = :11211 )'

07What edge filtering and scrubbing can do

Amplified reflection is purely volumetric, so for the victim there is only one place to deal with it: upstream, on a network with far more capacity than the flood. There, reflected UDP is recognised and discarded — it arrives from predictable service source ports, often with distinctive sizes, and almost never matches a request the victim actually made. Absorbed upstream, it never touches the victim's link.

The honest limits are worth stating. The victim cannot stop reflection at source — the spoofing and the open servers are other people's networks. A local firewall is useless, because the bandwidth is spent crossing the uplink before the firewall sees a packet. And for non-HTTP services an application proxy does not apply; the absorption happens through routed Layer 3/4 filtering, the model behind GRE transit, which is coming soon. For a website behind a reverse proxy such as GuardX, reflected floods land on the proxy's network instead of the origin, but the volume itself is handled by capacity, not cleverness.