10 lipca 2026
·
14 min czytania
Port-mirror z DPDK widzi 100% pakietów i alarmuje w 2-5 s. NetFlow, sFlow i IPFIX są próbkowane i reagują po 35-95 s. Która metoda wykrywania DDoS na którym łączu.
Krótka odpowiedź: metody wykrywania ataków DDoS dzielą się na dwie rodziny. Analiza pakietowa z portu mirrorowanego (SPAN albo pasywny TAP) z użyciem DPDK widzi 100% ruchu z prędkością łącza i alarmuje w 2–5 sekund. Analiza flowów (NetFlow, sFlow, IPFIX) korzysta z próbkowanych rekordów, które router i tak eksportuje — jest znacznie tańsza i obejmuje całą sieć, ale reaguje po 35–95 sekundach. Ta różnica czasu decyduje o tym, czy klient w ogóle zauważy atak.
Czym właściwie jest wykrywanie ataku DDoS?
Wykrywanie to proces rozpoznania, że trwa rozproszony atak odmowy usługi: system profiluje ruch na bieżąco i podnosi alarm w chwili, gdy natężenie, rozkład protokołów albo rozmiar pakietów w danej podsieci odrywa się od wyuczonej linii bazowej. Odpowiada na jedno pytanie i musi to zrobić szybko: to jest normalny ruch czy atak?
Wykrywanie to nie to samo co reakcja na atak, ale jedno bez drugiego nie istnieje. Żaden filtr, żadna reguła BGP FlowSpec i żadne odcięcie adresu przez RTBH nie odrzuci ani jednego pakietu, dopóki detektor nie powie, że jest co odrzucać. Cały łańcuch obrony jest tak szybki, jak jego pierwszy element.
To, czym karmisz detektor — kopią pakietów czy eksportowanymi flowami — ustala jednocześnie dwie rzeczy: czas reakcji i koszt pokrycia sieci. I to jest jedyny naprawdę trudny wybór w projekcie systemu wykrywania.
Dlaczego czas wykrycia decyduje o tym, czy klienci zauważą atak?
Bo współczesne ataki wolumetryczne wysycają uplink w kilkadziesiąt sekund, nie w minuty. Cloudflare w raporcie za IV kwartał 2025 podał, że liczba ataków DDoS wzrosła rok do roku o 121%, a rekordowy zablokowany atak o wolumenie 31,4 Tbps trwał zaledwie 35 sekund. Najczęściej atakowaną branżą w kategorii ataków hiperwolumetrycznych byli operatorzy telekomunikacyjni i dostawcy usług — czyli dokładnie ten profil sieci, o którym tu mówimy.
Warto przeczytać tę liczbę jeszcze raz: 35 sekund od początku do końca. Metoda wykrywania, która reaguje w 35–95 sekundach, może taki atak przegapić w całości albo zobaczyć go dopiero wtedy, gdy łącze jest już zapchane, a klienci od dawna dostają timeouty. Alarm przychodzi wtedy nie jako ostrzeżenie, tylko jako potwierdzenie awarii.
Równoległe dane NETSCOUT za drugą połowę 2025 roku mówią o ponad 8 milionach ataków DDoS w 203 krajach, przy czym około 42% wykorzystywało od dwóch do pięciu wektorów jednocześnie. Atak wielowektorowy o krótkim czasie trwania to modelowy przypadek, w którym wolne, próbkowane wykrywanie po prostu nie nadąża: zanim statystyka złoży się w anomalię, wektor już się zmienił.
Reguła praktyczna, według której pracujemy, brzmi: czas do wykrycia musi być krótszy niż czas do wysycenia łącza. Na obciążonym brzegu 100GE ten budżet liczy się w sekundach. Jeśli chcesz zobaczyć, jak to wygląda z perspektywy dyżurnego w NOC, opisaliśmy to w tekście o ataku DDoS na ISP — sieć położyło tam kilkadziesiąt sekund ruchu.
Jak działa wykrywanie z port-mirrora (DPDK)?
Wykrywanie pakietowe analizuje pełną kopię ruchu. Sesja SPAN albo mirror na przełączniku lub routerze — albo pasywny optyczny TAP, jeśli nie chcesz obciążać urządzenia produkcyjnego — duplikuje każdy pakiet na port monitorujący. Tam Packet Sensor systemu WanGuard przechwytuje ruch w przestrzeni użytkownika przy pomocy DPDK (Data Plane Development Kit), z prędkością łącza.
Kluczowe jest to, że nic tu nie jest szacowane. Sensor widzi każdy nagłówek, każdą flagę TCP, każdy protokół i każdy fragment bezpośrednio. Nie ma rekonstrukcji statystycznej, nie ma współczynnika próbkowania, którym trzeba przemnożyć wynik.
DPDK jest tym, co czyni takie podejście realnym na szybkich łączach. Omija stos sieciowy jądra Linuksa, korzysta ze sterowników w trybie odpytywania (poll mode) i z hugepages, dzięki czemu narzut na pojedynczy pakiet spada do minimum. Efekt: zwykły serwer x86 potrafi analizować dziesiątki, a przy odpowiedniej konfiguracji setki Gbps.
Zysk jest jeden i bardzo konkretny — czas reakcji. We wdrożeniach ITORO wykrywanie z port-mirrora sygnalizuje atak wolumetryczny zwykle w 2–5 sekund. To wystarczy, żeby uruchomić RTBH w czasie poniżej 5 sekund albo precyzyjne filtrowanie regułami BGP FlowSpec w 15–30 sekund.
Kosztem jest zasięg. Potrzebujesz pojemności mirrorowej i sensora w każdym punkcie pomiaru, więc pokrycie kilkunastu rozproszonych geograficznie POP-ów pełną analizą pakietową robi się drogie — i zwykle nie ma sensu. Port-mirror to narzędzie, które stawiasz tam, gdzie sekundy naprawdę kosztują: na najbardziej obciążonych brzegach i przy klientach o najwyższej wartości.
Czego port-mirror wymaga od urządzenia
Zanim zaplanujesz wdrożenie, sprawdź trzy rzeczy. Po pierwsze — czy urządzenie w ogóle uciągnie sesję mirror bez wpływu na forwarding (na sprzęcie z ograniczonym budżetem PFE mirror potrafi być kosztowny). Po drugie — czy port monitorujący ma przepustowość pokrywającą szczyt ruchu w obu kierunkach; mirror 2 × 10GE na jeden port 10GE po prostu się nie zmieści i zaczniesz gubić pakiety dokładnie wtedy, gdy są najważniejsze. Po trzecie — czy nie taniej wyjdzie pasywny TAP albo packet broker, który rozdzieli ten sam strumień na kilka narzędzi.
Jak działa wykrywanie oparte na NetFlow, sFlow i IPFIX?
Wykrywanie flowowe analizuje rekordy podsumowujące, które Twoje routery i tak już eksportują. Nie potrzebujesz ani mirrora, ani TAP-a. Flow Sensor zbiera te rekordy, odtwarza z nich statystyczny obraz ruchu per podsieć i zgłasza anomalię, gdy obraz odkleja się od linii bazowej.
Dominują trzy formaty eksportu i — wbrew potocznemu skrótowi „NetFlow" na wszystko — nie działają tak samo.
NetFlow i IPFIX — eksport z cache'u flowów
NetFlow (rodowód Cisco, wersje v5 i v9) oraz jego standard IETF, czyli IPFIX (RFC 7011), utrzymują na routerze cache flowów. Urządzenie grupuje pakiety w strumienie i eksportuje rekord dopiero wtedy, gdy flow się zakończy albo gdy wygaśnie timer. To właśnie active flow timeout decyduje, jak szybko zostanie zaraportowany długo trwający atak — a jego domyślna wartość na wielu platformach wynosi około 60 sekund. Na większości urządzeń da się ją obniżyć i warto to zrobić, ale schodząc niżej płacisz zwiększoną liczbą eksportowanych rekordów i obciążeniem kolektora.
Ten pojedynczy timer jest głównym powodem, dla którego wykrywanie flowowe ląduje w przedziale kilkudziesięciu sekund.
sFlow — próbkowanie pakietów
sFlow idzie inną drogą. Próbkuje 1 pakiet na N i wysyła te próbki w sposób ciągły, jako datagramy — nie ma tu żadnego cache'u, który musiałby wygasnąć. Skoro nie czeka na zamknięcie flowu, potrafi zareagować szybciej niż klasyczny NetFlow. Nadal jednak jest próbkowany, więc wymienia kompletność obrazu na dostarczanie w czasie zbliżonym do rzeczywistego.
Wspólna ekonomia wszystkich trzech
Eksport flowów jest niezależny od pasma — wysyłasz rekordy, a nie kopię ruchu. Obejmuje każdy router, który już mówi tym protokołem, i skaluje się do wolumenów terabitowych przy niewielkim koszcie. Płacisz za to czasem i szczegółowością: rekordy są próbkowane (na szybkich łączach zwykle 1:1000 albo 1:2000) i często agregowane w oknie eksportu, więc wykrywanie flowowe w produkcji mieści się typowo w 35–95 sekundach i widzi znacznie zgrubniejszy obraz niż analiza pakietowa.
Port-mirror kontra NetFlow, sFlow i IPFIX — porównanie
Uczciwe zestawienie wygląda tak. Żadna z tych metod nie jest „lepsza" w oderwaniu od kontekstu — każda wygrywa inne zadanie i dlatego na dojrzałym brzegu sieci zwykle pracują obie naraz.
| Kryterium | Port-mirror (DPDK Packet Sensor) | NetFlow / IPFIX | sFlow |
|---|---|---|---|
| Co widzi | 100% pakietów | próbkowane rekordy z cache'u flowów | próbkowane nagłówki pakietów |
| Próbkowanie | brak (pełna analiza) | tak + agregacja w cache'u | tak (1 na N) |
| Typowy czas wykrycia | ~2–5 s | ~35–95 s (limit: active timeout) | szybciej niż NetFlow, nadal próbkowane |
| Model pokrycia | per punkt pomiaru (TAP/SPAN) | każdy router, który eksportuje | każdy router, który eksportuje |
| Koszt pasma | wymaga pojemności mirrora/TAP | niezależny od pasma | niezależny od pasma |
| Koszt względny | wyższy na lokalizację | niski | niski |
| Martwe pola | praktycznie brak | ataki niskowolumenowe, fragmenty, luki próbkowania | luki próbkowania |
| Najlepszy do | obciążone brzegi, łącza krytyczne | szerokie pokrycie wielu POP | szerokie pokrycie w czasie zbliżonym do rzeczywistego |
Widoczność na poziomie pojedynczych pakietów dobrze łączy się z telemetrią strumieniową z Juniper MX: NOC ogląda ten sam atak i to samo filtrowanie na jednym dashboardzie, niezależnie od tego, który sensor podniósł alarm.
Gdzie próbkowanie tworzy martwe pola?
Próbkowanie tworzy martwe pola, bo Flow Sensor odtwarza ruch statystycznie z ułamka pakietów. Wszystko, co mieści się w przerwach między próbkami, łatwo policzyć za nisko albo zaklasyfikować błędnie.
Przy 1:1000 wzorzec o niskim natężeniu, ale realnie szkodliwy — powolny flood aplikacyjny, celowane wyczerpywanie tablicy stanów — może po prostu nie nazbierać dość próbek, żeby na czas przekroczyć próg. Atak działa, klient dzwoni, a wykres jest płaski.
Floody fragmentów to klasyczny przykład. Fragmenty IP inne niż pierwszy nie niosą nagłówka warstwy 4, więc nie ma w nich informacji o portach TCP/UDP (RFC 791). Rekordy flow potrafią je przez to zaklasyfikować do złego kubełka albo zignorować, a próbkowanie dodatkowo psuje ten obraz. Packet Sensor na DPDK widzi każdy fragment wprost — może go policzyć precyzyjnie albo złożyć z powrotem.
Ta sama logika dotyczy krótkich uderzeń: atak trwający 35 sekund nie daje żadnych szans 60-sekundowemu active timeout. Rekord zostanie wyeksportowany po fakcie, kiedy nie ma już czego bronić.
Nie znaczy to, że wykrywanie flowowe jest bezużyteczne — wręcz przeciwnie, na większości sieci to ono daje zasięg. Znaczy tylko tyle, że stawiasz je tam, gdzie jego martwe pola nie mają znaczenia, i podpierasz analizą pakietową tam, gdzie mają.
Kiedy stosować którą metodę?
Dobierz metodę do wartości i budżetu czasowego konkretnego łącza — a w większości realnych sieci oznacza to używanie obu. Nie ma tu jednego zwycięzcy: to inżynierski kompromis między czasem reakcji a kosztem objęcia całej sieci pełną analizą pakietową.
- Port-mirror (DPDK) — na najbardziej obciążonych brzegach, na uplinkach peeringowych i tranzytowych oraz w segmentach klientów o najwyższej wartości. Wszędzie tam, gdzie kilka sekund decyduje, czy łącze zdąży się wysycić, zanim zareagujesz.
- Flow (NetFlow/sFlow/IPFIX) — dla szerokiego, ekonomicznego pokrycia wielu POP-ów i routerów wewnętrznych, gdzie wstawianie TAP-a wszędzie jest niepraktyczne, a nieco wolniejszy alarm jest akceptowalny.
- Obie naraz — norma na dojrzałych sieciach: analiza pakietowa dla szybkości tam, gdzie to się liczy, flow dla zasięgu w pozostałych miejscach, i jedna konsola, która koreluje jedno z drugim.
Dokładnie tak wyceniamy i projektujemy usługi ochrony przed DDoS: mapujemy każde łącze na metodę wykrywania według jego ryzyka, zamiast rozwijać jeden schemat wszędzie. Zakres wdrożenia i wynikający z niego koszt znajdziesz w aktualnym cenniku wraz z kalkulatorem.
Jak WanGuard obsługuje obie metody wykrywania
WanGuard jest zbudowany dokładnie wokół tego dualnego modelu i to jest powód, dla którego na nim standaryzujemy. Packet Sensor przechwytuje ruch z mirrora przez DPDK, dając wykrycie poniżej 5 sekund przy pełnej widoczności. Flow Sensor przyjmuje NetFlow (v5/v9), sFlow (v5) oraz IPFIX, zapewniając pokrycie niezależne od pasma w skali terabitowej.
Oba zasilają ten sam silnik detekcji i tę samą konsolę, więc alarm z dowolnego z nich uruchamia tę samą automatyczną reakcję. Krótszy opis architektury zebraliśmy na stronie o WanGuard, a wprowadzenie dla osób, które dopiero zaczynają — w tekście czym jest WanGuard.
W praktyce oznacza to, że nie musisz wybierać obozu i żyć z jego martwymi polami. Stawiasz port-mirror z DPDK na łączach, gdzie reakcja w 2–5 sekund jest nienegocjowalna, rozprowadzasz sensory flow po szerszym brzegu dla zasięgu, a jeden system koreluje jedno z drugim, wykrywa atak i przekazuje go do filtrowania (najpierw BGP FlowSpec, RTBH dopiero jako ostateczność).
Trzeba przy tym powiedzieć jasno: dokładność wykrywania nadal zależy od strojenia. Linie bazowe liczone per podsieć, wyjątki dla znanych klientów o dużym ruchu, sensownie ustawione progi. Zrób to dobrze, a obie metody dają trafne, automatyczne alarmy. Zrób to źle, a każda z nich będzie generowała fałszywe alarmy — port-mirror po prostu szybciej.
ITORO jest światowym partnerem Gold firmy Andrisoft, z ponad 25-letnim doświadczeniem w operacjach ISP (w tym ponad 20 lat z Juniperem). Instalujemy, stroimy i utrzymujemy oba tryby wykrywania jako usługę zarządzaną, od początku do końca, w tej samej cenie na całym świecie.
Najczęstsze pytania
Która metoda wykrywania ataków DDoS jest najszybsza?
Najszybsze jest wykrywanie z portu mirrorowanego z użyciem DPDK — reaguje typowo w 2–5 sekund. Analizuje 100% pakietów z prędkością łącza przez sesję SPAN/mirror albo optyczny TAP, więc nic nie jest próbkowane ani szacowane. Wykrywanie flowowe (NetFlow/sFlow/IPFIX) jest tańsze i obejmuje więcej routerów, ale zwykle reaguje po 35–95 sekundach.
Czym różni się port-mirror od wykrywania po NetFlow?
Port-mirror analizuje pełną kopię każdego pakietu przez DPDK, więc widzi cały ruch z prędkością łącza i wykrywa atak w sekundach. NetFlow analizuje próbkowane rekordy zbiorcze eksportowane z cache'u flowów routera — jest niezależny od pasma i tani, ale wolniejszy (ograniczony przez active flow timeout, często ok. 60 sekund) i mniej szczegółowy.
Czy sFlow jest szybszy od NetFlow przy wykrywaniu DDoS?
Może być. sFlow wysyła próbkowane nagłówki pakietów w sposób ciągły i nie ma cache'u, który musiałby wygasnąć, więc nie czeka na timeout flowu tak jak klasyczny NetFlow i IPFIX. Oba są jednak próbkowane, więc oba pozostają wolniejsze i mniej precyzyjne niż pełna analiza pakietowa na DPDK i dzielą te same martwe pola przy atakach niskowolumenowych i floodach fragmentów.
Dlaczego czas wykrycia ma aż takie znaczenie?
Bo współczesne ataki wolumetryczne wysycają uplink w kilkadziesiąt sekund. Cloudflare odnotował rekordowy atak 31,4 Tbps, który trwał 35 sekund (luty 2026). Jeśli Twoje wykrywanie reaguje po 35–95 sekundach, krótkie uderzenie może się skończyć — albo łącze może się zapchać — zanim filtrowanie w ogóle wystartuje.
Czy wykrywanie flowowe może przegapić atak, który złapie port-mirror?
Tak. Dane flow są próbkowane (zwykle 1:1000), więc ataki o niskim natężeniu i krótkie serie potrafią przejść pod progiem statystycznym. Floody fragmentów są dodatkowo trudne do zaklasyfikowania, bo fragmenty inne niż pierwszy nie niosą informacji o portach warstwy 4. Packet Sensor na DPDK widzi każdy pakiet i każdy fragment wprost — dlatego łącza krytyczne czasowo łączy się z obiema metodami naraz.
Czy da się obniżyć czas wykrycia na samym NetFlow?
Częściowo. Obniżenie active flow timeout (np. z 60 do 10–15 sekund) i skrócenie interwału eksportu realnie przyspiesza alarm, kosztem większej liczby rekordów i obciążenia routera oraz kolektora. Zwiększenie gęstości próbkowania poprawia dokładność, ale też podnosi koszt. Nawet po dostrojeniu nie zejdziesz do poziomu analizy pakietowej — flow z definicji opisuje ruch, a nie go pokazuje.
Źródła
- Cloudflare — Q4 2025 DDoS Threat Report (luty 2026): https://blog.cloudflare.com/ddos-threat-report-2025-q4/
- NETSCOUT — DDoS Threat Intelligence Report, Issue 16 / 2H 2025 (marzec 2026): https://www.netscout.com/threatreport/
- IETF — RFC 7011, Specification of the IP Flow Information Export (IPFIX) Protocol: https://www.rfc-editor.org/rfc/rfc7011
- IETF — RFC 3176, InMon Corporation's sFlow: https://www.rfc-editor.org/rfc/rfc3176
- IETF — RFC 791, Internet Protocol (fragmentacja IP): https://www.rfc-editor.org/rfc/rfc791
- DPDK — dokumentacja Data Plane Development Kit: https://doc.dpdk.org/guides/
- Andrisoft — WanGuard, dokumentacja produktu: https://www.andrisoft.com/software/wanguard
