How DDoS Attacks Work

A Distributed Denial of Service (DDoS) attack overwhelms a target — a website, a DNS server, a network — with so much traffic that legitimate users cannot reach it. Unlike a simple denial-of-service attack from a single source, a DDoS attack is distributed: traffic arrives from hundreds, thousands, or even millions of compromised devices simultaneously. The target's bandwidth, CPU, memory, or application logic becomes saturated, and the service falls over.

DDoS attacks are one of the oldest and most persistent threats on the internet. They exploit a fundamental asymmetry: it is cheap to send traffic and expensive to receive it. An attacker with a botnet of 100,000 compromised IoT devices, each sending 1 Mbps, can generate 100 Gbps of attack traffic — enough to saturate all but the largest networks. Understanding how these attacks work at the network layer is essential for anyone operating internet infrastructure, and many of the defenses involve BGP, anycast, and the routing architecture of the internet itself.

The Three Categories of DDoS Attacks

DDoS attacks are generally classified into three categories based on which layer of the network stack they target. Each category exploits different weaknesses and requires different mitigation strategies.

Volumetric Attacks: Flooding the Pipe

Volumetric attacks are the blunt instruments of DDoS. Their goal is simple: send more traffic than the target's network links can carry. If a server has a 10 Gbps uplink and the attacker sends 50 Gbps, the link is saturated and legitimate traffic is dropped before it even reaches the server's network stack. These attacks are measured in bits per second (bps) and have reached multi-terabit scales.

UDP Floods

The simplest volumetric attack is a UDP flood. The attacker sends a massive volume of UDP packets to random ports on the target. Because UDP is connectionless — there is no handshake, no session state — the attacker can spoof source IP addresses freely. The target's server wastes resources checking for applications listening on each port, sending ICMP "destination unreachable" responses, and processing packets that should never have arrived.

UDP floods are easy to generate but relatively easy to filter because the traffic patterns are often distinguishable from legitimate traffic. The real danger comes from amplification attacks, which use UDP's connectionless nature to multiply the attacker's bandwidth.

DNS Amplification

DNS amplification exploits open DNS resolvers to multiply attack traffic. The attacker sends small DNS queries (typically 40-60 bytes) with the source IP spoofed to be the victim's address. The DNS resolver processes the query and sends its response — which can be 2,000-4,000 bytes for queries requesting DNSSEC-signed records or ANY queries — to the victim. The amplification factor is typically 28-54x: a 1 Gbps attack stream from the attacker becomes 28-54 Gbps hitting the victim.

The attack works because DNS uses UDP, which does not verify source addresses. The DNS resolver has no way to know the query was spoofed — it dutifully processes the request and sends the response to what it believes is the requester. The attacker typically uses thousands of open resolvers simultaneously, making the attack traffic appear to come from legitimate DNS servers rather than from a botnet. This makes filtering difficult because blocking the "sources" means blocking legitimate DNS infrastructure.

The 2013 Spamhaus attack used DNS amplification to generate approximately 300 Gbps of traffic — a record at the time. The attackers exploited tens of thousands of misconfigured open DNS resolvers worldwide.

NTP Amplification

NTP (Network Time Protocol) amplification abuses the monlist command on older NTP servers. The monlist command returns the list of the last 600 hosts that communicated with the NTP server. A single 234-byte request can generate a response of up to 100 packets totaling roughly 48,000 bytes — an amplification factor of approximately 556x. This makes NTP one of the most potent amplification vectors ever discovered.

In February 2014, an NTP amplification attack against the French hosting company OVH reached 400 Gbps. Within weeks, a separate attack set a new record at the time. The NTP amplification vector was eventually reduced as server operators patched or disabled the monlist command, but vulnerable servers persisted in the wild for years.

Memcached Reflection

In 2018, attackers discovered that memcached servers exposed to the internet over UDP port 11211 could be exploited for reflection attacks with an amplification factor exceeding 50,000x. A 15-byte request could generate a response of nearly 750 KB. This is the most extreme amplification factor ever observed in practice.

The February 2018 GitHub attack used this technique to generate 1.35 Tbps of attack traffic — at the time, the largest DDoS attack ever recorded. The attack peaked in under 10 minutes. GitHub was using Akamai Prolexic's DDoS mitigation service and recovered within roughly 20 minutes, but the sheer volume was unprecedented. Days later, an even larger 1.7 Tbps memcached attack was recorded by NETSCOUT Arbor.

The memcached amplification vector was devastating but short-lived. Service providers rapidly blocked UDP port 11211 at the network level, and memcached developers released patches that disabled UDP by default. But the incident demonstrated how a single overlooked protocol could become a weapon capable of record-breaking attacks.

Protocol Attacks: Exhausting State Tables

Protocol attacks exploit weaknesses in network protocols themselves — particularly the stateful nature of TCP. Instead of trying to saturate bandwidth, they exhaust the connection-tracking capacity of firewalls, load balancers, and servers. These attacks are measured in packets per second (pps) rather than bits per second.

SYN Floods

The SYN flood is the classic protocol-level DDoS attack, and understanding it requires understanding the TCP three-way handshake. When a client initiates a TCP connection, it sends a SYN packet. The server responds with a SYN-ACK and allocates memory to track the half-open connection in a data structure called the backlog queue. The server then waits for the client's ACK to complete the handshake.

In a SYN flood, the attacker sends millions of SYN packets per second with spoofed source IPs. The server allocates memory for each half-open connection and sends SYN-ACKs to addresses that will never respond. The backlog queue fills up, and the server can no longer accept new legitimate connections. Meanwhile, the attacker spends negligible resources — sending SYN packets is cheap because there is no handshake to maintain.

Modern defenses against SYN floods include SYN cookies, where the server encodes connection state in the SYN-ACK's sequence number and does not allocate memory until the final ACK is received. This effectively makes the server stateless during the handshake, neutralizing the attack. Most modern operating systems enable SYN cookies automatically under load.

Ping of Death

The Ping of Death is a historical attack that exploited a vulnerability in early IP implementations. The IPv4 specification limits packets to 65,535 bytes, but the attacker sends a fragmented ICMP ping packet that, when reassembled, exceeds this maximum size. Buggy network stacks would crash or reboot when attempting to handle the oversized packet.

The Ping of Death was devastating in the mid-1990s because virtually every operating system was vulnerable, and the attack required sending just a single packet. Patches were rapidly deployed, and modern operating systems are immune to this specific attack. However, the concept lives on in various fragmentation-based attacks that exploit edge cases in packet reassembly.

Smurf Attacks

The Smurf attack was one of the most feared DDoS techniques of the late 1990s and early 2000s. The attacker sends ICMP echo requests (pings) to a network's broadcast address with the source IP spoofed to be the victim's address. Every host on the broadcast network responds to the victim simultaneously, amplifying the traffic by the number of hosts on the network.

A broadcast network with 200 active hosts produces a 200x amplification factor. The attacker could chain multiple "Smurf amplifier" networks together for even greater effect. The attack was mitigated by configuring routers to not forward directed broadcast traffic (RFC 2644) and has been effectively dead since the early 2000s. However, it remains historically significant as one of the first amplification attacks.

Application Layer Attacks: Death by a Thousand Requests

Application layer (Layer 7) attacks are the most sophisticated category. Instead of overwhelming network capacity, they target the application itself — web servers, databases, APIs. These attacks are especially dangerous because each request looks like legitimate traffic. A volumetric attack sending 500 Gbps of random UDP is obviously malicious; an HTTP flood sending 50,000 requests per second to a login page is much harder to distinguish from a flash crowd of real users.

HTTP Floods

An HTTP flood sends a high volume of seemingly legitimate HTTP requests to a target web server. The attacker typically uses a botnet where each bot maintains a full TCP connection and sends well-formed HTTP requests. Because the requests complete the TCP handshake and present valid HTTP headers, they pass through most network-layer DDoS protections.

The requests are crafted to be expensive for the server to process. Attackers target pages that trigger database queries, search functions, or server-side rendering. A request to /search?q=a%20very%20long%20complex%20query might take 500ms of server CPU time, while the attacker's bot generates it in microseconds. With thousands of bots making such requests simultaneously, the server's CPU or database connection pool is exhausted.

HTTP floods come in two flavors: GET floods, which request pages or resources, and POST floods, which submit form data. POST floods can be more destructive because POST requests typically trigger write operations, database inserts, or complex processing that is more expensive than serving a cached page.

Slowloris

Slowloris takes the opposite approach from an HTTP flood. Instead of sending many complete requests quickly, it sends requests as slowly as possible. The attacker opens many HTTP connections to the target and sends partial HTTP headers, adding one header line every few seconds — just enough to keep the connection alive without completing the request.

The target server keeps each connection open, waiting for the request to finish. Apache's default configuration, for example, allocates a worker thread per connection. Once all worker threads are occupied with Slowloris connections, the server cannot accept new connections from legitimate users. The attacker needs minimal bandwidth — a single machine on a dial-up connection could theoretically take down an Apache server.

Slowloris is effective against servers that allocate per-connection resources (like Apache's prefork and worker MPMs) but less effective against event-driven servers like nginx, which handle thousands of connections with a small number of threads. Modern mitigations include connection timeouts, minimum data rate requirements, and reverse proxies that buffer incomplete requests.

RUDY (R-U-Dead-Yet)

RUDY targets web application form submissions by sending HTTP POST requests with a valid Content-Length header declaring a large body, then transmitting the body one byte at a time at very slow intervals. The server allocates resources to receive the complete POST body and waits patiently, tying up a connection slot for each slow POST.

Like Slowloris, RUDY exploits the server's willingness to wait for slow clients. The attack is particularly effective against applications with file upload endpoints or form handlers that expect large POST bodies. A single attacker can exhaust server resources with very little bandwidth.

Botnets: The Attack Infrastructure

Most large-scale DDoS attacks rely on botnets — networks of compromised devices under the attacker's control. A botnet provides the distributed firepower needed to overwhelm targets that could easily handle traffic from a single source.

Traditional Botnets

Early botnets consisted of compromised Windows PCs controlled via IRC (Internet Relay Chat) channels. The attacker would spread malware through email attachments, drive-by downloads, or exploit kits, and each infected machine would join an IRC channel waiting for commands. When the attacker issued the attack command, all bots would simultaneously flood the target.

Traditional botnets typically ranged from a few thousand to a few hundred thousand machines. The botnet's command-and-control (C2) infrastructure was a single point of failure — if defenders identified and shut down the IRC server, the entire botnet became inoperable. Later botnets evolved to use peer-to-peer C2, domain generation algorithms (DGAs), and encrypted communication to resist takedown.

Mirai and the IoT Revolution

In September 2016, the Mirai botnet fundamentally changed the DDoS landscape. Mirai targeted Internet of Things (IoT) devices — IP cameras, DVRs, home routers — by scanning the internet for devices with default or weak credentials. It tried a built-in dictionary of 62 common username/password combinations like admin:admin, root:root, and root:123456.

The Mirai botnet grew to an estimated 600,000 compromised IoT devices. On September 20, 2016, it was used to attack the website of security journalist Brian Krebs with approximately 620 Gbps of traffic — so much that Akamai, which had provided Krebs with pro bono DDoS protection, was forced to withdraw its protection due to the cost of absorbing the attack.

Weeks later, on October 21, 2016, Mirai was used in the attack on Dyn, a major DNS provider. By taking Dyn's DNS infrastructure offline, the attack caused cascading failures across the internet. Sites including Twitter, Reddit, GitHub, Netflix, Airbnb, and dozens of others became unreachable — not because their servers were down, but because the DNS servers that translated their domain names to IP addresses were overwhelmed.

The Mirai source code was publicly released in late September 2016, spawning dozens of variant botnets. Successors like Bashlite, Hajime, and Mozi continued to target IoT devices, and the fundamental problem — millions of IoT devices with hardcoded or default credentials, running outdated firmware, permanently connected to high-bandwidth links — remains largely unsolved.

DDoS-for-Hire: Attack as a Service

DDoS attacks are no longer the exclusive domain of skilled hackers. DDoS-for-hire services (also called "booters" or "stressers") allow anyone with a credit card or cryptocurrency to launch attacks. These services advertise openly, often disguising themselves as "network stress testing tools" while offering attack capabilities against any target.

A typical booter service charges $20-50 per month for access to attack infrastructure capable of generating 10-100 Gbps. Some premium services claim multi-terabit capacity. The services use a combination of rented servers, compromised machines, and amplification techniques to generate attack traffic. Customers choose the target IP, attack vector (UDP flood, DNS amplification, SYN flood, etc.), duration, and click a button.

The industrialization of DDoS has made attacks commonplace. Cloudflare reports mitigating thousands of DDoS attacks per day. Attacks are launched for extortion, competitive sabotage, hacktivism, personal grudges, and entertainment. The gaming industry is a particularly frequent target — players launch DDoS attacks against opponents or gaming servers as a form of cheating.

Law enforcement has conducted periodic crackdowns on booter services. In December 2018, the FBI seized 15 booter domains in "Operation Power Off." In December 2022, the FBI and international partners seized 48 more. These operations temporarily reduce attack activity, but new services quickly emerge to replace those taken down.

Mitigation Techniques

Defending against DDoS requires a layered approach. No single technique stops all attacks, and the most effective defenses combine multiple strategies operating at different layers of the network stack.

Scrubbing Centers

DDoS scrubbing centers are large, purpose-built facilities with massive bandwidth capacity (typically multiple terabits) that clean attack traffic in real-time. When an attack is detected, the target's traffic is rerouted to the scrubbing center — either by changing DNS records, swinging BGP routes, or through always-on inline deployment.

The scrubbing center inspects each packet and applies filtering rules: volumetric traffic is rate-limited, packets matching known attack signatures are dropped, and application-layer requests are challenged or validated. Clean traffic is forwarded to the origin server through a GRE tunnel or dedicated backhaul link.

Major scrubbing providers include Akamai Prolexic, Cloudflare, Hurricane Electric (which operates one of the most interconnected networks globally), and Neustar (now part of TransUnion). These providers maintain scrubbing capacity measured in double-digit terabits per second, spread across globally distributed facilities.

BGP Blackholing (RTBH)

Remote Triggered Black Hole (RTBH) routing uses BGP to instruct upstream routers to drop traffic destined for a specific IP address or prefix. When a target is under attack, the network operator sends a BGP announcement for the target's IP with a special community string (typically 65535:666, as defined in RFC 7999) that tells upstream routers to null-route the traffic.

The critical tradeoff: blackholing drops all traffic to the target, including legitimate traffic. The attacker effectively wins — the target is offline — but the rest of the network is protected from collateral damage. Blackholing is the nuclear option, typically used when the attack threatens to saturate an entire network link and impact other customers on the same infrastructure.

More granular filtering is possible with Flowspec (BGP Flow Specification, RFC 8955), which allows operators to distribute fine-grained traffic filtering rules via BGP. Instead of blackholing an entire IP, Flowspec can drop only UDP traffic on port 53 from specific source prefixes, for example. However, Flowspec support varies across router vendors and is not universally deployed.

Anycast Distribution

Anycast routing is one of the most effective structural defenses against DDoS attacks. By announcing the same IP prefix from dozens or hundreds of locations worldwide, attack traffic is naturally distributed across all locations by BGP routing. An attack that would overwhelm a single data center is spread across the entire anycast network.

For example, Cloudflare's network has over 300 locations. A 1 Tbps attack distributed across 300 cities results in roughly 3.3 Gbps per location — easily absorbed. Each location can apply local scrubbing, further reducing the impact. This is why CDN providers and anycast DNS services are inherently resistant to volumetric DDoS: their globally distributed architecture is designed to absorb exactly this kind of load.

Cloudflare's 1.1.1.1 DNS service and Google's 8.8.8.8 both use anycast for this reason. You can look up their routes to see how the same prefix is announced from multiple vantage points, each representing a different physical location absorbing a share of any attack.

Rate Limiting and Traffic Shaping

Rate limiting caps the number of requests or packets accepted from a single source within a time window. Simple per-IP rate limits are effective against application-layer attacks from a small number of sources but become less useful against distributed attacks where each bot sends a small number of requests.

More sophisticated approaches include:

• Adaptive rate limiting — dynamically adjusting thresholds based on overall traffic patterns and anomaly detection
• Connection rate limiting — capping new TCP connections per second per source IP, effective against SYN floods
• Request rate limiting — capping HTTP requests per source, often combined with CAPTCHA challenges for sources that exceed thresholds
• Geographic rate limiting — applying stricter limits to traffic from regions that do not normally generate significant traffic for the target

CDN and Reverse Proxy Protection

CDN providers like Cloudflare, Akamai, and Fastly act as reverse proxies that sit between the attacker and the origin server. The origin server's IP is hidden behind the CDN's anycast addresses, so the attacker can only target the CDN's infrastructure — which is designed to absorb attack traffic.

CDNs provide multiple layers of protection:

• Volumetric absorption — the CDN's global network absorbs raw bandwidth (multi-Tbps capacity)
• Protocol validation — the CDN terminates TCP and validates HTTP, dropping protocol-level attacks before they reach the origin
• Application-layer filtering — WAF rules, bot detection, JavaScript challenges, and CAPTCHA gates filter malicious requests
• Caching — cached content is served from edge nodes without touching the origin, so GET floods against cacheable URLs have no impact on the origin server
• IP masking — the origin IP is never exposed to the internet, preventing direct-to-origin attacks that bypass the CDN

The Routing Dimension: How DDoS Intersects with BGP

DDoS attacks and BGP are deeply intertwined. The internet's routing infrastructure is both a weapon in DDoS attacks and a critical tool for defense.

IP spoofing relies on routing. Amplification attacks only work because many networks do not implement BCP38/RFC 2827, which recommends filtering packets with source addresses that do not belong to the sending network. If all autonomous systems implemented ingress filtering, source IP spoofing — and with it, all amplification and reflection attacks — would be impossible. In practice, significant portions of the internet still allow spoofed packets to leave their networks.

BGP blackholing is the last-resort defense. When a volumetric attack threatens an entire network, operators use BGP to signal upstream providers to drop traffic at the edge. The BLACKHOLE community (RFC 7999) is supported by most major transit providers and IXPs. A network under attack can advertise a /32 host route with the blackhole community, and within seconds, the traffic is dropped before it reaches the network.

Anycast is the architectural answer. The most DDoS-resilient services on the internet — DNS root servers, major CDNs, public resolvers — all use anycast. By announcing the same prefix from many locations, they leverage the internet's routing fabric to distribute attack traffic globally.

BGP itself can be attacked. A BGP hijack can redirect a target's traffic to the attacker, effectively creating a denial of service. RPKI route origin validation helps prevent this, but adoption remains incomplete.

Notable DDoS Attacks

The history of DDoS attacks traces the arms race between attackers and defenders, with each major incident pushing the industry to develop new protections.

• February 2000 — Mafiaboy attacks Yahoo, eBay, CNN. A 15-year-old Canadian launched SYN flood attacks that took down major websites for hours. This was one of the first DDoS attacks to gain mainstream attention and led to increased investment in DDoS mitigation.
• March 2013 — Spamhaus attack (300 Gbps). DNS amplification attack against the anti-spam organization Spamhaus, facilitated by CyberBunker. The attack was large enough to cause noticeable slowdowns for other internet services in Europe. Cloudflare mitigated the attack using its anycast network.
• September 2016 — Krebs on Security (620 Gbps). The Mirai botnet attacked security journalist Brian Krebs. Akamai withdrew its pro bono protection due to cost, and Google's Project Shield stepped in to protect the site.
• October 2016 — Dyn DNS attack. Mirai botnet attacked Dyn's managed DNS infrastructure, causing widespread outages. The attack demonstrated how targeting shared DNS infrastructure creates cascading failures affecting hundreds of websites.
• February 2018 — GitHub (1.35 Tbps). Memcached amplification attack, the first to exceed 1 Tbps. GitHub used Akamai Prolexic to mitigate. Days later, a 1.7 Tbps memcached attack was recorded by NETSCOUT Arbor.
• August 2019 — Wikipedia. A sustained DDoS attack intermittently took Wikipedia offline across Europe and parts of the Middle East and Africa.
• September 2020 — Google Cloud (2.54 Tbps). Google disclosed it had mitigated a 2.54 Tbps UDP flood in 2017, the largest known volumetric attack at that time of disclosure.
• 2022-2024 — HTTP/2 Rapid Reset. Attackers exploited the HTTP/2 protocol's stream multiplexing to generate billions of requests per second. Cloudflare, Google, and AWS jointly disclosed CVE-2023-44487. Cloudflare reported mitigating attacks exceeding 201 million requests per second, and in subsequent months, attacks exceeding 398 million rps.

The Scale Arms Race

DDoS attack volumes have grown exponentially. In 2000, attacks measured in megabits. By 2010, gigabits were common. The 2013 Spamhaus attack set a record at 300 Gbps. By 2018, the GitHub attack reached 1.35 Tbps. By 2024, multi-terabit attacks are routine, and major CDN providers have built networks capable of absorbing them.

But scale alone does not tell the full story. The shift toward application-layer attacks means that even a small-bandwidth attack can be devastating if it targets the right endpoint. A 10 Mbps Slowloris attack can take down a server that could easily handle a 10 Gbps UDP flood (because the UDP flood would be caught by network-layer filters, while the Slowloris attack bypasses them).

The most dangerous modern attacks combine multiple vectors: a volumetric component to saturate bandwidth and distract defenders, a protocol attack to exhaust firewalls and load balancers, and an application-layer attack to overwhelm the servers that survive the first two layers. These multi-vector attacks require correspondingly multi-layered defenses.

Observing DDoS-Related Infrastructure

You can use the BGP looking glass to explore the networks that play key roles in DDoS attack and defense:

• AS13335 (Cloudflare) — one of the largest DDoS mitigation networks, present in 300+ cities
• AS20940 (Akamai) — operates the Prolexic scrubbing service
• AS15169 (Google) — operates Project Shield for journalist and human rights protection
• AS16509 (Amazon) — AWS Shield provides DDoS protection for cloud workloads
• AS6939 (Hurricane Electric) — one of the most peered networks globally, critical transit infrastructure
• 1.1.1.1 — Cloudflare's anycast DNS, designed to absorb DDoS via global distribution
• 8.8.8.8 — Google's anycast DNS, similarly distributed for resilience

Examining the AS paths and peering relationships of these networks reveals the architecture that makes large-scale DDoS mitigation possible: massive interconnection, strategic placement at Internet Exchange Points, and anycast prefixes announced from every continent.