Ochrona przed DDoS w sieci operatorskiej - kryteria wyboru

Decyzja o wdrożeniu ochrony przed atakami DDoS rzadko zapada w spokojnych warunkach. Zwykle poprzedza ją incydent - atak, który zapchał łącze, albo sparaliżował obsługę klientów na kilka godzin. Pod presją czasu łatwo o wybór podyktowany bardziej materiałami marketingowymi dostawcy niż realnymi potrzebami sieci. Efekt bywa taki, że system dobrze wygląda w ofercie, ale nie pasuje do architektury operatora albo generuje koszty, których nikt się nie spodziewał.

Poniżej zebraliśmy kryteria, które warto sprawdzić przed podjęciem decyzji - i pokazujemy, jak wypada na ich tle LiveShield.

Pierwsze pytanie, jakie warto sobie zadać, to gdzie faktycznie odbywa się analiza i filtrowanie ruchu. Część rozwiązań działa on-premise, bezpośrednio w infrastrukturze operatora - cały ruch pozostaje w sieci, a decyzje o filtrowaniu zapadają lokalnie. Inne przekierowują ruch na zewnątrz, do centrum czyszczącego zarządzanego przez dostawcę.

Różnica nie jest tylko architektoniczna. Przekierowanie ruchu oznacza dodatkowe opóźnienie, zależność od dostępności usługi zewnętrznej i koszt transferu, który przy dużym ataku wolumetrycznym potrafi zaskoczyć.

LiveShield jest zaprojektowany jako system on-premise - instalowany bezpośrednio w infrastrukturze operatora, bez przekierowywania ruchu na zewnątrz. Analiza i mitygacja odbywają się lokalnie, co eliminuje dodatkowe opóźnienie i uzależnienie od usługi zewnętrznej, a ruch przez cały czas pozostaje pod kontrolą operatora.

System anty-DDoS, który nie integruje się natywnie z waszym BGP, to system, który wymaga dodatkowej pracy integracyjnej. Warto sprawdzić, czy rozwiązanie ma własny demon BGP, czy jest zależne od zewnętrznego oprogramowania, oraz czy obsługuje zarówno BGP FlowSpec, jak i RTBH (remote-triggered blackholing).

FlowSpec pozwala na precyzyjne, granularne reguły filtrowania rozgłaszane bezpośrednio do routerów brzegowych, bez ręcznej konfiguracji ACL. Blackholing jest prostszym, bardziej brutalnym mechanizmem - skutecznym, gdy trzeba natychmiast odciąć zaatakowany adres kosztem jego całkowitej niedostępności.

LiveShield ma własny demon BGP i obsługuje oba mechanizmy - FlowSpec i selektywny RTBH - dobierając odpowiedni w zależności od charakteru ataku, bez potrzeby ręcznej konfiguracji po stronie operatora. Rozwiązanie jest przetestowane na sprzęcie, z którym pracuje większość operatorów ISP w Polsce: routerach Juniper (MX, PTX) oraz Cisco (ASR1k, ASR9k, NCS5500 w wariantach SE, seria 8000). To nie deklaracja zgodności ze standardem "na papierze" - to lista sprzętu, na którym konfiguracja była faktycznie sprawdzana.

Klasyczna detekcja skupiona na pojedynczym adresie IP dobrze radzi sobie z prostym atakiem wolumetrycznym, ale gubi się przy atakach typu carpet bombing - rozproszonych na wiele adresów lub całą podsieć jednocześnie, gdzie ruch na każdy pojedynczy IP osobno wygląda niegroźnie. To coraz częstszy wektor, bo skutecznie omija mechanizmy zaprojektowane pod kątem pojedynczego celu.

LiveShield wykrywa ataki zarówno per-IP, jak i per-subnet, automatycznie agregując rozproszone ataki na wiele adresów w jedną, możliwie wąską regułę filtrowania - tak, żeby ograniczyć wpływ na ruch, który nie jest częścią ataku. Mechanizm anti-overload dodatkowo chroni sam system detekcji przed przeciążeniem przy dużej skali jednoczesnych incydentów.

Operatorzy podlegający ustawie o Krajowym Systemie Cyberbezpieczeństwa mają obowiązek trzystopniowego raportowania incydentu poważnego do właściwego CSIRT: wczesne ostrzeżenie w ciągu 24 godzin od wykrycia, pełne zgłoszenie w ciągu 72 godzin, oraz sprawozdanie końcowe w ciągu miesiąca od zgłoszenia. W praktyce oznacza to, że w trakcie ataku ktoś musi jednocześnie reagować operacyjnie i przygotowywać dokumentację zgodną z tymi terminami.

Moduł raportowy LiveShield generuje gotowe zestawienie danych o ataku - czas trwania, wektor, skalę, podjęte działania mitygacyjne - w formie, którą można od razu wykorzystać przy przygotowaniu zgłoszenia do CSIRT. To realnie skraca czas potrzebny na dokumentację w oknie 24-godzinnym, kiedy liczy się każda godzina.

Warto to jednak nazwać uczciwie: moduł, który dostarcza dane do raportu, to nie to samo co gotowe narzędzie compliance. Ostateczna ocena zgodności z KSC i przygotowanie zgłoszenia pozostaje po stronie operatora - LiveShield odciąża zespół w newralgicznym momencie, ale nie zastępuje odpowiedzialności regulacyjnej.

Kolejne pytanie to, na czym system w ogóle ma działać. Część rozwiązań wymaga dedykowanego, zamkniętego appliance - co oznacza sztywny koszt wejścia i brak elastyczności przy skalowaniu. Inne działają na standardowym sprzęcie serwerowym, o ile spełnia on określone minima.

LiveShield działa na standardowym sprzęcie x86 wspierającym DPDK, bez konieczności inwestowania w dedykowany appliance. Moduł odpowiedzialny za przetwarzanie pakietów w czasie rzeczywistym (Worker) wymaga fizycznej maszyny - to jedyny komponent z takim wymogiem. Pozostałe dwa moduły, Manager i Analyser, mogą działać wirtualnie, co ułatwia dopasowanie wdrożenia do infrastruktury, którą operator już ma.

Orientacyjne minimum sprzętowe: liczba rdzeni fizycznych wyliczana ze wzoru Gbps ÷ 10 + 4 (nie mniej niż 8 rdzeni), 32 GB+ RAM, dysk NVMe od 60 GB oraz karta sieciowa kompatybilna z DPDK - rekomendowane modele to Intel X710, XXV710, E810 lub X520, ewentualnie karty Mellanox ConnectX. Zero zależności od jednego producenta sprzętu.

Modele rozliczeniowe różnią się mocno między dostawcami. Część rozlicza się od przepustowości sieci - jeden parametr, jedna cena, wszystkie funkcje w cenie. Inne stosują licencjonowanie modułowe, gdzie zaawansowane filtrowanie, obsługa FlowSpec czy raportowanie to osobne pozycje kosztowe, dokupywane oddzielnie.

Licencja LiveShield jest powiązana wyłącznie z ruchem przychodzącym (Gbps) - bez podziału na moduły, bez dodatkowych opłat za FlowSpec, filtrowanie zaawansowane czy raportowanie. Pełna funkcjonalność systemu mieści się w jednej cenie, co ułatwia przewidywanie kosztów przy wzroście ruchu w sieci.

Ostatni, często pomijany element to to, co dzieje się po podpisaniu umowy. Czy dostawca oferuje konsultacje podczas samodzielnego wdrożenia? Czy jest możliwość przetestowania rozwiązania przed zakupem, na realnym ruchu? Jak wygląda w praktyce czas reakcji na pytania techniczne - szczególnie te zadawane w trakcie pierwszej konfiguracji progów detekcji, kiedy błędne ustawienia mogą oznaczać fałszywe alarmy albo, gorzej, przepuszczony atak.

W cenie licencji LiveShield oferujemy bezpłatne konsultacje podczas wdrożenia oraz weryfikację poprawności konfiguracji przez naszego inżyniera.
Dostępna jest też licencja demonstracyjna do przetestowania systemu na realnym ruchu przed decyzją zakupową.

Checklista - podsumowanie

Przed podjęciem decyzji warto mieć odpowiedź na każde z poniższych pytań:

Na każde z tych pytań LiveShield ma konkretną, sprawdzalną odpowiedź - a nie tylko deklarację zgodności ze standardem.