A scrubbing center is a specialized network facility — your own or cloud-based — to which traffic bound for protected resources is diverted during a DDoS attack. The goal is simple: filter out the malicious packets and pass on only the traffic judged legitimate (so-called clean traffic). The center sits between the internet and the target network like a checkpoint at the entrance: it inspects traffic at the network, transport and application layers, separates anomalies from ordinary sessions, and sends the cleaned packets back, usually over a GRE tunnel or a dedicated link.
How does a scrubbing center work?
A full DDoS defense cycle using a scrubbing center has four stages: detecting the attack, diverting the traffic, filtering it, and sending the clean traffic back.
- Detection. Flow monitoring (NetFlow, sFlow, IPFIX) or in-line inspection spots a sudden surge in volume, an unusual mix of protocols, or known attack signatures, and signals that a threshold has been crossed.
- Diversion. Traffic addressed to the targeted range of addresses is steered to the center — through a
BGProute announcement, aDNSrecord change, or aBGP FlowSpecrule. - Filtering. Inside the center, traffic passes through several layers of checks: volume-based filtering (thresholds and signatures), protocol validation, rate limiting, behavioral and anomaly analysis, IP reputation, and “prove you’re human” tests (challenge-response) at the application layer. Malicious packets are dropped.
- Reinjection. The cleaned traffic returns to the target network by a separate path — most often a
GREtunnel, a cross-connect, MPLS/L2VPN, or a BGP clean pipe — so it doesn’t loop back into the diversion path.
Every event is logged — for reporting, post-incident analysis, and compliance.
How does traffic reach a scrubbing center?
Three core diversion methods are used, often combined:
- BGP redirection. The provider announces the customer’s range of addresses from its own network (ASN) as a more specific route — for example a
/24instead of the ISP’s/22. The internet picks the more specific route, so traffic flows to the center instead of the customer’s data center. It protects whole subnets and doesn’t depend on the application protocol. - DNS redirection. The service’s
AorCNAMErecord points to the center’s address, so traffic (usually HTTP/HTTPS for a website or app) is sent to scrubbing at the domain-name level. It needs a lowTTL(the record’s lifetime); how well it works depends on whether DNS resolvers actually honor that short TTL. - BGP FlowSpec. A central controller pushes rules to edge routers that match specific flows (source and destination address, protocol, ports) along with an action — drop, rate-limit, or redirect. This filters surgically instead of cutting off a whole range of addresses, which limits collateral damage.
Why a GRE tunnel for sending traffic back?
After cleaning, traffic can’t return over the same BGP route that pulled it into the center — it would loop. A GRE tunnel wraps the clean packets in a new “envelope” with an outer IP address, while keeping the original source and destination addresses. The customer’s edge router strips off that envelope and delivers the packet as if nothing had happened. The drawback is about 24 bytes of overhead per packet (for IPv4), which lowers the maximum packet size (MTU) on the return path. If ICMP traffic is blocked or Path MTU Discovery fails, this can cause silent packet loss. So in practice the GRE interface MTU is lowered (e.g. to ~1400 bytes) and MSS clamping is applied. Tunnel-free alternatives include cross-connect, MPLS/L2VPN, and a BGP clean pipe return. With an anycast architecture, filtering happens at the network edge, so sending traffic back drops out of the picture entirely.
Always-on vs on-demand
Scrubbing centers are switched on in two ways:
- Always-on. All traffic passes through the center all the time, so mitigation starts instantly — there’s no window for working out new routes. The cost is constant added latency and a higher bandwidth bill.
- On-demand. Traffic flows normally, and diversion to the center kicks in only after an attack is detected. In quiet times there’s no extra latency, but switching on and propagating the routes usually takes about 2 to 10 minutes — and within that window part of the attack may reach the target.
Scrubbing center vs blackholing (RTBH)
Blackholing in its RTBH (Remotely Triggered Black Hole) form announces a route that sends all traffic for the targeted address into nowhere (null0) — packets are dropped wholesale. This effectively relieves the link, but in practice it does the attacker’s job for them: both malicious and genuine traffic stop reaching the host. A scrubbing center does the opposite — instead of dropping everything, it separates the traffic and lets the legitimate sessions through. RTBH is sometimes used as a last resort or a complement when the attack volume exceeds the center’s capacity. The related source-based RTBH drops traffic by source address, while BGP FlowSpec offers finer filtering than classic RTBH.
Dedicated scrubbing vs inline scrubbing
The term “inline scrubbing” is used in two senses. As an activation mode it means always-on — all traffic always through the center. As a placement it means a device wired directly into the traffic path inside the customer’s network. Such a device works locally, without sending traffic outside, but it’s bounded by the link’s capacity and can’t stop a volumetric attack that saturates the internet link. The external variant (a dedicated center) hands cleaning off to high-capacity infrastructure and only pulls traffic in once an attack is detected — at the cost of the time needed to set up routes.
Why does a scrubbing center matter for security and monitoring?
How well scrubbing works depends on the quality of attack detection on the network side, not just on filter capacity. Flow telemetry (NetFlow/sFlow/IPFIX) and a known picture of normal traffic (a baseline) make it possible to spot an anomaly and divert traffic before the attack saturates the link. That’s why scrubbing works hand in hand with network monitoring, NDR systems, and the SOC. From a security standpoint, the following also matter:
- attacks that impersonate real connections (e.g. SYN/ACK floods) — to tell them apart from genuine TCP sessions, the center needs smarter analysis that simple edge filtering can’t provide;
- application-layer attacks (HTTP flood, slow-rate attacks) with low volume, invisible to thresholds that only count traffic — they surface only through behavioral analysis and challenge-response tests;
- different paths “there” and “back” during diversion and reinjection, which can blind devices that track connection state and complicate event correlation in the SOC;
- encrypted traffic — looking inside HTTPS content requires decrypting TLS in the center, which means moving sensitive keys there and widening the area that has to be trusted;
- logs and reports from the center as a data source for post-incident analysis, threshold tuning, and compliance documentation.
Learn more
- Advanced methods of protection against DDoS attacks in companies — Explains broader DDoS defenses, including when traffic should be redirected to a scrubbing center.
- How Sycope helps detect and stop DDoS attacks — Shows how DDoS detection can trigger mitigation workflows that include scrubbing center filtering.
- North-South vs East-West Traffic — Helps distinguish inbound attack traffic that may be sent to a scrubbing center.
- Cloud Security Posture Management (CSPM) — CSPM protects cloud environments, which may still rely on a scrubbing center for DDoS mitigation.
- Direct Network Flood — A direct network flood is a DDoS type that a scrubbing center can help filter.
- Protocol Attack — Protocol attacks are often mitigated by scrubbing centers that remove malicious traffic.
- IPS (Intrusion Prevention System) — An IPS can block attacks locally, while a scrubbing center handles larger DDoS traffic.
- Application Layer Attack (L7) — L7 attacks may need scrubbing center support when they overwhelm application defenses.