Własny system anty-DDoS i usługa od upstreamu nie wykluczają się, bo odpowiadają za różne rzeczy. Usługa upstreamu daje pojemność sieci dostawcy i działa, zanim ruch dotrze do łącza operatora, ale obejmuje ruch przechodzący przez tego dostawcę. Własny system widzi ruch ze wszystkich monitorowanych łączy, decyduje o reakcji w ciągu sekund i potrafi wysłać reguły lub blackholing do upstreamu. Dla większości operatorów pytanie nie brzmi więc "czy", tylko "jak podzielić role".
Co oferują usługi anty-DDoS od upstreamów?
Upstream może udostępnić operatorowi jeden lub kilka poziomów ochrony: blackholing wyzwalany community BGP, przyjmowanie reguł BGP FlowSpec od klienta, usługę zarządzaną z wykrywaniem i filtracją po stronie dostawcy oraz przekierowanie ruchu do centrum czyszczącego (scrubbing center). Zakres i warunki różnią się u poszczególnych dostawców.
Na polskim rynku publicznie opisane są m.in. dwie takie usługi:
Orange: DDoS Protection opisano jako ciągłe monitorowanie ruchu klienta 24/7/365, wykrywanie anomalii i eliminację podejrzanych pakietów, z SOC dostępnym całą dobę i raportem końcowym po zdarzeniu. Blokowanie odbywa się automatycznie lub po konsultacji z klientem. Osobna usługa Orange Internet Protection jest dodatkiem dla klientów Biznesowego VPN i Miejskiego Ethernetu, a o jej automatycznym uruchomieniu klient dostaje informację elektroniczną.
Exatel: TAMA występuje w trzech wariantach. Basic stosuje blackholing, Standard filtruje ruch złośliwy i przepuszcza poprawny, a Advanced dodaje wsparcie SOC podczas ataku. Usługa chroni klientów na łączach Exatela i działa na centralnej platformie w jego centrum danych. Ochrona wolumetryczna jest opisana do 100 Gb/s, a progi pps i bps dla pojedynczych adresów IP klient może ustawić sam.
Pojemność to realna przewaga sieci dostawcy. CERT Orange Polska opisał atak na pojedynczy adres IP o szczycie 1,5 Tb/s. To wolumen wielokrotnie większy niż łącza typowego operatora lokalnego. Na publicznych stronach obu usług nie znaleźliśmy natomiast konkretnych czasów reakcji ani cen, więc te parametry trzeba uzyskać bezpośrednio od dostawcy.
Co daje własny system anty-DDoS w sieci operatora?
Własny system widzi ruch z perspektywy całej sieci operatora i reaguje na jego routerach. LiveShield analizuje kopię ruchu z portu SPAN lub optycznego Link TAP, poza ścieżką produkcyjną, więc obejmuje wszystkie monitorowane łącza, a nie tylko jednego dostawcę.
Progi w pps i bps ustawia się osobno dla pojedynczego adresu IP i dla podsieci, co pozwala wykrywać także carpet bombing.
Po wykryciu ataku system zakłada na routerach brzegowych reguły BGP FlowSpec dopasowane do cech ruchu, a blackholing pozostaje ostatecznością. Różnice opisujemy w materiale o FlowSpec i RTBH.
Dla ataków stanowych, takich jak SYN-ACK reflection, służy filtr inline LiveShield AIF.
Ruch pozostaje w sieci operatora. Według dokumentacji nie jest tunelowany poza infrastrukturę, więc nie pojawia się stałe opóźnienie.
Przebieg zdarzenia jest zapisany, a raport KSC zawiera m.in. czas wykrycia, czas pierwszej reguły i czas do mitygacji. Zgłoszeń do CSIRT system nie wysyła, raport generuje użytkownik.
Licencja nie jest liczona od liczby lokalizacji ani urządzeń. Zasady opisujemy we wpisie Jedna licencja na całą sieć.
Czym różni się usługa upstreamu od własnego systemu?
Różnica dotyczy zakresu widoczności, pojemności i tego, kto podejmuje decyzję. Poniższe zestawienie opiera się na publicznie dostępnych opisach usług i na dokumentacji LiveShield.
Porównanie: usługa od upstreamu a własny system anty-DDoS w sieci operatora. Zakres: ruch przez łącza dostawcy albo ruch ze wszystkich monitorowanych łączy. Pojemność: sieć dostawcy albo łącza operatora. Wykrywanie i progi: po stronie dostawcy albo operatora, osobno dla IP i podsieci. Sposób blokady: blackholing, filtracja lub centrum czyszczące albo FlowSpec z blackholingiem jako ostatecznością. Czas reakcji, dowody po ataku i model rozliczeń.
Żadna z kolumn nie wygrywa w każdym wierszu. Dlatego porównanie ma sens dopiero wtedy, gdy zestawi się je z profilem własnej sieci.
Dlaczego sam system w sieci operatora nie poradzi sobie z atakiem większym niż łącze?
Filtracja w sieci operatora działa na ruchu, który już do niej dotarł. Gdy atak wysyca łącze od upstreamu, reguły na routerze brzegowym nie przywrócą pasma, bo pakiety zdążyły je zająć. Ten przypadek omawiamy szerzej w materiale o tym, co się dzieje, gdy atak DDoS przekracza przepustowość łącza uplink.
Wtedy sygnał musi pójść wyżej: reguły FlowSpec lub blackholing do upstreamu, jeśli dostawca je udostępnia, albo przekierowanie ruchu do centrum czyszczącego. To rola, w której usługi upstreamu uzupełniają lokalną ochronę, a nie ją zastępują.
Jak wyglądał podział ról w ataku 70 Gb/s na jeden adres?
W pierwszej fali ataku system lokalny wybrał reguły, a egzekucję blackholingu przejęli upstreamy. 27 września 2026 r. w sieci jednego z warszawskich operatorów chronionych przez LiveShield rozpoczął się atak na pojedynczy adres IPv4 abonenta. Szczyt wyniósł 70,47 Gb/s i 7,15 Mpps w trzeciej sekundzie.
Lokalnie system założył reguły FlowSpec dopasowane do ruchu: odrzucenie UDP na port 80, małych datagramów UDP i fragmentów IP, a w drugiej fali także SYN TCP i ICMP.
Przy wolumenie powyżej 70 Gb/s ogłosił upstreamom blackholing adresu ofiary. Trwał 68 sekund, od 20:19:42 do 20:20:50, a następnie został zdjęty automatycznie.
Ruch od dwóch dostawców tranzytu spadł niemal do zera, a ruch z punktów wymiany nadal był wymieniany i podlegał regułom FlowSpec.
Druga fala, o wolumenie ok. 52 Gb/s, nie przekroczyła progów blackholingu. Wystarczyły reguły FlowSpec.
Dane pochodzą z panelu LiveShield i pokazują ruch przychodzący do sieci. O tym, jak ograniczyć skutki uboczne blackholingu, piszemy we wpisie o selektywnym blackholingu.
Jak połączyć własny system z usługą upstreamu?
Połączenie wymaga ustaleń z każdym upstreamem osobno, bo to dostawca decyduje, jakie sygnały przyjmie. W praktyce składa się z kilku elementów.
Ustalenie oferty upstreamu. Dla każdego dostawcy trzeba potwierdzić, czy przyjmuje FlowSpec i RTBH oraz jakie community lub parametry są wymagane. Część dostawców wymaga osobnej sesji BGP tylko do blackholingu.
Community per upstream. LiveShield ogłasza trasę blackhole z lokalnym community, a router przepisuje je na community wymagane przez danego dostawcę. Wymagania każdego dostawcy konfiguruje się w menu Upstreams (dokumentacja blackholingu).
Selektywny blackholing. Trasa trafia tylko do upstreamów, które przekroczyły własne progi. Wymaga to znakowania ruchu VLAN 802.1Q i działa wolniej niż zwykły blackholing, bo system śledzi ruch każdego upstreamu osobno. RTBH działa zwykle tylko u dostawców IP transit, a na peeringach prywatnych i w punktach wymiany zazwyczaj nie jest wspierany.
Przekierowanie do centrum czyszczącego. Jeśli operator ma umowę z takim dostawcą, system może po wykryciu ataku na prefiksie wygenerować regułę FlowSpec z akcją redirect do wskazanego VRF lub adresu IP. Przekierowanie można powiązać z progami wolumenu, a powrót ruchu po ataku może być automatyczny. Router musi obsługiwać akcję redirect, a konfiguracja jest dopasowywana do sieci operatora i dostawcy. Szczegóły opisuje wpis o łączeniu lokalnej ochrony ze scrubbing center.
Test bez czekania na atak.Manual Rules pozwalają utworzyć ręczny blackholing dla wybranego adresu, z wybranym community i upstreamami. Warto sprawdzić, czy dostawca faktycznie przyjął trasę /32 i odrzuca ruch do tego adresu.
Kiedy wystarczy usługa upstreamu, a kiedy potrzebny jest własny system?
Usługa upstreamu może wystarczyć jako pierwszy krok, gdy sieć korzysta z jednego dostawcy tranzytu, nie ma zasobów do obsługi własnego systemu i akceptuje tempo reakcji dostawcy. Własny system jest potrzebny, gdy operator ma własny ASN, kilku upstreamów, peering lub punkty wymiany i chce chronić abonentów selektywnie, bo usługa jednego dostawcy nie widzi ruchu z pozostałych kierunków.
W większości sieci o takim profilu najlepiej sprawdza się układ warstwowy: własny system wykrywa i filtruje lokalnie, a upstream dokłada pojemność tam, gdzie lokalna filtracja nie wystarcza.
Działanie panelu LiveShield można obejrzeć w publicznym demo na demo.liveshield.net. Dokumentacja techniczna jest dostępna na docs.liveshield.net, a o wdrożenie w swojej sieci można zapytać pod adresem [email protected].
