Jak wygląda atak DDoS krok po kroku - od detekcji do mitygacji
253 Aufrufe
Jak wygląda atak DDoS krok po kroku - od detekcji do mitygacji
Większość materiałów o ochronie przed DDoS opisuje temat na poziomie ogólnym: "system wykrywa atak i go blokuje". W praktyce między pierwszym pakietem ataku a jego skuteczną mitygacją dzieje się kilka konkretnych, technicznych kroków - i to, jak szybko i precyzyjnie są wykonane, decyduje o realnym wpływie ataku na sieć. Poniżej rozkładamy ten proces na fazy, tak jak wygląda on w środowisku operatora ISP lub data center.
Faza 0: profil normalnego ruchu
Zanim w ogóle można mówić o wykryciu ataku, system ochrony musi wiedzieć, jak wygląda ruch w danej sieci w warunkach normalnych - dla poszczególnych adresów IP oraz całych podsieci. Bez tego punktu odniesienia każda decyzja o tym, co jest anomalią, a co zwykłym szczytem ruchu (np. wieczorny peak u dostawcy internetu), byłaby zgadywaniem. Ten etap dzieje się w tle, ciągle, niezależnie od tego, czy trwa atak, czy nie.
Faza 1: start ataku
Atak DDoS rzadko wygląda jak jeden, czytelny wzorzec. W praktyce to najczęściej jedna z kilku kategorii:
wolumetryczne floody (UDP flood, ataki wzmacniające przez DNS/NTP/memcached),
ataki na warstwę TCP (SYN flood, ataki wykorzystujące niedokończone sesje),
ataki rozproszone na wiele celów jednocześnie (tzw. carpet bombing) - zamiast bić w jeden adres IP, ruch jest rozłożony na całą podsieć lub pulę adresów klienckich, co utrudnia wykrycie klasycznymi metodami per-IP.
Z perspektywy sieci ofiary pierwszym sygnałem jest zwykle skok liczby pakietów lub sesji, zmiana rozkładu protokołów albo nietypowa dystrybucja ruchu na wielu adresach naraz.
Faza 2: detekcja
To moment, w którym jakość systemu ochrony robi największą różnicę. Dwa podejścia różnią się fundamentalnie czasem reakcji:
systemy oparte wyłącznie na danych z NetFlow/sFlow/IPFIX z routerów - dane są zagregowane i próbkowane, więc detekcja następuje z opóźnieniem rzędu dziesiątek sekund do kilku minut,
systemy analizujące ruch pakiet po pakiecie w czasie rzeczywistym - detekcja może nastąpić w ciągu pierwszych sekund od startu ataku, bo system nie czeka na zagregowane statystyki z urządzeń sieciowych.
Sam próg (threshold) to za mało - skuteczna detekcja musi też odróżnić atak rozproszony po wielu adresach od zwyczajnego wzrostu ruchu w całej sieci. Tu wchodzi agregacja per-subnet: system musi umieć połączyć w jeden incydent setki pozornie niezależnych, niewielkich anomalii na poszczególnych IP.
Faza 3: klasyfikacja i decyzja o typie reakcji
Po wykryciu anomalii system musi zdecydować, jak na nią odpowiedzieć. Tu w grę wchodzą dwa uzupełniające się mechanizmy, oba oparte na BGP:
BGP FlowSpec - dystrybucja precyzyjnych reguł filtrowania (np. blokada konkretnego protokołu, portu, wzorca pakietu) bezpośrednio do routerów brzegowych, bez ręcznej konfiguracji list ACL. Dla ataków TCP/UDP system analizuje próbkowane pakiety i generuje regułę dopasowaną do konkretnego wzorca ataku - w praktyce oznacza to blokadę złośliwego ruchu przy zachowaniu normalnego ruchu na tym samym adresie i protokole.
Blackholing (RTBH) - drastyczniejszy mechanizm: ruch do zaatakowanego adresu jest kierowany donikąd. Skuteczny i natychmiastowy, ale kosztem także legalnego ruchu do tego adresu. Klasyczny, pełny blackholing ma jednak wyraźną granicę opłacalności: zablokowanie jednego zaatakowanego adresu IP to akceptowalny koszt, ale gdy atak jest rozproszony na kilkaset adresów w tej samej podsieci (carpet bombing), blackholing całego zakresu oznacza odcięcie wszystkich klientów w tej podsieci - czyli w praktyce ten sam efekt, który chciał osiągnąć atakujący, tylko wykonany rękami operatora.
Dlatego przy wolumenach zagrażających wysyceniem łączy, zamiast blackholingu całego zaatakowanego zakresu, stosuje się blackholing selektywny - ograniczony do faktycznie zaatakowanych adresów lub węższego podzbioru prefiksów w ramach podsieci, ewentualnie rozgłaszany tylko do wybranych sesji BGP (np. konkretnego upstreamu, przez który nadchodzi atak), zamiast do wszystkich peerów jednocześnie. Dzięki temu ruch do adresów, które faktycznie nie są celem ataku, w tej samej podsieci pozostaje nienaruszony - blackholing zachowuje swoją główną zaletę, czyli natychmiastowość, bez konieczności odcinania całego zakresu adresowego.
Dobrze zaprojektowany system nie wybiera z automatu najbardziej drastycznej opcji - stara się w pierwszej kolejności o możliwie wąską regułę FlowSpec, a blackholing traktuje jako mechanizm dla sytuacji, w których precyzyjne dopasowanie nie nadąża za skalą ataku.
Faza 3b: uczenie się wzorca ataku
Sama klasyfikacja "to jest atak" to za mało, żeby nałożyć precyzyjną regułę - trzeba jeszcze wiedzieć, jak dokładnie wygląda ruch, który należy zablokować. Tu większość systemów opartych na statycznych sygnaturach ma problem: sygnatura napisana pod jeden wariant ataku nie złapie wariantu zmodyfikowanego, a atakujący modyfikują wektory w czasie, żeby ominąć znane reguły.
Zamiast polegać wyłącznie na gotowych sygnaturach, system analizuje próbkowane pakiety ataku w czasie rzeczywistym i na bieżąco buduje jego charakterystykę - protokół, porty, rozmiar i flagi pakietów, rozkład adresów źródłowych. Pierwsza reguła nakładana jest od razu, na bazie wstępnej klasyfikacji (np. "blokuj UDP flood na ten adres"), ale w kolejnych sekundach jest doprecyzowywana w miarę napływu kolejnych próbek - tak, żeby finalnie obejmowała możliwie wąski, faktyczny wzorzec ataku, a nie cały ruch danego protokołu.
To samo uczenie odpowiada za śledzenie ataku w czasie: jeśli w trakcie incydentu napastnik zmienia cel lub wektor, system aktualizuje regułę zamiast trzymać się pierwotnej klasyfikacji. Przy atakach typu carpet bombing przekłada się to również na dynamiczne rozszerzanie lub zawężanie maski chronionej podsieci, tak aby podążać za faktycznym zasięgiem ataku, a nie za jego stanem z pierwszej sekundy.
Faza 4: dystrybucja reguł
Wygenerowana reguła musi trafić do infrastruktury sieciowej. Odbywa się to przez sesję BGP między systemem ochrony a routerami brzegowymi operatora - reguły FlowSpec lub trasy blackhole są propagowane standardowym mechanizmem BGP, bez potrzeby logowania się na każde urządzenie z osobna. To istotne w sieciach z wieloma punktami styku (PoP) - jedna decyzja systemu ochrony propaguje się do wszystkich odpowiednich routerów jednocześnie.
Faza 5: utrzymanie filtracji przez cały czas trwania ataku
Reguła nałożona w pierwszych sekundach nie jest ostateczna - dopóki trwa incydent, mechanizm uczenia wzorca (Faza 3b) na bieżąco ją weryfikuje i koryguje. Dzięki temu system, który tylko raz nałożył regułę i "zapomniał" o incydencie, nie ma tu zastosowania - filtracja pozostaje aktualna względem faktycznego zachowania ataku przez cały czas jego trwania, a nie tylko w momencie wykrycia.
Faza 6: powiadomienia i dokumentacja incydentu
Równolegle do mitygacji system powinien poinformować odpowiednie osoby (e-mail, webhook) - najlepiej z możliwością rozdzielenia powiadomień na różne grupy klientów lub prefiksy, tak aby zespół NOC nie musiał ręcznie filtrować, którego klienta dotyczy dany alarm. Dla operatorów objętych Krajowym Systemem Cyberbezpieczeństwa/NIS2 istotne jest też, żeby dane o incydencie (czas, wektor, wolumen) były dostępne w formie, która ułatwia późniejsze raportowanie do CSIRT. Warto podkreślić: taki moduł wspiera proces raportowania, ale sam w sobie nie zastępuje pełnego programu zgodności z NIS2.
Faza 7: deeskalacja
Gdy ruch wraca do profilu sprzed ataku, reguły filtrowania powinny zostać automatycznie wycofane. Utrzymywanie blackholingu czy wąskich reguł FlowSpec dłużej niż to konieczne bez powodu obciąża infrastrukturę i utrudnia diagnostykę kolejnych, niezwiązanych zdarzeń.
Co z tego wynika w praktyce
Skuteczna ochrona przed DDoS to nie pojedyncza funkcja, tylko łańcuch decyzji podejmowanych w ciągu sekund: profil ruchu, detekcja, klasyfikacja, uczenie się wzorca ataku, wybór między FlowSpec a blackholingiem, dystrybucja reguł, utrzymanie filtracji dopasowanej do zmieniającego się wektora i w końcu wycofanie mitygacji. Każde ogniwo tego łańcucha, które działa wolniej lub mniej precyzyjnie, przekłada się na dłuższy czas niedostępności usługi lub większy zakres zablokowanego, legalnego ruchu.
Pełny opis architektury, konfiguracji BGP i mechanizmów filtracji znajduje się w dokumentacji technicznej: docs.liveshield.net. Działanie systemu można też sprawdzić bez zobowiązań w wersji demo: demo.liveshield.net.
Warten Sie nicht auf den nächsten DDoS-Angriff.
Kontaktieren Sie uns noch heute!
