Ataki DDoS na operatorów internetowych są dziś tanie w zamówieniu, wielowektorowe i potrafią znacznie przekraczać przepustowość łączy. LiveShield, polski system anty-DDoS dla operatorów telekomunikacyjnych, opisuje pięć zmian widocznych w atakach na sieci operatorskie. Pokazujemy je na realnym incydencie z sieci jednego z warszawskich operatorów internetowych, z września 2026 r. Podstawą obrony są w nim reguły BGP FlowSpec, a blackholing (RTBH) pozostaje ostatecznością.
Zamówienie ataku nie wymaga ani umiejętności, ani własnej infrastruktury. Według ENISA, DDoS był dominującym typem incydentu w UE i stanowił 77 proc. zgłoszonych zdarzeń w okresie od lipca 2024 r. do czerwca 2025 r., w większości jako kampanie hacktywistów o niewielkim wpływie na usługi. W kwietniu 2026 r. Europol w operacji PowerOFF zlikwidował 53 domeny usług DDoS-for-hire i wysłał ostrzeżenie do ponad 75 tys. ich użytkowników.
Dla operatora wniosek jest praktyczny: celem może być dowolny adres, także adres współdzielony przez wielu abonentów a tło mało groźnych ataków utrudnia zauważenie tego jednego, który jest groźny. LiveShield wykrywa atak na poziomie pojedynczego adresu IP oraz podsieci i uruchamia reakcję w czasie nawet poniżej sekundy.
Bo połączenie kilku technik utrudnia obronę opartą na jednej sygnaturze, a każda z nich uderza w inny zasób: flood o dużej objętości w łącza, małe pakiety w urządzenia sieciowe, odbicia ‒ w jedno i drugie. W incydencie z sieci warszawskiego operatora, który dzisiaj omawiamy w niespełna 5 minut pojawiło się pięć typów ruchu:
- flood UDP,
- małe pakiety UDP,
- fragmenty DNS reflection,
- TCP SYN,
- odbicie STUN.
I jeszcze do tego ICMP jako efekt uboczny. Każda z tych technik jest znana od lat. Wyzwaniem jest obrona przed nimi w jednym zdarzeniu.
Podstawą ochrony w LiveShield są reguły BGP FlowSpec, które odrzucają tylko ruch ataku. Przy włączonym zaawansowanym filtrowaniu, system sam szuka wspólnej cechy ruchu (port docelowy, długość pakietu, flagi TCP, fragmentacja itp.) i zakłada osobną regułę dla każdego wektora, zamiast odcinać cały adres. Szczegóły opisuje dokumentacja detekcji i filtrowania.
Panel LiveShield, widok ogólny (zrzut poglądowy).
W atakach reflection pakiety nie pochodzą od atakującego, tylko od zwykłych serwerów, które odpowiadają na zapytania z podmienionym adresem źródłowym. Jest to możliwe tak długo, jak długo operatorzy nie wdrożą BCP 38, czyli filtrowania pakietów z fałszywym adresem źródłowym na wyjściu z sieci. W próbkach ruchu z opisywanego incydentu widać to wyraźnie: odpowiedzi STUN, odpowiedzi DNS na zapytania ANY oraz komunikaty ICMP zawierające oryginalne zespoofowane zapytanie atakującego.
Lista złych adresów nie pomoże, bo źródłem są zwykłe serwery, ale sam ruch z odbić zwykle łatwo odróżnić od prawidłowego: ma charakterystyczne porty, długości pakietów lub fragmentację. Dlatego skuteczne jest dopasowanie reguły FlowSpec do cech ruchu. W opisanym incydencie jedna reguła na port docelowy 80/udp objęła zarówno flood z botnetu, jak i odbicie STUN.
