On this page
Key points
- React at the right layerThe priority is to identify whether saturation hits the link, PPS, server resources, an application layer or routing.
- Stop without going offlineGood mitigation filters the attack while preserving legitimate traffic and service continuity.
- Prepare the post-attack architectureAfter the emergency, the goal is to build a durable path: BGP, tunnels, specialised proxy or protected transit.
Understand what actually needs to be stopped
A DDoS attack attempts to make a service unavailable by sending more traffic, packets or requests than the infrastructure can process. The issue may be volumetric, with tens or hundreds of Gbps. It may be packet-rate oriented, with many small packets exhausting CPU, buffers or queues. It may also be application-specific: HTTP, TLS, login requests, UDP queries, game handshakes or API endpoints.
The first mistake is treating every attack the same way. A blackhole can save a network but disables the target. A local firewall rule is useless if the link is already full. To stop a DDoS attack properly, identify the target, protocol, volume, PPS, traffic direction and the exact point where failure starts.
- Volume
- The access link or transit saturates before your firewall can help.
- PPS
- Packet rate exhausts CPU, queues, interrupts, buffers or filtering logic.
- Application
- The service fails because the attack partially imitates real users.
Why a clean response changes everything
During an attack, every minute matters, but a brutal response can make the outage worse. Blocking too broadly can cut legitimate customers. Changing DNS without a plan creates cache issues. Moving routes without a return strategy makes troubleshooting harder. The goal is to reduce hostile traffic while keeping useful traffic alive.
For a company, hoster or game server, the cost is not only bandwidth. It includes lost customers, support tickets, refunds, reputation and time spent improvising. A clear mitigation method brings services back faster and turns the incident into a stronger architecture: upstream capacity, layered filtering, observability and clean handoff.
- Separate network saturation from a server bug.
- Protect real users instead of cutting everything.
- Keep useful traces for rule improvement.
- Plan clean traffic delivery back to the customer infrastructure.
Solutions that can stop a DDoS attack
The right solution depends on the attack type and your network control. If traffic saturates your link, action must happen upstream: transit provider, scrubbing center, FlowSpec, temporary blackhole or a protected network able to absorb the volume. If the link holds but the server suffers, better L3/L4 filtering, a router VM, a dedicated filtering server or more precise rules may be enough.
For web services, an HTTP/TLS reverse proxy can stop many application floods. For game servers, the response must respect the protocol: UDP, queries, handshakes, ports, latency and false positive tolerance. Networks with an ASN can use BGP to announce prefixes through protection. Customers without BGP can often start faster with GRE, IPIP, VXLAN or protected IP delivery.
| Solution | When to use it | Limit to know |
|---|---|---|
| Blackhole | Extreme emergency to save the network | The target service goes offline |
| FlowSpec | Reduce a simple pattern upstream | Can create false positives if too broad |
| Protected IP transit | Protect prefixes or exposed services | Requires clean network integration |
| GRE/IPIP/VXLAN tunnel | Protect an existing server without moving everything | Return path and MTU must be controlled |
| Web/gaming reverse proxy | Protect a precise protocol | Does not always replace volumetric mitigation |
Move from emergency to controlled mitigation
A serious approach first reduces saturation at the highest useful layer, then moves toward more precise rules. Massive obvious traffic should be reduced before it reaches your machines. Then filtering logic can inspect protocols, ports, packet length, flags, connection behavior or application signals.
Identify
Find whether the outage comes from the link, PPS, firewall, server or application layer.
Relieve
Move filtering upstream when volume exceeds local capacity.
Deliver
Return clean traffic with the right model: BGP, GRE, IPIP, VXLAN, xCo or proxy.
Stabilise
Measure false positives, tune rules and build a playbook for the next attack.
Concrete example: an exposed server is hit by a UDP flood
Imagine a game server or public UDP service. Players see timeouts, monitoring shows a sharp traffic spike and server CPU becomes unstable. A local firewall rule may help against small noise, but if the link is saturated, unwanted packets have already consumed capacity before being dropped. The correct decision is to filter before the customer link.
A clean scenario is to route traffic through a protected layer, apply upstream reduction, then deliver legitimate traffic back to the server through a tunnel or protected IP. If the service is FiveM, Minecraft or another game, filtering must account for protocol behavior and latency. The expected result is a clear path: attack absorbed upstream, useful traffic preserved, origin server less exposed.
Common mistakes during a DDoS attack
Panic often leads to bad decisions. Many teams change port, DNS or provider without understanding the vector. Others stack local rules until they block their own users. Some wait for the hoster to do something although the contract does not cover that attack profile or volume.
Another mistake is confusing marketing capacity with real design. Effective protection must explain where traffic is absorbed, how rules are decided, how clean traffic returns, what limits exist and how intervention works during the incident. Without that, you may simply move the problem.
- Expecting a local server to filter an attack that already saturates the link.
- Blocking an entire country or protocol without measuring customer impact.
- Using blackhole as the only protection strategy.
- Forgetting MTU, return routing or asymmetry after tunneling.
- Keeping no usable traces to improve mitigation later.
FAQ: how to stop a DDoS attack
What should I do first during a DDoS attack?
Identify where saturation starts: network link, firewall, server, CPU, PPS or application layer. Without that, the response may be too broad or ineffective.
Can a local firewall stop a DDoS attack?
Yes for small floods or simple patterns, but not if the link is already saturated. In that case filtering must happen upstream.
Is blackhole a good solution?
It is an emergency measure to protect the rest of the network, but it disables the target service. It should not be the main strategy if availability matters.
Do I need BGP to be protected?
No. BGP is ideal for prefixes, but protection can also use protected IPs, GRE, IPIP, VXLAN, cross-connect or reverse proxy delivery.
