Sophos Firewall SNMP Hardware Monitoring einrichten

Für SNMP Hardware Monitoring aktiviert man unter Administration > SNMP den Agent, richtet bevorzugt einen SNMPv3-Benutzer ein, begrenzt den Zugriff unter Administration > Device access auf den Monitoring-Host und lädt die aktuelle MIB herunter. Danach lässt sich die Verbindung vom Monitoring-System mit snmpget prüfen und der Hardwarebaum mit snmpwalk abfragen.

Seit Sophos Firewall v22 liefert die MIB je nach XGS-Appliance-Modell zusätzlich CPU- und NPU-Temperatur, Lüfterdrehzahlen, Netzteilstatus und PoE-Werte. SNMP beantwortet damit vor allem Zustandsfragen. Für einzelne Security-Ereignisse bleiben Central Firewall Reporting oder Syslog passender, für Traffic-Muster sFlow.

Wenn es nicht um dauerhaftes Monitoring, sondern um eine akute Kontrolle direkt auf der Appliance geht, zeigt Sophos Firewall Temperatur und Lüfter per SSH prüfen, wie man sensors und xgs-healthmond.log ausliest und scheinbare Rohsensor-Alarme richtig einordnet.

⚠️ SNMP sollte nur aus einem vertrauenswürdigen Management- oder Monitoring-Netz erreichbar sein. Eine breite Freigabe aus Client-, Gast-, IoT- oder WAN-Zonen legt unnötig Informationen über Modell, Interfaces und Betriebszustand offen.

SNMP sicher konfigurieren

Zugriff auf den Monitoring-Host begrenzen

Soll eine dedizierte Monitoring-Zone zugreifen, wird SNMP unter Administration > Device access nur für diese Zone aktiviert. Pollt dagegen genau ein Server mit fester IP-Adresse, bleibt SNMP für die Zone deaktiviert. Stattdessen erlaubt eine Local service ACL exception rule die Quelle, das Firewall-Ziel und den Dienst SNMP gezielt. Der vollständige Aufbau steht unter Sophos Firewall Device Access absichern.

SNMP ist ein lokaler Dienst der Firewall. Eine normale LAN-zu-WAN-Regel ersetzt Device Access nicht. Aus dem WAN sollte SNMP nicht direkt freigegeben werden; für externes Monitoring ist ein Management-VPN die sicherere Verbindung.

Agent aktivieren

1. Administration > SNMP öffnen.
2. Enable SNMP agent aktivieren.
3. Name, Standort und Kontakt eintragen, zum Beispiel xgs-zrh-01, ZRH-DC1 / Rack 3 und noc@example.net.
4. Mit Apply speichern.
5. Über Download MIB die zur Firewall-Version gehörende MIB herunterladen und im Monitoring-System importieren.

Neben dem Sophos-spezifischen Hardwarebaum stellt SFOS die Standard-MIBs SNMPv2-MIB, IF-MIB mit Counter32 und Counter64, SNMPv2-SMI, IP-MIB, IP-FORWARD-MIB, TCP-MIB und UDP-MIB bereit. Damit lassen sich beispielsweise Uptime, Interface-Zähler, IP- und Routingwerte sowie TCP-/UDP-Statistiken überwachen. Die aktuelle Sophos-MIB bleibt trotzdem wichtig, weil sie die herstellerspezifischen OIDs und deren Bedeutung zur installierten SFOS-Version liefert.

Abfragen gehen über UDP 161 an den Agent. Traps gehen über UDP 162 an den Manager. Routing und lokale Host-Firewalls zwischen beiden Systemen müssen diese Richtung ebenfalls erlauben.

SNMPv3 einrichten

1. Unter Administration > SNMP > SNMPv3 users and traps auf Add klicken.
2. Einen dauerhaften Benutzernamen wie monitoring setzen. Dafür Buchstaben ohne Leerzeichen verwenden und denselben Benutzernamen auf dem Manager konfigurieren. Er kann später nicht geändert werden.
3. Accept queries aktivieren.
4. Send traps nur aktivieren, wenn die Firewall auch Meldungen an den Manager senden soll.
5. Wenn Send traps aktiviert ist, unter Authorized hosts die tatsächlichen IPv4- oder IPv6-Adressen der vorgesehenen Trap-Empfänger eintragen, bevor der SNMPv3-Benutzer gespeichert wird. Hier gehören die Empfängeradressen der eigenen Umgebung hinein, nicht automatisch die IP-Adressen der Polling-Hosts.
6. Für neue Setups möglichst AES und SHA256 oder SHA512 wählen. Beide Passphrases müssen mindestens zwölf Zeichen lang sein.
7. Speichern.

SFOS bietet zusätzlich DES oder None für die Verschlüsselung und MD5 für die Authentifizierung an. Diese Verfahren sollten für neue Konfigurationen nicht verwendet werden. Unterstützt der Collector nur diese Optionen, wird zuerst der Collector aktualisiert oder die SNMP-Verbindung auf einen technisch begründeten, isolierten Managementpfad begrenzt; ein stilles Downgrade ist kein erfolgreicher Kompatibilitätstest.

Authorized hosts gilt laut Sophos nur für Trap-Ziele. Die Liste begrenzt keine SNMPv3-Abfragen. Dafür sind passende Credentials, Accept queries und Device Access entscheidend.

SNMPv1 oder SNMPv2c nur bei Bedarf verwenden

Wenn das Monitoring-System SNMPv3 nicht sauber unterstützt, unter Administration > SNMP > SNMPv1/v2c auf Add klicken und einen Community-Eintrag anlegen. Benötigt werden Name, Community String, IPv4 oder IPv6, die Manager-IP und Accept queries. Send traps bleibt aus, wenn keine Traps verwendet werden. Den Eintrag anschliessend mit Save speichern.

Der Community String funktioniert wie ein Passwort, wird aber bei v1/v2c unverschlüsselt übertragen. Er gehört nicht in Screenshots oder Tickets und sollte nur in einem eng begrenzten Management-Netz verwendet werden.

Nach einem Upgrade auf SFOS 22 sollte man bestehende v1/v2c-Einträge prüfen: Die Firewall übernimmt den bisherigen Namen als Community String und erzeugt für migrierte Objekte einen Namen mit dem Präfix snmp. Dabei lassen sich unnötige IPv4-/IPv6-Varianten und nicht mehr verwendete Monitoring-Quellen entfernen.

Traps gezielt aktivieren

SFOS 23 – Hotfix-Sicherheitsupdates: Für diese Updates gibt es keine SNMP-Benachrichtigungen. Statt eines Traps die E-Mail-Benachrichtigung für Firmware > Security updates mit globalem E-Mail-Schalter und funktionierendem SMTP einrichten und angewendete Updates prüfen. Diese Ausnahme gilt nicht pauschal für alle Hotfixes oder Firmware-Ereignisse.

Für Traps reicht der SNMP-Benutzer oder Community-Eintrag allein nicht. Unter System services > Notification list müssen SNMP traps und die tatsächlich benötigten Alert-Typen aktiviert werden.

Der Empfang sollte bei einem real auftretenden ausgewählten Ereignis geprüft werden. SNMPv3-Informs werden bestätigt; erhält die Firewall keine Bestätigung, versucht sie laut Sophos keine erneute Zustellung. Traps und Informs ersetzen deshalb keine Überwachung des Pollings.

SNMP-Konfiguration sichern oder übertragen

SFOS 22 kann die Konfiguration des SNMP-Agenten, der Communities und der SNMPv3-Benutzer unter Backup and firmware > Import export als TAR-Datei exportieren und wieder importieren. Das ist bei einem kontrollierten Hardwaretausch oder vor grösseren Änderungen hilfreich. Das Archiv enthält sicherheitsrelevante Monitoring-Konfiguration und gehört deshalb in eine geschützte Ablage. Der allgemeine Ablauf steht unter Sophos Firewall Konfiguration exportieren und importieren.

Ein erfolgreicher Import beweist noch nicht, dass das Monitoring funktioniert. Danach Agentstatus, Device Access oder ACL Exception, Credentials, Query und Trap-Ziel mit einem echten Polling- und Ereignistest erneut prüfen. Die zur Zielversion passende aktuelle MIB muss ebenfalls beim Monitoring-System liegen.

Eine Testkonfiguration zurücknehmen

Vor einem Pilotbetrieb notiert man, ob der Agent und SNMP für die betreffende Zone bereits aktiv waren, welche Benutzer, Communities und ACL Exceptions vorhanden sind und welche SNMP-Optionen unter System services > Notification list eingeschaltet sind. So lässt sich nur die eigene Änderung zurücknehmen, ohne ein anderes Monitoring-System abzuschalten.

Für den Rückweg deaktiviert man zuerst den Polling-Job und eine pilotspezifische Trap-Verarbeitung im Monitoring-System, nicht jedoch einen gemeinsam genutzten Trap-Empfänger. Danach löscht man den neu angelegten SNMPv3-Benutzer oder Community-Eintrag und entfernt die dafür erstellte Local Service ACL Exception. Enable SNMP agent wird nur deaktiviert und mit Apply bestätigt, wenn der Agent vor dem Pilotbetrieb ausgeschaltet war und kein anderer Manager ihn nutzt. Wurde SNMP für eine ganze Zone aktiviert, setzt man diesen Eintrag unter Administration > Device access auf den vorherigen Zustand zurück. Auch ausschliesslich für den Piloten aktivierte Trap- und Alert-Optionen unter System services > Notification list werden auf ihren notierten Ausgangszustand zurückgesetzt. Abschliessend muss die Abfrage vom Pilot-Host mit einem Timeout enden; bestehende Manager müssen weiterhin Antworten auf ihre Abfragen und die erwarteten Traps erhalten.

Hardwaremetriken und Modellgrenzen

SFOS 22 stellt die neuen Hardwarewerte für XGS Appliances bereit:

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

Sophos dokumentiert diese Sensoren für XGS Appliances. Bei virtuellen, Cloud- oder Software-Appliances sollte man keine physischen Hostsensoren aus der SFOS-MIB erwarten. Auch bei einer XGS Appliance bedeutet eine fehlende Metrik nicht automatisch einen Fehler; zuerst ist die Modellgrenze zu prüfen.

OIDs und Einheiten aus der SFOS-22-MIB

Der Hardwarebaum beginnt bei .1.3.6.1.4.1.2604.5.1.9. Die wichtigsten Bereiche sind:

• NPU-Temperatur: .1.3.6.1.4.1.2604.5.1.9.1.0
• CPU-Temperatur: .1.3.6.1.4.1.2604.5.1.9.2.0
• Lüfterdrehzahl: .1.3.6.1.4.1.2604.5.1.9.3.1.2
• Netzteilstatus: .1.3.6.1.4.1.2604.5.1.9.4.1.2
• PoE-Tabelle: .1.3.6.1.4.1.2604.5.1.9.5

Temperaturen werden in Zehntelgrad Celsius geliefert: 420 entspricht 42,0 °C. Lüfterwerte sind RPM. PoE-Leistung wird in Milliwatt, Spannung in Millivolt und Strom in Milliampere ausgegeben. Beim Netzteil bedeutet up(1) betriebsbereit und down(2) ausgefallen.

Die PoE-Tabelle liefert pro Port ausserdem Bezeichnung, Status, konfiguriertes Leistungslimit und aktuellen Verbrauch. enabled(1) steht für aktive PoE-Versorgung, disabled(2) für deaktivierte Versorgung. Deshalb ist disabled(2) allein kein Hardwarefehler. Für Alarme vergleicht man den aktuellen Verbrauch mit dem Limit desselben Ports und erfasst Portbezeichnung und Index bei der Discovery neu, statt Tabellenzeilen blind einer alten Vorlage zuzuordnen. Ein Gesamtbudget der Appliance enthält die Tabelle nicht; ein Alarm auf den Gesamtverbrauch benötigt daher zusätzlich ein separat belegtes, modellspezifisches PoE-Budget.

Für numerisch auswertbare Hardwarewerte sollte mindestens SFOS 22.0 GA Build 411 laufen. Dieser Build behebt unter anderem NC-169564, bei dem Sensorwerte als Strings statt als Integer geliefert wurden, sowie weitere MIB- und OID-Probleme.

Nach einem Firmware-Upgrade sollte man die aktuelle MIB erneut herunterladen, im Monitoring-System importieren und die Discovery prüfen. Monitoring-Vorlagen dürfen nicht allein von Anzeigenamen abhängen.

Verbindung und Hardwarewerte testen

Die folgenden Bash-Befehle laufen auf einem Linux- oder macOS-Monitoring-Host mit Net-SNMP, nicht auf der Sophos Firewall. Unter macOS startet man dafür zuerst bash, da read -p in der Standardshell zsh eine andere Bedeutung hat. Die Beispiele wurden gegen die dokumentierte Net-SNMP-Syntax und die offizielle SFOS-22-MIB geprüft, aber nicht gegen eine Kundenfirewall ausgeführt.

SHA-256 und SHA-512 benötigen in der Regel Net-SNMP 5.8 oder neuer. Mit snmpwalk -h lässt sich prüfen, welche Algorithmen der installierte Client akzeptiert. Alte macOS-Systemversionen unterstützen teilweise nur MD5 und SHA.

⚠️ Net-SNMP übergibt Community und Passphrases als Prozessargumente. Die Eingabe über read hält sie aus der Shell-History, verhindert aber nicht die kurzzeitige Sichtbarkeit in der Prozessliste. Solche Tests nur auf einem vertrauenswürdigen Monitoring-Host ausführen.

SNMPv3 mit AuthPriv testen

IP-Adresse und Benutzer anpassen, Passphrases eingeben und zuerst den ungefährlichen Standard-OID sysUpTime.0 abfragen:

FIREWALL_IP="192.0.2.1"
SNMP_USER="monitoring"

read -r -s -p "SNMPv3 authentication password: " SNMP_AUTH
printf '\n'
read -r -s -p "SNMPv3 encryption password: " SNMP_PRIV
printf '\n'

snmpget -v3 -l authPriv -u "$SNMP_USER" \
  -a SHA-256 -A "$SNMP_AUTH" \
  -x AES -X "$SNMP_PRIV" \
  -t 3 -r 1 \
  "$FIREWALL_IP" .1.3.6.1.2.1.1.3.0

snmpwalk -v3 -l authPriv -u "$SNMP_USER" \
  -a SHA-256 -A "$SNMP_AUTH" \
  -x AES -X "$SNMP_PRIV" \
  -t 3 -r 1 \
  "$FIREWALL_IP" .1.3.6.1.4.1.2604.5.1.9

unset SNMP_AUTH SNMP_PRIV

Eine erfolgreiche erste Abfrage liefert sysUpTime.0 als Timeticks. Der anschliessende Walk zeigt nur die Sensoren, die das konkrete Modell unterstützt.

SNMPv2c als Kompatibilitätstest

Für einen bewusst eingerichteten v2c-Manager:

FIREWALL_IP="192.0.2.1"

read -r -s -p "SNMP community: " SNMP_COMMUNITY
printf '\n'

snmpget -v2c -c "$SNMP_COMMUNITY" -t 3 -r 1 \
  "$FIREWALL_IP" .1.3.6.1.2.1.1.3.0

snmpwalk -v2c -c "$SNMP_COMMUNITY" -t 3 -r 1 \
  "$FIREWALL_IP" .1.3.6.1.4.1.2604.5.1.9

unset SNMP_COMMUNITY

Ein erfolgreicher Uptime-Test beweist Erreichbarkeit und passende Credentials, aber noch nicht die Plausibilität aller Sensorwerte. Danach Hostname, Modell, Firmware, MIB-Version und Werte gegen WebAdmin, Appliance und Normalbetrieb prüfen. Für Temperatur- und PoE-Alarme zuerst über mehrere Tage eine Baseline bilden.

Alarmierung und HA

Sinnvolle Alarme melden nicht nur einen einzelnen Messwert, sondern eine betriebliche Abweichung:

• SNMP-Erreichbarkeit oder ein erwartetes Interface fällt aus.
• CPU- oder NPU-Temperatur steigt dauerhaft über die eigene Baseline.
• Ein vorhandener Lüfter meldet 0 RPM oder keinen Wert.
• Ein redundantes Netzteil wechselt auf down(2).
• PoE-Verbrauch nähert sich dem konfigurierten Limit eines Ports.
• Interface-Fehler oder Drops steigen auffällig.

Feste universelle Temperaturgrenzen wären irreführend. Modell, Rack, Umgebungstemperatur und Last bestimmen den Normalbereich. Ein Alarm-Runbook sollte zuerst Messwert, Verlauf und Modellgrenze prüfen und danach Kühlung, Stromversorgung, Verkabelung, Switch-Port oder PoE-Geräte einordnen.

Alarme sollten mindestens zwischen Warnung und Kritisch unterscheiden; für jede Stufe gehören Zuständigkeit, erster Prüfschritt und Eskalationsweg ins Runbook.

Bei bestätigtem Hardwareverdacht werden Modell, Seriennummer, Firmware, Zeitpunkt und Verlauf dokumentiert. Der Ablauf für Garantie und Austausch steht unter Sophos Hardwaredefekt: RMA und Austausch vorbereiten. Für Datenträger passt SSD-Gesundheit per SMART prüfen besser als SNMP.

In einem HA-Cluster hat jede Appliance eigene Sensoren. Sophos dokumentiert eine Peer-Administrationsadresse für den WebAdmin-Zugriff auf die Auxiliary-Appliance, jedoch nicht, dass sich darüber deren SNMP-Hardwarewerte separat abfragen lassen. Deshalb darf eine Abfrage der Cluster-Adresse nicht als Nachweis für den Hardwarezustand beider Appliances gelten. Nach dem HA-Aufbau und nach einem Failover prüft man, ob der Manager die Messwerte eindeutig einer Appliance zuordnen kann; andernfalls braucht die Auxiliary-Appliance einen anderen belegten Prüfweg. Die HA-Grundlagen erklärt Sophos Firewall High Availability einrichten.

SNMP-Werte sollten nicht als alleiniger Leistungsnachweis verwendet werden. Die Einordnung von Durchsatz und Auslastung steht unter Sophos Firewall Leistungsdaten richtig verstehen.

Troubleshooting

Timeout oder keine Antwort

Zuerst Monitoring-IP, Routing, Device Access, Local Service ACL, Accept queries, SNMP-Version und Credentials prüfen. Im WebAdmin unter Diagnostics > Packet capture kann der Filter host 192.0.2.50 and port 161 verwendet werden; die Bedienung erklärt Packet Capture im WebAdmin.

Alternativ in Option 4 Device Console lesen, ob die Abfrage die Firewall erreicht:

tcpdump 'host 192.0.2.50 and port 161'

Nach dem Test mit Ctrl+C beenden. Kommt kein Paket an, liegt die Ursache vor dem SNMP-Agent. Kommt die Anfrage an, aber keine Antwort zurück, sind Device Access, Manager-IP, Credentials und Agent-Konfiguration die nächsten Prüfstellen.

Authentifizierung oder Algorithmus schlägt fehl

Benutzername, Security Level authPriv, Authentifizierungs- und Verschlüsselungsalgorithmus müssen exakt zur Firewall passen. Wenn der Client SHA-256 oder SHA-512 nicht akzeptiert, mit snmpwalk -h die unterstützten Verfahren prüfen und Net-SNMP aktualisieren. Nicht still auf MD5 oder unverschlüsseltes SNMP zurückfallen.

Bei einem Query-Fehler nicht an Authorized hosts festhalten: Diese Liste gilt bei SNMPv3 nur für Trap-Ziele.

Hardwarewerte fehlen oder wirken falsch

Modellgrenze, Firmware und MIB-Version prüfen. In SFOS 22.0 GA Build 365 können Hardwarewerte wegen NC-169564 als Strings statt Integer erscheinen; Build 411 behebt den Fehler. Nach dem Update MIB und Monitoring-Discovery erneuern.

Die letzten Meldungen lassen sich in der Device Console lesen:

show logs snmpd.log lines 100
show logs xgs-healthmond.log lines 100

snmpd.log gehört zum SNMP-Agent. xgs-healthmond.log hilft bei CPU-Temperatur und Lüfterstatus. Weitere Zuordnungen stehen unter Sophos Firewall Service-Logs.

Traps kommen nicht an

Zuerst den Ereignistyp prüfen: Bei Hotfix-Sicherheitsupdates in SFOS 23 ist ein fehlender Trap zu erwarten. Er beweist keinen Fehler bei Routing, UDP 162 oder der Bestätigung von SNMPv3-Informs und sagt nichts über den Update-Erfolg aus. Für dieses Ereignis den oben beschriebenen E-Mail- und Update-Nachweisweg nutzen, statt den SNMP-Transport zu ändern. Die folgenden Prüfungen gelten für unterstützte Trap-Ereignisse.

Send traps, Authorized hosts, UDP 162 und die ausgewählten Ereignisse unter System services > Notification list prüfen. In der Device Console zeigt ein enger Mitschnitt, ob die Firewall zum Manager sendet:

tcpdump 'host 192.0.2.50 and port 162'

Wenn Pakete die Firewall verlassen, aber nicht ankommen, Routing, Zwischenfirewalls und den Trap-Empfänger prüfen. Bei SNMPv3-Informs zusätzlich die Bestätigung des Managers kontrollieren.