Nasza strona używa cookies. Korzystając ze strony, wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki. Rozumiem

Ataki DDoS - jak walczyć z zagrożeniami?

Joanna Sitkowska Senior Product Owner
Poznaj rodzaje ataków DDoS oraz metody przeciwdziałania im.
Ataki DDoS - jak walczyć z zagrożeniami?

DDoS (distributed denial of service) to rozproszona odmowa dostępu, której celem jest spowodowanie niestabilności albo niedostępności serwera, usługi lub infrastruktury. Objawia się to w dwojaki sposób poprzez wysycenie przepustowości serwera i w efekcie jego niedostępności lub wykorzystanie zasobów systemu.

Wyróżniamy dwa podstawowe rodzaje ataków DDoS i jeden o charakterze mieszanym.


Atak wolumetryczny

Atak wolumetryczny (ang. flood attacks) wykorzystuje głównie warstwę sieciową lub transportową. Polega na masowej wysyłce na wskazany adres IP bardzo podobnych do siebie pakietów lub zapytań. Pojedynczo nie są one groźne, ich zagrożenie tkwi w masowości. W rezultacie dochodzi bowiem do zachwiania stabilności serwera, który nie jest gotowy na przyjęcie tak dużej ilości requestów.

Inną często wykorzystywaną techniką jest fragmentacja pakietów IP, wykorzystującą cechę dzielenia dużych pakietów IP. Ostatecznie, muszą one zostać połączone przez stos sieciowy systemu
(tj. logiczny podział komponentów związanych z komunikacją sieciową na oddzielne warstwy). To ponowne połączenie zajmuje pewne zasoby procesora, a z drugiej strony pozwala omijać sygnatury systemów IDS/IPS (jedne z głównych warstw zabezpieczeń sieciowych zajmujące się wykrywaniem prób uzyskania dostępu do systemu).

Ataki wolumetryczne są jednymi z najprostszych sposobów paraliżowania infrastruktury sieciowej oraz aplikacji. Z reguły wąskim gardłem w atakach DoS stają się urządzenia sieciowe: routery, firewalle, a jeżeli te zawiodą, to ofiarą pada serwer, do którego ostatecznie dotrze ruch.


Atak aplikacyjny

Atak aplikacyjny jest zjawiskiem znacznie groźniejszym, z uwagi na atak na logikę. Polega na wyczerpaniu zasobów informatycznych aplikacji internetowej, niekiedy także na wstrzyknięciu złośliwego kodu. Jego celem nie jest infrastruktura sieciowa, a sama aplikacja. Najczęściej chodzi o wywoływanie awarii aplikacji, uzyskiwanie dostępu do hosta, na którym działa aplikacja lub do innych hostów w ramach jego konfiguracji.

Ataki aplikacyjne identyfikują słabe punkty w aplikacjach, czyli takie, które w istotny sposób obciążają procesor, sieć lub inne zasoby. Ich identyfikacja pozwala na zalanie zapytaniami do aplikacji (np. HTTP POST), które nie tyle wyczerpują przepustowość serwera, co wyczerpanie innych zasobów.

System obsługuje konkretne zapytania w hurtowych ilościach, tym samym następuje jego przeciążenie i odmowa dostępu innym użytkownikom. Samo wykrycie złośliwych zapytań może być skomplikowane, z uwagi na wierne naśladowanie zachowań przeciętnego użytkownika. Nie muszą one także zalewać systemu złośliwymi zapytaniami w takiej ilości, jak w przypadku ataków wolumetrycznych. 

Dobrym przykładem będzie tutaj atak Slowloris, który polega na wysyłaniu częściowych zapytań HTTP do serwera aplikacji, mających utrzymać sesję oraz licznik limitu czasu odpowiedzi niedokończonego zapytania HTTP. Częściowe zapytanie Slowloris tym różni się od prawidłowego zapytania HTTP, że nie zawiera treści. Treść ta po dłuższym czasie zostaje przysyłana w małych częściach. Spowalniany jest proces przetwarzania zapytania od klienta do aplikacji - atak slow-POST.

Niekompletne zapytania HTTP mogą łatwo unieruchomić serwer ze względu na brak wolnych wątków czy gniazd sieciowych do obsługi innych żądań. Zapytania Slowlorisa nie są też wykrywane przez systemy IDS/IPS, ponieważ są w praktyce poprawnymi, niezłośliwymi zapytaniami HTTP. Problem w tym, że nie mają one końca. Zwykle w takiej sytuacji sesja by wygasła, Slowloris ją podtrzymuje, wykrywając wcześniej wartość parametru "time out" serwera i wysyłając w ostatniej chwili pakiet podtrzymujący.

Slowloris ma już swoje lata. Od tego czasu powstało wiele innych narzędzi, chociażby oparty na koncepcji Slowloris- Slowhttptest. W tym przypadku spowalniane są odpowiedzi serwera.


Atak mieszany

Trzeci rodzaj zagrożenia, to atak o charakterze mieszanym – łączy metody ataku wolumetrycznego i aplikacyjnego. Firma Kaspersky prowadzi cykliczne badania i statystyki nad skalą zjawiska. W drugim kwartale 2019 r. łączna liczba ataków DDoS zwiększyła się o 18% w porównaniu z analogicznym okresem w 2018 roku, natomiast w porównaniu z II kwartałem 2017 r. - o 25%. W porównaniu z II kwartałem 2018 r., liczba ataków aplikacyjnych wzrosła o niemal jedną trzecią, a ich udział w II kwartale 2019 r. zwiększył się do 46%.

Analizy wskazują także, że w II kwartale 2019 r. najdłuższy atak DDoS trwał 509 godzin - prawie 21 dni. To najdłużej trwający atak od czasu rozpoczęcia monitorowania przez Kaspersky aktywności botnetowej (2015 rok). Wcześniej ustanowiony rekord wynosił 329 godzin, który miał miejsce w IV kwartale 2018 r. Pełny raport poświęcony zagrożeniom i atakom DDoS w II kwartale 2019 r. jest dostępny na stronie DDoS attacks in Q2 2019.

Jakie firmy ponoszą koszty w związku z atakami DDoS? Straty potrafią być wielomilionowe, nie licząc szkód wynikających z utraty reputacji czy klientów. Wysokie koszty „sprzątania” po incydentach, utrata możliwości biznesowych i generowania przychodu, kosztuje małe i średnie firmy przeszło 123 tysiące dolarów. W przypadku przedsiębiorstw, koszty te przekraczają 2 miliony dolarów.


Jak zminimalizować ryzyko ataku i zabezpieczyć infrastrukturę przed atakiem

Można śmiało stwierdzić, że nie ma 100%-owej ochrony przed DDoS. Są jednak sposoby na ograniczenie ryzyka i zmniejszenie skali.

Jeżeli myślimy o dedykowanym rozwiązaniu anti-DDoS, to bez względu na dostawcę sprzętu - nie należy ono do tanich. Dodatkowo dochodzi jeszcze kwestia właściwego umieszczenia go w infrastrukturze. Słyszałam, że były przypadki, kiedy umieszczano rozwiązanie anti-DDoS przed chronionymi serwerami, ale za firewallem. To z kolei powodowało, że najsłabszym ogniwem i tak okazywała się zapora.

Być może lepszym pomysłem będzie skorzystanie z oferty usług pośredniczących między serwerem strony WWW, a klientami końcowymi (typu cloud-anty-DDoS). Ich wdrożenie sprowadza się do przekierowania adresów DNS na serwis dostawcy usługi (np. CloudFlare).

Podstawową techniką obrony dostawców typu CloudFlare jest możliwość ukrycia swoich usług w infrastrukturze CloudFlare. Chroniony serwer zaczyna być widoczny pod adresem IP Cloudflare, a ewentualny atak DDoS zmienia formę z ataku „wiele do jednego serwera” na „wiele do wielu serwerów”. Podejrzany ruch zostaje automatycznie odfiltrowany i rozłożony na kilkadziesiąt centrów. Centra te są odpowiednikami urządzeń pośredniczących w sieci oraz pozwalają na odetkanie przeciążonego serwera.

Ruch między web aplikacjami i ich klientami będzie dodatkowo automatycznie przepływał przez firewall aplikacyjny. Jest jedno ALE… Z jednej strony, outsourcing w dłuższej perspektywie często okazuje się tańszy niż inwestycja we własne wewnętrzne rozwiązania. Z drugiej jednak strony analiza ryzyka często wykazuje, że skutki ataku nie będą tak kosztowne, jak outsourcing ochrony DDoS

Testy przeciążeniowe/ Stress-tests są jednym z typów testów wydajnościowych. Ich celem jest sprawdzenie, jak zachowuje się system podczas aktywności określonej z góry liczby użytkowników, przy ograniczeniu bądź braku zasobów (procesor, pamięć bądź miejsce na dysku) oraz wyszukiwanie defektów aplikacji podczas utraty danych.

W czasie symulacji ataku sprawdzona zostanie nie tylko odporność urządzeń, ale także ich reakcja i schemat alarmowania w sytuacji pojawienia się realnego zagrożenia (alerty, logi, czy komunikacja
z innymi systemami). Na rynku istnieje cała masa narzędzi symulujących ataki odmowy dostępu do usługi. Wystarczy proste zapytanie w wyszukiwarce o narzędzia do testów i symulatory ataków DoS. Są one w stanie wygenerować praktycznie dowolny wolumen ruchu. Generator może symulować zarówno klasyczne ataki sieciowe, jak i ataki DDoS/DoS 

Jednym z narzędzi do przeprowadzenia kontrolowanego ataku wolumetrycznego, jest Bees with machine guns. To pewnie także narzędzie, o jednej z najbardziej zapadających w głowie nazw ;-) 

Dzięki niemu możemy testować obciążenie setek instancji AWS. Definiujemy w ilu wątkach ma być wykonana określona ilość żądań. Z poziomu konsoli wydajemy polecenie „Bees attack” i monitorujemy efekty. Szczegółowe informacje na temat tego narzędzia, dostępne są na GitHubie.

Innym przykładem jest Hulk (Http Unbearable Load King). To skrypt Pythona służący do przeprowadzania ataków DoS. Jest to już bardziej zaawansowane, gdyż stara się dynamicznie zmieniać żądania, w celu omijania podstawowych wzorców systemów IDS/IPS. Szczegółowe informacje na temat tego narzędzia znajdziesz tutaj.

Same stress-testy obejmują zwykle ataki zarówno w warstwie sieciowej, jak i w warstwie aplikacyjnej. Obejmują test całej infrastruktury styku, testy z pominięciem urządzenia chroniącego przed atakami DDoS (o ile już istnieje) albo testy poszczególnych elementów styku (routery, firewalle, Load Balancer itp.).

Samodzielna symulacja prostego ataku, np. zalewania pakietami SYN, umożliwia sprawdzenie wydajności procesorów (w przypadku ataku zwalczanego sprzętowo). Odpowiedź na pytanie, jak system radzi sobie z symultanicznym atakiem w warstwie aplikacji (np. atakiem wykorzystującym HTTP GET), uwidoczni granice możliwości testowanego rozwiązania.

Testowanie maksymalnego obciążenia to część procesu służącego zwiększeniu ochrony zewnętrznych zasobów IT w badanej infrastrukturze i znalezienia aktualnie największego obciążenia dla zewnętrznych serwisów. Znając punkt, w którym nasz system danych przestanie działać, możemy usprawnić posiadane procesy lub wprowadzić nowe w celu zwiększenia prawdopodobieństwa bezawaryjności.


Prewencja czyli przygotowanie infrastruktury

Bazując na obserwacji rynku, nie ma całkowicie pewnej ochrony przed DDoS. Są jednak sposoby na ograniczenie ryzyka, prewencji i detekcji. Najprostsze metody obrony przed atakami wolumerycznymi wykorzystują tradycyjne metody typu filtrowanie pakietów czy użycie rozwiniętych funkcji "rate limiting".

Optymalizacja strony

Ma na celu zmniejszenie liczby zapytań do bazy danych i mniej zasobów pobieranych z serwera przy każdorazowej wizycie na stronie. Wystawienie statycznych treści (skrypty js, obrazy, dokumenty PDF) przy pomocy odrębnego serwera CDN, pozwolą na udostępnianie danych z zewnętrznej lokalizacji. CDN odpowiadają adresami IP najbliższymi użytkownikowi, więc
w przypadku ewentualnego ataku ruch zostanie rozłożony na kilka serwerów.

Planując infrastrukturę sieci warto rozważyć blokowanie niepotrzebnego i nieprawidłowego ruchu sieciowego, co do którego jesteśmy pewni, że nie będzie przechodził przez dane urządzenie pośredniczące. Z kolei firewall i urządzenia pośredniczące powinny wykrywać anomalie w ruchu sieciowym poprzez analizę przepływu danych wychodzących i przychodzących.

Web Application Firewall

Wdrożenie firewalla warstwy aplikacji (ang. Web Application Firewall), będzie skutkowało wykrywaniem i zapobieganiem anomaliom w ruchu do aplikacji czy zablokowaniem ponadprzeciętnego ruchu wychodzącego określonego miejsca. Oczywiście nie uchroni nas to przed wysyceniem całego dostępnego łącza, jeśli ruch będzie się wywodził z wielu źródeł, ale pozwoli nam oddzielić typowy atak wolumetryczny od pozostałych.

Hardening

Wykonanie hardeningu serwerów sieciowych i urządzeń pośredniczących to konfiguracja systemów w taki sposób, aby ograniczać usługi i zamykać zbędne porty na publicznych interfejsach sieciowych, wzmocnić poziom uwierzytelniania, wprowadzić kontrolę dostępu oraz zoptymalizować sposób używania pamięci i mocy obliczeniowej oraz wszystkiego, co generuje dodatkowy ruch.

Jeżeli chodzi o uwierzytelnianie, to ciekawą koncepcją jest użycie JavaScript, który nie jest interpretowany przez większość narzędzi do ataków DoS. Dodatkowo powinien być wykonany przeprowadzony hardening serwerów aplikacji oraz usług (ograniczenie maksymalnej pulę pamięci oraz czas procesora dostępny dla aplikacji, ograniczyć długość żądań/parametrów http).

Loadbalancing

Loadbalancing to w największym skrócie skalowanie mocy obliczeniowej serwerów. Pozwoli to rozłożyć obciążenie kluczowych usługi na kilka maszyn. Zanim request trafi do webserwera jest przechwytywany przez loadbalancer, który w kolejnym kroku decyduje do którego webserwera z klastra je przekazać. Wybór pada na najmniej obciążone serwery. Dzięki rozproszeniu geograficznemu, blokowany będzie z kolei ruch z krajów, z których nie spodziewamy się aktywności (węzły botnetów mają zwykle rozlokowanie na całym świecie).

Dobrym pomysłem jest również używanie kilku serwerów aplikacyjnych ustawionymi za loadbalancerami, dzięki czemu zwiększona zostanie dostępność usług przy jednoczesnym zmniejszeniu skuteczności niektórych ataków. Posiadanie awaryjnego serwera poza używaną infrastrukturą będzie zaś awaryjnym rozwiązaniem w komunikacji z odciętymi na skutek ataku klientami. 

Detekcja ataków

Kolejny sposób to detekcja ataków poprzez wykrywanie anomalii w sieci i usługach. Monitorując sieć trzeba przede wszystkim zwrócić uwagę na wykrywanie gwałtownych zmian w obciążeniu zasobów w krótkich przedziałach czasu. Może to być gwałtowny wzrost liczby użytkowników, pojawienie się żadań z nieznanymi przypisaniami do urządzeń w sieci czy wreszcie pojawienie się zauważalnie więcej pakietów z flagą TCP- SYN (synchronizuje kolejne numery sekwencyjne), niż ACK (informuje
o istotności pola numer potwierdzenia).

Tego typu anomalie pomoże nam wykryć np. NetFlow, który analizuje próbki przepływów sieciowych. Przekazuje on informacje o miejscu ataku, jego rodzaju oraz sile. Więcej informacji tutaj.

Godny uwagi jest także Zabbix, monitorujący szereg parametrów sieci i serwerów. Poleganie na próbkach jest pewnym uproszczeniem, ponieważ nie są w nich uwzględnione duże części informacji. Potrzeba zatem więcej czasu, aby ustalić, że mamy do czynienia z jakimś poważnym naruszeniem bezpieczeństwa i nie jest to fałszywy alarm.


Redundacja usług DNS

Należy rozważyć rezygnacja z używania własnego serwera DNS w konfiguracji, w której odpowiada on na wszystkie żądania. Serwer DNS powinien być równoważnie obciążany, na podobnej zasadzie, co serwery WWW. 

W sytuacji, kiedy mimo wszystko dojdzie jednak do ataku, można zlecić jego odparcie zewnętrznej firmie (po finansowej analizie zysków i strat). Inną metodą będzie zlokalizowanie „wąskiego gardła” i podjęcie odpowiednich kroków w celu odciążenia serwera oraz urządzeń pośredniczących, w celu zwiększenia mocy obliczeniowej/ zmniejszenia obciążenia pamięci. Czasami będzie się to wiązało z koniecznością tymczasowego wyłączenia niektórych opcji ochrony, jak na przykład monitoring.

Lubisz dzielić się wiedzą i chcesz zostać autorem?

Podziel się wiedzą z 160 tysiącami naszych czytelników

Dowiedz się więcej