Automatyzacja reakcji na atak DDoS: co dzieje się po wykryciu ataku
59 views
Atak DDoS wykryty. Co robi Twój system w kolejnych sekundach?
Rozmowy o ochronie antyDDoS zwykle kręcą się wokół jednego pytania: jak szybko system wykryje atak i założy regułę filtrującą. To pytanie ma sens, ale dla zespołu NOC operatora rzadko kończy sprawę. Wygenerowana reguła FlowSpec czy blackholing to zwykle początek, nie koniec procedury. Ktoś musi dostać powiadomienie, incydent trzeba zalogować, czasem trzeba przełączyć klienta na inny adres IP, czasem odpalić skrypt na urządzeniu brzegowym.
W wielu sieciach te kroki i tak wykonuje człowiek. Dostaje alert, loguje się do panelu, sprawdza co się stało, dopiero potem uruchamia procedurę. Przy ataku, który trwa kilkanaście sekund, to opóźnienie bywa dłuższe niż sam czas detekcji i filtracji razem wzięty.
System już wie, co się dzieje - problem w tym, że nikt jeszcze o tym nie wie
W momencie wykrycia ataku system antyDDoS dysponuje kompletem informacji potrzebnych do dalszych działań: zna adres IP ofiary, protokoły, skalę ruchu, dokładny moment przekroczenia progu. Pytanie, czy ta wiedza kończy się na wygenerowaniu reguły filtrującej, czy da się nią od razu uruchomić coś więcej.
W LiveShield służy do tego event pipeline - zestaw akcji podpiętych pod konkretne zdarzenia w cyklu życia ataku, na przykład "Blackholing started" albo "Blackholing stopped". Pod każde z takich zdarzeń można podpiąć wywołanie własnego skryptu, z atakowanym adresem IP przekazanym jako parametr, albo webhooka pod wskazany adres URL.
Przykład z życia: dwa progi, jedna automatyczna reakcja
Typowa konfiguracja wygląda tak:
Na prefiksie ustawione są progi pps/bps. Po ich przekroczeniu system wykrywa atak z konkretnymi protokołami i generuje reguły FlowSpec. Równolegle sprawdzane są wyższe progi z profilu blackholingu - można je ustawić sumarycznie per IP albo osobno dla poszczególnych protokołów. Jeśli te wyższe progi też zostaną przekroczone, uruchamia się blackholing.
I tu wchodzi pipeline. W momencie wywołania blackholingu uruchamia się skrypt podpięty pod zdarzenie "Blackholing started" - może to być na przykład zmiana adresu IP klienta na zapasowy. Gdy atak ustępuje i blackholing zostaje zdjęty, zdarzenie "Blackholing stopped" wywołuje akcję odwrotną, czyli przywraca pierwotny adres.
Ten sam schemat działa przy integracji ze scrubbing center. Zamiast filtrować ruch lokalnie, pipeline może przekierować go na zewnętrzny punkt czyszczenia w momencie eskalacji ataku, a po jej zakończeniu wrócić do standardowego routingu.
FlowSpec najpierw, RTBH dopiero gdy naprawdę trzeba
Rozdzielenie progów detekcji od progów blackholingu ma sens praktyczny. Niższy próg uruchamia precyzyjną regułę FlowSpec, filtrującą ruch po konkretnych parametrach - protokole, porcie, flagach. Dopiero po przekroczeniu drugiego, wyższego progu następuje blackholing całego prefiksu. Większość ataków, tych mniejszych i bardziej przewidywalnych, jest obsługiwana bez utraty ruchu legalnego. RTBH zostaje środkiem na sytuacje, w których dalsze utrzymywanie ruchu do danego adresu zaczyna zagrażać stabilności całej sieci.
Dla adresów o innym profilu ryzyka - serwerów usługowych, które muszą mieć wyższą dostępność - te same mechanizmy da się skonfigurować osobno. Wystarczy dodać je jako bardziej specyficzną podsieć z własnym zestawem progów.
Uruchom system do ochrony przed atakami DDoS w swojej infrastrukturze. Skontaktuj się znami: office@liveshield.net
Don't wait for the next DDoS attack.
Contact us today!