What are DDoS Attacks

What a DDoS Attack Actually Is

A Distributed Denial-of-Service (DDoS) attack disrupts a service not by breaking it, but by overwhelming it — flooding a target server, service, or network with more requests, connections, or traffic than it (or the infrastructure in front of it) can process, so real users can't get through. The "distributed" part matters: instead of one machine generating traffic, the attack is launched from many machines at once — a botnet of compromised computers, IoT devices, or, in amplification attacks, unwitting third-party servers — which is what lets a modest amount of attacker-controlled bandwidth become an overwhelming flood.

The useful way to think about DDoS is as an economics attack, not a complexity attack. Every mechanism below works by finding a place where the cost to the attacker of sending a byte is far smaller than the cost to the defender of processing it. Understanding where that asymmetry lives — in TCP's connection state, or in a UDP service's response size — is what tells you which defense actually addresses the mechanism instead of the symptom.

Mechanism 1: The SYN Flood — Exploiting Connection State

TCP's three-way handshake (SYN → SYN-ACK → ACK) requires the server to allocate a small chunk of memory — a "half-open" connection entry in its SYN backlog — the moment it sees a SYN, before the client has proven it can complete the handshake. A SYN flood exploits exactly this: send SYNs from spoofed source IPs, let the server allocate backlog slots and reply with SYN-ACKs into the void, and never send the final ACK. The backlog fills with connections that will never complete, and legitimate SYNs get dropped because there's no room left.

What's actually on the wire

Tracing the backlog math

Take Linux's classic defaults: a SYN backlog (net.ipv4.tcp_max_syn_backlog) of 1024 slots, and SYN-ACK retransmission (tcp_synack_retries) of 5 — meaning the kernel resends the un-acked SYN-ACK at 1s, 2s, 4s, 8s, 16s, and 32s before giving up. That's 1 + 2 + 4 + 8 + 16 + 32 = 63 seconds that a single spoofed half-open connection occupies its backlog slot.

Once the backlog is full, the attacker doesn't need to keep sending 1024 SYNs per second — only enough to replace slots as they time out: 1024 slots ÷ 63 s ≈ 16.25 SYN/s. At 60 bytes per SYN, that's roughly 16.25 × 60 ≈ 975 bytes/s — call it ~1 KB/s of sustained spoofed traffic to keep a default Linux host's SYN backlog permanently saturated. The number is startlingly small because the attack targets a fixed-size table, not a pipe.

Mechanism 2: Reflection and Amplification — Exploiting Response Size

Where a SYN flood exhausts a state table, amplification attacks exhaust bandwidth — by abusing UDP services that reply to a small, spoofable request with a much larger response. The attacker spoofs the victim's IP as the request's source; the innocent, misconfigured UDP server does exactly what it's designed to do and sends its full response to the victim instead of the real requester. Because UDP has no handshake, the server has no way to know the source address is forged.

CISA (building on the widely-cited US-CERT/Cloudflare analysis) publishes bandwidth amplification factors — the ratio of response size to request size — for the protocols most commonly abused this way:

Memcached sits in a category of its own, by three orders of magnitude — because unlike DNS or NTP, it was never designed to be internet-facing at all; it was built as a trusted-LAN cache with no authentication, and a single get for a large cached value can return megabytes of response.

Case Study: The February 2018 GitHub Attack (1.35 Tbps)

On February 28, 2018, GitHub was hit with a flood that peaked at 1.35 Tbps and 126.9 million packets per second — at the time, the largest publicly recorded DDoS attack — via memcached reflection/amplification. The mechanism, traced end to end:

1. Attackers scanned the internet for memcached servers exposed on UDP port 11211 with no authentication (memcached was designed to be firewalled to a trusted LAN; thousands of instances were reachable from the open internet).
2. They primed each exposed server with a set command, storing a large value (tens of kilobytes) under a short key.
3. They then sent tiny get <key> requests to each server with the source IP spoofed to GitHub's — a request of maybe a few dozen bytes.
4. Each memcached server dutifully replied with the full stored value, sent to the spoofed (GitHub) address, fragmented across multiple ~1,400-byte UDP packets near typical MTU.

The numbers check out against the amplification factor: reversing the top-end 51,000× memcached factor against the observed peak gives the attacker's actual outbound bandwidth as roughly 1.35 Tbps ÷ 51,000 ≈ 26.5 Mbps — call it ~27 Mbps of real traffic the attacker's infrastructure had to generate to produce a 1.35 Tbps flood at GitHub. That's within reach of a handful of ordinary servers, which is exactly why amplification is the mechanism of choice for the largest attacks on record. The packet-size math is consistent too: 1.35 Tbps ÷ 126.9 Mpps ≈ 1,330 bytes/packet, matching memcached responses being split into near-MTU UDP fragments rather than one giant packet.

GitHub survived with about ten minutes of degraded service because its traffic was already routed through a scrubbing provider (Akamai Prolexic), which detected the anomaly and rerouted traffic through scrubbing centers. The longer-term fix wasn't on GitHub's side at all: memcached's maintainers disabled UDP by default starting in v1.5.6, and major transit providers began filtering and rate-limiting UDP port 11211 at the edge.

Mechanism 3: Application-Layer (L7) Floods — Exploiting Request Cost

The third mechanism is the one that looks least like an attack. In an L7 flood, every connection is real: each bot completes a full TCP three-way handshake, negotiates TLS, and issues a syntactically valid HTTP request. That single fact defeats the entire lower-layer defense stack — SYN cookies verify the handshake, and these clients pass the verification; packet-level filters look for malformed or spoofed traffic, and this traffic is well-formed with genuine source addresses. Nothing below layer 7 sees anything wrong, because nothing below layer 7 is wrong.

The economics asymmetry hasn't disappeared — it has moved up the stack. Instead of "cheap packet in, state-table slot out," it's "cheap request in, expensive computation out." The attacker's ideal target is an endpoint where one small GET or POST triggers heavy server-side work: an uncached search query, a DB-heavy report or filter endpoint, a large page render. Appending a random query string (?q=zqx81...) is the classic cache-busting trick — every request misses the CDN and cache and lands on the origin's database. Compare the arithmetic to Mechanism 1: a SYN flood needs ~1 KB/s to pin a fixed-size kernel table; an L7 flood needs no volume at all in network terms — a few hundred requests per second, each costing the attacker under a kilobyte, can saturate the origin's CPU or database connection pool if each request costs the server tens of milliseconds of real work. The pipe is idle while the service dies.

Slowloris is the low-and-slow dual of the HTTP flood. Instead of making the server compute, it makes the server wait: open many connections and send request headers one byte at a time, never completing the request, so each connection legitimately stays open and holds a worker thread or connection slot. With a per-server connection limit in the low thousands, a single machine trickling a few bytes per second per connection can exhaust every slot — connection-state exhaustion again, like the SYN flood, but with fully established connections that SYN cookies can't touch.

Because the mechanism is different, the defenses are different — none of the network-layer tools apply. What works: request-cost-aware rate limiting (budget by the work a client causes, not just its request count), challenges (JavaScript checks, CAPTCHA, or proof-of-work that force each client to spend resources before the server does), WAF signatures and behavioral scoring to separate bot traffic patterns from human ones, and — specifically against Slowloris — per-connection header/read timeouts and minimum-transfer-rate enforcement so a connection that dribbles bytes gets reaped. Note what's absent from that list: SYN cookies and upstream packet scrubbing, which are answering a question ("is this connection real?") that L7 attacks already answer honestly.

Choosing a Defense: Trade-offs, Not Silver Bullets

Every mitigation below addresses one mechanism, not "DDoS" in general. Picking the right one means matching it to the mechanism you're actually facing, not deploying all of them and hoping.

Takeaways

• DDoS is an economics attack: it wins by making your protection cost more than the attacker's traffic costs them — roughly 1 KB/s of spoofed SYNs can lock a default Linux SYN backlog, and roughly 27 Mbps of memcached queries became the 1.35 Tbps flood that hit GitHub in 2018.
• The attack surface is protocol asymmetry, not a bug: TCP's three-way handshake and UDP's "ask small, get big" services (DNS, NTP, memcached) are working exactly as designed — DDoS just points that design at a victim instead of a legitimate client.
• There's no single fix, only trade-offs: SYN cookies solve backlog exhaustion but not bandwidth exhaustion; BGP blackholing survives an attack by taking the target itself offline; scrubbing centers absorb volume at the cost of money, latency, and third-party trust.
• Fixing the SYN-flood side is unilateral — turn on SYN cookies on your own servers — but fixing amplification is a collective-action problem: it depends on other networks disabling open UDP services and deploying source-address validation (BCP38/RFC 2827), which is why 25-year-old amplification vectors are still exploitable today.

SYN cookies: the 32-bit stateless handshake trick

SYN cookies defend the SYN flood by refusing to allocate a half-open connection at SYN time. Instead, the server encodes the state it would have stored into the 32-bit Initial Sequence Number (ISN) of the SYN-ACK. A classic layout uses a few high bits for a coarse timestamp, a few bits for an encoded MSS value, and the remaining bits for a keyed cryptographic hash over the source IP, source port, destination IP, destination port, timestamp, MSS index, and a server secret. Exact bit layouts vary by implementation, but the principle is fixed: timestamp + MSS/options summary + cryptohash fit into the sequence number.

The client completes the TCP handshake by sending ACK = ISN + 1. On receipt, the server subtracts one from the acknowledgment number, re-derives the candidate cookie from the packet's own 4-tuple, the current or previous timestamp window, and its secret, then checks whether the hash and MSS bits match. If they do, the server allocates the real socket structure only after successful ACK verification. Spoofed SYNs never see the SYN-ACK, so they cannot return a valid ack - 1; they cost the server CPU for a hash but no backlog memory.

The trade-off is that 32 bits cannot preserve every TCP option. While SYN cookies are active, features such as large window scaling or richer option negotiation may be reduced. That is why SYN cookies are an overload defense for backlog exhaustion, not a universal DDoS solution.

Sources

• CISA/US-CERT, Alert TA14-017A — "UDP-Based Amplification Attacks" (bandwidth amplification factor table for DNS, NTP, SSDP, CharGen, memcached, and other protocols).
• CISA, Alert TA18-023A — "Memcached DDoS" advisory on the memcached UDP reflection/amplification vector.
• GitHub Engineering Blog, "February 28th DDoS Incident Report" (March 2018) — the 1.35 Tbps / 126.9 Mpps memcached attack against GitHub.
• RFC 9293 (obsoletes RFC 793) — TCP three-way handshake specification; Linux tcp_max_syn_backlog and tcp_synack_retries behavior per man 7 tcp and kernel networking documentation.
• RFC 2827 (BCP 38) — Network Ingress Filtering, the source-address-validation defense against spoofing-based reflection attacks.
• Cloudflare Learning Center — "What is a SYN flood attack?" and "What is a DDoS amplification attack?" for mechanism-level framing.