sFlow Monitoring auf Sophos Firewall konfigurieren

Mit sFlow Monitoring kann eine Sophos Firewall Traffic-Samples an einen externen Collector senden. Dadurch sieht man Volumenspitzen, auffällige Flows, ungewöhnliche Ziele oder Lastverteilung über Interfaces besser als nur mit einzelnen Live-Logs. Die Funktion steht in Sophos Firewall v22 zur Verfügung.

Die Funktion ist vor allem für Troubleshooting, Kapazitätsplanung und Security Monitoring interessant. sFlow ersetzt aber weder den Log viewer noch Packet Capture oder eine saubere Logaufbewahrung über Central Firewall Reporting beziehungsweise Syslog. sFlow beantwortet andere Fragen: nicht “welche Regel hat exakt gegriffen?”, sondern “welche Verkehrsflüsse laufen über dieses Interface und wie verteilen sie sich?”. Für Hardwarezustand, Temperatur, Lüfter, Netzteile und PoE passt dagegen SNMP Hardware Monitoring.

Wenn statt Interface-Samples NetFlow-v5-Records aus gezielt geloggten Firewall-Regeln benötigt werden, passt NetFlow auf Sophos Firewall konfigurieren und testen besser. Soll ein Switch dagegen einen gespiegelten Paketstrom passiv an die Firewall liefern, ist Discover Mode mit TAP und SPAN das passende, klar abgegrenzte Modell.

Wann sFlow sinnvoll ist

sFlow ist sinnvoll, wenn ein externer Collector oder ein Monitoring-System vorhanden ist und Traffic-Muster über Zeit sichtbar werden sollen.

Typische Anwendungsfälle:

• Unerwartete Bandbreitenspitzen auf WAN-, LAN- oder Core-Interfaces erkennen.
• Traffic zwischen VLANs oder Standorten besser einordnen.
• Kapazitätsplanung für Firewall, Uplink oder Core-Switching unterstützen.
• Verdächtige Flows als Ausgangspunkt für weitere Analyse finden.
• Monitoring-Daten mit Firewall Logs, Central Reporting oder SIEM-Daten vergleichen.

Wenn nur eine einzelne Verbindung geprüft werden soll, ist sFlow oft nicht das richtige Werkzeug. Für gezielte Performance-Tests passt eher iPerf. Für konkrete Verbindungsprobleme sind Log Viewer, Policy Test und Packet Capture meistens schneller.

Voraussetzungen

Für sFlow benötigt man:

• Sophos Firewall mit SFOS 22.0 oder neuer.
• Administrativen Zugriff auf die Device Console.
• Einen erreichbaren sFlow Collector, zum Beispiel ein NMS, SIEM oder Flow-Analyse-Tool.
• Ein sicheres Netz zwischen Firewall und Collector.
• Eine klare Entscheidung, welche Hardware-Interfaces überwacht werden sollen.

Die Konfiguration erfolgt nicht in einer WebAdmin-Seite, sondern über die Device Console mit system sflow. In WebAdmin öffnet man unter SFOS 22 rechts oben das Benutzernamen-Menü (zum Beispiel admin) und wählt Console; unter SFOS 23 öffnet man dort das Kontosymbol Account icon und wählt Command line. Danach wählt man in beiden Versionen 4. Device Console. Die Advanced Shell ist dafür nicht der richtige Ort. Die Unterscheidung erklärt der Artikel Sophos Firewall Troubleshooting: Services und Logs.

Wer stattdessen einen SSH-Client verwendet, muss den Zugriff unter Administration > Device access > Local service ACL für SSH aus der benötigten Quellzone erlauben und mit Apply speichern. Eine Zone sollte dafür nicht pauschal geöffnet werden: Wenn nur bestimmte Management-Hosts zugreifen sollen, ist eine Local service ACL exception rule die engere Wahl. Bestehenden Konsolen- oder SSH-Zugriff prüft man vor der sFlow-Änderung, nicht erst für den Rollback.

Minimaler Ablauf

Die eigentliche Konfiguration ist kurz. Wichtig ist vor allem, dass man zuerst den Monitoring-Pfad plant und erst danach sFlow aktiviert:

1. Collector, Port und Netzpfad festlegen.
2. Ein Hardware-Interface für den ersten Pilot auswählen.
3. Vorab mit system sflow show prüfen, ob bereits alte Collector oder Monitor-Interfaces hinterlegt sind.
4. Sampling Rate und optional Polling Interval konfigurieren.
5. Mit system sflow show prüfen, ob Collector und Interface korrekt hinterlegt sind.
6. sFlow mit system sflow on aktivieren.
7. Im Collector kontrollieren, ob Daten von der erwarteten Firewall-Agent-IP ankommen.

Die folgenden Abschnitte erklären die einzelnen Schritte und die betrieblichen Grenzen.

Wichtige Grenzen vor der Aktivierung

sFlow wirkt harmlos, kann aber Auswirkungen auf Betrieb und Sicherheit haben.

sFlow ist nicht verschlüsselt

Der sFlow-Traffic von der Firewall zum Collector ist nicht verschlüsselt. Deshalb sollte der Collector über ein vertrauenswürdiges Management-Netz, ein internes Monitoring-Netz oder einen anderweitig geschützten Pfad erreichbar sein.

⚠️ sFlow sollte nicht ungeschützt über unsichere Netze gesendet werden. Flow-Daten können interne IP-Adressen, Kommunikationsbeziehungen und Zielsysteme sichtbar machen.

FastPath wird auf dem überwachten Interface deaktiviert

Wenn sFlow auf einem Interface aktiv ist, wird Fast Path auf diesem Interface deaktiviert. Das ist besonders wichtig bei stark ausgelasteten WAN-, LAN- oder Core-Interfaces.

Vor der Aktivierung sollte man prüfen:

• Wie stark ist das Interface ausgelastet?
• Läuft darüber produktiver High-Throughput-Traffic?
• Gibt es ein Wartungsfenster für den ersten Test?
• Kann man Performance vor und nach der Aktivierung vergleichen?

Für die grundsätzliche Einordnung von Firewall-Leistung passt der Artikel Leistungsdaten der Sophos Firewall richtig verstehen.

HA-Cluster: sFlow läuft nur auf der Primary

In einem HA-Cluster läuft der sFlow-Agent auf der Primary. Das muss man bei Auswertungen und Failover-Tests berücksichtigen. Nach einem Rollenwechsel sollte geprüft werden, ob der Collector weiterhin Daten erhält und ob die Agent-IP wie erwartet bleibt.

Für die Planung von HA-Betrieb und Monitoring passt Sophos Firewall High Availability einrichten.

Interface und Collector planen

sFlow wird auf Hardware-Interfaces konfiguriert. Dabei können auch abhängige Interfaces wie Aliases und VLANs des gewählten Hardware-Interfaces in den Samples sichtbar werden. Die Interface-Auswahl sollte deshalb immer zum tatsächlichen Traffic-Pfad passen, nicht nur zum Namen des VLANs oder zur gewünschten Auswertung im Collector.

In SFOS 22 verwendet der Agent eine IP-Adresse eines Hardware-Interfaces. In SFOS 23 ist dies die automatische Auswahl, wenn keine Agent-IP mit agent-ip konfiguriert ist. Die SFOS-22-Hilfe legt jedoch nicht fest, welche Adresse bei mehreren geeigneten Hardware-Interfaces ausgewählt wird. Deshalb sollte man keine bestimmte Agent-IP allein aus Routing oder Interface-Namen ableiten. Nach dem Einschalten liest man die tatsächlich eintreffende Agent-IP am Collector ab und dokumentiert sie; eine Collector-Allowlist muss diese Beobachtung berücksichtigen.

Das ist praktisch, kann aber zu Fehlinterpretationen führen:

• Wenn Port1 überwacht wird, können auch zugehörige VLAN- oder Alias-Interfaces im Sampling sichtbar werden.
• Wenn nur ein bestimmtes VLAN interessiert, muss im Collector sauber gefiltert werden.
• Wenn mehrere Core- oder WAN-Ports existieren, sollte man nicht sofort alle Interfaces aktivieren.
• Bei LAG-, Bridge- oder VLAN-Designs sollte vorher klar sein, wo der relevante Traffic wirklich fliesst.

Die saubere Grundlage dafür ist eine verständliche Interface- und Zonenplanung. Der Artikel Sophos Firewall Zonen und Interfaces konfigurieren hilft bei der Einordnung von physischen Interfaces, VLANs, Bridges, LAGs und RED.

Pilot, Datenschutz und Rückweg planen

Vor der ersten Aktivierung sollte sFlow wie eine produktive Monitoring-Änderung behandelt werden. Die Funktion erzeugt zusätzliche Daten, verändert FastPath auf dem überwachten Interface und sendet Flow-Informationen an ein anderes System. Deshalb reicht es nicht, nur Collector-IP und Sampling Rate einzutragen.

Vor dem Pilot sollten diese Punkte feststehen:

• Welches konkrete Problem soll sFlow lösen: Kapazitätsplanung, Bandbreitenspitzen, Security Monitoring oder Fehlersuche?
• Wer betreibt den Collector und wer darf die Flow-Daten sehen?
• Wie lange werden Flow-Daten gespeichert?
• Über welchen Netzpfad erreichen die sFlow-Pakete den Collector?
• Welches Interface wird zuerst getestet?
• Welche Messwerte gelten vor der Aktivierung als Baseline?
• Wann wird sFlow wieder deaktiviert oder auf ein anderes Interface verschoben?

Flow-Daten können interne IP-Adressen, Kommunikationsbeziehungen, Zielsysteme, Ports und Traffic-Volumen sichtbar machen. Diese Daten sind damit weniger detailliert als ein vollständiger Packet Capture, aber trotzdem betriebs- und sicherheitsrelevant. Wenn der Collector an ein SIEM oder eine zentrale Monitoring-Plattform angebunden wird, sollte die Verantwortlichkeit ähnlich sauber geklärt sein wie bei Sophos Firewall Syslog an SIEM senden.

Für den ersten Test ist ein begrenzter Pilot sinnvoll:

1. Ausgangszustand dokumentieren: Interface-Last, CPU-Last, betroffene Dienste, vorhandene Monitoring-Daten.
2. Ein einzelnes, nicht maximal ausgelastetes Interface auswählen.
3. Sampling Rate konservativ setzen.
4. Collector-Empfang und Datenmenge prüfen.
5. Performance, Latenz und Durchsatz nach der Aktivierung beobachten.
6. Rückweg testen: system sflow off oder das Monitoring-Interface wieder entfernen.

Der Rückweg sollte vor der Aktivierung klar sein. Wenn die Performance auf einem produktiven Interface schlechter wird, sollte man nicht gleichzeitig Sampling Rate, Collector, Routing und Firewall-Regeln ändern. Zuerst sFlow deaktivieren oder das betroffene Interface aus der Überwachung nehmen, danach erneut messen.

Für einen erstmaligen Piloten mit den Beispieldaten ohne Änderung der Agent-Identität lautet der Rückweg wie folgt. Dieser Block setzt keine mit agent-ip konfigurierte Identität zurück; die Einschränkung beim optionalen SFOS-23-Schritt bleibt bestehen:

system sflow off
system sflow monitor delete interface-name Port1
system sflow collector delete ip-address 192.0.2.10 port 6343
system sflow polling-interval 60
system sflow show

Damit werden nur die im Beispiel neu angelegten Einträge entfernt und das Polling Interval auf den dokumentierten Default von 60 Sekunden zurückgesetzt. War sFlow vorher bereits konfiguriert, ist dieser Block kein pauschaler Rollback: Dann entfernt man nur die eigenen Ergänzungen, stellt das zuvor mit system sflow show dokumentierte Polling Interval und den früheren Ein-/Aus-Status wieder her und kontrolliert den Endzustand erneut mit system sflow show. Wurde SSH nur für diesen Pilot freigeschaltet, stellt man anschliessend auch die zuvor dokumentierte Local Service ACL beziehungsweise Exception Rule wieder her, ohne anderen Management-Zugriff zu entfernen.

sFlow Collector hinzufügen

Zuerst wird der Collector definiert. Wenn kein anderer Port geplant ist, verwendet sFlow typischerweise 6343. Sophos erlaubt Portwerte von 1 bis 65535; der dokumentierte Default ist 6343. In produktiven Umgebungen muss der Port trotzdem zum eingesetzten Collector und zu den Firewallregeln auf dem Weg dorthin passen.

Beispiel:

system sflow collector add ip-address 192.0.2.10 port 6343

Sophos unterstützt bis zu fünf Collector. Jeder Collector wird separat hinzugefügt.

Den aktuellen Status kann man danach prüfen:

system sflow show

Wenn ein Collector wieder entfernt werden soll:

system sflow collector delete ip-address 192.0.2.10 port 6343

Optional: Agent-Identität in SFOS 23 festlegen

Dieser Schritt gilt nur für SFOS 23; unter SFOS 22 bleibt der bisherige Ablauf unverändert. Mit agent-ip kann man eine gültige Unicast-IP als sFlow-Identität der Firewall im Collector festlegen. Pro Firewall ist nur eine konfigurierte Agent-IP möglich. Sie ist nicht die Zieladresse des Collectors. Ohne konfigurierte Identität verwendet SFOS 23 automatisch eine Hardware-Interface-IP.

⚠️ Vor der Änderung den Ausgangszustand mit system sflow show sichern, einschliesslich einer bereits vorhandenen Agent-IP. Eine andere Identität kann die Zuordnung und Identitätsfilter im Collector verändern. Eine bestehende Identität nicht blind ersetzen; zuerst das Vorgehen für die installierte Version klären. Die SFOS-23-Beschreibung widerspricht sich beim Löschen: Die Syntaxübersicht verlangt eine IP-Adresse, Detailbeschreibung und Beispiel lassen sie weg. Deshalb wird hier kein Löschbefehl und kein vollständiger Rückweg für eine neu gesetzte Identität angegeben. Wenn eine verlässliche Rückkehr zur automatischen Identität erforderlich ist, diesen optionalen Schritt auslassen, bis die Löschsyntax für die installierte Version verbindlich geklärt ist. system sflow off beendet den Export, stellt aber keinen Nachweis für die Wiederherstellung der früheren Identität dar.

Nur nach diesem Preflight und ohne vorhandene konfigurierte Identität kann man in der Device Console beispielsweise Folgendes verwenden:

system sflow show
system sflow agent-ip add 192.0.2.20
system sflow show

192.0.2.20 ist ein Dokumentationswert: Man ersetzt ihn durch eine gültige Unicast-IP, mit der die eigene Firewall im Collector eindeutig zugeordnet werden soll. 192.0.2.10 bleibt im Beispiel das separate Collector-Ziel. Die Agent-Identität garantiert weder die UDP-Quelladresse noch Routing, Interface-Zuweisung oder Transport-ACL-Verhalten; den Netzpfad prüft man separat.

Nach der Änderung die Konfiguration kontrollieren und nach der Aktivierung die vom Collector tatsächlich aus den sFlow-Daten dekodierte Agent-IP mit dem geplanten Wert vergleichen. Identitätsfilter erst anhand dieser Beobachtung anpassen. Bei Abweichungen zuerst Konfiguration und Collector-Dekodierung prüfen, nicht weitere Identitätsänderungen raten. Auch nach HA-Failover Empfang und Zuordnung erneut prüfen; eine stabile Identität über den Rollenwechsel wird nicht zugesichert.

Interface und Sampling Rate konfigurieren

Danach wird festgelegt, welches Interface überwacht wird und mit welcher Sampling Rate Pakete ausgewählt werden. In SFOS 22 verwendet der sFlow-Agent eine Hardware-Interface-IP; in SFOS 23 gilt dies nur ohne konfigurierte agent-ip. Im Collector kann deshalb eine Hardware-Interface-IP auftauchen, auch wenn die eigentliche Auswertung ein VLAN oder Alias unterhalb dieses Ports betrifft.

Beispiel:

system sflow monitor add interface-name Port1 sampling-rate 1000

Die Sampling Rate entscheidet, wie häufig Pakete als Sample ausgewählt werden. Eine niedrigere Zahl erzeugt mehr Samples und damit mehr Details, aber auch mehr Last und mehr Daten am Collector. Eine höhere Zahl reduziert die Datenmenge, kann aber kurze oder kleinere Flows weniger sichtbar machen.

Die relevanten Grenzwerte sind:

Für den Start ist ein konservativer Wert sinnvoll, zum Beispiel 1000 oder höher. Danach sollte man im Collector prüfen, ob die Datenmenge, Detailtiefe und Performance zum Ziel passen.

Ein Monitoring-Interface kann wieder entfernt werden:

system sflow monitor delete interface-name Port1

Polling Interval einstellen

Neben Packet Sampling kann sFlow auch Statistiken und Interface Counter in einem Intervall abfragen. Sophos erlaubt ein Polling Interval zwischen 30 und 300 Sekunden, der Default ist 60 Sekunden. Mit 0 wird Polling deaktiviert.

Beispiel:

system sflow polling-interval 80

Polling deaktivieren:

system sflow polling-interval 0

Für die meisten Umgebungen ist ein mittleres Intervall sinnvoll. Zu kurze Intervalle erzeugen mehr Daten und sind nicht automatisch hilfreicher.

sFlow aktivieren

Wenn Collector, Interface und Polling geplant sind, wird sFlow aktiviert. Standardmässig ist sFlow ausgeschaltet:

system sflow on

Den Status prüfen:

system sflow show

sFlow deaktivieren:

system sflow off

Nach der Aktivierung sollte man nicht nur die Firewall prüfen, sondern auch den Collector. Dort müssen Daten von der Firewall-Agent-IP ankommen und sinnvoll aufgelöst werden.

Validierung nach der Aktivierung

Nach dem Einschalten sollte man diese Punkte prüfen:

1. system sflow show zeigt Collector, Interface, Sampling Rate und Status korrekt an.
2. Der Collector empfängt sFlow-Daten von der erwarteten Firewall-IP.
3. Die Zeit auf Firewall und Collector stimmt.
4. Interface-Namen und Flow-Richtung sind im Collector nachvollziehbar.
5. Die Last auf Firewall und Collector bleibt unkritisch.
6. Die Datenmenge passt zur geplanten Aufbewahrung und Verarbeitung.
7. Der definierte Rückweg wurde einmal getestet oder zumindest als konkreter Befehl dokumentiert.
8. Bei HA-Clustern wird nach einem Failover geprüft, ob weiterhin Daten ankommen.

Wenn parallel Firewall-Regeln, NAT, VPN oder TLS Inspection analysiert werden, sollte sFlow nicht isoliert betrachtet werden. Für konkrete Verbindungsentscheidungen bleiben Log Viewer und Packet Capture entscheidend. Für längerfristige Auswertung sollte man prüfen, ob zusätzlich Syslog oder Central Reporting benötigt wird.

Troubleshooting

Kein Traffic im Collector

Zuerst system sflow show prüfen. Danach kontrollieren, ob Collector-IP, Port und der Netzpfad zum Collector passen. Auf dem Collector prüft man, ob eingehende sFlow-Pakete verworfen werden und ob nach einer falschen Agent-IP gefiltert wird. Bei mehreren Hardware-Interface-IPs darf man die Agent-IP nicht vorab erraten.

Nur ein Teil des Traffics ist sichtbar

sFlow arbeitet mit Sampling. Es ist normal, dass nicht jedes einzelne Paket sichtbar ist. Wenn wichtige Flows fehlen, kann die Sampling Rate angepasst oder ein anderes Interface gewählt werden. Bei VLANs und Aliases sollte man prüfen, ob das richtige Hardware-Interface überwacht wird.

Performance verändert sich nach Aktivierung

Wenn ein stark genutztes Interface überwacht wird, kann die Deaktivierung von FastPath relevant sein. In diesem Fall sollte sFlow testweise deaktiviert und die Performance verglichen werden. Bei produktiven Core- oder WAN-Interfaces ist ein geplanter Test besser als eine spontane Aktivierung.

HA-Daten wirken unvollständig

In HA-Umgebungen läuft der sFlow-Agent auf der Primary. Nach einem Failover sollte geprüft werden, welche Firewall gerade Primary ist, welche IP als Agent-IP verwendet wird und ob der Collector die Daten weiterhin korrekt zuordnet.

Betriebscheckliste

• Collector im sicheren Netz platzieren.
• Eigentümer, Zweck, Zugriff und Aufbewahrung der Flow-Daten dokumentieren.
• UDP-Port und Routing zum Collector prüfen.
• Mit einem oder wenigen Interfaces starten.
• Vorher-Nachher-Baseline für Interface-Last, CPU, Latenz und Durchsatz erfassen.
• Sampling Rate konservativ wählen und danach anpassen.
• FastPath-Auswirkung bei kritischen Interfaces berücksichtigen.
• Rückweg dokumentieren: system sflow off oder Monitoring-Interface entfernen.
• HA-Failover testen, wenn sFlow im Cluster genutzt wird.
• Flow-Daten mit Log Viewer, Packet Capture und Reporting abgleichen.
• Regelmässig prüfen, ob die Daten noch ausgewertet werden oder nur ungenutzt gesammelt werden.

FAQ