Decyzja o protokole monitoringu zapada zwykle nie przy biurku administratora, lecz w katalogu producenta sprzętu. Cisco eksportuje NetFlow, przełączniki data center mówią w sFlow, a IPFIX pojawia się tam, gdzie ktoś chciał uniezależnić się od jednego dostawcy. Trzy protokoły to trzy odpowiedzi na to samo pytanie: ile dokładności poświęcić w zamian za skalowalność.
NetFlow: pełna księgowość ruchu IP
NetFlow powstał w Cisco i działa na zasadzie pełnego rozliczania przepływów. Urządzenie grupuje pakiety w przepływy (adresy źródłowy i docelowy, porty, protokół, typ usługi), trzyma je w pamięci podręcznej (flow cache) i eksportuje do kolektora po zakończeniu sesji. Dzięki temu widzi każdą komunikację — nic nie ucieka przez statystyczne sito, więc dane nadają się do analiz śledczych incydentów i rozliczeń. Wadą jest to, że monitoruje wyłącznie ruch IP i obciąża urządzenie utrzymywaniem flow cache. W praktyce spotkacie NetFlow v5 (sztywny zestaw pól, tylko IPv4) oraz v9, który wprowadził szablony (templates) i otworzył drogę do IPv6 oraz pól definiowanych elastycznie.
sFlow: próbkowanie zamiast pełnego obrazu
sFlow działa odwrotnie: próbkuje pakiety ze stałym współczynnikiem (np. 1 na 2000) i wysyła próbki do kolektora niemal w czasie rzeczywistym, bez flow cache. Obciążenie procesora i pamięci jest minimalne, dlatego sFlow sprawdza się w rdzeniu sieci, w przełącznikach data center i u operatorów, gdzie liczą się terabity, a monitoring nie może spowalniać forwardingu. Cena tej skalowalności to dokładność — pomiar jest przybliżeniem, a krótka sesja może w ogóle nie trafić do próbki. Atut, którego NetFlow nie ma: sFlow rejestruje też ruch nie-IP, czyli ramki warstwy 2 i protokoły inne niż IP. Poza ekosystemem Cisco dominuje — stosują go m.in. HPE, Juniper, Huawei i Arista.
IPFIX: otwarty standard
IPFIX to formalny standard IETF (seria dokumentów RFC), którego bazą architektoniczną stał się NetFlow v9. Różnica nie jest kosmetyczna: NetFlow kontroluje Cisco, a IPFIX ma opublikowaną specyfikację, testy interoperacyjności i ciało standaryzacyjne nadzorujące rozwój — co zmniejsza ryzyko uzależnienia od jednego dostawcy. Pozwala też eksportować pola definiowane przez producenta (enterprise-specific Information Elements): od metadanych aplikacyjnych po informacje warstwy 7 czy własne atrybuty bezpieczeństwa. To pełne rozliczanie przepływów jak NetFlow, ale otwarte, rozszerzalne i neutralne względem marki.
Który protokół do czego
Wybór sprowadza się do kompromisu dokładność kontra skalowalność — żaden protokół nie jest uniwersalnie lepszy:
- NetFlow — gdy macie sprzęt Cisco na brzegu sieci i łączach WAN, a zależy wam na pełnym obrazie każdego przepływu IP do analizy bezpieczeństwa i rozliczeń.
- sFlow — w rdzeniu, data center i u operatorów, gdzie liczy się przepustowość, a statystyczne przybliżenie wystarcza do wykrywania trendów i anomalii wolumenowych.
- IPFIX — gdy chcecie dokładności NetFlow bez przywiązania do producenta, potrzebujecie bogatszych metadanych albo budujecie środowisko wielu dostawców.
W praktyce wiele organizacji łączy te protokoły: sFlow na szybkim rdzeniu, NetFlow lub IPFIX na brzegu i routerach WAN. To podejście pragmatyczne, ale generuje wymóg — kolektor i narzędzie analityczne muszą rozumieć wszystkie trzy formaty naraz.
Rola narzędzia analitycznego
Protokół to tylko transport danych. Wartość powstaje w warstwie, która przepływy koreluje, wzbogaca o kontekst i zamienia w obraz sieci. Stąd praktyczne kryterium zakupowe: dobre narzędzie do monitorowania ruchu powinno obsługiwać NetFlow, sFlow i IPFIX równolegle, bo realna infrastruktura rzadko mówi jednym protokołem. Sycope, polskie rozwiązanie klasy NDR, przyjmuje wszystkie trzy jednocześnie, bez limitu źródeł danych i podsieci — to sprzęt dyktuje format, a warstwa analityczna się dostosowuje. Instalacja on-premise oznacza, że dane o ruchu nie opuszczają infrastruktury firmy (istotne wobec RODO i NIS2), a korelacja z bazą MITRE ATT&CK pozwala wyciągać z surowych przepływów sygnały o zagrożeniach.
Artykuł sponsorowany
