DDoS Amplification and Reflection Attacks Explained

Some of the largest denial-of-service floods on record were launched by people who never had much bandwidth of their own. They borrowed it. A DDoS amplification attack is a trick that lets a small push produce an enormous flood, by bouncing traffic off other machines on the internet and aiming all of the replies at a single target. This article explains, in plain terms, how reflection and amplification attacks work, why they grow so large, what they do to a server, and how protection against them actually holds up. You do not need a networking background to follow along.

A small forged request can trigger a much larger reply, and thousands of them arrive at the victim at once.

How a small request becomes a large flood

Normally, talking to a server on the internet is a simple exchange. Your computer sends a request, the server sends a reply, and the reply comes back to you because your request carried your address. An amplification attack quietly breaks two assumptions in that exchange.

The first trick is reflection. The attacker forges the return address on its requests. Picture someone mailing thousands of letters to busy companies, but writing your home address in the sender field. Every reply lands in your mailbox, even though you never wrote to anyone. On a network, the "return address" is the source IP address, the label that says where a packet came from, and faking it is called spoofing. When the attacker spoofs your address onto its requests, the servers that answer send their replies to you instead of to the attacker. The traffic bounces off a third party before it reaches the victim, which is why this is called a reflection attack.

The second trick is amplification. The attacker deliberately picks requests where the answer is much bigger than the question. A short request triggers a long reply, so the victim receives far more data than the attacker ever sent. The size of the reply compared with the size of the request is called the amplification factor.

Put together, the method is simple and effective. The attacker sends small, forged requests to many well-connected public servers, and each of those servers, believing the request is genuine, fires a much larger reply at the victim. The servers doing the reflecting are usually ordinary internet services that were left open to the public by mistake, not machines the attacker controls. The United States cybersecurity agency describes the mechanism and the services most often abused in CISA's advisory on UDP-based amplification attacks.

Why the floods get so large

The danger is in the multiplier. If a request of a few dozen bytes produces a reply of a few thousand bytes, a single exchange has multiplied the attacker's traffic many times over. Now run thousands of those exchanges at once, across thousands of reflecting servers, and a person with an unremarkable internet connection can direct a flood many times larger than anything they could generate directly. This is how attacks reach hundreds of gigabits per second, a gigabit being a billion bits of data arriving each second.

There is a second reason these attacks are hard to trace. Because the flood arrives from thousands of real, innocent servers rather than from the attacker, the victim sees a storm of traffic from legitimate-looking sources. The machine that started it all stays hidden behind the reflectors.

What an amplification attack does to your service

An amplification attack is a volumetric attack, which means its goal is to fill your internet connection rather than to trip up your software. Think of your connection as a pipe with a fixed width. It does not matter how well your server is configured if the pipe feeding it is already full of junk. Once the link is saturated, real visitors cannot squeeze through, and your own firewall never gets a chance to help, because the congestion is happening upstream, out on the wider internet, before the traffic reaches anything you control.

When the flood fills the connection, legitimate visitors cannot get through.

When the pipe fills, everything behind it goes down together: a website stops loading, a game server starts dropping players, an API stops answering, and any other services sharing that same connection suffer at the same time. For a hosting company, one customer being targeted can take neighbors offline as collateral damage.

Why you cannot stop it on your own server

The instinct is to block the attacking addresses, but that plan falls apart against reflection. The flood is arriving from thousands of ordinary servers that did nothing wrong, and many of them are services your real users might legitimately need to reach. Blocking them is a losing game of whack-a-mole, and the list changes constantly.

Even if you could write a perfect set of rules, they would run too late. By the time the flood reaches your server, or even your connection, the damage is already done, because the pipe filled up before your rules ever saw a packet. The only place to stop a volumetric flood is earlier along its path, inside a network with far more capacity than your own link.

How protection against amplification attacks works

Effective protection moves the fight upstream. Instead of traffic flowing straight to you, it first passes through a network built to absorb large floods, where the junk is filtered out and only clean traffic continues on to your server. Because that network has enormous capacity, a flood that would instantly overwhelm a single connection is soaked up long before it reaches you. This is the model behind Sterile Networks' network and ASN protection, where volumetric and protocol floods are absorbed upstream and clean traffic is handed back to you.

Filtering the flood upstream keeps it away from your connection and your server.

Amplification floods have a useful weakness that good filtering exploits. The traffic is unsolicited: your services never asked those reflecting servers for anything, so a filtering layer can recognize replies that do not belong to any real conversation your service started and drop them. A common approach is to do this filtering continuously rather than switching it on after an attack begins, since a flood can fill a link in seconds and any delay is time your service spends offline. Sterile's always-on Layer 4 protection for applications is built around this idea, filtering patterns such as reflection and amplification, UDP floods, and SYN floods at the edge of its network before they reach your origin.

Choosing protection that covers amplification

Amplification is one kind of volumetric flood, a single branch of the broader main types of DDoS attacks, and real incidents often mix several at once. When you compare protection options, a few questions cut to what matters. The first is whether the service can absorb large volumetric floods, measured in gigabits per second, upstream of your own connection. The second is whether the filtering is always on, or whether it only switches on after an attack is already noticed. The third is whether it protects the specific thing you run, whether that is a single server, an application, or an entire network with its own address space.

A provider that only filters traffic once it reaches your server is solving the wrong half of the problem, because an amplification flood does its damage on the connection itself. If you are weighing your options, you can review the available protection plans or contact the Sterile Networks team to talk through what you need to keep online.

Stay online. Stay Sterile.