Sophos Firewall SNMP Hardware Monitoring einrichten

Mit SNMP Hardware Monitoring kann man den Zustand einer Sophos Firewall besser in ein vorhandenes Monitoring-System einbinden. Neben klassischen Erreichbarkeits- und Interface-Werten sind seit Sophos Firewall v22 zusätzliche Hardwaremetriken über die MIB verfügbar. Dazu gehören je nach Modell CPU-Temperatur, NPU-Temperatur, Lüfter, Netzteilstatus und PoE-Werte.

Das ist besonders für produktive XGS-Installationen interessant. Eine Firewall kann zwar im WebAdmin noch erreichbar sein, aber trotzdem Anzeichen für thermische Probleme, defekte Lüfter, ein ausgefallenes Netzteil oder unerwartete PoE-Last zeigen. Solche Zustände sollten nicht erst beim nächsten manuellen Login auffallen.

Wann SNMP auf der Firewall sinnvoll ist

SNMP ist sinnvoll, wenn bereits ein Monitoring-System betrieben wird und die Firewall dort als Infrastrukturkomponente überwacht werden soll.

Typische Anwendungsfälle:

• Hardwarezustand von XGS-Appliances überwachen.
• CPU- und NPU-Temperatur über Zeit beobachten.
• Lüfter- und Netzteilstatus in ein NOC oder MSP-Monitoring aufnehmen.
• PoE-Last bei XGS-Modellen mit PoE-Ports kontrollieren.
• Interface-Werte mit Switch-, Router- und Provider-Monitoring vergleichen.
• Alarme aus Firewall, Switch, USV und Umgebungstemperatur korrelieren.

SNMP ersetzt keine Logauswertung. Für Traffic- und Security-Fragen bleiben Log viewer, Central Firewall Reporting, Syslog oder ein SIEM wichtiger. Für Traffic-Muster auf Interfaces passt sFlow Monitoring auf Sophos Firewall besser. SNMP beantwortet vor allem Zustandsfragen: Ist das Gerät erreichbar, laufen Interfaces, sind Hardwarewerte unauffällig und ändern sich Werte über Zeit?

Voraussetzungen

Vor der Einrichtung sollte man diese Punkte klären:

• Ein Monitoring-System mit SNMP-Unterstützung ist vorhanden.
• Die Firewall ist über ein Management- oder Monitoring-Netz erreichbar.
• SNMP-Zugriff ist unter Device Access nur für das Monitoring-System erlaubt.
• Der SNMP-Agent auf der Firewall ist geplant: Name, Standort, Kontakt und gewünschte SNMP-Version stehen fest.
• Es ist klar, ob das Monitoring nur abfragt oder ob die Firewall zusätzlich SNMP-Traps senden soll.
• Die passende Sophos Firewall MIB ist in das Monitoring-System importiert.
• Es ist klar, welche Firewall-Modelle überwacht werden und welche Hardwarewerte diese Modelle liefern.
• Alarmregeln sind so geplant, dass sie echte Betriebsprobleme melden und nicht nur Rauschen erzeugen.

⚠️ SNMP sollte nicht breit aus Client-, Gast-, IoT- oder WAN-Zonen erreichbar sein. Monitoring-Daten können Modell, Interfaces, Statuswerte und Betriebszustände sichtbar machen. Der Zugriff gehört in ein vertrauenswürdiges Management- oder Monitoring-Netz.

SNMP, sFlow und Reporting sauber trennen

SNMP, sFlow und Reporting liefern unterschiedliche Antworten.

Die Werkzeuge beantworten unterschiedliche Fragen:

• SNMP: Gut für Erreichbarkeit, Hardware- und Interfacewerte. Nicht ideal für einzelne Firewall-Regeln, URL-Blocks oder VPN-Fehler.
• sFlow: Gut für Verkehrsflüsse auf einem Interface. Nicht ideal für exakte Paket- oder Regelanalyse.
• Log Viewer, Syslog und Central Reporting: Gut für Regel, Modul, Benutzer und Ereigniskontext. Nicht ideal für Hardwarezustand und langfristige Interface-Polling-Werte.
• Packet Capture: Gut für die Frage, was auf einem Interface tatsächlich zu sehen ist. Nicht geeignet als dauerhaftes Monitoring.

In der Praxis kombiniert man diese Werkzeuge. SNMP meldet zum Beispiel hohe Temperatur oder Interface-Fehler. Danach prüft man Log Viewer, Packet Capture, Switch-Port, Umgebungstemperatur oder das betroffene Netzsegment.

Welche Hardwarewerte SFOS 22 liefert

Sophos hat in den SFOS 22 Release Notes zusätzliche SNMP-Hardwaremetriken beschrieben. Die Verfügbarkeit hängt vom Firewall-Modell ab.

Wichtige Hardware-Metriken:

• CPU temperature: laut Sophos für alle XGS-Modelle verfügbar.
• NPU temperature: für XGS-Modelle ausser XGS 88/88w, 108/108w, 118/118w und 128/128w.
• Fan speed: für XGS-Modelle ausser XGS 88/88w und 108/108w.
• Power supply status: für XGS 2100 und höher.
• PoE measurements: für XGS-Modelle mit PoE, ausser XGS 116/116w.

Diese Einordnung ist wichtig für die Erwartungshaltung. Wenn ein kleines Desktop-Modell keinen Lüfterwert oder keine NPU-Temperatur liefert, ist das nicht automatisch ein Monitoring-Fehler. Zuerst muss geprüft werden, ob das Modell die jeweilige Metrik überhaupt unterstützt.

SNMP-Zugriff absichern

Der erste Sicherheitscheck findet nicht im Monitoring-System statt, sondern auf der Firewall selbst.

Unter Administration > Device access sollte SNMP nur aus dem Netz erreichbar sein, in dem der Monitoring-Server steht. Wenn das Monitoring-System eine einzelne feste IP-Adresse hat, ist eine Local service ACL exception rule meist besser als eine breite Zonenfreigabe.

Sinnvolle Grundregeln:

• SNMP nicht aus WAN erlauben.
• SNMP nicht für komplette Client- oder Serverzonen freigeben, wenn nur ein Monitoring-Host pollt.
• Monitoring-Server als eigenes Host-Objekt oder Management-Netz definieren.
• Zugriff nach Änderungen mit Packet Capture oder Monitoring-Test prüfen.
• Nicht verwendete SNMP-Regeln und alte Monitoring-Quellen entfernen.

Device Access steuert Traffic zur Firewall selbst. Eine normale Firewall-Regel für LAN-zu-WAN-Traffic ersetzt diese Einstellung nicht.

SNMP-Agent und Manager-Einträge konfigurieren

Die Basis wird unter Administration > SNMP eingerichtet. Dort muss die Firewall zuerst als SNMP-Agent aktiviert werden, bevor ein Monitoring-System sinnvoll abfragen kann.

Grundkonfiguration:

1. Administration > SNMP öffnen.
2. Enable SNMP agent aktivieren.
3. Einen eindeutigen Namen eintragen, idealerweise passend zum Firewall-Hostname.
4. Standort und Kontakt hinterlegen, damit Alarme später einem Standort und Verantwortlichen zugeordnet werden können.
5. Mit Apply speichern.
6. Download MIB verwenden und die MIB im Monitoring-System importieren.

Sophos beschreibt für den Agent zwei Standardports: Abfragen laufen zum Agent über UDP 161, Traps werden zum Manager über UDP 162 gesendet. Diese Ports müssen nicht nur in der Firewall-Konfiguration stimmen, sondern auch zwischen Monitoring-System, Routing, lokalen Host-Firewalls und möglichen Management-Netzsegmenten erreichbar sein.

Für SNMPv3 wird unter Administration > SNMP > SNMPv3 users and traps ein Benutzer angelegt. Der Benutzername sollte bewusst gewählt werden, weil er laut Sophos später nicht geändert werden kann. Danach entscheidet man getrennt:

• Accept queries: Die Firewall beantwortet SNMP-Abfragen mit diesem Benutzer.
• Send traps: Die Firewall darf Traps an den Manager senden.
• Authorized hosts: Diese Liste gilt laut Sophos nur für Trap-Ziele, nicht als Zugriffsliste für SNMP-Abfragen.
• Encryption algorithm: AES, DES oder None. Für produktive Umgebungen sollte Verschlüsselung aktiv sein, wenn das Monitoring-System es unterstützt.
• Authentication algorithm: MD5, SHA256 oder SHA512. Neue Setups sollten nach Möglichkeit SHA256 oder SHA512 verwenden.
• Passwörter: Sophos verlangt für Verschlüsselung und Authentifizierung jeweils mindestens 12 Zeichen.

Für SNMPv1/v2c wird unter Administration > SNMP > SNMPv1/v2c ein Community-Eintrag erstellt. Dabei werden Name, Community String, IP-Version, Manager-IP und die Optionen Accept Queries sowie Send traps gesetzt. Der Community String funktioniert wie ein Passwort für SNMP-Abfragen und sollte deshalb nicht in Screenshots, Tickets oder Monitoring-Vorlagen im Klartext auftauchen.

Wenn Traps verwendet werden, reicht der Eintrag unter SNMP nicht immer als vollständige Alarmkonfiguration. Unter System services > Notification list müssen SNMP-Traps und die gewünschten Alert-Typen ebenfalls aktiviert werden.

SNMP-Version bewusst wählen

Wenn möglich, sollte SNMPv3 verwendet werden, weil es Authentifizierung und bei passender AuthPriv-Konfiguration auch Verschlüsselung ermöglicht. SNMPv1 und SNMPv2c arbeiten mit Community Strings. Diese Community Strings sind keine Benutzerkonten, sondern geteilte Geheimnisse und sollten entsprechend geschützt werden.

Für SNMPv1/v2c nennt Sophos in SFOS 22 eine Änderung: Man kann den Community String hinzufügen und auswählen, ob die Konfiguration für IPv4 oder IPv6 gilt. Beim Upgrade übernimmt die Firewall vorhandene Namen als Community String und erzeugt migrierte Objektbezeichnungen mit dem Präfix snmp.

Nach einem Upgrade sollte man deshalb prüfen:

• Gibt es alte SNMPv1/v2c Community Strings?
• Sind die automatisch migrierten snmp-Objekte verständlich benannt?
• Wird IPv4, IPv6 oder beides wirklich benötigt?
• Können alte Monitoring-Quellen entfernt werden?
• Ist SNMPv3 möglich oder bleibt v2c aus Kompatibilitätsgründen nötig?

⚠️ Community Strings sollten nicht wie harmlose Labels behandelt werden. Solche Strings gehören in ein Passwort- oder Secrets-Konzept, sollten nicht in Tickets kopiert werden und dürfen nicht in Screenshots sichtbar sein.

MIB importieren und OIDs prüfen

Damit ein Monitoring-System die Sophos-Werte sinnvoll erkennt, braucht es die passende MIB-Datei. Die MIB beschreibt, welche OIDs für Firewall-, Interface- und Hardwarewerte verfügbar sind.

Praktisches Vorgehen:

1. Aktuelle MIB-Datei unter Administration > SNMP > Download MIB beziehen.
2. MIB im Monitoring-System importieren.
3. Firewall mit SNMPv3 oder einer bewusst gewählten v1/v2c-Konfiguration hinzufügen.
4. Modell, Firmwareversion und erreichbare OIDs erkennen lassen.
5. Hardwaremetriken gegen das konkrete Modell prüfen.
6. Einen manuellen Poll durchführen und Werte plausibilisieren.
7. Erst danach Alarmregeln aktivieren.

Nach Firmware-Upgrades sollte die MIB-Seite erneut geprüft werden. Neue SFOS-Versionen können OIDs ergänzen oder bestehende Bereiche ändern. Wenn ein Monitoring-System nach einem Update Werte nicht mehr sauber auflöst, sollte man nicht zuerst die Firewall verdächtigen, sondern MIB-Version, Discovery und OID-Zuordnung prüfen.

Sinnvolle Alarmierung

SNMP-Monitoring ist nur hilfreich, wenn Alarme sinnvoll gesetzt sind. Zu enge Schwellenwerte erzeugen Rauschen, zu breite Schwellenwerte melden Probleme zu spät.

Typische Alarmbereiche:

• Erreichbarkeit: Firewall antwortet nicht mehr per SNMP oder Ping.
• CPU temperature: Temperatur steigt dauerhaft über den normalen Bereich.
• NPU temperature: Temperaturtrend ist auffällig oder dauerhaft höher als Vergleichswerte.
• Fan speed: Lüfterwert fehlt, ist null oder liegt deutlich ausserhalb des Normalbereichs.
• Power supply: Redundantes Netzteil fehlt oder meldet Fehler.
• PoE: PoE-Last nähert sich dem verfügbaren Budget.
• Interfaces: Port down, Error Counter oder ungewöhnliche Bandbreite.

Für Temperaturwerte ist eine Baseline wichtig. Eine kleine Desktop-Firewall in einem warmen Technikschrank verhält sich anders als eine Rack-Appliance im klimatisierten Raum. Deshalb sollte man zuerst einige Tage Normalbetrieb beobachten und erst danach produktive Schwellenwerte festlegen.

Für produktive Standorte ist eine zweistufige Alarmierung oft sinnvoll:

• Warnung: Der Wert ist auffällig, aber der Dienst läuft. Verlauf, Standort, Last und letzte Änderungen prüfen.
• Kritisch: Der Wert deutet auf ein akutes Risiko hin, zum Beispiel Netzteilfehler, dauerhaft sehr hohe Temperatur, verlorene Erreichbarkeit oder stark steigende Interface-Fehler.

Damit bleibt das Monitoring handlungsfähig. Nicht jeder Temperaturanstieg muss sofort eskaliert werden, aber ein wiederkehrender Trend sollte nicht im normalen Dashboardrauschen verschwinden.

Alarm-Runbook und Verantwortlichkeit festlegen

Ein SNMP-Alarm ist nur hilfreich, wenn danach klar ist, wer reagiert und welcher Ablauf gilt. Hardwarewerte sind oft Frühindikatoren: Eine steigende Temperatur, ein fehlender Lüfterwert oder ein Netzteilalarm bedeutet nicht automatisch, dass die Appliance sofort ersetzt werden muss. Es bedeutet aber, dass der Zustand eingeordnet und dokumentiert werden sollte.

Für produktive Firewalls sollte ein kurzer Runbook-Eintrag existieren:

Typische erste Checks:

• Firewall nicht per SNMP erreichbar: Management-Netz, Device Access, Routing, Monitoring-Server und Appliance-Erreichbarkeit prüfen.
• Temperatur steigt dauerhaft: Umgebungstemperatur, Lüftung, Rack-Position, Staub, Last und Verlauf vergleichen.
• Lüfterwert fehlt oder ist auffällig: Modellgrenze, Sensorwert, Geräusch, Temperaturtrend und Supportrelevanz prüfen.
• Netzteil meldet Fehler: Stromzufuhr, USV, Kabel, redundantes Netzteil und HA-Risiko kontrollieren.
• PoE-Last ist hoch: Angeschlossene Geräte, PoE-Budget und geplante Reserven prüfen.
• Interface-Fehler steigen: Kabel, Switch-Port, Duplex/Speed, SFP-Modul und Providerübergabe prüfen.

Wichtig ist die Reihenfolge: zuerst Sichtbarkeit und Plausibilität prüfen, dann Risiko bewerten, danach Support- oder Austauschprozess vorbereiten. Bei möglichen Hardwaredefekten sollte zusätzlich Seriennummer, Modell, Firmwarestand, Zeitpunkt, betroffene Metrik, Verlauf und Screenshot oder Monitoring-Auszug dokumentiert werden. Garantie- und RMA-Fragen hängen am Ende nicht nur vom Alarm ab, sondern vom konkreten Gerät, Supportstatus und Fehlerbild.

Für SSD-Themen ist SNMP nicht der richtige Hauptweg. Wenn Datenträgerzustand oder Schreiblast im Fokus stehen, passt Sophos Firewall SSD-Gesundheit per SMART prüfen besser.

HA-Cluster und mehrere Firewalls

In HA-Umgebungen sollte man klar festlegen, wie beide Geräte überwacht werden. Es reicht nicht immer, nur die Cluster-Adresse zu beobachten. Für Hardwarewerte sind oft beide Appliances relevant, weil ein Lüfter, Netzteil oder Port auf der passiven Appliance ebenfalls ausfallen kann.

Wichtige Fragen:

• Werden Primary und Auxiliary getrennt erkannt?
• Haben beide Geräte eigene Management-IP-Adressen für Monitoring?
• Werden Seriennummer, Hostname oder Modell im Monitoring eindeutig angezeigt?
• Bleiben Alarme nach einem Failover verständlich?
• Wird ein Netzteilfehler auf der passiven Appliance ebenfalls gemeldet?

Für den HA-Betrieb selbst passt Sophos Firewall High Availability einrichten. SNMP sollte dort nicht isoliert geplant werden, sondern zusammen mit Firmware-Updates, Failover-Tests, Backup-Konzept und Betriebsdokumentation.

Validierung nach der Einrichtung

Nach der SNMP-Einrichtung sollte man nicht nur prüfen, ob das Monitoring grün ist. Wichtig ist, ob die richtigen Daten aus der richtigen Quelle kommen.

Checkliste:

1. SNMP-Zugriff ist nur aus dem Monitoring-Netz möglich.
2. Der SNMP-Agent ist aktiv und antwortet auf UDP 161.
3. Falls Traps genutzt werden, kommen Testmeldungen über UDP 162 beim Manager an.
4. Die Firewall wird mit korrektem Hostnamen, Modell und Firmwareversion erkannt.
5. Die Sophos MIB ist importiert und Hardwarewerte werden sauber benannt.
6. Nicht unterstützte Metriken werden als Modellgrenze dokumentiert, nicht als Fehler.
7. Temperatur-, Lüfter-, Netzteil- und PoE-Werte sind plausibel.
8. Ein Testalarm wird ausgelöst und landet beim richtigen Empfänger.
9. Bei HA-Clustern werden beide Geräte oder die gewünschte Clusterlogik geprüft.
10. Nach einem Firmware-Upgrade wird die Discovery erneut getestet.

Für Performance- und Durchsatzfragen sollte man SNMP-Werte nicht überinterpretieren. Die Einordnung von Sophos-Leistungsdaten ist im Artikel Leistungsdaten der Sophos Firewall richtig verstehen beschrieben.

Troubleshooting

Firewall antwortet nicht auf SNMP

Zuerst prüfen, ob das Monitoring-System aus der erwarteten Zone kommt und ob SNMP unter Administration > Device access erlaubt ist. Danach IP-Adresse, Routing, lokale ACL-Regeln, SNMP-Version, Community String oder SNMPv3-Zugangsdaten prüfen.

Wenn unklar ist, ob Pakete die Firewall erreichen, hilft Packet Capture auf dem betroffenen Interface. Eine normale Firewall-Regel löst dieses Problem nicht, wenn der Traffic zur Firewall selbst geht.

MIB wird importiert, aber Werte fehlen

Zuerst prüfen, ob die fehlende Metrik für das eingesetzte Modell verfügbar ist. Kleine XGS-Modelle liefern nicht alle Hardwarewerte. Danach MIB-Version, OID-Zuordnung und Firmwareversion vergleichen.

Nach dem Upgrade sind SNMP-Objekte anders benannt

Bei SNMPv1/v2c kann SFOS 22 migrierte Objekte mit dem Präfix snmp erzeugen. Nach einem Upgrade sollte man deshalb Community Strings, Objektbezeichnungen und Monitoring-Discovery prüfen. Falls das Monitoring mit Namen statt stabilen OIDs arbeitet, können Vorlagen angepasst werden müssen.

Monitoring meldet zu viele Temperaturalarme

Dann sind Schwellenwerte wahrscheinlich zu eng oder ohne Baseline gesetzt. Zuerst Normalwerte über mehrere Tage erfassen. Danach Schwellenwerte nach Modell, Standort und Umgebungstemperatur festlegen. Einzelne kurze Spitzen sind anders zu bewerten als ein dauerhaft steigender Temperaturtrend.

HA-Cluster zeigt nur ein Gerät

Dann muss geprüft werden, ob das Monitoring nur die Cluster-Adresse abfragt oder ob beide Appliances separat erreichbar sind. Für Hardwarezustand ist die passive Appliance ebenfalls relevant. Bei produktiven Clustern sollte man dokumentieren, welche IP-Adresse welches Gerät und welche Rolle repräsentiert.

Betriebscheckliste

• SNMP nur aus Management- oder Monitoring-Netzen erlauben.
• SNMPv3 bevorzugen, wenn das Monitoring-System es sauber unterstützt.
• SNMPv1/v2c Community Strings wie Secrets behandeln.
• Sophos MIB importieren und nach Firmware-Upgrades prüfen.
• Modellgrenzen für Hardwarewerte dokumentieren.
• Temperatur- und PoE-Schwellenwerte anhand realer Baselines setzen.
• HA-Geräte eindeutig benennen und getrennt bewerten.
• Alarm-Runbook mit erster Prüfung, Eskalation und Zuständigkeit dokumentieren.
• Bei Hardwareverdacht Modell, Seriennummer, Firmwarestand und Verlauf sichern.
• Alarme regelmässig testen und Zuständigkeit klären.
• SNMP-Daten mit Logs, sFlow, Packet Capture und Central Reporting kombinieren.

FAQ