pk.org: CS 419/Lecture Notes

Distributed Denial of Service (DDoS) Attacks

Reflection and Amplification

Paul Krzyzanowski – 2025-11-11

Part 1: Link Layer Attacks
Part 2: Network Layer Attacks
Part 3: Transport Layer Attacks.
Part 4: DNS Attacks
Part 5: DDoS Attacks

Introduction

Denial of Service (DoS) attacks are attempts to make a system or service unavailable by overwhelming it. The attacker’s goal is simple: prevent legitimate users from doing useful work.

There are two broad ways to do this:

Crashing a service via a single exploit is ideal from an attacker’s perspective, but modern systems are harder to bring down that way. In practice, most serious attacks rely on overloading.

Traditional DoS attacks come from a single source. Modern attacks are usually Distributed Denial of Service (DDoS): many systems around the world send traffic at the same time, coordinated through a botnet. The traffic may come from thousands of IP addresses across multiple ISPs and countries. This makes the attack more powerful and much harder to block.

The common theme is asymmetry. It is usually far cheaper for an attacker to send a request than for a server or network to process it.

How DDoS Attacks Exploit Asymmetry

Basic asymmetry

A simple web request that looks like “load this page” might result in complex actions at the server, such as:

The attacker spends only a few CPU cycles crafting the request, which may be just a few hundred bytes long. The server might spend milliseconds or more doing real work. Multiply that by thousands or millions of requests, and a modest attacker can overwhelm a much larger service.

Similar asymmetries appear at lower layers:

Attacks that intentionally exploit this imbalance are sometimes called asymmetric attacks.

Historical ICMP attacks

Some older DoS tricks are mostly fixed today but illustrate the idea of asymmetry — low effort on the part of the sender but a burden on the receiver:

IP spoofing

Many DDoS techniques rely on IP spoofing: forging the source IP address in packets.

Spoofing is easiest with UDP because there is no concept of a connection and no handshake. With TCP, spoofing makes it hard to establish connections, but with UDP, the attacker can send a packet with any source address; the receiver has no built-in way to verify the claimed source address.

Spoofing helps attackers:

Ideally, ISPs would block spoofed traffic at the edge of their networks. In practice, filters are unevenly deployed, so spoofing remains a major enabler of DDoS.

Reflection

Attackers do not simply want to send traffic; they want to send more traffic than the victim can possibly handle. The challenge is scale. A single machine, even with a fast network link, cannot generate enough traffic to overwhelm a large service or cloud provider.

This leads attackers to look for ways to multiply their impact. One approach is to make other servers on the internet send traffic to the victim on the attacker's behalf. These servers act as unwitting participants, turning a single attacker’s request into many incoming packets at the victim.

This technique is known as reflection.

A reflection attack uses innocent servers as mirrors.

The attacker sends requests to public services (DNS, NTP, CLDAP, etc.) but spoofs the victim’s IP address as the source. The server sends its response back to the spoofed address, which is actually the victim.

From the victim’s point of view:

From the attacker’s point of view:

Reflection is particularly useful when combined with amplification.

Amplification

Reflection solves the problem of hiding the attacker and distributing the attack traffic among many legitimate servers, but it does not solve the problem of scale. If each reflected response is roughly the same size as the attacker’s request, the attacker does not gain much leverage.

Attackers discovered that some public services respond with messages far larger than the queries sent to them. If the attacker can reflect these oversized responses toward the victim, each small request turns into a much larger flood.

This is the idea behind amplification.

Amplification occurs when a small request causes a large response.

For example, a short DNS query for all records in a zone can produce a much larger response. If the attacker sends the query with the victim’s IP address as the source, the victim receives a large response without ever sending a request.

The amplification factor is:

response size ÷ request size

A factor of 50x means the attacker’s outbound traffic is multiplied by 50 on the way to the victim. Some protocols have even higher factors.

Reflection and amplification together enable massive volumetric attacks (floods that overwhelm a target’s network bandwidth), often measured in terabits per second.

Application-layer attacks

Application-layer DDoS attacks target specific services or endpoints using seemingly legitimate requests:

These attacks are difficult because traffic often resembles normal usage patterns.

Application-layer loop DoS

A newer class of attacks creates persistent loops between two or more servers.

Research published in 2024 showed that some UDP-based services, including DNS, TFTP, and other protocols, can be triggered into an endless back-and-forth exchange:

The attacker sends a single packet and then disappears. The two services keep sending packets to each other, consuming bandwidth and CPU indefinitely.

Amplification Examples

Reflection and amplification remain core ingredients in large DDoS attacks.

Protocol Approx. Amplification Factor Notes
Memcached Up to ~51,200× Exposed cache servers; used in the 2018 GitHub attack.
NTP ~556× monlist command returns lists of prior clients.
DNS ~50–179× Large responses (e.g., ANY queries or DNSSEC-enabled zones).
CLDAP ~56–70× Windows AD protocol sometimes exposed on UDP.
DTLS ~37× TLS over UDP; misconfigured servers can amplify.

The pattern is the same for all of these:

  1. Send small, spoofed UDP packets to public servers.

  2. Servers reply with larger messages to the victim.

  3. The victim’s bandwidth and devices are overwhelmed.

Botnets

Reflection and amplification give attackers leverage, but truly large DDoS attacks still require more raw traffic than a single machine can generate, even with amplification.

To produce traffic at Internet scale, attackers recruit many devices to work together. These can be home computers, compromised servers, or -- most commonly today -- poorly secured IoT devices. Each device contributes only a small amount of traffic, but thousands or millions acting together can overwhelm even well-provisioned networks.

A network of compromised, remotely controlled devices is called a botnet.

Each infected device runs malware that connects to a command and control (C&C) infrastructure. When the attacker issues a command, all bots begin sending traffic to the target. This distributed architecture:

Mirai and its successors (including newer variants such as the Eleven11bot botnet) demonstrate how quickly IoT-based botnets can appear and grow when devices ship with default passwords or known vulnerabilities.

Botnets and C&C Infrastructure

We discussed the communication mechanisms of malware, including botnets, in more detail previously. Botnets depend on communication channels that allow the attacker to coordinate large numbers of infected devices. Common C&C methods include:

Botnets adapt continuously. If a portion of the network is taken down, the malware may switch to new domains or fallback servers. Devices that are cleaned can be reinfected if they remain vulnerable. IoT devices continue to be the easiest foothold because they are rarely patched and often deployed with weak or default credentials.

How We Measure DDoS Attacks

Once attackers combine reflection, amplification, and botnets, the resulting attacks can overwhelm targets in several different ways. Sometimes the limiting factor is total bandwidth. Other times it is the rate of packets or the number of application-layer requests.

Because there are several ways to overload a system, we need several different ways to measure DDoS attack size.

Volumetric attacks (bits per second)

Volumetric attacks attempt to saturate network links. They are measured in:

If a victim has a 10 Gbps upstream link and is hit with 50 Gbps of attack traffic, its link is saturated and legitimate traffic cannot get through.

Recent years have seen volumetric attacks ranging from several terabits per second to more than 10 Tbps, mostly through reflection, amplification, and IoT-driven botnets.

Packet-per-second (PPS) and request-per-second (RPS) attacks

Sometimes the bottleneck is not bandwidth but the number of packets or requests that systems can process:

Recent incidents have reported:

These attack rates exceed what most infrastructures can handle without specialized defenses.

Real-World Incidents and Trends

The scale of DDoS attacks has increased dramatically over the past decade. Early attacks operated in the tens or hundreds of megabits per second, enough to knock small sites offline but rarely a threat to major providers.

Today, attackers routinely generate traffic in the terabit range, and record-setting attacks occur every year.

The rise of large botnets, exposed UDP services, and cloud-hosted infrastructure has allowed even modestly resourced attackers to produce floods that challenge the defenses of global networks. The examples below show how quickly both the volume and complexity of DDoS attacks have evolved.

Year Type / Peak Notes
2018 1.7 Tbps Memcached attack on GitHub.
2020 2.3 Tbps CLDAP-based attack mitigated by AWS.
2022 3.47 Tbps Azure mitigated multi-terabit UDP flood.
2022 46M RPS Large Layer 7 HTTPS flood blocked by Google.
2023 398M RPS Rapid Reset HTTP/2 attack wave.
2024 5.6 Tbps, 666M PPS Hyper-volumetric IoT botnet attack.
2025 6.5 Tbps Eleven11bot attack from ~30,000 IoT devices.
2025 11.5 Tbps, 5.1B PPS Record-breaking UDP flood mitigated by Cloudflare.

Defenses Against DDoS

Defending against DDoS attacks is difficult because attackers can target different bottlenecks. Some attacks saturate bandwidth, some overwhelm routers with packet rates, and others exhaust CPU or memory inside applications. No single technique stops all attacks; effective defense requires multiple layers of protection.

Network-level defenses

Overprovisioning
Organizations often buy more bandwidth or processing capacity than they need. Extra capacity cannot stop a sustained attack, but it helps absorb short spikes and gives defenders more time to respond.

Rate limiting
Routers and firewalls can restrict how many packets or connections they accept from a given source within a certain time. This does not stop distributed attacks, but it slows down traffic from misbehaving endpoints and reduces the impact of small floods.

Traffic shaping
Network devices can prioritize certain types of traffic or slow down low-priority traffic. During an attack, shaping ensures that essential services (such as DNS or critical APIs) remain usable even when other traffic is under load.

Blackhole routing
If a particular IP address is under attack and cannot be kept online, a provider can temporarily “blackhole” it: route all traffic to that address into a discard path. This sacrifices availability for that service, but protects the rest of the network from collapsing.

Geo-IP filtering
Some attacks originate mainly from specific regions. Providers can block or throttle traffic from those areas when they have no legitimate users there. This is a crude but sometimes effective measure.

Anti-spoofing
Networks can enforce rules that block packets with forged source addresses. This prevents reflection attacks from originating inside the network and reduces the attacker’s ability to hide behind spoofed traffic.

Scrubbing centers
Large providers operate dedicated facilities that receive incoming traffic, filter out malicious packets, and forward only legitimate traffic to the customer. These centers use high-capacity links and specialized hardware to drop malformed packets, reflection traffic, and known attack patterns before they reach the target.

Application-level defenses

Web Application Firewalls (WAFs)
A WAF examines HTTP(S) requests and blocks suspicious or abusive patterns, such as repeated requests to expensive endpoints or known attack signatures.

CAPTCHAs and puzzles
When a service suspects automated traffic, it can require proof that the client is human. CAPTCHAs, proof-of-work puzzles, and email verification are common ways to separate real users from bots during an attack.

Per-user and per-IP throttling
Applications can track how often each user or IP requests resources. If a client exceeds normal behavior, the server slows them down or temporarily blocks them. This protects databases, search endpoints, and other expensive services.

Content Delivery Networks (CDNs)
CDNs cache content at many locations around the world. During an attack, traffic is absorbed by the CDN’s global infrastructure rather than reaching the origin server. CDNs can also detect and filter unusual request patterns across their network.

Graceful degradation
Applications can be designed to reduce functionality under heavy load. For example, a site might temporarily disable search, recommendations, or nonessential features so that basic pages remain usable. This prevents the entire service from collapsing during application-layer floods.

Participation controls

To avoid becoming part of an attack:

Example: Google Cloud Armor and Project Shield

Google operates one of the largest networks in the world, and its infrastructure absorbs DDoS attacks on a regular basis. Two services built on this infrastructure – Google Cloud Armor and Project Shield – illustrate how large providers defend against modern attacks.

Google Cloud Armor

Google Cloud Armor](https://cloud.google.com/security/products/armor) protects applications running on Google Cloud by enforcing security policies at Google’s edge routers rather than at the customer’s servers. Because most attack traffic never reaches the customer’s network, the impact of volumetric floods is greatly reduced.

Cloud Armor evaluates each incoming request using a combination of filtering, protocol validation, and rate limiting. Administrators can write rules that block or allow traffic based on IP ranges, headers, URL paths, or common attack patterns. Cloud Armor integrates with Google’s global load balancers, which means requests are inspected across hundreds of locations close to the users and far from the customer’s backend.

For large layer-3 or layer-4 attacks (such as UDP floods or SYN floods), Google automatically redirects traffic to its scrubbing centers. These facilities drop malformed packets and reflection traffic using high-speed stateless filters, then forward only clean packets to the customer. For application-layer attacks (layer 7), Cloud Armor uses behavioral analysis and machine learning to detect unusual request spikes and throttle or block them.

Cloud Armor also includes adaptive protection, which profiles normal traffic to a service and raises alerts when patterns deviate in ways that resemble an attack.

Project Shield

Project Shield uses the same core technology but is designed for at-risk organizations such as independent news outlets, human rights groups, and election monitors. The goal is to prevent DDoS attacks from silencing these sites.

Project Shield runs as a reverse proxy: administrators point their domain’s DNS records to Google, and Google receives all traffic on their behalf. Harmful traffic is filtered at Google’s edge, while legitimate traffic is forwarded to the real server. Because Google can cache static content, the customer’s server receives far less traffic during an attack.

Unlike Cloud Armor, Project Shield is free and available even to websites that are not hosted on Google Cloud.

Together, Cloud Armor and Project Shield show how large-scale DDoS protection depends on distributing traffic across global infrastructure, applying layered filtering, and detecting abnormal patterns early.

Summary

DDoS attacks exploit:

Effective defense requires:

DDoS remains one of the most difficult threats to mitigate because attackers constantly find new ways to generate enormous traffic volumes while blending in with legitimate users.

Next: Study Guide