DDoS

A DDoS attack denies service by exhausting a resource. Attacks fall into three broad classes. Volumetric attacks saturate the target’s bandwidth, often using amplification, where a small request to a third-party service (a misconfigured DNS or NTP server, for example) returns a much larger reply aimed at the victim. Protocol attacks exhaust connection-tracking state in firewalls, load balancers or the server’s network stack. Application-layer attacks send requests that look valid but are expensive to serve, draining CPU or database capacity with far less traffic. The “distributed” part is what defeats simple defences: the traffic comes from many hosts, frequently a botnet, so blocking one source does nothing.

The failure is usually a plan that assumes the attack looks like a flood. Volumetric floods are the loudest but often the easiest to absorb with upstream scrubbing. The attacks that hurt in practice are application-layer: a modest request rate against an unauthenticated, expensive endpoint (a search, a report, a login) can take a service down while the bandwidth graph stays flat, so the monitoring never trips. From the attacker’s side, the cheapest win is finding the one endpoint that does heavy work per request and has no rate limiting, then sending just enough traffic to keep it saturated.

DDoS resilience is assessed as an architecture question rather than a single test: is there upstream capacity or scrubbing, does a CDN absorb volumetric traffic, are expensive endpoints rate-limited and cache-friendly, and does the incident process include the provider who would actually mitigate. In an application assessment we flag unauthenticated endpoints that do disproportionate work, because those are the cheapest application-layer targets. A WAF is recorded as a partial control, useful against some application-layer patterns and largely irrelevant to a volumetric flood.