Denial of Service Attacks
DDoS attack patterns, amplification vectors, botnet architectures, and comprehensive DoS defense strategies
Chapter 7: Denial of Service Attacks
The 2.3 Tbps Attack on AWS
In February 2020, Amazon Web Services reported mitigating the largest DDoS attack ever recorded at that time: 2.3 terabits per second (disclosed in the AWS Shield Threat Landscape Report Q1 2020). To put that in perspective, that’s enough bandwidth to download the entire Netflix library every few seconds.
The attack used CLDAP (Connection-less Lightweight Directory Access Protocol) reflection—a technique where small queries to misconfigured servers generate massive responses directed at the victim. AWS Shield, Amazon’s DDoS protection service, absorbed the traffic and kept customer services online.
But not everyone has AWS-scale resources. In October 2016, the Mirai botnet took down Dyn DNS and, with it, major websites including Twitter, Netflix, and Reddit. The attack peaked at 1.2 Tbps using a botnet of compromised IoT devices—cameras, DVRs, routers.
These incidents illustrate the modern DDoS landscape: massive botnets, powerful amplification techniques, and attacks that can overwhelm even large infrastructure providers. This chapter explores how DoS attacks work and how to defend against them.
Understanding Denial of Service
Denial of Service attacks aim to make systems or networks unavailable to legitimate users. They target the CIA triad’s Availability component.
DoS Attack Categories
DoS Attack Categories:
═══════════════════════════════════════════════════════════════════
┌─────────────────────────────────────────────────────────────────┐
│ VOLUMETRIC ATTACKS │
│ Overwhelm bandwidth capacity │
├─────────────────────────────────────────────────────────────────┤
│ • UDP Floods • DNS Amplification │
│ • ICMP Floods • NTP Amplification │
│ • Memcached Attacks • SSDP Amplification │
└─────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────┐
│ PROTOCOL ATTACKS │
│ Exhaust server/infrastructure resources │
├─────────────────────────────────────────────────────────────────┤
│ • SYN Floods • Ping of Death │
│ • ACK Floods • Smurf Attack │
│ • Fragmented Packets • Connection Floods │
└─────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────┐
│ APPLICATION ATTACKS │
│ Target application-layer resources │
├─────────────────────────────────────────────────────────────────┤
│ • HTTP Floods • Slowloris │
│ • GET/POST Floods • R-U-Dead-Yet (RUDY) │
│ • API Abuse • HashDoS │
└─────────────────────────────────────────────────────────────────┘DoS vs DDoS
| Feature | DoS | DDoS |
|---|---|---|
| Sources | Single | Multiple (botnet) |
| Scale | Limited | Massive |
| Blocking | Block one IP | Must filter traffic patterns |
| Sophistication | Usually simple | Often coordinated |
| Cost | Free tools | Botnet rental ($50-$500/hour) |
MITRE ATT&CK Reference
DoS attacks map to:
- T1498 - Network Denial of Service
- T1498.001 - Direct Network Flood
- T1498.002 - Reflection Amplification
- T1499 - Endpoint Denial of Service
- T1499.002 - Service Exhaustion Flood
Volumetric Attacks
UDP Flood
Simple attack flooding target with UDP packets to consume bandwidth.
UDP Flood
UDP Flood:
═══════════════════════════════════════════════════════════════════
Attacker ─── UDP packets ───────────────────────────────► Victim
─── UDP packets ───────────────────────────────►
─── UDP packets ───────────────────────────────►
─── (millions per second) ─────────────────────►
Target: Saturate victim's network bandwidth
Result: Legitimate traffic can't get through
Characteristics:
- Simple to execute
- Easy to detect (random ports, no application data)
- Relatively easy to filterAmplification Attacks
Amplification multiplies attack traffic by exploiting UDP services that send larger responses than requests.
Amplification Attack Concept
Amplification Attack Concept:
═══════════════════════════════════════════════════════════════════
Attacker
│
Spoofed request │ Request: 64 bytes
(src=victim_ip) │
▼
┌─────────────────┐
│ Amplifier │
│ (Open DNS, │
│ NTP, etc.) │
└────────┬────────┘
│
│ Response: 3,000+ bytes
▼
Victim
Amplification Factor = Response Size / Request Size
= 3000 / 64 = ~47x
With 1 Gbps attack bandwidth, attacker achieves 47 Gbps at victim!Amplification Vectors Comparison
| Protocol | Port | Amplification Factor | Notes |
|---|---|---|---|
| memcached | 11211 | 10,000-51,000x | Highest known, mostly patched |
| NTP monlist | 123 | 556x | Legacy servers still vulnerable |
| DNS ANY | 53 | 28-54x | Open resolvers |
| SSDP | 1900 | 30x | UPnP devices |
| CLDAP | 389 | 56-70x | Windows domain controllers |
| Chargen | 19 | Variable | Obsolete, rare |
| SNMP | 161 | 6.3x | Network devices |
| RIPv1 | 520 | 131x | Legacy routing |
DNS Amplification
DNS Amplification Attack
DNS Amplification Attack:
═══════════════════════════════════════════════════════════════════
REQUEST (64 bytes):
┌─────────────────────────────────────────────────────────────────┐
│ DNS Query: ANY dnsamplificationtest.com │
│ Source IP: 192.0.2.1 (VICTIM - SPOOFED) │
└─────────────────────────────────────────────────────────────────┘
RESPONSE (3,000+ bytes):
┌─────────────────────────────────────────────────────────────────┐
│ DNS Response to: 192.0.2.1 (victim) │
│ │
│ A records, AAAA records, MX records, TXT records, │
│ NS records, SOA records, DNSSEC signatures... │
│ │
│ All sent to victim! │
└─────────────────────────────────────────────────────────────────┘Using hping3 (Demonstration):
# DO NOT use without authorization
# Demonstrates concept only
# Spoofed DNS request
# Real attacks use many reflectors simultaneously
sudo hping3 --udp -p 53 --spoof VICTIM_IP DNS_SERVER_IP --data 64NTP Amplification
NTP’s monlist command returns addresses of last 600 clients—huge amplification.
# Check if NTP server has monlist enabled
ntpdc -n -c monlist NTP_SERVER_IP
# If returns list of IPs, server is vulnerable
# Modern NTP servers have monlist disabled
# Detection in traffic:
# Large UDP port 123 responses
# monlist response format identifiableMemcached Amplification (2018 Record)
Memcached Attack Record Breaking
Memcached Attack - Record Breaking:
═══════════════════════════════════════════════════════════════════
February 2018: GitHub attacked with 1.35 Tbps
February 2018: Record 1.7 Tbps attack detected
How it works:
1. Attacker stores large value in open memcached server:
set key 0 0 1000000
[1MB of data]
2. Attacker sends spoofed request:
get key (src=victim)
Request: ~15 bytes
3. Memcached responds to victim:
Response: 1,000,000 bytes (1MB!)
Amplification: ~51,000x
Why so effective:
- memcached default: listen on 0.0.0.0 (all interfaces)
- No authentication required
- UDP support enabled by default (older versions)Mitigation:
# Bind memcached to localhost only
memcached -l 127.0.0.1
# Or disable UDP entirely
memcached -U 0
# Firewall memcached port
iptables -A INPUT -p udp --dport 11211 -j DROP
iptables -A INPUT -p tcp --dport 11211 -s 127.0.0.1 -j ACCEPT
iptables -A INPUT -p tcp --dport 11211 -j DROPBotnet Architectures
Traditional Command & Control
Centralized C2
Centralized C2:
═══════════════════════════════════════════════════════════════════
┌─────────────────┐
│ C2 Server │
│ (IRC, HTTP, etc)│
└────────┬────────┘
│
┌───────────────────┼───────────────────┐
│ │ │
┌────┴────┐ ┌────┴────┐ ┌────┴────┐
│ Bot │ │ Bot │ │ Bot │
│ (Host 1)│ │ (Host 2)│ │ (Host n)│
└─────────┘ └─────────┘ └─────────┘
Pros: Simple, direct control
Cons: Single point of failure, easy to takedownP2P Botnet Architecture
PeertoPeer Botnet
Peer-to-Peer Botnet:
═══════════════════════════════════════════════════════════════════
┌─────────┐ ┌─────────┐ ┌─────────┐
│ Bot A │◄─────►│ Bot B │◄─────►│ Bot C │
└────┬────┘ └────┬────┘ └────┬────┘
│ │ │
└────────────────►│◄────────────────┘
│
┌────┴────┐
│ Bot D │
└─────────┘
Commands propagate through peer network
No single point of failure
Harder to takedown
Examples: GameOver Zeus, TDL-4Mirai Botnet Architecture
Mirai Architecture (IoT Botnet)
Mirai Architecture (IoT Botnet):
═══════════════════════════════════════════════════════════════════
SCANNING COMPONENT:
┌─────────────────────────────────────────────────────────────────┐
│ Infected devices scan for: │
│ - Open Telnet (23) │
│ - SSH (22) │
│ Using hardcoded credential list (admin/admin, root/root, etc.) │
└─────────────────────────────────────────────────────────────────┘
│
▼
C2 INFRASTRUCTURE:
┌─────────────────────────────────────────────────────────────────┐
│ Report Server - Receives vulnerable targets │
│ Load Server - Delivers malware payload │
│ C2 Server - Sends attack commands │
└─────────────────────────────────────────────────────────────────┘
│
▼
ATTACK CAPABILITIES:
┌─────────────────────────────────────────────────────────────────┐
│ - UDP floods │
│ - SYN floods │
│ - ACK floods │
│ - GRE floods │
│ - DNS water torture │
└─────────────────────────────────────────────────────────────────┘
Peak: 600,000+ infected devices
Record attack: 1.2 Tbps against Dyn DNSDDoS-for-Hire (Booter Services)
DDoSasaService
DDoS-as-a-Service:
═══════════════════════════════════════════════════════════════════
Cost: $10-500+ per attack
Access: Tor hidden services, clear web (disguised as "stress testing")
Power: Up to hundreds of Gbps
Customer ─── Orders attack ───► Booter Service
│
▼
Botnet Controller
│
┌────────────────┼────────────────┐
▼ ▼ ▼
Bot 1 Bot 2 Bot n
│ │ │
└───── Attack Traffic ───────────►│ VictimApplication Layer Attacks
HTTP Flood
Legitimate-looking HTTP requests overwhelming web application.
HTTP Flood Characteristics
HTTP Flood Characteristics:
═══════════════════════════════════════════════════════════════════
SIMPLE GET FLOOD:
GET / HTTP/1.1
Host: target.com
(thousands per second)
SOPHISTICATED HTTP FLOOD:
- Rotates User-Agents
- Uses real browser headers
- Varies request patterns
- Targets expensive endpoints (search, login)
- Uses HTTPS (encrypted, harder to inspect)
Detection Challenge:
Each request looks legitimate individually
Volume/pattern analysis requiredSlowloris and Slow Attacks
(Covered in detail in Chapter 5)
Slow Attack Variants
Slow Attack Variants:
═══════════════════════════════════════════════════════════════════
SLOWLORIS:
- Sends partial HTTP headers slowly
- Keeps connections open indefinitely
- Exhausts connection pool
SLOW POST (R-U-Dead-Yet):
- Sends POST with large Content-Length
- Sends body 1 byte at a time
- Server waits for complete body
SLOW READ:
- Completes request normally
- Sets tiny window size
- Reads response very slowly
- Server buffers response in memoryAPI-Based DDoS
API Abuse Patterns
API Abuse Patterns:
═══════════════════════════════════════════════════════════════════
EXPENSIVE ENDPOINT TARGETING:
- Search endpoints with complex queries
- Report generation
- Data export functions
- Authentication endpoints (hashing cost)
EXAMPLE - Search DoS:
GET /api/search?q=a*&sort=relevance&filter=all&page=1
GET /api/search?q=b*&sort=relevance&filter=all&page=1
(thousands per second)
Each request triggers:
- Database query
- Full-text search
- Result sorting
- Response formatting
CPU exhaustion without massive bandwidthDDoS Mitigation Strategies
Architectural Defenses
DDoSResilient Architecture
DDoS-Resilient Architecture:
═══════════════════════════════════════════════════════════════════
┌─────────────────────────────────────┐
│ CDN / ANYCAST │
│ (Geographic distribution) │
└─────────────────┬───────────────────┘
│
┌─────────────────┴───────────────────┐
│ DDoS MITIGATION SERVICE │
│ (Cloudflare, AWS Shield, Akamai) │
│ - Traffic scrubbing │
│ - Rate limiting │
│ - Challenge pages │
└─────────────────┬───────────────────┘
│
┌─────────────────┴───────────────────┐
│ LOAD BALANCER │
│ (Connection limits, health checks)│
└─────────────────┬───────────────────┘
│
┌───────────────────────┼───────────────────────┐
│ │ │
┌────┴─────┐ ┌────┴─────┐ ┌────┴─────┐
│ Server 1 │ │ Server 2 │ │ Server n │
│(Hardened)│ │(Hardened)│ │(Hardened)│
└──────────┘ └──────────┘ └──────────┘Network-Level Defenses
Rate Limiting:
# iptables - Rate limit by source
iptables -A INPUT -p tcp --dport 80 -m limit --limit 25/minute --limit-burst 100 -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j DROP
# Nginx - Connection limits
limit_conn_zone $binary_remote_addr zone=perip:10m;
limit_conn perip 100; # Max 100 connections per IP
limit_req_zone $binary_remote_addr zone=one:10m rate=10r/s;
limit_req zone=one burst=20 nodelay;BGP Blackhole/Flowspec:
BGP Blackhole Routing
BGP Blackhole Routing:
═══════════════════════════════════════════════════════════════════
When under attack:
1. Identify victim IP (e.g., 192.0.2.100)
2. Announce to upstream: "Route 192.0.2.100/32 to null"
3. Attack traffic dropped at network edge
RTBH (Remotely Triggered Black Hole):
router bgp 65001
neighbor 10.0.0.1 remote-as 65002
neighbor 10.0.0.1 route-map RTBH out
route-map RTBH permit 10
match tag 666
set community 65002:666
ip route 192.0.2.100 255.255.255.255 Null0 tag 666
Cons: Victim IP unreachable (attacker wins?)
Pros: Protects rest of infrastructureBGP Flowspec (More Granular):
Flowspec Granular Traffic Filtering
Flowspec - Granular Traffic Filtering:
═══════════════════════════════════════════════════════════════════
Instead of black-holing destination, filter specific traffic:
"Drop UDP traffic to 192.0.2.100:53 from any source"
Preserves legitimate traffic while blocking attack patterns
Requires Flowspec-capable routersApplication-Level Defenses
Challenge Systems:
JavaScript Challenge (Bot Detection)
JavaScript Challenge (Bot Detection):
═══════════════════════════════════════════════════════════════════
Initial request ───► Challenge Page (JavaScript required)
│
▼
Browser executes JavaScript
Computes proof-of-work
Sends solution
│
▼
Server validates ───► Access granted
Bots: Can't execute JavaScript, fail challenge
Humans: Minor delay, then normal accessCAPTCHA:
# Trigger CAPTCHA under attack conditions
# After rate limit exceeded or suspicious pattern
if request_rate > threshold:
show_captcha()DoS Detection
Traffic Analysis
# Monitor connection states
watch -n 1 'netstat -ant | grep -c SYN_RECV'
watch -n 1 'netstat -ant | grep -c ESTABLISHED | wc -l'
# High SYN_RECV = potential SYN flood
# Excessive ESTABLISHED = potential HTTP flood
# Bandwidth monitoring
iftop -i eth0
nethogs eth0
# Packet capture for pattern analysis
tcpdump -i eth0 -w attack_capture.pcapAttack Pattern Recognition
| Pattern | Likely Attack |
|---|---|
| High UDP to single port | UDP flood |
| Many SYN, few ACK | SYN flood |
| Large UDP responses (53, 123) | Amplification reflection |
| Consistent packet sizes | Botnet flood |
| Many HTTP requests, few complete | Slowloris |
| HTTP floods to single endpoint | Application DoS |
Monitoring Tools
| Tool | Purpose |
|---|---|
| Netflow/sFlow | Traffic analysis |
| Prometheus + Grafana | Metrics and alerting |
| Elastic Stack | Log analysis |
| Arbor/Netscout | Commercial DDoS detection |
| FastNetMon | Open source detection |
Lab Exercise: DDoS Analysis
Objective
Understand DDoS traffic patterns through analysis (not execution).
Exercise 1: Traffic Capture Analysis
# Download sample DDoS capture (from public datasets)
# CAIDA DDoS attack datasets: https://www.caida.org/catalog/datasets/ddos/
# Analyze with tshark
tshark -r ddos_sample.pcap -q -z conv,ip
# Shows conversation statistics
tshark -r ddos_sample.pcap -q -z io,phs
# Protocol hierarchy statistics
# Look for:
# - Predominant protocol (UDP for volumetric)
# - Packet size distribution
# - Source IP diversityExercise 2: Amplification Factor Measurement
# Safely measure DNS amplification potential
# (Against your OWN server)
# Request size
dig @your-dns-server ANY example.com | wc -c
# Compare request vs response
# Calculate amplification factor
# Response size / Request size = AmplificationExercise 3: Mitigation Testing
# Test rate limiting effectiveness
# On YOUR test server
# Configure rate limiting
iptables -A INPUT -p tcp --dport 80 -m limit --limit 10/s -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j DROP
# Use Apache Bench to test
ab -n 1000 -c 100 http://localhost/
# Observe that requests beyond 10/s are dropped
# Monitor with iptables -L -v -nKey Takeaways
-
Volumetric attacks overwhelm bandwidth—requires upstream filtering or DDoS services
-
Amplification multiplies attacker’s bandwidth up to 51,000x—close open reflectors
-
Botnets provide distributed attack sources—IoT devices are frequent targets for recruitment
-
Application attacks are harder to detect—look like legitimate traffic
-
Defense requires layers: ISP filtering, DDoS services, rate limiting, application hardening
-
BGP techniques (blackhole, flowspec) provide network-level response capabilities
Self-Assessment
-
Comprehension: Why can’t simple IP blocking stop a DDoS attack?
-
Application: Your web server is under a Slowloris attack. How do you identify it, and what’s your immediate mitigation?
-
What if: An attacker is using HTTPS for their HTTP flood. How does this complicate detection and mitigation?
Review Questions
- Explain the difference between volumetric, protocol, and application layer attacks.
- How does UDP amplification work, and what makes memcached particularly effective?
- Describe the architecture of the Mirai botnet.
- Why is HTTP flood detection challenging?
- How do BGP blackhole and flowspec differ in their approach to DDoS mitigation?
- What role do challenge systems (JavaScript challenges, CAPTCHA) play in DDoS defense?
MITRE ATT&CK Mapping
| Attack | Technique ID | Tactic |
|---|---|---|
| UDP Flood | T1498.001 | Impact |
| SYN Flood | T1498.001 | Impact |
| Amplification Attack | T1498.002 | Impact |
| HTTP Flood | T1499.002 | Impact |
| Slowloris | T1499.002 | Impact |
| Botnet C2 | T1071 | Command and Control |