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. Sophos hat sFlow mit Sophos Firewall v22 als Monitoring-Funktion ergänzt.

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.

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 der normalen WebAdmin-Oberfläche, sondern über die Device Console mit system sflow. Die Advanced Shell ist dafür nicht der richtige Ort. Die Unterscheidung zwischen Device Console und Advanced Shell ist im Artikel Sophos Firewall Troubleshooting: Services und Logs erklärt.

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.

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 mit system sflow monitor delete interface-name ... aus der Überwachung nehmen, danach erneut messen.

sFlow Collector hinzufügen

Zuerst wird der Collector definiert. Der Standardport für sFlow ist häufig 6343; in produktiven Umgebungen muss der Port zum eingesetzten Collector 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

Interface und Sampling Rate konfigurieren

Danach wird festgelegt, welches Interface überwacht wird und mit welcher Sampling Rate Pakete ausgewählt werden.

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. 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:

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, Routing und Firewall-Regeln zum Collector passen. Zusätzlich sollte man auf dem Collector prüfen, ob der UDP-Port erreichbar ist und ob eingehende sFlow-Pakete verworfen werden.

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