Nastolatkowie sprzedawali ataki DDoS: polski model booter-as-a-service

10 marca 2026 roku CBZC poinformowało o ustaleniu siedmiu nieletnich, którzy w czasie zarzucanych czynów mieli od 12 do 16 lat. Według funkcjonariuszy udostępniali w internecie programy przystosowane do ataków DDoS, współpracowali przy administrowaniu infrastrukturą i uzyskiwali z tego korzyści finansowe. Atakowane miały być portale sprzedażowe, serwisy hostingowe, domeny IT i usługi rezerwacji noclegów.

Podczas działań w czterech województwach zabezpieczono komputery, telefony, nośniki, dyski, urządzenie sprzętowe do obsługi aktywów cyfrowych oraz notatki. Ze względu na wiek materiały miały trafić do sądów rodzinnych. Sprawę nadzoruje Prokuratura Rejonowa Bydgoszcz-Północ. Są to ustalenia organów ścigania, a nie prawomocne rozstrzygnięcia.

Czym jest booter lub stresser

Booter upraszcza atak DDoS do usługi: klient wybiera cel, czas i klasę ruchu, płaci, a panel steruje rozproszonymi źródłami. Nazwa „stresser” bywa przykrywką sugerującą legalne testy, ale legalny test wymaga jednoznacznej zgody właściciela systemu, limitów i planu awaryjnego. Atakowanie obcego serwisu „na próbę” pozostaje bezprawne.

Technicznie usługa może korzystać z botnetu przejętych urządzeń, serwerów wynajętych na fałszywe dane albo amplifikacji UDP. W amplifikacji napastnik fałszuje adres IP ofiary i wysyła małe zapytania do publicznych usług, które odpowiadają większym pakietem. Źródła rozproszone geograficznie utrudniają proste blokowanie adresów.

Dlaczego krótki DDoS nadal jest groźny

Kilkunastominutowa niedostępność może być niezauważalna dla części użytkowników, ale dla sklepu, rezerwacji lub hostingu oznacza porzucone transakcje, uruchomienie SLA i pracę zespołu awaryjnego. DDoS bywa też zasłoną: gdy administratorzy obserwują przepustowość, napastnik testuje logowanie, zmienia DNS albo wykorzystuje podatność aplikacji.

Obrona wymaga rozdzielenia warstw. Ataki wolumetryczne powinien pochłaniać operator lub globalna sieć scrubbing/CDN. Ataki protokołowe wymagają ochrony stosu sieciowego, a warstwa aplikacyjna — limitów per użytkownik, cache, kolejek i reguł opartych na zachowaniu. Sam firewall w serwerowni nie pomoże, jeśli łącze jest już nasycone.

Runbook obrony usługi

Najpierw poznaj normalny ruch: zapytania na sekundę, przepustowość, rozkład krajów, błędy i koszt zapytania do backendu. Potem ustaw limity, które nie krzywdzą legalnych klientów, i przygotuj tryb degradacji: statyczną stronę, wyłączenie kosztownych wyszukiwań, kolejkę oraz priorytet dla logowania i płatności.

W czasie incydentu zachowaj próbki NetFlow/PCAP, zakres czasu, ASN-y, nagłówki i metryki aplikacji. Eskalacja do dostawcy ochrony musi mieć gotowy kontakt 24/7. Po ataku sprawdź nie tylko dostępność, ale też równoległe logowania i zmiany konfiguracji. Mechanikę nowoczesnego ruchu omawiamy w analizie HTTP/2 Rapid Reset.

Nie testuj odporności produkcji bez uzgodnienia z operatorem, hostingiem i właścicielem biznesowym. Bezpieczny test ma limit, obserwatorów po obu stronach i natychmiastowy kill switch. Możemy przygotować taki scenariusz bez ryzyka dla klientów.

Trzy różne problemy ukryte pod nazwą DDoS

Atak wolumetryczny próbuje zająć całe łącze. Atak protokołowy wyczerpuje tablice stanu, kolejki lub zasoby stosu TLS. Atak warstwy aplikacyjnej wysyła pozornie poprawne zapytania do kosztownej funkcji, np. wyszukiwania albo generowania raportu. Każdy wymaga innych metryk. Sam wykres Mbps nie pokaże przeciążenia puli połączeń do bazy.

Runbook powinien przypisać właścicieli: operator odpowiada za upstream i RTBH/scrubbing, platforma za autoscaling i cache, a zespół aplikacji za koszt endpointów. Gdy wszystko trafia do jednego „zespołu sieci”, czas decyzji rośnie.

Projektowanie limitów, których nie omija rozproszenie

Limit per IP jest potrzebny, lecz niedostateczny. Legalni użytkownicy mogą dzielić NAT, a botnet rozłoży ruch na tysiące adresów. Stosuj kombinację tożsamości, sesji, tokenu, ASN-u, reputacji i kosztu operacji. Oddziel limit rozpoczęcia kosztownego zadania od limitu pobrania taniego zasobu.

Warto wprowadzić budżety zasobów: maksymalny czas CPU, liczbę równoległych zapytań i rozmiar odpowiedzi. Circuit breaker powinien odciąć zależność, zanim awaria rozleje się kaskadowo. Cache ma pomagać przy powtarzalnych odczytach, ale nie może mieszać danych użytkowników.

Metryki po incydencie

Zmierz czas do detekcji, czas do włączenia mitygacji, udział legalnego ruchu odrzuconego i koszt chmurowy. Sprawdź, czy autoscaling nie zwiększył rachunku bez zwiększenia przepustowości backendu. Przejrzyj także logowania, DNS i wdrożenia z tego samego okna — DDoS mógł być zasłoną.

Czy CDN wystarczy? Nie zawsze. Chroni zasoby cache’owalne i pochłania część ruchu, ale origin, API oraz bezpośrednio ujawniony adres nadal mogą być celem. Origin powinien przyjmować ruch tylko z sieci CDN.

---

Źródła pierwotne: CBZC — siedmiu nastolatków sprzedawało narzędzia do ataków DDoS, CISA — DDoS Guidance for Federal Agencies.