Nowoczesne DDoS w erze chmury: metody atakujących i odporna architektura obronna

Dlaczego DDoS w erze chmury wygląda inaczej niż „kiedyś”

Od zabijania łącza do duszenia aplikacji i usług zarządzanych

Kiedyś klasyczny atak DDoS kojarzył się głównie z „zalaniem łącza” – tak ogromną ilością pakietów, że router operatora lub firewall po prostu przestawał wyrabiać. W erze chmury ten scenariusz wciąż istnieje, ale coraz częściej główna bitwa toczy się kilka warstw wyżej: w logice aplikacji, usługach zarządzanych i warstwie API.

Dostawcy chmury i duzi operatorzy mają do dyspozycji przepustowości na poziomie, którego pojedyncza organizacja praktycznie nie jest w stanie „zabić” jednym atakiem volumetrycznym. Dlatego atakujący przesuwają się w stronę precyzyjnych uderzeń w komponenty, które nie skalują się liniowo z ruchem: bazy danych, kolejki, brokery komunikatów, funkcje serverless, systemy płatności, systemy logowania czy wyszukiwarki wewnętrzne.

Coraz częściej DDoS nie polega więc na tym, że wszystko jest „down”. Lepiej mówić o wymuszonych degradacjach: API działa, ale rzuca 503 przy części żądań, panel administracyjny jest nieużywalny, webhooki mają gigantyczne opóźnienia, a kluczowe integracje przestają przetwarzać dane. Z punktu widzenia klienta „firma leży”, choć serwerom ciągle coś tam miga.

Elastyczność chmury jako tarcza i jako wektor ataku

Autoskalowanie i elastyczna infrastruktura chmurowa to naturalna obrona przed DDoS: jeśli ruch rośnie, dokładamy instancje, powiększamy pulę workerów, rozszerzamy klastry. Jednak w przypadku niekontrolowanego ataku ten sam mechanizm może zostać wykorzystany przeciwko organizacji.

Atakujący potrafią generować ruch wyglądający na poprawny z punktu widzenia protokołu i podstawowych reguł bezpieczeństwa. W efekcie system autoskalowania niczego podejrzanego nie widzi – liczba żądań rośnie, więc skaluje wszystko w górę. Po kilku godzinach incydentu organizacja ma:

• wyskalowaną infrastrukturę „pod atakujących”,
• ogromny rachunek za zasoby chmurowe,
• użytkowników nadal narzekających na wydajność.

Taki scenariusz to w praktyce połączenie klasycznego DDoS z atakiem na portfel – wyczerpywanie limitów subskrypcji, przekraczanie budżetów i doprowadzanie do automatycznych wyłączeń usług przez samego dostawcę chmury.

Nowy profil atakujących: od skrypt kiddies do DDoS-as-a-Service

Proste skrypty i domowe „booterki” wciąż krążą po sieci, ale główne incydenty DDoS w środowiskach chmurowych są coraz częściej realizowane przez:

• zorganizowane grupy przestępcze (często powiązane z ransomware),
• grupy oferujące komercyjny „DDoS-as-a-Service”,
• podmioty motywowane politycznie lub ideologicznie.

Dostęp do panelu, w którym można zamówić atak DDoS na konkretną domenę lub adres IP, kosztuje mniej niż porządna kolacja. Użytkownik takiej „usługi” nie musi znać się ani na sieciach, ani na chmurze. Infrastruktura atakującego jest zarządzana profesjonalnie: z rozproszonymi botnetami, możliwością szybkiej zmiany wektorów i „profilami ataku” przygotowanymi pod typowe środowiska chmurowe.

Shared Responsibility Model a odpowiedzialność za DDoS

Model odpowiedzialności współdzielonej w chmurze (Shared Responsibility Model) bywa źródłem bardzo bolesnych nieporozumień. Dostawcy chmury zapewniają infrastrukturę i mechanizmy pozwalające bronić się przed atakami, ale to nie oznacza automatycznej ochrony przed DDoS.

W uproszczeniu:

• IaaS – dostawca dba o fizyczną infrastrukturę i podstawowe mechanizmy sieciowe; obrona aplikacji, konfiguracja firewalli, WAF, limitów – po stronie klienta.
• PaaS – dostawca zabezpiecza platformę (np. App Service, Kubernetes zarządzany), ale ruch przychodzący, limity aplikacji, reguły WAF i API Gateway trzeba zaprojektować samodzielnie.
• SaaS – część dostawców oferuje ochronę przed DDoS „w pakiecie”, ale często są to tylko podstawowe zabezpieczenia; integracje, własne webhooki czy API nadal mogą być słabym punktem.

Brak zrozumienia, gdzie kończy się odpowiedzialność dostawcy chmury, a zaczyna odpowiedzialność klienta, prowadzi do klasycznych sytuacji: „przecież myślałem, że Azure/AWS/GCP to zatrzyma” – i późniejszego szoku, gdy okazuje się, że usługę trzeba było skorzystać, włączyć, skonfigurować i… regularnie testować.

Krótki przegląd współczesnych typów DDoS w modelu warstwowym

Ataki L3/L4: volumetryczne, odblaskowe i amplifikacyjne

Na warstwie sieci (L3) i transportu (L4) wciąż królują volumetryczne techniki DDoS. Klasyka gatunku:

• UDP flood – generowanie ogromnej liczby pakietów UDP na losowe porty, co zmusza serwer do sprawdzania i odrzucania ruchu.
• SYN flood – wysyłanie masywnie zainicjowanych, ale niekończonych połączeń TCP, by wyczerpać tablice połączeń.
• ICMP flood – męczenie infrastruktury echo requestami i odpowiedziami.

Do tego dochodzą ataki odblaskowe i amplifikacyjne, w których atakujący podszywa się pod IP ofiary i wykorzystuje serwery z otwartymi usługami (DNS, NTP, Memcached, CLDAP, itp.), aby generowały wielokrotnie większy ruch w stronę ofiary. Stąd prosty skrypt na małym łączu potrafi wygenerować ruch nieosiągalny dla pojedynczej maszyny.

Coraz częściej obserwuje się kampanie mieszane, gdzie w jednym incydencie łączone są różne wektory: już po odcięciu ruchu UDP pojawia się SYN flood, a gdy operator blokuje całe /24, pojawiają się nowe prefixy i do tego pakiety „dziwnie” przypominające zwykły ruch HTTP handshake. To nie jest już chaotyczna zabawa, tylko sterowane scenariusze.

Ataki L7: HTTP(S) flood i ataki na logikę aplikacji

Na warstwie aplikacyjnej (L7) walka bywa znacznie bardziej podstępna. Z zewnątrz wygląda to jak wzrost ruchu użytkowników – nawet nagłówki User-Agent i referery potrafią być wiarygodne. Natomiast realnie aplikacja i jej zależności dostają zadyszki.

Typowe przykłady:

• HTTP(S) flood – masowe wysyłanie żądań GET/POST do wybranych endpointów, często takich, które intensywnie korzystają z bazy danych lub systemów zewnętrznych.
• Ataki na logikę aplikacji – sekwencje żądań powtarzające ciężkie operacje (np. generowanie PDF, raportów, złożonych raportów BI), celowo wybierane tak, by maksymalnie obciążyć procesor i pamięć.
• Ataki niskoprzepsyłowe – pozornie mało żądań, ale każde „kosztowne” (np. wiele parametrów, skomplikowane filtry, nieskończone scrollowanie, które zawsze generuje złożone zapytania).

W takich scenariuszach klasyczne zabezpieczenia sieciowe, oparte tylko na przepustowości, okazują się mało skuteczne. Ruch jest szyfrowany (HTTPS), więc inspekcja pakietów bez terminacji TLS niczego nie wyłapie. Aplikacja wygląda na „po prostu bardzo popularną”, dopóki ktoś nie połączy kropek w logach i metrykach.

Ataki na DNS, TLS, brokery komunikatów i kolejki

Nowoczesna infrastruktura chmurowa opiera się na wielu usługach pomocniczych. Dla atakującego to idealne miejsca, żeby „pociągnąć za mniej oczywisty kabel”:

• Ataki na DNS – przeciążenie serwerów autorytatywnych, ataki na managed DNS w chmurze, próby wyczerpania limitów zapytań; skutkiem jest „znikanie” domen z sieci, mimo że serwery aplikacyjne działają.
• Ataki na warstwę TLS – wymuszanie dużej liczby kosztownych handshake’ów TLS, próby wyczerpania mocy obliczeniowej serwerów terminujących TLS lub load balancerów.
• Ataki na brokery i kolejki – generowanie nadmiarowej liczby wiadomości do systemów typu MQTT, Kafka, RabbitMQ, SQS, Pub/Sub, by wymusić skalowanie konsumentów, zapełnić kolejki, doprowadzić do opóźnień lub przekroczenia limitów.

Przykład: atak L7 na prostą usługę API

Wyobraźmy sobie zespół, który wystawia w chmurze prosty REST API do pobierania danych produktowych. Endpoint /products/search nie ma limitów, bo „przecież to tylko wyszukiwanie”. Zostaje wystawiony za klasycznym load balancerem, chroniony podstawowym firewallem sieciowym. WAF jest, ale głównie na potrzeby ochrony przed SQL injection.

Atakujący uruchamia kampanię, która:

• wysyła tysiące żądań na sekundę z setek tysięcy IP,
• każde żądanie to wyszukiwanie po złożonych filtrach,
• większość żądań jest poprawnie sformatowana i wygląda jak normalne użycie API.

Firewall sieciowy widzi „ładny” ruch HTTP/HTTPS. WAF nie reaguje, bo nie ma tu klasycznych wzorców ataków. Load balancer grzecznie rozrzuca żądania po instancjach. A baza danych i silnik wyszukiwania zaczynają spędzać większość CPU na realizacji tych żądań. Dla użytkowników strona ciągle działa, ale wyszukiwanie produktów nagle trwa 15–30 sekund lub kończy się błędem timeout. Formalnie DDoS, w praktyce – „po prostu nikt nic nie kupuje”.

Chmurowe wektory ataku i specyfika środowisk wielochmurowych

Publiczne IP, load balancery, API Gateway i serverless jako cel

W środowisku chmurowym powierzchnia ataku to nie tylko klasyczne serwery za jednym publicznym adresem IP. W praktyce atakujący widzi:

• publiczne adresy IP VM-ek, klastrów Kubernetes, gatewayów,
• adresy i domeny managed load balancerów (ALB, NLB, Application Gateway itp.),
• publiczne endpointy API Gateway, GraphQL i usług serverless (lambda, functions),
• publiczne interfejsy usług SaaS zintegrowanych z naszą infrastrukturą.

Każdy z tych komponentów ma własne limity, style skalowania i sposoby naliczania opłat. Oznacza to, że:

• atak na endpoint serverless może szybciej „zjeść” budżet niż atak na klasyczny serwer,
• atak na API Gateway może zabić całą rodzinę mikroserwisów stojących za nim,
• atak na load balancer może doprowadzić do przekroczenia limitów backendów, mimo że frontend skaluje się poprawnie.

Bez szczegółowego zrozumienia, gdzie dokładnie kończą się publiczne ścieżki, a gdzie zaczyna się sieć prywatna, buduje się obronę w ciemno.

Komponenty wspólne: DNS, WAF, bazy zarządzane

Atakujący chętnie uderzają w elementy wspólne dla wielu usług, bo ich przeciążenie daje efekt domina. W chmurze klasyczne punkty wspólne to:

• Managed DNS – atak na strefę DNS potrafi unieruchomić jednocześnie WWW, API, panele, integracje.
• WAF działający w trybie fail-open – w razie przeciążenia przepuszcza ruch dalej, aby „nie blokować klientów”, co przy masowym ataku kończy się zalaniem backendów.
• Zarządzane bazy danych – backendy mogą się skalować w górę, ale baza ma ograniczoną liczbę połączeń i maksymalną przepustowość I/O. DDoS L7 na ciężkie zapytania bardzo szybko doprowadza do saturacji.

W wielu projektach to właśnie te komponenty nie mają odpowiednio ustawionych limitów ani planów awaryjnych. W efekcie, nawet jeśli same serwery aplikacyjne radzą sobie z ruchem, cała infrastruktura pada przez źle dobrany rozmiar instancji bazy lub brak zapasowego DNS.

Multi-cloud: rozproszone logi, różne mechanizmy ochrony

Środowiska wielochmurowe niosą ze sobą dodatkowe wyzwania. Gdy aplikacja jest rozbita między kilku dostawców, pojawia się:

• rozproszenie logów i metryk – trudno szybko zbudować pełny obraz ataku,
• różne mechanizmy i nazwy usług ochronnych – trzeba znać każdy ekosystem osobno,
• „najniższy wspólny mianownik” bezpieczeństwa – często poziom ochrony jest taki, jak w najsłabszej chmurze w łańcuchu.

Atakujący lubią wykorzystywać niespójność konfiguracji. Przykładowo: w jednej chmurze jest dobrze skonfigurowany WAF i rate limiting, ale w innym regionie lub u innego dostawcy te same endpointy są wystawione z domyślną konfiguracją. Kampania DDoS jest wtedy „rzeźbiona” tak, by omijać „twarde” wejścia i atakować te bardziej miękkie.

Konfiguracje chmurowe jako nowy wektor ataku

„Miękkie gardła” konfiguracji: limity, autoskalowanie, billing

W modelu chmurowym granica pomiędzy „atak techniczny” a „atak ekonomiczny” jest bardzo cienka. DDoS rzadko ma dziś formę spektakularnego wyłączenia serwisu na godzinę; częściej chodzi o wymuszenie niekontrolowanego skalowania i „wyklikanie” budżetu.

Najczęstsze pułapki konfiguracyjne wyglądają tak:

• Brak twardych limitów – API Gateway bez limitów na klucze lub IP, kolejki bez kontroli wielkości, funkcje serverless bez górnego pułapu równoległych wywołań.
• Autoskalowanie „do bólu” – polityki scale-out wyłącznie na CPU, bez mechanizmów bezpiecznego zatrzymania; przy DDoS wszystko skaluje się heroicznie, aż ktoś z finansów zacznie zadawać pytania.
• Domyślne progi alertów – alarmy ustawione tak, że reagują dopiero, gdy wszystko płonie; w multi-cloudzie często w inny sposób u każdego dostawcy.
• Brak guardrailów billingowych – limity kosztów i powiadomienia o skokowym wzroście zużycia są wyłączone lub ignorowane.

Atak „na portfel” nie musi nawet doprowadzić do awarii – wystarczy, że przez kilka godzin ruch L7 triggeruje intensywne skalowanie funkcji serverless i usług zarządzanych. Technicznie system „działa świetnie”, tylko faktura miesiąc później przyprawia o ból głowy.

Antidotum to świadome traktowanie limitów i kvot jako elementu bezpieczeństwa:

• definiowanie realistycznych, biznesowych limitów ruchu per klient, per klucz API, per funkcja,
• wprowadzenie miękkich i twardych progów (soft/hard limit) z różnymi reakcjami: najpierw logowanie, potem degradacja, na końcu blokada,
• opisane procesy override: kto i jak może tymczasowo podnieść limity bez otwierania wszystkich furtek naraz.

Błędne założenia sieciowe jako furtka dla DDoS

W wielu projektach konfiguracja sieciowa w chmurze jest zbudowana wokół prostego założenia: „wewnątrz VPC jest bezpiecznie”. To częściowo prawda, o ile nikt nie przywiązał do tego VPC dziesiątek tuneli VPN, peeringów, Cloud Connectów i innych magicznych kabli do firm trzecich.

Typowe błędy:

• Publiczne endpointy „do administracji” – panele, interfejsy zarządzające, wewnętrzne API administracyjne wystawione w sieci publicznej „na chwilę” i tak już zostało.
• Źle skonfigurowane security groups / NSG – reguły typu „0.0.0.0/0” dla wygody, bo „przecież WAF i tak chroni” (spoiler: nie zawsze chroni to, co trzeba).
• Zapomniane IP i interfejsy – stare load balancery, testowe instancje z publicznym IP, demo API – z perspektywy atakującego to pełnoprawny punkt wejścia do ataku wolumetrycznego.

DDoS w tej warstwie często zaczyna się od skanowania chmury pod kątem takich „resztek konfiguracji”, a dopiero potem przechodzi w atak. Usunięcie nieużywanych publicznych punktów wejścia i systematyczny higieniczny przegląd security groups robią więcej niż najdroższy firewall w katalogu.

Nowoczesne metody atakujących: od botnetów IoT po inteligentne ataki L7

Ewolucja botnetów: od PC w domu do lodówek i kamer

Botnety nie są nowe, ale charakter ich „mięśni” się zmienił. Kiedyś większość zainfekowanych hostów to były komputery użytkowników domowych. Dziś to:

• urządzenia IoT: kamery, routery SOHO, rejestratory, inteligentne gniazdka,
• serwery z tanich hostingów, często dzierżawione całymi paczkami /24,
• małe urządzenia przemysłowe z archaicznymi systemami.

Takie boty mają ograniczone zasoby, ale za to ogromną liczebność i zróżnicowanie geograficzne. Świetnie nadają się do rozproszonego skanowania i testowania wektorów – część urządzeń wywołuje proste żądania HTTP, inne badają reakcje na nietypowe nagłówki czy parametry zapytań. To daje operatorowi botnetu profil reakcji naszej infrastruktury, zanim jeszcze zacznie właściwy atak.

Do tego dochodzą botnety „profesjonalne” – oparte na przejętych VPS-ach i serwerach w data center. Te z kolei służą do generowania bardziej skomplikowanego ruchu L7, wymagającego pełnego stosu TLS, poprawnego HTTP/2, WebSocketów czy gRPC.

Ataki sterowane w czasie rzeczywistym

Klasą wyżej są kampanie, które przypominają testy penetracyjne wykonywane w trybie live. Atakujący:

• mierzy opóźnienia, kody HTTP, wskaźniki błędów,
• obserwuje, które IP dostają bloczki,
• dostosowuje częstotliwość żądań i zestaw endpointów.

Często używane są do tego własne panele kontrolne z dashboardami niewiele gorszymi od narzędzi SRE. Gdy włączasz dodatkową ochronę, po kilku minutach zmienia się wzorzec ruchu: inny kraj, inny typ klienta (np. przejście z HTTP/1.1 na HTTP/2), inne endpointy.

To atak interaktywny, reagujący na obronę niemal w czasie rzeczywistym. Stare, statyczne reguły WAF i ręczne bloczki IP szybko przestają wystarczać.

„Inteligentne” HTTP(S) flood – ataki na profil normalnego użytkownika

W nowocześniejszych kampaniach L7 atakujący nie wali ślepo w jeden endpoint. Zamiast tego buduje model zwykłego użytkownika:

• miesza ruch do strony głównej, wyszukiwania, logowania, koszyka,
• używa realistycznych User-Agentów, często z rotacją przeglądarek i systemów,
• utrzymuje sesje, korzysta z cookies, a nawet wykonuje prostą logikę JavaScript po stronie klienta.

Dla klasycznych systemów detekcji taki ruch wygląda jak nagły boom popularności. Szczególnie gdy:

• używane są HTTP/2 i multiplexing – wiele zapytań w jednym połączeniu, trudniej liczyć „żądania na IP”,
• celowane są endpointy, które normalnie są dość kosztowne (np. wyszukiwanie, rekomendacje produktowe).

Ciekawym trikiem jest celowy underload – każde pojedyncze źródło wysyła relatywnie mało żądań, ale w skali botnetu daje to stały, kilkukrotny wzrost obciążenia. Aplikacja działa, tylko wolniej, i to w sposób, który trudno jednoznacznie nazwać incydentem.

Omijanie WAF i rate limiting

Atakujący od dawna rozumieją, jak działają WAF-y i limity. Często testują:

• różne ścieżki dostępu – ten sam backend może być osiągalny przez główną domenę WWW, panel partnerski i starszą domenę legacy,
• różne kombinacje nagłówków (X-Forwarded-For, X-Real-IP, custom header z IP klienta) – część systemów rate limiting bazuje na niewłaściwym nagłówku,
• różne regiony i POP-y – ruch rozbijany jest świadomie między wiele wejść anycast/CDN.

Do tego dochodzą sztuczki z przesuwaniem ciężaru:

• atak na endpoint GraphQL, który przechodzi przez WAF, ale używa bardzo skomplikowanych, głębokich zapytań (tzw. GraphQL query depth/complexity attacks),
• nadmierne używanie funkcji filtrów i sortowania w API, których WAF nie traktuje jako „podejrzanych”,
• wykorzystanie endpointów „zdrowotnych” lub monitorujących, które mają poluzowane zasady.

Jeżeli logika limitowania opiera się wyłącznie na IP, atakujący po prostu przechodzą na sieci proxy i residential proxies. Gdy jest oparta tylko na kluczach API – generują lub przejmują dużą liczbę kont niskiego zaufania.

Ataki na łańcuchy zależności

Coraz częściej celem nie jest sama aplikacja, ale jej zależności:

• zewnętrzne usługi płatnicze, antyfraudowe, scoringowe,
• wewnętrzne usługi katalogowe lub tożsamościowe (IdP, SSO),
• mikroserwisy wspólne dla wielu produktów: np. profil użytkownika, cenniki, rekomendacje.

Atak typu DDoS na punkt wspólny skutkuje kaskadą błędów w różnych domenach i aplikacjach. Na poziomie L7 wygląda to czasem jak seria dziwnych timeoutów na drobnych endpointach, które „i tak się kiedyś poprawi”. Tymczasem jest to wstęp do większego incydentu, podczas którego agresor systematycznie bada granice wytrzymałości całego łańcucha.

Projektowanie odpornej architektury: zasady ogólne przed wyborem narzędzi

Myślenie w kategoriach „degradacji kontrolowanej”

Najgorzej działają systemy, które mają tylko dwa stany: „wszystko” albo „nic”. Architekturę warto projektować tak, by istniały pośrednie poziomy dostępności:

• przy rosnącym obciążeniu wyłączane są funkcje niekrytyczne (np. rekomendacje, widgety społecznościowe, rozszerzone raporty),
• po przekroczeniu kolejnego progu część operacji staje się asynchroniczna,
• w skrajnym przypadku udostępniana jest lekka wersja strony lub API „tylko do odczytu”.

To, co w dokumentacji opisuje się jako graceful degradation, w praktyce oznacza bardzo przyziemne decyzje: co konkretnie może przestać działać, żeby klienci nadal mogli zapłacić za to, co kluczowe. Zespół powinien mieć na to gotowy „przełącznik”, a nie improwizować podczas incident calla.

Ograniczanie blast radius: segmentacja i izolacja

W chmurze łatwo o logikę „jeden wielki front, za nim całe królestwo”. Dużo rozsądniejsze jest dzielenie systemu na strefy:

• oddzielenie ruchu publicznego od paneli administracyjnych i integracji B2B,
• różne load balancery / API Gateway dla różnych grup mikroserwisów,
• podział na projekty/abonamenty/chmurowe konta tak, by DDoS na jedną aplikację nie zasysał kwot i limitów globalnych.

Segmentacja nie usuwa DDoS, ale sprawia, że incydent dotyczy konkretnej części biznesu, a nie całej organizacji. Przy multi-cloudzie dochodzi jeszcze aspekt rozdzielenia krytycznych usług tak, by awaria lub błąd limitowania u jednego dostawcy nie odcinał wszystkiego.

Projektowanie „na limity” zamiast „na średnie obciążenie”

Kluczowe decyzje nie powinny opierać się na średnim ruchu, tylko na:

• maksymalnych akceptowalnych wolumenach per typ klienta (publiczny, partner, wewnętrzny),
• twardych limitach mocy usług zarządzanych (bazy danych, kolejki, cache),
• założeniach biznesowych – kto ma być priorytetem w sytuacji skrajnej (np. klienci zalogowani vs anonimowi).

Na tej podstawie dopiero sensowne jest ustawienie limitów w WAF, API Gateway, load balancerach i samych aplikacjach. Architektura powinna „wiedzieć”, że baza wytrzyma np. określoną liczbę równoległych zapytań ciężkich i aktywnie do tego dążyć, np. poprzez kolejkowanie żądań i odrzucanie nadmiaru u bramy.

Obserwowalność jako element obrony

Bez spójnego obrazu sytuacji nawet najlepsze narzędzia ochronne będą wyglądały jak gra w whack-a-mole. Minimum to:

• centralizacja logów z WAF, load balancerów, API Gateway i samych aplikacji,
• metryki na poziomie L7: RPS per endpoint, czasy odpowiedzi, kody statusu, liczba błędów,
• metryki z komponentów zarządzanych: limity połączeń do bazy, kolejki oczekujących, wykorzystanie IOPS.

Przydatne są proste, ale dobrze przemyślane dashboardy. Jeden zespół SRE wspominał, że największą różnicę zrobił nie superzaawansowany system ML, tylko zwykła tablica pokazująca żądania na sekundę dla pięciu najcięższych endpointów – po latach nikt już nie „przegapił” powolnego DDoS na funkcję raportów.

Testy przeciążeniowe z perspektywą DDoS

Klasyczne testy loadowe skupiają się na sprawdzeniu, ile RPS aplikacja obsłuży, gdy ruch jest ładny, równy i przewidywalny. Atakujący tak nie działa. Warto dodać scenariusze:

• nagły skok ruchu do konkretnych, ciężkich endpointów (np. 5–10x w ciągu minuty),
• mieszanie ruchu prawdziwego z generowanym, aby zobaczyć, kiedy ucierpią zwykli użytkownicy,
• testowanie cutoffów: w którym momencie limity i mechanizmy degradacji zaczynają działać.

Chaos engineering w kontekście DDoS

Dopóki odporność na DDoS istnieje głównie w diagramach architektonicznych, jest bardziej życzeniem niż gwarancją. Dobrym krokiem jest systematyczne psucie własnej infrastruktury – oczywiście w kontrolowany sposób.

Typowe eksperymenty, które pomagają wyłapać słabe punkty przed prawdziwym atakiem:

• sztuczne dławienie przepustowości między wybranymi segmentami (np. między frontem a bazą danych), aby sprawdzić zachowanie timeoutów i retry,
• symulacja częściowej niedostępności CDN / WAF (np. wyłączenie konkretnego regionu lub POP-u w środowisku testowym),
• wprowadzenie opóźnień na wybranych mikroserwisach, aby zobaczyć, czy klient „odpuści”, czy załamie się łańcuch zależności.

Przy takich testach liczy się nie tylko to, czy system „przeżyje”, ale też:

• jak szybko zespoły zorientują się, że coś jest nie tak,
• czy dashboardy pokazują faktyczną przyczynę, czy tylko fale czerwonych alertów,
• czy runbooki obsługujące DDoS są rzeczywiście użyteczne, czy wymagają dopisania „tl;dr” na pierwszej stronie.

Warstwa sieciowo–infrastrukturalna: filtry, scrubbing, anycast i CDN

Architektura wejścia ruchu: edge jako pierwsza linia obrony

Najbardziej kosztowne błędy to te, które wpuszczają niepotrzebny ruch zbyt daleko w głąb infrastruktury. W modelu chmurowym sensownie jest traktować edge (WAF/CDN/edge LB) jako miejsce, gdzie podejmowana jest większość decyzji „wpuszczam / nie wpuszczam”.

Praktyczny układ, który sprawdza się przy większej skali:

• publiczne DNS kierujące na globalny anycast CDN / WAF,
• stamtąd ruch dopiero na wewnętrzne load balancery w chmurze (prywatne IP, brak bezpośredniego ruchu z internetu),
• mikroserwisy schowane w sieciach prywatnych, bez publicznych adresów, komunikacja wyłącznie przez LB / API Gateway.

W takiej konfiguracji atakujący „bije” w warstwę, która jest projektowana pod bardzo duży wolumen, a koszt jednostkowy odrzucenia pakietu czy żądania jest niski.

Filtry i ACLe bliżej źródła problemu

Dużo ruchu można zatrzymać jeszcze zanim trafi na WAF czy aplikację. Kluczowe mechanizmy to:

• network ACL / security groups ograniczające zakres portów i protokołów (otwarte tylko to, co rzeczywiście jest potrzebne),
• filtracja na poziomie firewalli chmurowych (np. blokady na konkretne ASN, kraje, typy ruchu UDP przy L3/L4 floodach),
• reguły rate limiting na poziomie LB dla kategorii ruchu, które nie wymagają pełnego parsowania HTTP.

Przykładowo: jeżeli aplikacja nie korzysta z UDP do obsługi użytkowników końcowych, sensowne jest agresywne traktowanie gwałtownego skoku UDP na publicznych interfejsach. Z punktu widzenia ochrony DDoS dobrze mieć „domyślną nieufność” wobec wszystkiego, co nie pasuje do normalnego profilu ruchu.

Scrubbing centers i blackholing – kiedy nie opłaca się przyjmować ruchu

Przy dużych atakach wolumetrycznych granicą staje się nie tyle sama aplikacja, ile przepustowość łączy i peeringów. Wtedy wchodzą w grę dwa narzędzia, często realizowane przez dostawcę chmury lub operatora:

• scrubbing center – przekierowanie (np. przez BGP) ruchu na wyspecjalizowaną infrastrukturę „czyszczącą”, która odfiltrowuje większość szumu,
• blackholing (RTBH) – celowe „utopienie” ruchu do określonego IP, gdy nie ma sensu próbować dalszej obrony, bo priorytetem jest ochrona reszty adresacji.

W praktyce te mechanizmy mają sens tylko wtedy, gdy są uzgodnione i przetestowane zawczasu. Szybka decyzja typu „podnieśmy RTBH na tym prefiksie” wymaga jasnych procedur: kto ją podejmuje, w jakich warunkach i jak długo blokada ma pozostać.

Anycast, georozproszenie i „rozbijanie” ataku

Anycast w połączeniu z globalnym CDN potrafi zamienić jeden duży DDoS w kilka mniejszych, rozłożonych po świecie. Trik polega na tym, żeby ta „dystrybucja bólu” była naprawdę korzystna:

• POP-y i regiony muszą być zaprojektowane tak, by nie współdzieliły krytycznych wąskich gardeł (np. jednego klastra bazy),
• limitowanie i reguły WAF powinny być możliwie lokalne – inaczej zalew w jednym regionie wywoła blokady globalne,
• routing DNS / geolocation musi przewidywać scenariusz „odcinamy lub dławimy część regionów”, kierując ruch gdzie indziej.

W multi-cloudzie anycast bywa realizowany różnie u różnych dostawców. Często sensowne jest rozdzielenie ruchu na poziomie DNS (np. podział ruchu według kontynentów między chmury) i niezależne polityki ochronne po każdej stronie.

CDN jako bufor i tarcza dla statycznych i półstatycznych treści

Treści, które da się skeszować na brzegu, rzadko powinny trafiać przy każdym żądaniu do backendu. W kontekście DDoS CDN pomaga na kilku poziomach:

• zmniejsza liczbę requestów przechodzących do aplikacji,
• przełamuje część korelacji IP–backend (atakujący „bije” w POP, a nie w pojedynczy serwer),
• przy odpowiedniej konfiguracji może służyć jako fallback – np. serwować półstatyczne strony błędu, gdy backend jest niedostępny.

W praktyce największe zyski dają:

• agresywne cache’owanie elementów UI, które rzadko się zmieniają (CSS, JS, layouty),
• cache’owanie stron dla anonimowych użytkowników przy użyciu ETag / Cache-Control i mechanizmów „stale-while-revalidate”,
• przygotowanie wersji „read-only” widoków (np. katalog produktów bez pełnej personalizacji), które CDN może serwować nawet przy problemach z backendem.

Jeżeli CDN jest używany tylko jako „ładna dystrybucja statycznych plików”, potencjał ochronny zostaje w dużej mierze zmarnowany.

Ograniczanie wewnętrznych efektów DDoS: kolejki, backpressure i circuit breakers

Atak na L3/L4 to jedno, ale nawet częściowo przefiltrowany ruch może skutecznie zatkać kluczowe usługi wewnętrzne. Tu wchodzą wzorce znane z architektury rozproszonej:

• kolejkowanie kosztownych operacji (np. przetwarzanie płatności, generowanie raportów) zamiast ich natychmiastowej realizacji po stronie API,
• backpressure – świadome informowanie warstw wyższych „więcej nie przyjmę, zacznij odrzucać” zamiast milczącego timeoutu,
• circuit breakers – odcinanie wywołań do usług, które i tak są przeciążone, z szybkim zwracaniem błędu lub odpowiedzi degradującej.

Bez tych mechanizmów nawet dobrze przefiltrowany DDoS może przełożyć się na kaskadowe awarie: najpierw API, potem baza, na końcu cache, który próbował bohatersko „ratować sytuację”. Taka heroiczna śmierć cache’a zwykle nie jest celem architekta.

Warstwa aplikacyjna i API: WAF, rate limiting i odporne wzorce projektowe

Projektowanie endpointów „pod limitowanie”

Wiele problemów z DDoS L7 bierze się z tego, że endpointy powstają wyłącznie „pod funkcję biznesową”, a ograniczenia przychodzą dopiero później. Zdecydowanie korzystniej jest planować od razu:

• jak będziemy liczyć zużycie – na użytkownika, organizację, klucz API, IP, fingerprint przeglądarki czy kombinację tych elementów,
• jakie klasy operacji istnieją (tanie odczyty, drogie odczyty, operacje modyfikujące, operacje masowe),
• jak zachować się przy przekroczeniu limitu – twardy błąd, tryb degradacji, opóźnianie odpowiedzi.

Na tej podstawie można definiować sensowne limity, a nie jedną magiczną liczbę „1000 requestów na minutę per IP”, która będzie zła zarówno dla atakującego, jak i dla realnego klienta korporacyjnego z NAT-em.

WAF jako narzędzie kontekstowe, nie uniwersalny młotek

Nowoczesne WAF-y są w stanie analizować ruch daleko poza prostym „czy jest SQL injection w URL”. W kontekście DDoS kluczowe funkcje to:

• profile behawioralne na poziomie ścieżek – inne oczekiwania wobec ruchu do /api/login, a inne do /api/search,
• analiza anomalii na poziomie nagłówków i wzorców sesji (nienaturalne sekwencje żądań, dziwne korelacje UA vs. kraj vs. czas),
• dynamiczne reguły – możliwość szybkiego wprowadzenia dodatkowych filtrów dla konkretnego ataku bez restartu połowy infrastruktury.

W praktyce sporo obron nie działa, bo WAF jest albo w trybie „allow almost all”, albo każde odchylenie kończy się false positive na kluczowych klientach. Zespół bezpieczeństwa i zespoły produktowe muszą wspólnie ustalić, co jest „normalne” w danej aplikacji i jak wygląda akceptowalna liczba blokad.

Rate limiting z rozróżnieniem „kto, do czego i jak często”

Rate limiting ma dwa oblicza: pancerne (chronimy system) i biznesowe (nie wkurzamy klientów). W światach produkcyjnych sprawdza się podejście warstwowe:

• limity globalne – ile łącznie ruchu jesteśmy w stanie przyjąć, zanim zaczniemy twardo odrzucać,
• limity per plan / klienta – różne progi dla anonimów, użytkowników darmowych i płacących,
• limity per endpoint / kategoria operacji – osobne widełki na logowanie, wyszukiwanie, operacje masowe.

Dla DDoS szczególnie przydatne są:

• token bucket / leaky bucket z małym „wiaderkiem” na krótkie piki i większym, ale ograniczonym „zbiornikiem” na dłuższy okres,
• „soft limits” – po przekroczeniu progu nie ma od razu HTTP 429, tylko wydłużany jest czas odpowiedzi, co zniechęca część agresywnych klientów,
• limity na operacje kosztowne (np. raporty, eksporty, głębokie wyszukiwania), z osobnymi progami i komunikatami dla użytkowników.

Przy multi-cloudzie i wielu regionach wyzwaniem jest spójność limitów. Jeżeli jedna część świata ma inne progi, atakujący szybko to odczyta. Rozwiązaniem bywa centralny „service limitów” lub synchronizacja konfiguracji WAF / gatewayów przez pipeline’y CI/CD.

Odporne wzorce w API: paginacja, limity złożoności, „twarde nożyczki”

W API szczególnie podatne na DDoS są operacje typu „daj wszystko” oraz „policz coś bardzo skomplikowanego”. Kilka prostych reguł oszczędza wielu łez podczas incydentów:

• paginacja obowiązkowa – brak endpointów typu /users/all; zawsze limit + offset / cursor, z maksymalnym limitem strony,
• limity złożoności zapytań – w GraphQL: depth i complexity; w REST: ograniczenia liczby filtrów, sortowań i pól do zwrócenia w jednym żądaniu,
• „twarde nożyczki” – przy przekroczeniu limitu kosztu operacji zwracany jest błąd lub ucięty wynik z jasną informacją.

Podczas realnych kampanii L7 często wychodzi na jaw, że „mały, pomocniczy endpoint raportowy” potrafi zjeść więcej CPU niż cała reszta systemu. Dobrym nawykiem jest klasyfikowanie endpointów według kosztu i rangi biznesowej, a następnie stosowanie innych zasad do każdej klasy.

Autoryzacja i tożsamość jako narzędzie obronne

Jeżeli każdy może robić wszystko anonimowo, obrona sprowadza się do walki z IP-ami i fingerprintami. Dużo efektywniejszy model to taki, w którym:

• większość kosztownych operacji wymaga silnej tożsamości (konto, plan, rola),
• limity i priorytety są powiązane z poziomem zaufania do tej tożsamości,
• adresy IP i inne cechy sieciowe są tylko dodatkowym sygnałem, a nie fundamentem całej polityki.

W integracjach B2B dużą pomocą są podpisywane żądania (HMAC, mTLS) oraz osobne pule adresów źródłowych dla partnerów. Dzięki temu łatwiej rozróżnić atakujący ruch „z internetu” od problemów z integracją, a do tego precyzyjniej stosować dławienie.

Adaptacyjne mechanizmy ochrony po stronie aplikacji

Najczęściej zadawane pytania (FAQ)

Na czym polega różnica między „klasycznym” DDoS a DDoS w środowisku chmurowym?

Tradycyjny DDoS kojarzył się głównie z zabiciem łącza – tyle pakietów na wejściu, że router, firewall czy serwer przestawały odpowiadać. W chmurze taki scenariusz nadal występuje, ale coraz częściej główny cel jest wyżej: logika aplikacji, bazy danych, API, kolejki czy funkcje serverless.

W praktyce zamiast pełnej niedostępności mamy wymuszoną degradację: część żądań kończy się błędami 503, webhooki mają gigantyczne opóźnienia, panel admina zamienia się w pokaz slajdów, a integracje „gubią” dane. Z zewnątrz firma „leży”, choć serwery wciąż coś przetwarzają.

Jak atakujący wykorzystują autoskalowanie w chmurze przeciwko ofierze?

Atakujący generują ruch, który wygląda poprawnie z punktu widzenia protokołu i prostych reguł bezpieczeństwa. System autoskalowania widzi tylko wzrost żądań, więc zgodnie ze swoją rolą dokłada instancje, rozszerza klaster, zwiększa liczbę workerów. Działa idealnie… ale dla atakującego.

Po kilku godzinach organizacja ma wyskalowaną infrastrukturę „pod boty”, rosnący rachunek za zasoby chmurowe i użytkowników, którzy nadal skarżą się na wydajność. Taki scenariusz to hybryda klasycznego DDoS i ataku na portfel: zużywanie limitów subskrypcji i doprowadzenie do automatycznych odcięć usług przez samego dostawcę chmury.

Jakie są najczęstsze typy ataków DDoS w chmurze na poziomie sieci (L3/L4)?

Na warstwie sieci i transportu dominują ataki volumetryczne oraz odblaskowe. Klasyka to UDP flood, SYN flood i ICMP flood – ogromne ilości pakietów mają zająć łącze i zasoby urządzeń po drodze, zanim ruch dotrze do właściwej aplikacji.

Często dochodzą do tego techniki odblaskowe i amplifikacyjne, gdzie atakujący podszywa się pod IP ofiary i wykorzystuje serwery DNS, NTP, Memcached czy inne usługi z otwartymi portami do wielokrotnego zwielokrotnienia ruchu. Coraz częściej obserwuje się kampanie mieszane: po zablokowaniu jednego wektora natychmiast pojawia się kolejny, z inną charakterystyką ruchu.

Czym różnią się ataki DDoS na warstwę aplikacji (L7) od klasycznych ataków na łącze?

Ataki L7 celują w to, co jest „droższe” dla aplikacji niż zwykłe przyjęcie pakietu: złożone zapytania HTTP(S), ciężkie operacje biznesowe, raporty, wyszukiwanie z wieloma filtrami. Ruch wygląda jak legalny: prawidłowe nagłówki, wiarygodne User-Agenty, normalne metody HTTP, często wszystko po HTTPS.

Zamiast zapchać łącze, atak obciąża bazę danych, cache, systemy zewnętrzne czy logikę aplikacji. Efekt to spadek wydajności, timeouty, błędy 5xx na wybranych endpointach. Klasyczne zabezpieczenia sieciowe, patrzące tylko na przepustowość, niewiele tu wykrywają – potrzeba WAF, reguł na API Gateway i dobrego monitoringu zachowania aplikacji.

Co oznacza Shared Responsibility Model w kontekście ochrony przed DDoS?

Shared Responsibility Model określa, które elementy zabezpieczeń leżą po stronie dostawcy chmury, a które po stronie klienta. Dostawca zapewnia infrastrukturę i podstawowe mechanizmy (np. filtrowanie na brzegu sieci), ale nie bierze odpowiedzialności za to, jak zaprojektujesz swoje API, limity ruchu czy reguły WAF.

W uproszczeniu:

• IaaS – dostawca zabezpiecza serwery fizyczne i sieć, natomiast konfiguracja firewalli, WAF, rate limiting i obrona aplikacji to zadanie klienta.
• PaaS – platforma (np. zarządzany Kubernetes, App Service) jest chroniona, ale sposób ekspozycji aplikacji, limity per endpoint i reguły na API Gateway trzeba zaplanować samemu.
• SaaS – część usług ma wbudowaną ochronę DDoS, jednak integracje, webhooki czy własne API nadal mogą pozostać słabym punktem.

Najczęstszy błąd brzmi: „myśleliśmy, że AWS/Azure/GCP to zrobi za nas”. Niestety – zwykle trzeba usługę ochronną włączyć, skonfigurować i regularnie sprawdzać, czy faktycznie działa.

Kim są dzisiejsi sprawcy ataków DDoS i jak działa „DDoS-as-a-Service”?

Proste skrypty „na flooda” nadal krążą po sieci, ale poważniejsze incydenty w chmurze są coraz częściej realizowane przez zorganizowane grupy przestępcze (często powiązane z ransomware), komercyjne ekipy oferujące „DDoS-as-a-Service” oraz grupy motywowane politycznie lub ideologicznie.

Dostęp do panelu, w którym można „zamówić” atak na wybraną domenę lub IP, potrafi kosztować mniej niż dobry obiad. Użytkownik takiej usługi nie musi rozumieć sieci ani chmury – wybiera cel, czas trwania i profil ataku. Infrastruktura po stronie atakującego jest zarządzana jak normalny biznes: rozproszone botnety, szybka zmiana wektorów, predefiniowane scenariusze pod typowe środowiska chmurowe.

Jakie komponenty w architekturze chmurowej są szczególnie wrażliwe na DDoS?

W środowiskach chmurowych „wąskimi gardłami” stają się często nie same serwery aplikacyjne, ale usługi pomocnicze. Typowe cele to:

• DNS – przeciążenie serwerów autorytatywnych lub managed DNS, co sprawia, że domena znika z sieci, choć aplikacja działa;
• warstwa TLS – masowe wymuszanie kosztownych handshake’ów, które zużywają zasoby load balancerów i bramek;
• brokery i kolejki (Kafka, RabbitMQ, SQS, Pub/Sub itp.) – zalew wiadomości, który wymusza skalowanie konsumentów, zapycha kolejki i powoduje opóźnienia;
• ciężkie endpointy API (np. wyszukiwarka, generowanie raportów) – pozornie normalny ruch, ale z ogromnym kosztem po stronie CPU, RAM i bazy danych.

Często to właśnie te elementy „puszczają” jako pierwsze, choć dashboard łagodnie sugeruje, że „użytkownicy po prostu pokochali wasze API”.

Co warto zapamiętać

• DDoS w chmurze coraz rzadziej „zabija łącze”, a częściej dławi konkretne komponenty aplikacji (API, bazy danych, kolejki, funkcje serverless), powodując degradację usług zamiast pełnej awarii.
• Elastyczność i autoskalowanie chmury działają jak miecz obosieczny: przy dobrze zaprojektowanej ochronie pomagają przetrwać atak, ale przy braku kontroli mogą skończyć się wyskalowaniem infrastruktury „pod napastnika” i gigantycznym rachunkiem.
• Nowy ekosystem DDoS-as-a-Service sprawia, że skuteczne ataki są dostępne „z menu” dla osób bez wiedzy technicznej, za to z infrastrukturą przestępczą zarządzaną profesjonalnie i nastawioną na środowiska chmurowe.
• Shared Responsibility Model nie obejmuje automatycznej ochrony przed DDoS – dostawca daje narzędzia i infrastrukturę, ale reguły WAF, limity, konfigurację firewalli i testy obrony trzeba zaprojektować, włączyć i utrzymywać samodzielnie.
• W modelu IaaS, PaaS i SaaS granica odpowiedzialności za DDoS przesuwa się, ale nigdy nie znika: nawet w SaaS integracje, webhooki i własne API pozostają potencjalnym „wąskim gardłem” do zduszenia ruchem.
• Klasyczne ataki L3/L4 (UDP/ICMP/SYN flood, odblaskowe i amplifikacyjne) nadal są groźne, zwłaszcza gdy są łączone w kampanie mieszane, które adaptują się do kolejnych blokad operatora niczym dobrze przygotowany test odporności.

Bibliografia i źródła

• NIST SP 800-61 Rev. 2: Computer Security Incident Handling Guide. National Institute of Standards and Technology (2012) – Ramy reagowania na incydenty, w tym ataki DDoS
• NIST SP 800-184: Guide for Cybersecurity Event Recovery. National Institute of Standards and Technology (2016) – Odzyskiwanie po incydentach, planowanie ciągłości usług
• ENISA Threat Landscape for DDoS Attacks. European Union Agency for Cybersecurity (ENISA) (2020) – Przegląd współczesnych technik DDoS, trendy i scenariusze
• AWS Best Practices for DDoS Resiliency. Amazon Web Services (2023) – Rekomendacje architektoniczne i usługi ochrony DDoS w AWS
• Azure DDoS Protection: Overview and Best Practices. Microsoft Azure (2023) – Opis usług Azure DDoS Protection i wzorców obrony
• Google Cloud Armor Security Overview. Google Cloud (2023) – Mechanizmy ochrony L3–L7, WAF i DDoS w Google Cloud
• DDoS Attack Trends. Cloudflare (2023) – Statystyki i analiza współczesnych kampanii DDoS, L3–L7
• The 2023 DDoS Threat Intelligence Report. NETSCOUT (2023) – Raport o skali, wektorach i ewolucji ataków DDoS globalnie