Sophos Firewall NetFlow konfigurieren und testen

Mit NetFlow sendet die Sophos Firewall Verbindungsmetadaten an einen externen Flow-Collector. Damit lassen sich Kommunikationsbeziehungen, Traffic-Volumen und auffällige Verbindungen über längere Zeit auswerten. Die wichtigste Voraussetzung wird leicht übersehen: Exportiert wird nur Traffic aus Firewall-Regeln mit aktivem Log firewall traffic.

Der kurze Weg lautet:

1. Im Collector einen NetFlow-v5-Listener vorbereiten, beispielsweise auf UDP 2055.
2. Unter System > Administration > Netflow den Collector hinzufügen.
3. Bei der betroffenen Firewall-Regel Log firewall traffic aktivieren.
4. Einen klar dokumentierten Testfluss erzeugen.
5. Transport mit Packet Capture und Inhalt im Collector getrennt prüfen.

Für ein belastbares Ergebnis müssen drei Dinge zusammenpassen: die Felder von Version 5, die tatsächlich greifende Firewall-Regel und der Netzpfad zum Collector.

Wann NetFlow das richtige Werkzeug ist

NetFlow passt, wenn ein Collector Flow-Records der von geloggten Regeln verarbeiteten Verbindungen speichern und über Zeit auswerten soll. Typische Fragen sind: Welche Quell- und Zieladressen kommunizieren miteinander, welche Ports werden verwendet und wie viele Pakete oder Bytes gehören zum Flow?

Andere Werkzeuge beantworten andere Fragen:

• sFlow Monitoring sampelt Traffic und Interface-Counter ausgewählter Hardware-Interfaces. Das eignet sich besonders für Verkehrsmuster und Kapazitätsbeobachtung.
• Syslog an ein SIEM transportiert Firewall-, VPN-, IPS- und andere Logevents mit produktspezifischen Feldern.
• SNMP Hardware Monitoring überwacht Hardware, Interfaces, Temperatur, Lüfter oder Netzteile.
• Central Firewall Reporting bietet Sophos-eigene Reports, Suche und Aufbewahrung in Sophos Fusion (ehemals Sophos Central).
• Packet Capture bleibt für einen einzelnen Paketpfad, NAT oder Verbindungsfehler genauer.

NetFlow ersetzt diese Werkzeuge nicht. Häufig zeigt der Collector einen auffälligen Flow, und Log Viewer oder Packet Capture erklären danach, welche Regel, NAT-Entscheidung oder Security-Funktion beteiligt war.

Was NetFlow v5 zeigt – und was nicht

SFOS 22 exportiert NetFlow Version 5. Ein v5-Record kann unter anderem diese Werte enthalten:

• IPv4-Quell- und Zieladresse;
• Quell- und Zielport sowie IP-Protokoll;
• Paket- und Bytezähler;
• Start- und Endzeit des Flows;
• Eingangs- und Ausgangs-Interface als ifIndex;
• TCP-Flags, ToS sowie AS- und Präfixinformationen.

NetFlow v5 enthält dagegen keine nativen Felder für Benutzername, Firewall Rule ID, URL, Anwendung oder Paketinhalt. Ein Collector kann IP-Adressen mit zusätzlichen Datenquellen korrelieren, aber diese Informationen stammen nicht direkt aus dem v5-Record.

Die Collector-Adresse darf in SFOS als IPv4-Adresse, IPv6-Adresse oder FQDN eingetragen werden. Das ändert das Exportformat nicht: Die Firewall sendet weiterhin NetFlow v5. Dieses Format besitzt keine Felder für IPv6-Quell- und Zieladressen. Eine IPv6-Collector-Adresse betrifft daher nur den Transport zum Collector; sie macht IPv6-Nutztraffic nicht als native IPv6-Flows darstellbar.

API-Hinweis: Die Referenz Configure Netflow für SFOS 23 dokumentiert für NetflowServer die Datentypen IPADDRESS und DOMAIN sowie maximal 255 Zeichen. Die SFOS-22-Referenz führt zusätzlich STRING auf und nennt für dieses Feld keine maximale Länge. Das ist ein Unterschied in den dokumentierten API-Metadaten, kein Nachweis für unbegrenzte Annahme in SFOS 22 oder neu abgewiesene Werte in SFOS 23. Daraus lassen sich weder eine WebAdmin-Prüfung noch getestetes Laufzeitverhalten ableiten.

Collector und Netzpfad vorbereiten

Vor der Firewall-Konfiguration benötigt der Collector einen aktiven NetFlow-v5-Listener. Sophos verwendet standardmässig UDP 2055; ein anderer gültiger UDP-Port ist möglich, wenn Firewall und Collector identisch konfiguriert werden. Bis zu fünf NetFlow-Server lassen sich hinterlegen.

Für das Beispiel gelten:

• Collector-Name: flow-collector-primary
• Collector-Adresse: 192.0.2.50
• Transport: UDP
• Collector-Port: 2055
• Testregel: LAN_Test_to_WAN_HTTPS

192.0.2.50 ist eine reservierte Dokumentationsadresse und kann nicht als echter Collector verwendet werden. Sie zeigt im Beispiel nur, welches Feld gemeint ist. Eingetragen wird die reale IP-Adresse oder der FQDN des Collectors, auf dem der v5-Listener läuft und den die Firewall über den vorgesehenen Netzpfad erreicht. Vorher sollten diese Punkte geklärt sein:

• Der Collector unterstützt NetFlow v5 und lauscht wirklich auf UDP 2055.
• Die Firewall hat eine Route zum Collector; bei einem FQDN funktioniert zusätzlich DNS.
• Zwischenkomponenten und die Host-Firewall des Collectors erlauben den UDP-Port.
• Der Collector ordnet die tatsächlich verwendete Quelladresse der richtigen Firewall zu.
• Zweck, Zugriffsrechte und Aufbewahrungsdauer der Flow-Daten sind festgelegt.

Der NetFlow-Export ist von der Firewall erzeugter Systemverkehr. Eine Client-Firewall-Regel steuert diesen Export nicht. Relevant sind der Systemtraffic-Pfad, Routing, DNS bei einem FQDN und Filter zwischen Firewall und Collector.

⚠️ Die NetFlow-Konfiguration bietet keine TLS- oder Authentifizierungsoption. Flow-Daten können interne Adressen, Kommunikationspartner, Ports, Zeiten und Volumen offenlegen. Der Collector sollte deshalb über ein vertrauenswürdiges Managementnetz oder einen geschützten VPN-Pfad erreichbar sein.

NetFlow-Collector konfigurieren

1. Im WebAdmin System > Administration > Netflow öffnen.
2. Auf Add klicken.
3. Unter Server name flow-collector-primary eintragen.
4. Unter Netflow server IP/domain 192.0.2.50 eintragen.
5. Unter Netflow server port 2055 eintragen.
6. Mit Save speichern.

Bestehende NetFlow-Servereinträge lassen sich ebenfalls aktualisieren. Nach einer Änderung wird der unten beschriebene kontrollierte Exporttest wiederholt: Regel-Match, UDP-Transport und v5-Decoding werden getrennt geprüft.

In der Maske gibt es keinen dokumentierten Verbindungstest. Ein gespeicherter Eintrag bestätigt deshalb nur die Konfiguration, nicht den Transport oder das Decoding im Collector.

Rule Logging als Datenquelle aktivieren

NetFlow exportiert nur Verbindungen aus Firewall-Regeln, bei denen Log firewall traffic aktiv ist. Die Einstellung wird unter Rules and policies > Firewall rules in der passenden Regel geprüft.

Für den ersten Test sollte eine klar eingegrenzte Regel verwendet werden. Im Beispiel verarbeitet LAN_Test_to_WAN_HTTPS einen HTTPS-Test von einem bekannten Client zu einem freigegebenen Ziel. Wichtig ist nicht der Beispielname, sondern dass der Admin im Log Viewer zweifelsfrei erkennt, welche Regel den Flow tatsächlich verarbeitet.

Wie eine Regel sauber aufgebaut und protokolliert wird, erklärt Sophos Firewall-Regeln richtig erstellen. Bei Unsicherheit über den Match hilft Regel testen mit Log Viewer, Policy tester und Packet Capture.

Export kontrolliert testen

Der Test trennt drei Fragen: Hat die richtige Regel gegriffen, verlässt ein UDP-Paket die Firewall und kann der Collector den Inhalt als NetFlow v5 lesen?

1. Im Collector prüfen, ob der v5-Listener auf UDP 2055 läuft.
2. Zeitpunkt, Testclient, Zieladresse, Zielport und erwartete Firewall-Regel notieren.
3. Unter Diagnostics > Packet capture auf Configure klicken, unter Enter BPF string dst host 192.0.2.50 and dst port 2055 eintragen, mit Save speichern und die Aufzeichnung mit Trace On starten.
4. Vom Testclient genau eine neue Verbindung erzeugen, beispielsweise einen erlaubten HTTPS-Aufruf.
5. Im Log Viewer prüfen, ob LAN_Test_to_WAN_HTTPS beziehungsweise die erwartete Rule ID gegriffen hat.
6. Die Aufzeichnung mit Trace Off beenden und im Capture nach UDP-Paketen zum Collector suchen.
7. Im Collector prüfen, ob ein v5-Record mit den erwarteten Quell- und Zielwerten erscheint.

Für eine zusätzliche lesende Kontrolle kann in der Device Console ein kurzer Capture laufen:

tcpdump 'host 192.0.2.50 and port 2055'

192.0.2.50 und 2055 werden durch den echten Collector und Port ersetzt. Mit Ctrl+C wird der Capture beendet. Sichtbare UDP-Pakete bestätigen den Transport bis zum beobachteten Interface, aber noch nicht, dass der Collector die Records als Version 5 dekodiert.

Ein erfolgreicher Test ist erst vollständig, wenn Regel-Match, UDP-Transport und v5-Decoding zusammenpassen. So bleibt auch nachvollziehbar, an welcher Stelle ein Fehler liegt.

Fehlende oder unvollständige Flows eingrenzen

Keine UDP-Pakete zur Collector-Adresse

Collector-Adresse und Port in System > Administration > Netflow prüfen. Danach DNS bei FQDN, Route, ausgehendes Interface sowie Filter auf Zwischenkomponenten kontrollieren. Auch die Host-Firewall des Collectors muss UDP 2055 annehmen.

Wenn andere Regeln oder Routingpfade gleichzeitig geändert werden, lässt sich das Ergebnis kaum noch zuordnen. Deshalb zuerst mit einer bekannten geloggten Regel und einem einzelnen Testfluss arbeiten.

UDP-Pakete kommen an, aber der Collector zeigt nichts

Der Listener muss ausdrücklich NetFlow v5 verarbeiten. Ein nur für NetFlow v9, IPFIX oder sFlow eingerichteter Eingang kann die UDP-Pakete empfangen und trotzdem keine brauchbaren Flows anzeigen. Collector-Logs, Parser und erwartete Quelladresse prüfen.

Packet Capture beweist in diesem Fall nur den Transport. Die erfolgreiche Decodierung muss im Collector selbst sichtbar sein.

Nur ein Teil der Verbindungen ist sichtbar

Zuerst kontrollieren, welche Firewall-Regel den fehlenden Traffic tatsächlich verarbeitet und ob dort Log firewall traffic aktiv ist. Eine andere Regel kann weiter oben greifen als erwartet. Ausserdem kann UDP-Paketverlust Lücken verursachen.

NetFlow v5 hat technische Grenzen. Fehlende Benutzernamen, Rule IDs, URLs oder Anwendungsnamen sind kein Exportfehler. IPv6-Nutztraffic lässt sich in diesem Format zudem nicht mit nativen IPv6-Quell- und Zieladressen darstellen; eine IPv6-fähige Collector-Adresse ändert daran nichts.

Die Quelladresse ist unerwartet

Die NetFlow-Maske besitzt keinen eigenen Source-IP-Wähler. Ein kurzer Packet Capture zeigt, mit welcher Quelladresse die Firewall tatsächlich exportiert. Diese Adresse mit der Zuordnung und den Eingangsfiltern des Collectors abgleichen; bei einer Abweichung danach Route und ausgehendes Interface prüfen.

HA-Failover oder Firmwarewechsel

Für NetFlow ist kein nahtloser oder duplikatfreier HA-Export öffentlich zugesichert. Deshalb im Normalbetrieb und nach einem kontrollierten Failover prüfen, ob Records weiter ankommen, welche Quelladresse sichtbar ist und ob der Collector sie weiterhin der richtigen Firewall zuordnet.

Nach Firmware-, Routing-, DNS-, Collector- oder Regeländerungen wird derselbe dokumentierte Test wiederholt. Ein kurzer Referenzfluss ist zuverlässiger als die Annahme, dass ein gespeicherter NetFlow-Eintrag weiterhin funktioniert.

Betrieb und Datenschutz

NetFlow-Daten brauchen wie Firewall-Logs einen Owner und eine definierte Aufbewahrung. Der Betrieb sollte mindestens diese Punkte abdecken:

• Collector-Empfang pro Firewall überwachen und Ausfälle alarmieren;
• Quelladressen, Interface-Zuordnung und Zeitsynchronisation dokumentieren;
• Zugriff auf interne Kommunikationsmetadaten begrenzen;
• Aufbewahrung und Löschung im Collector festlegen;
• nach Routing-, HA-, Firmware- oder Rule-Logging-Änderungen erneut testen;
• auffällige Flows mit Log Viewer oder Packet Capture verifizieren.

NetFlow zeigt Zusammenhänge über Zeit, ist aber kein Beweis für die Ursache einer blockierten oder langsamen Verbindung. Für eine konkrete Session bleiben Rule ID, NAT ID, Paketpfad und beteiligte Security-Funktionen entscheidend.

Änderung zurücknehmen

Soll der Export beendet werden, wird der betreffende Server unter System > Administration > Netflow gelöscht. Anschliessend mit demselben engen Packet-Capture-Filter prüfen, dass keine UDP-Pakete mehr an diesen Collector gehen. Log firewall traffic sollte nur auf seinen früheren Zustand zurückgesetzt werden: Das Deaktivieren beendet nicht nur NetFlow für diese Regel, sondern verhindert auch weitere Einträge im Firewall-Log.

Häufige Fragen