Sampling i analiza ruchu sieciowego część II – NetFlow vs. sFlow vs. IPFIX

W tym wpisie przyjrzymy się trzem popularnym mechanizmom zbierania próbek ruchu z urządzeń sieciowych – NetFlow, sFlow i IPFIX. Pamiętaj, że Twoje urządzenie może nie wspierać wszystkich tych standardów, a jedynie wybrane. Inne urządzenia, na przykład proste przełączniki czy modemy kablowe zazwyczaj nie obsługują żadnego z nich. To, jakie protokoły i w której wersji nasze urządzenie wspiera, najlepiej sprawdzić w dokumentacji do używanej przez nas wersji firmware. Pamiętajmy też, że wielu dostawców nie pozwala na konfigurację tych mechanizmów z poziomu interfejsu GUI, a jedynie za pomocą konsoli. Wybór odpowiedniej techniki samplingu ruchu sieciowego wymaga zrozumienia fundamentalnych różnic między głównymi protokołami monitorowania. NetFlow, sFlow i IPFIX reprezentują różne paradygmaty zbierania danych telemetrycznych, oferując unikalne kompromisy między dokładnością, skalowalnością i elastycznością.

NetFlow

NetFlow został opracowany przez firmę Cisco Systems pod koniec lat 90. XX wieku jako narzędzie do monitorowania przepływu danych w sieciach komputerowych. Pierwotnie zaprojektowany do analizy ruchu w routerach Cisco umożliwiał administratorom sieci zbieranie informacji o przepływach danych, takich jak adresy IP źródłowe i docelowe, porty, protokoły oraz ilość przesłanych danych. Opiera się na koncepcji agregacji pakietów w logiczne przepływy definiowane przez pięciokrotkę: źródłowy i docelowy adres IP, porty oraz protokół warstwy transportowej. Każdy przepływ rejestrowany jest w cache’u urządzenia z polami:

• Liczniki bajtów i pakietów
• Znaczniki czasu rozpoczęcia/zakończenia
• Informacje o interfejsach wejściowych/wyjściowych
• Flagi TCP oraz typ usługi (ToS)

Przepływy eksportowane są do kolektora po przekroczeniu progów czasowych (domyślnie 30 sekund aktywności, 15 sekund braku aktywności) lub po wykryciu flag kończących sesję (np. FIN w TCP). Wersja v9 wprowadza mechanizm szablonów, umożliwiający dynamiczne definiowanie struktur danych poprzez Template Records.

analizy danych stawała się oczywista.3 NetFlow nie jest w pełni otwartym standardem. Początkowo był to rozwiązanie zamknięte firmy Cisco, co ograniczało jego zastosowanie do urządzeń tej firmy. Jednak wraz z rozwojem i rosnącym zapotrzebowaniem na wszechstronne narzędzia monitorujące, powstały próby ujednolicenia i otwarcia standardu, co zaowocowało stworzeniem IPFIX – otwartego standardu bazującego na NetFlow wersji 9. Obecnie NetFlow implementowany jest na urządzeniach różnych dostawców.

Proces zbierania i analizy danych obejmuje kilka kroków:

1. Zbieranie danych: Urządzenie sieciowe analizuje każdy pakiet przechodzący przez interfejs, wyodrębniając istotne informacje niezbędne do zalogowania przepływu.
2. Tworzenie rekordów przepływu: Na podstawie zebranych danych tworzone są rekordy przepływu, które zawierają szczegółowe informacje o ruchu sieciowym (metadane).
3. Eksportowanie danych: Rekordy przepływu są okresowo wysyłane do serwera kolektora NetFlow, gdzie są przechowywane i analizowane.
4. Analiza i raportowanie: Na serwerze kolektorowe narzędzia analizują zebrane dane, umożliwiając administratorom monitorowanie ruchu, identyfikację wzorców oraz wykrywanie anomalii.

NetFlow przeszedł kilka iteracji rozwojowych, z których najważniejsze to wersje 5 i 9. Każda z nich wprowadzała nowe funkcjonalności i ulepszenia, odpowiadając na rosnące potrzeby analizy ruchu sieciowego. Choć NetFlow nie jest standardem IETF, jego wersja 9 stała się podstawą dla IPFIX (RFC 7011). Kluczowe różnice w implementacjach:

• Cisco IOS/IOS-XE: Wymaga konfiguracji Flow Monitor, Flow Exporter i Flow Record z możliwością wyboru 400+ pól metadanych
• Juniper j-Flow: Wykorzystuje statystyki per interfejs z opcją próbkowania 1:N (np. set forwarding-options sampling instance rate 1024)
• Huawei NetStream: Dodaje obsługę MPLS Labels i VXLAN w szablonach eksportu

NetFlow v5

NetFlow v5 jest jedną z najczęściej stosowanych wersji tego protokołu. Charakteryzuje się prostotą i stabilnością, co sprawia, że jest szeroko wspierany przez różne urządzenia sieciowe. Wersja 5 definiuje stały zestaw pól w rekordzie przepływu, co ułatwia implementację i analizę danych. Typowe pola obejmują adresy IP źródłowe i docelowe, porty, protokół, liczbę pakietów i bajtów, a także czas trwania przepływu.

Zaletą NetFlow v5 jest jego szeroka kompatybilność i łatwość integracji z narzędziami analitycznymi. Jednak jego ograniczenie polega na braku elastyczności w definiowaniu nowych pól, co może być problematyczne w przypadku potrzeby zbierania bardziej szczegółowych danych.

NetFlow v9

NetFlow v9 wprowadza znaczące ulepszenia w porównaniu do wersji 5, przede wszystkim poprzez wprowadzenie szablonów przepływów. Dzięki szablonom, użytkownicy mogą definiować własne zestawy pól, co zwiększa elastyczność i pozwala na dostosowanie zbieranych danych do specyficznych potrzeb organizacji. To sprawia, że NetFlow v9 jest bardziej przyszłościowy i lepiej przystosowany do dynamicznie zmieniających się wymagań sieciowych.

Kolejną zaletą NetFlow v9 jest wsparcie dla eksportu różnych typów danych, co umożliwia bardziej zaawansowaną analizę i integrację z różnorodnymi narzędziami monitorującymi. Ponadto, wersja 9 stanowi podstawę dla standardu IPFIX, co zwiększa interoperacyjność i ułatwia wdrażanie rozwiązań monitorujących w środowiskach z urządzeniami różnych producentów.

IPFIX

IPFIX jest bezpośrednim następcą NetFlow wersji 9, który został zaprojektowany przez firmę Cisco. Podczas gdy NetFlow v9 wprowadził mechanizm szablonów przepływów, umożliwiając definiowanie niestandardowych zestawów danych, IPFIX formalizuje te idee w ramach otwartego standardu. Standaryzacja IPFIX przez IETF miała na celu stworzenie uniwersalnego protokołu, który może być szeroko adoptowany przez różnych producentów sprzętu sieciowego, eliminując zależność od jednego dostawcy i promując większą elastyczność w monitorowaniu ruchu sieciowego.

IPFIX (RFC 7011-7015) wprowadza ustandaryzowany mechanizm eksportu danych:

• Information Elements (IEs): 169 predefiniowanych pól (np. postNATSourceIPv4Address) z możliwością rozszerzeń vendor-specific
• Struktura szablonów: Template Records definiują układ Data Records, obsługując zagnieżdżone struktury poprzez listy sekwencyjne
• Transport: Wymagane wsparcie dla SCTP z opcjonalnym UDP i TCP, z mechanizmami retransmisji

Kluczową innowacją jest wsparcie dla biflow aggregation – korelacji przepływów w obu kierunkach. Biflow to pojedynczy rekord przepływu, który zawiera informacje o ruchu w obu kierunkach między źródłem a celem. Wykorzystanie biflows pozwala na zmniejszenie redundancji danych i poprawę efektywności eksportu, co dokładnie zostało opisane w RFC 5103, które definiuje metodę eksportu biflows za pomocą pojedynczego rekordu przepływu.

Podobnie jak NetFlow v9, IPFIX wykorzystuje mechanizm szablonów do definiowania struktury rekordów przepływu. Jednak IPFIX rozszerza ten model, wprowadzając dodatkowe funkcje, które zwiększają jego elastyczność i zdolność do adaptacji do nowych technologii. Sam proces zbierania i przetwarzania danych jest zbliżony do opisanego w sekcji poświęconej NetFlow.

Wsparcie dla IPFIX deklarują m.in.:

• Cisco ASR 9000: Eksport danych NBAR2 (Application ID) + DSCP
• Juniper MX Series: Integracja z Inline JFlow dla próbkowania interfejsów 40G
• Fortinet FortiGate: Eksport pól związanych z IPSec i SSL Inspection

sFlow

sFlow (sampling Flow) to otwarty standard opracowany przez firmę InMon, który zyskał szerokie uznanie dzięki swojej zdolności do efektywnego monitorowania dużych, skalowalnych sieci bez generowania nadmiernych ilości danych. sFlow został wprowadzony na przełomie lat 90. jako odpowiedź na rosnące potrzeby monitorowania ruchu w coraz bardziej złożonych i dynamicznych sieciach. Jego głównym celem było zapewnienie metody zbierania danych, która jest zarówno wydajna, jak i reprezentatywna, niezależnie od wielkości i złożoności sieci. Dzięki swojej otwartej naturze, sFlow szybko zyskał popularność i został zaimplementowany w sprzęcie wielu wiodących producentów, takich jak Cisco, Juniper, HP czy Dell.

sFlow (opisany dokładnie w RFC 3176) łączy dwa mechanizmy:

1. Packet Sampling: Losowy wybór 1 z N pakietów (np. 1:1024) realizowany sprzętowo przez ASIC przełącznika
2. Counter Polling: Okresowe zbieranie liczników interfejsów (co 30-60 sekund)

Próbkowane nagłówki pakietów (do 128 bajtów) eksportowane są natychmiastowo w formie datagramów UDP, bez buforowania przepływów. Dzięki temu opóźnienie pomiarowe spada do <1 ms, co jest kluczowe dla detekcji ataków DDoS. Spójrzmy dokładniej jak sFlow wykorzystuje to podejście polagające na próbkowaniu pakietów oraz monitorowania statystyk interfejsów sieciowych, gdyż proces ten można podzielić na kilka kluczowych etapów:

1. Próbkowanie pakietów: sFlow wykorzystuje losowe próbkowanie pakietów przechodzących przez interfejsy sieciowe. Zazwyczaj tylko jeden z N pakietów jest wybierany do analizy, co znacznie redukuje ilość danych przesyłanych do kolektora bez utraty reprezentatywności.
2. Zbieranie statystyk interfejsów: Oprócz próbkowania pakietów, sFlow zbiera również statystyki dotyczące interfejsów, takie jak liczba przesłanych i odebranych pakietów, błędów oraz przepustowość.
3. Eksportowanie danych: Zebrane dane są przesyłane do centralnego serwera kolektorowego, gdzie są analizowane i wizualizowane za pomocą specjalistycznych narzędzi analitycznych.
4. Analiza i raportowanie: Na serwerze kolektorowym, dane sFlow są przetwarzane w celu generowania raportów, identyfikacji wzorców ruchu, wykrywania anomalii oraz optymalizacji wydajności sieci.

Jedną z kluczowych zalet sFlow jest jego szeroka adopcja przez producentów sprzętu sieciowego. Urządzenia takie jak routery, przełączniki, firewalle oraz urządzenia wirtualne często posiadają wbudowane wsparcie dla sFlow, co ułatwia jego implementację w różnorodnych środowiskach sieciowych.

Główną wadą sFlow jest statystyczna niepewność pomiarów – przy próbkowaniu 1:1000, błąd estymacji ruchu TCP może sięgać 15%. Producenci rekomendują:

• Używanie sFlow v5 z rozszerzonymi polami MPLS i IPv6
• Konfigurację próbkowania adaptacyjnego w funkcji obciążenia CPU (np. Arista DANZ)
• Integrację z protokołem PSAMP (RFC 5475) dla zaawansowanej analizy warstwy aplikacyjnej

Kolektor danych

Na koniec słowo o kolektorze danych, czyli oprogramowaniu, które ma za zadanie odbierać rekordy z urządzeń sieciowych, agregować je, wzbogacać i wysyłać do hurtowni danych lub innych mechanizmów pozwalających na gromadzenie i analizę danych.

Rozwiązania klasy enterprise (np. Flowmon Collector) implementują:

• Kompresję delta encoding dla powtarzających się pól szablonów
• Partycjonowanie czasowe bazy danych (np. 5-min przedziały)
• Pre-agregację wskaźników KPI (np. top-talkerów)

Jeżeli natomiast samplowanie ruchu jest elementem systemu bezpieczeństwa klasy SIEM to najczęściej charakteryzuje się poniższymi cechami:

1. Normalizacja pól między różnymi eksporterami (np. interfaceIndex -> SNMP ifName)
2. Wsparcie dla NetFlow-LNS (Lost Notification Service) przy użyciu UDP
3. Dekodowanie rozszerzeń vendor-specific (np. Palo Alto User-ID) via Private Enterprise Number

Jak widać cechy obu tych kolektorów się od siebie różnią, mimo, że pracują na tym samym zestawie odebranych z urządzeń sieciowych danych.

Ewolucja protokołów monitorowania ruchu zmierza w kierunku ujednoliconego standardu IPFIX, który dzięki swojej rozszerzalności zastępuje starsze rozwiązania. Jednak specyficzne wymagania infrastrukturalne wciąż utrzymują znaczenie technik takich jak sFlow w niszowych zastosowaniach. Kluczem jest implementacja kolektorów zdolnych do równoległego przetwarzania heterogenicznych strumieni danych z zachowaniem kontekstu topologicznego.