A reflection attack is a way of attacking a network in which the attacker impersonates the victim. The attacker sends requests to ordinary, legitimate servers — known as reflectors — but in the “sender address” field writes the victim’s IP address instead of their own. The server replies as usual, except the reply goes not to the attacker but straight to the victim’s address. In this way an innocent server becomes an unwitting tool of the attack. In practice the technique is used almost exclusively to overwhelm a target with traffic, that is, for denial-of-service attacks. Its distributed form is called DRDoS (Distributed Reflection Denial of Service). For the attack to work, two conditions must be met: the attacker has to be able to forge the sender’s address (so-called IP spoofing, easiest over UDP, which does not check the sender) and there have to be public services that answer anyone who asks.

How does a reflection attack work?

The attack proceeds in several steps:

Selecting reflectors. The attacker collects a list of public servers that answer over UDP. These can be open DNS servers (which translate site names into addresses), NTP time servers, memcached instances, SSDP devices, or CLDAP services.
Impersonating the victim. Each reflector receives a request in which the victim’s address is written as the sender. UDP sets up no connection in advance, so the server never checks who really sent the packet.
Reflecting the traffic. The reflector treats the request as genuine and sends its reply — to the victim’s address. From the target’s point of view, the traffic looks as if it came from thousands of ordinary servers, not from the attacker.
Flooding the link. Replies from many reflectors at once (a botnet spreads out the requests) clog the victim’s link or its servers. The service stops working.

Along the way, the attacker hides their identity: the victim sees the reflectors’ addresses, while the real source stays invisible. This is what sets a reflection attack apart from plain flooding straight from a botnet, where the attacking machines’ addresses are visible.

How is reflection different from amplification?

These are two separate mechanisms, although they usually appear together:

Reflection is about the direction of traffic. Thanks to the forged sender address, the server’s reply goes to the victim. Reflection on its own does not increase the amount of data.
Amplification is about size. The attacker chooses requests that make the server reply with a packet far larger than the question itself. The ratio of reply size to request size is called the bandwidth amplification factor (BAF).

In practice, most DRDoS attacks combine both at once: the attacker sends a small spoofed request, and the reflector bounces a large reply at the victim. Reflection without amplification is possible but not very worthwhile. Amplification without reflection makes no sense — it is the reflection that delivers the large reply to the victim rather than to the attacker.

Which protocols do reflection attacks abuse?

The most commonly abused services are those running over UDP, because that protocol does not check who sent a request. Here are the typical vectors and their approximate amplification:

DNS (port 53/UDP) — ANY queries or requests for large records sent to open DNS servers; amplification of roughly tens of times.
NTP (port 123/UDP) — the monlist command returns a list of a time server’s recent clients; very high amplification, up to several hundred times.
memcached (port 11211/UDP) — a cache exposed to the internet without a password; extreme amplification, on the order of tens of thousands of times in record attacks.
SSDP (port 1900/UDP) — UPnP devices answering requests about services available on the network.
CLDAP (port 389/UDP) — a UDP variant of the LDAP directory protocol, a common amplification vector.
SNMP (port 161/UDP), Chargen (19/UDP), QOTD (17/UDP) and other legacy services.

Reflection can also be done over TCP (for example, abusing servers’ SYN/ACK packets as reflectors), but UDP still dominates because impersonation is easiest there.

Reflection attack versus the cryptographic reflection attack

The name “reflection attack” also has a second, narrower meaning — from the area of login and authentication. In a cryptographic reflection attack, the attacker abuses a question–answer (challenge–response) protocol. When both sides prove their identity with the same secret and the same method, the attacker sends the victim its own question back in a second, parallel session. The victim politely computes the correct answer, and the attacker uses it to log in as themselves. Defenses include making each side’s questions different from the other’s and attaching the participants’ identifiers to them. This is an entirely different mechanism from the DDoS attack described above — they share only a name and the general idea of “reflecting.” In the context of network monitoring and flooding attacks, “reflection attack” means the DRDoS variant.

How do you detect a reflection attack on the network?

From the point of view of security teams (SOC) and network monitoring (NDR), a reflection attack leaves characteristic traces in traffic-flow data (NetFlow/IPFIX/sFlow) and in the packets themselves:

Mismatched ports. A lot of inbound traffic from a source port typical of a reflector (53, 123, 11211, 1900, 389) aimed at a single target — even though no one on that network asked for anything beforehand.
Many senders, one target. Thousands of different addresses (reflectors) converging on a single victim address or a single pool of addresses.
A sudden spike in traffic. A sharp rise in bandwidth (bits per second) or in the number of packets, often with a large average packet size (this is the amplification effect).
Replies without questions. DNS or NTP replies for which there were no outbound requests — a classic sign of reflected traffic.
Your network as a reflector. Watching outbound traffic matters just as much. If your own open DNS or NTP server answers queries from around the world, it is a sign that someone is using your infrastructure to attack someone else.

Comparing flow data with a list of known amplification ports and with the normal level of traffic (the baseline) makes it possible to tell an attack apart from an ordinary spike and to work out whether the organization is the target or an unwitting reflector.

How do you reduce the risk of a reflection attack?

Effective defense works on two levels: in the source networks (so that impersonation is impossible) and at the target (so it can survive the flood):

Filtering traffic at the entrance (BCP38 / BCP84). Operators and organizations should drop, at the network edge, packets whose sender address does not belong to their own pool of addresses. This removes the core precondition of the attack — the ability to forge a sender address.
Closing and hardening reflectors. Restrict DNS servers to trusted clients, disable the monlist command in NTP, never expose memcached to the internet, and block unused UDP ports at the edge.
Limiting the rate of replies (RRL, Response Rate Limiting) on DNS servers, plus per-service query limits.
Defense at the operator or CDN. Filtering and “cleaning” the traffic (scrubbing) before it reaches the victim’s link. An attack larger than your own link cannot be fended off on your own.
Monitoring and baselining. Continuous analysis of flow data with alerts on unusual source ports and traffic spikes, which shortens detection and response time.

Learn more

HTTP Flood — An HTTP flood can be used as a reflection-based DDoS method to amplify traffic toward a victim.
Amplification Attack — Reflection attacks often rely on amplification to magnify spoofed requests into larger responses.
Scrubbing Center — A scrubbing center can filter reflected traffic and help mitigate reflection attacks.

Reflection Attack

A network attack in which requests carrying the victim's spoofed IP are sent to reflector servers so their replies flood the target — the basis of DRDoS attacks.