DoS and DDoS Defense

The Three Layers of Denial of Service

Denial of Service attacks aim to make a resource unavailable to legitimate users. They differ in which layer of the network stack they target and which resource they exhaust. Understanding the taxonomy is essential because the defense for a volumetric flood is completely different from the defense for an application-layer attack.

Volumetric Attacks (Layer 3/4)

The goal is simple: consume all available bandwidth between the target and the internet. The attack floods the network pipe with so much traffic that legitimate packets cannot get through. These are measured in bits per second (bps) or packets per second (pps).

Common volumetric techniques:

• UDP floods — send massive volumes of UDP packets to random ports. The target must process each packet, sending ICMP port unreachable responses for closed ports, which consumes additional bandwidth.
• ICMP floods — similar to UDP floods but using ICMP echo requests (ping floods).
• DNS amplification — send small DNS queries with a spoofed source IP (the victim's IP) to open DNS resolvers. The response is much larger than the query (amplification factor of 50–100x), and it is sent to the victim.
• NTP amplification — exploit the monlist command on Network Time Protocol servers, which returns a list of the last 600 clients. A 234-byte query can generate a 4,000+ byte response.
• Memcached amplification — send a small request to an exposed memcached server with a spoofed source IP. The server responds with up to 100,000x amplification, making this one of the most powerful reflection vectors ever observed.

The 2016 Dyn DNS attack peaked at 1.2 Tbps using the Mirai botnet. The 2018 GitHub attack reached 1.35 Tbps using memcached amplification. These numbers exceed the capacity of most single data centers.

Protocol Attacks (Layer 4)

Protocol attacks exhaust connection state tables on firewalls, load balancers, and the target servers themselves. They exploit the stateful nature of connection-oriented protocols.

• SYN floods — exploit the TCP three-way handshake. The attacker sends SYN packets but never completes the handshake (never sends the final ACK). The server allocates a connection object for each half-open connection and waits. Eventually the connection table fills and no new legitimate connections can be established.
• ACK floods — send large volumes of ACK packets. The target must process each one, consuming CPU and state-table lookups.
• RST floods — send TCP RST packets to tear down established connections.
• Fragmentation attacks — send overlapping or malformed IP fragments that consume reassembly buffer memory on the target.

Protocol attacks are measured in packets per second (pps) because the packet size is small but the per-packet processing cost is high. A server might handle 10 Gbps of normal traffic but collapse under 1 Mpps of SYN floods because each packet requires a state-table lookup and memory allocation.

Application-Layer Attacks (Layer 7)

Application-layer attacks are the most sophisticated and difficult to defend because they mimic legitimate user behavior. They target the application's processing capacity rather than network bandwidth.

• HTTP floods — send large volumes of HTTP GET or POST requests that appear legitimate. Each request triggers application logic, database queries, and template rendering. A modest number of requests per second can exhaust server CPU, memory, or database connections.
• Slow POST (Slowloris) — open many connections to the web server and send HTTP headers very slowly, one byte at a time, with pauses between each byte. The server keeps each connection open waiting for the complete request. With enough slow connections, the server's connection pool is exhausted and no new connections are accepted. The traffic volume is extremely low — often under 1 Mbps — making it invisible to volumetric detection.
• Slow read — similar to Slowloris but the attacker sends a complete request and then reads the response very slowly, keeping the connection open and consuming server resources.
• Cache busting — request URLs with random query parameters (/search?q=random123) to bypass CDN caching and force every request to hit the origin server.

Application-layer attacks are measured in requests per second (rps). They are effective because a single request can trigger expensive backend operations (database joins, API calls, file I/O) that consume far more server resources than the network cost of the request itself.

Layered Defense: Edge, Scrubbing, and Origin

No single defense handles all DDoS attack types. Effective protection requires a layered architecture that absorbs volumetric floods at the edge, filters protocol attacks at the network boundary, and rate-limits application-layer attacks at the origin.

Edge Protection: CDN and Anycast

A Content Delivery Network (CDN) with Anycast routing distributes traffic across a global network of points of presence (PoPs). When a DDoS attack targets your origin, the CDN absorbs the flood at its edge — the attack traffic is distributed across dozens or hundreds of PoPs, each handling a fraction of the total volume.

Anycast is a routing technique where the same IP address is announced from multiple locations. BGP routes each user to the nearest PoP. During a DDoS attack, the flood is automatically distributed across all PoPs announcing the attacked IP, diluting the impact on any single location.

Attack Traffic → CDN PoP 1 (absorbs 20%)
              → CDN PoP 2 (absorbs 20%)
              → CDN PoP 3 (absorbs 20%)
              → ... (distributed globally)
              → Origin Server (sees only filtered legitimate traffic)

Scrubbing Centers

For attacks that exceed CDN capacity or target non-HTTP protocols, scrubbing centers provide dedicated DDoS mitigation. Traffic is diverted (via BGP route announcement or DNS redirection) to a scrubbing facility that analyzes the traffic, drops attack packets, and forwards clean traffic to the origin.

Scrubbing centers use a combination of techniques:

• Signature-based filtering — match known attack patterns (specific payloads, protocol anomalies)
• Rate-based filtering — drop traffic that exceeds per-source or per-destination thresholds
• Behavioral analysis — identify traffic that deviates from normal behavioral baselines
• Challenge-response — send JavaScript challenges or CAPTCHAs to verify that the client is a real browser, not a bot

Major cloud providers (AWS Shield, Cloudflare, Azure DDoS Protection, GCP Cloud Armor) operate scrubbing centers as part of their DDoS mitigation services.

Origin Protection

The origin server must be protected even when edge defenses are in place, because attackers may discover and target the origin IP directly (bypassing the CDN).

Rate limiting at the web application firewall (WAF) or load balancer restricts the number of requests per source IP, per URL, or per session. This is the primary defense against application-layer attacks.

# Nginx rate limiting example
limit_req_zone $binary_remote_addr zone=perip:10m rate=10r/s;

server {
    location / {
        limit_req zone=perip burst=20 nodelay;
        proxy_pass http://backend;
    }
}

Connection limits restrict the number of concurrent connections per source IP, preventing Slowloris-style attacks from exhausting the connection pool.

Timeouts ensure that slow connections are closed before they consume resources indefinitely. Set aggressive timeouts for request headers and body reception.

Origin IP hiding — the origin server's IP address should never be publicly resolvable. Remove it from DNS records, restrict direct access at the firewall, and ensure that only the CDN or scrubbing center can reach it.

SYN Flood Defense: SYN Cookies

SYN cookies are a kernel-level defense against SYN floods. Instead of allocating a connection object for every SYN packet (which exhausts the state table), the server encodes the connection state into the SYN-ACK packet's sequence number. Only when the client sends the final ACK does the server allocate the connection object. This makes the server stateless during the handshake, eliminating the state-table exhaustion attack.

# Enable SYN cookies on Linux
sysctl -w net.ipv4.tcp_syncookies=1

# Verify
sysctl net.ipv4.tcp_syncookies
# Output: net.ipv4.tcp_syncookies = 1

SYN cookies have a trade-off: they lose some TCP options (like window scaling and SACK) that are negotiated during the handshake. For high-performance servers, a combination of SYN cookies and increased backlog queues provides better protection.

Capacity Planning

The fundamental defense against volumetric attacks is having more bandwidth than the attacker can generate. This is why cloud-based DDoS protection is effective — providers like Cloudflare, AWS, and Azure have network capacity measured in tens of terabits per second, far exceeding what most botnets can generate. For on-premises infrastructure, ensure that your internet circuit has headroom and that your ISP offers DDoS mitigation services.

Telling an Attack from a Flash Crowd

The hardest problem in DDoS defense is distinguishing an attack from a legitimate traffic surge. A product launch, a viral social media post, or a holiday shopping event can generate traffic patterns that look identical to a DDoS attack. Blocking legitimate users during a surge is as damaging as the attack itself.

Traffic Baseline Analysis

Effective detection starts with understanding normal traffic patterns. Establish baselines for:

• Requests per second (rps) per endpoint
• Bandwidth consumption (bps) per protocol
• Connection rate (new connections per second)
• Geographic distribution of sources
• User-Agent and TLS fingerprint distributions

Deviations from the baseline trigger investigation. A sudden 10x spike in rps from a single ASN (autonomous system number) is more suspicious than a 2x spike distributed across many ASNs.

Attack Signatures

Volumetric attacks are detected by monitoring bandwidth utilization and packet rates. A sudden spike in UDP or ICMP traffic, especially to a single destination, is a strong indicator. NetFlow or sFlow data from routers provides the visibility needed to detect these patterns.

# Detect top talkers using NetFlow data
# Identify sources generating the most traffic
nfdump -R /var/log/netflow/ -s srcip/bytes -n 10

Protocol attacks are detected by monitoring connection state tables. A high ratio of half-open connections to completed connections indicates a SYN flood. Firewall and load balancer metrics expose this ratio.

Application-layer attacks are the hardest to detect because the traffic looks legitimate. Indicators include:

• Unusual concentration of requests on a single endpoint (e.g., login page)
• Requests with missing or generic User-Agent strings
• Requests with no Referer header or unusual header ordering
• Geographic concentration from regions that don't normally access the service
• Requests that bypass cache (high cache miss rate)

Behavioral Analysis

Modern DDoS detection uses machine learning to identify traffic patterns that deviate from normal behavior. These systems analyze hundreds of features per request — timing, headers, TLS fingerprints, request paths, and interaction patterns — to classify traffic as legitimate or malicious.

The advantage of behavioral analysis is that it can detect slow-rate attacks (like Slowloris) that don't trigger volumetric thresholds. A Slowloris attack might generate only 100 rps, well below any rate limit, but the behavioral pattern (connections that stay open for minutes without sending complete requests) is anomalous.

Challenge-Response Verification

When the detection system is uncertain, it can issue a challenge to verify that the client is legitimate:

• JavaScript challenge — the client must execute a simple JavaScript computation and return the result. Real browsers execute it instantly; most botnet scripts do not.
• CAPTCHA — a more aggressive challenge that requires human interaction. Used sparingly because it degrades user experience.
• TLS fingerprinting — analyze the TLS ClientHello message to determine the client library. Python requests, curl, and browser TLS stacks have distinct fingerprints. Blocking requests from known botnet TLS fingerprints is effective against scripted attacks.

Response Playbook

Detection without a response plan is incomplete. The response playbook defines:

1. Automatic mitigation — rate limits, SYN cookies, and CDN absorption that activate without human intervention
2. Escalation triggers — when to page the on-call engineer, when to engage the ISP's DDoS team, when to activate the scrubbing service
3. Communication plan — who notifies customers, how to communicate status, when to involve legal or law enforcement
4. Post-attack analysis — what was attacked, what worked, what failed, how to improve

The playbook should be tested regularly with simulated attacks (red team exercises or cloud-based DDoS simulation services) to ensure that the response works under pressure.