Ochrona przed DDoS we własnej sieci czy scrubbing w chmurze? Uczciwe porównanie

11 lipca 2026 · 13 min czytania

Filtrowanie we własnej sieci reaguje w sekundy i ma stały koszt. Scrubbing w chmurze wchłania ataki większe niż uplink. Porównanie: czas reakcji, koszt, droga ruchu.

Krótka odpowiedź: filtrowanie we własnej sieci wykrywa i odrzuca ruch ataku na Twoich własnych routerach, zwykle w kilka sekund, przy stałym koszcie i bez wypuszczania ruchu poza sieć. Scrubbing center to obiekt zewnętrznego dostawcy, do którego przekierowujesz ruch, żeby go oczyścił i odesłał — wygrywa wtedy i tylko wtedy, gdy atak jest większy niż Twój uplink. Dla większości operatorów uczciwa odpowiedź nie brzmi „albo–albo", tylko „jedno jako pierwsza linia, drugie jako eskalacja".

Dwa modele, dwa różne miejsca w sieci

Oba podejścia rozwiązują ten sam problem, ale robią to w innym punkcie topologii — i to jedno rozróżnienie wyjaśnia praktycznie wszystkie różnice, które zobaczysz niżej.

Filtrowanie we własnej sieci oznacza, że detekcja i reakcja dzieją się na infrastrukturze, którą sam eksploatujesz: sensor patrzy na ruch, który i tak przez Ciebie przechodzi, a reguła filtrująca ląduje na Twoim routerze brzegowym albo na serwerze filtrującym. Ruch nie zmienia trasy.

Scrubbing center to zdalne centrum danych z bardzo dużą pojemnością szkieletu. W momencie ataku ogłaszasz swoje prefiksy przez BGP (albo przekierowujesz ruch DNS-em), ruch idzie tam, zostaje oczyszczony i wraca do Ciebie tunelem albo dedykowanym łączem.

Wybór sprowadza się do czterech dźwigni: czasu reakcji, modelu kosztu, kontroli nad drogą ruchu i pojemności, jaką da się wchłonąć. Żadna z opcji nie wygrywa we wszystkich czterech.

Kontekst jest przy tym coraz mniej komfortowy. Cloudflare raportuje, że w 2025 roku liczba ataków DDoS wzrosła o 121% rok do roku, a średnio filtrowano 5376 ataków na godzinę; telekomunikacja, dostawcy usług i operatorzy byli najczęściej atakowaną branżą przy atakach o skrajnie dużym wolumenie (Cloudflare, Q4 2025 DDoS Threat Report, luty 2026). NETSCOUT odnotował w drugiej połowie 2025 roku ponad 8 milionów ataków w 203 krajach, z czego około 42% używało od dwóch do pięciu wektorów jednocześnie (NETSCOUT DDoS Threat Intelligence Report, wydanie 16, marzec 2026).

Porównanie: filtrowanie lokalne kontra scrubbing w chmurze

Poniższa tabela zbiera te kryteria, które faktycznie decydują o wyborze u ISP, w hostingu i w przedsiębiorstwie utrzymującym własny ruch.

Kryterium	We własnej sieci (np. WanGuard)	Scrubbing center w chmurze
Czas wykrycia	2–5 s przy port-mirrorze / DPDK	Dziesiątki sekund do minut (przekierowanie + zbieżność BGP)
Miejsce filtrowania	Twoje routery brzegowe	Centrum danych zewnętrznego dostawcy
Model kosztu	Wdrożenie jednorazowe + licencja + wsparcie	Rozliczenie za Gbps / za ruch oczyszczony — rośnie z wielkością ataku
Droga ruchu	Ruch nie opuszcza Twojej sieci	Ruch przechodzi przez podmiot trzeci
Suwerenność danych	Pełna, w sieci (NIS2, regulacje telekomunikacyjne)	Ruch i metadane przekraczają granicę Twojej infrastruktury
Opóźnienie w stanie ustalonym	Brak dodatkowego	Dodane przy trybie always-on; brak przy on-demand
Sufit wolumetryczny	Pojemność Twoich uplinków	Skala terabitowa, szkielet dostawcy
Kontrola i strojenie	Twoje progi, wyjątki i polityki	Logika dostawcy, platforma współdzielona

Tabela jest celowo bezlitosna w obie strony. Nie ma w niej wiersza, w którym jedna kolumna wygrywa „ogólnie" — są wiersze, w których wygrywa jedna, i wiersze, w których wygrywa druga.

Na czym polega filtrowanie ataku we własnej sieci?

To oprogramowanie (rzadziej dedykowany sprzęt), które wykrywa i odrzuca ruch ataku wewnątrz Twojej sieci, na serwerach i routerach, którymi zarządzasz. Platforma taka jak WanGuard profiluje ruch produkcyjny, uczy się linii bazowej „normalności" per podsieć, per adres i per dekoder, a w momencie odchylenia podnosi anomalię i sięga po dostępny mechanizm filtrowania. Nic nigdzie nie jest przekierowywane.

Reakcja odbywa się w istniejącej płaszczyźnie przekazywania pakietów:

BGP FlowSpec — chirurgiczna reguła po 5-tuple, wykonywana na routerze z prędkością łącza. Opisaliśmy to szczegółowo we wpisie o filtrowaniu ataków regułami BGP FlowSpec.
RTBH — blackholing jako opcja ostatnia, gdy ataku nie da się już rozdzielić granularnie. Kiedy to ma sens, a kiedy jest kapitulacją, rozbieramy w tekście o RTBH.
Serwer filtrujący DPDK — inline albo na odgałęzieniu, przy 10/40/100 GE.

Ponieważ i detekcja, i reakcja mieszkają na Twoim brzegu, czas odpowiedzi mierzy się w sekundach — a nie w czasie potrzebnym na przetasowanie ruchu w internecie. To model, który ITORO wdraża i utrzymuje jako usługę anty-DDoS opartą o WanGuard.

Uczciwe zastrzeżenie: ten model wymaga, żeby ktoś u Ciebie rozumiał sieć. Progi trzeba nastroić, wyjątki opisać, a przekierowanie ruchu na serwer filtrujący w sieci z jednym routerem potrafi być architektonicznie kłopotliwe. To nie jest pudełko, które się włącza i zapomina.

Czym jest scrubbing center i co realnie daje?

Scrubbing center to obiekt zewnętrznego dostawcy dysponujący dużą pojemnością szkieletu, który filtruje („szoruje") Twój ruch poza Twoją siecią. Gdy zaczyna się atak, ruch zostaje tam przekierowany — najczęściej przez ogłoszenie prefiksów w BGP, rzadziej przez przekierowanie DNS. Centrum odrzuca ruch ataku i odsyła czysty strumień tunelem albo łączem dedykowanym.

Scrubbing center istnieje przede wszystkim z jednego powodu: pojemności. Dostawca z wieloterabitowym szkieletem wchłonie zalew, który wysyciłby uplink pojedynczego operatora w kilka sekund. To jest realna, ważna przewaga i nie ma sensu jej relatywizować.

Cena tej przewagi jest architektoniczna, nie tylko finansowa:

Ruch przechodzi przez infrastrukturę, której nie kontrolujesz.
Filtrowanie czeka na przekierowanie i zbieżność BGP.
Model handlowy zwykle rozlicza się za Gbps ruchu oczyszczonego — więc faktura rośnie razem z wielkością ataku, przed którym się bronisz.
Polityki są definiowane przez dostawcę i współdzielone z innymi klientami. Twój nietypowy ruch (np. UDP produkcyjne, gaming, VoIP) bywa fałszywie odrzucany, a strojenie idzie przez ticket, nie przez Twoją konsolę.

Ile czasu tracisz na przekierowaniu ruchu?

Czas wykrycia to czynnik, który operatorzy zaniżają, a napastnicy wykorzystują.

Detekcja z port-mirrora analizuje kopię każdego pakietu z prędkością łącza (DPDK, PF_RING), więc rozpoznaje zalew wolumetryczny w około 2–5 sekund i od razu wyzwala reakcję. Detekcja z NetFlow / sFlow / IPFIX jest wygodniejsza wdrożeniowo, ale płacisz za to opóźnieniem eksportu flowów z routera — w praktyce kilkanaście do kilkudziesięciu sekund.

Scrubbing center nie może zrobić nic, dopóki ruch do niego nie dotrze. Ogłoszenie prefiksu, propagacja, zbieżność BGP, ustanowienie ścieżki powrotnej — to są dziesiątki sekund, czasem minuty, zależnie od konstrukcji sieci i tego, czy tunel powrotny stoi na stałe.

Ta różnica decyduje o wyniku. Gdy rekordowy zalew osiąga szczyt 31,4 Tbps i trwa 35 sekund (Cloudflare, luty 2026), ścieżka obronna potrzebująca pół minuty na uruchomienie może przegapić atak w całości albo zacząć działać dokładnie wtedy, gdy atak się kończy. Filtrowanie lokalne jest już w linii ruchu — nie ma kroku „przekieruj", na który trzeba czekać.

Są dwa warianty pośrednie i oba mają swoją cenę:

Scrubbing always-on likwiduje opóźnienie przekierowania, ale dokłada stałe opóźnienie do całego ruchu i stały koszt — bo cały ruch jest inspekcjonowany przez cały czas.
Scrubbing on-demand nie dokłada opóźnienia w stanie ustalonym, ale przywraca opóźnienie przekierowania dokładnie wtedy, gdy jest najgorzej.

Filtrowanie we własnej sieci omija oba problemy — ale wyłącznie dla ataku, który mieści się w Twoim uplinku. To jest sedno całego porównania.

Koszt: stała licencja kontra rachunek za Gbps

Struktury kosztów różnią się fundamentalnie, a różnica kumuluje się dokładnie w tych momentach, w których ochrona jest potrzebna.

Model lokalny to jednorazowe wdrożenie plus licencja i poziom wsparcia. Koszt jest stały niezależnie od wielkości ataku, bo pojemność filtrującą już masz. Budżetowanie jest przewidywalne: większy atak nie oznacza większej faktury. Dochodzi efekt uboczny, o którym się rzadko mówi — sensor daje retencję i szczegółowe raportowanie ruchu, więc przy okazji dostajesz dane do planowania zakupu tranzytu.

Scrubbing rozlicza się zwykle za Gbps ruchu oczyszczonego albo według progu pojemności burst. Model jest elastyczny, co brzmi atrakcyjnie, ale w praktyce oznacza, że koszt skaluje się z wielkością ataku. Wielodniowa kampania albo seria powtarzalnych ataków — a takie właśnie widujemy przy wymuszeniach okupu — zamienia przewidywalną pozycję w budżecie w zmienną, która osiąga szczyt dokładnie wtedy, gdy jesteś pod największą presją.

Trzeba jednak dopowiedzieć drugą stronę: model lokalny wymaga nakładu na wejściu, zanim cokolwiek się wydarzy, i wymaga kompetencji do utrzymania. Dla organizacji, która nie ma zespołu sieciowego i nie chce go mieć, subskrypcja u dostawcy może być racjonalną decyzją — nawet jeśli w horyzoncie kilku lat wychodzi drożej.

Nie podajemy kwot w tekście blogowym, bo cennik żyje własnym życiem. Aktualne stawki i kalkulator są na stronie Cennik.

Dlaczego droga ruchu ma znaczenie regulacyjne?

To, gdzie ruch jest czyszczony, nie jest wyłącznie pytaniem o wydajność. Jest też pytaniem o zgodność i zaufanie.

Filtrowanie lokalne zatrzymuje każdy pakiet i jego metadane wewnątrz Twojej sieci. Dla ISP, telekomów i podmiotów regulowanych to ma znaczenie: kierowanie ruchu klientów przez scrubbing center oznacza, że dane abonentów i wzorce ruchu przechodzą przez infrastrukturę, której nie kontrolujesz. Przy NIS2 i przepisach sektorowych to rodzi pytania, na które trzeba mieć odpowiedź w dokumentacji, a nie na spotkaniu z audytorem.

Podobnie z kontrolą. Lokalnie masz własne progi, wyjątki i polityki — łącznie z tym brzydkim, nietypowym ruchem, który u dostawcy trafiłby pod regułę ogólną. Współdzielona platforma chmurowa stosuje logikę zdefiniowaną przez dostawcę wobec wielu klientów naraz. To jest efektywne, ale mniej precyzyjne dla Twojej konkretnej sieci.

Z naszych obserwacji: operatorzy, którzy najbardziej dopytują o drogę ruchu, to ci z najsilniejszą ekspozycją regulacyjną. Dla nich filtrowanie w sieci nie jest preferencją, tylko wymogiem.

Kiedy scrubbing w chmurze naprawdę wygrywa?

Ma jedną przewagę rozstrzygającą: wchłania ataki większe niż Twój uplink. To jest uczciwa granica każdego rozwiązania lokalnego i nie da się jej obejść żadnym strojeniem.

Nie odfiltrujesz więcej ruchu, niż fizycznie przenoszą Twoje łącza. Zalew, który wysyca łącze powyżej Twoich routerów, zapcha je, zanim Twój filtr zobaczy jakąkolwiek wolną pojemność. Fizyki się nie oszuka i każdy dostawca, który twierdzi inaczej, sprzedaje coś innego niż inżynierię.

Scrubbing (albo eskalacja u operatora tranzytowego) jest właściwym ruchem, gdy:

zalew osiąga skalę terabitową albo po prostu przekracza wykupioną przepustowość,
atak jest wielowektorowy i długotrwały, a Ty nie masz zespołu do prowadzenia go 24/7,
prowadzisz usługę o profilu, który regularnie ściąga na siebie duże wolumeny (gaming, publiczne DNS, duże serwisy medialne).

Wiarygodny dostawca mówi Ci o tym przed podpisaniem umowy, a nie w trakcie incydentu.

Warto dodać wariant trzeci, który wielu operatorów pomija: filtrowanie u operatora tranzytowego regułami BGP FlowSpec. Część operatorów w Polsce przyjmuje reguły FlowSpec od klientów i wykonuje je na swoim brzegu. Wtedy górny limit tego, co potrafisz odrzucić, przestaje być wyznaczany przez Twój uplink — bez przekierowywania ruchu i bez opłaty za Gbps.

Werdykt: pierwsza linia w sieci, eskalacja wyżej

Dla większości operatorów żaden z modeli nie wygrywa samodzielnie, a najmocniejsza architektura łączy oba.

Warstwa pierwsza — Twoja sieć. Wykrycie w sekundach, filtrowanie w miejscu, ruch nie wychodzi na zewnątrz, koszt stały. Obsługuje przytłaczającą większość ataków, bo rozkład ataków według wolumenu jest silnie skośny: dominują te małe i średnie, mieszczące się w uplinku.

Warstwa druga — eskalacja. Blackholing u operatora, reguła FlowSpec wypchnięta wyżej albo scrubbing center. Uruchamiana wtedy, gdy wolumen przekracza to, co przenoszą łącza.

Automatyzacja jest tym, co sprawia, że to działa. WanGuard filtruje najpierw granularnie regułą BGP FlowSpec, przechodzi na RTBH, gdy uplinki zbliżają się do wysycenia, i sygnalizuje potrzebę eskalacji, gdy wolumen wychodzi poza pojemność łącza. Dostajesz reakcję poniżej 5 sekund w przypadku typowym i zabezpieczenie o skali terabitowej w przypadku rzadkim.

Czego ten model nie daje: gwarancji, że każdy atak zostanie odfiltrowany bez śladu. Nikt tego nie daje. Daje natomiast to, że w większości incydentów usługa nadal działa, a w tych rzadkich, największych — masz zaplanowaną ścieżkę zamiast improwizacji o trzeciej w nocy.

ITORO, Gold Partner firmy Andrisoft, projektuje, wdraża i utrzymuje dokładnie taki układ dla ISP, hostingów i przedsiębiorstw. Szczegóły architektury opisaliśmy na stronie o WanGuard.

Najczęstsze pytania

Co jest lepsze — filtrowanie we własnej sieci czy scrubbing w chmurze?

To zależy od wielkości ataku. Filtrowanie lokalne jest szybsze (2–5 sekund), ma stały koszt i nie wypuszcza ruchu poza sieć, więc wygrywa dla wszystkiego, co mieści się w uplinku. Scrubbing wygrywa wyłącznie przy zalewach przekraczających przepustowość łączy. Większość operatorów prowadzi oba układy równolegle.

Czym jest scrubbing center?

To obiekt zewnętrznego dostawcy z dużą pojemnością szkieletu, który filtruje Twój ruch poza Twoją siecią. W momencie ataku ruch jest tam przekierowywany przez BGP lub DNS, czyszczony i odsyłany z powrotem. Siłą jest wchłanianie zalewów o skali terabitowej; ceną — opóźnienie przekierowania, rozliczenie za Gbps i ruch przechodzący przez podmiot trzeci.

O ile szybciej reaguje filtrowanie w mojej sieci?

Detekcja z port-mirrora reaguje w około 2–5 sekund, bo analizuje ruch, który już przez Ciebie płynie. Scrubbing center musi najpierw przejąć ruch, a przekierowanie plus zbieżność BGP zajmuje zwykle dziesiątki sekund do minut. Przy rekordowych zalewach trwających 35 sekund (Cloudflare, luty 2026) ta różnica jest rozstrzygająca.

Czy filtrowanie we własnej sieci zatrzyma atak o skali terabitowej?

Samodzielnie nie. Jest ograniczone pojemnością Twoich uplinków, więc zalew większy niż łącza musi zostać zatrzymany wyżej. Dlatego rozsądny projekt zakłada dwie warstwy: lokalne filtrowanie wszystkiego, co mieści się w łączu, i eskalację do blackholingu u operatora, reguły FlowSpec na jego brzegu albo do scrubbing center dla reszty.

Czy rozwiązanie lokalne wychodzi drożej niż subskrypcja w chmurze?

W horyzoncie kilku lat zwykle nie. Lokalne to jednorazowe wdrożenie plus licencja i wsparcie — koszt stały niezależnie od wielkości ataku. Scrubbing rozlicza się za Gbps ruchu oczyszczonego, więc rośnie razem z atakiem i osiąga szczyt przy długich kampaniach. Za to model lokalny wymaga nakładu na starcie i kompetencji do utrzymania. Aktualne stawki znajdziesz w Cenniku.

Dlaczego droga ruchu ma znaczenie przy NIS2?

Bo filtrowanie lokalne zatrzymuje każdy pakiet wewnątrz Twojej sieci, a scrubbing prowadzi Twój ruch — łącznie z danymi abonentów i wzorcami ruchu — przez podmiot trzeci. Dla ISP, telekomów i podmiotów regulowanych utrzymanie drogi ruchu w sieci bywa wymogiem zgodności, a nie tylko preferencją architektoniczną.