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

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.

Diese Tabelle 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-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 aus der Sophos Firewall oder der passenden Sophos-Dokumentation 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:

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.

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:

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. Die Firewall wird mit korrektem Hostnamen, Modell und Firmwareversion erkannt.
3. Die Sophos MIB ist importiert und Hardwarewerte werden sauber benannt.
4. Nicht unterstützte Metriken werden als Modellgrenze dokumentiert, nicht als Fehler.
5. Temperatur-, Lüfter-, Netzteil- und PoE-Werte sind plausibel.
6. Ein Testalarm wird ausgelöst und landet beim richtigen Empfänger.
7. Bei HA-Clustern werden beide Geräte oder die gewünschte Clusterlogik geprüft.
8. 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