Technika
Anty-DDoS a ciągłość działania. Co się dzieje, gdy zawiedzie sam system ochrony?
Czy system ochrony przed DDoS może sam stać się powodem przerwy w usługach? To pytanie, które zarząd operatora powinien zadać dostawcy przed zakupem, a nie po pierwszej awarii. Odpowiedź zależy od miejsca, w którym dany element leży w ścieżce ruchu. LiveShield, polski system anty-DDoS dla operatorów ISP i telekomunikacyjnych, wykrywa ataki na kopii ruchu, poza jego ścieżką produkcyjną. Poniżej wyjaśniamy, co to oznacza dla ciągłości usług, i podajemy pytania, które warto zadać każdemu dostawcy ochrony.
Czy system anty-DDoS może zatrzymać ruch w sieci operatora?
Może, jeśli leży w ścieżce ruchu. Dlatego pierwsze pytanie do dostawcy dotyczy architektury, a nie listy funkcji.
Wykrywanie ataków w LiveShield opiera się na kopii ruchu z portu lustrzanego (SPAN) albo z optycznego rozgałęźnika (Link TAP). Przy rozgałęźniku wystarczy kopia ruchu przychodzącego, a według dokumentacji jest to metoda, która nie wpływa na urządzenie produkcyjne. Detekcja działa więc bez ingerencji w ścieżkę pakietów i nie wprowadza ryzyka dla ruchu abonentów. Ten układ opisaliśmy szerzej w materiale o tym, jak działa ochrona przed DDoS w sieci operatora.
Co dzieje się z ochroną, gdy zawiedzie element wykrywający ataki?
Ruch w sieci płynie dalej, ale lokalizacja przestaje wykrywać nowe ataki do czasu przywrócenia modułu. Moduł analizujący pakiety (worker) pracuje poza ścieżką ruchu produkcyjnego, więc awaria workera nie przerywa ruchu produkcyjnego w danej lokalizacji.
To uczciwy kompromis: awaria systemu ochrony nie odcina abonentów, ale oznacza okres bez detekcji. Dlatego warto traktować ją jak każdy inny element sieci, czyli z monitoringiem i planem przywrócenia.
Schemat: detekcja LiveShield pracuje na kopii ruchu, a ruch produkcyjny płynie przez router bez zmian
Które elementy ochrony mają wpływ na ruch?
Te, które mają go zmieniać, czyli mitygacja. Reguły BGP FlowSpec odrzucają ruch ataku według jego cech, a blackholing (RTBH) pozostaje ostatecznością. Wpływ jest zamierzony i ograniczony do atakowanego celu, a reguły trafiają na routery operatora, który zachowuje nad nimi kontrolę.
Jedynym elementem LiveShield pracującym w ścieżce ruchu jest opcjonalny filtr stanowy LiveShield AIF, umieszczony między routerem brzegowym a koncentratorem (BRAS). Dlatego ma tryby obejścia (bypass), zmieniane na żywo: częściowy wyłącza filtrowanie i zostawia uczenie połączeń, a pełny tylko przekazuje ruch. Dla operatora to prosty hamulec bezpieczeństwa na czas prac w sieci.
Co, jeśli atak jest większy niż łącze?
System lokalny filtruje ruch, który dociera do sieci operatora. Gdy atak wysyca łącze od upstreamu, potrzebna jest reakcja wyżej: reguły FlowSpec lub RTBH przekazane do upstreamu, jeśli ten oferuje takie usługi, albo przekierowanie ruchu do zewnętrznego centrum czyszczącego (scrubbing center). To uzupełnienie lokalnej ochrony, a nie jej zamiennik.
Przekierowanie można powiązać z progami przepustowości łącza, a powrót ruchu po ataku może być automatyczny. Szczegóły opisujemy w materiale o tym, co dzieje się, gdy atak DDoS przekracza przepustowość łącza uplink.
Jakie pytania zarząd powinien zadać dostawcy anty-DDoS?
- Które elementy systemu leżą w ścieżce ruchu produkcyjnego, a które pracują na jego kopii?
- Co dzieje się z ruchem i z ochroną, gdy zawiedzie każdy z nich?
- Czy filtrowanie można wyłączyć na żywo, bez przerwy w ruchu?
- Co dzieje się, gdy atak jest większy niż łącze od upstreamu?
Ciągłość usług powinna być kryterium wyboru równie ważnym jak szybkość reakcji i koszt. Pozostałe kryteria zebraliśmy w materiale Ochrona przed DDoS w sieci operatorskiej – kryteria wyboru. Działanie panelu można obejrzeć w publicznym demo na demo.liveshield.net, a o wdrożenie w swojej sieci zapytać pod adresem office@liveshield.net.
