Redémarrer l'interface WebAdmin de Sophos Firewall

Si l’interface WebAdmin de Sophos Firewall ne répond plus, il n’est pas nécessaire de redémarrer immédiatement l’ensemble du pare-feu. Tant que le routage, le VPN et les règles de pare-feu continuent de fonctionner et que SSH ou la console locale reste accessible, il est possible de vérifier et de redémarrer séparément les deux services WebAdmin, tomcat et apache.

Les commandes suivantes sont prévues pour un pare-feu autonome. Dans un cluster HA, le mode de synchronisation approprié dépend du service, du nœud, du build SFOS et du problème rencontré. Il ne faut pas utiliser -ds nosync en HA sans vérifier au préalable que cette option convient.

⚠️ Le redémarrage d’un service modifie l’état du système, met fin aux sessions WebAdmin actives et peut également interrompre brièvement le User Portal. Il faut d’abord sauvegarder les journaux pertinents, informer les autres administrateurs et prévoir un autre moyen d’accès pour les sites distants.

Procédure rapide pour un pare-feu autonome

Cette procédure convient lorsque WebAdmin affiche une Internal Server Error, une erreur HTTP 503, une page de connexion incomplète ou une interface qui ne répond plus durablement, tandis que SSH et les autres fonctions du pare-feu restent disponibles.

Se connecter en tant qu’admin par SSH ou depuis la console locale. Si SSH n’est pas encore configuré, Se connecter à Sophos Firewall par SSH explique comment préparer un accès sécurisé.
Ouvrir 5. Device Management > 3. Advanced Shell.
Afficher les dernières erreurs WebAdmin et copier les sorties utiles pour la documentation du changement ou un dossier d’assistance :

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

Vérifier l’état actuel des services :

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

Si un service affiche STOPPED, exécuter uniquement la commande de démarrage correspondante :

# Si tomcat est STOPPED :
service tomcat:start -ds nosync

# Si apache est STOPPED :
service apache:start -ds nosync

Si un service affiche DEAD, redémarrer uniquement ce service. Si les deux affichent RUNNING mais que WebAdmin reste inutilisable, commencer par tomcat :

service tomcat:restart -ds nosync

Tester à nouveau WebAdmin. Exécuter la commande suivante uniquement si apache affiche DEAD ou si le problème persiste après le redémarrage de tomcat :

service apache:restart -ds nosync

Attendre quelques secondes, rouvrir WebAdmin depuis le réseau d’administration prévu, puis vérifier à nouveau l’état des services :

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

Les deux services doivent afficher RUNNING. Le test fonctionnel reste toutefois déterminant : la connexion, le tableau de bord, Log Viewer et une page de configuration non critique doivent se charger de manière stable. Un processus actif ne prouve pas à lui seul que WebAdmin fonctionne correctement.

Les sessions SSH inactives sont fermées après 15 minutes. Il est donc préférable de préparer la vérification des journaux, le redémarrage et le contrôle avant d’ouvrir Advanced Shell afin qu’une session expirée n’interrompe pas la procédure.

Vérifier si le redémarrage d’un service est approprié

Derrière le nom de service tomcat se trouve le serveur d’applications web Jetty ; apache correspond au serveur HTTP Apache. WebAdmin et le User Portal utilisent ces deux composants. Leurs journaux se trouvent dans Advanced Shell :

Serveur d’applications : /log/tomcat.log
Serveur web : /log/apache.log et /log/apache_access.log
Autres erreurs du serveur web : /log/error_log.log

Tous les problèmes WebAdmin ne proviennent pas de ces services. Le type d’erreur détermine l’étape suivante :

Internal Server Error, HTTP 503 ou page de connexion incomplète : Vérifier tomcat, apache et les journaux indiqués. Un redémarrage ciblé est pertinent dans ce cas.
Avertissement de certificat : Vérifier le nom, la validité et la chaîne de confiance du certificat. Le redémarrage d’un service ne corrige pas un certificat incorrect.
Délai d’attente dépassé ou accès impossible depuis un seul réseau : Vérifier la route, le réseau d’administration et Administration > Device access. Les services locaux du pare-feu sont autorisés via Device Access et non par une règle de pare-feu classique. Device Access et Local Service ACL explique la configuration sécurisée.
Un seul navigateur est concerné : Tester une session privée, un deuxième navigateur ou un autre client d’administration avant d’intervenir sur le pare-feu.
WebAdmin, SSH, VPN ou d’autres services tombent en panne simultanément : Cela indique plutôt un problème de charge système, de stockage, de base de données, de HA ou un problème système général. Ne pas redémarrer des services au hasard.

Si une mise à jour du firmware, d’un hotfix ou des patterns, une synchronisation HA, une session de débogage de l’assistance ou une tâche Central active est en cours, il faut d’abord identifier ce processus et, si possible, le terminer. Sinon, il sera difficile de déterminer par la suite si le problème provenait de la mise à jour, de Central, de HA ou du redémarrage du service.

Conserver les éléments de diagnostic avant l’intervention

Un redémarrage peut faire disparaître les messages d’erreur actuels du contexte visible. Pour un problème récurrent ou un dossier d’assistance, il faut au minimum consigner l’heure, le build SFOS, le chemin d’accès concerné et les derniers messages de tomcat.log, apache.log et error_log.log.

Si WebAdmin fonctionne encore partiellement, des journaux individuels ou un Consolidated Troubleshooting Report peuvent être téléchargés sous Diagnostics > Tools. Si seul le shell reste disponible, Sauvegarder les journaux Sophos Firewall pour l’assistance et l’analyse explique la procédure. Dans un cluster HA, chaque nœud conserve ses propres journaux ; Primary et Auxiliary doivent être vérifiés séparément si nécessaire.

Avant un redémarrage en production, il faut également confirmer :

si d’autres administrateurs ou un changement en cours sont concernés ;
si SSH, la console locale, Sophos Central ou une autre connexion d’administration offre une voie de retour ;
si WebAdmin est le seul service concerné ;
si, pour un cluster HA, le bon nœud et des instructions Sophos actuelles propres au service sont disponibles.

Redémarrer les services Sophos Firewall en toute sécurité explique la gestion générale des noms de service, de leur état, des journaux et des limites de HA. Dépannage de Sophos Firewall : services et journaux fournit d’autres correspondances entre les fonctions et les fichiers journaux.

Vérifier le résultat et analyser les problèmes récurrents

Relire les journaux après le redémarrage. Les nouvelles erreurs qui apparaissent immédiatement après le démarrage sont plus utiles que les anciens messages sans référence temporelle :

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

Ouvrir ensuite le tableau de bord, Log Viewer et une page non critique. Tout accès SSH ou Device Access autorisé temporairement doit être à nouveau limité aux sources d’administration prévues.

Si le problème revient, le redémarrage du service n’a constitué qu’une restauration temporaire. L’analyse de la cause doit alors porter sur :

l’espace libre sur les partitions, les rapports locaux et l’état de la base de données ;
l’utilisation du processeur et de la RAM ainsi que les journaux système inhabituels ;
les sessions d’administration simultanées ou l’utilisation intensive de la capture de paquets ;
les tâches Central actives ou en échec ;
le rôle HA, la synchronisation et le nœud concerné ;
les modifications de configuration, de certificat, d’interface ou de Device Access effectuées juste avant le problème.

Gérer le stockage et les rapports de Sophos Firewall aide à résoudre les problèmes de stockage et de rapports. Les modifications effectuées avant la panne peuvent être retracées grâce aux journaux Audit Trail de Sophos Firewall.

Une courte note d’exploitation évite de traiter un problème récurrent uniquement par des redémarrages répétés :

Date, heure et fuseau horaire :
Pare-feu et nœud HA, le cas échéant :
Version et build SFOS :
Symptômes :
Journaux vérifiés :
Commande exécutée :
Résultat et prochaine action :

Si WebAdmin reste indisponible

Si un service reste STOPPED ou DEAD, si le redémarrage renvoie une erreur ou si le problème réapparaît immédiatement, il faut sauvegarder tomcat.log, apache.log, error_log.log, l’état du système et le CTR afin de les analyser avec Sophos Support. Le redémarrage aléatoire d’autres services risque surtout de dégrader les éléments de diagnostic.

Si ni WebAdmin ni SSH ne sont accessibles, la voie de récupération dépend de l’environnement : console locale via un câble de console ou Micro-USB sur les modèles compatibles, Sophos Central, solution de repli HA préparée ou redémarrage planifié. Sur les sites distants, il faut déterminer qui pourra obtenir un accès local si le pare-feu ne démarre pas correctement. Dans un cluster HA, il ne faut pas déclencher un basculement non vérifié uniquement parce que WebAdmin ne répond plus tant que le trafic de production continue de circuler normalement.

Un redémarrage complet est plus invasif que le redémarrage des services concernés. Il ne doit être envisagé que si plusieurs services centraux sont touchés, si le pare-feu reste instable, si un processus de firmware ou de hotfix l’exige ou si Sophos Support le demande. Il faut d’abord confirmer la sauvegarde, la fenêtre de maintenance et les effets sur le VPN, le routage, RED, wireless et les services publiés. Planifier correctement la sauvegarde et la restauration de Sophos Firewall explique la préparation.