Scrubber — centrum czyszczenia ruchu w Twojej sieci
Ten sam dataplane co nasze routery, postawiony jako osobne urządzenie, przez które przechodzi ruch zaatakowanego prefiksu — tylko na czas ataku albo na stałe. Atak zostaje u nas, czysty ruch wraca do Twojej sieci. Twój prefiks, Twoja maszyna, nasz AS niewidoczny w ścieżce.
Zapytaj o scrubber19,6 Mpps
odrzucenia ataku na rdzeń, 64 B
30 Mpps
dywanu SYN+ACK odrzucone w 100 %, 2 rdzenie
99,97 %
ruchu legalnego dostarczone pod dywanem
21,4 Mpps
przez tunel GRE, 0 strat
Zmierzone przy pakietach 64 B, czyli profilu ataku, na AMD EPYC 4565P (Zen 5).
Skala jednej maszyny
Odrzucenie pakietu ataku kosztuje mniej niż jego przekazanie — pakiet kończy w filtrze, bez szukania trasy, przepisania nagłówka i wysyłki. Dlatego jeden rdzeń odrzuca 19,6 Mpps, a atak nie zabiera mocy, której potrzebuje ruch legalny.
W przeliczeniu na 16 rdzeni maszyny to więcej, niż mieszczą dwa porty 100 G: przy 64 B granicą jest pełny line-rate 2 × 100 G — 297,6 Mpps, nie procesor.
Trzy sposoby wpięcia — wszystkie działają produkcyjnie
Przekierowanie BGP od Twoich routerów
Scrubber ogłasza prefiks ofiary (np. /32) z wyższym priorytetem, czysty ruch wraca osobną sesją — VRF powrotu, bez pętli. ITCSECadmin włącza i wyłącza przekierowanie przez API, automatycznie przy ataku.
Styk z operatorem tranzytowym
Scrubber stoi między upstreamem a Twoim routerem brzegowym — cały ruch z tego styku przechodzi przez filtry, na stałe.
Tunel GRE od dostawcy scrubbingu anycast
Scrubber przyjmuje ruch oczyszczony wstępnie przez dostawcę i czyści go dalej. Nasz AS nie pojawia się w ścieżce — prefiks widać w internecie z Twoim AS-em. Ruch z tunelu rozkładamy RSS-em na wszystkie rdzenie: 21,4 Mpps zmierzone bez strat.
Warstwy, przez które przechodzi ruch — w tej kolejności
- Krzem karty (mlx5 rte_flow) — drop przed CPU po cesze ataku: flagi TCP, fragmenty, port.
- ITCacl — reguły z ITCSECadmin i z panelu, per styk, z czasem życia; dziesiątki tysięcy reguł. Na scrubberach filtrujemy też w XDP (eBPF) — na najwcześniejszym etapie ścieżki pakietu w jądrze Linuksa.
- Ochrona stanowa brzegu — SYN+ACK bez wcześniejszego SYN-a odpada; stan synchronizowany między urządzeniami, gdy pracuje więcej niż jeden scrubber albo router (37,1 Mpps kopii stanu przyjęte na 2 rdzeniach bez strat); tryb „licz” albo „egzekwuj” dla każdej warstwy osobno.
- Automat portów — z sFlow wykrywa dywan UDP na porty i sam zakłada regułę (próg, limit wpisów, zwolnienie po spadku ataku). Z produkcji, listopad 2026: 9 reguł w 2 minuty, 99,8 % dywanu odrzucone, ruch legalny przechodzi.
- Automat treści — sygnatury bajtowe z próbek UDP (np. odbicia STUN ze stałym identyfikatorem): propozycja → potwierdzenie na ruchu → odrzucanie.
- Geoblokada per prefiks klienta (lista krajów, licz/egzekwuj), klasy ochrony (DNS-AMPL, NTP-AMPL, fragmenty), BCP38, MSS clamp na tunelach.
- Analiza sFlow w pamięci — bez zapisu surowych pakietów na dysk; ekran „Ruch” per klient: wchodzi / odrzucone / dostarczone, osobno ruch wychodzący w świat.
Sterowanie z ITCSECadmin
ITCSECadmin włącza i wyłącza przekierowanie przez API — automatycznie przy ataku — i dostarcza reguły ITCacl i XDP. Pętla telemetria → detekcja → reakcja → audyt zamyka się w jednym systemie, bez opłat za Gbps i bez wysyłania danych poza Twoją sieć.
Wdrożenia
Trzy scrubbery przyjmują dziś prawdziwy ruch ataków u operatorów w Polsce. Nazw klientów, ich AS-ów i prefiksów nie publikujemy bez ich zgody.
Skala, którą zmierzyliśmy — przy pakietach 64 B, czyli profilu ataku →