Co to jest atak DDoS?
Rozproszony atak typu Denial-of-Service to dokładnie to, co mówi nazwa: skoordynowany wysiłek wielu punktów końcowych, aby przytłoczyć pojedynczy cel ruchem, wyczerpując jakiś zasób (przepustowość sieci, stan połączeń jądra, wątki aplikacji, połączenia z bazą danych) i czyniąc usługę niedostępną. Współczesne ataki DDoS dzielą się na trzy klasy, które różnią się sposobem wykorzystania celu.
Ataki wolumetryczne wyczerpują surową przepustowość sieci. Klasycznym wariantem jest refleksyjna amplifikacja — atakujący wysyła sfałszowane pakiety UDP do publicznych serwerów (DNS, NTP, Memcached, CLDAP), które odpowiadają znacznie większymi odpowiedziami, mnożąc przepustowość atakującego od 50x do 50 000x w zależności od protokołu. Ataki wolumetryczne mierzy się w bitach na sekundę, a największe publicznie ujawnione zdarzenia przekroczyły 3 Tbps. Łagodzenie odbywa się na brzegu sieci, zanim ruch dotrze do Twojego serwera.
Ataki protokołowe wyczerpują stan połączeń na poziomie jądra. SYN flood (półotwarte połączenia TCP), ACK flood i różne ataki z uszkodzonymi pakietami należą do tej kategorii. Mierzy się je w pakietach na sekundę. Łagodzenie odbywa się zarówno na brzegu (za pomocą filtrów bezstanowych), jak i na serwerze (za pomocą strojenia jądra, ciasteczek SYN, automatycznego blokowania w stylu fail2ban).
Ataki warstwy aplikacji (L7) wyczerpują zasoby na poziomie aplikacji. HTTP flood skierowane na kosztowne punkty końcowe, ataki slow-loris, które utrzymują połączenia otwarte, zapytania GraphQL, które eksplodują w wzorce N+1. Mierzone w żądaniach na sekundę; łagodzenie wymaga zrozumienia powierzchni aplikacji i rzadko jest możliwe wyłącznie na brzegu sieci — zwykle wymaga ograniczania szybkości na poziomie aplikacji, budżetów zapytań, buforowania CDN lub WAF.
Każda klasa wymaga innego łagodzenia; nowoczesne stosy ochrony łączą wszystkie trzy warstwy. Liczby Gbps w materiałach marketingowych offshore hostingu odnoszą się do pojemności wolumetrycznej, ale ataki wolumetryczne to tylko jedno z trzech zagrożeń — pozostałe dwa wymagają pracy inżynieryjnej po Twojej stronie.
Jak działa nowoczesny scrubbing DDoS
Infrastruktura, która pochłania ataki wolumetryczne, nazywana jest "centrum scrubbingu", a architektura jest spójna u wszystkich głównych dostawców (Cloudflare, Akamai, Imperva, NTT) i u większości hostów offshore prowadzących własną sieć.
Ruch przeznaczony dla Twojego IP jest ogłaszany przez anycast z wielu punktów geograficznych. Anycast umożliwia dostęp do tego samego IP z wielu lokalizacji; protokoły routingu automatycznie dostarczają każdy pakiet do najbliższej krawędzi. Gdy trwa atak, ruch atakujący jest rozproszony na wiele punktów brzegowych (ponieważ atakujący są również rozproszeni geograficznie), a każdy punkt brzegowy widzi tylko ułamek całkowitego wolumenu.
W każdym punkcie brzegowym filtry scrubbingowe klasyfikują ruch w czasie rzeczywistym. Legalny ruch jest przekazywany do origin; ruch atakujący jest odrzucany na brzegu. Klasyfikacja wykorzystuje mieszankę reguł bezstanowych (odrzucanie sfałszowanych adresów IP źródłowych, odrzucanie nietypowych struktur pakietów), heurystyk stanowych (śledzenie stanu połączeń i odrzucanie niekompletnych uzgadniań) oraz analizy behawioralnej (odrzucanie źródeł pasujących do znanych wzorców botnetów).
Cała architektura jest prewencyjna — brak czasu reakcji człowieka w pętli, brak potrzeby "uruchamiania" łagodzenia. Gdy Twoje IP jest objęte chronioną anonsacją anycast, ochrona jest zawsze włączona. Plany MurmurHost obejmują to domyślnie; strona funkcji ochrony DDoS dokumentuje pojemność dla każdego poziomu.
Jaka pojemność jest wystarczająca?
To pytanie zadaje większość klientów, a odpowiedź jest bardziej zniuansowana, niż sugerują materiały marketingowe.
Dla większości projektów osobistych (blog, małe forum, hobbyistyczna instancja Mastodon), 10 Gbps scrubbingu wystarcza. Ataki wymierzone w projekty osobiste są zazwyczaj oportunistyczne — poziom script-kiddie, poniżej 10 Gbps, trwające od minut do godzin. Nasze plany podstawowe VPS-1 i VPS-2 obejmują 10 Gbps scrubbingu i to pokryło wszystkie ataki, jakie widzieliśmy przeciwko klientom z projektami osobistymi w ciągu ostatniego roku.
Dla skromnych operacji komercyjnych (niszowy sklep e-commerce, małe SaaS, ruchliwe forum), 50–100 Gbps to właściwy poziom. Ataki na tym poziomie są zazwyczaj motywowane — nękanie konkurencji, próby wymuszenia, ataki ideologiczne przeciwko konkretnym komentarzom — i czasami utrzymują się godzinami lub dniami. Plany średnie VPS-4 i VPS-8 obejmują 100 Gbps scrubbingu.
Dla obciążeń o wysokiej przepustowości lub wysokim ryzyku (streaming, dorosłe, serwery gier, węzły wyjściowe VPN), 200–400 Gbps jest odpowiednie. Ataki na te obciążenia są zwykle zarówno większe (komercyjne rynki DDoS-for-hire wyraźnie celują w streaming i dorosłych), jak i dłuższe (utrzymujące się przez dni, czasem tygodnie). Nasz poziom dedykowany — DS-Mid, DS-Pro — obejmuje 400 Gbps scrubbingu.
Dla obciążeń korporacyjnych z ciągłą uwagą wrogą (obserwowane ataki 1+ Tbps), standardową praktyką jest umieszczenie Cloudflare lub BunnyCDN przed origin offshore i poleganie na znacznie większej pojemności absorpcji CDN (multi-Tbps globalnie) dla ochrony L3/L4. Darmowy poziom Cloudflare obejmuje użyteczną ochronę; płatne poziomy dodają możliwości WAF i zarządzania botami. Wspieramy ten wzorzec jawnie — zobacz naszą stronę funkcji ochrony DDoS.
Poniższa tabela podsumowuje poziomy ochrony MurmurHost:
| Poziom planu | Scrubbing wolumetryczny | Zastosowanie |
|---|---|---|
| Współdzielony, VPS-1, VPS-2 | 10 Gbps | Osobiste, hobby |
| VPS-4, VPS-8, RDP-Pro | 100 Gbps | Komercyjne, średni ruch |
| VPS-16, DS-Lite | 200 Gbps | Wysoki ruch |
| DS-Mid, DS-Pro, DS-Beast, plany GPU | 400 Gbps | Streaming, dorosłe, ciągłe |
| Niestandardowe korporacyjne | 1+ Tbps | Poziom suwerenny, cross-CDN |
Taktyki na brzegu — reguły warstwy aplikacji, ograniczanie szybkości
Poziom scrubbingu wolumetrycznego obsługuje ataki L3/L4. Ataki warstwy aplikacji wymagają pracy inżynieryjnej na brzegu aplikacji. Trzy wzorce mają największe znaczenie:
Ograniczanie szybkości. Ogranicz żądania na IP, na sesję lub na punkt końcowy. Najprostsza implementacja to Nginx (limit_req_zone), HAProxy lub middleware aplikacji. Bardziej zaawansowane podejścia — token-bucket na tożsamość, przesuwne okno na punkt końcowy — wymagają więcej konfiguracji, ale pochłaniają ataki skokowe bardziej elegancko. Właściwy stosunek zależy od normalnych wzorców ruchu: jeśli Twój najbardziej aktywny legalny użytkownik wykonuje 50 żądań na minutę, ustaw limit na 200/minutę, nie na 30.
Reguły WAF. Web Application Firewall sprawdza ładunki żądań i blokuje wzorce pasujące do znanych sygnatur ataków (SQL injection, XSS, typowe odciski botów). WAF Cloudflare, modsecurity (z OWASP Core Rule Set) i WAF BunnyCDN działają dla hostów offshore. WAF znajduje się na brzegu CDN, jeśli go masz, lub przed serwerem aplikacji, jeśli nie.
Cloudflare lub BunnyCDN z przodu. Poza WAF, CDN pochłania atak na warstwie, która skaluje się znacznie dalej niż jakikolwiek pojedynczy origin. Cloudflare w szczególności jest standardową praktyką w hostingu offshore od dekady — działa dobrze przed origin w Holandii lub Islandii, a darmowy poziom zapewnia znaczącą ochronę samodzielnie. Dokumentujemy kanoniczną konfigurację Cloudflare-plus-offshore-origin na naszej stronie funkcji.
Tarpitting i mechanizmy wyzwań
W przypadku ciągłych ataków L7 o niskim wolumenie (zaawansowane boty, skrapery, skryptowe przejęcia kont), jawne mechanizmy wyzwań stają się przydatne.
Wyzwanie JS. Tryb "I'm Under Attack" Cloudflare i podobne funkcje wstrzykują małe wyzwanie JavaScript, które legalne przeglądarki przechodzą automatycznie; boty, które nie uruchamiają JS, są filtrowane. Tanie, skuteczne, przejrzyste dla legalnych użytkowników.
Bramki CAPTCHA. Gdy wyzwanie JS jest niewystarczające, rzeczywista CAPTCHA na podejrzanych punktach końcowych oddziela ludzi od zaawansowanych botów. Koszt tarcia jest realny — współczynnik porzuceń wzrasta — więc używaj oszczędnie i tylko na punktach końcowych pod ciągłym atakiem.
Wyzwania proof-of-work. mCaptcha, Anubis i podobne narzędzia wymagają od klienta obliczenia małego proof-of-work przed przetworzeniem żądania. Koszt ekonomiczny dla atakującego skaluje się liniowo z szybkością ataku; koszt dla legalnego użytkownika jest niewidoczny (kilkaset milisekund w najgorszym przypadku). Ten wzorzec zyskał popularność w latach 2025–2026 szczególnie przeciwko kampaniom AI scraping i credential-stuffing.
Tarpitting. Spowalnianie odpowiedzi na podejrzany ruch bez jawnego odrzucania. Skuteczne przeciwko prostym botom, które utrzymują połączenia otwarte, dopóki nie otrzymają odpowiedzi; mniej skuteczne przeciwko nowoczesnym narzędziom atakującym, które przekraczają limit czasu i przechodzą dalej.
Ekonomia DDoS: kto płaci za co
Ekonomia ochrony DDoS jest zwykle nieprzejrzysta dla klientów. Z grubsza:
- Pojemność scrubbingu wolumetrycznego jest najdroższą warstwą dla hosta. Poziom 10 Gbps scrubbingu na dużą skalę kosztuje dostawcę około $0,01–0,10 za chroniony GB ruchu atakującego, co sumuje się do znaczących kosztów ogólnych dla obciążeń o wysokim ryzyku. Większość dostawców wlicza podstawowy poziom do ceny planu i pobiera opłaty za "premium" pojemność powyżej.
- Peering anycast jest umiarkowanie drogi — potrzebujesz nieruchomości w wielu punktach wymiany internetowej. To głównie koszt stały.
- Reguły WAF i ochrona L7 są tanie w porównaniu do scrubbingu — większość kosztów to utrzymanie zestawu reguł, nie CPU.
MurmurHost wlicza pełny podstawowy poziom do każdego planu. Premium scrubbing (powyżej pojemności poziomu planu, dla ciągłych ataków 1+ Tbps) to rozmowa o modernizacji na poziomie korporacyjnym, nie opłata za atak. Nie rozliczamy według wolumenu ataku; ciągłe ataki powyżej pojemności planu wyzwalają rozmowę z klientem o modernizacji poziomu planu, nie niespodziewany rachunek.
Co możesz zrobić na poziomie aplikacji
Najskuteczniejsza ochrona przed DDoS to nie być celem, a druga najskuteczniejsza to utrzymanie aplikacji taniej w serwowaniu. Konkretne dźwignie:
Buforuj agresywnie. Treści statyczne serwowane z CDN (lub nawet z lokalnego Nginx z dyrektywą cache) nie kosztują origin nic. Treści dynamiczne buforowane w krótkich oknach (5–60 sekund dla większości stron) pochłaniają skoki ruchu bez pełnego przetwarzania przez origin.
Spraw, aby dynamiczne punkty końcowe były tanie. Żądanie, które trafia do bazy danych przy każdym ładowaniu strony, jest znacznie bardziej podatne niż to, które trafia do Redis. Przenieś kosztowne obliczenia do pracowników w tle, zwracaj dane z pamięci podręcznej lub ostatecznie spójne na ścieżce żądania.
Ustaw budżety zapytań. API GraphQL są szczególnie podatne na ataki amplifikacyjne — pojedyncze żądanie atakującego może wywołać tysiące zapytań do bazy danych. Ustaw limity głębokości zapytań, limity złożoności zapytań i budżety zapytań na IP.
Oddziel ścieżki odczytu i zapisu. Ruch intensywnie czytający nie powinien konkurować z ruchem intensywnie piszącym o tę samą pulę połączeń z bazą danych. Repliki do odczytu obsługują ataki odczytowe z gracją; ataki zapisu są mniejsze objętościowo i łatwiejsze do ograniczenia szybkości.
Monitoruj i alarmuj. 10-minutowy atak, którego nie zauważasz, to w większości nie wydarzenie. 10-minutowy atak, który zauważasz, daje czas na włączenie ochron (przełącz tryb I'm-Under-Attack Cloudflare, wdróż awaryjne reguły WAF, skontaktuj się z pomocą). Nawet podstawowe monitorowanie (obciążenie serwera, szybkość żądań, wskaźnik błędów 5xx) wystarcza do pierwszej reakcji.
Plany z wbudowaną ochroną DDoS
Wybrane plany MurmurHost, posortowane według typowego przypadku użycia:
- Projekty osobiste, hobby: VPS-1 ($8/mies., 10 Gbps), Shared Pro ($7.99/mies., 10 Gbps).
- Komercyjne małe firmy: VPS-2 ($16/mies., 10 Gbps), VPS-4 ($32/mies., 100 Gbps).
- Streaming, dorosłe, seedboxy: VPS-8 ($64/mies., 100 Gbps), Stream-1 (poziom wysokiej przepustowości).
- Serwery gier: Game-M (filtry UDP klasy gamingowej), Game-L.
- Ciągłe dedykowane o wysokim ryzyku: DS-Mid ($149/mies., 400 Gbps), DS-Pro, DS-Beast.
- Inferencja GPU i ML: GPU-Pro, GPU-Beast — chronione scrubbingiem 400 Gbps tak samo jak dedykowane.
Pełne menu znajduje się na /pricing, a szczegółowy podział funkcji na /features/ddos-protection.
Podsumowanie
Ochrona przed DDoS to rozwiązany problem na warstwie wolumetrycznej — każdy wiarygodny host offshore w 2026 roku domyślnie obejmuje znaczną pojemność scrubbingu. Pozostała praca odbywa się na warstwie aplikacji, gdzie tanie buforowanie, ograniczanie szybkości, budżety zapytań i podstawowe monitorowanie zamykają większość pozostałej powierzchni. Właściwy poziom planu jest określany bardziej przez przypadek użycia niż przez przewidywania wielkości ataku: projekty osobiste potrzebują 10 Gbps, komercyjne o średnim ruchu 100 Gbps, a obciążenia o wysokim ryzyku 400 Gbps z Cloudflare z przodu. Wybierz poziom pasujący do Twojego obciążenia ze strony cenowej i połącz go z rozsądną inżynierią na poziomie aplikacji. Dla modeli zagrożeń, które tego wymagają, strona funkcji ochrony DDoS szczegółowo omawia pojemność dla każdego poziomu.