DDoS Attack Encyclopedia

What a DDoS attack is

A denial-of-service attack makes a service unavailable to its legitimate users. A distributed denial-of-service attack does so from many sources at once — a botnet of compromised IoT devices, servers, routers, or rented booter/stresser infrastructure — which defeats simple source blocking and multiplies available bandwidth.

The defender's core problem is separating attack traffic from legitimate traffic when both look like ordinary requests. That is why modern defence layers reputation, behavioural baselining and fingerprinting on top of raw rate limits.

Symptoms versus causes

Slow site, 5xx from origin, saturated uplinks, connection timeouts and exhausted load-balancer state tables are all symptoms shared with ordinary capacity failures. Distinguishing signals: a sudden traffic spike from a single geography or ASN, an implausible spike from one device class or one User-Agent, a flood to a single URL, an unusual ratio of odd traffic patterns (e.g. every request identical length), or repeated spikes at a fixed interval.

Attack classes

Asymmetry is what makes L7 attacks efficient: a request costs the attacker a few hundred bytes and almost no CPU, while the response may require a database join, a template render and megabytes of egress. Ten thousand requests per second can take down an origin that would shrug off many gigabits of junk packets.

Layer 3 attacks

Layer 3 (network layer) attacks target the IP layer itself and do not require any application interaction — often not even a completed handshake. They aim to saturate the pipe or overwhelm packet-processing capability, which is measured in packets per second because per-packet overhead, not payload size, is frequently the bottleneck for routers and firewalls.

• ICMP (ping) flood — a torrent of echo requests; each reply consumes outbound bandwidth too, so the target loses capacity in both directions.
• Smurf attack — ICMP echo requests sent to a network broadcast address with the victim's spoofed source, so every host on that network replies to the victim. Largely mitigated by disabling directed broadcasts.
• IP fragmentation attacks — overlapping or never-completing fragments force the target to hold reassembly buffers.
• Ping of Death — malformed oversized packets that crash naive reassembly code (historic, but the pattern recurs in new stacks).

Mitigation: upstream scrubbing with far more capacity than the attack (Prolexic), anycast to spread the load over many POPs, and edge ACLs/flowspec rules. On-box filtering does not help once the uplink itself is full — the traffic must be dropped before it reaches your transit.

SYN flood

The attacker sends a flood of TCP SYN packets, usually with spoofed source addresses, and never completes the handshake. Each SYN causes the server to allocate a connection control block and hold it in SYN-RECV while it retransmits SYN-ACKs and waits for an ACK that never arrives. The backlog queue fills and legitimate SYNs are dropped.

Attacker (spoofed 198.51.100.x)          Server
  SYN  ---------------------------------->  allocate TCB, SYN-RECV
  SYN  ---------------------------------->  allocate TCB
  SYN  ---------------------------------->  allocate TCB   ... backlog full
       <--- SYN-ACK (sent to the innocent spoofed host, discarded)
  (final ACK never arrives; TCBs are held until timeout)

Variants

• Direct — attacker uses its real IP (rare; easy to block and the attacker's own stack must suppress RSTs).
• Spoofed — random or targeted spoofed sources; the default.
• Distributed — botnet-sourced, may or may not spoof; volume alone exhausts the backlog.

Mitigation

SYN cookies are the canonical defence: instead of allocating state, the server encodes the connection parameters into the initial sequence number of the SYN-ACK and only allocates memory when a valid ACK returns. Complementary controls: increasing the backlog, reducing SYN-RECV timeout, recycling the oldest half-open connection, and upstream scrubbing that completes handshakes on behalf of the origin (proxy/TCP-terminating architectures such as a CDN edge do this inherently).

UDP flood

The attacker floods random ports on the target with UDP datagrams. For each datagram the host checks for a listening application, finds none, and answers with an ICMP Destination Unreachable. Both the inbound flood and the outbound ICMP responses consume resources, and the target's rate-limiting of ICMP eventually causes legitimate traffic to be dropped as well.

Amplified variants are far more common than raw floods because they multiply the attacker's bandwidth: DNS ANY queries, NTP monlist, memcached, SSDP, CLDAP, chargen. Mitigation is upstream: drop the unwanted UDP at the scrubbing centre, since anything reaching your edge has already consumed your transit.

DNS flood

A DNS flood is a symmetric layer-7 attack against authoritative DNS infrastructure — distinct from DNS amplification, which uses DNS servers as reflectors against a third party. Because the request looks like a valid query from a valid resolver, filtering must be smarter than a pattern match.

Sub-variants

• Straight query flood — high-rate valid queries for existing records; overwhelms QPS capacity.
• NXDOMAIN / random subdomain (“water torture”) attack — queries for <random>.example.com. These can never be cached, so every recursor is forced to forward to the authoritative servers, and both the recursors' outstanding-query tables and the authoritative servers are exhausted simultaneously.
• Phantom domain attack — the attacker stands up slow or unresponsive nameservers and makes resolvers query them, tying up resolver resources.

Mitigation: massively distributed anycast authoritative DNS so the load lands on hundreds of POPs (Akamai Edge DNS), response rate limiting, per-resolver behavioural analysis, and shielding architectures that place a caching tier in front of authoritative infrastructure (DNS Shield).

ACK flood

The attacker sends a flood of TCP ACK packets that do not correspond to any established session. Stateful devices must look up each packet in their connection table; when no session matches, they must decide whether to drop or reset, and that lookup cost per packet is the attack. ACK floods are attractive because ACKs pass many naive filters that only rate-limit SYNs.

A particularly nasty variant is the ACK-PSH flood, which adds the PSH flag so devices are pushed to process the payload immediately. Mitigation: stateful inspection at a scrubbing tier with capacity measured in Tbps/Gpps, dropping out-of-state ACKs before they touch origin firewalls.

QUIC flood

QUIC runs over UDP with integrated TLS 1.3, so a QUIC flood combines UDP's spoofability with the CPU cost of cryptographic handshakes. Attack forms include floods of QUIC Initial packets that force the server into expensive key derivation, floods of packets with invalid connection IDs, and generic UDP floods aimed at port 443/UDP that the server must at least parse before discarding.

Defence is complicated by QUIC's encryption: intermediate devices cannot inspect most of the header, so mitigation must happen where the QUIC session is terminated. Key controls: enforce the anti-amplification limit and Retry-token address validation, rate-limit new connection attempts per source, offload handshake processing to distributed edge capacity, and retain the ability to disable QUIC and fall back to TCP under attack.

Application-layer (layer 7) attacks

L7 attacks complete the handshake and send well-formed requests. They are cheap for the attacker and expensive for the defender, and they are hard to distinguish from a flash crowd. The mitigation problem is fundamentally one of identity and behaviour, not volume.

HTTP flood

Many bots issue GET or POST requests to the target.

• HTTP GET flood — requests for content, often large assets or uncacheable dynamic pages. Cheap to generate.
• HTTP POST flood — form submissions and API writes that trigger database work and server-side processing; each request costs the origin far more than the attacker.
• Cache-busting — appending random query strings (?cb=91827) so the CDN cannot serve from cache and every request goes to origin. This is why unique-query-string handling and behavioural detection matter more than cache hit ratio alone.
• Expensive-endpoint targeting — search, filtering, report generation, PDF export, or an unbounded API pagination parameter.

Low-and-slow attacks

Slowloris opens many connections and sends partial headers, adding one header every few seconds to keep them alive; the server's worker pool is exhausted with almost no bandwidth. Slow POST (R-U-Dead-Yet) declares a large Content-Length and dribbles the body a byte at a time. Slow read advertises a tiny TCP receive window so responses drain very slowly. All three are invisible to bps/pps monitoring — watch concurrent connection counts and request duration distributions instead.

Detecting and mitigating L7

• Behavioural baselining per endpoint — learn the normal request rate for method + hostname + path and act on deviation rather than on a static number (see the Behavioral DDoS Engine).
• Client fingerprinting — TLS/JA-style fingerprints and HTTP header ordering separate real browsers from scripted clients even when User-Agent is forged.
• Reputation — score clients on their history across the whole platform before they ever touch your property.
• Progressive challenges — JavaScript proof-of-work, cryptographic challenges or CAPTCHA for suspicious tiers rather than a binary block.
• Rate controls — still valuable for coarse, high-volume URL fuzzing and scraping.

IP spoofing

IP spoofing forges the source address in the IP header. Because IP itself has no source authentication and UDP requires no handshake, forging is trivial for connectionless protocols. Spoofing enables three things: hiding the attacker's identity, defeating source-based blocklists, and — most importantly — reflection, where the response goes to the victim rather than the sender.

Where it works and where it does not

Spoofing works for UDP and for the first packet of TCP (the SYN). It does not survive a completed TCP handshake, because the attacker never receives the SYN-ACK and therefore cannot produce a valid ACK sequence number. This is why L7 attacks generally come from real, non-spoofed botnet IPs, and why L3/L4 floods are overwhelmingly spoofed.

Countermeasures

• BCP 38 / ingress filtering at network operators: drop outbound packets whose source address is not within the network's own allocation. The single most effective fix, and still incompletely deployed.
• uRPF (unicast Reverse Path Forwarding) — drop a packet if the route back to its source does not point out of the interface it arrived on.
• SYN cookies — make spoofed SYNs stateless for the server.
• Egress and reflector hygiene — disable open recursion on resolvers, disable NTP monlist, do not expose memcached to the internet.

A layered mitigation strategy

1. Absorb — anycast plus multi-Tbps scrubbing capacity so volumetric traffic is diluted across hundreds of locations rather than concentrated at your uplink.
2. Terminate — a proxying edge terminates TCP/TLS/QUIC, so state-exhaustion attacks stop at the edge and never reach origin.
3. Hide the origin — if the origin IP is reachable directly, every other control can be bypassed. Lock origin firewalls to the CDN's IP ranges and use mutual authentication.
4. Score and baseline — reputation and per-endpoint behavioural baselines for the L7 traffic that survives.
5. Rate-limit the coarse cases — static thresholds for URL fuzzing, scraping and pathological clients.
6. Rehearse — runbooks, pre-approved emergency configurations, contact paths to your provider's SOC, and known-good rollback.