A third kind of attack: not reading, not forging, just drowning
Everything in this rung so far has guarded two of the three letters in the CIA triad: confidentiality (keep secrets secret) and integrity plus authenticity (prove who sent what, untampered). Eavesdropping threatens the first; spoofing and man-in-the-middle threaten the second. A denial-of-service attack goes after the third letter, the one we have barely mentioned: availability. The attacker does not want to read your messages or impersonate you. They simply want your service unreachable — the shop with the doors jammed shut.
Why is availability so attackable? Because every shared resource is finite. A server has only so much memory for half-open connections; a link has only so much bandwidth; a CPU can hash only so many requests per second. A denial-of-service attack is, at heart, a contest of exhaustion: make the victim spend a scarce resource on garbage until there is none left for real users. The cheapest attacks find a resource where one packet from the attacker forces the victim to spend far more than one packet's worth of effort. That asymmetry is the whole game, and we will see it three times.
The extra letter D — DDoS, distributed denial-of-service — changes the scale, not the idea. Instead of one attacking machine, the traffic comes from thousands: a botnet of hijacked home routers, cameras, and PCs, each sending a trickle that sums to a flood. Distribution makes the attack harder to simply block by source (there is no single source) and lets a swarm of small uplinks overwhelm one big one. Same exhaustion, many faucets.
Attack one: the SYN flood and the half-open table
Recall the three-way handshake that opens every TCP connection: SYN, SYN-ACK, ACK — "can you hear me? — yes, can you? — yes." Here is the detail that an attacker abuses. When your server receives a SYN, it cannot finish the connection yet; it must remember this half-formed connection while it waits for the final ACK. So it allocates a small slab of memory in a half-open connection table and sends back its SYN-ACK. That memory is committed before the client has proven anything — the handshake is sequence-number synchronization, not authentication.
A SYN flood weaponizes that commitment. The attacker fires a torrent of SYN packets, usually with spoofed source addresses, and then simply never sends the third ACK. Each SYN forces the server to reserve a table slot and wait. With the source forged, the SYN-ACKs fly off toward addresses that never asked for anything and never reply. The table fills with phantom half-open connections, and when it is full the server must turn away the next SYN — including the SYN from a real customer. No data was stolen; the door is just jammed with people who knocked and walked off.
Normal handshake: SYN flood (spoofed sources):
client --- SYN ----> srv attacker - SYN(fake A) -> srv [slot 1 held]
client <- SYN-ACK -- srv attacker - SYN(fake B) -> srv [slot 2 held]
client --- ACK ----> srv attacker - SYN(fake C) -> srv [slot 3 held]
[connection open] srv -> SYN-ACK -> A,B,C (no one home)
...thousands more... TABLE FULL
real client - SYN -> srv [REJECTED]The clever defense is SYN cookies. Instead of allocating memory on the first SYN, the server refuses to remember anything: it encodes the connection state it would have stored into the initial sequence number of its own SYN-ACK, computed with a secret. If a real client returns the ACK, that returned number lets the server reconstruct the state on the spot — no slot was ever held. A flood of SYNs that never produce a valid ACK therefore costs the server no memory at all. It is a lovely move: make the client carry the state, so the attacker's cheap SYN no longer buys expensive server memory.
Attack two: DNS amplification, where one packet becomes fifty
The SYN flood exhausts memory. DNS amplification goes after raw bandwidth, and it leans hard on the asymmetry we flagged earlier. It exploits two facts at once: that the Internet's phone book, DNS, runs over connectionless UDP with no handshake to verify who is asking, and that a tiny query can provoke a huge answer. A small request like "give me everything you know about this domain" might be 60 bytes, while the reply — many records, signatures, the works — can be 3000 bytes or more. That is roughly a 50-to-1 amplification.
Now add source spoofing again. The attacker sends those tiny queries to thousands of open DNS servers, but writes the victim's address as the source. Because UDP never checks who really asked, each server dutifully ships its fat reply not back to the attacker but to the victim. The attacker spends 60 bytes of their own uplink and forces 3000 bytes onto the victim's downlink — fifty times the punch — and with a botnet doing this in parallel from countless reflectors, the victim's bandwidth is buried. The DNS servers are innocent middlemen, called reflectors; the trick is sometimes called a reflection attack.
Attack three: ARP spoofing, drowning a single LAN
The first two attacks come from across the Internet. ARP spoofing is the inside job, and it shows that denial of service can also be a side effect of a deeper compromise. On a local network, a host that knows another's IP address must learn its hardware MAC address before it can frame and deliver anything. It shouts an ARP request — "who has 192.168.1.1? tell me your MAC" — and trusts whatever answer comes back. There is no authentication: ARP simply believes the reply. That trust is the hole.
An attacker on the same LAN sends forged ARP replies: "192.168.1.1 is at my MAC address." Victims update their tables and start handing the attacker every packet meant for the gateway. As a man-in-the-middle this enables eavesdropping; but as denial of service it is even simpler. The attacker can point the gateway's IP at a MAC address that does not exist, and now every packet bound for the outside world is delivered into a black hole. The whole subnet loses its route off the network — total local outage — without a single byte crossing the Internet.
The defenses fit the local setting. Switches can run a feature often called dynamic ARP inspection that cross-checks ARP replies against the trusted IP-to-MAC bindings the switch already learned (for example from watching DHCP hand out addresses), and drops the lies. Static ARP entries for critical hosts, and segmenting the network into VLANs so a compromised device can poison fewer neighbors, both shrink the blast radius. The honest summary: ARP was designed for a small trusted room, and security has to be bolted on at the switch because the protocol itself will never say no.
Bailing the water out: how defense actually works
There is no single switch that turns DDoS off, and the deepest reason is uncomfortable: a flood that fills your inbound link has already done its damage before your equipment touches it, since the bottleneck is the pipe you do not control. So defense is layered. Closest in, a firewall and rate limiters drop obvious junk and cap how fast any one source may knock. SYN cookies neutralize SYN floods specifically. But against a genuinely large flood, you cannot win at your own door — you must move the fight upstream.
Upstream is where scale lives. Large mitigation providers and content networks absorb a flood by being enormous and spread out. The key trick uses anycast: the same defended IP address is announced from dozens of data centers around the world, so the routing system naturally delivers each attacker's packets to the nearest center. A flood that would crush one machine gets diluted across the whole planet, each site swallowing a slurp it can handle. Scrubbing centers then sit in the path, sift attack traffic from real traffic, and forward only the clean stream onward — bailing the water before it reaches your boat.
Step back and the pattern of this whole rung clicks into place. Confidentiality, integrity, authenticity, and availability are four separate promises, and each needs its own machinery: cryptography for the first three, capacity and validation for the last. Notice too how every attack here grew out of a protocol that trusted by default — TCP trusts that a SYN means a real client, UDP trusts the source address, ARP trusts the reply. The Internet was built among friends; network security is the long, patient work of bolting verification onto a system that originally assumed everyone was telling the truth.