Topic 7.7
Network Attacks & Defences: DDoS, SYN Floods & Spoofing
In one line
Services on the internet face floods of traffic (DDoS), half-open connection floods (SYN floods), forged source addresses (spoofing), and attempts to redirect traffic (DNS or BGP hijacks). Defence is layered: absorb volume at a CDN or cloud edge, use SYN cookies and connection limits on hosts, rate-limit at proxies, filter spoofed traffic, and monitor so you notice early. This topic covers how each threat shows up and how to detect and defend against it.
Think of it like this
A popular restaurant. A crowd blocking the entrance (volume flood), fake phone bookings that never show up (SYN flood holding tables), or someone placing orders in another person's name (spoofing). The restaurant needs a doorman, a booking policy, and a way to verify callers.
Words you'll meet
New words in this topic, in plain English. Come back here whenever one feels fuzzy.
- DDoS
- Distributed denial of service: many sources overwhelming a service to make it unavailable.
- SYN flood
- An attack sending many SYNs without completing handshakes, to exhaust connection state.
- SYN cookies
- A technique where the server encodes connection state in the SYN-ACK, storing nothing until the client replies.
- IP spoofing
- Sending packets with a forged source address.
- Amplification
- Using servers that send large responses to small requests to multiply attack traffic toward a victim.
- WAF
- Web Application Firewall: filters HTTP requests by rules (paths, patterns, rates, bots).
- BCP 38
- The best practice of filtering outgoing packets whose source address doesn't belong to your network.
Step by step
01Spotting a SYN flood
During a lunch-hour promotion, the Tiffin API becomes unreachable for some users. CPU is low, but the number of half-open connections is huge and the kernel log mentions SYN flooding.
02Layered defence for Tiffin
After the incident, Tiffin puts all public traffic behind a CDN with DDoS protection, locks the origin so it accepts traffic only from the CDN's address ranges, and adds rate limits and a WAF rule on the expensive search endpoint.
# trust the CDN's header for the real client IP (only from CDN ranges)
set_real_ip_from 173.245.48.0/20; # example CDN range, keep the full list updated
real_ip_header CF-Connecting-IP;
limit_req_zone $binary_remote_addr zone=search:20m rate=5r/s;
limit_conn_zone $binary_remote_addr zone=perip:10m;
server {
location /api/search { limit_req zone=search burst=10 nodelay; limit_req_status 429; }
limit_conn perip 50; # max concurrent connections per client IP
}03Not being part of someone else's attack
Defence also means not helping attackers. Tiffin's internal DNS resolver must not answer queries from the internet (an open resolver is an amplification tool), and the VPC's egress must not allow spoofed sources (cloud networks already enforce this).
Break it on purpose
Errors are the best teachers. Make each change, read the error, guess what went wrong, then reveal the answer.
Break #1
Protection that can be bypassed
Tiffin enables the CDN's DDoS protection, but the load balancer still accepts traffic from anywhere, and its public IP appears in old DNS history.
Myth vs fact
Myth
Autoscaling handles DDoS.
Fact
It can absorb small application-layer spikes, but scaling to meet an attack mostly scales the bill. Filter at the edge and cap autoscaling.
Pro corner
Extra depth for experienced readers. New to this? Skip it for now and come back later.
- ▸
Write the DDoS runbook before you need it: who can enable 'under attack' modes or stricter WAF rules, the provider's emergency contact, which endpoints can be temporarily disabled (search, recommendations) to protect ordering, and how to tell customers. Practise it in a game day (SRE course).
Remember this
- 1
DDoS comes in layers: volumetric (filling the link with traffic, measured in Gbps), protocol (exhausting connection tables, such as SYN floods), and application (expensive HTTP requests like search or login, measured in requests per second).
- 2
SYN flood: attackers send many SYNs (often with spoofed sources) and never complete the handshake, filling the server's queue of half-open connections. SYN cookies let the kernel answer without storing state until the handshake completes.
- 3
Spoofing: forging the source IP. It works for one-way floods and reflection/amplification attacks (small spoofed requests to open DNS, NTP, or memcached servers that send large replies to the victim). Networks block it by dropping packets with impossible source addresses (BCP 38 ingress filtering).
- 4
Absorb at the edge: CDNs and cloud DDoS services (Cloudflare, AWS Shield, Cloud Armor) have far more capacity than one data centre. Keep origin servers reachable only from the edge, so attackers can't go around it.
- 5
Application-layer defences: rate limits per IP or user, caching, WAF rules, bot checks for expensive endpoints, and autoscaling with sensible limits.
- 6
Detect early: alert on unusual traffic (requests per second, SYN-RECV counts, bandwidth by source), and keep a runbook: who to call, how to turn on stricter edge rules, how to communicate.
Explain it without notes
How do SYN cookies defend against SYN floods?
Why must the origin be locked to the CDN?
Practice
Check whether SYN cookies are enabled and how many half-open connections a server has.
List three layers of defence for a public API, from the edge to the app.
Trade-offs
- ↔
Aggressive filtering stops attacks but can block real users (shared office or carrier IPs), so prefer per-user limits where possible and monitor false positives. Edge protection costs money but is far cheaper than building equivalent capacity yourself.
Done when you can
I can describe volumetric, protocol, and application-layer attacks.
I know how SYN cookies and rate limits help.
My origins only accept traffic from the edge.