Konfiguracja i testowanie NetFlow w Sophos Firewall

Za pomocą NetFlow Sophos Firewall wysyła metadane połączeń do zewnętrznego Collectora przepływów. Pozwala to analizować w czasie relacje komunikacyjne, wolumen ruchu i nietypowe połączenia. Najważniejszy warunek łatwo przeoczyć: eksportowany jest wyłącznie ruch z reguł firewall, w których włączono Log firewall traffic.

Krótki przebieg wygląda następująco:

1. Przygotować w Collectorze listener NetFlow v5, na przykład na UDP 2055.
2. Dodać Collector w System > Administration > Netflow.
3. Włączyć Log firewall traffic w odpowiedniej regule firewall.
4. Wygenerować dokładnie udokumentowany przepływ testowy.
5. Oddzielnie sprawdzić transport za pomocą Packet Capture i zawartość w Collectorze.

Wiarygodny wynik wymaga zgodności trzech elementów: pól wersji 5, reguły firewall, która rzeczywiście zadziałała, oraz ścieżki sieciowej do Collectora.

Kiedy NetFlow jest właściwym narzędziem

NetFlow sprawdza się, gdy Collector ma przechowywać i analizować w czasie rekordy przepływów połączeń przetwarzanych przez logowane reguły. Typowe pytania brzmią: które adresy źródłowe i docelowe komunikują się ze sobą, jakie porty są używane oraz ile pakietów lub bajtów należy do przepływu?

Inne narzędzia odpowiadają na inne pytania:

• Monitorowanie sFlow pobiera próbki ruchu i liczniki wybranych interfejsów sprzętowych. Nadaje się szczególnie do analizy wzorców ruchu i planowania pojemności.
• Syslog do SIEM transportuje zdarzenia firewall, VPN, IPS i inne logi wraz z polami specyficznymi dla produktu.
• SNMP Hardware Monitoring monitoruje sprzęt, interfejsy, temperaturę, wentylatory i zasilacze.
• Central Firewall Reporting oferuje raporty, wyszukiwanie i przechowywanie danych w Sophos Fusion (dawniej Sophos Central).
• Packet Capture pozostaje dokładniejszy dla pojedynczej ścieżki pakietu, NAT lub problemu z połączeniem.

NetFlow nie zastępuje tych narzędzi. Często Collector najpierw pokazuje nietypowy przepływ, a Log Viewer lub Packet Capture wyjaśnia następnie, która reguła, decyzja NAT lub funkcja bezpieczeństwa brała udział w komunikacji.

Co pokazuje NetFlow v5, a czego nie pokazuje

Dokumentacja SFOS 22 i SFOS 23 opisuje NetFlow Version 5 oraz możliwość eksportowania wszystkich parametrów v5. Ta udokumentowana możliwość nie potwierdza, że każde pole zawiera znaczącą wartość dla każdego przepływu; trzeba to sprawdzić w rzeczywiście odebranych rekordach. Rekord v5 może zawierać między innymi następujące wartości:

• źródłowy i docelowy adres IPv4;
• port źródłowy i docelowy oraz protokół IP;
• liczniki pakietów i bajtów;
• czas rozpoczęcia i zakończenia przepływu;
• interfejs wejściowy i wyjściowy jako ifIndex;
• flagi TCP, ToS oraz informacje o AS i prefiksach.

NetFlow v5 nie zawiera natomiast natywnych pól dla nazwy użytkownika, Firewall Rule ID, adresu URL, aplikacji ani zawartości pakietu. Collector może korelować adresy IP z dodatkowymi źródłami danych, ale informacje te nie pochodzą bezpośrednio z rekordu v5.

Pomoc Sophos wskazuje również cel, jakim jest identyfikacja protokołów, polityk, interfejsów i użytkowników intensywnie wykorzystujących przepustowość. Protokoły i indeksy interfejsów można analizować na podstawie rekordów v5; przypisanie do polityki lub użytkownika wymaga dodatkowych danych z logów lub danych inwentaryzacyjnych. Sophos wymienia PRTG i Open Source Data Analyzer jako przykłady narzędzi do analizy raportów, a nie jako zamkniętą listę zgodnych rozwiązań.

Adres Collectora można wprowadzić w SFOS jako adres IPv4, adres IPv6 lub FQDN. Nie zmienia to formatu eksportu: firewall nadal wysyła NetFlow v5. Ten format nie zawiera pól dla źródłowych i docelowych adresów IPv6. Adres IPv6 Collectora dotyczy więc tylko transportu do Collectora; nie umożliwia przedstawienia ruchu użytkowego IPv6 jako natywnych przepływów IPv6.

Uwaga dotycząca API: Dokumentacja Configure Netflow dla SFOS 23 podaje dla NetflowServer typy danych IPADDRESS i DOMAIN oraz maksymalnie 255 znaków. Dokumentacja SFOS 22 wymienia dodatkowo STRING i nie określa maksymalnej długości tego pola. Jest to różnica w udokumentowanych metadanych API, a nie dowód nieograniczonej akceptacji w SFOS 22 ani odrzucania nowych kategorii wartości w SFOS 23. Nie można z niej wywnioskować walidacji w WebAdmin ani zachowania potwierdzonego testem podczas działania.

Przygotowanie Collectora i ścieżki sieciowej

Przed konfiguracją firewalla Collector musi mieć aktywny listener NetFlow v5. Sophos domyślnie używa UDP 2055; można zastosować inny prawidłowy port UDP, jeśli firewall i Collector mają identyczną konfigurację. Można zapisać maksymalnie pięć serwerów NetFlow.

W przykładzie użyto:

• Nazwa Collectora: flow-collector-primary
• Adres Collectora: 192.0.2.50
• Transport: UDP
• Port Collectora: 2055
• Reguła testowa: LAN_Test_to_WAN_HTTPS

192.0.2.50 jest zarezerwowanym adresem dokumentacyjnym i nie może być używany jako rzeczywisty Collector. W przykładzie pokazuje jedynie, którego pola dotyczy konfiguracja. Należy wpisać rzeczywisty adres IP lub FQDN Collectora, na którym działa listener v5 i do którego firewall dociera przewidzianą ścieżką sieciową. Wcześniej trzeba wyjaśnić następujące kwestie:

• Collector obsługuje NetFlow v5 i rzeczywiście nasłuchuje na UDP 2055.
• Firewall ma trasę do Collectora; przy FQDN działa również DNS.
• Urządzenia pośrednie i firewall hosta Collectora zezwalają na port UDP.
• Collector przypisuje faktycznie używany adres źródłowy do właściwego firewalla.
• Określono cel, uprawnienia dostępu i okres przechowywania danych przepływów.

Eksport NetFlow jest ruchem systemowym generowanym przez firewall. Reguła firewall dla klientów nie steruje tym eksportem. Znaczenie mają ścieżka ruchu systemowego, routing, DNS przy FQDN oraz filtry między firewallem a Collectorem.

⚠️ Sprawdzone dokumenty NetFlow nie opisują ustawień TLS ani uwierzytelniania i nie stanowią pełnego wykazu dostępnych opcji. Dane przepływów mogą ujawniać wewnętrzne adresy, partnerów komunikacji, porty, czasy i wolumeny. Collector powinien być więc dostępny przez zaufaną sieć zarządzania lub chronioną ścieżkę VPN.

Przykład: przygotowanie PRTG jako Collectora

W PRTG przepływy odbiera Probe, a nie automatycznie centralny serwer WWW. Poniższy przykład zakłada, że istnieje już lokalna lub zdalna Probe. Sensor NetFlow v5 nie obsługuje Probe w klastrze; w przypadku PRTG Hosted Monitor wymagana jest zdalna Probe.

1. Na wybranej Probe dodać sensor NetFlow v5.
2. W polu Receive Packets on UDP Port wpisać 2055.
3. W polu Receive Packets on IP Address wybrać rzeczywisty adres Probe, który zostanie wpisany w SFOS jako adres docelowy Collectora.
4. W polu Sender IP Address wpisać faktycznie zaobserwowany adres źródłowy eksportu z firewalla. Puste pole umożliwia odbieranie danych od dowolnych nadawców na tym porcie, dlatego nie jest odpowiednim trwałym zamiennikiem prawidłowego przypisania.
5. Na potrzeby pierwszego testu pozostawić pola Include Filter i Exclude Filter puste, aby żaden filtr Collectora nie ukrył przepływu referencyjnego. Na hoście Probe zezwolić na odbiór tylko od wymaganych eksporterów.

Po teście eksportu porównać Top Talkers, Top Connections i Top Protocols z zanotowanymi wartościami testowymi. Jeśli pakiety UDP docierają do hosta Probe, ale brakuje wyników analizy, najpierw sprawdzić adres odbioru, filtr nadawcy oraz filtry Include/Exclude. Status Unknown może pojawić się po upływie Active Flow Timeout (Minutes), jeśli nie napłyną nowe dane przepływów. Sam w sobie nie dowodzi błędu firewalla; nie podaje się tutaj niepotwierdzonego limitu czasu eksportu dla SFOS.

Konfiguracja Collectora NetFlow

1. W WebAdmin otworzyć System > Administration > Netflow.
2. Kliknąć Add.
3. W polu Server name wpisać flow-collector-primary.
4. W polu Netflow server IP/domain wpisać 192.0.2.50.
5. W polu Netflow server port wpisać 2055.
6. Zapisać za pomocą Save.

Można również aktualizować wpisy istniejących serwerów NetFlow. Po zmianie powtórzyć opisany poniżej kontrolowany test eksportu: oddzielnie sprawdzić dopasowanie reguły, transport UDP i dekodowanie v5.

W tym formularzu nie ma udokumentowanego testu połączenia. Zapisany wpis potwierdza więc tylko konfigurację, a nie transport ani dekodowanie w Collectorze.

Włączenie Rule Logging jako źródła danych

NetFlow eksportuje tylko połączenia z reguł firewall, w których włączono Log firewall traffic. Ustawienie sprawdza się w odpowiedniej regule pod Rules and policies > Firewall rules.

Do pierwszego testu należy użyć jednoznacznie ograniczonej reguły. W przykładzie LAN_Test_to_WAN_HTTPS obsługuje test HTTPS ze znanego klienta do dozwolonego celu. Nazwa przykładowa nie jest najważniejsza; istotne jest, aby w Log Viewer można było jednoznacznie rozpoznać regułę, która rzeczywiście przetwarza przepływ.

Prawidłowe tworzenie i logowanie reguł opisuje artykuł Bezpieczna konfiguracja reguł Sophos Firewall. W razie wątpliwości dotyczących dopasowania pomaga test reguły za pomocą Log Viewer, Policy tester i Packet Capture.

Kontrolowany test eksportu

Test rozdziela trzy pytania: czy zadziałała właściwa reguła, czy pakiet UDP opuszcza firewall i czy Collector potrafi odczytać zawartość jako NetFlow v5?

Przed rozpoczęciem wyznaczyć skończone okno obserwacji odpowiednie dla lokalnego środowiska i zanotować czas jego zakończenia. Sprawdzone źródła nie podają harmonogramu eksportu SFOS; eksport może zostać zaobserwowany z opóźnieniem po zakończeniu połączenia. W tym oknie monitorować stan przechwytywania, wykorzystanie bufora i przetwarzanie w Collectorze. Przechwytywanie w WebAdmin ma bufor 2048 KB i zatrzymuje się automatycznie po jego zapełnieniu, chyba że włączono Wrap capture buffer once full. Ta opcja pozwala kontynuować przechwytywanie, ale nadpisuje starsze pakiety. Zapisać potrzebne dowody przed ich utratą i nie traktować przedwcześnie zatrzymanego lub nadpisanego przechwytywania jako ciągłej obserwacji.

1. W Collectorze sprawdzić, czy listener v5 działa na UDP 2055.
2. Zanotować czas, klienta testowego, adres docelowy, port docelowy i oczekiwaną regułę firewall.
3. W Diagnostics > Packet capture kliknąć Configure, w polu Enter BPF string wpisać dst host 192.0.2.50 and dst port 2055, kliknąć Save i uruchomić przechwytywanie za pomocą Trace On.
4. Wygenerować z klienta jeden rozpoznawalny, ograniczony przepływ testowy, na przykład dozwolone żądanie HTTPS, i w miarę możliwości zakończyć połączenie. Zanotować czas jego zakończenia.
5. W Log Viewer sprawdzić, czy zadziałała LAN_Test_to_WAN_HTTPS lub oczekiwana Rule ID.
6. Kontynuować obserwację do ustalonego końca okna i wyszukiwać pakiety UDP do Collectora; następnie zatrzymać przechwytywanie za pomocą Trace Off.
7. W tym samym oknie sprawdzać w Collectorze, czy pojawia się rekord v5 z oczekiwanymi wartościami źródłowymi i docelowymi, oraz zapisać wynik. Brak danych w krótkim oknie nie jest rozstrzygający bez ustalonych czasów eksportu i sam w sobie nie dowodzi błędu eksportu.

Dodatkową kontrolę tylko do odczytu można przeprowadzić za pomocą krótkiego przechwytywania w Device Console:

tcpdump 'host 192.0.2.50 and port 2055'

192.0.2.50 i 2055 należy zastąpić rzeczywistym Collectorem i portem. Przechwytywanie kończy się za pomocą Ctrl+C. Widoczne pakiety UDP potwierdzają transport do obserwowanego interfejsu, ale nie potwierdzają jeszcze, że Collector dekoduje rekordy jako wersję 5.

Test kończy się powodzeniem dopiero wtedy, gdy zgadzają się dopasowanie reguły, transport UDP i dekodowanie v5. Dzięki temu wiadomo również, na którym etapie występuje błąd.

Zawężanie brakujących lub niepełnych przepływów

Brak pakietów UDP do adresu Collectora

Sprawdzić adres i port Collectora w System > Administration > Netflow. Następnie skontrolować DNS przy FQDN, trasę, interfejs wyjściowy oraz filtry na urządzeniach pośrednich. Firewall hosta Collectora również musi zezwalać na UDP 2055.

Jeśli jednocześnie zmienia się inne reguły lub ścieżki routingu, trudno później przypisać wynik do konkretnej przyczyny. Dlatego najpierw należy pracować ze znaną logowaną regułą i pojedynczym przepływem testowym.

Pakiety UDP docierają, ale Collector niczego nie pokazuje

Listener musi wyraźnie przetwarzać NetFlow v5. Wejście skonfigurowane wyłącznie dla NetFlow v9, IPFIX lub sFlow może odbierać pakiety UDP, ale mimo to nie wyświetlać użytecznych przepływów. Sprawdzić logi Collectora, parser i oczekiwany adres źródłowy.

Packet Capture potwierdza w tym przypadku jedynie transport. Pomyślne dekodowanie musi być widoczne w samym Collectorze.

Widoczna jest tylko część połączeń

Najpierw sprawdzić, która reguła firewall rzeczywiście przetwarza brakujący ruch i czy włączono w niej Log firewall traffic. Inna reguła może znajdować się wyżej i zadziałać wcześniej niż oczekiwano. Luki mogą również wynikać z utraty pakietów UDP.

NetFlow v5 ma ograniczenia techniczne. Brak nazw użytkowników, Rule IDs, adresów URL lub nazw aplikacji nie jest błędem eksportu. Format nie może też przedstawiać ruchu użytkowego IPv6 za pomocą natywnych źródłowych i docelowych adresów IPv6; adres IPv6 Collectora nie zmienia tego ograniczenia.

Adres źródłowy jest nieoczekiwany

Sprawdzone dokumenty NetFlow nie opisują osobnego ustawienia adresu źródłowego eksportu. Packet Capture ograniczony czasowo pokazuje faktycznie używany adres, gdy zaobserwowano pakiety eksportu. Należy porównać go z przypisaniem i filtrami wejściowymi Collectora; jeśli adres jest inny niż oczekiwany, sprawdzić następnie trasę i interfejs wyjściowy.

Failover HA lub zmiana firmware

Sprawdzone dokumenty nie potwierdzają gwarancji eksportu NetFlow bez przerw lub duplikatów podczas failover HA. Failover przeprowadzać wyłącznie jako zatwierdzone, zaplanowane ćwiczenie operacyjne. Przed nim, podczas normalnej pracy, i po nim użyć tego samego ograniczonego testu, aby sprawdzić odbiór rekordów, luki lub duplikaty, widoczny adres źródłowy i przypisanie do właściwego firewalla. To instrukcja weryfikacji, a nie raport z przeprowadzonego testu HA.

Po zmianach firmware, routingu, DNS, Collectora lub Rule Logging powtarza się ten sam udokumentowany test. Krótki przepływ referencyjny jest bardziej wiarygodny niż założenie, że zapisany wpis NetFlow nadal działa.

Eksploatacja i ochrona danych

Dane NetFlow, podobnie jak logi firewalla, wymagają właściciela i określonego czasu przechowywania. Eksploatacja powinna obejmować co najmniej następujące punkty:

• monitorować odbiór danych w Collectorze dla każdego firewalla i alarmować o awariach;
• dokumentować adresy źródłowe, przypisanie interfejsów i synchronizację czasu;
• ograniczyć dostęp do wewnętrznych metadanych komunikacyjnych;
• określić przechowywanie i usuwanie danych w Collectorze;
• ponownie testować po zmianach routingu, HA, firmware lub Rule Logging;
• weryfikować nietypowe przepływy za pomocą Log Viewer lub Packet Capture.

NetFlow pokazuje zależności w czasie, ale nie dowodzi przyczyny zablokowanego lub powolnego połączenia. Dla konkretnej sesji nadal decydujące są Rule ID, NAT ID, ścieżka pakietu i zaangażowane funkcje bezpieczeństwa.

Wycofanie zmiany

Aby zatrzymać eksport, usunąć odpowiedni serwer w System > Administration > Netflow. Następnie za pomocą tego samego wąskiego filtra Packet Capture potwierdzić, że pakiety UDP nie są już wysyłane do tego Collectora. Log firewall traffic należy przywrócić wyłącznie do poprzedniego stanu: wyłączenie tej opcji zatrzymuje NetFlow dla reguły, ale zapobiega też kolejnym wpisom w logu firewalla.

Często zadawane pytania