Disclaimer: This article is intended for educational purposes related to cybersecurity, defensive security, and authorized security testing only. DoS/DDoS testing should only be conducted against systems, applications, networks, or lab environments where explicit authorization has been provided.
Introduction
Denial of Service (DoS) attacks target availability by exhausting a system or network resource, disrupting a service, or exploiting a weakness that causes a service to become unavailable.
A Distributed Denial of Service (DDoS) attack uses multiple distributed sources to achieve the same objective. The attack surface extends from network bandwidth and TCP state to HTTP services, APIs, databases, cloud resources, and vulnerable application components.
One can classify these attacks by the resource they target and the layer at which the disruption occurs. This makes their mitigation easier to understand and apply.
1. Volumetric Attacks
Volumetric attacks attempt to consume the available network capacity of the target. The application and underlying servers may remain operational, but legitimate traffic cannot reach them because the network path is saturated.
Common examples include UDP floods, ICMP floods, and large packet floods.
Mitigation generally needs to occur before traffic reaches the organization's network.
Rate limiting, upstream filtering, CDN-based protection, Anycast distribution, traffic scrubbing, and dedicated DDoS protection services are commonly used.
2. UDP Floods
UDP floods generate large volumes of UDP packets toward a target. Since UDP does not require the same connection establishment process as TCP, attackers can generate significant packet volumes without maintaining conventional sessions.
The resulting impact can include bandwidth exhaustion, packet-processing overhead, and excessive work on firewalls, routers, or servers.
Internet-facing UDP services should be reviewed regularly because unnecessary exposure increases the attack surface.
3. ICMP and Ping Floods
ICMP is essential for several networking functions, but excessive ICMP traffic can consume bandwidth and processing capacity.
A ping flood is a straightforward example where the target receives unusually high volumes of ICMP echo requests.
The appropriate response is generally rate limiting and traffic profiling rather than blindly blocking ICMP.
For larger attacks, filtering at the network edge or through an upstream DDoS mitigation provider is more effective than relying entirely on the destination host.
4. TCP SYN Floods
A TCP SYN flood abuses the connection-establishment process. Large numbers of connection attempts can cause a server or network device to maintain excessive incomplete connection state.
The attack primarily targets connection-handling capacity rather than simply consuming bandwidth.
Common defenses include SYN cookies, connection limits, TCP timeout controls, stateful filtering, load balancing, and upstream DDoS protection.
Monitoring TCP connection states is also important. A sudden increase in incomplete connections can indicate malicious activity, although the traffic must always be evaluated against normal application behavior.
5. TCP Connection and State Exhaustion
DoS attacks can target TCP resources beyond SYN processing. Excessive established, half-closed, or abnormal connections can consume connection tables, memory, file descriptors, worker threads, or other server resources.
This type of attack can affect firewalls and load balancers as well as application servers.
Mitigation includes appropriate connection limits, timeout policies, stateful filtering, load balancing, and sufficient capacity. Network appliances should be monitored independently because an overloaded firewall or load balancer can cause an outage even when backend systems remain healthy.
6. Reflection Attacks
Reflection attacks use third-party systems to generate traffic toward the victim. An attacker manipulates requests so that responses are directed to the intended target.
This allows the attacker to use legitimate Internet services as intermediaries.
Mitigation involves both protecting the victim and preventing internal infrastructure from becoming a reflector. Organizations should restrict unnecessary services, secure exposed protocols, prevent spoofed traffic where possible, and use upstream DDoS filtering.
CISA recommends controls such as stateful UDP inspection, upstream coordination, and measures against source-address spoofing when responding to reflective attacks.
7. Amplification Attacks
Amplification attacks are a form of reflection attack where a small request generates a substantially larger response.
Historically abused protocols include DNS, NTP, CLDAP, SSDP, and Memcached.
The defensive priority is to prevent exposed infrastructure from acting as an amplifier. Unnecessary UDP services should be disabled or restricted, recursive services should not be unnecessarily exposed, and rate controls should be applied where appropriate.
For organizations being targeted, upstream traffic filtering and DDoS mitigation are generally required because amplification attacks can exceed the capacity of the victim's network connection.
CISA provides guidance on UDP-based amplification attacks and recommends controls including ingress filtering and restricting unnecessary UDP services.
8. DNS Query Floods
DNS infrastructure can be targeted directly through excessive query volumes. Attacks can affect authoritative DNS servers, recursive resolvers, or supporting infrastructure.
DNS availability is particularly important because many other services depend on successful name resolution.
Mitigation includes DNS rate limiting, resilient DNS architecture, caching, Anycast distribution, access controls, and dedicated DNS/DDoS protection.
Recursive DNS services should not be unnecessarily available to arbitrary Internet clients. DNS monitoring should also track unusual query volumes, query types, response patterns, and error rates.
9. HTTP Floods
An HTTP flood targets a web application with excessive HTTP requests. The traffic can consist of completely valid HTTP requests, making these attacks more difficult to distinguish from legitimate user activity.
You need to consider which endpoints are being accessed, how expensive those requests are, whether they require authentication, and what backend resources they consume while monitoring.
Mitigation includes WAF controls, request-rate limiting, CDN caching, behavioral analysis, bot detection, authentication, API quotas, and endpoint-specific resource controls.
10. HTTP POST and Request-Processing Attacks
Web applications can be exhausted through large or expensive POST requests, file uploads, searches, form submissions, and similar operations.
A relatively small number of requests can create significant impact when each request triggers heavy application processing or database activity.
Defensive controls include request-size limits, upload restrictions, authentication, validation, rate limiting, processing queues, timeouts, and resource quotas. A single client should not be able to consume a disproportionate amount of application capacity.
11. Slow HTTP and Low-and-Slow Attacks
Low-and-slow attacks attempt to keep connections open for extended periods rather than generating extremely high traffic volumes.
Slowloris is a well-known example. The objective is to occupy connection slots or application workers long enough to prevent legitimate clients from being served.
These attacks demonstrate why bandwidth monitoring alone is insufficient.
Mitigation includes appropriate connection and request timeouts, maximum header and body limits, reverse proxies, connection controls, and application-aware DDoS protection.
12. TLS and Cryptographic Resource Exhaustion
TLS processing requires computational resources. Attackers can attempt to generate excessive connection or handshake activity and consume CPU and memory before normal application processing takes place.
This is particularly relevant when TLS termination occurs directly on application servers.
Mitigation can include TLS termination at appropriately scaled edge infrastructure, connection controls, rate limiting, session reuse, load balancing, and DDoS protection capable of handling encrypted traffic.
13. API Denial of Service
APIs are increasingly important DoS targets because a single endpoint can expose significant backend functionality.
An attacker may repeatedly invoke expensive operations, consume quotas, generate excessive concurrent requests, or abuse endpoints that trigger database queries or downstream services.
Effective API protection includes authentication, per-client rate limits, quotas, concurrency controls, request-size limits, caching, and endpoint-specific restrictions.
14. Database and Query-Based DoS
An application can become unavailable because an attacker repeatedly triggers expensive database operations.
Complex searches, poorly optimized queries, unrestricted filters, large result sets, and report-generation functions can consume database CPU, memory, connections, and I/O.
Mitigation includes query optimization, indexing, pagination, query timeouts, connection-pool controls, caching, application-level rate limiting, and restrictions on computationally expensive operations.
This is an important security consideration because the database may not be attacked directly. The attacker may simply abuse legitimate application functionality that places excessive pressure on the database.
15. Memory Exhaustion
Memory exhaustion can occur when malicious or unusually large requests cause applications to allocate excessive memory.
Possible causes include large uploads, unbounded input, inefficient parsing, oversized responses, memory leaks, or application logic that creates disproportionately large objects.
Mitigation includes strict input-size limits, memory quotas, streaming where appropriate, efficient parsing, process isolation, and resource monitoring.
16. CPU and Computational DoS
Examples include expensive cryptographic operations, inefficient algorithms, complex searches, problematic regular expressions, and application functions with excessive processing requirements.
Mitigation includes algorithm optimization, request throttling, execution time limits, caching, authentication, workload isolation, and resource quotas.
During security testing, consider the relationship between one request and the amount of CPU time it can consume. An operation that consumes disproportionate resources deserves additional controls.
17. Application Crash and Vulnerability-Based DoS
A DoS condition does not always require a flood of requests. A specially crafted input can exploit a vulnerability and cause a service to crash, hang, enter an unstable state, or consume excessive resources.
Potential causes include memory corruption, parser vulnerabilities, malformed input handling, infinite loops, resource leaks, and implementation flaws.
The primary defenses are secure development, vulnerability management, patching, dependency updates, fuzz testing, input validation, isolation, and crash monitoring.
18. Resource Exhaustion
Almost any finite system resource can become a DoS target.
Examples include:
- File descriptors
- Processes and threads
- Database connections
- Network sockets
- Storage
- Message queues
- Application workers
- Cloud quotas
- Authentication sessions
- Logging infrastructure
OWASP specifically identifies resources such as memory, processes, threads, CPU, file systems, and other finite resources as potential DoS targets.
The mitigation principle is consistent: identify finite resources, establish safe limits, monitor consumption, and prevent a single workload or client from monopolizing capacity.
19. Cloud and Auto-Scaling Abuse
Cloud environments introduce an additional DoS concern. Auto-scaling can maintain availability during legitimate demand, but uncontrolled malicious traffic can trigger continuous resource expansion.
The result may be service degradation combined with unexpected infrastructure costs.
Mitigation should combine application-level rate limiting with cloud quotas, scaling boundaries, budget alerts, authentication, caching, and DDoS protection.
Auto-scaling should be treated as a resilience mechanism, not as a replacement for traffic controls.
20. Routing and Infrastructure-Level Disruption
Availability can also be affected at the routing layer. BGP route leaks, prefix hijacking, incorrect routing policies, and other routing failures can prevent legitimate users from reaching a service without a conventional traffic flood.
Network resilience therefore extends beyond firewalls and DDoS appliances.
NIST guidance discusses controls such as RPKI, Route Origin Authorization, route-origin validation, prefix filtering, source-address validation, uRPF, RTBH, and FlowSpec as mechanisms relevant to routing security and DDoS resilience.
Building a Layered DoS Defense
A reliable DoS defense requires controls across multiple layers rather than dependence on a single security product.
At the network edge, upstream DDoS protection, traffic filtering, source validation, rate controls, resilient routing, and traffic scrubbing can prevent large attacks from reaching internal infrastructure.
At the application edge, CDNs, WAFs, API gateways, authentication, behavioral controls, and request limits can reduce malicious traffic before it consumes expensive backend resources.
At the application and database layers, resource quotas, query controls, input limits, concurrency restrictions, caching, and efficient processing reduce the impact of resource-exhaustion attacks.
Infrastructure should provide redundancy, load balancing, capacity planning, monitoring, and controlled scaling. This reduces the likelihood that exhaustion of one component will cause complete service failure.
Monitoring is equally important. Network traffic, connection counts, CPU, memory, application latency, error rates, database connections, and other resource metrics should be correlated to establish whether an incident is volumetric, protocol-based, application-driven, or caused by backend resource exhaustion.
OWASP emphasizes that DoS protection cannot be reduced to a single control. Resilience needs to be considered across application, infrastructure, and network components.
DoS Incident Response
When availability suddenly degrades, the first task is to establish whether the cause is malicious. Infrastructure failures, software defects, configuration errors, unexpected traffic spikes, and dependency failures can produce symptoms similar to a DoS attack.
Once an attack is confirmed, the affected layer should be identified. A volumetric attack may require upstream traffic scrubbing, while an HTTP or API attack may require WAF rules, rate limiting, or endpoint-specific controls.
The incident-response process should already define escalation contacts for the ISP, cloud provider, CDN, and DDoS mitigation provider. During a major attack, waiting until network capacity is exhausted can significantly increase recovery time.
After recovery, the incident should be reviewed from both security and engineering perspectives. The important questions are which resource was exhausted, how quickly the attack was detected, which controls were effective, and where additional resilience is required.
Top comments (1)
The split I'd add sits underneath this whole list: volumetric vs asymmetric-cost. Almost everything here — SYN cookies, scrubbing, CDN absorption, per-IP rate limits — is tuned for volume, where the attacker roughly has to spend what you spend. The ones that actually ruin your week are the asymmetric-cost requests: one well-formed GraphQL query that fans out into thousands of resolver calls, a search with a leading wildcard that table-scans, a regex with catastrophic backtracking, a small JSON/zip that's cheap to send and expensive to parse or decompress. Ten of those exhaust the box, so counting requests per IP never trips — each client looks polite.
The mitigation that generalizes is to budget the server-side cost of a request (query depth/complexity limits, statement timeouts, decompression caps, regex timeouts) rather than its rate, because the expensive path is the one an attacker finds first. Also worth flagging that a few of the network-layer fixes move the bottleneck rather than remove it — SYN cookies trade state for CPU, and per-IP limits fold the moment the source is a botnet or a residential-proxy pool.