W rozmowach z operatorami ISP o ochronie anty-DDoS jedno pytanie wraca częściej niż jakiekolwiek inne: "czy mój upstream musi wspierać FlowSpec, żeby to zadziałało?". Odpowiedź brzmi: nie. I to nieporozumienie warto wyjaśnić raz na zawsze, bo przez nie część operatorów rezygnuje z rozważania automatycznej mitygacji DDoS, zanim w ogóle sprawdzi, że ich obecna infrastruktura w zupełności wystarcza.
Dwa mechanizmy, dwa różne miejsca w sieci
BGP FlowSpec i RTBH (Remotely Triggered Blackholing) to dwa podstawowe mechanizmy mitygacji ataków DDoS w sieciach operatorskich. Często wrzuca się je do jednego worka "BGP do ochrony DDoS", ale działają w różnych miejscach i rozwiązują różne problemy.
FlowSpec to precyzyjne filtrowanie. Reguła FlowSpec opisuje konkretny ruch - protokół, port, długość pakietu, fragmentację - i instruuje router, co z tym ruchem zrobić: odrzucić, ograniczyć pasmo, przekierować. Zaatakowany adres pozostaje osiągalny, wycinany jest tylko ruch pasujący do wzorca ataku.
RTBH to odcięcie. Rozgłaszana jest trasa dla atakowanego adresu ze specjalną community, a routery (własne lub upstreama) kierują cały ruch do tego adresu w null. Skuteczne, ale brutalne - atakowany adres przestaje być osiągalny w ogóle. RTBH ma sens wtedy, gdy wolumen ataku zagraża wysyceniem łączy tranzytowych i trzeba ratować resztę sieci.
Kluczowa rzecz: FlowSpec działa lokalnie, na Twoim brzegu
Reguły FlowSpec system taki jak LiveShield rozgłasza sesją BGP do Twoich własnych routerów brzegowych. To one programują filtrację w data plane i wycinają ruch ataku na wejściu do sieci. Upstream nie bierze w tym udziału i nie musi niczego wspierać ani na nic wyrażać zgody.
Od strony upstreama potrzebna jest tylko jedna, powszechnie dostępna rzecz: obsługa blackholingu przez community (RTBH). To standard u praktycznie każdego dostawcy tranzytu i na punktach wymiany ruchu. Trasy blackhole rozgłaszane są zwykłą sesją BGP unicast i redystrybuowane w górę z odpowiednią community - bez dodatkowych uzgodnień technicznych.
Jeżeli upstream dodatkowo przyjmuje reguły FlowSpec od klientów - świetnie, wtedy filtrację można przesunąć jeszcze wyżej i atak jest wycinany, zanim dotknie Twoich łączy. W praktyce u operatorów, którzy mają FlowSpec u swoich upstreamów, z RTBH można zrezygnować całkowicie. Ale to opcja, nie warunek.
Jak to wygląda podczas realnego ataku: scenariusz hybrydowy
W praktyce najskuteczniejsze jest połączenie obu mechanizmów, działające automatycznie w zależności od skali incydentu:
Atak zostaje wykryty, a pierwsze reguły FlowSpec trafiają na routery brzegowe w ciągu pojedynczych sekund. Ruch ataku jest wycinany lokalnie, pozostały ruch do atakowanego adresu przechodzi normalnie - klient nie odczuwa incydentu.
System doprecyzowuje filtrację na podstawie analizy próbkowanych pakietów, generując możliwie najwęższe reguły - zamiast blokować cały ruch danego protokołu.
Jeżeli wolumen ataku rośnie do poziomu zagrażającego wysyceniem łączy tranzytowych, uruchamiany jest RTBH dla atakowanego adresu - lokalna filtracja przestaje wystarczać, więc trasa blackhole jest redystrybuowana do upstreamów i ruch ginie poza Twoją siecią.
Ten scenariusz LiveShield realizuje automatycznie. Progi i sekwencję reakcji można konfigurować per prefiks lub grupa klientów - inne działania dla małego ataku, inne dla dużego, z powiadomieniami i wyzwalaniem własnych skryptów po drodze.
"Czy mój router to obsłuży?" - praktyczne realia sprzętowe
To drugie najczęstsze pytanie i tu warto być szczerym: nie każdy sprzęt deklarujący wsparcie FlowSpec faktycznie potrafi programować reguły w data plane. Niektóre platformy przyjmują trasy FlowSpec i potrafią je redystrybuować, ale nie stosują filtracji.
Kilka praktycznych wskazówek z wdrożeń:
Sprawdzone platformy to m.in. Juniper MX/PTX, Cisco ASR 9000/9900, ASR 1000 oraz Cisco 8000.
W serii Cisco NCS 5500 FlowSpec wymaga modeli z zewnętrznym eTCAM (oznaczenie -SE), i to nie wszystkich - reguły FlowSpec zajmują dużo miejsca w TCAM, więc konkretny model warto zweryfikować przed zakupem.
Routery programowe (BIRD, CHR i podobne) to osobna historia: BIRD przyjmie reguły FlowSpec, ale sam nic z nimi nie zrobi poza przekazaniem dalej. Dla takich środowisk realną opcją pozostaje RTBH lub redystrybucja reguł do upstreama z obsługą FlowSpec.
Jeżeli nie masz pewności co do swojego modelu - zapytaj producenta albo napisz do nas. Przy liczbie wdrożeń, które zrealizowaliśmy, jest spora szansa, że Twój sprzęt już znamy.
Dobra praktyka konfiguracyjna: reguły FlowSpec warto stosować wyłącznie na interfejsach upstream, wyłączając je na interfejsach klienckich i wewnętrznych. Gotowe przykłady konfiguracji dla poszczególnych platform znajdziesz w naszej dokumentacji: docs.liveshield.net/bgpconfiguration.html.
Co z tego wynika dla operatora
Automatyczna mitygacja DDoS oparta o BGP FlowSpec i RTBH nie wymaga wymiany infrastruktury ani negocjacji z dostawcą tranzytu. Wymaga routera brzegowego z realnym wsparciem FlowSpec - który spora część operatorów już posiada - oraz standardowej obsługi blackholingu u upstreama, która jest dziś normą.
LiveShield spina to w jeden automatyczny mechanizm: detekcja per-IP i per-subnet, reguły FlowSpec na Twoim brzegu w ciągu sekund od wykrycia ataku, RTBH jako zabezpieczenie przed wysyceniem łączy. Wszystko on-premise, bez przekierowywania ruchu poza Twoją sieć i w ramach jednej licencji.
Masz wątpliwości, czy Twoje routery poradzą sobie z FlowSpec? Napisz do nas:office@liveshield.net - podpowiemy na podstawie doświadczeń z konkretnych platform. Działanie systemu możesz zobaczyć na demo.liveshield.net.
