DDoS & flood protection
A flood attack fills a link or a server until real traffic cannot get through. Defense works in layers: detect the attack quickly, drop the bad traffic as close to the edge as possible, and send the rest of the traffic on its way. Our team designs these layers for networks that run their own address space and for businesses that rely on a scrubbing provider.
What we do
- XDP and eBPF filters for volumetric and SYN floods on Linux hosts
- Flow-based detection with FastNetMon and sFlow, NetFlow or IPFIX
- RTBH with the BLACKHOLE community (RFC 7999) toward upstream providers
- BGP FlowSpec (RFC 8955) rules for narrow, automatic filtering
- Diversion to cloud scrubbing over BGP and GRE or IPsec tunnels
- Always-on and on-demand scrubbing designs
- Attack runbooks, escalation contacts and tabletop tests
- Post-attack review and rule tuning
On our own hosts we use XDP and eBPF, which run packet filters inside the Linux network driver path before the normal network stack. Upstream we use BGP: remotely triggered blackholing with the BLACKHOLE community (RFC 7999, 65535:666), and BGP Flow Specification (RFC 8955) to push narrow filters to routers. Detection tools such as FastNetMon tie the two together.
For attacks larger than a business link, traffic is diverted to a cloud scrubbing service over BGP and tunnels, then returned clean. We plan that path, test it before it is needed and document who triggers it.
Leading platforms we work with
- FastNetMon
- Cloudflare Magic Transit
- Akamai Prolexic
- AWS Shield Advanced
- Arbor / NETSCOUT
- Radware
- Imperva
- Corero
Platforms and practices
- XDP & eBPF packet filtering
- BGP FlowSpec
- Remotely triggered blackhole (RTBH)
- uRPF source filtering
- Anycast scrubbing diversion
- GRE tunnel return paths
- sFlow / NetFlow / IPFIX detection
- Rate limiting & SYN protection
References
- FastNetMon (vendor site)
- Cloudflare Magic Transit documentation
- Akamai Prolexic (vendor page)
- AWS Shield (vendor page)
- Linux kernel documentation: AF_XDP and XDP redirect
- RFC 8955: Dissemination of Flow Specification Rules
- RFC 7999: BLACKHOLE Community
- RFC 5635: Remote Triggered Black Hole Filtering with uRPF
Sources last checked .
Product names are trademarks of their owners and are listed to describe our experience; they do not imply endorsement or partnership.
A flood stopped in four layers
An attack is cut down before it reaches your servers: upstream scrubbing takes the bulk, XDP drops what remains at the network card, and BGP FlowSpec and RTBH push new rules outward. Clean traffic keeps flowing the whole time.
Flood in, clean traffic flat
A volumetric UDP flood climbs to about 180 Gb/s across two 100G transit links. XDP drops it at line rate on the edge and a BGP FlowSpec rule (RFC 8955) pushes the filter upstream within about three seconds; delivered traffic stays at its normal 20 Gb/s after one short blip. Illustrative figures.
How we use DDoS & flood protection for clients
Cybersecurity
We find out whether everything you run is safe from attackers, then we fix it.
Learn moreManaged IT Services
We run your IT day to day so it stays secure: help desk, devices, Microsoft 365, Exchange, Active Directory, backups, networks and monitoring.
Learn moreCloud Management
Cloud cost review and management, without compromising on quality or security.
Learn moreFrequently asked questions
Direct answers to the questions we hear most. Something else on your mind?
Send us a messageWhat is the difference between a volumetric attack and a SYN flood?
A volumetric attack tries to fill your internet link with traffic, such as UDP or amplification floods, so nothing else gets through. A SYN flood targets the server's connection table by sending many connection requests that are never completed. The first must be stopped upstream of the link it fills; the second can be handled at the host with SYN cookies and early packet drops.
When do we need an upstream scrubbing service?
When an attack is larger than your own internet link, no filter on your side can help, because the link is already full before the traffic reaches it. Scrubbing providers absorb the attack on much larger capacity and send clean traffic back. If your circuits are small compared with plausible attacks, plan for scrubbing, on demand or always on.
What is RTBH and what is its downside?
Remotely triggered blackholing asks your upstream provider, by tagging a route with the BLACKHOLE community (RFC 7999), to drop all traffic to one address. It stops the flood from harming everything else on your link, but the attacked address is unreachable, so the attacker has achieved the outage for that one host. It is a last resort for a single target, not a complete defense.
How is BGP FlowSpec different from blackholing?
FlowSpec (RFC 8955) distributes match-and-act rules, such as drop UDP source port 123 to this address, instead of dropping everything to the address. That keeps legitimate traffic flowing while the attack is filtered. It needs support and agreement from the upstream provider, and rules are only as precise as what you can match.
What does an XDP filter do that a firewall does not?
XDP runs eBPF programs in the network driver, before the kernel allocates memory for the packet. Dropping a flood packet there costs far less CPU than letting it reach the firewall or the network stack, so a single Linux host can discard many millions of packets per second. It protects the host, not the link: it cannot help if the link itself is saturated.
What should a DDoS runbook contain?
Who declares an incident and who may trigger actions, the detection thresholds and dashboards, the exact steps for diversion, FlowSpec or blackholing with provider contact details, and customer communication. It should list what to protect first, a way to roll back each action, and be rehearsed with a test at a low rate. Without rehearsal, a runbook often fails at the first real attack.