Distributed Denial-of-Service Attacks

DoS and DDoS — The Big Picture

A Denial of Service (DoS) attack tries to make a service unavailable to legitimate users. Examples: a website becomes unreachable, a server is overloaded, a router or link is saturated, or an application crashes.

A Distributed Denial of Service (DDoS) attack is the same idea, but launched from many machines at once — usually a botnet (a group of compromised devices under attacker control).

Which security property is under attack? Availability. The service may still have correct data and keep secrets confidential, but users cannot access it.

Key Terms

DoS Attack Taxonomy

DoS attacks are classified along three dimensions: target discovery (scanning), source hiding (spoofing), and what system component is attacked.

Scanning Strategies

IP Source Spoofing Types

Attack Target Classification

Network DoS & Amplification

Two Types of Amplification Attacks

DoS Can Happen at Any Network Layer

• Application: Request large files, flood HTTP, RSA handshake exhaustion (10× decrypt cost)
• Transport: TCP SYN flood exhausts server connection backlog queue memory
• Network: IP spoofing, BGP route hijacking redirects global traffic to attacker
• Data Link: Flood traffic to saturate the physical link bandwidth entirely

NTP/DNS Amplification Attack

NTP synchronizes clocks. Its asymmetric request/response size makes it ideal for amplification. The attacker spoofs the victim's IP as the source — the NTP/DNS server sends its large response straight to the victim.

DNS Amplification — March 2013 (309 Gbps Attack):

Attacker (spoofs victim IP) → Small Query (60 bytes) → DNS Server → Big Response (3000 bytes) → VICTIM (flooded)

50× DNS amplification factor — EDNS = Extended DNS flags enable larger responses.

Why UDP-based NTP is especially vulnerable:

Key stats: 309 Gbps peak (March 2013), 28 min duration, 28M open DNS resolvers (2014), 3 networks used for 309 Gbps.

Why UDP is Often Abused

UDP is a favorite for attackers because it is connectionless, requires no handshake, allows source IP spoofing, and servers may respond immediately. That makes UDP-based services like DNS and NTP especially useful for amplification attacks.

UDP Floods

A UDP flood sends many UDP packets to overwhelm the target. Attackers can spoof UDP source IPs. Firewalls do not magically solve this — a firewall must still inspect huge amounts of traffic, and during a large enough flood, the firewall itself can become part of the problem.

IP & TCP — Why They're Vulnerable

IP Header

• Connectionless · Unreliable · Best-Effort
• Critical weakness: Source Address — NOT AUTHENTICATED

TCP Header

• Session-Based · Congestion Control · In-Order Delivery
• SYN flag: initiates connection
• Server must store connection state (seq numbers, port info) while waiting for ACK

Normal TCP 3-Way Handshake

CLIENT                                    SERVER
   |                                         |
   |  SYN: seq=rand_C, ack=0 ──────────────> |  (Listening)
   |                                         |
   |  <──────────────── SYN/ACK: seq=rand_S, ack=seq_C+1
   |                                         |  (Store seq_C, seq_S)
   |                                         |
   |  ACK: seq=seq_C+1, ack=seq_S+1 ───────> |  ✓ Established

TCP SYN Flood

After receiving a SYN, the server stores connection state and waits for ACK. The attacker sends thousands of SYNs with spoofed random source IPs — the SYN/ACKs go to random machines that never ACK back, filling the server's backlog queue until it can accept no new connections.

SYN Flood flow: Attacker (spoofed IPs) → SYN C1, SYN C2, SYN C3... → Server (QUEUE FULL)

Defense: SYN Cookies

Proxy-Based Defense (CloudFlare / Prolexic)

For very large DDoS attacks, the issue is not only the server's memory — uplinks, routers, and surrounding infrastructure can also be overloaded. Proxies and CDNs (e.g., CloudFlare, Prolexic) sit in front of the real site, handle large traffic volumes, and only forward established or validated traffic. They absorb or filter attack traffic before it reaches the origin.

Defeated by connection floods (see next section), but then bot IPs are revealed — defenders can block or rate-limit them.

Advanced Attack Techniques

TCP Connection Flood

Bypasses SYN-flood proxies by completing the full TCP handshake, then repeatedly sending HTTP HEAD requests.

1. Complete TCP handshake — full SYN/SYN-ACK/ACK. Proxy cannot block it.
2. Send HTTP HEAD request — causes expensive server work (disk/DB) for minimal attacker cost.
3. Repeat at scale — 20,000 bots overwhelm even protected servers.

JavaScript-Based DDoS

Real case: GitHub DDoS (March 2015). Attacker compromises a popular server and injects malicious JS into innocent users' browsers:

function imgflood() {
  var TARGET = "victim-website.com/index.php?";
  var rand = Math.floor(Math.random() * 1000);
  var pic = new Image();
  pic.src = "http://" + TARGET + rand + "=val";
}
setInterval(imgflood, 10); // fire every 10ms

Flow: User visits compromised site → imageFlood.js injected → Script hammers target every 10ms → Millions of honest users = massive involuntary botnet.

DoS via BGP Route Hijacking

The BGP routing protocol can be exploited to redirect all traffic destined for a victim. If an AS announces a more-specific IP prefix, every router on the Internet updates — traffic flows to the attacker instead. BGP prefers more-specific routes: e.g., /24 is more specific than /22, so the more specific route wins.

SSL/TLS Handshake Exploitation

In an SSL/TLS handshake, the client encrypts a shared secret using the server's public key (cheap). The server must RSA-decrypt it (10× more expensive). Attacker floods the server with handshake requests — overwhelming it with decryption while spending almost nothing.

Same principle at the application layer: a simple HTTP GET for a 1GB file costs the attacker almost nothing but exhausts server I/O.

DoS Mitigation Strategies

Client Puzzles

Force connecting clients to solve a moderately hard computational problem before the server does expensive work. Slows down bots while remaining tolerable for humans.

Memory-Bound Puzzles — Better: CPU ratio (server vs phone): 8000×. Memory access time ratio: only 2×. Memory-bound functions are fairer across all device classes.

CAPTCHAs

Completely Automated Public Turing test to tell Computers and Humans Apart. Server verifies that requests come from humans, not bots. One CAPTCHA per source IP.

Flow: Attack detected → New IP → CAPTCHA presented → Only valid solution unlocks processing → Bots cannot solve → rate-limited.

Limitation: CAPTCHAs are not a universal DDoS solution. They are more useful for browser/app traffic and human-facing actions. Less useful for raw protocol floods, reflection attacks, and non-human traffic that does not involve a UI.

Ideal client puzzle properties: Stateless, scalable difficulty, easy to construct / hard to solve.

Ingress Filtering

ISPs configure routers to drop any packet whose source IP does not belong to the ISP's own address space. Example: Drop all packets with src outside 204.69.207.0/24.

Traceback

Given a stream of attack packets, reconstruct where they came from. Traceback [Savage et al. '00] has routers probabilistically mark packets with routing information — the victim collects many packets and statistically rebuilds the attack path.

Assumptions: Most routers uncompromised; attackers send many packets; route relatively stable; works for single or multiple attackers.

Why many packets? One packet rarely contains enough path information; many packets together allow the victim to reconstruct the full path.

Why not record full path? Path can be 30+ hops — no header space. Changing IP format requires global upgrades. Better: fixed-size field + probabilistic sampling.

Edge Sampling Algorithm

Each packet carries: start IP, end IP, distance. Each router flips a coin to overwrite or increment.

Walkthrough (R1 → R2 → R3):

1. R1 tosses heads → Writes start=R1, end=—, d=0
2. R2 tosses tails, d=0 → Writes end=R2, d=1
3. R3 tosses tails, d>0 → Only increments d=2

Victim reads: edge R1→R2 at distance 2. Collecting many packets builds the full path graph.

Path reconstruction:

Reflector Attack

A reflector attack uses legitimate, innocent servers as unwitting middlemen to flood the victim. The attacker spoofs the victim's IP as source — legitimate servers send their responses to the victim, flooding it without the attacker directly touching the victim.

Architecture: Master → Bots → (request with src=victim) → Reflectors (DNS, Web, Gnutella) → reply (dst=victim) → VICTIM flooded

Reflector attack defenses: Filtering DNS close to the victim is too late — the flood has already arrived. Better approaches: server redundancy across networks and geographies; rate-limiting responses from name servers; distributing load so one location being hit does not take down the service.

Capability-Based Defense

Basic idea: Sender includes a receiver-granted "capability" token. Routers only forward (1) initial requests, and (2) packets with valid capability. Revoke capability → routers drop packets close to source.

Key papers: Anderson et al. "Preventing Internet DoS with Capabilities" SIGCOMM '04; Yaar et al. "SIFF" IEEE S&P '04; Yang et al. "A DoS-Limiting Network Architecture" SIGCOMM '05.

Summary & Key Takeaways

Attack Landscape

• Scanning: Random · Permutation · Signpost · Hitlist
• Amplification: NTP/DNS exploited for 50×+; 28M open resolvers
• Protocol Exploits: IP no source auth; TCP leaks state; BGP no prefix verification
• Higher-Level: SSL RSA imbalance; HTTP asymmetry; JS injection → browser botnet

Defense Toolbox

• SYN Cookies: Stateless TCP defense, minimal overhead
• Proxy Filtering: Forward only established TCP; bot IPs revealed by connection floods
• Client Puzzles & CAPTCHAs: Rate-limit with computational cost
• Traceback & Capabilities: Edge sampling; future: receiver-granted capabilities

Quick Reference

Further Reading

• Savage et al. '00 — Probabilistic packet marking for IP traceback
• Paxson '01 — An Analysis of Using Reflectors for DDoS Attacks
• CloudFlare Blog — "The DDoS that Almost Broke the Internet" (March 2013, 309 Gbps)