19 lutego 2018
·
7 min czytania
Port-mirror daje wykrycie ataku DDoS do 5 sekund, NetFlow — kilkadziesiąt sekund opóźnienia. Porównanie czasu reakcji, kosztu i obciążenia routera.
Krótka odpowiedź: zanim zbudujesz jakąkolwiek ochronę przed DDoS, musisz zdecydować, skąd bierzesz dane o ruchu. Port-mirror daje pełną widoczność bez opóźnienia i pozwala wykryć atak w czasie do 5 sekund, ale wymaga wolnych portów i okablowania. NetFlow / IPFIX / sFlow nie wymaga dodatkowych portów i skaluje się do dowolnie dużej sieci, ale kosztuje kilkadziesiąt sekund opóźnienia wynikającego z eksportu flowów i wprowadza błąd próbkowania. W małej i średniej sieci wybieraj port-mirror wszędzie, gdzie masz na niego porty; NetFlow zostaw tam, gdzie kopiowanie całego ruchu jest fizycznie niewykonalne.
To jest pierwsza decyzja architektoniczna, a nie szczegół implementacyjny. Metoda zbierania danych wyznacza górną granicę tego, jak szybko w ogóle możesz zareagować — żaden filtr nie zadziała wcześniej, niż dowiesz się o ataku.
Dlaczego czas wykrycia jest tu najważniejszy?
Wolumetryczny atak wysyca łącze w kilkadziesiąt sekund. Jeżeli dane o ruchu docierają do sensora z opóźnieniem porównywalnym z czasem trwania samego ataku, obrona reaguje na zgliszcza. Opisaliśmy to szczegółowo w tekście o ataku DDoS na ISP z perspektywy NOC.
Skąd bierze się opóźnienie NetFlow? Router nie wysyła informacji o pakiecie od razu. Buduje wpisy flow w pamięci, agreguje je i eksportuje dopiero po upływie zdefiniowanych timeoutów — active flow timeout i inactive flow timeout. Do tego dochodzi czas przetworzenia datagramów po stronie sensora. W praktyce między pierwszym pakietem ataku a momentem, w którym system może go zobaczyć, mija kilkadziesiąt sekund.
Przy port-mirrorze tego etapu nie ma — przełącznik lub router kopiuje pakiety na port monitorujący w tej samej chwili, w której je przełącza. Stąd różnica: do 5 sekund kontra kilkadziesiąt sekund. Przy krótkich atakach impulsowych, trwających poniżej 30 sekund, decyduje ona o tym, czy atak w ogóle zostanie zauważony.
Czym różni się port-mirror od NetFlow?
| Kryterium | Port-mirror (kopia ruchu) | NetFlow / IPFIX / sFlow / jFlow |
|---|---|---|
| Czas wykrycia | do 5 sekund | kilkadziesiąt sekund (eksport flowów) |
| Widoczność | 100%, każdy pakiet | próbkowana, co n-ty pakiet |
| Dokładność podczas ataku | pełna | niewielki błąd, rośnie z próbkowaniem |
| Obciążenie routera | minimalne, kopiowanie pasywne | zauważalne, generowanie flowów kosztuje CPU |
| Okablowanie | wymagane porty + kable | brak dodatkowych kabli |
| Warstwa | działa niezależnie od L3 | najłatwiej na urządzeniach L3 |
| Skalowalność | ograniczona liczbą portów | praktycznie nieograniczona |
| Ataki impulsowe (<30 s) | wykrywane | często niewidoczne |
| Koszt wdrożenia | porty, kable, ewentualnie TAP | zwykle zerowy, funkcja urządzenia |
Dwie rzeczy łatwo przeoczyć na etapie planowania.
Po pierwsze, port-mirror kopiuje ruch w obu kierunkach. Łącze 5 Gbps RX plus 5 Gbps TX daje 10 Gbps na porcie monitorującym — jeżeli port monitorujący ma tę samą prędkość co monitorowany, przy pełnym obciążeniu zaczniesz gubić pakiety. To najczęstszy błąd pierwszego wdrożenia.
Po drugie, mirrorowanie wielu portów lub VLAN-ów naraz podlega ograniczeniom platformy: liczba sesji, obsługiwane kierunki, współistnienie z innymi funkcjami. Sprawdź dokumentację swojego sprzętu (Cisco: SPAN/RSPAN/ERSPAN i ograniczenia platform Nexus; Juniper: ograniczenia port mirroringu na przełącznikach EX).
Jak duży błąd wprowadza próbkowanie NetFlow?
Mniejszy, niż podpowiada intuicja. Zgodnie z prezentacją Cisco Live BRKSPG-3335 („DDoS Mitigation Deployment — Impact on your Architecture", Nicolas Fevrier, Rajendra Chayapathi, Syed Hassan) zmiana współczynnika próbkowania ma niewielki wpływ na samą zdolność wykrycia ataku, choć wprowadza błąd pomiaru. Dla generycznego ataku typu flood (pakiety 84 B, atak rozproszony o natężeniu 100 Mbps na interfejs routera):
| Sampling | Błąd |
|---|---|
| 1:1000 | 2,1% |
| 1:2000 | 2,9% |
| 1:4000 | 2,9% |
| 1:10000 | 6,5% |
Wniosek praktyczny: przy dużym, trwającym ataku wolumetrycznym próbkowanie nawet 1:10000 wystarcza, żeby stwierdzić „coś się dzieje". Problemem nie jest więc dokładność wolumenu, tylko opóźnienie i niewidoczność zjawisk rzadkich — atak rozproszony po całej podsieci, w którym żaden pojedynczy adres nie przekracza progu, przy agresywnym próbkowaniu może zniknąć w szumie.
Co zrobić, gdy nie ma wolnych portów?
Są dwa wyjścia, oba stosowane w produkcji.
TAP optyczny — pasywny albo aktywny. Jeśli skończyły się porty albo NetFlow nie działa tak, jak powinien, wpięcie TAP-a w tor optyczny daje kopię ruchu bez angażowania routera. TAP pasywny nie wymaga zasilania i nie wprowadza punktu awarii; aktywny daje więcej możliwości (regeneracja sygnału, agregacja kierunków), ale wymaga zasilania. Do rozdzielenia kopii między kilka systemów analitycznych używa się packet brokera.
Ruch próbkowany zamiast pełnej kopii. Jeśli sieć jest duża i nie stać Cię na mirrorowanie każdego portu WAN, router może wysyłać do sensora co dziesiąty pakiet — z 30 Gbps robi się wtedy 3 Gbps do przeanalizowania.
Sama analiza kopii ruchu wymaga po stronie sensora silnika przechwytywania pakietów. WanGuard obsługuje kilka wariantów, różniących się przepustowością, kosztem i poziomem skomplikowania wdrożenia:
| Capture engine | Prędkości | Koszt | Złożoność |
|---|---|---|---|
| Embedded LibPcap | 1–4 Gbps | brak | żadna |
| System LibPcap | 1–4 Gbps | brak | żadna |
| Myricom Sniffer 10G | 10 Gbps | licencja na kartę | średnia |
| PF_RING | 10/40 Gbps | licencja na MAC | dodatkowy moduł jądra / średnia |
| Netmap | 10/40 Gbps | brak | dodatkowy moduł jądra / wysoka |
| DPDK | 10/40 Gbps | brak | dodatkowy moduł jądra / wysoka |
Praktyczna zasada: do 4 Gbps wystarcza zwykły LibPcap. Powyżej tej granicy potrzebny jest silnik omijający stos sieciowy jądra, bo inaczej sensor zacznie gubić pakiety dokładnie wtedy, kiedy najbardziej go potrzebujesz — czyli podczas ataku. Rolę sensora w architekturze opisaliśmy w tekście czym jest WanGuard.
Którą metodę wybrać dla swojej sieci?
Punktem wyjścia powinny być dwie zmienne: typy ataków, których się spodziewasz i przepustowość, jaką musisz obserwować. Uproszczona reguła decyzyjna:
- Masz wolne porty i mniej niż kilkanaście Gbps na brzegu — port-mirror. Najkrótszy czas wykrycia, najmniejsze obciążenie routera, najmniej niespodzianek.
- Duża sieć, wiele portów WAN, dziesiątki Gbps — NetFlow / IPFIX, ewentualnie uzupełniony mirrorem na najbardziej krytycznych łączach.
- Brak portów, a NetFlow zachowuje się dziwnie — TAP optyczny.
- Zależy Ci na ochronie przed krótkimi atakami impulsowymi — mirror albo ruch próbkowany. Klasyczny NetFlow tych ataków po prostu nie zdąży pokazać.
Rozwiązania nie wykluczają się nawzajem — typowe wdrożenie w średnim ISP łączy oba: mirror tam, gdzie liczy się czas reakcji, NetFlow jako pokrycie reszty sieci i źródło danych do raportowania oraz planowania pojemności łączy. Jeśli masz wątpliwości, który wariant pasuje do Twojej topologii — napisz do nas; dobór metody zbierania danych to pierwszy etap każdego wdrożenia systemu WanGuard.
Najczęstsze pytania
Czy port mirroring obciąża router?
W niewielkim stopniu. Kopiowanie ramki na port monitorujący realizuje zwykle układ przełączający, a nie CPU. Generowanie flowów dla NetFlow jest operacją znacznie droższą, bo wymaga utrzymywania tablicy flowów i okresowego eksportu. Uwaga na wyjątki: mirrorowanie wielu VLAN-ów albo kierunków naraz potrafi na niektórych platformach uruchomić wolniejszą ścieżkę przetwarzania.
Ile pasma potrzebuje port monitorujący?
Tyle, ile suma obu kierunków monitorowanego łącza. Łącze 5 Gbps RX + 5 Gbps TX daje 10 Gbps kopii. Port monitorujący o tej samej prędkości co monitorowany zacznie gubić pakiety przy większym obciążeniu, więc planuj z zapasem albo rozdziel kierunki na osobne porty.
Czy sFlow wystarczy do wykrywania ataków DDoS?
Do wykrycia dużego ataku wolumetrycznego — tak, próbkowanie wprowadza błąd rzędu kilku procent, co nie przeszkadza w stwierdzeniu, że łącze jest wysycane. Do wykrycia ataków krótkich, niskowolumenowych albo rozproszonych po całej podsieci — zwykle nie. Tam potrzebna jest pełna widoczność.
Po co TAP, skoro mam port mirroring?
TAP przydaje się w trzech sytuacjach: gdy skończyły się wolne porty, gdy nie chcesz obciążać urządzenia produkcyjnego dodatkową funkcją, oraz gdy potrzebujesz kopii ruchu niezależnej od konfiguracji routera — TAP pasywny działa dalej nawet wtedy, gdy urządzenie się zrestartuje lub ktoś skasuje sesję mirrorowania.
