Sophos Firewall Temperatur und Lüfter per SSH prüfen

Die Temperatur wird im WebAdmin der Sophos Firewall nicht angezeigt. Auf einer physischen XGS-Appliance kann man die Hardwarewerte jedoch in der Advanced Shell auslesen und mit dem Hardware-Log vergleichen. Welcher Rohsensor-Befehl Werte liefert, hängt vom Modell ab.

Für eine schnelle Prüfung auf der hier getesteten XGS 138 genügen zunächst zwei lesende Befehle:

sensors
tail -n 100 /log/xgs-healthmond.log

Der erste Befehl zeigt die aktuellen Rohwerte des Sensorchips. Das Log ordnet die wichtigsten Werte verständlicher als Host_CPU_Temperature, NPU_CPU_Temperature und Fan_Speed_Avg ein. Ein einzelner hoher Wert beweist noch keine Überhitzung; entscheidend sind Verlauf, Last, Umgebungstemperatur, Lüfter und beobachtete Ausfälle.

⚠️ Wichtig: Die Advanced Shell bietet direkten Zugriff auf das Betriebssystem. Die hier gezeigten Befehle lesen nur Informationen. Keine Sensorgrenzen setzen, Lüftersteuerung verändern, Dateien löschen oder Services neu starten.

Temperatur direkt mit sensors auslesen

Für die Prüfung benötigt man SSH-Zugriff mit dem Benutzer admin. Nach der Anmeldung öffnet man:

5. Device Management
3. Advanced Shell

Wie SSH sicher freigegeben und die richtige Konsole geöffnet wird, erklärt Sophos Firewall per SSH verbinden.

In der Advanced Shell wird die aktuelle Sensoransicht aufgerufen:

sensors

Der Befehl wurde auf einer XGS 138 mit SFOS 22.0 GA Build 411 ausgeführt. Die Rohsensor-CLI ist modellabhängig: Für eine XGS 2100 nennt Sophos Hardware Development stattdessen folgenden Befehl, wenn sensors keine Werte liefert:

xgs-1us-sensors -a

Solche Alternativen sollten nur auf dem passenden Modell verwendet werden. /log/xgs-healthmond.log ist die breiter dokumentierte Quelle und sollte unabhängig davon geprüft werden. Auf virtuellen, Cloud- oder Software-Appliances können Hardware-Sensorbefehle fehlen, weil SFOS dort keinen Zugriff auf die physischen Sensoren des Hypervisors oder Servers hat.

Die Ausgabe unterscheidet sich je nach Modell. Typisch sind Temperaturkanäle, Lüfterdrehzahlen in RPM, Spannungen und zusätzliche Rohwerte des Hardware-Monitoring-Chips. Es ist sinnvoll, zuerst die vollständige Ausgabe zu sichern und nicht nur nach ALARM zu filtern. Ein solcher Filter würde bei manchen Modellen zahlreiche technisch vorhandene, aber nicht sinnvoll zugeordnete Rohkanäle zeigen.

Produktwerte im Hardware-Log prüfen

Sophos dokumentiert /log/xgs-healthmond.log auf Hardware-Appliances für CPU-Auslastung und -Temperatur, Lüftergeschwindigkeit und den NPU-Management-Port. Die letzten Einträge zeigt:

tail -n 100 /log/xgs-healthmond.log

Für eine kurze Beobachtung kann man das Log live verfolgen:

tail -f /log/xgs-healthmond.log

Die Anzeige wird mit Ctrl+C beendet. Eine Debug-Aktivierung ist dafür nicht nötig. xgs-healthmond.log ist ein Logdateiname und kein gültiger Name, den man als Debug-Subsystem übernehmen sollte.

In diesem Log sind vor allem diese Zeilen hilfreich:

• Host_CPU_Temperature: Temperatur der Haupt-CPU.
• NPU_CPU_Temperature: Temperatur der separaten NPU beziehungsweise des Xstream Flow Processors, sofern das Modell eine NPU besitzt.
• Fan_Speed und Fan_Speed_Avg: aktuelle beziehungsweise zusammengefasste Lüfterdrehzahl in RPM.
• Host_CPU_Usage und NPU_CPU_Usage: Auslastung zum Messzeitpunkt. Sie hilft, einen Temperaturanstieg mit hoher Last zu verbinden.
• Min, Max, Current und Avg: vom Health-Monitor geführte Statistikwerte.

Sophos dokumentiert das genaue Zeitfenster dieser Statistikwerte nicht öffentlich. Max sollte deshalb nicht als Spitzenwert der letzten fünf Minuten, seit dem letzten Reboot oder über die gesamte Lebensdauer bezeichnet werden. Für einen Supportfall werden Messwert und Zeitstempel gemeinsam gesichert.

Rohwerte und scheinbare Alarme richtig einordnen

Die Ausgabe von sensors stammt direkt vom Linux-Hardware-Monitoring. Ein Sensorchip kann mehr Eingänge anbieten, als auf der konkreten Appliance tatsächlich angeschlossen oder für SFOS sinnvoll beschriftet sind. Deshalb ist nicht jede sichtbare Zeile ein verwertbarer Produktwert.

Auf der getesteten XGS 138 erschienen beispielsweise mehrere Spannungszeilen nach diesem Muster:

in1: +1.78 V  (min = +0.00 V, max = +0.00 V)  ALARM

Der positive Messwert liegt formal über dem programmierten Maximum von 0.00 V, wodurch der Rohchip ALARM meldet. Daraus folgt aber noch kein bestätigter Spannungs- oder Hardwaredefekt. Für eine belastbare Diagnose fehlen die Zuordnung des Eingangs und die gültigen Grenzwerte des konkreten Boards.

Ähnlich vorsichtig werden weitere Auffälligkeiten gelesen:

• Mehrere Lüfterkanäle mit 0 RPM bedeuten nicht automatisch, dass mehrere Lüfter ausgefallen sind. Wenn ein Modell diese Anschlüsse nicht nutzt und gleichzeitig min = 0 RPM zeigt, können es unbelegte Kanäle sein.
• Werte wie -128 °C, 0 °C, 99 °C oder -1.0 können einen nicht angeschlossenen, nicht unterstützten oder nicht nutzbar zugeordneten Sensor darstellen.
• intrusion0: ALARM gehört zur Gehäuseerkennung und ist kein Temperaturalarm.
• high und crit gelten nur für genau den Sensor, neben dem sie angezeigt werden. Eine Schwelle bei CPUTIN darf nicht ohne Nachweis auf Host_CPU_Temperature übertragen werden.

Für die erste Einordnung sind deshalb die benannten Werte aus xgs-healthmond.log verlässlicher als einzelne unklare Rohkanäle. Auffällige Rohwerte bleiben dennoch im Support-Auszug erhalten, damit Sophos sie modellbezogen prüfen kann.

Ist die Sophos Firewall zu heiss?

Zuerst muss man zwischen Umgebungstemperatur und interner Komponententemperatur unterscheiden. Sophos spezifiziert die XGS 118, 128 und 138 für eine Umgebungstemperatur von 0 bis 40 °C. Damit ist die Luft am Betriebsort beziehungsweise im Rack gemeint, nicht die interne CPU-Temperatur. Die genaue Grenze des eigenen Modells steht in den jeweiligen Sophos Operating Instructions.

Eine interne CPU-Temperatur von beispielsweise 70 °C kann daher nicht mit der Umgebungsgrenze von 40 °C verglichen werden. Sophos veröffentlicht zudem keine allgemeingültige normale CPU- oder NPU-Temperatur für alle XGS-Modelle. Pauschale Aussagen wie «bis 80 °C ist alles normal» oder «ab 90 °C ist die Firewall defekt» wären deshalb nicht belastbar.

Eine sinnvolle Bewertung verbindet mehrere Beobachtungen:

1. Umgebung: Lufttemperatur am Ansaugbereich der Appliance messen, nicht nur die Raumtemperatur an einer entfernten Stelle. Bei Chassis_Ambient_Temperature : -1.0 liefert die Firewall selbst keinen brauchbaren Umgebungswert.
2. Verlauf: Werte bei vergleichbarer Last und Raumtemperatur über mehrere Messungen vergleichen. Ein dauerhaft steigender Trend ist aussagekräftiger als eine kurze Spitze.
3. Lüfter: Prüfen, ob der tatsächlich vorhandene Lüfter läuft und bei steigender Temperatur reagiert.
4. Last: CPU- und NPU-Auslastung zum selben Zeitpunkt dokumentieren.
5. Symptome: Unerwartete Reboots, Hänger, NPU-Fehler oder wiederholte Ausfälle erhöhen die Dringlichkeit.
6. Modellgrenze: Betriebs- und Rackbedingungen aus der Hardwareanleitung des konkreten Modells prüfen.

Auch ein warmes Gehäuse allein beweist keinen Defekt. Es zeigt aber, dass Luftstrom, Racktemperatur, freie Lüftungsöffnungen und der zeitliche Verlauf kontrolliert werden sollten.

Reales Beispiel einer XGS 138

Auf einer XGS 138 mit SFOS 22.0 GA Build 411 zeigte das Hardware-Log unter anderem:

Fan_Speed_Avg : 6081 RPM
NPU_CPU_Temperature : +61.3 Degrees C
Host_CPU_Temperature : +71.5 Degrees C
Host_CPU_Usage : 86.7681 %
{Host_CPU_Temperature} Min: +69.5 Max: +82.5 Current: +71.5 Avg: 71.8534

Die Haupt-CPU war zu diesem Zeitpunkt stark ausgelastet, der Lüfter lief und die NPU antwortete laut Log weiterhin erfolgreich. Der gespeicherte Maximalwert von 82.5 °C ist zusammen mit Last, Racktemperatur und dem vorausgegangenen Ausfall prüfenswert. Der Ausschnitt enthält jedoch keine explizite Thermal- oder Lüfterfehlermeldung und beweist allein nicht, dass Überhitzung die Ursache des Ausfalls war.

Genau diese Unterscheidung ist wichtig: Ein Reboot kann einen thermischen Zustand vorübergehend entschärfen, aber ebenso einen Software-, Last- oder Prozessfehler beseitigen. Nach einem Ausfall sollten deshalb Temperaturdaten und Systemlogs gemeinsam gesichert werden.

Nach einem Ausfall richtig weiterprüfen

Wenn die Firewall nicht reagiert hat oder erst nach einem Reboot wieder funktionierte, genügt eine einzelne aktuelle Temperaturmessung nicht. Der Vorfall wird wie ein möglicher Hardware- oder Systemfehler dokumentiert:

1. Modell, Seriennummer, Hardware-Revision, SFOS-Version, Build, Uhrzeit und beobachtetes Verhalten notieren.
2. Lufttemperatur am Ansaugbereich sowie Zustand von Klima, Rack und Luftstrom prüfen.
3. sensors und die letzten Einträge aus xgs-healthmond.log sichern.
4. Aktuelle Hinweise in Hardware- und Systemlog suchen:

grep -Ei 'temp|thermal|fan|overheat|critical|fault' /log/xgs-healthmond.log /log/syslog.log

5. Einen Consolidated Troubleshooting Report und relevante Logs sichern. Nach einem Absturz oder Reboot können flüchtige Informationen bereits fehlen.
6. Keine Lüfter ersetzen, das Gehäuse öffnen oder Sensorwerte verändern. Nach einem ungeklärten Ausfall sollte bereits ein Supportfall eröffnet werden; bei Wiederholung, unzulässiger Racktemperatur, deutlichem Temperaturanstieg, Lüfterfehlern oder NPU-Problemen steigt die Dringlichkeit.

Für einen möglichen Austausch hilft der Ablauf Sophos Hardwaredefekt: RMA und Austausch vorbereiten. Der SSD-Zustand per SMART ist eine separate Prüfung und beantwortet keine Temperatur- oder Lüfterfrage.

HA und dauerhafte Überwachung

In einem HA-Cluster werden beide Appliances separat geprüft. Jede XGS besitzt eigene Sensoren, Lüfter und lokale Troubleshooting-Logs. Eine unauffällige Primary Appliance beweist deshalb nicht, dass die Auxiliary Appliance ebenfalls thermisch unauffällig ist. Bei gleicher Rackposition und vergleichbarer Last kann der Peer zugleich als nützlicher Vergleichswert dienen. Die Rollen und Zugriffswege erklärt der Artikel zu Sophos Firewall High Availability.

Für eine einmalige Diagnose sind Advanced Shell und Hardware-Log schnell. Für den Betrieb sind sie kein Ersatz für Monitoring. Seit SFOS 22 liefert die Sophos-MIB je nach XGS-Modell CPU-Temperatur, NPU-Temperatur und Lüfterdrehzahl. Das bestehende SNMP Hardware Monitoring erklärt MIB, OIDs, Modellgrenzen, sichere SNMPv3-Konfiguration und Alarmierung.

Ein gutes Monitoring sammelt zuerst eine Baseline und alarmiert auf dauerhafte Abweichungen, fehlende erwartete Lüfterwerte, Nichterreichbarkeit und reale Hardwarefehler. Es sollte keine allgemeine CPU-Grenze aus dem Internet ungeprüft auf alle XGS-Modelle übertragen.