How to Stop DDoS Attacks: A Practical Guide

How to stop DDoS attacks

You cannot stop anyone from sending a flood of traffic, so stopping a DDoS attack means keeping your service available while it happens. That takes four things: filter bad traffic before it reaches your servers, absorb what gets through, shrink what an attacker can hit, and know in advance who acts when an alert fires. In practice most of this runs at the network edge, not on your origin server.

A distributed denial-of-service (DDoS) attack uses many machines, often a botnet of hijacked devices, to flood one target so legitimate users cannot get in. See what a DDoS attack is for the basics.

Know the attack type first

The right defence depends on the layer being attacked:

• Volumetric and reflection attacks (layers 3 and 4) try to fill your bandwidth, for example UDP reflection. Only capacity larger than the attack helps, which means an edge network or scrubbing service.
• Protocol attacks (layer 4) exhaust connection state, the classic case being a SYN flood.
• Application-layer attacks (layer 7) send requests that look legitimate, such as an HTTP flood against a search or login endpoint. They need little bandwidth and are hard to tell from a traffic spike. More in application-layer DDoS attacks.

What to put in place

• Put an edge network in front of the origin. A CDN or cloud edge service with built-in DDoS protection absorbs volumetric traffic close to its source. AWS describes this setup, CloudFront with Shield and WAF, in its DDoS resiliency whitepaper.
• Add a web application firewall with rate-based rules. Block known bad patterns and cap requests per client, ideally per IP and per session. Remember that one office or mobile carrier can sit behind a single IP, so set limits by measuring real usage.
• Reduce the attack surface. Keep the origin address private and reachable only from your edge provider, close ports you do not use, and put expensive endpoints (search, login, exports) behind stricter limits.
• Cache what you can. Every request answered at the edge is one the origin never sees, which blunts layer 7 floods against cacheable pages.
• Handle SYN floods in the stack. SYN cookies let a server avoid keeping state for half-open connections, at the cost of compatibility with some TCP options. RFC 4987 describes SYN cookies, filtering and the other countermeasures with their trade-offs.
• Scale and alert. Auto scaling buys time for application-layer traffic, but also scales your bill, so pair it with alerts and caps.
• Write a response plan. Decide who confirms an attack, who contacts your CDN, DNS or ISP, and who communicates with customers. CISA's advice is the same: have a plan for communication, mitigation and recovery, and contact your network administrator and ISP to confirm what you are seeing.

Example: an HTTP flood on a search page

A shop sees its search endpoint time out. Bandwidth is normal, but the origin is at full CPU and the request log shows thousands of search calls per minute from a few hundred IPs. The fix is layered: serve cached results for repeated queries, add a rate-based rule on the search path, challenge clients that exceed it, and alert on request rate per path so the next flood is caught in minutes.

Common mistakes

• Defending at the origin only. A single server or link can be saturated, so edge protection has to come first.
• Null-routing your own IP. It stops the flood by making your service unreachable, which is what the attacker wanted. Use it only as a last resort.
• Ignoring layer 7. Network-level protection does not stop requests that look like normal users.
• No baseline. Without normal request rates per path, you cannot tell an attack from a sale or a viral post.
• Setting up protection mid-attack. Onboarding a provider during an incident is slow. Have the contract, DNS and contacts ready beforehand.

DDoS defence, load testing and monitoring

Load testing answers a different question from a DDoS simulation. Use it to learn how much legitimate traffic your own system handles, where it degrades first and whether your rate limits and autoscaling kick in the way you expect. Start with load testing vs stress testing, and see API rate limiting causes for how limits show up as 429 responses in a test. LoadFocus load testing runs HTTP tests against your own site or API from cloud regions, which suits this kind of capacity and rate-limit check.

Do not point any load tool at a system you do not own, and do not treat a load test as a DDoS exercise. Real DDoS simulations are governed by provider rules: AWS, for example, allows them only through pre-approved partners under set volume limits, and its policy forbids originating the traffic from an AWS resource. Check your CDN's and cloud provider's policy and tell them before any high-volume test.

Afterwards, keep watching: synthetic checks from several regions plus alerts on error rate and latency are often the first sign of an attack from the outside.

FAQ: stopping DDoS attacks

Can I stop a DDoS attack on my own?

Only small ones, with rate limits and IP blocks. Anything that fills your bandwidth or exhausts your origin needs an edge network or scrubbing service with more capacity than the attack.

Will a CDN stop every DDoS attack?

No. It absorbs most volumetric and protocol attacks at the edge, but application-layer floods also need WAF rules, rate limits and caching tuned to your traffic.

How do I know I am under a DDoS attack?

Typical signs are a site that is suddenly slow or unreachable, a jump in requests or errors, and traffic from many sources at once. CISA lists unusually slow performance and unavailable websites as symptoms, and notes that attackers sometimes use an attack as a distraction.

Is rate limiting enough?

It helps against small floods and abusive clients, but it will not stop a distributed attack from thousands of sources or a volumetric flood. Use it as one layer.

Should I pay a ransom?

No. Payment does not guarantee the attack stops, and it marks you as a paying target. Report the demand and activate your mitigation plan.

Can I test my DDoS protection?

Only within your provider's rules, usually through an approved partner and with prior coordination. For capacity and rate limits, a controlled load test against your own system is the safer way to start.