A DDoS scrubbing service diverts your traffic to a filtering centre, drops the attack packets, and sends the clean traffic back to your network, either always or only when an attack is detected.
It is enterprise plumbing, and most small sites will never need to rent it. What they usually need is a CDN proxy with sane rules and an origin that is not directly reachable. Still, the term shows up in every DDoS conversation, so here is what scrubbing actually does, the difference between the delivery models, and an honest line between who needs it and who does not.
Table of contents
- What scrubbing actually is
- How traffic gets diverted: BGP and DNS
- Getting the clean traffic back: GRE, cross-connects and proxies
- Always-on versus on-demand, and layers 3/4 versus 7
- Who actually needs a scrubbing service
- What small sites should do instead
- How this fits the rest of the stack
- FAQ
What scrubbing actually is
A scrubbing centre is a facility, or a set of them, with a lot of bandwidth and specialised filtering hardware and software. During an attack your traffic is redirected there. The centre analyses it, separates legitimate requests from attack traffic, discards the attack traffic, and forwards what is left to your servers. Radware’s scrubbing centre explainer describes exactly that sequence: redirect, analyse, remove, return.
The word that matters is capacity. A volumetric attack is a flood measured in gigabits or terabits per second, and if the flood is bigger than the link into your data centre, the link is full and nothing legitimate gets through, however clever your firewall is. A scrubbing provider absorbs it upstream, where the capacity is bigger than the attack.
Filtering is a mix of techniques: rate limits per source, protocol validation (dropping malformed or spoofed packets), reputation lists, behavioural baselines learned from your normal traffic, challenge-response for suspected bots, and signature matching for known attack tools. Good services combine automated mitigation with analysts who handle the odd cases.
Notice what scrubbing is not. It is not a web application firewall, it does not fix an application that falls over at 200 requests per second, and it does not help if your traffic never passes through it.
How traffic gets diverted: BGP and DNS
There are two main ways to route traffic through a scrubbing centre, and which you can use depends on what you own.
BGP diversion is for organisations that have their own IP address space. You announce your prefix, or the provider announces it on your behalf, so that internet traffic for those addresses flows to the scrubbing network first. Internet routing practice generally filters prefixes smaller than a /24 for IPv4, so a /24 is the smallest block you can usefully divert. This method works for any protocol and any port, which is why game servers, VoIP, DNS and other non-web services rely on it.
DNS diversion is for web applications. You change the DNS records so your hostname resolves to the provider’s addresses. Traffic then hits the provider first and is forwarded to your origin. This is how a CDN proxy works, and it is why it only protects the hostnames and ports that go through it. If your origin IP is known, an attacker can skip the provider altogether.
- BGP diversion: needs your own prefix (at least a /24), works for any protocol, common for network operators and hosting providers.
- DNS diversion: needs only a hostname, works for HTTP and HTTPS, common for websites and APIs.
- Both: only help if attackers cannot reach the origin directly.
The second point is why origin protection matters as much as the service itself. A shield with a side door is not a shield.
Getting the clean traffic back: GRE, cross-connects and proxies
Once traffic is scrubbed, the provider has to deliver it to you. The delivery method affects latency, complexity and cost.
A GRE tunnel wraps the clean packets and sends them across the public internet to a router at your end, which unwraps them. It is quick to set up and works anywhere with a public IP, at the cost of some extra overhead, an MTU to manage, and a return path that shares the internet with everything else. A direct cross-connect or private link runs a dedicated circuit from the scrubbing centre to your network, which is more reliable and lower latency and requires being in the same facility or paying for a circuit.
Reverse proxy delivery, the CDN model, terminates the connection at the provider and opens a new one to your origin. It does not preserve the client IP at the network layer, so you rely on headers like X-Forwarded-For, and you need to lock the origin to accept connections only from the provider.
# example: allow web traffic to the origin only from the provider's ranges (ranges are illustrative)
sudo ufw default deny incoming
sudo ufw allow from 198.51.100.0/24 to any port 443 proto tcp
sudo ufw allow OpenSSH
sudo ufw enableA subtle point on symmetry: BGP diversion with a GRE return usually means traffic in from the scrubber but out directly, so your outbound path bypasses the provider. That is normal, and it is why your egress capacity still needs to be adequate.
Always-on versus on-demand, and layers 3/4 versus 7
Always-on scrubbing routes all traffic through the provider all the time. Mitigation starts instantly because there is nothing to switch over, at the cost of a constant extra hop of latency and a standing subscription. On-demand scrubbing keeps traffic direct until an attack is detected, then activates diversion (a BGP announcement, or a DNS change). It is cheaper but has a delay, from minutes to longer, during which the attack does its damage, and BGP and DNS changes both take time to propagate.
The hybrid, common in enterprise, is always-on detection with on-demand mitigation triggered automatically from your own flow data.
Then there are the layers. Layer 3 and 4 attacks target the network and transport: UDP floods, SYN floods, amplification attacks using open DNS or NTP servers. Scrubbing centres are excellent at these because they are raw packet problems. Layer 7 attacks target the application: floods of legitimate-looking HTTP requests to expensive endpoints like search or login. Those need a proxy that understands HTTP, with rate limiting, challenges and bot detection. A pure network scrubber can miss them entirely, because each packet looks valid.
If you suspect a layer 7 problem, the lever is a WAF and rate limits, not more bandwidth. We compared those options in best cloud WAF and looked at the DNS side in DNS DDoS mitigation.
Who actually needs a scrubbing service
You probably need a dedicated scrubbing service if any of these apply: you run your own IP space and autonomous system; you operate a hosting business, a game platform, a financial exchange or a VoIP service with non-HTTP protocols; you are a repeat target with real revenue at stake per minute of downtime; or a compliance or contractual requirement demands it.
You probably do not if you run a website or an API over HTTP and HTTPS with normal traffic. For those workloads a CDN proxy already includes network-scale mitigation: because the proxy has enormous distributed capacity and terminates web traffic itself, it absorbs floods that would drown a small server, and most include rate limiting and a WAF. Our DDoS protection CDN post walks through that model.
The line to draw: if your service is reachable only via a hostname over web ports, a CDN proxy is the appropriate tool. If it needs raw IP reachability, non-web ports or your own address space, scrubbing is the appropriate tool. Vendors such as Netscout’s Arbor Cloud sell the second kind.
Also consider the boring alternative: right-sizing. Many self-inflicted outages that look like DDoS are a viral link, a crawler, or a broken retry loop hitting an under-sized server. Logs tell you which one you have.
What small sites should do instead
A short, effective list beats a scrubbing contract for a small site. Put a proxy in front of the site, and lock the origin so it accepts traffic only from that proxy. Turn on rate limiting for login, search, checkout and any endpoint that costs real work. Cache what is cacheable, so an attack on a cached page never reaches the app. Keep the origin’s IP out of public DNS history, mail headers and certificate logs, and rotate it if it leaked.
Make the app degrade gracefully. Connection limits on the database, timeouts on upstream calls, and queueing for expensive work mean a spike slows the site instead of taking it down. Autoscaling between a floor and a ceiling buys headroom for a legitimate spike, though you should set a ceiling so a flood cannot turn into a surprise bill.
Finally, have a runbook: who checks what, how to enable stricter rules, how to see logs and metrics quickly, and how to roll back a deploy. When something is on fire you do not want to be reading documentation for the first time.
- Proxy in front, origin locked to the proxy.
- Rate limits on expensive endpoints.
- Cache aggressively; cached pages absorb floods for free.
- Set limits on connections, timeouts and autoscaling ceilings.
- Keep logs and metrics one click away.
How this fits the rest of the stack
Scrubbing is the right tool for networks, non-web protocols and repeat targets. For a website or an API, a proxy in front of a locked-down origin covers most of the risk, and the rest is an application that degrades gracefully. If you want to see what an origin with autoscaling limits costs, the RunxBuild hosting calculator puts the plan ladder in numbers. Deploy the service from the RunxBuild dashboard, and read autoscaling on RunxBuild to set a ceiling you can live with. If you are unsure which side of the line you are on, look at your last traffic incident. If the cause was a flood of packets that filled your link, you have a network problem and scrubbing is worth pricing. If it was a flood of requests that exhausted your app, you have an application problem and rules, caching and limits are the cheaper fix.
Useful related references:
FAQ
What is a DDoS scrubbing service?
It is a service that reroutes your traffic to a high-capacity filtering centre during an attack. The centre removes malicious packets and sends clean traffic to your servers. It handles volumetric and protocol attacks at network layers 3 and 4 that would otherwise saturate your own link.
What is the difference between always-on and on-demand scrubbing?
Always-on routes all traffic through the provider constantly, so mitigation is immediate but adds a hop and a standing cost. On-demand diverts traffic only when an attack is detected, which is cheaper but leaves a delay while the diversion takes effect.
How does BGP diversion work for DDoS mitigation?
You announce your IP prefix through the scrubbing provider, so internet traffic to your addresses flows through their network first. After filtering, clean traffic returns via a GRE tunnel or direct link. It needs your own address space, generally a /24 or larger for IPv4.
Do I need a scrubbing service for a small website?
Usually not. A CDN proxy in front of a locked-down origin absorbs typical floods, adds rate limiting and WAF rules, and terminates web traffic itself. Scrubbing services matter for operators with their own IP space, non-web protocols or high-value repeat targets.
Does scrubbing protect against application-layer attacks?
Network-focused scrubbing is strongest against layer 3 and 4 floods. Layer 7 attacks look like legitimate HTTP requests, so they need a proxy with a WAF, rate limiting and bot detection. Many providers combine both, so ask which layers are actually covered before you buy.