loader
critical risk OSI Layers 3–4 / UDP current

Reflection & Amplification

Forged requests cause third-party services to direct responses at a victim, frequently multiplying the attacker's bandwidth many times over.

Defender-oriented briefing. This page describes behavior, observable signals, prevention and response. Operational attack instructions are intentionally excluded.

How it works

The attacker sends requests to exposed connectionless services with the victim's address forged as the source. Those services reply to the victim. Because responses are larger than requests, the attacker delivers far more traffic than they send.

Two mechanisms, often confused

Reflection and amplification are distinct properties that usually appear together, and separating them clarifies which defence applies.

Reflection is the redirection. The attacker forges the victim's address as the source of a request, so an innocent third-party service sends its response to the victim rather than to the attacker. This conceals the origin and means the victim sees traffic from legitimate infrastructure rather than from the attacker.

Amplification is the multiplication. If a small request produces a large response, the attacker delivers more bandwidth to the victim than they spent sending it. The ratio between the two is the amplification factor, and it determines how much attack capacity a given attacker actually commands.

Reflection requires spoofing to be possible. Amplification requires a service that answers small questions with large answers. A service with both properties, reachable from the internet, is a weapon available to anyone who finds it.

Why amplification factors vary so widely

Published amplification factors range from low single digits to several orders of magnitude, and the spread is not arbitrary. It depends on how much state the service holds and how verbose its replies are.

A protocol that returns a fixed short acknowledgement offers little. One that returns a full directory listing, a large cached object, or an accumulated list of recent peers offers a great deal. The most severe cases are services that were designed for trusted local networks, where returning large amounts of data cheaply was a feature rather than a risk, and which were never intended to face the internet at all.

This is why the worst amplifiers are usually the most obviously misconfigured. The protocols were not designed to be abused; they were designed for an environment that no longer applies once the service is publicly reachable.

The protocols in practice

The specific service varies with what happens to be exposed at any given time, but the recurring set is stable.

  • DNS — open recursive resolvers answer queries for anyone. A short query can return a substantially larger response, and the sheer number of resolvers on the internet makes this durable. Prevent open recursion; serve recursion only to your own clients.
  • NTP — older implementations supported administrative queries that returned lists of recent clients, producing very large replies from tiny requests. Update the software and disable the legacy query features; there is no operational reason to expose them.
  • CLDAP — connectionless directory lookups that should never have been internet-facing. Directory services belong on internal networks behind policy, not on a public interface.
  • SSDP and UPnP — device discovery on consumer routers, cameras and media equipment. Exposure is usually accidental, caused by WAN-facing UPnP left enabled by default. Disable it at the gateway and keep firmware current.
  • Memcached — a caching service intended for trusted networks, historically shipping with UDP enabled and no authentication. It can return very large stored values from minimal requests, which produced some of the largest recorded attacks. Disable UDP where it is not needed and bind to private interfaces.
  • WS-Discovery, SLP and mDNS — service-discovery protocols that answer broadcast-style questions about what a network contains. Printers, cameras and appliances routinely expose them when placed on a public address. Keep discovery protocols inside trusted segments and filter them at the boundary.

Plain UDP floods, for contrast

Not all UDP attacks reflect. A plain UDP flood sends packets directly to the target, often to random or unused ports, relying on volume rather than multiplication.

The distinction matters diagnostically. A direct flood typically shows random destination ports and no coherent source protocol, and the target may waste effort generating ICMP port-unreachable replies for every packet. Reflected traffic shows the opposite: it is concentrated on one source port, arrives from servers that are running a real and identifiable service, and has response sizes clustered around a characteristic value. Reading the source port distribution usually settles which one you are looking at within a minute.

If you are the victim

Blocking the sources is neither possible nor appropriate. The traffic originates from thousands of legitimate servers whose operators are unaware of it, and the addresses are not the attacker's. Filtering them individually is endless and blocks infrastructure your users may need.

Filter by protocol characteristic instead. Reflected traffic is unusually uniform — one source port, a narrow size distribution, a single protocol. That signature is straightforward for an upstream provider to match, and it can be dropped at the network edge without touching the legitimate use of those services.

The filtering must happen upstream. Amplification exists to saturate circuits, so by the time traffic arrives at your equipment the damage is done. This is a call to the transit provider or scrubbing service, made with the protocol and port detail they need to act precisely.

If you are the reflector

You may be participating without any indication of compromise. Nothing on your systems is breached; a service is simply answering questions it should not be asked by strangers.

The signs are unusual outbound volume from a single service, inbound requests from addresses with no business relationship, and abuse reports from networks you have never contacted. That last one is often the first notice an operator receives.

Remediation is configuration rather than incident response. Determine which service is answering, restrict it to the clients that legitimately need it, and disable UDP transport where the service does not require it. If it must remain public, apply response-rate limiting so a single source cannot extract unlimited replies.

Eliminating the exposure

This is the rare attack category with a genuine structural fix, and it operates at two levels.

Source address validation at network edges removes the ability to forge the victim's address in the first place. Without spoofing there is no reflection, regardless of how many amplifiers exist. This is the durable solution, and its incomplete deployment is the reason the technique persists.

Reducing the amplifier population is the complementary half and is entirely within each operator's control. Every connectionless service removed from public reachability permanently reduces the capacity available to attackers. Scan your own address space from outside it, on a schedule — accidental exposure is usually the result of a default setting or a firewall change rather than a deliberate decision, which means it appears without anyone noticing.

Also known as

DRDoS amplification DDoS DNS amplification NTP amplification CLDAP amplification SSDP amplification memcached amplification WS-Discovery amplification SLP amplification mDNS amplification

What defenders may observe

  • Unsolicited replies arrive from many legitimate servers
  • Inbound response traffic has no matching outbound requests
  • One or two UDP source ports dominate the traffic mix
  • Sources are diverse in ownership but identical in protocol
  • Response sizes cluster tightly around a characteristic value

Prevention and mitigation

  • Deploy source address validation so forged requests cannot leave your network (BCP 38)
  • Disable or restrict connectionless services reachable from the internet
  • Bind cache, directory and discovery services to private interfaces only
  • Apply response-rate limiting on services that must remain public
  • Arrange protocol-aware upstream filtering by abused source port

Initial response priorities

  • Shift mitigation upstream before the circuit saturates.
  • Compare packet rates, flags and source distribution with the baseline.
  • Rate-limit or filter the affected service without blocking known-good traffic.

Use your approved incident-response plan and adapt decisions to your environment. This is educational guidance, not a substitute for live incident leadership.

Authoritative references