Sophos Firewall WebAdmin GUI neu starten

Wenn die Sophos Firewall WebAdmin GUI nicht mehr reagiert, muss nicht sofort die ganze Firewall neu gestartet werden. Solange Routing, VPN und Firewall-Regeln weiterarbeiten und SSH oder die lokale Konsole erreichbar ist, kann man die beiden WebAdmin-Services tomcat und apache gezielt prüfen und neu starten.

Der folgende Befehlssatz ist für eine Standalone-Firewall gedacht. In einem HA-Cluster hängt der richtige Synchronisationsmodus vom Service, Node, SFOS-Build und konkreten Fehlerbild ab. Dort darf -ds nosync nicht ungeprüft übernommen werden.

⚠️ Ein Service-Neustart verändert den Systemzustand, beendet laufende WebAdmin-Sitzungen und kann auch das User Portal kurzzeitig unterbrechen. Vorher relevante Logs sichern, andere Admins informieren und bei Remote-Standorten einen alternativen Zugriff bereithalten.

Schnellablauf für eine Standalone-Firewall

Der Ablauf passt, wenn WebAdmin einen Internal Server Error, HTTP 503, eine unvollständige Login-Seite oder eine dauerhaft hängende Oberfläche zeigt, während SSH und die übrigen Firewall-Funktionen erreichbar bleiben.

1. Als admin per SSH oder lokaler Konsole anmelden. Falls SSH noch nicht eingerichtet ist, erklärt Sophos Firewall per SSH verbinden den sicheren Zugriff.
2. 5. Device Management > 3. Advanced Shell öffnen.
3. Die letzten WebAdmin-Fehler anzeigen und relevante Ausgaben für die Change-Dokumentation oder einen Supportfall kopieren:

tail -n 80 /log/tomcat.log
tail -n 80 /log/apache.log
tail -n 80 /log/error_log.log

4. Den aktuellen Service-Status prüfen:

service -S | grep -iE 'tomcat|apache'

5. Zeigt ein Service STOPPED, wird nur der passende Startbefehl ausgeführt:

# Wenn tomcat STOPPED ist:
service tomcat:start -ds nosync

# Wenn apache STOPPED ist:
service apache:start -ds nosync

6. Zeigt ein Service DEAD, wird nur dieser neu gestartet. Sind beide RUNNING, WebAdmin bleibt aber unbenutzbar, beginnt man mit tomcat:

service tomcat:restart -ds nosync

WebAdmin danach erneut testen. Nur wenn apache DEAD ist oder das Problem nach dem tomcat-Restart weiter besteht, folgt:

service apache:restart -ds nosync

7. Einige Sekunden warten, WebAdmin aus dem vorgesehenen Managementnetz neu öffnen und den Service-Status nochmals prüfen:

service -S | grep -iE 'tomcat|apache'

Erwartet wird für beide Services RUNNING. Entscheidend ist aber der Funktionstest: Anmeldung, Dashboard, Log Viewer und eine unkritische Konfigurationsseite müssen stabil laden. Ein laufender Prozess allein beweist noch nicht, dass WebAdmin wieder korrekt arbeitet.

Inaktive SSH-Sitzungen werden nach 15 Minuten beendet. Vor dem Einstieg in die Advanced Shell sollten deshalb Logprüfung, Neustart und Kontrolle vorbereitet sein, damit der Ablauf nicht durch eine abgelaufene Sitzung unterbrochen wird.

Prüfen, ob ein Service-Neustart überhaupt passt

Hinter dem Servicenamen tomcat arbeitet der Jetty-Webanwendungsserver; apache ist der Apache-HTTP-Server. Beide Komponenten werden neben WebAdmin auch für das User Portal verwendet. Die zugehörigen Logs liegen in der Advanced Shell unter:

• Anwendungsserver: /log/tomcat.log
• Webserver: /log/apache.log und /log/apache_access.log
• weitere Webserver-Fehler: /log/error_log.log

Nicht jedes WebAdmin-Problem entsteht in diesen Services. Die Art des Fehlers entscheidet über den nächsten Schritt:

• Internal Server Error, HTTP 503, unvollständige Login-Seite: tomcat, apache und die genannten Logs prüfen. Der gezielte Neustart ist hier plausibel.
• Zertifikatswarnung: Zertifikatsname, Gültigkeit und Trust Chain prüfen. Ein Service-Neustart korrigiert kein falsches Zertifikat.
• Timeout oder nur aus einem Netz kein Zugriff: Route, Managementnetz und Administration > Device access prüfen. Lokale Firewall-Dienste werden über Device Access und nicht über eine normale Firewall-Regel freigegeben. Die sichere Konfiguration erklärt Device Access und Local Service ACL.
• Nur ein Browser ist betroffen: Private Sitzung, zweiten Browser oder anderen Admin-Client testen, bevor auf der Firewall eingegriffen wird.
• WebAdmin, SSH, VPN oder weitere Services fallen gemeinsam aus: Das spricht eher für Systemlast, Speicher, Datenbank, HA oder ein allgemeines Systemproblem. Dann nicht wahllos Services neu starten.

Läuft gerade ein Firmware-, Hotfix- oder Pattern-Update, eine HA-Synchronisation, ein Support-Debug oder ein aktiver Central-Task, sollte der Vorgang zuerst eingeordnet und möglichst abgeschlossen werden. Sonst lässt sich später kaum unterscheiden, ob die Störung vom Update, von Central, von HA oder vom Service-Neustart stammt.

Vor dem Eingriff Belege sichern

Ein Neustart kann aktuelle Fehlermeldungen aus dem sichtbaren Kontext verdrängen. Für einen wiederkehrenden Fehler oder Supportfall sollte man deshalb mindestens Uhrzeit, SFOS-Build, betroffenen Zugriffspfad und die letzten Meldungen aus tomcat.log, apache.log und error_log.log festhalten.

Wenn WebAdmin noch teilweise funktioniert, lassen sich einzelne Logs oder ein Consolidated Troubleshooting Report unter Diagnostics > Tools herunterladen. Ist nur noch die Shell verfügbar, hilft Sophos Firewall Logs für Support und Analyse sichern. In einem HA-Cluster speichert jeder Node seine eigenen Logs; bei Bedarf müssen Primary und Auxiliary getrennt geprüft werden.

Vor einem produktiven Neustart sollte ausserdem klar sein:

• ob andere Admins oder ein laufender Change betroffen sind;
• ob SSH, lokale Konsole, Sophos Central oder eine andere Managementverbindung als Rückweg funktioniert;
• ob WebAdmin der einzige betroffene Dienst ist;
• ob auf einem HA-Cluster der richtige Node und eine aktuelle dienstspezifische Sophos-Anweisung vorliegen.

Der allgemeine Umgang mit Service-Namen, Status, Logs und HA-Grenzen steht in Sophos Firewall Services sicher neu starten. Weitere Zuordnungen zwischen Funktionen und Logdateien enthält Sophos Firewall Troubleshooting: Services und Logs.

Erfolg prüfen und Wiederholungen einordnen

Nach dem Neustart werden die Logs erneut gelesen. Neue Fehler direkt nach dem Start sind aussagekräftiger als alte Meldungen ohne Zeitbezug:

tail -n 80 /log/tomcat.log
tail -n 80 /log/apache.log
tail -n 80 /log/error_log.log

Anschliessend sollte man Dashboard, Log Viewer und eine unkritische Seite öffnen. Temporär erlaubter SSH- oder Device-Access-Zugriff wird wieder auf die vorgesehenen Admin-Quellen beschränkt.

Kehrt die Störung zurück, ist der Service-Neustart nur eine kurzfristige Wiederherstellung. Dann gehören diese Punkte in die Ursachenanalyse:

• freie Partitionen, lokale Reports und Datenbankzustand;
• CPU- und RAM-Last sowie auffällige Systemlogs;
• parallele Admin-Sitzungen oder intensive Packet-Capture-Nutzung;
• laufende oder fehlgeschlagene Central-Tasks;
• HA-Rolle, Synchronisation und betroffener Node;
• Konfigurations-, Zertifikats-, Interface- oder Device-Access-Änderungen unmittelbar vor dem Fehler.

Für Speicher- und Reportprobleme hilft Sophos Firewall Speicherplatz und Reports verwalten. Änderungen vor dem Ausfall lassen sich mit Sophos Firewall Audit Trail Logs nachvollziehen.

Eine kurze Betriebsnotiz verhindert, dass ein wiederkehrender Fehler immer nur neu gestartet wird:

Datum, Uhrzeit und Zeitzone:
Firewall und gegebenenfalls HA-Node:
SFOS-Version und Build:
Fehlerbild:
Geprüfte Logs:
Ausgeführter Befehl:
Ergebnis und nächste Massnahme:

Wenn WebAdmin weiterhin nicht erreichbar ist

Bleibt ein Service STOPPED oder DEAD, liefert der Restart einen Fehler oder kehrt das Problem sofort zurück, sollten tomcat.log, apache.log, error_log.log, Systemzustand und CTR gesichert und mit Sophos Support ausgewertet werden. Weitere beliebige Service-Neustarts verschlechtern eher die Beweislage.

Sind WebAdmin und SSH nicht erreichbar, braucht es je nach Umgebung die lokale Konsole über Console-Kabel oder bei unterstützten Modellen Micro-USB, Sophos Central, einen vorbereiteten HA-Rückfallweg oder einen geplanten Reboot. Bei Remote-Standorten muss vor dem Reboot geklärt sein, wer bei einem fehlgeschlagenen Start lokalen Zugriff herstellen kann. In einem HA-Cluster sollte man nicht allein wegen einer hängenden WebAdmin-Oberfläche ungeprüft failovern, solange der produktive Traffic stabil weiterläuft.

Ein kompletter Reboot ist invasiver als der gezielte Service-Neustart. Er kommt erst infrage, wenn mehrere zentrale Services betroffen sind, die Firewall insgesamt instabil bleibt, ein Firmware- oder Hotfix-Prozess ihn verlangt oder Sophos Support ihn vorgibt. Vorher müssen Backup, Wartungsfenster und Auswirkungen auf VPN, Routing, RED, Wireless und veröffentlichte Dienste bekannt sein. Die Vorbereitung beschreibt Sophos Firewall Backup und Restore richtig planen.