A practical guide covering the key measures every internet service provider should adopt to withstand and quickly recover from DDoS attacks.
DDoS attacks are a constant reality for internet service providers. The good news is that much of the impact can be reduced or eliminated with engineering practices applied before an attack happens. This article covers the key measures an ISP should adopt to increase its resilience.
IPv6 is rarely the target of volumetric DDoS attacks. The vast majority of botnets and attack tools still operate exclusively over IPv4, where services and exposed addresses are concentrated. By migrating subscribers, DNS servers, and management interfaces to IPv6, the provider substantially reduces its attack surface.
Another direct benefit is the reduction of costs for cloud mitigation services, which typically charge by the volume of clean IPv4 traffic delivered. Less exposed IPv4 means less attack traffic to process — and a lower bill at the end of the month.
DNS is one of the main amplification vectors and a direct attack target. Two combined features greatly increase resilience: hyperlocal and anycast.
Hyperlocal means keeping a local copy of the internet's root zone inside the ISP's own recursive resolver. This way, even if root servers are unreachable during an attack — or if the provider's link is saturated — internal DNS continues resolving normally for subscribers.
Anycast distributes the same DNS IP address across multiple servers in different locations. When a volumetric attack arrives, it is diluted across points of presence instead of concentrating on a single server, making it much harder to take down.
Static route loops are a silent damage multiplier. When an attack targets a prefix that has a loop, the router processes the same packet repeatedly, consuming CPU and bandwidth simultaneously on both upload and download. The final impact is disproportionate to the attack volume.
Many providers only discover they have loops during a real attack, when it's already too late. The right approach is to conduct a preventive audit of all static routes, ensuring there are no circular dependencies between next-hops and that summary routes point to discard (blackhole) rather than dynamic interfaces.
A routing loop during a DDoS attack can bring down links that would normally handle the traffic just fine. Fix this before an attack exposes the problem.
MikroTik is widely used by ISPs for its excellent cost-effectiveness. However, unlike equipment with dedicated forwarding ASICs, RouterOS processes traffic through the device's CPU. This creates a specific vulnerability point during volumetric attacks.
The most common mistake is creating firewall rules to drop attack traffic directly on the MikroTik. The problem is that even when dropped, each packet still needs to be received and processed by the CPU before being discarded — which can lock up the entire device. The most effective solution is to remove malicious traffic before it reaches the MikroTik, using blackhole at the uplink or FlowSpec.
Point-to-point links between routers using public IPv4 addresses are easy and frequently overlooked targets. An attack directed specifically at an interface IP can overload the router's control plane, dropping all traffic passing through it — even if the link itself has the capacity to absorb the attack.
The solution is simple: use private addresses (RFC 1918) on internal links. For links with peers and upstreams, many operators already accept negotiating interconnections using private address space. What doesn't have a public address cannot be attacked directly.
Detecting a DDoS attack manually and reacting to it is too slow. Tools such as Wanguard and FastNetMon analyze the network's NetFlow and sFlow in real time, identify traffic anomalies, and trigger countermeasures automatically — all within seconds.
Without automation, the process of identifying the attack, locating the affected prefix, reaching the uplink, and configuring the blackhole can take minutes or even hours. With an automated system, this complete cycle happens before most subscribers notice any degradation.
FastNetMon has a functional open-source version that can be the entry point for mitigation automation at no initial cost. For larger environments, Wanguard offers reporting, multi-uplink integration, and scrubbing center support.
BGP communities are the primary mechanism for requesting actions from your upstream during an attack. The most important is the blackhole community: by announcing a prefix with it, the uplink drops all traffic destined for that IP before forwarding it to you. The attack is blocked at the uplink's edge, not inside your network.
When hiring or evaluating an uplink, ask which communities are available. The best ones offer blackhole by origin AS, by geographic region, and by protocol type — enabling surgical mitigation that blocks only malicious traffic without affecting legitimate flows.
GRE tunnels are widely used to forward clean traffic from scrubbing centers back to the ISP. The problem is that GRE encapsulation adds overhead to packets, and without the correct TCP MSS (Maximum Segment Size) adjustment, TCP packets end up being fragmented. Excessive fragmentation causes retransmissions, increases latency, and degrades the user experience — precisely when the network is already under pressure.
Beyond the MSS adjustment, a good practice is to use GRE over IPv6 whenever possible, as it reduces the risk of the tunnel address itself becoming an attack target.
A mitigation tool that has never been tested in production has a high chance of failing at the moment it matters most. Misconfigured systems, broken integrations, or incorrect thresholds only surface when a real attack happens.
Schedule periodic tests outside peak hours: validate that automatic detection is working, that the blackhole is triggered within the expected time, and that the NOC team's contacts and runbooks are up to date. Finding a failure during a controlled test is far better than discovering it at 3 AM during a real attack.
Document an attack response runbook: who triggers what, in which order, with which uplink contacts. Without it, every attack becomes an improvisation.
The practices above cover the needs of most providers well. But there are additional layers of protection that few Brazilian ISPs implement completely and that make a significant difference:
If you have to choose one starting point, start with RPKI. It's free, improves overall internet routing security, and can be enabled on any modern router in under an hour.