How to Stop a Denial of Service Attack
A denial of service attack aims to make a service unavailable by overwhelming it with traffic or exploiting a weakness that consumes critical resources. Stopping one is not a single product decision; it is a layered process that spans detection, containment, mitigation, and recovery. The right approach depends on whether you are defending a small website, a SaaS platform, or an on-premises application, and on whether the attack is volumetric, protocol-based, or application-layer. This guide walks through the controls that actually matter, what each one costs in complexity and expense, and how to choose them without treating security as a feature checklist.
More from this site
Keep reading the latest coverage
Know What You Are Fighting
Different attack shapes require different defenses, and misidentifying the vector leads to wasted spending. The table below maps the common denial of service families to their primary impact and the controls that address them.
| Attack Type | How It Works | Primary Impact | Best Defenses |
|---|---|---|---|
| Volumetric UDP flood | Massive packet volumes from botnets or amplification | Network pipe saturation | Upstream scrubbing, rate limiting, Anycast |
| SYN flood | Half-open TCP connections exhaust state tables | Server resource exhaustion | SYN cookies, firewalls, edge rate limits |
| HTTP flood | High volume of seemingly legitimate requests | Application server overload | WAF, bot management, request throttling |
| Slowloris / slow POST | Holds connections open with partial requests | Connection table exhaustion | Timeouts, connection limits, reverse proxies |
| DNS amplification | Spoofed queries to open resolvers | Bandwidth saturation | DNS rate limiting, source validation |
| Application-layer logic abuse | Targeted expensive queries or workflows | CPU or database saturation | Behavioral analysis, input validation, caching |
Build Detection Into Your Baseline
You cannot stop what you do not see. Start by establishing normal traffic patterns for bandwidth, request rates, connection counts, and error ratios per endpoint. When a denial of service attack begins, the deviation from that baseline is usually the first signal. Use netflow or packet telemetry at the edge, application performance monitoring for request latency and error spikes, and log aggregation to correlate events across services. The goal is early detection with low false positives, because alert fatigue causes real incidents to be ignored.
Network and Edge Controls
The first line of defense is at the network boundary, where you can discard traffic before it reaches your infrastructure.
- Upstream scrubbing services: Cloud providers and specialized DDoS mitigation firms can divert traffic through cleaning centers that drop malicious packets and pass legitimate traffic to your origin. This is the most effective countermeasure against large volumetric attacks but depends on your provider's capacity and your willingness to route traffic through their network.
- Anycast network topology: Distributing your service across multiple geographic points absorbs traffic spikes by spreading load, though it does not replace filtering and can increase complexity.
- Firewalls and routers with rate limiting: Thresholds on packets per second, connection rates, and bandwidth per source can blunt floods, but poorly tuned limits block legitimate users during traffic surges.
- Blackhole and null-route policies: As a last resort, dropping all traffic to a targeted IP stops the attack but also stops your service. Use this only when the affected segment is isolated and the business impact is understood.
Application and Service-Level Defenses
Once traffic reaches your application layer, controls shift from volume to intent.
- Web application firewall (WAF): A WAF can block known attack patterns, filter abusive user agents, and challenge suspicious requests with CAPTCHAs or JavaScript puzzles. It is strongest against HTTP floods and protocol abuse, but it can be bypassed by novel attack logic or by mimicking genuine user behavior.
- Rate limiting and throttling: Per-IP, per-session, or per-endpoint request caps reduce the impact of floods. The trade-off is that aggressive limits degrade performance for real users during legitimate spikes, such as product launches or breaking news events.
- Connection and session management: Timeouts for idle connections, caps on concurrent sessions, and SYN cookies mitigate resource exhaustion attacks like Slowloris and SYN floods without requiring a full content inspection stack.
- Caching and CDN fronting: Serving static assets and cached responses from edge nodes reduces the load on origin servers, but dynamic or personalized content remains exposed to application-layer attacks.
Incident Response and Containment
When a denial of service attack is confirmed, containment decisions must balance service availability with business risk.
- Activate your DDoS response plan: Pre-defined playbooks that specify escalation paths, communication channels, and mitigation actions reduce decision latency during a high-pressure incident.
- Coordinate with your ISP or cloud provider: They can apply upstream filtering or reroute traffic, but response times vary and you should test these relationships before an attack occurs.
- Divert or shed traffic: Temporarily moving services to a scrubbing endpoint or reducing feature scope can preserve core functionality while under attack.
- Preserve evidence: Logs, packet captures, and flow data support post-incident analysis and any legal or insurance follow-up, but collecting them during a live attack can consume resources you need for mitigation.
Recovery and Post-Incident Review
Stopping the immediate attack is only half the job. Recovery means restoring normal service, verifying that no persistent access or data exposure occurred alongside the disruption, and updating defenses based on what the attack revealed. Review your detection timelines, false positive rates, and the effectiveness of each mitigation step. Use the findings to adjust thresholds, tune WAF rules, and refine runbooks. A denial of service attack is often a distraction for a deeper intrusion, so treat the incident as a trigger to re-evaluate your overall security posture rather than an isolated availability problem.
What Stops a Denial of Service Attack Depends on Your Setup
Small sites with limited engineering capacity benefit most from upstream scrubbing and CDN-based protection because they externalize the hard problem. Larger organizations with on-premises infrastructure can invest in dedicated hardware, traffic shaping, and in-house threat intelligence, but they carry the operational burden of tuning and maintaining those systems. The common thread across all approaches is that no single control is sufficient; detection, filtering, application resilience, and incident response must work together. The cost of each layer is not just money but complexity, and the right balance is the one your team can operate reliably under load.