DDoS

DDoS (distributed denial of service) to rozproszona odmiana ataku odmowy usługi (denial of service, DoS), w której wiele maszyn działa razem przeciw jednemu celowi ^[1]. Skutek jest ten sam co przy zwykłym DoS: uprawnieni użytkownicy tracą dostęp do systemu, strony albo usługi sieciowej ^[1]. Sekurak zwraca uwagę, że ataki z tej rodziny nie niszczą danych, tylko utrudniają albo uniemożliwiają dostęp do nich ^[2]. Ruch z tysięcy źródeł trudno odfiltrować, bo nie ma jednego adresu, który wystarczy zablokować.

Jak działa

Atakujący potrzebuje wielu maszyn. Zwykle jest to botnet, czyli sieć przejętych urządzeń podłączonych do internetu; CISA wskazuje, że botnety często wynajmuje się w ramach usług „ataku na zlecenie” ^[1]. Sekurak pisał już w 2014 roku, że botnety liczą dziesiątki, a nawet setki tysięcy urządzeń zombie ^[2]. Operator wysyła polecenie, a boty jednocześnie zaczynają słać ruch do ofiary.

Drugą techniką jest amplifikacja przez odbicie. Protokół UDP nie sprawdza adresu nadawcy, więc atakujący podszywa się pod adres ofiary i wysyła krótkie zapytania do publicznych serwerów; te odpowiadają ofierze znacznie większymi pakietami ^[3]. To odmiana spoofingu. Przebieg pokazuje schemat poniżej.

RYS. 1DDoS z odbiciem i wzmocnieniem

Siłę wzmocnienia opisuje współczynnik BAF, czyli stosunek bajtów odpowiedzi do bajtów zapytania ^[3].

Rodzaje

OWASP dzieli ataki odmowy usługi na trzy warstwy ^[6]. Sekurak stosuje podobny podział na ataki na protokoły, ataki wolumetryczne i ataki na logikę aplikacji ^[2].

• Wolumetryczne. Zapychają łącze dużą ilością ruchu ^[6]. Tu mieszczą się ataki z wzmocnieniem przez DNS, NTP czy memcached.
• Na protokół i sesje. Wyczerpują zasoby serwera i urządzeń pośrednich, takich jak zapory i load balancery ^[6]. Klasycznym przykładem jest SYN flood, w którym niedokończone żądania połączenia zajmują dostępne porty serwera ^[1].
• Na warstwę aplikacji. Wyczerpują zasoby aplikacji albo czynią ją bezużyteczną, często bez dużego zużycia pasma ^[6]. Najczęstszym przykładem jest HTTP flood.

Proporcje widać w danych Cloudflare za 2025 rok: firma odpierała średnio około 3925 ataków sieciowych i 1451 ataków HTTP na godzinę ^[8].

W WordPressie

Strona WordPress może być w DDoS celem albo narzędziem.

Jako narzędzie. W marcu 2014 roku SANS Internet Storm Center opisało ataki, w których napastnicy wysyłali do tysięcy stron WordPress żądania POST do /xmlrpc.php z metodą pingback.ping i adresem ofiary ^[5]. Każda z tych stron sama wysyłała wtedy żądanie do ofiary, a atakujący dopisywali losowe parametry, by ominąć pamięć podręczną ^[5]. Jako obronę SANS podał filtr usuwający metodę pingback z XML-RPC i odradzał kasowanie pliku xmlrpc.php, bo przestałyby działać inne funkcje ^[5]:

add_filter( 'xmlrpc_methods', function( $methods ) {
    unset( $methods['pingback.ping'] );
    return $methods;
} );

Jako cel. Każde żądanie do WordPressa uruchamia PHP i zapytania do bazy, więc zalew żądań HTTP szybko wyczerpuje serwer, zwłaszcza na hostingu współdzielonym. Dokumentacja WordPressa zauważa przy okazji ataków siłowych, że nawet nieudane próby logowania mogą zalać stronę żądaniami, a wtyczki zabezpieczające działają w PHP i pod dużym obciążeniem same zużywają zasoby ^[7]. Dlatego zaleca ograniczanie liczby żądań do logowania i XML-RPC na poziomie serwera WWW, a najlepiej na brzegu sieci lub w WAF-ie, zanim ruch dotrze do serwera ^[7].

Jak się bronić

CISA zaleca usługi ochrony przed DoS, które filtrują złośliwy ruch, oraz przygotowany plan odtworzenia działania ^[1]. OWASP dodaje obronę na każdym poziomie ^[6]:

• redundancję i unikanie pojedynczych punktów awarii ^[6];
• pamięć podręczną i serwowanie statycznych zasobów z osobnych domen, na przykład przez CDN ^[6];
• rate limiting, limity połączeń i przepustowości oraz krótkie czasy oczekiwania ^[6];
• sprawdzenie przed wyborem dostawcy internetu, czy potrafi łagodzić DDoS, i komercyjne usługi filtrowania w chmurze przy dużych atakach ^[6].

Pierwszym problemem jest rozpoznanie ataku. CISA wymienia jako możliwe objawy nietypowo wolną pracę sieci, niedostępność stron i szerokie problemy z łącznością ^[1]. Te same objawy daje awaria albo prace serwisowe, dlatego CISA radzi najpierw zapytać administratora sieci, a potem dostawcę internetu, czy problem leży po jego stronie i czy to on nie jest właściwym celem ataku ^[1]. Pomaga w tym stały monitoring dostępności i logi serwera, które pokazują, skąd i do jakich adresów płynie ruch.

Przy atakach wolumetrycznych własny serwer niewiele zdziała, bo łącze zapełnia się, zanim ruch dotrze do aplikacji. Ruch trzeba wtedy przekierować przez sieć o dużej przepustowości, zwykle reverse proxy dostawcy ochrony. Warto też uwzględnić DDoS w planie ciągłości działania.

Historia i przykłady

28 lutego 2018 roku GitHub przyjął atak o szczycie 1,35 Tbps i 126,9 mln pakietów na sekundę, oparty na źle skonfigurowanych serwerach memcached z otwartym UDP ^[4]. Według GitHuba wzmocnienie sięgało 51 000 razy, czyli na każdy bajt wysłany przez atakującego do celu trafiało do 51 KB ^[4]. Serwis był całkowicie niedostępny od 17:21 do 17:26 UTC, po czym ruch przekierowano do Akamai ^[4]. Ruch pochodził z ponad tysiąca systemów autonomicznych i dziesiątek tysięcy punktów końcowych, a po godzinie 18:00 UTC nastąpił drugi skok do 400 Gbps ^[4]. W podsumowaniu firma zapowiedziała automatyzację reakcji na DDoS i zwiększenie odporności sieci brzegowej ^[4].

Skala stale rośnie. Cloudflare podał, że w 2025 roku liczba ataków DDoS przekroczyła 47,1 mln, a rekordowy atak w czwartym kwartale, odnotowany w czasie kampanii botnetu Aisuru-Kimwolf, osiągnął 31,4 Tbps i trwał 35 sekund ^[8].