Ataki na warstwę 3, 4 i 7
Ataki na warstwę 3 celują w warstwę sieciową (IP, ICMP) — przykładami są ICMP flood i ataki fragmentacji IP. Ataki na warstwę 4 celują w warstwę transportową (TCP, UDP) — przykładami są SYN flood, amplifikacja UDP i amplifikacja DNS. Ataki na warstwę 7 celują w warstwę aplikacji (HTTP, HTTPS) — przykładami są HTTP GET/POST flood i Slowloris. Każda warstwa wymaga innej mitygacji.
Ataki wolumetryczne na warstwach 3 i 4 próbują nasycić sam łącz sieciowy. Największe publicznie ujawnione ataki przekroczyły próg wielu terabitów na sekundę — Cloudflare zgłosił mitygację ataku 7,3 Tbps w maju 2025 r., a AWS Shield zgłosił atak 2,3 Tbps już w lutym 2020 r. Te ataki działają, ponieważ protokoły amplifikacji (DNS, NTP, memcached, CLDAP) pozwalają, by mała sfałszowana zapytanie wywołało znacznie większą odpowiedź wysłaną do ofiary — udokumentowane są współczynniki amplifikacji 50x dla DNS, 200x dla NTP i 50 000x dla memcached. Ataki protokołowe na warstwie 4 — SYN flood, ACK flood, ataki na sfragmentowane pakiety — wyczerpują stan śledzenia połączeń na firewallach i load balancerach, zamiast nasycać pasmo. Ataki warstwy 7 są najmniejsze pod względem bajtów, ale najtrudniejsze do filtrowania: HTTP flood ze 100 000 węzłów botnetu wygląda bit-w-bit jak ruch realnych użytkowników i tylko logika świadoma aplikacji potrafi je odróżnić.
Blackhole BGP i remote-triggered black hole (RTBH)
Blackhole BGP to brutalna, ale skuteczna mitygacja ostatniej szansy: operator sieci ogłasza trasę /32 dla atakowanego IP w specjalnej społeczności BGP „blackhole”, mówiąc wszystkim peerom upstream, by całkowicie odrzucali ruch do tego IP. Cel pozostaje offline, ale reszta sieci pozostaje aktywna. RTBH jest ustandaryzowany w RFC 5635 i obsługiwany przez każdego operatora Tier 1.
RTBH jest udokumentowany w RFC 5635 (sierpień 2009 r.) i działa przez oznaczenie trasy atrybutem społeczności, który peery upstream interpretują jako „odrzucaj cały ruch kierowany do tego prefiksu”. Mitygacja jest totalna — chronione IP staje się nieosiągalne z całego internetu, w tym dla uprawnionych użytkowników — ale chroni resztę floty klientów przed szkodami pobocznymi. Ze względu na swoją radykalność RTBH jest właściwy, gdy pojedyncze IP jest nasycane atakiem o setkach gigabitów, a koszt szerszej awarii przewyższa wartość utrzymania tego jednego IP online. Wiele niskobudżetowych planów VPS „chroniących przed DDoS” oznacza dokładnie to: dostawca zaleje twoje IP czarną dziurą podczas ataku, by chronić resztę swojej floty. To z definicji jest mitygacją odmowy usługi, ale chronionym zasobem jest sieć dostawcy, nie twoja.
Centra scrubbingu i przekierowanie ruchu
Centrum scrubbingu to utwardzona lokalizacja sieciowa, w której ruch ataku jest filtrowany, a czysty ruch przekazywany do źródła. Ruch jest tam przekierowywany przez ogłoszenie BGP (zawsze włączone lub na żądanie) lub wskazania DNS. Pojemność scrubbingu w Tbps to wskaźnik nagłówkowy — najwięksi dostawcy operują ponad 200 Tbps zagregowanego scrubbingu, a specjalistyczni dostawcy hostingu zwykle reklamują 1-10 Tbps.
Centra scrubbingu uruchamiają wyspecjalizowane urządzenia — Arbor TMS, Radware DefensePro, A10 Thunder, NSFOCUS ADS lub własne wielkoskalowe potoki Linux/DPDK — które inspekcjonują każdy pakiet, klasyfikują wzorce łagodne i złośliwe oraz przekazują tylko czystą frakcję do źródła. Przekierowanie odbywa się zwykle przez BGP: prefiks klienta jest ogłaszany z anycastowej sieci dostawcy scrubbingu podczas ataku, ściągając cały ruch do najbliższego centrum scrubbingu. Po wyczyszczeniu ruch jest tunelowany (GRE, IPSec, dedykowany cross-connect lub bezpośredni peering) z powrotem do serwera źródłowego. Opóźnienie scrubbingu to zwykle 1-3 ms w regionie plus dodatkowa droga, którą wprowadza przekierowanie. Scrubbing zawsze włączony utrzymuje przekierowanie na stałe, eliminując czas startu mitygacji kosztem stałego podatku opóźnień. Scrubbing na żądanie przekierowuje tylko podczas wykrytych ataków, co jest tańsze, ale wprowadza okno aktywacji 30-180 sekund, w trakcie którego atak dociera.
Mitygacja zawsze włączona vs na żądanie
Mitygacja zawsze włączona kieruje cały ruch przez warstwę scrubbingu 24/7 — zerowy czas aktywacji, ale każdy pakiet płaci niewielki podatek opóźnień (zwykle 1-5 ms). Mitygacja na żądanie aktywuje się tylko przy wykryciu ataku, eliminując opóźnienie w stanie ustalonym, ale eksponując źródło w trakcie okna aktywacji (zwykle 30-180 sekund). Konfiguracje hybrydowe łączą oba podejścia: zawsze włączone dla HTTP/HTTPS, na żądanie dla surowego ruchu IP.
Wybór między zawsze włączoną a na żądanie to kompromis między opóźnieniami w stanie ustalonym a podatnością w oknie ataku. Usługi wrażliwe na opóźnienia — wieloosobowe serwery gier, trading o niskich opóźnieniach, głos/wideo — zazwyczaj wybierają na żądanie i akceptują lukę aktywacji, bo każda milisekunda RTT w stanie ustalonym ich kosztuje. Publiczne usługi webowe, API i aplikacje SaaS zazwyczaj wybierają zawsze włączoną lub w pełni proksowaną topologię typu CDN, w której IP źródła nie jest publicznie znane, eliminując okno ataku w całości. Nowoczesni dostawcy edge cloud (Cloudflare, Fastly, AWS Shield Advanced, Google Cloud Armor) domyślnie skłaniają się ku zawsze włączonej, bo ich sieć już terminuje ruch w setkach lokalizacji brzegowych, a „objazd” jest praktycznie zerowy.
Rate limiting, WAF i obrona warstwy aplikacji
Rate limiting ogranicza liczbę żądań na adres źródłowy, sesję lub URL, tępiąc floody warstwy 7 bez wpływu na uprawniony ruch. Web Application Firewall (WAF) inspekcjonuje żądania HTTP względem reguł — ochrony OWASP Top 10, niestandardowych reguł stawek, blokad geograficznych, wyzwań JS i CAPTCHA. Razem obsługują ataki warstwy 7, których sam scrubbing wolumetryczny nie powstrzyma.
Scrubbing wolumetryczny zatrzymuje się na granicy IP i portu. By powstrzymać HTTP flood, który wygląda jak ruch realnego Chrome, potrzebne są reguły działające na URL-ach, nagłówkach, cookies i zachowaniach. Rate limiting to najprostsza i najskuteczniejsza kontrola warstwy 7: ograniczyć pojedyncze IP do, powiedzmy, 60 żądań na minutę na /login, resztę odrzucić. WAF idzie dalej z regułami świadomymi treści: blokuje żądania z wzorcami SQL injection, anomalnymi user agentami, brakującymi referrerami, pochodzeniem geograficznym poza obszarem usług lub rozmiarami payloadu daleko poza uprawnionym zakresem. Nowoczesne WAF-y (AWS WAF, Cloudflare WAF, Fastly Next-Gen WAF, ModSecurity z OWASP Core Rule Set) uruchamiają też wyzwania JavaScript, hCaptcha i heurystyki odcisków botów, które obniżają skuteczność botnetów o 99%+ bez utrudniania życia realnym przeglądarkom.
Co dostawcy hostingu zwykle wliczają vs co dolicza się dodatkowo
Bezpłatne lub wliczone poziomy zwykle pokrywają wolumetryczne ataki warstwy 3-4 do stałego limitu w gigabitach na sekundę (często 10-100 Gbps) z podstawowym rate limiting i blackhole BGP. Płatne dodatki zwykle obejmują scrubbing zawsze włączony, WAF, mitygację warstwy 7, autorstwo niestandardowych reguł i gwarancje mitygacji oparte na SLA. Należy czytać umowę — „nielimitowana ochrona DDoS” często oznacza „przy ruchu powyżej X Gbps zostaniesz null-route'owany”.
Marketing DDoS u dostawców hostingu jest skrajnie zróżnicowany. Naprawdę użyteczna ochrona obejmuje trzy rzeczy: (1) jasno podaną pojemność w Gbps lub Tbps, (2) pokrycie warstw 3-7 łącznie z mitygacją HTTP flood oraz (3) pisemne SLA z czasem startu mitygacji i zobowiązaniami dotyczącymi utraty ruchu. Mniej użyteczna ochrona to pojedyncza odznaka „DDoS protected” bez liczby pojemności, co zwykle oznacza wyłącznie blackhole BGP — IP zostaje null-route'owane podczas ataku, a klient jest offline na czas trwania. Przy ocenie warto pytać: jaka jest podana pojemność na IP? Czy to zawsze włączona, czy na żądanie? Czy obejmuje warstwę 7? Jakie SLA na czas aktywacji mitygacji? Co dzieje się, gdy atak przekroczy limit poziomu? Odpowiedzi pokazują, czy kupuje się realną ochronę, czy tylko marketingową etykietę.