In late April 2007, the Estonian government moved a Soviet-era war memorial from central Tallinn. Within days, the websites of the Estonian parliament, ministries, banks, newspapers, and broadcasters were unreachable. They stayed that way on and off for three weeks. The traffic came from botnets worldwide. Nothing was stolen, and nothing was altered. The sites were buried under more requests than they could handle. A country that had moved most of its government services online found that availability was the property it could least afford to lose.

A denial-of-service (DoS) attack makes a system unavailable to the people who are supposed to use it. A distributed denial-of-service (DDoS) attack is one whose traffic comes from many sources at once, whether compromised machines under the attacker’s control or ordinary servers tricked into sending it.

We begin with why these attacks are possible: an imbalance between the work it takes to send a request and the work it takes to handle. Reflection and amplification follow, the techniques that let an attacker send far more traffic than the attacker’s own connection could produce, and then the botnets that supply the rest. We then look at attacks on applications rather than networks, at how attacks are measured, and at the defenses, none of which is enough alone.

Two Ways to Deny Service

An attacker can make a service unavailable in two ways:

1. Exploit a flaw that crashes the software or the machine. A single malformed packet did this to many systems in the 1990s. The ping of death, discovered in 1996, sent IP fragments that reassembled into a packet larger than the 65,535 bytes the protocol allows, and the overflow crashed the operating systems of the day.

2. Overload the service, its network link, or something it depends on, with more work than it can do.

The first is ideal from the attacker’s view, since sending one packet takes nothing, but once found, each such flaw is fixed. Most large attacks use the second method, which does not depend on a flaw. The two are not independent, though. A flaw in how a service limits its work can make overloading it far cheaper, and two of the attacks later in this part are of that kind.

Asymmetry

The arithmetic favors the attacker because handling a request is usually more work than making it. A web request of a few hundred bytes can make the server run database queries, read files, assemble a page, and write log entries. The attacker spends microseconds producing the request; the server spends milliseconds responding to it. The same imbalance appears at every layer. As Part 2 described, a SYN segment takes the sender one packet and takes the server memory and a timer. A request to a search endpoint makes the application scan its index. The attacker’s goal is to find the request with the highest receiver-effort-to-sender-effort ratio and send it as often as possible.

An attacker can attack an expensive operation with little bandwidth. Saturating a large service’s network link is harder, since one machine has one connection and a large service has far more capacity. The next two sections are about where an attacker gets traffic on that scale.

Reflection and Amplification

Some floods come from the attacker’s own machines and don’t need forgery. Reflection and amplification depend on IP spoofing: writing a victim’s address as the source of a request so that the reply goes to the victim. They succeed wherever the attacker’s network forwards spoofed packets, which, as Part 2 described, many still do.

Reflection Attacks

A reflection attack makes ordinary public servers send their replies to the victim, so that the traffic the victim sees comes from legitimate servers rather than from the attacker.

The attacker needs a network that forwards spoofed packets and public servers that reply to unauthenticated requests. The attacker sends requests to those servers with the victim’s address as the source. The servers send their replies to the victim. The reflectors need not be compromised; they are doing what they were built to do.

From the victim’s side, traffic arrives from hundreds of servers worldwide, and the attacker’s machines never receive anything. Reflection hides the attacker from the victim’s immediate view and complicates attribution, but it doesn’t make the attack untraceable, since reflectors and their providers can see where the requests came from. By itself, it also adds nothing to the volume: a reply the same size as its request delivers the same number of bytes the attacker sent.

The earliest widely used form of this attack dates from 1997. An attacker sent a ping request to a network’s broadcast address with the victim’s source address. Every host on that network replied to the victim. It was called a smurf attack, after the program that automated it. In 1999, it was stopped by changing the default router configuration so that routers do not forward packets addressed to a broadcast address from outside the network.

Amplification Attacks

An amplification attack chooses a reflector whose reply is much larger than the request, so that each small packet the attacker sends becomes a large one arriving at the victim.

The amplification factor is the size of the reply divided by the size of the request. Suppose a request of 60 bytes produces a reply of 3,000 bytes. The factor is 50. An attacker with an ordinary home connection sending 20 megabits per second of such requests delivers about 1 gigabit per second to the victim, fifty times what the attacker’s own connection could send. A thousand such machines deliver a terabit per second. The factor depends on the protocol, request, server’s configuration and software version, and how bytes are counted. Published figures are examples from particular attacks rather than constants.

Two protocols illustrate the range. A DNS query is small. A reply can be many times larger if the attacker asks for a name with many records or for a signed zone’s records with their signatures. Factors of several dozen have been common, though modern servers can respond to the largest queries with a minimal reply.

The extreme case was memcached, a memory-based object cache that web applications run inside their data centers. It was never meant to be reachable from the Internet, so it did not authenticate requests, but tens of thousands of installations were exposed anyway.

An attacker could store a large object, hundreds of kilobytes of data under a short key, in one of them and then send a 15-byte request for that key with a victim’s address. The server would send the value to the victim, split across many packets. Cloudflare measured a 15-byte request producing about 750 kilobytes of response, a factor of about 51,000.

On February 28, 2018, this technique produced 1.35 terabits per second of traffic against GitHub, the largest attack recorded at the time. The site was unavailable for about five minutes. Within weeks, network operators had blocked the memcached port at their borders, and the attack rate collapsed.

Three things must be true for an amplification attack to work, and each is a point of defense:

1. The attacker’s network must forward spoofed packets, which ingress filtering prevents.

2. The reflecting service must be reachable from the Internet, which firewalls prevent.

3. The service must also send a large reply to a small request, which rate limiting and protocol changes reduce.

Botnets

A botnet is a group of compromised devices that an attacker controls. Those devices can flood a victim directly or send forged requests to reflectors.

The devices in a botnet run malware that connects to the attacker’s command-and-control infrastructure and sends traffic to whatever target the attacker names. Botnets range from a few hundred machines to over a million. What counts for denial of service depends on the number of devices and each one’s bandwidth. Since about 2016, the largest ones have been built from devices that stay on, rarely update, and connect to fast home links: routers, cameras, digital video recorders, and, most recently, television set-top boxes. Traffic sent directly comes from real connections on real devices, so nothing in it is forged, which makes it hard to filter.

Mirai is an example. In September and October 2016, it assembled several hundred thousand such devices by logging into them with default passwords. On October 21, 2016, it targeted Dyn, a company that ran authoritative DNS servers for many major websites (it still does, and serves pk.org, but has since been acquired by Oracle). For users on the east coast of the United States, Twitter, Reddit, Netflix, Spotify, GitHub, and dozens of other sites became unreachable. They were not attacked. Their names could not be resolved.

The scale has grown since.

On October 24, 2025, Microsoft absorbed a 15.7 terabits-per-second attack from a botnet of about 500,000 addresses, mostly home routers and consumer devices, and reported it the following month.

Cloudflare’s report for the last quarter of 2025, published in February 2026, described an attack from the same botnet that peaked at 31.4 terabits per second and lasted 35 seconds.

Botnets are also rented. Booter or stresser services, advertised as tools for testing one’s own servers, sell attacks by the hour against any target the customer names. In December 2022, the FBI and its partners seized 48 of these services in a single operation, and others replaced them.

Attacks on Applications

An application-layer attack exhausts the server’s processing rather than its network link, using requests that are individually valid and hard to tell from real users.

Volumetric attacks exhaust bandwidth. These attacks exhaust the application. The requests are valid HTTP requests that arrive faster than the application can sustain. They are hard to filter because each one looks like a user. The most effective ones target expensive endpoints: search, reports, pages assembled from several database queries, or, increasingly, endpoints that call a language model.

A flaw in how a server limits work makes such an attack far cheaper. HTTP/2, the version of the web protocol that most browsers now use, lets a client send many requests on one connection as separate streams. It limits how many streams can be open at once. In August 2023, attackers found that canceling a stream freed its slot immediately, before the server finished starting the request.

In the Rapid Reset attack, a client sends a request and cancels it, over and over, as fast as the connection allows. The stream limit never applies, and the server keeps paying the startup overhead of each request. A stream reset cancels one request inside an open connection; it is not the TCP reset of Part 2, which terminates the connection. Google measured a peak of 398 million requests per second, more than seven times anything it had seen before. Amazon and Cloudflare saw similar attacks in the same weeks. The fix was a change to how servers count and limit cancellations. It had to be applied to every HTTP/2 implementation.

Measuring an Attack

An attack is measured by whatever it exhausts, so three units are in use:

• Bits per second measures bandwidth. A target with a 10 gigabit per second link is unreachable if it receives 50 gigabits per second of attack traffic, whatever its servers can do. Large attacks are measured in terabits per second.

• Packets per second measures the load on routers, firewalls, and load balancers, which have to make a forwarding decision for every packet regardless of size. A flood of tiny packets can exhaust a router that could have passed the same number of bytes in large packets. The largest attacks of 2025 exceeded 10 billion packets per second.

• Requests per second measures the load on an application. The Rapid Reset attacks reached several hundred million requests per second.

For scale, the 2007 attack on Estonia was measured in tens of megabits per second. The largest attack reported for 2025 was 31.4 terabits per second, several hundred thousand times more.

Defenses

Every defense against denial of service either absorbs the traffic, filters it, or reduces the work each request causes. A large service uses all three, because an attacker will exploit any unprotected bottleneck.

Where Filtering Has to Happen

One rule governs every network-level defense: filter before the bottleneck. If an organization’s 10 gigabit per second link is receiving 50 gigabits per second, a firewall on the organization’s side of the link can discard the attack traffic. It won’t make a difference. The link is already full, so legitimate packets compete with attack traffic and are dropped or delayed upstream.

Filtering after the congested link cannot recover its capacity. The traffic has to be removed upstream, at the provider or at a facility with far more capacity than the target. That is why the defenses below are mostly services that a provider offers, and why a target under attack has to coordinate with its provider rather than act alone.

In the Network

Overprovisioning, buying more bandwidth and capacity than normal operation needs, absorbs short attacks and buys time. It cannot keep up with a sustained attack from a large botnet, whose capacity grows with the number of devices the attacker can compromise.

Anycast announces the same address from many data centers at once, so that routing delivers each packet to whichever site the routing system selects, usually a nearby one. An attack from devices spread worldwide is then divided among dozens of sites instead of landing on one, though not evenly. Root DNS servers have used anycast for two decades. It is the main reason large content delivery networks can absorb attacks that would overwhelm any single site.

Scrubbing centers are facilities with very large network links that receive a customer’s traffic during an attack, discard the malformed packets, spoofed replies, and known attack signatures, and forward the remainder to the customer. An attacked customer redirects its traffic to the scrubbing center by changing its routing announcements, so the filtering happens before the customer’s own link. The centers are expensive to build, so large providers run them and sell them as a service.

Blackhole routing gives up on one address to save the rest. If an attack on a single address threatens the entire network, the operator asks its provider to discard all traffic for that address before it reaches the operator’s link. The service at that address becomes unreachable, which is the attacker’s goal, but the link stays up for everyone else. It is a last-resort response.

Rate limiting caps the packets, connections, or requests accepted per source, per destination, or per operation. Per-source limits stop a single misbehaving endpoint but do little against a botnet, where each source sends a small share. Limits on a destination or on an expensive operation protect the resource regardless of how many sources are involved.

Ingress filtering, described in Part 2, is the defense that stops reflection and amplification at the source. It benefits other networks rather than the one that deploys it.

In the Application

A reverse proxy or content delivery network (CDN) sits in front of the origin server, the customer’s own server, serves cached content itself, and forwards only the rest. During an attack, the proxy’s infrastructure absorbs the flood and the origin server sees a fraction of it, provided the origin accepts traffic only from the proxy. An origin that is still reachable at its own address can be attacked directly. Cloudflare and Akamai sell this. Google’s Project Shield provides it free to news organizations, election monitors, and human rights groups that attackers target to silence them rather than for profit.

A web application firewall inspects HTTP requests and blocks those that match attack signatures, that arrive from one source too quickly, or that target an endpoint the operator has marked as expensive.

When a service cannot tell bots from people, it asks. A CAPTCHA or a proof-of-work puzzle forces each client to do something, solve a visual challenge or spend a fraction of a second of computation, before the server does anything expensive. The purpose is to raise the attacker’s work per request. It is a partial defense. A botnet spreads the work across its members, automated solvers exist for most challenges, and every legitimate user pays the same price.

Graceful degradation keeps the essential part of a service running when the rest cannot. A site under attack can disable search, recommendations, and personalization and serve plain cached pages, so the application survives a load its full feature set couldn’t handle.

Not Becoming Part of a Botnet

The last set of defenses protects the organization and everyone else. An organization keeps its devices from joining a botnet by patching them, changing default credentials, and keeping management interfaces off the Internet. That also keeps those devices from being compromised for any other purpose.

It keeps its servers from becoming reflectors by not exposing UDP services it does not need and by rate-limiting the replies of those it does. And it keeps its network from becoming a launch point by filtering spoofed packets at its border. The second and third mostly benefit other networks, which is why they remain incompletely deployed and why attacks are so large.

Conclusion

Network attacks exploit unauthenticated claims, unsafe configurations, software flaws, or limited resources. ARP and DHCP accept claims from anyone on the local network. BGP accepts an announcement from any neighbor that is not filtering. A resolver accepts a reply that matches the fields it can see. A TCP receiver accepts a segment whose numbers fall in its window. Each was adequate for the network the protocol was designed for, but became a vulnerability as the network grew.

We couldn’t replace the protocols, so we added verification around them. Switches check ARP against DHCP records. Routers check BGP announcements against signed authorizations. Resolvers check DNS records against signatures. Endpoints check connections with TLS. In every case, protection is only as complete as its deployment. Some of the most useful defenses, such as ingress filtering, protect everyone except the operator who has to deploy them.

Authentication does not prevent denial of service because attackers often send real traffic from real devices. Authentication helps against forged requests, but it cannot stop resource exhaustion on its own. Defenses include capacity, distribution, filtering before the bottleneck, and cooperation from the networks the traffic passes through.

Analyzing an attack on the network, we ask:

1. What access does the attacker need: the local network, an on-path position, routing access, or only the ability to send packets?

2. Which check does it bypass: an unauthenticated claim, a missing authorization, an unsafe default, or a resource limit?

3. What does the attacker gain: redirection, plaintext, impersonation, injection, or unavailability?

4. Which defense verifies the claim that was exploited, and was it deployed where it needed to be?

5. What remains exposed when the defense is in place, and does the remaining protection depend on the user?

Lecture 10: Part 1 | Part 2 | Part 3 | Part 4
Lecture 10 Study Guide | List of terms