logo

Denial-of-Service (DoS & DDoS)

Category:

Network

Summary:

How DoS and DDoS attacks exhaust bandwidth, connections, or CPU to knock a service offline, and how to build resilience against them.

A denial-of-service (DoS) attack overwhelms a target’s bandwidth, connection table, or application resources until legitimate users can’t get through. A distributed denial-of-service (DDoS) does the same thing from many hosts at once, usually a botnet. Unlike man-in-the-middle or SQL injection, the goal here is availability, not access. In a penetration test, DoS testing is normally out of scope — it’s only performed with explicit, separate authorization because of the outage risk.

How It Works

Volumetric floods (UDP, ICMP, or reflection/amplification via DNS or NTP) simply saturate bandwidth. Protocol and state-exhaustion attacks like SYN floods fill a server’s connection table without completing handshakes. Application-layer attacks — an HTTP flood or a slow-drip attack like Slowloris — exhaust web server resources with comparatively little traffic. Any of these can run from a single host or, as a DDoS, from thousands at once.

Want to save time on reporting?

Let PentestPad generate, track, and export your reports - automatically.

logo-cta

How to Detect It

  • Compare traffic volume against a known baseline and alert on sudden spikes.
  • Watch for a lopsided SYN/ACK ratio, a sign of a SYN flood in progress.
  • Monitor connection-table saturation on load balancers and firewalls, and pull telemetry from your upstream provider or CDN.

How to Defend Against It

  • Route traffic through upstream scrubbing or a CDN that absorbs volumetric floods before they reach origin.
  • Apply rate limiting and SYN cookies to blunt connection-exhaustion attempts.
  • Use anycast and autoscaling for resilience, close off reflectors with BCP38 egress filtering, and keep an incident runbook ready before you need it.

Validating Your Defenses

Resilience testing against DoS is only ever run with explicit, separate authorization and tight coordination — never as a default part of a pentest. Document every threshold, mitigation trigger, and time-to-recover so it lands in the pentest report rather than a postmortem written from memory.