DDoS Attack Defense: Volumetric, Protocol, and Application Layer Attacks

The Three Categories of DDoS Attack

Distributed Denial of Service attacks aim to exhaust resources—bandwidth, CPU, connection tables, application threads—until legitimate requests cannot be served. The attack category determines which resource is targeted and therefore which defenses apply.

Volumetric Attacks (Layer 3/4)

Volumetric attacks flood the network with raw traffic—packets per second or bits per second—to saturate the target's upstream bandwidth or overwhelm network devices. No server-side application is involved; the goal is pure pipe saturation.

UDP Flood: UDP is connectionless, so forged source IPs are trivial. An attacker can send millions of UDP packets per second to random ports on the target, forcing the server to process each one only to discover no application is listening. Rates of 100+ Gbps are achievable from botnets.

DNS Amplification: An attacker sends DNS queries with a forged source IP (the victim's IP) to open resolvers. The resolver sends responses to the victim—responses that are 50–100x larger than the query. A 100 Mbps upstream attack generates 5–10 Gbps of incoming traffic at the victim.

NTP Amplification: Similar to DNS amplification, exploiting the MONLIST command on misconfigured NTP servers to achieve amplification factors of 200–700x.

ICMP Flood (Ping Flood): High-rate ICMP echo requests consume inbound bandwidth and CPU for response generation.

Typical scale: 100 Gbps to multi-terabit attacks. Cloudflare and Akamai have each reported absorbing attacks exceeding 2 Tbps.

Protocol Attacks (Layer 4)

Protocol attacks exploit weaknesses in TCP and other network protocol implementations to exhaust stateful resources—firewall connection tables, load balancer session tables, or server SYN backlog queues.

SYN Flood: The classic attack. The TCP three-way handshake begins with the client sending a SYN. The server allocates state and sends SYN-ACK, waiting for the client's ACK. Attackers send millions of SYNs with forged source IPs that never complete the handshake. The server's SYN backlog fills up and legitimate connections are refused.

Mitigation: SYN cookies allow the server to encode connection state into the sequence number, deferring state allocation until the ACK is received—making SYN floods much less effective.

ACK Flood: Sends ACK packets that do not match any existing connection, forcing stateful devices to look up the connection and discard it—CPU-intensive at scale.

Fragmented Packet Attack: Sends fragmented IP packets that force the target to maintain fragment reassembly buffers, consuming memory.

Application Layer Attacks (Layer 7)

Layer 7 attacks are the most sophisticated and hardest to mitigate because the attack traffic is indistinguishable from legitimate HTTP/S requests at the network level. The attacker completes TCP handshakes, performs TLS negotiation, and sends valid HTTP requests—just millions of them, targeted at expensive operations.

HTTP GET Flood: High-rate requests to a URL that is expensive to serve—typically a page requiring database queries, image generation, or complex computation. Even 50,000 requests per second can overwhelm an application server if each request involves multiple database round-trips.

HTTP POST Flood: POST requests to login endpoints, search endpoints, or APIs. Particularly effective because POST endpoints often perform more work than GET endpoints.

Slowloris: Keeps many HTTP connections open by sending partial requests and periodically sending just enough data to prevent timeout. A server with a limited connection pool (Apache with default settings, for example) can be taken down with a single machine sending Slowloris traffic.

Slow POST (RUDY - R-U-Dead-Yet): Similar concept, but sends POST bodies extremely slowly—enough to maintain the connection but not enough to complete the request—tying up application threads.

Cache Busting: Appends random query string parameters to defeat CDN caching, ensuring every request hits the origin server.

CDN and Scrubbing Services

How CDNs Absorb Volumetric Attacks

A CDN like Cloudflare, Akamai, or Fastly operates points of presence (PoPs) at internet exchange points globally with aggregate bandwidth measured in tens of terabits per second. When a volumetric attack targets a customer, the CDN absorbs it at the PoP closest to the attack source, preventing the traffic from ever reaching the customer's origin network.

The key mechanism is anycast routing: the CDN's PoPs all announce the same IP prefixes. When a botnet sends traffic to your CDN-protected IP, packets are routed to the nearest PoP, where they are inspected and filtered before being forwarded to the origin.

BGP blackholing is a faster but blunter tool: the CDN or upstream ISP announces a more-specific route for the attacked IP prefix with a community that tells peers to discard traffic destined for that IP. This mitigates the attack but also drops legitimate traffic.

Scrubbing Centers

For organizations that cannot place their origin behind a CDN (legacy protocols, compliance requirements, latency constraints), scrubbing centers offer on-demand or always-on mitigation. Providers include Radware, NETSCOUT Arbor, and Imperva.

Traffic is redirected to the scrubbing center (via BGP or DNS) where it is filtered. Clean traffic is tunneled back to the origin via GRE tunnel or dedicated circuit. Latency overhead is typically 5–15 ms.

Always-on scrubbing routes all traffic through the scrubbing center permanently. On-demand scrubbing activates mitigation only when an attack is detected, preserving direct routing during normal operations.

Protection for TCP-Based Attacks

Protocol attacks require stateful tracking at the network edge. Modern DDoS mitigation platforms maintain their own connection state and use SYN cookies, ACK validation, and connection rate limiting to filter malicious connections while passing legitimate ones.

WAF Rules for Layer 7 DDoS

Network-level defenses are insufficient for sophisticated Layer 7 attacks because the attack traffic is valid HTTP. Web Application Firewalls provide the application-context rules needed to distinguish attack traffic from legitimate requests.

Rate Limiting by URI

Rate limiting is the foundational Layer 7 defense. Apply limits at the URI level rather than globally:

POST /api/auth/login          → 10 requests/IP/minute
GET  /api/search?q=*          → 20 requests/IP/10 seconds
POST /api/payment             → 5 requests/IP/minute
GET  /                        → 200 requests/IP/minute

Be careful with IP-based rate limiting when users are behind NAT (corporate networks, mobile carriers). Consider a token bucket algorithm that allows bursting while enforcing an average rate.

Behavioral Fingerprinting

Legitimate browsers behave differently from HTTP library clients used in floods. WAF rules can challenge or block requests that:

Lack standard browser headers (Accept, Accept-Language, Accept-Encoding)
Use an unusual User-Agent string or one associated with known attack tools
Do not execute JavaScript challenges (Cloudflare's "I'm Under Attack Mode" works on this principle)
Do not set or send cookies after receiving a challenge cookie

Cloudflare's Bot Score and Akamai's Bot Manager both use browser fingerprinting and behavioral analysis to assign a bot probability score to each request.

TLS Fingerprinting

TLS client hello messages have identifiable characteristics based on the client library: cipher suite list, extension order, elliptic curve preferences. A real Chrome browser has a distinct fingerprint (JA3 hash) from a Python requests library client. WAF platforms use JA3 and JA4 fingerprinting to classify traffic.

Challenge Pages and CAPTCHA

For sustained Layer 7 attacks where the above signals are inconclusive, browser-based challenges add a computational barrier. Cloudflare's managed challenge (based on proof-of-work), hCaptcha, and reCAPTCHA v3 all impose friction on automated clients while having minimal impact on legitimate users.

Protecting Expensive Endpoints

Identify your most compute-intensive endpoints and add protective rules:

Enable caching for any endpoint that can be cached, removing origin load entirely
Require authentication before allowing access to expensive operations
Implement CSRF tokens on form submissions to prevent replay of POST floods
Add query complexity limits on GraphQL endpoints (a single deeply nested query can consume significant CPU)

Incident Response for DDoS Events

Detection

Set up monitoring alerts for:

Inbound bandwidth spike (5x normal baseline)
Request rate spike at the CDN or load balancer layer
Server CPU or connection table saturation
Elevated error rates (503s, connection timeouts)
Network device CPU utilization

Automated detection should trigger alerting within 1–2 minutes of attack onset. Many attacks are resolved by CDN/scrubbing infrastructure without human intervention, but humans need to be in the loop for extended events and to assess whether the DDoS is a smokescreen for a concurrent data exfiltration attempt.

Immediate Response Actions

Activate CDN/scrubbing mitigation if not already active in always-on mode
Identify attack type from traffic analysis: volumetric (bandwidth charts), protocol (connection table saturation), or application layer (request rate and error patterns)
Apply emergency rate limiting at the CDN layer for the targeted endpoints
Enable CAPTCHA or browser challenge for affected endpoints if attack is Layer 7
Null route specific source IPs if the attack originates from a small number of sources (rare for botnets but occurs with less sophisticated attacks)
Notify upstream ISP if traffic is saturating upstream links before reaching the CDN

Communication

Prepare a status page template in advance. Users experiencing outages deserve timely updates. Internal escalation paths should be defined: who gets paged, who approves emergency configuration changes, who communicates with the CDN/scrubbing provider's support line.

Post-Incident Review

After mitigation, document:

Attack start and end times, peak traffic volumes
Attack type, source distribution
Time to detect and time to mitigate
Any legitimate traffic impacted by mitigation measures
Any concurrent attack activity (was DDoS used as a distraction?)
Configuration changes made during the incident that should become permanent

DDoS attacks are rarely one-time events. Groups that successfully disrupted your service once are likely to return. Ensure your mitigation configuration remains in place, your CDN contract covers the observed attack volume, and your runbook is updated based on what worked and what did not.