Zum Inhalt springen
Avanet

Sophos Firewall SNMP Hardware Monitoring einrichten

Sophos Firewall

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

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. 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. Für neue Setups möglichst AES und SHA256 oder SHA512 wählen. Beide Passphrases müssen mindestens zwölf Zeichen lang sein.
  6. Speichern.

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, wird unter Administration > SNMP > SNMPv1/v2c ein Community-Eintrag angelegt. Benötigt werden Name, Community String, IPv4 oder IPv6, die Manager-IP und Accept queries. Send traps bleibt aus, wenn keine Traps verwendet werden.

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

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.

Hardwaremetriken und Modellgrenzen

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

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

Sophos dokumentiert diese Sensoren für XGS-Hardware. Bei virtuellen, Cloud- oder Software-Appliances sollte man keine physischen Hostsensoren aus der SFOS-MIB erwarten. Auch bei XGS 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.

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 Budget.
  • 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 sind beide Appliances relevant. Eine Abfrage der Cluster-Adresse allein zeigt nicht zwingend den Lüfter, das Netzteil oder den Port der passiven Appliance. Wenn Netzaufbau und Plattform getrennte Management-Zugriffe erlauben, sollten Primary und Auxiliary einzeln erkannt werden. Die tatsächliche SNMP-Erreichbarkeit und Zuordnung muss nach dem HA-Aufbau und nach einem Failover geprüft werden. 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

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.