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.

NetFlow można więc szybko skonfigurować. Wiarygodny wynik wymaga jednak zrozumienia, jakie dane zawiera wersja 5, która reguła obsługuje przepływ testowy i jaką ścieżką firewall dociera 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 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

SFOS 22 eksportuje NetFlow Version 5. 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.

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. Dlatego trzeba osobno sprawdzić, czy wymagany ruch użytkowy IPv6 jest odpowiednio odwzorowany w danym środowisku; adres Collectora IPv6 nie potwierdza obsługi przepływów IPv6.

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ć inne porty od 1 do 65535, 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.

⚠️ Konfiguracja NetFlow nie oferuje opcji TLS ani uwierzytelniania. 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.

Konfiguracja Collectora NetFlow

1. W WebAdmin otworzyć System > Administration > Netflow.
2. Kliknąć Add.
3. W polu Netflow 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.

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?

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. Wygenerować z klienta testowego dokładnie jedno nowe połączenie, na przykład dozwolone wywołanie HTTPS.
4. W Log Viewer sprawdzić, czy zadziałała LAN_Test_to_WAN_HTTPS lub oczekiwana Rule ID.
5. W Diagnostics > Packet capture wyszukać eksport za pomocą dst host 192.0.2.50 and dst port 2055.
6. W Collectorze sprawdzić, czy pojawił się rekord v5 z oczekiwanymi wartościami źródłowymi i docelowymi.

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. Nie należy również oczekiwać ruchu użytkowego IPv6 wyłącznie na podstawie adresu Collectora obsługującego IPv6.

Adres źródłowy jest nieoczekiwany

Formularz NetFlow nie ma osobnego wyboru Source IP. Adres widoczny w Collectorze zależy więc od ścieżki ruchu systemowego firewalla. Przed zapisaniem stałego przypisania w Collectorze należy sprawdzić trasę, interfejs wyjściowy oraz ewentualną konfigurację SD-WAN lub Source NAT dla ruchu systemowego.

Failover HA lub zmiana firmware

Nie ma publicznej gwarancji płynnego ani pozbawionego duplikatów eksportu NetFlow w HA. Dlatego podczas normalnej pracy i po kontrolowanym failover trzeba sprawdzić, czy rekordy nadal docierają, jaki adres źródłowy jest widoczny i czy Collector nadal przypisuje go do właściwego firewalla.

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.

Często zadawane pytania