DDoS Attack #

DDoS (Distributed Denial of Service) is the attack of "sending massive (often legitimate-looking) traffic from many sources so that real users can no longer use the service." It's one of the few attack classes that succeeds even when the code has no vulnerabilities, and because "a flood of legitimate requests" and "an attack" are fundamentally indistinguishable, it has remained one of the hardest problems on the modern Internet.

The image of "DDoS = floods that fill bandwidth" is too narrow. The reality spans from filling L3/L4 bandwidth or state tables to targeting L7 application logic. This article opens with DoS vs. DDoS and why DDoS is structurally hard, then groups the attacks into three categories in one diagram, dissects Reflection + Amplification — the mechanism that scales DDoS to "another order of magnitude" — in another, surveys the supply side (botnets), 25 years of representative incidents, the defense stack, and finally what to do in the first 30 minutes when you're under attack.

1. DoS vs. DDoS — the 1-vs-N gap #

DoS follows a "single attacker exploiting a code bug" model — like Ping of Death (1996), where "send this special packet to crash the OS" — mostly patched by now. DDoS is "you can't stop it even with correct code," so it's a fundamentally different problem. "Imagine 10,000 garden hoses pointed at you simultaneously" — each hose is normal water, but the total flow exceeds what the target can drink.

2. Why DDoS is fundamentally a hard problem #

DDoS doesn't end with "the vendor publishes a patch" because it lives in the Internet's structural problems:

• The Internet was designed on mutual trust — packets reaching anywhere is the foundational feature. "Stop the irrelevant flood" is a retrofit war
• Source IPs can be spoofed — UDP doesn't form a connection, so the source IP can be anything. BCP38 (Network Ingress Filtering, RFC 2827) asks ISPs to drop spoofed packets, but less than half of the world's ISPs implement it (per CAIDA Spoofer Project's continuous measurement)
• Misconfigured amplifier servers exist in vast numbers — open DNS resolvers, NTP monlist, memcached on UDP/11211, etc. — millions of servers worldwide with sloppy configs remain
• IoT security is catastrophic — admin/admin Wi-Fi cameras and routers come online every day worldwide, so the botnet supply pipeline never empties
• "Attack vs. legitimate user" is hard to distinguish — a flash sale can spike legitimate traffic 100×, so a naive threshold drops real users

In short, DDoS lives in a structure where "perfectly hardening your servers doesn't fix the upstream paths, the reflectors, or source-IP spoofing — none of those are yours to fix." The model that emerged — giant operators (Cloudflare / AWS Shield / Akamai) absorbing attacks with anycast networks and capacity — is the practical adaptation to that structure.

3. The three attack categories — Volumetric / Protocol / Application #

DDoS divides into three by what gets exhausted. Each requires a different defense, so identifying the type is the first call when responding.

A one-line contrast for the three:

• Volumetric = "pump too much water through the pipe and overflow it" (saturate the link). Home / SMB defense is essentially upstream-dependent — you can't take 100 Gbps in your closet
• Protocol = "fill the reception desk's clipboard with incomplete customers" (SYN flood saturates TCP half-open state). SYN cookies handle this
• Application = "ask for expensive operations following the legitimate protocol" (/search?q=... at 1 M rps; Slowloris holds connections open). The hardest to distinguish from real users

Modern DDoS combines them — 1 GB/s UDP flood saturating the pipe while a 1 Mrps HTTP flood pummels the app. "Multi-vector attacks" are the standard.

4. Reflection + Amplification — generating outsized force #

DDoS reaches Tbps scale mainly because of Reflection and Amplification. Sending a small query produces a much larger response from another server — the property of UDP-based protocols that gets weaponized.

"An attacker with only 100 Mbps can produce 10 Gbps by stepping on a x100 amplifier" — this is the actual reason DDoS is feasible at the individual scale. memcached's x51,200 shocked the industry because it demonstrated 51 Gbps from 1 Mbps of input as a real possibility.

The defender's root remedy is "close every amplifier in the world," but misconfigured servers, old IoT devices, and badly designed UPnP keep entering the pool, so it never fully drains. Groups like Shadowserver Foundation and Open Resolver Project continuously scan and publish amplifier lists, notifying the operators.

5. Botnets — the supply side of DDoS #

Where reflection uses stepping-stone servers, botnets use the compromised devices themselves. Since Mirai (2016) conscripted hundreds of thousands of Wi-Fi cameras and routers left at default passwords, IoT botnets have been the primary supply of DDoS power.

A typical botnet structure:

• Loader / scanner — sweep the Internet for 23/tcp (Telnet) / 22/tcp (SSH) / 7547/tcp (TR-069), etc., and brute-force with default credential lists
• Implant (malware) — persists on infected devices, awaiting orders from a C2 (Command & Control) server
• C2 server — distributes "next target / what to send" via IRC / HTTP / Tor hidden services / blockchain
• Hit the victim — bots simultaneously launch SYN flood / HTTP flood / UDP flood at the target

The recent trend is "quality over quantity" — a few thousand high-bandwidth, datacenter-grade VMs are more efficient at raw rps than hundreds of thousands of IoT bots. Mantis pushing 26 Mrps from just 5,000 hosts is the symbolic example.

6. 25 years of representative incidents #

"The largest record breaks every year" is the steady state of the DDoS industry. Defenders (Cloudflare / Akamai / AWS) are scaling capacity rapidly too — by 2026, major scrubbing operators each have 100+ Tbps of absorption capacity.

7. Defense layers — what to stop, where, and how #

DDoS defense is layered. Doing it all yourself is impractical; the cost trade-off is how much to push upstream.

A concrete combination:

# Minimum on a single Linux server (modulo bandwidth)
sudo sysctl -w net.ipv4.tcp_syncookies=1            # SYN flood mitigation
sudo sysctl -w net.ipv4.tcp_max_syn_backlog=8192    # larger accept backlog
sudo sysctl -w net.netfilter.nf_conntrack_max=2000000

# nginx rate limiting
# /etc/nginx/conf.d/rate.conf
limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;
location /api {
    limit_req zone=api burst=20 nodelay;
    ...
}

# Flip Cloudflare into "Under Attack mode" via API instantly
curl -X PATCH "https://api.cloudflare.com/client/v4/zones/$ZONE/settings/security_level" \
     -H "Authorization: Bearer $TOKEN" \
     -H "Content-Type: application/json" \
     --data '{"value":"under_attack"}'

8. The first 30 minutes under attack #

What to actually do when DDoS hits is essentially scripted. Building a runbook in advance matters most.

1. Confirm impact — which services are down / which bandwidth or rps is anomalous / origin direct or via CDN
2. Identify attack type — use tcpdump, NetFlow, CDN dashboards to determine L3/L4 (UDP/SYN flood) vs L7 (HTTP flood)
3. Switch CDN/WAF to defensive mode — Cloudflare "Under Attack mode" / AWS Shield Advanced Engagement Hotline / call Akamai SOC
4. Narrow source IPs / countries — if the attack concentrates regionally, temporary GeoIP blocks help
5. Isolate origin — restrict origin to CDN's IP range only. Prevent direct hits
6. Tighten rate limiting — prioritize heavy endpoints like /api/*, /login, /search
7. Aggressive caching — short TTL caches even on dynamic pages
8. Notify law enforcement — depending on jurisdiction, report to police / NICTER / JPCERT (Japan) / FBI IC3 (US) in parallel for large incidents
9. Customer disclosure — update status page, post progress on social
10. Post-incident analysis — attacker IP list / amplifier identification / additional defenses / RTO/RPO review

"The best DDoS defense is preparation." Switching to Cloudflare Enterprise on a credit card after the first hit is much worse than already having CDN/WAF in front and a routing path that absorbs attacks. Even a personal site benefits from Cloudflare's free plan for L7 mitigation.

DDoS is one of the few attack classes that succeeds even against bug-free code, rooted in the structural problems of the Internet's open design and the ubiquity of amplifiers. Holding the three categories Volumetric / Protocol / Application, plus the Reflection + Amplification mechanism that produces "another order of magnitude," in your head means that when you read "an N-Tbps DDoS" in the news, you can immediately reconstruct what was actually happening.

The fundamental defense is "push it upstream" — let the providers with anycast networks and scrubbing capacity (Cloudflare / Akamai / AWS Shield) take the hit. Self-hosting and absorbing 1 Tbps is brutal even at AWS / Google / Microsoft scale. "DDoS defense = put a CDN/WAF in front" is the modern infrastructure floor; behind that, layer OS-level SYN cookies, app-level rate limits, and circuit breakers — that's the standard form for 2026.