Gdy atak DDoS przekracza przepustowość łącza uplink, żadna filtracja uruchomiona lokalnie u operatora nie jest w stanie temu zaradzić - łącze jest już fizycznie nasycone, zanim ruch dotrze do urządzenia filtrującego. W takiej sytuacji jedynym skutecznym mechanizmem jest RTBH (Remote Triggered Black Hole) ogłoszony w stronę operatora tranzytowego, który odrzuca ruch jeszcze przed wejściem na łącze klienta.

To jedno z pierwszych pytań, jakie pada podczas rozmów z operatorami ISP i data center o wdrożeniu ochrony anty-DDoS, i słusznie - to nie jest teoretyczny scenariusz, tylko codzienność w sieciach obsługujących ruch abonencki i hosting.

Systemy anty-DDoS oparte o BGP FlowSpec, w tym LiveShield, analizują ruch i generują precyzyjne reguły filtrujące instalowane na routerach brzegowych operatora. Mechanizm ten działa bardzo dobrze, dopóki problemem jest charakter ruchu - a nie jego ilość względem dostępnego pasma.

Punkt krytyczny wygląda następująco: FlowSpec jest ogłaszany lokalnie, na routerach, które znajdują się już za łączem uplink. Jeśli atak generuje więcej ruchu, niż łącze fizycznie przenosi, część tego ruchu nigdy nie dotrze do routera z zainstalowaną regułą FlowSpec - łącze zostanie nasycone wcześniej, niezależnie od tego, jak precyzyjna byłaby reguła filtrująca.

Innymi słowy: FlowSpec rozwiązuje problem jakości ruchu na łączu, nie problem jego ilości powyżej przepustowości łącza.

Kiedy jedynym skutecznym mechanizmem jest RTBH do upstreamu

W scenariuszu, w którym wolumen ataku przekracza przepustowość uplinku, jedynym mechanizmem, który realnie odciąża łącze, jest RTBH (Remote Triggered Black Hole) ogłoszony nie na własnych routerach, ale w stronę operatora tranzytowego (upstreamu).

RTBH działa na zupełnie innej zasadzie niż FlowSpec: zamiast precyzyjnie filtrować konkretne pakiety, informuje sieć operatora tranzytowego, żeby cały ruch kierowany na dany adres IP (najczęściej /32) został odrzucony jeszcze zanim wejdzie na łącze klienta. To rozwiązanie brutalne - odcina też ruch legalny kierowany na ten sam adres - ale skuteczne tam, gdzie FlowSpec fizycznie nie ma szans zadziałać.

LiveShield generuje reguły RTBH automatycznie, na podstawie tych samych progów detekcji, które odpowiadają za FlowSpec, i ogłasza je przez sesję BGP skonfigurowaną z routerem operatora. Kluczowe jest jednak to, że skuteczność tego mechanizmu zależy od tego, co dzieje się dalej - czyli od tego, jak szybko i w jaki sposób reaguje na te ogłoszenia operator tranzytowy.

Jak LiveShield skraca czas do interwencji, zanim zadziała RTBH u upstreamu

Skoro finalna skuteczność RTBH zależy od upstreamu, przewaga systemu anty-DDoS rozgrywa się na etapie, który operator faktycznie kontroluje: jak szybko atak zostanie wykryty i jak szybko poprawna reguła RTBH trafi do operatora tranzytowego. Im krótszy ten czas, tym krótsze okno, w którym łącze pozostaje nasycone, zanim upstream zdąży zareagować.

LiveShield analizuje ruch pakiet po pakiecie, w czasie rzeczywistym i w pamięci, zamiast opierać się na zagregowanych danych z NetFlow czy sFlow, które z natury dostarczają obraz sytuacji z opóźnieniem rzędu dziesiątek sekund do kilku minut. W praktyce oznacza to wykrycie ataku i wygenerowanie pierwszych reguł ochronnych rzędu pojedynczych sekund od jego rozpoczęcia, a nie po fakcie, gdy łącze jest już od dłuższego czasu nasycone.

Drugi element, który skraca czas reakcji, to automatyzacja. Mechanizm event pipeline pozwala zdefiniować z góry, co dokładnie ma się wydarzyć w momencie wykrycia ataku przekraczającego określony próg - wygenerowanie i ogłoszenie RTBH, powiadomienie zespołu NOC, wywołanie zewnętrznego skryptu (uruchamiającego np. scrubbing) czy zapis zdarzenia do systemu ticketowego. Operator nie reaguje ręcznie po fakcie, tylko ma gotowy, wcześniej przetestowany scenariusz, który uruchamia się sam.

Dla operatorów, którzy mają już (lub planują) umowę z zewnętrznym centrum scrubbingowym, event pipeline LiveShield pozwala spiąć wykrycie ataku z automatycznym przekierowaniem ruchu do takiego centrum, zamiast wyłącznie blokować adres przez RTBH. Nie jest to gotowa integracja z pudełka - wymaga konfiguracji pod konkretną topologię sieci i konkretnego dostawcę scrubbingu - ale sama funkcjonalność event pipeline na to pozwala, więc LiveShield może pełnić rolę warstwy detekcyjno-decyzyjnej także w architekturze, która ostatecznie nie kończy się na RTBH.

To jest rozróżnienie, które warto zrozumieć przed wdrożeniem jakiegokolwiek systemu anty-DDoS, nie tylko LiveShield: system lokalny odpowiada za wykrycie ataku i wygenerowanie poprawnej reguły RTBH. To, jak szybko ta reguła realnie odetnie ruch przed wejściem na łącze, zależy od konfiguracji i polityki operatora tranzytowego, nie od systemu anty-DDoS.

W praktyce oznacza to, że przed wdrożeniem ochrony przed atakami wolumetrycznymi przekraczającymi pojemność łącza, operator ISP powinien ustalić bezpośrednio ze swoim dostawcą tranzytu:

Bez tej rozmowy z upstreamem system anty-DDoS może działać poprawnie - wykryć atak i wygenerować regułę we właściwym czasie - a mimo to nie ochronić łącza, jeśli sam upstream nie honoruje otrzymywanych ogłoszeń albo reaguje na nie zbyt wolno.

Nie ma lokalnej alternatywy. Jeśli wolumen ataku przekracza przepustowość łącza uplink, jedyną drogą jest odcięcie ruchu bliżej źródła - czyli po stronie sieci operatora tranzytowego lub jeszcze dalej, u kolejnych dostawców w łańcuchu. Rozwiązania działające wyłącznie lokalnie u klienta, niezależnie od producenta i mechanizmu filtracji, fizycznie nie są w stanie przetworzyć ruchu, który nie zmieści się na łączu.

Dlatego przy projektowaniu ochrony anty-DDoS dla sieci ISP warto od początku traktować RTBH do upstreamu jako integralną część architektury, a nie mechanizm zapasowy uruchamiany tylko w wyjątkowych przypadkach.

Atak DDoS przekraczający przepustowość łącza uplink to scenariusz, w którym lokalna filtracja ruchu (FlowSpec) przestaje wystarczać, ponieważ łącze zostaje nasycone zanim ruch dotrze do urządzenia filtrującego. Jedynym skutecznym mechanizmem w tej sytuacji jest RTBH ogłaszany do operatora tranzytowego, a jego realna skuteczność zależy od polityki i szybkości reakcji tego operatora - dlatego ustalenia z dostawcą tranzytu powinny być częścią przygotowań do wdrożenia ochrony anty-DDoS, a nie elementem pominiętym do czasu pierwszego dużego ataku.

Najczęściej zadawane pytania

Czy FlowSpec zatrzyma atak większy niż moje łącze uplink? Nie. FlowSpec jest ogłaszany na routerach klienta, znajdujących się już za łączem uplink - jeśli atak nasyca to łącze, część ruchu nigdy nie dotrze do reguły filtrującej.

Co to jest RTBH i czym różni się od FlowSpec? RTBH (Remote Triggered Black Hole) to mechanizm odcinający cały ruch kierowany na dany adres IP, ogłaszany do operatora tranzytowego, dzięki czemu ruch jest odrzucany jeszcze przed wejściem na łącze klienta. W przeciwieństwie do FlowSpec nie filtruje precyzyjnie - blokuje adres w całości, wraz z ruchem legalnym.

Czy każdy operator tranzytowy honoruje ogłoszenia RTBH? To zależy od konkretnego dostawcy tranzytu i wymaga ustalenia bezpośrednio z nim - w tym akceptowanej community BGP i czasu reakcji na ogłoszenie.