DDoS attacks: incident triage and practical resilience

A DDoS is an availability attack. The attacker is trying to make a service unusable by exhausting bandwidth, connection state, or application resources. Most DDoS response is not “hacker hunting”. It is traffic engineering, provider escalation, and making sure a noisy outage does not hide a separate intrusion.

Key idea: you rarely “block a DDoS” on your own server. You reduce impact by pushing mitigation upstream and designing services to degrade predictably.

What a DDoS is, and what it is not

DDoS stands for distributed denial-of-service: many sources generating traffic or requests to overwhelm something. It is not automatically a data breach. It is also not proof that your website was “hacked”, even though the business impact can be severe.

That distinction matters because the wrong response wastes time. A breach response starts with access control, containment, and credential rotation. A DDoS response starts with traffic shaping, provider escalation, and keeping critical functions alive.

Common DDoS types (in plain terms)

• Volumetric: raw bandwidth floods that saturate links.
• Protocol/state exhaustion: attacks that burn connection tables or intermediary state.
• Application-layer: requests that look “legitimate” but are designed to exhaust CPU, database, cache, or third-party API quotas.

Run two tracks at once: restore availability and check for intrusion

During a real incident, you want parallel tracks with clear ownership. The availability track keeps the business running. The security track checks whether the outage is cover for something else.

Availability track: practical escalation sequence

• CDN/WAF first: if you are using a CDN or edge WAF, enable their DDoS posture and add rate limiting for obvious hot paths (login endpoints, search, expensive API calls).
• DNS second: if DNS is failing, move quickly. Use a provider that can absorb volumetric events, and pre-stage TTLs so you can move in minutes, not days.
• Origin hardening: protect the origin by restricting direct access (only allow CDN egress IPs), and separate admin interfaces from public traffic.
• ISP or cloud escalation: if the pipe is saturated, only your upstream can help. Ask for scrubbing or blackholing for specific targets when needed.

Security track: “no-breach check” that does not slow mitigation

• Review authentication logs for brute force, password spraying, and credential stuffing.
• Check for unusual admin logins, new API keys, unexpected OAuth app authorizations, and changes to recovery email/phone on critical accounts.
• Confirm there were no emergency firewall rule changes or “temporary” exceptions that opened sensitive ports.
• If anything looks off, switch into a broader incident workflow: how to check if you have been hacked.

Do not: rotate all passwords during an active availability event unless you have evidence of intrusion. You can lock yourself out of the systems you need to restore service.

Design choices that reduce DDoS impact

DDoS resilience is mostly decided before the incident. The goal is to make it cheap to absorb abuse and expensive for traffic to reach your most fragile components.

Keep expensive work behind cheap checks

• Put caching in front of pages and endpoints that can be cached safely.
• Rate-limit by IP and by user identity where possible, with separate limits for anonymous traffic.
• Challenge or throttle traffic that hits known-abuse patterns (high request concurrency, repeated login attempts, obvious bot fingerprints).
• Move expensive “fan-out” requests off the synchronous path (queues, async jobs) so a spike does not cascade.

Protect the origin so the edge can do its job

• Restrict origin access so attackers cannot bypass the CDN/WAF and hit your server directly.
• Separate public services from admin panels and VPN-only tools.
• Use separate credentials and separate accounts for infrastructure management so an outage does not become a takeover.

Plan for degraded modes

When under pressure, “partial service” is often the correct target. Examples of acceptable degraded modes:

• Keep checkout and login alive while disabling non-essential features.
• Serve a static status page while APIs are restricted.
• Disable search or user-generated content ingestion temporarily to protect databases.

Incident communication that reduces damage

DDoS events create uncertainty. Customers do not need details about packets. They need clarity about what works, what does not, and when you will update next.

• Maintain a status page on separate infrastructure from your primary website.
• Publish timestamped updates on a predictable cadence.
• Do not speculate publicly about attribution during the event.

A small-business DDoS readiness baseline

You do not need an enterprise SOC to get most of the benefit.

• Use a reputable CDN/WAF in front of public services that matter to revenue.
• Use managed DNS with DDoS resistance and pre-staged failover.
• Keep an emergency contact list for your hosting, ISP, DNS, and domain registrar.
• Log authentication events and admin actions, and retain logs long enough to compare “before and during”.
• Document who can approve emergency controls (blocking countries, disabling endpoints, scaling capacity) so decisions are not ad hoc.

If you are building broader fundamentals alongside availability work, start with: how to protect your business from hackers.

DDoS risk becomes manageable when mitigation is upstream, origins are protected from bypass, and you have a runbook for degraded operation. That does not guarantee zero downtime, but it turns an attacker’s “chaos lever” into a routine operational incident with clear escalation paths and predictable recovery.