LiveShield a scrubbing center - jak lokalna ochrona DDoS i scrubbing center mogą się wzajemnie uzupełniać

LiveShield i scrubbing center nie są rozwiązaniami, między którymi operator musi wybrać raz na zawsze - to dwa różne poziomy ochrony przed DDoS, które sprawdzają się w innych sytuacjach i mogą pracować razem: LiveShield filtruje większość ataków lokalnie, w czasie rzeczywistym i bez dodatkowego opóźnienia, a scrubbing center przejmuje te przypadki, w których lokalna filtracja przestaje wystarczać - np. atak przekraczający przepustowość łącza albo wymagający głębszej, stanowej analizy ruchu.

To pytanie pojawia się coraz częściej wśród operatorów ISP, którzy już rozważają albo budują własny scrubbing center i zastanawiają się, czy to oznacza rezygnację z lokalnej ochrony, czy raczej jej rozszerzenie.

Scrubbing center to zewnętrzna infrastruktura, do której w razie ataku przekierowywany jest ruch kierowany na atakowany adres - tam jest on oczyszczany z pakietów ataku, a dopiero „czysty" ruch wraca do sieci docelowej. Ochrona on-premise, jak LiveShield, działa odwrotnie: analiza i filtracja odbywają się lokalnie, na sprzęcie operatora, bez przekierowywania ruchu na zewnątrz.

Każdy z tych modeli ma inny profil kosztów i opóźnień. Przekierowanie ruchu do scrubbing center wprowadza dodatkowy skok w trasie (routing przez zewnętrzną infrastrukturę), który dla części usług - szczególnie wrażliwych na opóźnienia - ma znaczenie nawet poza czasem trwania ataku, jeśli przekierowanie jest stałe. Filtracja lokalna nie wprowadza tego dodatkowego kroku - ruch legalny idzie swoją normalną trasą, a modyfikowany jest tylko wtedy i tylko tam, gdzie faktycznie wykryto atak.

Z drugiej strony scrubbing center ma zasób, którego pojedynczy operator lokalny zwykle nie ma - dużo większą, zagregowaną przepustowość, pozwalającą wchłonąć atak, który przekracza możliwości pojedynczego łącza uplink.

Zdecydowana większość ataków DDoS, z którymi mierzą się operatorzy ISP, nie wymaga przekierowywania ruchu na zewnątrz - wystarczy precyzyjna, szybka filtracja lokalna, którą LiveShield realizuje przez BGP FlowSpec, uzupełnianą blackholingiem (RTBH), gdy filtracja lokalna przestaje wystarczać dla konkretnego łącza. Kierowanie każdego, nawet niewielkiego ataku do zewnętrznego scrubbing center byłoby nieefektywne - dodaje opóźnienie i koszt tam, gdzie lokalna reguła FlowSpec poradziłaby sobie równie skutecznie i szybciej.

Scrubbing center ma sens jako drugi poziom ochrony, uruchamiany selektywnie, dla tej mniejszości przypadków, w których lokalna filtracja faktycznie nie wystarcza - przede wszystkim atak przekraczający przepustowość łącza uplink oraz ataki wymagające stanowej analizy ruchu, wykraczającej poza to, co da się zrealizować regułami FlowSpec na sprzęcie brzegowym operatora.

LiveShield nie działa domyślnie w modelu scrubbing center - standardowo nie przekierowuje ruchu na zewnątrz do czyszczenia, tylko mityguje atak lokalnie, na własnych routerach brzegowych operatora, mechanizmami FlowSpec i RTBH. System udostępnia jednak mechanizm event pipeline, czyli możliwość uruchamiania dowolnych akcji i skryptów w reakcji na wykrycie ataku.

Dzięki temu, jeśli operator ma umowę z zewnętrznym scrubbing center, można skonfigurować LiveShield tak, żeby w określonych warunkach - np. gdy atak przekracza zdefiniowany próg ruchu, którego lokalna filtracja nie jest już w stanie skutecznie obsłużyć - automatycznie wyzwolił przekierowanie odpowiedniego prefiksu do tego scrubbing center. Nie jest to gotowa integracja "z pudełka" dla dowolnego dostawcy scrubbingu - wymaga konfiguracji dopasowanej do konkretnego środowiska i konkretnej umowy z partnerem - ale sama funkcjonalność event pipeline w pełni na to pozwala.

W praktyce oznacza to podział ról: LiveShield odpowiada za wykrycie ataku, podjęcie pierwszej, szybkiej decyzji o mitygacji i - jeśli trzeba - wysłanie sygnału dalej, a scrubbing center włącza się dopiero wtedy, kiedy faktycznie jest potrzebny, zamiast być pierwszym i jedynym punktem obsługi każdego ruchu.

Architektura łącząca lokalną filtrację z zapasowym kanałem do scrubbing center ma największe uzasadnienie tam, gdzie operator jednocześnie: chce zachować pełną kontrolę i minimalne opóźnienie dla normalnego ruchu i większości ataków, ale liczy się też ze scenariuszem ataku, który przekroczy pojemność jego własnych łączy uplink. To dokładnie sytuacja, w jakiej znajduje się dziś wielu mniejszych i średnich operatorów ISP obserwujących rosnącą skalę ataków wolumetrycznych - stąd zresztą biorą się inicjatywy budowy wspólnych, społecznościowych scrubbing center przy punktach wymiany ruchu.

Dla operatora, który dopiero zaczyna budować ochronę przed DDoS, sensowną kolejnością jest zwykle: najpierw lokalna, szybka filtracja (FlowSpec/RTBH) pokrywająca zdecydowaną większość realnych ataków, a dopiero potem, w miarę potrzeb i skali, rozszerzenie o umowę ze scrubbing center jako zabezpieczenie na wypadek ataków przekraczających lokalną pojemność łącza.

LiveShield i scrubbing center nie konkurują ze sobą, tylko pokrywają różne warstwy ochrony przed DDoS: lokalna, szybka filtracja FlowSpec/RTBH obsługuje zdecydowaną większość ataków bez dodatkowego opóźnienia i kosztu przekierowania ruchu, a scrubbing center stanowi zapasową warstwę na wypadek ataków przekraczających możliwości lokalnej infrastruktury. Mechanizm event pipeline w LiveShield pozwala połączyć oba podejścia w jedną, spójną architekturę - automatyczne przekierowanie do scrubbing center wyzwalane dopiero wtedy, kiedy jest faktycznie potrzebne, a nie jako domyślna trasa dla każdego ruchu.

Czy LiveShield zastępuje scrubbing center? Nie, i nie taka jest jego rola. LiveShield standardowo mityguje ataki lokalnie, na routerach brzegowych operatora, przez FlowSpec i RTBH - to inny, uzupełniający się model względem scrubbing center, a nie jego zamiennik dla każdego scenariusza.

Czy LiveShield można połączyć z zewnętrznym scrubbing center? Tak. Mechanizm event pipeline pozwala skonfigurować automatyczne przekierowanie ruchu do zewnętrznego scrubbing center w reakcji na wykrycie ataku, jeśli operator ma taką umowę - wymaga to indywidualnej konfiguracji pod konkretne środowisko.

Kiedy warto rozważyć scrubbing center oprócz lokalnej ochrony DDoS? Przede wszystkim wtedy, gdy operator liczy się ze scenariuszem ataku przekraczającego przepustowość własnego łącza uplink - w takiej sytuacji lokalna filtracja fizycznie nie jest w stanie odciążyć łącza, a rozwiązaniem jest albo RTBH do upstreamu, albo przekierowanie do scrubbing center.

Czy każdy atak powinien być kierowany do scrubbing center? Nie. Zdecydowana większość ataków DDoS da się skutecznie i szybciej obsłużyć lokalną filtracją FlowSpec, bez dodatkowego opóźnienia związanego z przekierowaniem ruchu na zewnątrz. Scrubbing center ma sens jako selektywna warstwa zapasowa, nie domyślna trasa dla każdego ruchu.