A DDoS attack tries to make a service unavailable by exhausting a resource: link bandwidth, packet-processing capacity, connection state, or application workers. On adult platforms the motivation is usually competitive, extortion, or disruption around a launch or a live event. Effective protection is layered, always on, and designed so that absorbing an attack does not break legitimate delivery. See Web application and API protection for the layer-7 rules that complement it.
Volumetric versus layer 7
The two classes need different defences because they exhaust different resources.
| Class | What it exhausts | Signature | Primary defence |
|---|---|---|---|
| Volumetric (L3/L4) | Link capacity, packet rate | Huge Gbps/Mpps, often spoofed or reflected | Network capacity, scrubbing, anycast distribution |
| Protocol/state (L4) | Connection tables, handshake CPU | SYN floods, connection churn | SYN protection, connection limits |
| Application (L7) | Worker pools, origin CPU, database | Request floods that look like real traffic | Rate limiting, caching, bot rules, WAF |
Volumetric attacks are measured in bits and packets per second and are often amplification/reflection attacks using UDP-based protocols. Layer-7 attacks are measured in requests per second and are the harder problem: they use valid TCP sessions and well-formed requests, so they blend into real traffic.
Always-on mitigation
The right default is mitigation that is active before an attack starts, not one that is switched on after a support escalation. Always-on means attack traffic is sampled and scrubbed continuously, so the first seconds of an attack — when volumetric floods do the most damage — are already covered. Capacity is distributed so that an attack aimed at one hostname is absorbed across many edge locations rather than concentrated on one ingress point.
Redirection: BGP and GRE
For large volumetric attacks, a common architecture is to redirect traffic for the attacked prefixes to a scrubbing network. Two generic mechanisms:
- BGP-based diversion. The scrubbing network announces the attacked prefix with a more specific route, so traffic flows to scrubbing capacity, is cleaned, and is returned to the real service — often over a tunnel. This is the standard response to large floods because it moves the whole prefix, not just one service.
- GRE tunnel redirection. Traffic is tunnelled to a scrubbing location and returned clean. This works at the routing layer and is useful when you control the edge but the attack is aimed at a specific address.
Both are traffic-engineering responses; the exact control depends on how your routing is set up. The important property is that diversion is fast and reversible, and that returning clean traffic does not itself create a new bottleneck.
FlowSpec and surgical filtering
FlowSpec lets you distribute a filtering rule to routers so that matching traffic is dropped or rate-limited at the forwarding layer, before it consumes application capacity. It is useful for precise, high-volume drops — a specific attack vector, port, or protocol — and for pushing a mitigation out quickly across a network. Pair it with flow telemetry so you can see whether the rule is actually removing the attack and not collateral traffic.
Cache-busting attacks
The most expensive layer-7 attacks on a CDN-fronted platform are cache-busting: the attacker appends a unique query string or random path to every request so that each one is a cache miss. The cache stops helping, every request reaches the origin, and a modest request rate becomes enormous origin load. Defences:
- Normalise cache keys so meaningless parameters do not create unique objects. See Cache control and cache keys.
- Cap the cardinality of what can reach origin, and apply rate limits per client and per path pattern.
- Put an origin shield in front of the origin so even a miss storm collapses into a bounded number of fills.
- Alert on origin request rate and origin egress, not just edge request rate — a cache-busting attack can look normal at the edge.
Inline mitigation for short attacks
Many attacks are short and bursty. For these, inline mitigation at the edge — rate limiting, connection limits, challenge responses, and dropping known-bad fingerprints — can absorb the event without a full traffic-diversion dance. The tradeoff is precision: inline rules must not catch legitimate viewers. Start in monitor mode, measure the false-positive rate, then enforce.
Event logs and forensics
Every mitigation event should produce a record: start and end time, vector, peak rate, the prefixes and hostnames affected, the rule or diversion applied, and the estimated collateral. Those logs let you tune thresholds, prove what happened, and distinguish an attack from a self-inflicted outage. Retain them long enough to compare across events.
Where AdultInfra fits
AdultInfra runs always-on protection sized for the bursty, high-cardinality traffic adult platforms see, and tunes cache-key hygiene so cache-busting attacks do not reach origin. Content moderation, lawful takedowns, and abuse handling remain your responsibility. Start with CDN platform or contact us to review your exposure.