Jest wtorek, godzina 9:40. CSIRT sektorowy prosi o doprecyzowanie wczesnego ostrzeżenia: z którymi maszynami w sieci wewnętrznej rozmawiał zainfekowany serwer plików w ostatnich dwóch tygodniach? Logi firewalla pokazują ruch na granicy sieci. EDR ma pełną historię stacji roboczych, ale nie drukarek, kamer IP ani sterowników w hali. Bez historii ruchu wewnątrz sieci uczciwa odpowiedź brzmi „nie wiemy” — a to słaby punkt wyjścia do raportu, który za niespełna trzy doby trzeba uzupełnić o ocenę skutków.
Analiza ruchu sieciowego na przepływach odpowiada właśnie na to pytanie: kto z kim, kiedy i ile. Nie zastępuje firewalla, EDR ani przechwytywania pakietów, tylko wypełnia lukę między nimi. W tym tekście opisujemy, co da się wykryć na samych metadanych ruchu, gdzie ta metoda się kończy i jak jej dane przekładają się na obowiązki z dyrektywy NIS2 i znowelizowanej ustawy o krajowym systemie cyberbezpieczeństwa. Jako przykład narzędzia służy Progress Flowmon, ale kryteria stosują się do każdej platformy tej klasy.
Czym jest analiza ruchu sieciowego i czym różnią się przepływy od pakietów?
To badanie komunikacji w sieci na podstawie jej zapisu — albo pełnych pakietów, albo ich streszczeń, czyli przepływów. Przechwytywanie pakietów zapisuje wszystko, łącznie z treścią, w jednym punkcie sieci. Tak działa Wireshark, który opisujemy w tekście o Wiresharku i przechwytywaniu pakietów. Metoda jest precyzyjna, ale zapis całej sieci przez tygodnie szybko staje się nieosiągalny.
Przepływ to streszczenie. Specyfikacja protokołu IPFIX (RFC 7011, wrzesień 2013) definiuje go jako zbiór pakietów przechodzących przez punkt obserwacji w określonym przedziale czasu, które mają wspólne cechy, na przykład adresy, porty i protokół. Jeden rekord przepływu mówi, które urządzenia rozmawiały, jak długo, przez jaki port i ile danych wymieniły. Nie mówi, co było w środku.
Ta różnica decyduje o zastosowaniu. Pakiety służą do szczegółowej analizy konkretnego zdarzenia. Przepływy służą do wiedzy o całej sieci w długim okresie: pozwalają zobaczyć wzorce, odchylenia od normy i historię, do której można wrócić po tygodniach. W praktyce obie metody się uzupełniają, a analiza przepływów wskazuje, gdzie warto sięgnąć po pakiety.
Przepływ w jednym zdaniu: rekord „kto, z kim, kiedy, przez jaki port i ile danych” dla każdej rozmowy w sieci, bez treści tej rozmowy. Tani w przechowywaniu, więc może sięgać daleko wstecz.
Czego nie widzą firewall i EDR w sieci wewnętrznej?
Ruchu, który nie przechodzi przez granicę sieci, i urządzeń bez agenta. Firewall brzegowy kontroluje połączenia z internetem i między wydzielonymi strefami. Połączenie ze stacji roboczej do serwera plików w tym samym segmencie w ogóle go nie dotyka. To ruch „wschód–zachód”, którym atakujący porusza się po wejściu do sieci.
EDR widzi szczegółowo to, co dzieje się na urządzeniu z zainstalowanym agentem: procesy, pliki, połączenia. Agent nie trafia jednak na drukarki, kamery IP, telefony VoIP, urządzenia sieciowe, systemy wbudowane ani sterowniki przemysłowe. Porównanie zakresów obu klas narzędzi opisujemy w tekście EDR vs XDR vs NDR.
Tę lukę wypełnia kategoria nazywana network detection and response, czyli NDR, którą szerzej definiujemy w artykule o NDR i widoczności w sieci. Progress pozycjonuje Flowmon dokładnie w tym miejscu: między ochroną perymetru a ochroną punktów końcowych. Analiza ruchu nie potrzebuje agenta na urządzeniu, bo obserwuje jego komunikację z zewnątrz.
Im mniej podzielona jest sieć, tym więcej ruchu bocznego omija wszystkie punkty kontroli — ograniczanie go opisujemy w tekście o mikrosegmentacji sieci.
Skąd brać dane o przepływach: routery, przełączniki czy sondy?
Najpierw z urządzeń, które już są w sieci, a sond używać tam, gdzie te dane nie wystarczają. Routery, przełączniki, firewalle i load balancery zwykle potrafią eksportować rekordy przepływów. Kolektor Flowmon według producenta przyjmuje NetFlow w wersjach 5 i 9, IPFIX, sFlow, jFlow i inne formaty flow opisane w RFC. Obsługuje też logi przepływów chmur AWS, Azure i Google Cloud.
Przed włączeniem eksportu trzeba sprawdzić jedną rzecz: próbkowanie. Wiele urządzeń, zwłaszcza przy dużych przepływnościach, eksportuje tylko co n-ty pakiet, a sFlow z założenia opiera się na próbkach. Próbkowanie wystarcza do statystyk obciążenia łączy, ale gubi krótkie połączenia, czyli właśnie te, po których widać skanowanie i próby logowania. Czego nie ma w eksporcie, tego kolektor już nie odtworzy.
Sonda to osobne urządzenie, które obserwuje ruch pasywnie — przez port SPAN przełącznika albo przez TAP — i sama tworzy rekordy. Sonda Flowmon występuje w wersji sprzętowej, wirtualnej i chmurowej, dla łączy od 10 Mb/s do 100 Gb/s. Poza danymi warstw 2–4 dodaje w rozszerzeniu IPFIX informacje z warstwy aplikacji, takie jak nazwy hostów, adresy URL i zapytania DNS, oraz metryki wydajności: czas odpowiedzi serwera, opóźnienie, jitter i retransmisje.
Rozsądny układ łączy obie metody: eksport z urządzeń daje szeroki obraz niskim kosztem, a sonda przed kluczowymi serwerami — pełne dane tam, gdzie są najcenniejsze.
Jakie zagrożenia da się wykryć na samych metadanych ruchu?
Te, które zmieniają wzorzec komunikacji, nawet jeśli nie zmieniają jej treści. Rozpoznanie sieci wygląda jak jedno urządzenie łączące się z wieloma adresami lub portami w krótkim czasie. Ruch boczny widać jako nowe połączenia SMB lub RDP między stacjami, które wcześniej ze sobą nie rozmawiały. Eksfiltracja to nietypowy wolumen danych wychodzących, często o nietypowej porze albo do nowego celu.
Łączność z serwerem sterującym atakującego często przybiera postać regularnych, małych połączeń w stałych odstępach czasu. Nadużycia protokołów pomocniczych to kolejna klasa. Progress wymienia analizę DNS, DHCP, ICMP i SMTP jako sposób wykrywania eksfiltracji, rozpoznania i ruchu bocznego.
Flowmon realizuje to w module Anomaly Detection System. Producent deklaruje wiele metod opartych na AI i algorytmów łączących analizę behawioralną, adaptacyjne linie bazowe, reputację adresów i detekcję sygnaturową. Zdarzenia mapuje na framework MITRE ATT&CK i może porównywać ruch ze wskaźnikami kompromitacji z sieci wymiany informacji MISP. Opcjonalna sonda IDS oparta na silniku Suricata dodaje detekcję sygnaturową na pakietach.
Metadane służą też do polowania na zagrożenia: hipotezę „kto spoza zwykłej grupy łączy się z tym serwerem” sprawdza się na historii przepływów, bez instalowania czegokolwiek na serwerze. Metodę opisujemy w tekście o threat huntingu w praktyce.
Co widać w ruchu szyfrowanym bez jego odszyfrowania?
Więcej, niż się zwykle zakłada, choć nie treść. Szyfrowanie ukrywa zawartość rozmowy, ale nie to, że rozmowa się odbyła, między kim, jak długo i z jakim wolumenem. Wzorce opisane wyżej — skanowanie, ruch boczny, regularne połączenia sterujące — działają tak samo dla ruchu szyfrowanego.
Sam protokół TLS też zostawia ślady. Sonda Flowmon wzbogaca rekordy o informacje z negocjacji TLS. Producent wymienia wśród zastosowań wskazywanie przestarzałych i niezgodnych z polityką certyfikatów, słabego szyfrowania i starych wersji TLS, które mogą zawierać podatności.
To ma znaczenie nie tylko dla wykrywania ataków. Dyrektywa NIS2 w art. 21 ust. 2 lit. h wymaga polityk i procedur stosowania kryptografii i szyfrowania. Inwentarz rzeczywiście używanych wersji TLS i certyfikatów, zbudowany z obserwacji ruchu, pokazuje, czy polityka działa w praktyce, a nie tylko na papierze.
Granica jest twarda: metadane nie powiedzą, czy w zaszyfrowanym połączeniu przesłano konkretny plik.
Jak długo przechowywać dane o przepływach i ile to zajmuje?
Tak długo, żeby sięgnąć do momentu prawdopodobnego pierwszego wejścia atakującego, a nie tylko do dnia wykrycia. Incydenty rzadko wykrywa się w dniu, w którym się zaczęły. Historia obejmująca tylko ostatnie dni pozwala opisać objawy, ale nie drogę, którą atakujący przeszedł przez sieć.
Wielkość danych zależy od liczby przepływów, a nie od przepływności łączy. Sieć z wieloma krótkimi połączeniami, na przykład dużą liczbą zapytań DNS, generuje więcej rekordów niż sieć z kilkoma dużymi transferami. Dlatego wymiarowanie warto oprzeć na pomiarze z pilotażu, a nie na przeliczniku z katalogu.
Progress podaje dla kolektora Flowmon pojemność od 0,5 do 192 TB na urządzenie i przechowywanie danych od miesięcy do lat, zależnie od wybranej pojemności. Producent podkreśla, że kolektor nie agreguje i nie próbkuje danych. Większe sieci obsługuje architektura rozproszona z centralnym węzłem, który zbiera dane z oddziałów.
Rekordy zawierają adresy, które da się przypisać do pracowników, więc okres przechowywania i zakres dostępu opisuje się jak dla innych logów bezpieczeństwa.
Jak analiza ruchu wspiera obowiązki raportowe z NIS2 i ustawy o KSC?
Dostarcza faktów, które trzeba podać w kolejnych zgłoszeniach, i to w terminach, w których inaczej ich nie ma. Art. 23 ust. 4 dyrektywy NIS2 przewiduje wczesne ostrzeżenie w ciągu 24 godzin od powzięcia wiedzy o poważnym incydencie. W ciągu 72 godzin trzeba złożyć zgłoszenie ze wstępną oceną dotkliwości i skutków, a w stosownych przypadkach ze wskaźnikami integralności systemu. Sprawozdanie końcowe, z rodzajem zagrożenia lub pierwotną przyczyną, przychodzi nie później niż miesiąc po zgłoszeniu.
Polska transpozycja liczy te terminy od wykrycia incydentu. Znowelizowana ustawa o krajowym systemie cyberbezpieczeństwa (Dz.U. 2026 poz. 252, w mocy od 3 kwietnia 2026 r.) w art. 11 ust. 1 pkt 4 i 4a każe zgłosić wczesne ostrzeżenie w ciągu 24 godzin, a incydent poważny w ciągu 72 godzin — w obu przypadkach „od momentu jego wykrycia”, do właściwego CSIRT sektorowego. Według art. 33 ust. 1 nowelizacji podmioty kluczowe i ważne realizują obowiązki z rozdziału 3 ustawy w ciągu 12 miesięcy od jej wejścia w życie.
Dyrektywa definiuje obsługę incydentu jako działania mające na celu m.in. jego wykrywanie, analizowanie i ograniczanie zasięgu (art. 6 pkt 8). Historia przepływów odpowiada na pytania, które pojawiają się na każdym etapie: od kiedy trwa nietypowa komunikacja, które urządzenia są zaangażowane, czy dane opuściły sieć i w jakiej ilości. Bez niej wstępna ocena skutków opiera się na przypuszczeniach.
Oś czasu zgłoszeń i dane z sieci: 24 h — czy ruch wskazuje na działanie celowe i skąd przyszedł; 72 h — które segmenty i urządzenia są objęte, czy był transfer na zewnątrz; 1 miesiąc — droga atakującego od pierwszego połączenia, pierwotna przyczyna, skuteczność ograniczenia. Każdy etap wymaga historii sięgającej przed dzień wykrycia.
Narzędzie nie zapewnia jednak zgodności samo w sobie. NIS2 wymaga procesu obsługi incydentów, wyznaczonych ról i dokumentacji. Analiza ruchu jest jednym ze źródeł danych dla tego procesu, a przegląd wszystkich wymagań prowadzimy w ramach wdrożenia zgodności z NIS2. Pozostałe teksty o dyrektywie zebraliśmy w bazie wiedzy NIS2.
Gdzie analiza przepływów się kończy i kiedy potrzebny jest zapis pakietów?
Tam, gdzie pytanie dotyczy treści, a nie faktu komunikacji. Przepływ powie, że z serwera wyszło kilka gigabajtów do nieznanego adresu. Nie powie, jakie pliki to były. Do ustalenia zakresu wycieku albo odtworzenia konkretnego polecenia potrzebny jest zapis pakietów lub dane z samego urządzenia.
Druga granica to próbkowanie i miejsca bez obserwacji. Jeżeli eksport z przełącznika jest próbkowany albo ruch omija punkty pomiaru, historia będzie niepełna. Trzecia granica to procesy na urządzeniu: analiza ruchu nie wskaże, który program nawiązał połączenie. To domena EDR.
Flowmon łagodzi pierwszą granicę, uruchamiając pełny zapis pakietów po wykryciu zdarzenia; według producenta bufor rotacyjny obejmuje też ruch sprzed początku ataku.
W dochodzeniu po incydencie przepływy wskazują kierunek, a pakiety i dane z urządzeń dostarczają dowodów. Kolejność zabezpieczania dowodów opisujemy w tekście o informatyce śledczej po cyberataku.
Jak połączyć NDR z SIEM i SOC, żeby alert nie utonął?
Przez trzy połączenia: eksport zdarzeń, wzbogacenie o tożsamość i przypisanie właściciela. Pierwsze jest techniczne. Flowmon przekazuje zdarzenia do systemów zarządzania logami i SIEM przez syslog, SNMP, e-mail, REST API lub własne skrypty. Dzięki temu alert z sieci trafia obok alertów z EDR i logów systemowych.
Drugie połączenie zamienia adres IP w człowieka. Flowmon może korelować zdarzenia z logami systemów uwierzytelniania, na przykład Active Directory, LDAP lub Cisco ISE. Wtedy analityk widzi użytkownika albo nazwę hosta zamiast samego adresu. Przy adresacji dynamicznej to różnica między szybką decyzją a godziną ustalania, kto miał dany adres.
Trzecie połączenie jest organizacyjne i najczęściej pomijane. Ktoś musi alert przeczytać, ocenić i zdecydować o reakcji — w godzinach, w których atakujący działa. Automatyczna reakcja pomaga, bo Flowmon potrafi na przykład odizolować adres przez integrację z systemem kontroli dostępu do sieci. Nie zastępuje jednak oceny człowieka przy zdarzeniach niejednoznacznych.
Bez własnego zespołu dyżurującego alerty z sieci warto włączyć do usługi SOC — inaczej detekcja kończy się na pulpicie, którego nikt nie ogląda w nocy.
Jak dobrać narzędzie do analizy ruchu?
Od wymagań, które da się sprawdzić w pilotażu, a nie od listy funkcji w materiałach dostawcy. Poniższa tabela zamienia każde wymaganie na pytanie do dostawcy i sposób weryfikacji we własnej sieci.
| Wymaganie | Pytanie do dostawcy | Jak sprawdzić w pilotażu |
|---|---|---|
| Źródła danych | Jakie formaty przyjmuje (NetFlow v5/v9, IPFIX, sFlow, logi chmurowe)? | podłączyć eksport z własnych urządzeń i chmury, porównać liczbę rekordów |
| Kompletność | Czy kolektor agreguje lub próbkuje dane? | porównać rekordy z sondy i z próbkowanego eksportu dla tego samego łącza |
| Retencja | Ile miesięcy historii zmieści się przy naszej liczbie przepływów? | zmierzyć przepływy na sekundę przez tydzień i przeliczyć pojemność |
| Warstwa aplikacji i TLS | Czy rekordy obejmują DNS, nazwy hostów i metadane TLS? | sprawdzić, czy raport wskazuje stare wersje TLS w naszej sieci |
| Detekcja | Jakie metody detekcji i czy zdarzenia są mapowane na MITRE ATT&CK? | przeprowadzić kontrolowane skanowanie segmentu i zmierzyć czas do alertu |
| Tożsamość | Czy koreluje adresy z logami AD, LDAP lub NAC? | sprawdzić, czy alert pokazuje użytkownika zamiast adresu |
| Integracje | Jak eksportuje zdarzenia do SIEM i SOAR? | przesłać zdarzenie do własnego SIEM i sprawdzić komplet pól |
| Zapis pakietów | Czy może uruchomić zapis po zdarzeniu, z ruchem sprzed niego? | wywołać zdarzenie testowe i odczytać zapis |
| Wdrożenie | Czy dostępne są wersje sprzętowe, wirtualne i chmurowe? | uruchomić wersję wirtualną w docelowym środowisku |
Kolejność wierszy nie jest przypadkowa. Kompletność i retencja decydują o tym, czy narzędzie odpowie na pytania z raportu po incydencie. Detekcja i integracje decydują o tym, czy incydent zostanie wykryty wcześniej.
Od czego zacząć wdrożenie w firmie średniej wielkości?
Od mapy punktów, przez które płynie ruch, i od danych, które sieć już produkuje. Pierwszy krok to wskazanie miejsc obserwacji: rdzeń sieci, połączenie z serwerownią, wyjście do internetu i środowiska chmurowe. Drugi — włączenie eksportu przepływów na istniejących urządzeniach i sprawdzenie, czy nie jest próbkowany.
Trzeci krok to sonda tam, gdzie eksport z urządzeń nie wystarcza, zwykle przed najważniejszymi serwerami. Czwarty to okres uczenia się normalnego ruchu i strojenia progów, zanim alerty trafią do zespołu reagowania. Piąty — test: kontrolowane skanowanie albo symulacja ruchu bocznego, żeby sprawdzić, czy i kiedy pojawi się alert.
Na końcu wynik trzeba wpiąć w procedurę obsługi incydentów: kto dostaje alert, kto decyduje o izolacji i kto przygotowuje dane do zgłoszenia w 24 godziny.
Checklista pilotażu: miejsca obserwacji wskazane; eksport bez próbkowania lub z opisanym próbkowaniem; zmierzona liczba przepływów i wyliczona retencja; test wykrycia skanowania; alert widoczny w SIEM z nazwą użytkownika; przypisany właściciel alertów.
Pilotaż i wdrożenie Progress Flowmon prowadzimy razem z konfiguracją eksportu na istniejących urządzeniach i włączeniem zdarzeń do monitoringu. Stały nadzór nad infrastrukturą realizujemy w ramach usługi monitorowania infrastruktury IT. Pojęcia z tego tekstu znajdziesz też w słowniku: NDR i monitorowanie sieci.
Źródła przywołane w tekście: RFC 7011 „Specification of the IP Flow Information Export (IPFIX) Protocol” (wrzesień 2013); dyrektywa (UE) 2022/2555 (NIS2), art. 6 pkt 8, art. 21 ust. 2, art. 23 ust. 4; ustawa z 23 stycznia 2026 r. o zmianie ustawy o krajowym systemie cyberbezpieczeństwa (Dz.U. 2026 poz. 252), art. 11 ust. 1 pkt 4 i 4a, art. 33 ust. 1; strony produktowe Progress Flowmon (progress.com, stan na wrzesień 2026).
Najczęściej zadawane pytania
Czym różni się analiza przepływów od przechwytywania pakietów?
Przechwytywanie pakietów zapisuje pełną treść ruchu w jednym punkcie sieci i jest precyzyjne, ale kosztowne w przechowywaniu. Przepływ, według specyfikacji IPFIX (RFC 7011, wrzesień 2013), to zbiór pakietów o wspólnych cechach, np. adresach i portach, przechodzących przez punkt obserwacji w określonym czasie. Rekord przepływu mówi, kto z kim, kiedy i ile danych wymienił, bez treści. Dzięki temu da się go przechowywać miesiącami dla całej sieci.
Czy analiza ruchu działa, gdy ruch jest szyfrowany?
Częściowo. Metadane połączenia pozostają widoczne: adresy, porty, wolumen, czas, a przy TLS także wersja protokołu, siła szyfrowania i ważność certyfikatu. Progress Flowmon wykorzystuje je m.in. do wskazywania przestarzałych certyfikatów i starych wersji TLS. Treści zaszyfrowanej komunikacji analiza przepływów nie odczyta.
Czy narzędzie do analizy ruchu wystarczy do spełnienia NIS2?
Nie. Dyrektywa NIS2 w art. 21 ust. 2 wymienia m.in. obsługę incydentu i ciągłość działania, a w art. 23 ust. 4 terminy zgłoszeń: 24 godziny na wczesne ostrzeżenie, 72 godziny na zgłoszenie i miesiąc na sprawozdanie końcowe. Analiza ruchu dostarcza danych do wykrycia i opisu incydentu, ale zgodność wymaga procesu, ról i dokumentacji.
Skąd wziąć dane o przepływach, jeśli nie kupuje się sond?
Z urządzeń, które już są w sieci. Routery, przełączniki, firewalle i load balancery zwykle eksportują NetFlow, IPFIX lub sFlow, a chmury publiczne udostępniają własne logi przepływów. Trzeba jednak sprawdzić, czy eksport nie jest próbkowany, bo próbkowanie gubi krótkie połączenia, których kolektor już nie odtworzy.
