Most DDoS postmortems celebrate the moment inbound gigabits fell. The outage that users felt often arrived later, when origin connection tables, TLS handshake queues, and application worker pools were already exhausted. Volumetric scrubbing can leave those layers unprotected if your playbook treats bandwidth absorption as the finish line.
That gap matters right now. Application-layer abuse keeps evolving alongside quieter protocol shifts that many edge rules still treat as edge cases. The emerging HTTP QUERY method sits in a grey zone between GET and POST for caching and idempotency assumptions, which means rate policies and bot scores built only around classic verbs can miss floods that look polite in packet counts. Pair that with the steady drumbeat from ISC Stormcast briefings this week and you get a practical reminder: defenders who only watch transit volume will misread the attack they are actually in.
Where the standard playbook quietly breaks
Security and network teams usually inherit a layered story that sounds complete. Upstream blackholing or scrubbing for floods. CDN and WAF for Layer 7. Rate limits for abuse. Runbooks that say engage the provider, raise thresholds, wait for the curve to flatten. On paper that covers the kill chain. In production it covers the layers that produce the loudest graphs.
Real attacks rarely stay in one lane. A mid-size SaaS operator we reviewed after a two-day event saw scrubbing bring public transit from 48 Gbps down to a few hundred Mbps within twelve minutes. Customer tickets kept rising for another forty minutes. The origin fleet still accepted SYN and ClientHello traffic that had already passed reputation and volumetric filters. Conntrack on the load balancers hit max entries. New TLS sessions queued behind half-open work. Application pods spent CPU on handshake and auth preamble instead of business requests. From the scrubber portal the incident looked contained. From support it looked like a total outage.
Three habits drive that mismatch.
- Success metrics tied to transit only. If the dashboard that executives see is Gbps and pps, responders optimize for those numbers and stop investigating once they improve.
- Assumed symmetry between edge and origin capacity. Edge nodes absorb millions of concurrent flows. Origins are sized for legitimate concurrency plus a modest spike. Passing a thinned flood to origin still wins for the attacker.
- Static verb and path assumptions at Layer 7. Controls tuned for GET and POST miss unusual methods, slow-and-low POST bodies, and cache-busting query patterns that stay under volumetric alarms while burning workers.
Identity and agent-driven incidents in the broader 2026 threat landscape also change the motive. DDoS is frequently a distraction while operators chase availability, giving attackers quieter windows for credential misuse or data changes elsewhere. Your DDoS cell still needs a parallel watch on admin paths and identity anomalies during every sustained event.
Map failure modes before you rewrite filters
Start with a capacity inventory that names the resource that dies first under each attack class. Write it as an operations artifact, not a slide.
Volumetric and state exhaustion
SYN floods, ACK floods, and reflection amplify packets. Your first casualty may be firewall session tables, SYN cookies under load, or upstream router control-plane CPU. Record max concurrent sessions, SYN backlog, and the point at which health checks fail even though interfaces still show free bandwidth.
Protocol and handshake pressure
TLS renegotiation storms, HTTP/2 rapid reset style patterns, and oversized handshake attempts burn CPU on terminators. Measure handshakes per second per node, certificate stapling cost, and queue depth on the TLS process. If you terminate TLS at multiple tiers, know which tier collapses first when the scrubber starts forwarding cleaned but still hostile clients.
Application-logic floods
Authenticated search, report export, GraphQL queries, and login endpoints convert cheap requests into expensive work. Rate limits that count requests per IP fail when attackers rotate clean cloud exits or distribute across residential proxies. Prefer budgets tied to account, session, API key, and expensive operation class, with shed policies that protect those paths first.
A pragmatic playbook that starts in peacetime
Build the response you will actually run at 02:00, then rehearse the cutovers that scare people in theory.
1. Declare dual ownership with one incident commander
Network owns transit, scrubbing engagement, and BGP decisions. Application and platform own connection budgets, queue shedding, and feature flags that disable expensive work. One commander decides when cleaned traffic may reach origin. Without that gate, scrubbing teams declare victory and app teams discover the outage alone.
2. Pre-stage scrubbing and signal the cutover
Document the exact trigger to advertise scrubbing prefixes or flip DNS to always-on protection. Include rollback criteria. During drills, time the interval from decision to stable origin latency. Many teams discover their first real event is also their first successful BGP handoff under stress.
3. Protect origin with explicit connection and concurrency caps
Set hard limits on concurrent connections per load balancer backend, pending handshake caps, and per-pod request concurrency. Fail closed on new connections when caps hit, while keeping a reserved slice for health checks and admin break-glass networks. Soft limits that only log leave you with beautiful alerts and a dead site.
4. Retune Layer 7 controls for methods and cost, not only reputation
Inventory which HTTP methods your edge accepts. Default-deny obscure methods on public vhosts unless a named API needs them. As QUERY and similar verbs appear in client ecosystems, decide explicitly whether they are cached, authenticated, or blocked at the edge. Attach cost scores to routes so a flood of expensive operations trips shed rules faster than a flood of cheap static GETs.
5. Keep identity and change monitoring on the side channel
While the DDoS bridge runs, stream privileged login failures, token minting spikes, and unexpected data-modification alerts to a second responder. Recent AI-agent breach reporting shows automated actors can modify personal data while operators stare at traffic graphs. Treat prolonged DDoS as a potential smokescreen by policy, not by improvisation.
6. Rehearse with production-shaped load
Quarterly, run a controlled test that stresses connection tables and one expensive application path behind your normal edge. Validate that scrubbing engagement, origin caps, and status-page updates happen in the documented order. Capture the metrics that should appear on the war-room board: scrubber ingress, origin conntrack, TLS queue, p99 latency, error rate on costly routes, and ticket volume.
What good looks like during the event
When the flood hits, the commander opens a single timeline. Network confirms scrubbing state and residual pps reaching origin. Platform reads connection budget headroom every minute. App owners enable shed mode on report generation and search fan-out if concurrency crosses the pre-agreed line. Comms posts a status update that names customer impact in plain language, even if transit graphs already look calm.
Concrete thresholds belong in your environment, but the decision pattern stays stable. If origin handshake failures rise while scrubber volume falls, you still have an active incident. If expensive endpoints dominate CPU under modest request rates, escalate to application shedding before you chase another ASN block. If admin authentication anomalies rise during the event, spin a parallel incident immediately.
Implementation details that survive contact with vendors
- Ask scrubbing providers for cleaned-traffic characteristics. Request samples or aggregate views of methods, TLS versions, and top paths still forwarded after mitigation. You need that to tune origin defenses.
- Align CDN and origin timeouts. Long edge timeouts against short origin timeouts create retry storms that amplify application load after the attacker already moved on.
- Reserve capacity for synthetic checks from outside the scrubbing path. Otherwise you can believe the site is down when only the monitoring vantage is blackholed.
- Log connection resets with reason codes. Distinguishing maxconn from backend crash from WAF reject shortens the next event by hours.
- Keep a peacetime allowlist for payment webhooks and critical SaaS callbacks. Aggressive emergency ACLs regularly break the revenue path while defending the marketing site.
Takeaways you can act on this week
- Add origin conntrack, TLS queue depth, and per-route concurrency to the primary DDoS war-room board next to Gbps.
- Write a one-page rule that cleaned traffic does not equal recovered service until those origin budgets return to green.
- Default-deny unexpected HTTP methods on public endpoints and assign cost-based shed rules to your top five expensive routes.
- Schedule a scrubbing cutover drill that includes application shedding and a second watcher on identity anomalies.
- Update executive reporting so successful mitigation means restored user transactions, not merely restored transit calm.
DDoS defense earns trust when users can complete work again. Scrubbers remain essential. They clear the road. Your connection budgets, handshake caps, and application shed policies decide whether traffic that survives the scrubber can still take the site down. Build those controls in peacetime, measure them during every event, and keep a second eye on identity while the flood holds the room’s attention.
