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.

NetFlow ist damit schnell eingerichtet. Für ein verlässliches Ergebnis muss aber klar sein, welche Daten Version 5 enthält, welche Regel den Testfluss verarbeitet und über welchen Pfad die Firewall den Collector erreicht.

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 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. Ob der benötigte IPv6-Nutztraffic im eingesetzten Aufbau sinnvoll abgebildet wird, muss deshalb separat geprüft werden; aus einer IPv6-Collector-Adresse folgt keine bestätigte IPv6-Flow-Unterstützung.

Collector und Netzpfad vorbereiten

Vor der Firewall-Konfiguration benötigt der Collector einen aktiven NetFlow-v5-Listener. Sophos verwendet standardmässig UDP 2055; andere Ports zwischen 1 und 65535 sind 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 Netflow 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.

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. Vom Testclient genau eine neue Verbindung erzeugen, beispielsweise einen erlaubten HTTPS-Aufruf.
4. Im Log Viewer prüfen, ob LAN_Test_to_WAN_HTTPS beziehungsweise die erwartete Rule ID gegriffen hat.
5. Unter Diagnostics > Packet capture mit dst host 192.0.2.50 and dst port 2055 nach dem Export suchen.
6. 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. Auch IPv6-Nutztraffic darf nicht allein aufgrund einer IPv6-fähigen Collector-Adresse erwartet werden.

Die Quelladresse ist unerwartet

Die NetFlow-Maske besitzt keinen eigenen Source-IP-Wähler. Welche Adresse der Collector sieht, hängt deshalb vom Systemtraffic-Pfad der Firewall ab. Route, ausgehendes Interface und gegebenenfalls vorhandene SD-WAN- oder Source-NAT-Konfiguration für Systemverkehr prüfen, bevor am Collector eine feste Zuordnung hinterlegt wird.

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.

Häufige Fragen