Denial of service
Exhaust or disrupt a service so legitimate users cannot use it.
The idea
A denial-of-service attack targets availability. It may overwhelm bandwidth, consume connection state, or exhaust application resources. Distributed denial of service uses multiple sources, which complicates filtering. Defenses depend on the attacked layer and include resilient design, upstream traffic handling, limits, and incident coordination. Normal popularity or a misconfiguration can also create overload, so evidence should distinguish the cause before assigning an explanation.
In practice
A booking site becomes unavailable because expensive requests consume its application workers. Adding raw bandwidth alone may not address the application bottleneck.
A common misunderstanding
Every outage is not an attack, and every denial-of-service event is not solved by the same network rule.
Check your understanding
Why investigate which resource is exhausted?
Think it through: The mitigation must protect the actual bottleneck without unnecessarily blocking legitimate users.
The exhausted resource determines the defense
Availability can fail at several layers. A network may run out of bandwidth, an intermediary may exhaust connection state, or an application may spend excessive time on expensive requests. The visible symptom can be similar: legitimate users cannot complete work. Effective response starts by identifying the constrained resource and the path that consumes it.
Distributed sources can make filtering harder, but not every outage is a deliberate attack. A popular event, a faulty client, a dependency failure, or a misconfiguration can create overload. Compare traffic, service health, recent changes, and business context before assigning intent. Preserve evidence while prioritizing continuity.
A fictional enrollment surge
An academy's enrollment page becomes slow during a campaign. Network volume is moderate, but the database shows repeated expensive requests. The team examines application endpoints, query cost, caching, and request patterns. Simply buying more network bandwidth would not address the observed bottleneck.
Another incident could instead saturate the upstream connection and require provider assistance. Those are different mechanisms and response routes. Capacity expansion can help some situations but may increase cost without removing abuse. Coordinate operational changes and verify their effect on legitimate users, not only on an infrastructure metric.
Diagnose a fictional bottleneck
Use prepared charts for bandwidth, connection count, application latency, and database load. Identify which resource appears constrained and list a benign and an abusive explanation. Propose a proportionate next observation and a continuity action. Do not run load or denial-of-service tests against real services without a defined authorized scope.
Recovery includes confirming that normal workflows function and reviewing whether emergency restrictions remain necessary. A rate limit that stops abuse but blocks students indefinitely is an incomplete outcome. Record the incident's mechanism, decision route, and measured effect so future preparation addresses the actual failure mode.
Keep exploring
References & further reading
Original explanations, with primary references for deeper study.
NIST: An Introduction to Information SecurityMITRE ATT&CK: Network Denial of ServiceMITRE ATT&CK: Endpoint Denial of Service