A distributed denial-of-service attack overwhelms a service from many sources so legitimate users cannot reach it. Some attacks saturate network capacity, some exhaust connection-handling infrastructure, and others imitate costly application requests. The objective is availability loss—not necessarily entry into the system or theft of data.
“Distributed” is important. Blocking one address is ineffective when traffic arrives from thousands of compromised devices, rented servers, open proxies, or reflected services.
DoS versus DDoS
A denial-of-service attack can originate from one source. A DDoS attack uses multiple sources or appears distributed through reflection. Both target a resource limit: bandwidth, packet-processing state, CPU, memory, connection pools, threads, database capacity, third-party quotas, or a human-operated dependency.
CISA and the FBI group denial attacks by the resource or layer they overwhelm, including network bandwidth, protocol resources, and application resources.[1]
Three broad attack classes
Volumetric attacks
These send enough traffic to fill links before requests reach the application. Reflection and amplification abuse internet services that return a larger response to a small request while directing that response toward the victim.
Defense requires upstream capacity and filtering. An organization cannot filter a flooded 1 Gbps link using a firewall behind that same link.
Protocol and state exhaustion
These exploit how network devices and servers track connections or process packets. The traffic volume may be smaller, yet firewalls, load balancers, or operating-system tables run out of state.
Mitigations include stateless validation where appropriate, connection controls, resilient network stacks, distributed edges, and specialized scrubbing.
Application-layer attacks
Requests look more like legitimate web or API traffic but target expensive functions: searches, dynamic rendering, authentication, report generation, large downloads, or database queries. A relatively small botnet can create high backend cost if each request triggers substantial work.
Rate limiting helps, but naive limits can block real users behind shared networks. Effective defense combines behavioral signals, caching, request cost, identity, challenges, and application design.
Why “just block the IPs” fails
Addresses change, can be spoofed in some attack types, and may belong to innocent infected devices or shared providers. Large blocklists also consume resources and can create collateral damage. Defenders need aggregate patterns, upstream mitigation, and controls close to the traffic source or globally distributed edge.
A layered DDoS defense
Architecture
Use geographically distributed delivery, multiple availability zones, redundant DNS, tested failover, and providers with sufficient upstream capacity. Remove single dependencies that scaling the web tier cannot fix.
Edge controls
Content delivery networks and DDoS mitigation services can absorb and filter traffic before it reaches the origin. Hide and restrict origin addresses so attackers cannot bypass the edge.
Application efficiency
Cache safe responses, bound query complexity, paginate results, queue expensive work, set timeouts, use circuit breakers, and apply quotas to costly features. A fast failure can be healthier than an unbounded queue that collapses everything.
Detection and operations
Baseline normal traffic, collect network and application metrics, define escalation contacts, and prearrange provider procedures. During an event, teams need to distinguish attack traffic from a legitimate surge, determine the exhausted resource, and change controls without guessing.
Business continuity
Prepare status communication, alternate customer channels, manual procedures, and dependency contacts. A technically small outage can become a large trust problem when users receive no reliable information.
DDoS is not always a “huge traffic” problem
An attack that saturates a database connection pool may use little bandwidth. A low-rate request pattern can hold resources open. Abuse of a third-party API can exhaust a quota. Defenders should monitor service-level symptoms—latency, errors, saturation, queue depth, dependency failures—not traffic volume alone.
A basic response playbook
- Confirm impact and rule out deployment, dependency, routing, or certificate failures.
- Identify the constrained layer and resource.
- Engage the hosting, transit, CDN, or mitigation provider.
- Protect the origin and critical management paths.
- Apply targeted filters, challenges, caching, or temporary feature restrictions.
- Watch collateral damage and attacker adaptation.
- Communicate through an independent status channel.
- Preserve metrics and decisions for the review.
Do not make random network changes under pressure. Record each mitigation, expected result, and rollback condition.
Is a DDoS attack a distraction?
Sometimes availability pressure coincides with fraud, intrusion, or extortion, but do not assume a second attack without evidence. Maintain visibility into authentication, privileged activity, data movement, and configuration changes while the availability team mitigates traffic.
The bottom line
DDoS defense is capacity plus control plus preparation. Distributed edges handle scale; protocol defenses preserve infrastructure; efficient applications limit per-request cost; and a rehearsed response keeps technical mitigation aligned with business continuity.