Atak DDoS w sieci operatorskiej rzadko wygląda tak, jak przedstawiają go materiały marketingowe dostawców chmurowych. To nie jest pojedynczy incydent na jednym serwerze, tylko problem na poziomie łącza, routera brzegowego i całej puli adresowej klientów. Dla ISP, data center czy operatora telekomunikacyjnego pytanie nie brzmi "czy nas to spotka", tylko "co się stanie, gdy 20 Gbps śmieciowego ruchu trafi na nasz upstream w środku nocy". Ten artykuł to praktyczne spojrzenie na ochronę DDoS z perspektywy sieci operatorskiej: jakie są rodzaje ataków, jak realnie wygląda anty-DDoS na poziomie infrastruktury i dlaczego system anty-DDoS działający on-premise, na własnym sprzęcie, ma dla operatora inne uzasadnienie niż dla pojedynczej firmy z jedną witryną.

Atak DDoS to rozproszony atak odmowy usługi - ruch generowany jednocześnie z wielu źródeł, którego celem jest wyczerpanie zasobów: pasma, tablicy połączeń, CPU na urządzeniach brzegowych. W przypadku pojedynczej firmy ofiarą jest zwykle jeden adres IP lub jedna domena. W sieci operatora skala problemu jest inna - atak potrafi uderzyć w jeden adres z puli klienta, a mimo to nasycić całe łącze upstream, zabierając przepustowość wszystkim pozostałym klientom podłączonym do tego samego styku. To zjawisko określane czasem jako "collateral damage" jest dla ISP dotkliwsze niż sam fakt niedostępności jednego serwisu - bo płaci za nie cała sieć, nie tylko atakowany klient.

Drugi problem specyficzny dla operatorów to tzw. carpet bombing - atak, w którym ruch rozkładany jest na wiele adresów IP z jednej podsieci lub całego bloku klienta, tak by pojedynczy adres nie przekroczył progu alarmowego, a suma ruchu na całą podsieć i tak zalała łącze. Klasyczne systemy monitorujące ruch per adres IP takiego wzorca nie wyłapią - potrzebna jest agregacja na poziomie prefiksu.

Ataki wolumetryczne - najprostsze do zrozumienia i wciąż najczęstsze. Ich celem jest nasycenie pasma: UDP flood, amplifikacja DNS, NTP czy inne techniki reflection/amplification, gdzie atakujący wysyła niewielkie zapytanie z podszytym adresem źródłowym ofiary, a odpowiedź wraca wielokrotnie większa. Obrona przed tym typem ataku musi działać na styku z upstreamem, zanim ruch w ogóle wejdzie do sieci operatora - stąd znaczenie mechanizmów takich jak BGP FlowSpec i blackholing.

Ataki protokołowe - celują w stan połączenia, nie w samo pasmo. Klasyczny SYN flood potrafi położyć router czy serwer przy relatywnie niewielkim wolumenie ruchu, bo wyczerpuje tablicę połączeń, a nie łącze. To właśnie ten typ ataku bywa najbardziej podstępny - alarm od strony wolumenu może się nie włączyć, a usługa już nie odpowiada.

Coraz częściej pojawia się też wariant, który łączy stateful atak protokołowy z próbą ominięcia klasycznej ochrony wolumetrycznej - fala SYN-ACK, ACK czy RST bez odpowiadającego wychodzącego SYN, kierowana bezpośrednio na styk BRAS/koncentrator. Wolumen bywa zbyt niski, żeby wywołać reakcję systemu opartego wyłącznie na progach ruchu, a mimo to potrafi zapchać stan połączeń na urządzeniach dostępowych.

Jak działa ochrona przed DDoS na poziomie sieci

Skuteczna ochrona DDoS dla operatora opiera się na kilku uzupełniających się mechanizmach, nie na jednym uniwersalnym rozwiązaniu.

Detekcja przez analizę ruchu. System anty-DDoS musi widzieć ruch, żeby cokolwiek wykryć - najczęściej przez port SPAN lub optyczny Link TAP, wyłącznie w trybie odbioru z kierunku upstream, bez ingerencji w ścieżkę pakietów. Dzięki temu detekcja nie wprowadza żadnego ryzyka dla ruchu produkcyjnego - w razie awarii samego systemu detekcji sieć dalej działa normalnie.

Mitygacja przez BGP FlowSpec. Gdy system wykryje atak, generuje reguły FlowSpec i przekazuje je do routera brzegowego operatora przez sesję BGP. Router programuje reguły w sprzęcie i filtruje ruch na wczesnym etapie, zanim obciąży resztę infrastruktury. To rozwiązanie działa lokalnie, między systemem anty-DDoS a własnymi routerami operatora - nie wymaga wsparcia FlowSpec od dostawcy upstream, wystarczy że upstream honoruje standardowe community blackholingowe. Warunkiem jest sprzęt z obsługą FlowSpec w hardware - sprawdzona lista obejmuje m.in. Juniper MX/PTX oraz Cisco ASR1k/9k/NCS5500 SE/8000. Przy innym sprzęcie, np. Huawei, standardowy RTBH powinien zadziałać, ale wsparcie FlowSpec wymaga weryfikacji per model.

Blackholing i selektywny RTBH. Tam, gdzie FlowSpec nie wystarcza - bo atak przekracza możliwości upstreamów albo sprzęt go nie wspiera - pozostaje RTBH, czyli przekierowanie ruchu do atakowanego adresu w null route. Różnica między prostym blackholingiem całej podsieci a selektywnym blackholingiem pojedynczych adresów /32 jest dla operatora kluczowa - ten drugi wariant pozwala odciąć tylko realnie atakowany adres, zamiast poświęcać całą pulę klienta, w tym adresy, które w ogóle nie są celem ataku.

Ochrona przed carpet bombingiem. Wymaga agregacji ruchu na poziomie prefiksu, nie pojedynczego adresu IP - inaczej rozproszony atak na całą podsieć zostanie niezauważony, mimo że sumarycznie zalewa łącze.

Filtracja stanowa inline. Dla ataków protokołowych typu SYN-ACK/ACK/RST bez odpowiadającego wychodzącego połączenia, ochrona przed DDoS na poziomie FlowSpec czy RTBH nie wystarczy - to atak na stan połączenia, nie na wolumen. Tu potrzebny jest silnik śledzący dwukierunkowo stan połączeń TCP, umieszczony inline między routerem brzegowym a BRAS-em lub koncentratorem, który odrzuca pakiety niepasujące do żadnej znanej sesji. To rozwiązanie ma sens jako warstwa uzupełniająca, nie zastępująca ochronę wolumetryczną - jeśli atak nasyca samo łącze upstream, żaden filtr stanowy tego nie naprawi, dopóki RTBH nie odciąży łącza.

Dla firmy z jedną witryną naturalnym wyborem bywa usługa chmurowa - przekierowanie ruchu przez zewnętrzne centrum danych w momencie ataku. Dla operatora, który sam jest dostawcą łącza, sytuacja wygląda inaczej. Przekierowywanie całego ruchu klientów przez zewnętrzną infrastrukturę oznacza dodatkowe opóźnienie, zależność od trzeciej strony i utratę kontroli nad tym, jak dokładnie filtrowany jest ruch własnych klientów.

System anty-DDoS działający on-premise, na sprzęcie operatora, adresuje ten problem inaczej - detekcja i mitygacja dzieją się w tej samej sieci, bez wyprowadzania ruchu na zewnątrz, a decyzje o tym, co jest atakiem, a co nie, podejmuje operator, nie zewnętrzny dostawca. To podejście wymaga własnego sprzętu i utrzymania, ale eliminuje zależność od trzeciej strony w najbardziej krytycznym momencie - w trakcie ataku.

Ochrona przed DDoS to dziś nie tylko kwestia dostępności usługi, ale też obowiązek regulacyjny. Operatorzy usług kluczowych i ważnych objęci dyrektywą NIS2 oraz krajową ustawą o krajowym systemie cyberbezpieczeństwa muszą wdrażać odpowiednie środki techniczne i organizacyjne w zakresie zarządzania ryzykiem, a incydenty DDoS o odpowiedniej skali podlegają obowiązkowi zgłoszenia do CSIRT. System anty-DDoS, który generuje gotowe raporty zgodne z wymaganym zakresem danych, skraca czas potrzebny na wypełnienie tego obowiązku - choć samo złożenie zgłoszenia w systemie CSIRT wciąż pozostaje po stronie operatora.

Ochrona DDoS dla operatora to nie jeden produkt, tylko zestaw uzupełniających się mechanizmów dobranych do warstwy ataku: FlowSpec i selektywny RTBH na poziomie sieci dla ataków wolumetrycznych, agregacja per prefiks dla carpet bombingu, filtracja stanowa inline dla ataków protokołowych, które omijają klasyczne progi wolumenowe. System anty-DDoS działający on-premise, na własnym sprzęcie i we własnej sieci, daje operatorowi coś, czego usługa chmurowa dać nie może - pełną kontrolę nad tym, jak i kiedy ruch jest filtrowany, bez pośrednika w najbardziej krytycznym momencie.

Jeśli zastanawiasz się, jak wygląda wdrożenie systemu anty-DDoS LiveShield w Waszej sieci - jaki sprzęt będzie potrzebny przy Waszym wolumenie ruchu i jakie routery brzegowe wspierają FlowSpec - najprostszym punktem wyjścia jest rozmowa o konkretnej topologii sieci.