Ochrona przed DDoS

Odmowa usługi i ataki DDoS

Usługa internetowa korzysta z serwerów, łączy i aplikacji, które obsługują żądania użytkowników. Jeżeli napastnik zajmie te zasoby dużą liczbą żądań lub pakietów, użytkownicy mogą nie otrzymać odpowiedzi w wymaganym czasie. Obciążenie może dotyczyć przepustowości mierzonej w bitach na sekundę, obsługi pakietów albo pamięci przeznaczonej na stan połączeń.

Odmowa usługi (Denial of Service, DoS) polega na zakłóceniu dostępności usługi, serwera lub sieci. Źródłem może być pojedynczy system albo większa liczba źródeł. Skutkiem jest odrzucanie żądań, opóźnienia albo wyczerpanie zasobów przeznaczonych dla prawidłowych użytkowników. Wektor może działać na warstwie sieciowej, transportowej albo aplikacyjnej.

Gdy ruch pochodzi z wielu źródeł, mówimy o rozproszonej odmowie usługi (DDoS). Atak może przeciążyć cel albo infrastrukturę pośrednią. Bezpośrednim celem jest ograniczenie dostępności. Incydent może również odwracać uwagę od innych działań napastnika. Do rozproszenia ruchu służą botnety, usługi odbijające odpowiedzi i sfałszowane adresy źródłowe.

Botnety używane w atakach DDoS

Koordynowanie wielu urządzeń w celu jednoczesnego wysyłania ruchu do jednego celu wymaga infrastruktury sterującej, często opartej na botnecie. Serwer dowodzenia przekazuje zadanie, a urządzenia wykonują je z użyciem różnych protokołów i parametrów ruchu.

Botnet to sieć przejętych, połączonych z internetem urządzeń. Urządzenia te, znane jako boty lub zombie, zostały zainfekowane złośliwym oprogramowaniem, które pozwala atakującemu, botmasterowi, zdalnie je kontrolować bez wiedzy ich właścicieli. Botnet może składać się z różnorodnych urządzeń, w tym:

• Komputerów stacjonarnych i laptopów.
• Serwerów.
• Urządzeń mobilnych (smartfonów i tabletów).
• Urządzeń IoT (kamery bezpieczeństwa, urządzenia inteligentnego domu, routery).

Po zbudowaniu botnetu napastnik może wydać polecenie z serwera dowodzenia i kontroli (C2), aby boty skierowały ruch na adres IP ofiary. Ruch może pochodzić z wielu lokalizacji i adresów, co utrudnia odróżnienie go od ruchu użytkowników oraz skuteczne filtrowanie. Rozproszenie źródeł zwiększa obciążenie celu i urządzeń ochronnych. Część ruchu może używać sfałszowanego adresu źródłowego, dlatego sam adres nadawcy nie wystarcza do oceny wiarygodności. Wykrywanie botnetu i usunięcie złośliwego oprogramowania ogranicza dalsze wykorzystanie urządzeń.

Typy wektorów DDoS

Wektory DDoS można podzielić na trzy grupy według zasobu lub warstwy, którą obciążają. Jeden incydent może łączyć kilka wektorów i zmieniać proporcje ruchu podczas trwania ataku. Monitoring powinien obejmować przepływność, pps, rps, błędy aplikacji i opóźnienia. Należy porównywać te wartości z ruchem bazowym oraz zapisanym profilem usługi.

1. Ataki wolumetryczne

Ataki wolumetryczne mają zużyć przepustowość łącza celu albo urządzeń pośrednich. Ich wielkość mierzy się w bitach na sekundę (bps), w tym w gigabitach (Gbps) i terabitach (Tbps). Analiza obejmuje także liczbę pakietów i źródła ruchu, ponieważ sama przepustowość nie opisuje kosztu obsługi każdego pakietu.

Po nasyceniu łącza pakiety prawidłowych użytkowników mogą nie dotrzeć do usługi, nawet gdy serwery nadal działają.

Typowe ataki wolumetryczne to:

• UDP Flood:User Datagram Protocol (UDP) jest protokołem bezpołączeniowym. Napastnik wysyła dużą liczbę pakietów, często na porty bez aplikacji nasłuchującej. System może wtedy generować komunikaty 'ICMP Destination Unreachable', zależnie od konfiguracji i ograniczeń, co zużywa zasoby oraz przepustowość. Sam napływ pakietów może przeciążyć obsługę UDP.
• ICMP Flood:Ten wariant wykorzystuje protokół Internet Control Message Protocol (ICMP), używany między innymi do diagnostyki. Napastnik wysyła wiele pakietów 'ICMP Echo Request'. Odpowiedzi 'ICMP Echo Reply' zależą od konfiguracji i ograniczeń szybkości, lecz obsługa żądań może zużywać przepustowość i zasoby celu.
• Ataki amplifikacyjne: Napastnik wysyła małe zapytania do publicznie dostępnych usług, takich jak resolvery DNS albo serwery NTP, i umieszcza w nich sfałszowany adres źródłowy ofiary. Usługa odpowiada na ten adres, czasem większą wiadomością niż zapytanie. Ofiara otrzymuje wtedy niezamówione odpowiedzi od wielu serwerów. Ograniczanie odpowiedzi, filtrowanie ruchu z odbicia i walidacja adresów źródłowych zmniejszają ten wektor po stronie dostawców.

2. Ataki protokolarne i wyczerpanie stanu

Ataki na wyczerpanie stanu obciążają zasoby zapór, load balancerów i innych urządzeń infrastruktury. Ich celem są tablice stanów połączeń, kolejki albo limity obsługi pakietów, zamiast samej przepustowości łącza.

Atak obciąża urządzenia dużą liczbą operacji i stanów do utrzymania. Wielkość takiego ruchu mierzy się między innymi w pakietach na sekundę (pps).

Klasyczny przykład to:

• SYN Flood:Atak wykorzystuje trójetapowe ustanawianie TCP ('SYN', 'SYN-ACK', 'ACK'). Napastnik wysyła wiele pakietów 'SYN', często ze sfałszowanymi adresami źródłowymi. Serwer może utworzyć stan półotwartego połączenia i oczekiwać na końcowy 'ACK'. Gdy potwierdzenie nie nadchodzi, takie stany zajmują zasoby i ograniczają obsługę nowych połączeń. Mechanizmy takie jak SYN cookies mogą zmniejszyć ten problem, ponieważ ograniczają przechowywanie stanu przed otrzymaniem potwierdzenia.

3. Ataki na warstwę aplikacji

Ataki warstwy 7 obciążają zasoby konkretnej aplikacji lub usługi, na przykład serwera WWW albo bazy danych. Mogą przypominać zwykłe żądania, co utrudnia ich odróżnienie od ruchu użytkowników. Ocena wymaga analizy ścieżki URL, parametrów, sesji, kodów odpowiedzi i czasu obsługi.

Napastnik może wysyłać żądania do funkcji wymagających dużej liczby operacji, na przykład złożonego zapytania do bazy danych, wyszukiwania albo pobierania dużego pliku. Niewielka liczba równoległych sesji może wtedy długo zajmować zasoby aplikacji.

Te ataki są mierzone w żądaniach na sekundę (rps) i obejmują:

• HTTP Flood: Botnet jest używany do wysyłania pozornie legalnych żądań HTTP GET lub POST do serwera WWW. Żądania te mogą być spreparowane tak, aby celować w zasobochłonne funkcje, takie jak złożone zapytanie do bazy danych, wyszukiwanie na stronie lub pobieranie dużego pliku. Ponieważ żądania wyglądają jak normalny ruch użytkowników, prostym mechanizmom obronnym może być bardzo trudno odróżnić je od legalnych żądań. Reguły mogą uwzględniać limity sesji, koszt operacji i zachowanie klienta.
• Ataki Low-and-Slow (np. Slowloris): Napastnik otwiera wiele połączeń z serwerem WWW i utrzymuje je, wysyłając dane z małą szybkością. Serwer czeka na zakończenie żądań, więc zajęte połączenia mogą wyczerpać dostępne sloty. Atak zużywa niewielką przepustowość, lecz ogranicza możliwość nawiązywania nowych sesji. Limity czasu, maksymalna liczba połączeń i obsługa strumieni pomagają ograniczyć skutki.

Strategie ochrony przed DDoS

Ochrona przed DDoS wymaga kilku warstw kontroli: monitorowania, filtrowania, ograniczania szybkości oraz przygotowanych procedur reagowania. Zespół powinien znać właściciela usługi, punkt eskalacji, zależności DNS i sposób kontaktu z dostawcą łącza. Warto wcześniej ustalić dopuszczalne opóźnienia i kryteria uruchomienia ochrony. Procedura powinna obejmować zachowanie logów i późniejszą analizę incydentu.

1. Ochrona lokalna

Są to środki obronne wdrożone we własnym centrum danych organizacji. Obejmują reguły zapory, ACL, limity połączeń, ochronę serwera i obserwację parametrów ruchu. Monitoring powinien obejmować przepustowość, liczbę pakietów, liczbę żądań i czas odpowiedzi usługi.

• Ograniczanie szybkości (rate limiting): Konfiguracja urządzeń sieciowych ogranicza liczbę żądań w określonym czasie. Reguły oparte wyłącznie na adresie IP mogą być omijane, lecz ograniczanie szybkości pomaga przy prostych zalewach. Wymaga dobrania limitów do zwykłego ruchu, aby nie odrzucać prawidłowych klientów. Limity można ustawić osobno dla sesji, punktów końcowych i kosztownych operacji. Po zmianie profilu ruchu należy ponownie ocenić ich wartości.
• Dedykowane urządzenia anty-DDoS: Wyspecjalizowane urządzenia mogą analizować ruch, rozpoznawać wzorce i odrzucać wybrane pakiety. Chronią tylko wtedy, gdy ruch dociera do urządzenia. Atak przekraczający przepustowość łącza nasyci połączenie przed filtrowaniem lokalnym, więc potrzebna jest także współpraca z operatorem lub dostawcą ochrony. Urządzenie trzeba dobrać do zwykłego ruchu i oczekiwanych skoków obciążenia.

2. Ochrona w chmurze

Usługi chmurowe przenoszą analizę i filtrowanie ruchu do rozproszonej infrastruktury dostawcy. Ich skuteczność zależy od pojemności usługi, konfiguracji i sposobu przekierowania ruchu. Przed uruchomieniem trzeba ustalić, które prefiksy, domeny i usługi obejmuje ochrona oraz jaką drogą oczyszczony ruch wróci do organizacji.

• Usługi oczyszczania ruchu w chmurze (cloud scrubbing): Po wykryciu ataku ruch organizacji może zostać przekierowany zmianą DNS albo BGP do centrów oczyszczania dostawcy ochrony DDoS. DNS kieruje zapytania aplikacyjne, a BGP może zmienić trasę dla określonych prefiksów IP. Wybrana metoda decyduje, który ruch zostanie poddany analizie.

  Centra analizują ruch, odrzucają pakiety spełniające reguły ataku i przekazują zaakceptowany ruch do serwerów organizacji. Sposób przekazania może korzystać z prywatnego łącza albo innego kanału ustalonego przez dostawcę. Reguły muszą ograniczać atak bez odrzucania wymaganych żądań, a ich skuteczność wymaga monitorowania. Niewłaściwe reguły mogą zwiększyć opóźnienia albo przerwać działanie legalnych klientów. Organizacja i dostawca powinni uzgodnić procedurę zmiany filtrów w trakcie incydentu. Konfiguracja powinna obejmować także zdrowie serwerów i możliwość wycofania przekierowania.

• Sieci dostarczania treści (CDN): CDN przechowuje wybrane treści na rozproszonych serwerach brzegowych, więc część żądań nie trafia do serwera źródłowego. Może to ograniczyć ataki aplikacyjne, jeżeli usługa i reguły CDN obejmują dany ruch. CDN nie zastępuje konfiguracji ochrony źródła ani filtrowania ruchu, którego nie można buforować. Gdy architektura na to pozwala, dostęp do originu powinien być ograniczony do serwerów brzegowych, a kontrole zdrowia i limity szybkości dla originu powinny być skonfigurowane osobno.

3. Ochrona hybrydowa

Podejście hybrydowe łączy lokalne urządzenie do obsługi części ataków protokołowych i aplikacyjnych z chmurową usługą oczyszczania uruchamianą przy ataku, który może nasycić lokalne łącze. Lokalna warstwa filtruje ruch docierający do sieci, a dostawca chmurowy przejmuje ruch wymagający większej przepustowości. Plan powinien opisywać kryteria przełączenia, testy procedury, role kontaktowe i powrót do zwykłego routingu. Po incydencie należy skorelować logi obu warstw, uwzględniając czas każdej zmiany routingu.