LiveShield wykrywa atak DDoS i wdraża pierwszą regułę filtrowania praktycznie od razu - w kontrolowanym teście na żywym ataku system wykrył zagrożenie i zainstalował pierwszą regułę w tej samej sekundzie, w której atak wystartował. To wynik architektury opartej o analizę ruchu w pamięci, w czasie rzeczywistym, bez pośrednictwa bazy danych na krytycznej ścieżce detekcji.

W ochronie przed DDoS czas ma bezpośrednie przełożenie na skutki ataku - im dłużej trwa wykrycie i wdrożenie filtracji, tym dłużej atakujący ruch dociera do infrastruktury klienta, obciążając łącza, routery i urządzenia brzegowe. Dlatego zamiast opierać się wyłącznie na deklaracji "reagujemy błyskawicznie", pokazujemy realny test na porównywalnym ataku, przeprowadzony równolegle z innym, popularnym rozwiązaniem rynkowym.

21 listopada przeprowadzony został test na żywym ataku o parametrach 700 kpps / 6,5 Gb/s, na który złożyły się trzy jednoczesne wektory: fragmentacja IP (IP Fragments), amplifikacja DNS oraz UDP Flood. Ruch analizowany był równolegle przez LiveShield i przez inne, powszechnie stosowane w branży rozwiązanie anty-DDoS, na tej samej infrastrukturze i w tym samym momencie ataku, co pozwoliło bezpośrednio porównać czas reakcji obu systemów na identyczny ruch.

Test celowo obejmował atak wielowektorowy, a nie pojedynczy, prosty flood - w praktyce ataki DDoS rzadko ograniczają się do jednego typu ruchu, więc bardziej wiarygodny obraz daje sprawdzenie, jak system radzi sobie z kilkoma nakładającymi się wzorcami jednocześnie.

LiveShield wykrył atak i wdrożył pierwszą regułę filtrowania (na ruch DNS) w tej samej sekundzie. Porównywane rozwiązanie wykryło atak z opóźnieniem 4 sekund względem LiveShield, a jego pierwsza reguła filtrująca (również na ruch DNS) została wdrożona z opóźnieniem 18 sekund względem momentu, w którym LiveShield już filtrował ten ruch.

Przy drugim wektorze ataku (fragmentacja IP) różnica wyniosła 8 sekund na korzyść LiveShield. Trzeci wektor (UDP na konkretnym porcie docelowym) LiveShield obsłużył jako kolejną, osobną regułę - porównywane rozwiązanie mimo skonfigurowanej reguły dla tego wzorca ruchu, nie wdrożyło jej w ogóle podczas trwania testu.

Kilkanaście sekund różnicy w wdrożeniu pierwszej reguły filtrującej może wydawać się niewielkim marginesem, ale przy ataku rzędu kilku gigabitów na sekundę to kilkadziesiąt do kilkuset gigabajtów ruchu, który w tym czasie swobodnie dociera do infrastruktury klienta, zamiast zostać odfiltrowany na brzegu sieci. Dla urządzeń o ograniczonych zasobach - jak BRAS-y czy routery brzegowe niższej klasy - to właśnie te pierwsze sekundy ataku decydują, czy urządzenie zdąży się przeciążyć, zanim ochrona zacznie realnie działać.

Jeszcze istotniejszy jest przypadek trzeciej reguły z testu - sytuacja, w której system ma regułę poprawnie skonfigurowaną, ale mimo to jej nie wdraża podczas realnego ataku. To pokazuje, że sama deklarowana funkcjonalność (system "obsługuje" dany typ ataku) nie jest tym samym, co potwierdzone, praktyczne działanie tej funkcji pod obciążeniem na żywym ruchu.

Różnica w czasie reakcji wynika bezpośrednio z architektury przetwarzania danych. LiveShield analizuje ruch pakiet po pakiecie, w pamięci, a komunikacja między modułem analizującym a modułem generującym reguły odbywa się przez dedykowany, szybki protokół oparty na TCP, zaprojektowany specjalnie pod minimalizację opóźnień. Większość operacji krytycznych dla czasu detekcji nie przechodzi przez bazę danych - baza służy do przechowywania danych historycznych i statystyk, nie do podejmowania bieżących decyzji o filtracji.

Rozwiązania, które w większym stopniu opierają logikę detekcji i filtrowania na zapytaniach do bazy danych, z natury wprowadzają dodatkowe opóźnienie na każdym etapie - od wykrycia anomalii, przez klasyfikację, po wygenerowanie i wysłanie reguły. Przy pojedynczym ataku różnica rzędu kilku, kilkunastu sekund może wydawać się drobna, ale rośnie wraz ze skalą i liczbą jednoczesnych incydentów w sieci.

W kontrolowanym teście na ataku wielowektorowym o parametrach 700 kpps / 6,5 Gb/s (IP Fragments, DNS amplification, UDP Flood) LiveShield wykrył atak i wdrożył pierwszą regułę filtrowania w tej samej sekundzie, w której atak wystartował, wyprzedzając porównywane rozwiązanie rynkowe o kilka do kilkunastu sekund na kolejnych wektorach ataku - a jedną z reguł konkurencyjny system, mimo poprawnej konfiguracji, w ogóle nie wdrożył. To wynik architektury opartej na analizie ruchu w pamięci i komunikacji między modułami zaprojektowanej pod minimalny czas reakcji, a nie tylko deklarowana szybkość.

Jak szybko LiveShield wykrywa atak DDoS? W testach na żywym ruchu LiveShield wykrywał atak i wdrażał pierwszą regułę filtrowania w tej samej sekundzie, w której atak się rozpoczynał, dzięki analizie ruchu w czasie rzeczywistym, w pamięci, bez pośrednictwa bazy danych na krytycznej ścieżce detekcji.

Jakie parametry miał atak użyty w teście porównawczym? Test przeprowadzono na ataku o natężeniu 700 kpps i 6,5 Gb/s, złożonym z trzech jednoczesnych wektorów: fragmentacji IP, amplifikacji DNS oraz UDP Flood.

Czy wszystkie systemy anty-DDoS reagują w podobnym czasie? Nie. W przeprowadzonym teście porównywane rozwiązanie rynkowe wykryło ten sam atak z kilkusekundowym opóźnieniem względem LiveShield, a jedną ze skonfigurowanych reguł filtrujących w ogóle nie wdrożyło podczas trwania ataku.