Volumetric absorption
Amplification and reflection floods dropped at the nearest scrubbing cluster. Capacity is per cluster, not pooled across a region.
Our filter is an eBPF program attached to the receive path of every network card in every cluster. A packet is classified and dropped before the kernel allocates a buffer for it. That is why a drop costs nanoseconds - and why capacity is measured in tens of millions of packets per second per server, and a billion per scrubbing location.
Most providers inspect traffic after the operating system has already paid for it. We attach to the driver's receive path, so a dropped packet costs a few nanoseconds and never touches the stack.
Amplification and reflection floods dropped at the nearest scrubbing cluster. Capacity is per cluster, not pooled across a region.
SYN cookies, connection tracking and rate limits keyed on the TCP option fingerprint, so a flood is separated from a busy customer.
Payload judged on its bytes, never on its port number. A DNS reply is recognised as DNS wherever it arrives.
Every vector below has its own counter, its own threshold and its own drop reason. When something is mitigated you can be told which rule fired and why - not just that “an attack was blocked”.
Your traffic is never blackholed. A prefix under attack keeps being announced and keeps being reachable. Dropping a customer off the internet to save the network is not mitigation, it is the attacker’s objective reached by other means - and it is the one thing we have never done.
Everything above is decided in the network, on the packet, at line rate. An attack that is indistinguishable from a real user at the packet level cannot be. A valid HTTPS request is a valid HTTPS request whatever its intent. It has the right handshake, the right headers and a real TCP connection behind it. No amount of filtering in a NIC driver will tell it from the request beside it.
Judging that needs the decrypted request, which means terminating the connection. So the application layer is a second engine with a different architecture: a reverse proxy that accepts the session, inspects what was actually asked for, and forwards only what survives.
It sits behind the network filter, not instead of it. That ordering is the part most WAF products cannot offer. A proxy exposed directly to the internet has to survive the volumetric attack itself - and a 300 Gbps flood takes it off the air long before it evaluates a single request. Here the packet filter absorbs the flood first and the proxy only ever sees traffic that already passed, so the two layers never compete for the same machine’s resources.
Certificates are generated automatically the moment a hostname is pointed at us, and renewed without anybody being asked. Issuing a certificate is easy and everyone gets it right; renewing one at three in the morning eighty-nine days later is what actually takes sites down, which is why that half is automated and not documented.
Suspicious sessions are challenged; everyone else is not. An always-on captcha is a tax on every real visitor to catch a few bad ones, and it trains people to leave. The challenge escalates with the evidence - most legitimate users never see one, and the ones who do see it once.
Anonymising infrastructure and automated clients are identified and handled by policy: open proxies, VPN egress, Tor exit nodes, headless browsers and scripted clients that imitate one. Policy, not verdict - for a shop, Tor traffic may be worth blocking outright; for a news site it may be the readers who need it most. You choose per hostname, and we do not choose for you.
Request-rate limits per client rather than per address, so one NAT does not stand in for a thousand users. Plus the ordinary WAF work: injection and traversal attempts, malformed and oversized requests, and login endpoints protected against credential stuffing by rate rather than by blocking a country.
We say all of this plainly because the alternative is selling one product and delivering another: several providers put “HTTP flood” on the same list as “UDP flood” without mentioning that the two are stopped by entirely different machinery - or by none.
Protection is delivered over ordinary networking - a tunnel from wherever you already are, or a cable in a facility we share. No agents on your servers, no DNS tricks for the network layer, nothing to install.
You stay at your current provider and nothing physical changes. We announce your prefixes (or you keep announcing them and steer traffic to us), inbound traffic crosses the filter, and what survives is delivered to your routers through the tunnel.
If your equipment is in - or near - a facility we are present in, a cross connect replaces the tunnel: no encapsulation, no MTU overhead, and the filter sits directly in the physical path. This is also how protected IP transit is delivered.
Both arrive at the same filter with the same thresholds - the delivery method changes where your clean traffic comes out, never how it is cleaned. Not sure which fits your topology? Ask an engineer - it is usually a five-minute answer, and a longer one is a service we also sell.
Most protected customers end up holding two or three of these - not because we bundle them, but because each one removes a hand-off that used to be a weak point.
Buy the connectivity from the same network that cleans it and the finger-pointing disappears: no diversion event, no third-party GRE, one NOC that owns the whole path. Protected IP transit →
Protection follows the prefix. With your own ASN and PI space the protected resources are registered to you - portable, permanent, and never hostage to any provider, including us. ASN & address space →
Where filtering belongs in your topology, what it must see to decide anything, and which attacks a design provably cannot stop - answered before you spend, not after. How an engagement runs →
It does not start - it is already running. Filtering is permanently in the path, so there is no activation, no diversion and no BGP convergence to wait out. A new vector goes from first packet to enforced rule in under a second.
As our own mitigation step - never. Blackholing completes the attack, so our escalation path ends in a tighter filter, not in your prefix disappearing. RTBH exists as a tool you can trigger for your own reasons; we do not use it on you.
Only if your servers stay at another provider. Tunnels (GRE, IPIP, VXLAN) are one delivery method; a cross connect at any of our sites or protected transit are the others. Same filter either way - only where the clean traffic exits changes.
Nanoseconds. The decision happens in the NIC driver before the kernel allocates memory for the packet, and there is no scrubbing-centre detour because there is no detour at all - the filter sits on the path your traffic already takes.
An incident record: which rule fired, what threshold it crossed, what the traffic was made of, and a packet capture you can open in Wireshark. The exact format is on the evidence page - we would rather you checked than trusted.
That traffic is why the filter judges packets by their bytes, never by their port. Source engine, RakNet, SIP and RTP are recognised as themselves, and thresholds are set against your measured baseline rather than an industry default.
This site sets zero cookies - no analytics, no trackers, no profile of you. The only third-party requests are the fonts, served by Google Fonts, and the spam check on the contact form. Everything else stays between your browser and our network - the full privacy note.