LiveShield wykrywa atak DDoS, licząc w czasie rzeczywistym konkretne progi ruchu - pakiety na sekundę i przepustowość - osobno dla każdego analizowanego protokołu, osobno dla pojedynczych adresów IP i osobno dla całych podsieci. Nie jest to nieprzejrzysty mechanizm typu "czarna skrzynka" opisywany ogólnie jako "sztuczna inteligencja" - to zestaw jawnie konfigurowalnych parametrów, które operator ustawia i dostraja pod charakterystykę własnej sieci.

To rozróżnienie ma znaczenie praktyczne, nie tylko marketingowe: operator, który wie dokładnie, co system mierzy i po czym podejmuje decyzję, jest w stanie przewidzieć jego zachowanie, dostroić je pod własną sieć i zdiagnozować, dlaczego dana reguła się uruchomiła - czego nie da się zrobić z systemem opisywanym wyłącznie hasłem "AI".

System liczy progi osobno dla każdego z kilkunastu analizowanych protokołów i typów ruchu, obejmujących m.in.: całkowity ruch IP, TCP, UDP, ruch TCP-SYN (nawiązywanie połączeń), ICMP, fragmentację IP (IPFRAG), małe pakiety UDP (SMALL_UDP) oraz typowe wektory amplifikacji wykorzystywane w atakach DNS, NTP, SSDP, CHARGEN, SNMP, CLDAP czy Memcached. Dla jednego prefiksu system utrzymuje pełny komplet tych progów zarówno na poziomie pojedynczego adresu IP, jak i na poziomie całej podsieci.

Rozdzielenie progów per-protokół ma bezpośrednie znaczenie dla precyzji reakcji: zamiast jednej ogólnej reguły "za dużo ruchu na ten adres", system rozpoznaje, że przekroczony został akurat próg dla ruchu UDP-amplifikacji albo akurat dla fragmentów IP, i reaguje regułą dopasowaną do konkretnego wektora ataku, a nie blokadą całego ruchu na danym adresie.

LiveShield analizuje ruch jednocześnie na poziomie pojedynczych adresów IP i na poziomie całych podsieci, ponieważ atak skierowany w pojedynczy adres i atak rozproszony na wiele adresów jednocześnie (carpet bombing) wymagają innego podejścia do wykrycia.

Detekcja per-IP sprawdza się przy klasycznym ataku na jeden cel - próg jest przekraczany wyraźnie na jednym adresie i reguła może zejść nawet do pojedynczego adresu (maska /32). Sam atak rozproszony na wiele adresów jednocześnie jest z definicji zaprojektowany tak, żeby ominąć progi liczone per-IP - każdy pojedynczy adres dostaje relatywnie niewielki wolumen ruchu, niewystarczający do przekroczenia progu, mimo że suma ruchu na całą podsieć jest już atakiem. Dlatego progi per-subnet trzeba skonfigurować osobno, niezależnie od progów per-IP - jedno nie zastępuje drugiego.

Gdy system wykryje wzorzec wskazujący na atak rozproszony na wiele adresów, uruchamiają się wyłącznie reguły per-subnet, a system automatycznie szuka największej możliwej maski, która pokryje atakowane adresy możliwie precyzyjnie. Mechanizm próbuje najpierw najwęższej możliwej maski (np. /32), a jeśli to się nie sprawdza - typowe dla prawdziwego carpet bombingu, gdzie atak faktycznie obejmuje wiele różnych adresów - system stopniowo rozszerza regułę, np. do /29, /28, aż do całej atakowanej podsieci, w zależności od tego, jak szeroko rozłożone są atakowane adresy.

Ten mechanizm jest jednocześnie zabezpieczeniem przed przeciążeniem samego systemu detekcji - bez agregacji do szerszych reguł, atak na setki czy tysiące adresów jednocześnie musiałby wygenerować równie dużo osobnych reguł /32, co obciążałoby zarówno system, jak i tablice reguł na routerach brzegowych.

LiveShield oferuje dwa tryby filtrowania dla poszczególnych protokołów: prefiltering, który opiera się wyłącznie na przekroczeniu progu ruchu (pakiety na sekundę i/lub przepustowość) bez dodatkowej analizy zawartości pakietów, oraz advanced filtering, który dodatkowo analizuje bardziej szczegółowe cechy ruchu, np. porty docelowe czy flagi TCP, żeby wygenerować regułę węższą i bardziej dopasowaną do konkretnego ataku.

Wybór między tymi trybami to kompromis między precyzją a ryzykiem: prefiltering reaguje szybciej i prościej, ale przy nieostrożnie dobranych progach może odciąć też część legalnego ruchu o podobnej charakterystyce. Advanced filtering pozwala zawęzić regułę dokładniej, ale wymaga, żeby dodatkowe kryteria (np. konkretny port) faktycznie odpowiadały charakterowi ruchu na danym typie adresów - w praktyce oznacza to, że dla różnych grup adresów w sieci (np. zwykli klienci a serwery, które nasłuchują na wielu portach) dobiera się różne profile filtrowania, a nie jedną uniwersalną regułę dla całej sieci.

System nie ma jednego uniwersalnego zestawu progów odpowiedniego dla każdej sieci, ponieważ charakter normalnego ruchu różni się istotnie między różnymi segmentami tej samej infrastruktury - inny bywa typowy ruch na pulach adresowych za NAT-em, inny na adresach przypisanych bezpośrednio klientom, a jeszcze inny na adresach serwerowych, które z natury odbierają duży, zróżnicowany ruch od wielu źródeł jednocześnie.

Dlatego wdrożenie LiveShield w praktyce obejmuje etap obserwacji ruchu produkcyjnego i iteracyjnego dostrajania progów pod konkretną sieć, zamiast jednorazowej konfiguracji uznawanej za ostateczną. Dotyczy to zarówno progów per-protokół, jak i progu decydującego o eskalacji z FlowSpec do RTBH (opartego o procent ruchu, który system zdołał odfiltrować) - konfiguracja jest w pełni dostępna dla operatora i można ją zmieniać w miarę zbierania danych z realnego ruchu, bez ingerencji dostawcy.

Detekcja ataków w LiveShield opiera się na jawnym, konfigurowalnym zestawie progów ruchu liczonych osobno dla każdego z kilkunastu protokołów i wektorów ataku, jednocześnie na poziomie pojedynczych adresów IP i całych podsieci. Ataki rozproszone na wiele adresów wykrywane są przez osobny mechanizm agregacji, który automatycznie dobiera najwęższą skuteczną maskę podsieci, a poziom szczegółowości filtrowania (prefiltering albo advanced filtering) operator dobiera indywidualnie do charakteru ruchu w danym segmencie sieci. To właśnie ta przejrzystość i konfigurowalność, a nie ogólne hasło "sztuczna inteligencja", odpowiada za skuteczność i przewidywalność systemu w praktyce.

Jak LiveShield wykrywa atak typu carpet bombing? Gdy wzorzec ruchu wskazuje na atak rozproszony na wiele adresów jednocześnie, uruchamiają się reguły per-subnet, a system automatycznie dobiera najwęższą możliwą maskę podsieci pokrywającą atakowane adresy, stopniowo ją rozszerzając, jeśli węższa maska nie wystarcza.

Czym różni się prefiltering od advanced filtering? Prefiltering reaguje wyłącznie na przekroczenie progu ruchu, bez analizy dodatkowych cech pakietów. Advanced filtering dodatkowo analizuje szczegóły takie jak port docelowy czy flagi TCP, żeby wygenerować węższą, bardziej precyzyjną regułę filtrującą.

Czy progi detekcji trzeba dostrajać ręcznie po wdrożeniu? Tak. Charakter normalnego ruchu różni się między segmentami sieci (np. adresy za NAT-em, adresy klienckie, adresy serwerowe), dlatego wdrożenie obejmuje etap obserwacji i iteracyjnego dostrajania progów pod konkretną infrastrukturę.