RTBH (Remote Triggered Black Hole) blokuje cały ruch kierowany na dany adres IP, w tym ruch legalny - to jego fundamentalna różnica względem FlowSpec, który filtruje wyłącznie pakiety pasujące do konkretnej sygnatury ataku. LiveShield minimalizuje ten efekt uboczny, priorytetyzując FlowSpec i uruchamiając RTBH dopiero jako mechanizm awaryjny, gdy filtracja precyzyjna przestaje wystarczać - a nie jako pierwszą i jedyną reakcję na każdy atak.

To rozróżnienie ma bezpośrednie przełożenie na jakość usługi w trakcie ataku: źle skonfigurowana mitygacja potrafi wyrządzić klientowi więcej szkody niż sam atak, odcinając mu dostęp do usługi, którą miała chronić.

FlowSpec pozwala zdefiniować regułę filtrującą na podstawie konkretnych cech ruchu - adresu docelowego, protokołu, portu źródłowego lub docelowego, flag TCP czy rozmiaru pakietu - i zainstalować ją bezpośrednio w sprzętowym forwarding path routera brzegowego. Router odrzuca wyłącznie pakiety pasujące do tej sygnatury, a cała reszta ruchu do danego adresu przechodzi bez zakłóceń.

RTBH działa zupełnie inaczej: ogłasza całą trasę do adresu IP (najczęściej /32) jako czarną dziurę, przez co router odrzuca wszystko, co jest do niego kierowane - ruch ataku, ale też ruch legalny idący na ten sam adres. Nie ma tu selekcji na poziomie pakietu, tylko całkowite odcięcie celu.

Z tego wynika prosta zasada: tam, gdzie da się zastosować FlowSpec, pozostały ruch klienta nie cierpi. RTBH jest rozwiązaniem ostatecznym, stosowanym wtedy, gdy FlowSpec przestaje wystarczać, a nie domyślnym pierwszym krokiem.

Reguły filtrowania (FlowSpec) i reguły blackholingowe (RTBH) są sprawdzane niezależnie od siebie, na podstawie osobno skonfigurowanych progów dla tego samego prefiksu. Jeśli próg reguły filtrującej zostanie przekroczony jako pierwszy, system uruchamia FlowSpec. Jednocześnie, równolegle, sprawdzany jest próg blackholingowy - i dopóki ruch go nie przekroczy, RTBH się nie uruchamia.

W praktyce oznacza to, że jeśli progi blackholingowe są ustawione wyżej niż progi filtrowania - co jest zalecaną konfiguracją - to FlowSpec przejmuje mitygację jako pierwszy, a RTBH włącza się dopiero, gdy mimo filtracji FlowSpec ruch nadal rośnie i zbliża się do granicy, przy której zagrożona jest saturacja łącza. Typowy wzorzec konfiguracji wygląda tak: lokalne filtrowanie FlowSpec aż do osiągnięcia krytycznej ilości ruchu, a dopiero powyżej tego poziomu RTBH jako zabezpieczenie przed wysyceniem styku ze światem.

Rekomendowana praktyka przy konfiguracji progu blackholingowego to pozostawienie w profilu wyłącznie kontroli na poziomie adresu IP (bez rozbijania na protokoły) i ustawienie progu blisko maksymalnej ilości ruchu, jaką dany styk jest w stanie faktycznie przyjąć - a nie blisko zera. Dzięki temu RTBH faktycznie chroni przed nasyceniem portów, zamiast uruchamiać się przy każdym niewielkim ataku, który FlowSpec i tak by obsłużył.

System ocenia reguły filtrowania w taki sam sposób, jak router ocenia trasy w routingu - bardziej specyficzny prefiks ma wyższy priorytet niż ogólny. Dzięki temu dla pojedynczego, krytycznego adresu (np. serwera usługowego) w obrębie szerszej podsieci można skonfigurować osobną regułę /32 z innymi progami niż reguła obejmująca całą podsieć, i to ta bardziej specyficzna reguła zostanie zastosowana jako pierwsza.

To pozwala np. ustawić dla zwykłych klientów agresywne, niskie progi na ruch TCP-SYN kierowany do nich (bo standardowo nie powinni otrzymywać dużo takich pakietów), a dla serwerów, które z natury odbierają duży ruch SYN od wielu klientów jednocześnie, zostawić wyższe progi albo inny mechanizm filtracji, żeby nie odcinać im ruchu, który jest dla nich normalny.

Ten mechanizm ma jedno wyraźne ograniczenie: działa dobrze, gdy chcemy wyróżnić pojedynczy adres w obrębie ataku na całą podsieć. Nie da się natomiast w prosty sposób wyłączyć konkretnego adresu z mitygacji, jeśli atak obejmuje całą podsieć i to na poziomie całej podsieci działa już szeroka reguła FlowSpec lub RTBH - nie ma możliwości rozgłoszenia jeszcze bardziej specyficznej trasy, która wyjęłaby jeden adres spod tej reguły.

Collateral damage nie ogranicza się do samego mechanizmu RTBH - błędnie dobrany, zbyt niski próg filtrowania może odciąć legalny ruch, mimo że system technicznie zadziałał zgodnie z konfiguracją. Typowy przykład z praktyki: agresywny próg na fragmentację IP (IPFRAG), ustawiony w celu ochrony przed atakami wykorzystującymi fragmentowane pakiety, może zacząć odcinać legalny ruch tuneli IPsec - protokół ESP z natury fragmentuje się przy większych pakietach, więc przy niskim progu i regule blokującej wszystkie fragmenty do danego adresu, cały tunel VPN klienta przestaje działać.

To pokazuje, dlaczego dostrajanie progów to proces, a nie jednorazowa czynność - konfiguracja, która wygląda bezpiecznie na papierze, może w praktyce blokować konkretny, legalny wzorzec ruchu specyficzny dla danej sieci. Dlatego LiveShield rejestruje zrzuty pakietów (packet dump) dla wyzwolonych reguł, co pozwala po fakcie sprawdzić dokładnie, jaki ruch został odcięty i czy reguła zadziałała zgodnie z intencją.

Minimalizacja collateral damage w LiveShield opiera się na trzech mechanizmach działających razem: priorytecie FlowSpec nad RTBH (RTBH jako zabezpieczenie awaryjne, nie pierwsza linia obrony), priorytecie bardziej specyficznych prefiksów nad ogólnymi (możliwość wydzielenia innych progów dla krytycznych adresów w obrębie szerszej podsieci) oraz świadomym dostrajaniu progów filtrowania, żeby same reguły filtrujące nie stały się źródłem szkód. Żaden z tych mechanizmów nie działa w pełni automatycznie od pierwszego dnia - wymaga skonfigurowania progów odpowiednio do konkretnej sieci i późniejszej obserwacji, ale to właśnie ta konfigurowalność pozwala ograniczyć skutki uboczne mitygacji do minimum.

Najczęściej zadawane pytania

Czy RTBH i FlowSpec działają w LiveShield jednocześnie, czy jedno po drugim? Reguły filtrowania (FlowSpec) i reguły blackholingowe (RTBH) są sprawdzane niezależnie i równolegle, na podstawie osobnych progów. Jeśli próg blackholingowy jest ustawiony wyżej niż próg filtrowania, w praktyce FlowSpec reaguje pierwszy, a RTBH włącza się dopiero, gdy ruch mimo filtracji nadal rośnie.

Czy da się wyłączyć konkretny adres IP z mitygacji podczas ataku na całą podsieć? Nie w prosty sposób. Dla pojedynczego adresu w normalnych warunkach można skonfigurować osobną, bardziej specyficzną regułę z innymi progami, ale gdy atak obejmuje całą podsieć i działa już szeroka reguła FlowSpec lub RTBH na tę podsieć, nie da się rozgłosić jeszcze bardziej specyficznej trasy wyłączającej z niej jeden adres.

Jak ustawić próg blackholingu, żeby nie uruchamiał się przy każdym małym ataku? Zalecana praktyka to pozostawienie w profilu blackholingowym wyłącznie kontroli na poziomie adresu IP i ustawienie progu blisko maksymalnej ilości ruch