Atak DDoS - jak go rozpoznać i skutecznie się bronić?

Rozproszona odmowa usługi potrafi zatrzymać sklep internetowy, panel klienta albo API, choć sama infrastruktura nie została przejęta. W tym tekście wyjaśniam, czym jest atak DDoS, jak działa, po czym go rozpoznać i co naprawdę pomaga ograniczyć szkody. Skupiam się na praktyce: różnicach między typami ataków, objawach, których nie wolno bagatelizować, oraz na obronie, którą da się wdrożyć bez chaosu.

Czym jest atak DDoS i czym różni się od DoS

W uproszczeniu chodzi o sparaliżowanie dostępności usługi przez zasypanie jej ruchem. Przy DoS źródło jest jedno lub nieliczne, przy DDoS mamy wiele punktów naraz, więc filtrowanie robi się trudniejsze. Sam serwis nie musi się całkowicie „wyłożyć” - czasem wystarczy, że odpowiada zbyt wolno, a dla użytkownika to już praktycznie przerwa w działaniu.

Ta różnica jest ważna, bo innego działania wymaga pojedynczy napastnik, a innego rozproszona fala ruchu. To prowadzi wprost do pytania, jak taki strumień w ogóle rozlewa się po infrastrukturze.

Jak taki ruch blokuje serwis

Najczęściej za wszystkim stoi botnet, czyli sieć wcześniej przejętych urządzeń, którymi ktoś steruje zdalnie. Mogą to być komputery, routery, kamery, a nawet inne urządzenia IoT. Właśnie dlatego ruch jest rozproszony: każde urządzenie dokłada małą część, ale razem tworzą strumień wystarczający, by zapchać pasmo albo wyczerpać limity połączeń.

Drugi wariant polega na wykorzystaniu pośredników, którzy odpowiadają większą porcją danych, niż sami otrzymali. Taki efekt wzmocnienia sprawia, że pozornie niewielki impuls potrafi uruchomić ogromny strumień odpowiedzi. Na warstwie aplikacji problem bywa jeszcze bardziej podstępny: pojedyncze żądanie może uruchamiać kosztowne obliczenia, długi odczyt z bazy albo generowanie odpowiedzi od zera.

To dlatego niektóre ataki „wyglądają” niegroźnie w samych liczbach, a mimo to zabijają serwis. Kiedy rozumiesz ten mechanizm, łatwiej zobaczyć, z jakim typem incydentu masz do czynienia i gdzie szukać wąskiego gardła.

Najczęstsze rodzaje i wektory

Nie każdy DDoS wygląda tak samo. W praktyce wyróżnia się kilka głównych grup, które uderzają w inne elementy infrastruktury. Ja patrzę na nie przede wszystkim przez pryzmat tego, co się dusi jako pierwsze, bo od tego zależy skuteczna obrona.

W praktyce te warianty często się mieszają. Jeden incydent może zacząć się od zalania łącza, a chwilę później dołożyć kosztowne żądania HTTP. Dlatego sama etykieta na alertcie jeszcze niczego nie rozwiązuje - dopiero obserwacja objawów daje sensowny obraz sytuacji.

Po czym rozpoznać problem w praktyce

Ja zwykle zaczynam od pytania, czy problem widać na łączu, w logach aplikacji czy tylko w jednym fragmencie ruchu. To szybko zawęża diagnozę. Nie każdy skok obciążenia oznacza atak - czasem winna jest zmiana w kodzie, wadliwa konfiguracja albo awaria u dostawcy - ale są objawy, które powinny zapalić czerwoną lampkę.

• Nagły wzrost ruchu z wielu adresów jednocześnie, bez normalnego uzasadnienia biznesowego.
• Skoki opóźnień, timeouty i błędy 502, 503 lub 429 w miejscach, które wcześniej działały stabilnie.
• Ruch sieciowy rośnie, ale konwersje, logowania czy liczba realnych sesji nie idą za tym samym trendem.
• Najmocniej cierpi jeden endpoint, na przykład logowanie, wyszukiwanie, checkout albo publiczne API.
• Monitoring pokazuje wysycenie pasma, kolejki połączeń albo wzrost utraconych pakietów.
• Problem nie pasuje do żadnej planowanej kampanii, wdrożenia ani publikacji, które mogłyby legalnie wywołać taki ruch.

Warto też porównać bieżące dane z typowym profilem ruchu z ostatniej godziny albo z tego samego dnia tygodnia. To często wystarcza, by odróżnić incydent od zwykłego wzrostu zainteresowania. To ważne, bo skuteczna obrona zaczyna się wcześniej niż pierwszy alert.

Jak się bronić, zanim ruch zacznie rosnąć

Z mojego doświadczenia najlepiej działa podejście warstwowe. Nie ma jednego filtra, który zatrzyma wszystko, więc sensowna obrona łączy architekturę, reguły i procedury. Najpierw ograniczam to, co można odciąć na brzegu, a dopiero potem patrzę na aplikację.

• Ukryj origin za CDN-em lub reverse proxy. Użytkownicy nie powinni trafiać bezpośrednio na serwer źródłowy, bo wtedy łatwiej go przeciążyć.
• Włącz WAF i rate limiting. WAF filtruje żądania według reguł, a rate limiting ogranicza liczbę prób w określonym oknie czasu.
• Rozdziel warstwę publiczną od administracyjnej. Panel, SSH i krytyczne API trzymaj za VPN lub inną kontrolą dostępu, zamiast wystawiać je bezpośrednio do internetu.
• Utrzymuj cache dla treści statycznych. Obrazy, CSS i gotowe odpowiedzi odciążają aplikację, ale nie uratują ciężkich, dynamicznych endpointów.
• Przygotuj ochronę upstream. Gdy pasmo jest zalane, liczy się filtracja jeszcze przed Twoim łączem, bo samo dokładanie mocy serwera nie usuwa wąskiego gardła na brzegu sieci.
• Miej monitoring i progi alarmowe. Bez baseline’u nie odróżnisz kampanii marketingowej od incydentu, a bez alertów reakcja zawsze będzie spóźniona.
• Zadbaj o DNS i redundancję. Awaria samego DNS potrafi unieruchomić usługę tak samo skutecznie jak przeciążenie aplikacji.

Gdy przygotowuję taki plan, zawsze rozdzielam ochronę sieciową od ochrony aplikacji, bo każda z nich łata inny rodzaj ryzyka. Gdy mimo to ruch przechodzi dalej, trzeba działać według kolejności, nie intuicji.

Co zrobić, gdy ruch już zalewa infrastrukturę

1. Oddziel incydent od awarii. Sprawdź wykresy, ostatnie wdrożenia i błędy aplikacji. Jeśli problem zaczął się dokładnie po zmianie kodu, nie zakładaj automatycznie, że to DDoS.
2. Włącz ochronę po stronie dostawcy. Skontaktuj się z hostingiem, operatorem lub CDN-em i uruchom filtrację upstream, zanim ruch dotrze do originu.
3. Przytnij najbardziej kosztowne punkty. Ogranicz endpointy, które generują największy koszt: logowanie, wyszukiwanie, raporty, ciężkie API albo niestandardowe operacje backendowe.
4. Komunikuj jasno i krótko. Status page, helpdesk i zespół handlowy powinny mówić to samo: co nie działa, od kiedy i kiedy będzie kolejny update.
5. Zachowaj ślady. Logi, metryki, konfiguracja i zrzuty z dashboardów są potrzebne do analizy po incydencie, nawet jeśli w pierwszej chwili wyglądają niepozornie.
6. Wracaj do normalności stopniowo. Nie zdejmuj ochrony w ciemno. Obserwuj ruch po każdym kroku i dopiero wtedy luzuj reguły.

Nie próbuj ratować wszystkiego ręcznie przez jeden firewall albo przypadkowo wycięty zakres IP. Szybkie, szerokie cięcia często tworzą kolejne wąskie gardło i odcinają realnych użytkowników. Najwięcej szkód robią zwykle nie pakiety, tylko błędne reakcje.

Jakich reakcji unikać, bo tylko pogarszają sytuację

W kryzysie łatwo wpaść w odruchy, które wyglądają sensownie, ale w praktyce pogarszają sytuację. Najczęściej widzę cztery błędy, które kosztują najwięcej czasu i ruchu.

Jeśli któryś z tych punktów brzmi znajomo, lepiej poprawić go teraz niż dopisywać w trakcie kolejnego alarmu. To prowadzi do ostatniej rzeczy, która naprawdę robi różnicę: przygotowania minimum operacyjnego.

Co przygotować dziś, żeby kolejny incydent nie zaskoczył zespołu

Ja traktuję tę listę jak minimum operacyjne. Jeśli jest gotowa, DDoS nadal pozostaje zagrożeniem, ale nie zamienia firmy w improwizację pod presją.

• Aktualna lista kontaktów do hostingu, CDN-u, operatora i osoby decyzyjnej po Twojej stronie.
• Baseline ruchu z normalnego dnia, najlepiej z opisanymi progami alarmowymi.
• Jasna polityka dostępu do originu, paneli administracyjnych, DNS i SSH.
• Krótki plan komunikacji do klientów i partnerów, który można uruchomić od razu.
• Lista endpointów, które można ograniczyć bez ryzyka dla całego biznesu.
• Test przywracania i przegląd reguł co kwartał, zamiast dopiero po awarii.

Największą różnicę robi nie jedna magiczna usługa, tylko połączenie architektury, monitoringu i procedury reakcji. Kiedy te trzy elementy są przygotowane wcześniej, rozproszona odmowa usługi staje się incydentem do opanowania, a nie kryzysem, który zatrzymuje cały biznes.