DDoS Mitigation: Staying Online Under Attack

Availability is a security property too

Most security work focuses on keeping attackers out of your data. A distributed denial-of-service (DDoS) attack ignores your data entirely. It does not try to break in — it tries to make sure your legitimate customers cannot get in either, by overwhelming your infrastructure with more traffic or requests than it can handle. The site goes dark, the API stops responding, the transactions stop clearing, and the business loses revenue and trust for every minute it stays down. Availability is one of the three pillars of security for a reason, and DDoS is the attack aimed squarely at it.

The economics favor the attacker. Launching a large attack is cheap and increasingly commoditized — booter and stresser services rent attack capacity by the hour, and vast botnets of compromised IoT devices provide the firepower. Defending is harder, because absorbing or filtering an attack that can exceed the capacity of your entire internet connection is not something you can do from inside your own data center. That asymmetry is why DDoS mitigation is fundamentally about scale and architecture, decided long before an attack begins.

Three kinds of attack, three kinds of defense

"DDoS" covers a family of techniques that attack different layers of the stack. They require different defenses, and a mitigation that stops one does nothing for another.

• Volumetric attacks aim to saturate your bandwidth by flooding the pipe with sheer volume — UDP floods, ICMP floods, and especially amplification/reflection attacks that abuse open DNS, NTP, or memcached servers to multiply a small spoofed request into a massive response aimed at you. These are measured in bits per second and are the "clog the highway" category. You cannot filter your way out of a flood larger than your link; the traffic has to be absorbed upstream.
• Protocol attacks exhaust the state tables of network devices — firewalls, load balancers, servers — rather than the bandwidth. The classic SYN flood opens half-connections and never completes them, filling the connection table until no legitimate session can be established. Measured in packets per second, these target the machinery rather than the pipe.
• Application-layer (Layer 7) attacks are the subtlest. Instead of brute volume, they send a modest number of requests that look legitimate but are expensive to serve — hammering a search endpoint, a login page, or a costly database query. An HTTP flood can take a site down with traffic small enough to slip past bandwidth-based defenses, because each request is individually plausible. These are the hardest to distinguish from a genuine traffic spike.

Because a serious adversary may combine all three, effective defense has to operate at every layer at once. There is no single appliance that covers the whole family.

Figure: DDoS defense is layered — volumetric floods are absorbed in the cloud, protocol attacks are filtered at the edge, and application-layer floods are inspected closest to the app, because no single tier stops all three.

You cannot absorb a flood from inside your own walls

The single most important architectural fact about DDoS defense is that the biggest attacks must be handled before the traffic reaches your infrastructure. If an attack delivers more traffic than your internet connection can carry, no on-premises firewall or scrubbing box can help — the link is already saturated by the time packets arrive. The defense has to live upstream, where there is enough capacity to soak it up.

That upstream layer takes a few common forms, usually combined:

• Cloud scrubbing services with globally distributed capacity far larger than any single victim's link. Traffic is routed through the provider's network, malicious flows are filtered out, and only clean traffic is passed to your origin. This is the workhorse defense against volumetric attacks.
• Content delivery networks and anycast. Distributing your presence across many global points of presence via anycast spreads an attack across the whole network instead of concentrating it on one location, so no single node is overwhelmed. A CDN also absorbs much of the load by serving cached content from the edge.
• Always-on versus on-demand. Always-on protection filters continuously and reacts instantly but runs all your traffic through the scrubbing layer at all times. On-demand engages only when an attack is detected, which is cheaper but introduces a detection-and-reroute delay during which you are exposed. For anything latency-sensitive or business-critical, always-on is the safer default.

The practical implication is that DDoS resilience is an architecture decision made in advance. Scrambling to sign up for scrubbing while an attack is already underway means rerouting under fire, and every minute of that is downtime.

Layer 7 is where it gets hard

Volumetric defense is largely a capacity problem, and the industry has enormous capacity. Application-layer attacks are a harder, more interesting problem, because the malicious requests are designed to be indistinguishable from real users. Stopping them without blocking legitimate customers requires inspecting behavior, not just volume:

• Rate limiting caps how many requests a single source can make in a window — effective against crude floods, but easily evaded by attacks distributed across thousands of IPs.
• Behavioral and reputation analysis profiles what normal traffic looks like and flags sources deviating from it, and draws on threat intelligence about known-malicious infrastructure and botnet nodes.
• Challenge mechanisms — CAPTCHAs, JavaScript challenges, proof-of-work puzzles — cheaply separate automated clients from real browsers, since most attack tooling cannot solve them. The tradeoff is friction for genuine users, so challenges are applied selectively under suspicion rather than to everyone.
• Web application firewall integration. A web application firewall sitting in front of the app filters malicious request patterns and enforces per-endpoint limits, giving you finer control over the expensive routes attackers target.

Because Layer 7 attacks blend into legitimate traffic, tuning matters: too aggressive and you block paying customers, too loose and the attack gets through. This is ongoing adjustment, not a set-and-forget rule.

Have a plan before the traffic arrives

Technology is only half of staying online. Organizations that weather DDoS attacks have decided how they will respond before one starts, and folded it into their broader incident response planning. The elements that matter:

1. Know your baseline and get alerted on deviation. You cannot recognize an attack if you do not know what normal traffic looks like. Continuous monitoring that flags anomalous spikes buys you the early warning that determines how much damage an attack does.
2. Define the runbook and the contacts. Who declares an incident, who engages the mitigation provider, who updates customers. Under attack, at 2 a.m., is the wrong time to be looking up a support number.
3. Harden the origin and hide it. Keep your true origin IPs off the public internet behind the scrubbing or CDN layer, so an attacker cannot bypass your protection by hitting the origin directly. Rightsize timeouts and connection limits so protocol attacks find less to exhaust.
4. Build in redundancy. Multiple providers, distributed capacity, and graceful degradation — serving a reduced experience beats serving none — turn an outage into a slowdown.
5. Rehearse. Test the plan so the response is muscle memory, not improvisation.

Where to start

Start by understanding your exposure: which internet-facing services would hurt most if they went dark, and whether anything stands between them and a large flood today. Put always-on upstream protection in front of the business-critical ones, hide your origin behind it, and add application-layer and network security controls for the endpoints attackers can hit cheaply. Then write the runbook and rehearse it, because the plan you never tested is the plan that fails at 2 a.m.

intSignal designs and operates DDoS resilience as part of a managed network and security practice: upstream scrubbing, edge and application-layer defenses, origin hardening, and a rehearsed response plan. Talk to our team and we will assess how your critical services would hold up under a serious attack — before one tests them for you.