Attack class
Reflection and Amplification Attacks
Last updated: August 2026 · Two properties that combine badly · Reading time ~10 min

Reflection means sending requests with the victim's address forged as the source, so third-party servers send their answers to the victim. Amplification means those answers are larger than the requests. They are separate properties that combine badly: reflection hides the origin, amplification multiplies the bandwidth, and together they let a small attacker saturate a large circuit.

What it exhausts
Bandwidth, arriving from everywhere at once. The victim sees a flood of answers to questions it never asked, from servers that are behaving correctly.
How the two properties combine
Reflection works because UDP does not validate source addresses. An attacker sends a query with your address in the source field; the server answers your address. Nothing in the path objects unless the attacker’s own network refuses to forward packets with forged sources RFC 2827.
Amplification works because some protocols answer disproportionately. A short query can produce a long response, and the ratio between them is the bandwidth amplification factor CISA TA14 017A.
Neither alone is decisive. Reflection without amplification gives anonymity at one-to-one cost. Amplification without reflection points the answer back at the attacker. Together, a modest uplink becomes a large flood aimed at someone else.
The published factors, with the command each was measured against, are in the amplification-factors dataset. They are measurements under stated conditions rather than constants, which is why the dataset carries no single universal figure.
How it differs from similar attacks
A direct UDP flood consumes the same resource and carries no leverage or concealment. A DNS query flood aimed at your own authoritative servers is an application-layer attack on those servers rather than a reflection off them — same protocol, different target, different answer. Carpet bombing is about how volume is distributed across destinations and can use reflection as its mechanism.
Observable telemetry
- Large UDP responses arriving from source ports characteristic of the abused protocol — 53, 123, 11211, 1900, 19, 17.
- No matching outbound queries in your own flow records.
- Source addresses widely dispersed and belonging to legitimate infrastructure.
- Packet-size distribution clustered at whatever the reflecting protocol’s answer size is, which is often distinctive enough to write a filtering rule against.
Common false positives
Legitimate high-volume UDP services look superficially similar. A busy authoritative DNS server, a video platform or a VoIP estate all produce large volumes of UDP with dispersed sources. The distinguishing feature is the absence of a matching request — which means the detection has to be able to correlate, not just count.
Mitigation by layer
Upstream is where this class is answered, because by the time it reaches you the circuit is already the constraint. A FlowSpec rule matching protocol and source port removes the vector while leaving the destination reachable; RTBH is the blunt fallback.
Scrubbing absorbs it at a scale you would not build, which is the standard commercial answer for anyone whose circuit is smaller than a plausible attack.
Your own edge can drop UDP to ports nothing listens on, which costs nothing and removes a surprising share.
As a good neighbour: do not run the reflectors. Audit what answers unsolicited UDP, disable UDP on memcached, restrict NTP, and make DNS resolvers not open. For authoritative DNS, TCP support is now an operational requirement rather than an option RFC 9210, and response-rate limiting bounds what your servers contribute to somebody else’s attack.
Operational pitfalls
Blocking the reflectors blocks innocent infrastructure and achieves little, since the attacker moves to another set.
Filtering the protocol wholesale — dropping all UDP/53 — removes the attack and your DNS with it. The narrower the rule, the better, which is the discipline the FlowSpec page insists on.
Ignoring your own exposure. Most organisations check whether they are being attacked and never check whether they are reflecting. The second question is answerable in an afternoon.
Safe validation
Do not generate reflection traffic. Testing this class by actually reflecting means sending forged packets to third-party servers, which is an attack on them regardless of intent.
What you can do safely: scan your own address space for services that answer unsolicited UDP, confirm your egress path does not permit forged source addresses, and rehearse the upstream filtering rule against a controlled generator inside your own scope.
Sources
Frequently asked questions
- What is the difference between reflection and amplification?
- Reflection is about who appears to be sending: the attacker forges your address, so innocent servers answer you rather than them. Amplification is about size: the answer is bigger than the question. An attack can reflect without amplifying, and the combination is what makes the technique dangerous — the attacker gets both anonymity and leverage.
- Which protocols carry the highest factors?
- Memcached is the extreme case, with a published range far above anything else, and CharGEN, QOTD, NTP and TFTP are all high. The full set of published factors, with the command each was measured against, is in the amplification dataset — and every one is a measurement under stated conditions rather than a constant.
- Why can we not just block the reflecting servers?
- Because they are innocent third parties, and there are a great many of them. Blocking them blocks whatever legitimate service they also provide, and the attacker simply moves to a different set. The countermeasure that actually works is ingress filtering, deployed by the networks the forged packets leave from.
- Does this affect us if we run one of the reflecting services?
- Yes, in a different direction. An exposed memcached, NTP or DNS resolver makes your infrastructure part of someone else's attack, consumes your bandwidth doing it, and can get your addresses onto blocklists. Auditing what of yours answers unsolicited UDP is cheap and rarely done.
Sources
- Alert TA14-017A: UDP-Based Amplification Attacks
CISA · 2014-01-17 · regulator · accessed 2026-08-15
Last revised 18 December 2019. The source of the amplification factors in the linked dataset.
- RFC 2827 (BCP 38) — Network Ingress Filtering
IETF · 2000-05 · standard · accessed 2026-08-15
- RFC 9210 — DNS Transport over TCP: Operational Requirements
IETF · 2022-03 · standard · accessed 2026-08-15
Published: August 2026 · Last reviewed: August 2026
Reviewed means the sources above were re-read on that date; the text is only reissued when something material changed.
This guide is updated as vendors release new models and pricing. How we compare vendors