Sophos Firewall redémarre de manière inattendue : vérifier la cause

Si une Sophos Firewall redémarre sans intervention planifiée, ne la rebootez pas immédiatement et ne redémarrez pas des services par précaution. Il faut d’abord déterminer si l’ensemble de l’appliance a réellement redémarré ou si seuls WebAdmin, un service individuel ou le rôle HA actif sont tombés en panne. Un redémarrage réussi peut rétablir le fonctionnement, mais n’explique pas encore la cause.

⚠️ Sauvegarder les preuves avant toute autre intervention : Ne supprimez aucun log, ne provoquez pas un autre reboot, ne modifiez pas le statut de auto-reboot-on-hang et ne lancez pas de debug, d’action sur un service, de fsck, de Factory Reset ou de Reimage sur la base d’un soupçon. De telles interventions peuvent modifier les indices, provoquer de nouvelles interruptions ou masquer le défaut réel.

La procédure rapide et sûre est la suivante :

Noter l’heure avec le fuseau horaire, la durée de la panne et la dernière observation connue où le système fonctionnait.
Noter si le trafic, WebAdmin, SSH et la console locale ont été affectés simultanément.
Dans le Control Center, sauvegarder l’uptime, les services, les interfaces, les VPN et, pour HA, le statut du cluster.
Sous Log viewer > System, exporter les événements correspondants et sauvegarder l’historique sous Diagnostics > System graphs.
Sous Diagnostics > Tools, télécharger un CTR ainsi que sysinit.log, syslog.log et, pour HA, les logs locaux des nœuds.
Dans la Device Console, lire l’uptime, le build et le statut de redémarrage automatique :

system diagnostics show uptime
system diagnostics show version-info
system auto-reboot-on-hang show

Pour HA, comparer les rôles, le statut, Last status change et l’uptime des deux nœuds.
Ce n’est qu’ensuite qu’il faut examiner la branche de causes appropriée et tester complètement le fonctionnement en production.

system auto-reboot-on-hang show ne modifie rien. SFOS active cette fonction par défaut et peut redémarrer automatiquement le pare-feu si le kernel ne répond plus. Un enable affiché prouve toutefois uniquement la recovery policy configurée, et non qu’un kernel hang a provoqué ce redémarrage précis.

Vérifier ce qui est réellement tombé en panne

L’interruption observée ne prouve pas à elle seule qu’un reboot complet s’est produit. Ces quatre cas nécessitent des étapes suivantes différentes :

Reboot complet de l’appliance : L’uptime recommence, plusieurs services et connexions ont été interrompus simultanément et SFOS a relancé le démarrage du système. Le diagnostic de reboot de cet article s’applique maintenant.
Seul WebAdmin ou un service a été affecté : L’uptime continue et une partie du trafic de production peut fonctionner sans changement. Dans ce cas, un redémarrage ciblé de la GUI WebAdmin ou le contrôle d’un service individuel est plus approprié qu’un reboot de l’appliance.
Failover HA : Les utilisateurs peuvent constater une brève interruption alors que seuls les rôles ont changé. L’uptime, le rôle et les logs de chaque nœud montrent si un appareil a réellement rebooté. Le contrôle HA est décrit plus bas.
Mode failsafe : Le pare-feu ne démarre pas normalement et affiche un état de récupération sur la console. Dans ce cas, show failure-reason du runbook sur le mode failsafe de Sophos Firewall est la première commande appropriée.

L’uptime constitue donc un indice solide pour la période du redémarrage, mais pas une preuve de la cause. Une brève coupure de courant, un kernel hang, une erreur de firmware et un redémarrage planifié par un administrateur le réinitialisent également.

Sauvegarder les preuves après le redémarrage

Après un reboot non planifié, des données volatiles peuvent déjà manquer. Il faut néanmoins sauvegarder intégralement l’état accessible avant d’effectuer d’autres modifications.

Le dossier d’incident doit contenir au minimum :

modèle, numéro de série et plateforme : matériel, VM ou cloud
version SFOS complète avec MR et build
heure exacte, fuseau horaire, durée et fréquence de la panne
fonctions affectées : trafic, WebAdmin, SSH, console, VPN et services publiés
dernière modification du firmware, de la configuration, de l’hyperviseur, du stockage ou de l’alimentation
uptime actuel et statut des services, interfaces, VPN et HA
pour HA : nœud affecté, rôles avant et après l’événement et statut du peer
événements UPS, PDU, hyperviseur, cloud, switch et supervision disponibles dans la même fenêtre temporelle

Sous Diagnostics > System graphs, contrôlez CPU, Memory, Load et Disk autour de l’heure présumée. Une anomalie peut circonscrire la recherche. Une valeur actuelle normale ne prouve toutefois pas que la charge était également normale avant le reboot.

Sous Log viewer > System, filtrez et exportez les événements de démarrage, restart, shutdown et HA dans la même fenêtre temporelle. Le Log Viewer constitue une source temporelle utile, mais pas une preuve complète de crash. Des événements qui n’avaient pas encore été enregistrés peuvent manquer après un hang.

Lire l’état du système dans la Device Console

Outre l’uptime et le build, ces commandes de lecture indiquent l’état actuel :

system diagnostics show cpu
system diagnostics show memory
system diagnostics show disk

Les valeurs doivent figurer dans la note d’incident avec l’heure de la requête. Elles décrivent l’état après le redémarrage et ne doivent pas être interprétées rétrospectivement comme sa cause.

Contrôler les logs de démarrage et système

Dans l’Advanced Shell, les fichiers les plus importants peuvent être lus intégralement et sans modification :

cd /log
less sysinit.log
less syslog.log
less applog.log
less csc.log

q permet de quitter less. Dans le fichier, /terme-de-recherche lance une recherche, par exemple /error ; n permet d’accéder au résultat suivant.

sysinit.log documente le démarrage du système.
syslog.log contient les événements du kernel et du système.
applog.log et csc.log aident à classer les actions internes et les modifications proches de l’événement.

Sous Diagnostics > Tools > Troubleshooting logs, téléchargez également les mêmes fichiers afin de conserver les données originales en dehors de l’appliance. La correspondance des logs de service Sophos Firewall explique quel fichier de log supplémentaire appartient à un service.

En outre, sous Diagnostics > Tools > Consolidated troubleshooting report, générez un CTR avec System snapshot et All log files. Le CTR contient l’état actuel du système et de nombreux logs dans une archive chiffrée. Par défaut, les logs des sous-systèmes de services ne contiennent pas plus de 10'000 lignes ; les logs individuels complets restent importants pour des périodes plus longues. La procédure complète est décrite dans Sauvegarder les logs Sophos Firewall pour le support.

Une section de log vide n’exclut ni un crash ni une coupure de courant. Des informations qui n’avaient pas encore été écrites sur le disque peuvent être perdues lors d’un hang et les logs locaux peuvent faire l’objet d’une rotation. Les sources temporelles externes et une chronologie précise de l’incident sont donc particulièrement importantes.

Distinguer un failover HA d’un reboot du nœud

Sous System services > High availability, sauvegardez Health, Mode, les rôles, le statut, les numéros de série et Last status change. Dans la Device Console, exécutez également :

system ha show details

Contrôlez ensuite l’uptime sur les deux nœuds. Si un seul nœud présente un uptime court, cela indique un redémarrage de cet appareil. Si les uptimes sont inchangés mais que les rôles ont basculé, examinez d’abord le déclencheur HA, tel qu’un Monitored Port ou un problème de peer. Un changement manuel du rôle actif peut également redémarrer l’ancien Primary ; une éventuelle intervention d’un administrateur doit donc également figurer dans la chronologie.

Les logs HA sont stockés localement sur chaque nœud et ne sont pas synchronisés. Sur les deux appliances, au moins ces fichiers sont donc pertinents :

cd /log
less ha.log
less msync.log

ha.log montre la formation du cluster et les changements de statut, tandis que msync.log montre la synchronisation. Ne lancez pas un redémarrage simultané des deux nœuds et ne forcez pas un autre failover pour reproduire le problème. Le diagnostic complet des rôles et des liens est décrit dans Haute disponibilité Sophos Firewall.

Circonscrire la cause selon le contexte

Redémarrage planifié par un administrateur ou le firmware

Comparez d’abord le calendrier des changements, les fenêtres de maintenance, les actions des administrateurs, les tâches Sophos Central et les notifications avec l’heure de l’événement. Les changements de configuration précédents peuvent être classés grâce aux Audit Trail logs. Sophos Firewall génère des événements système pour un démarrage ainsi que pour restart ou shutdown via WebAdmin. Si les notifications par e-mail sont configurées, le message dans la boîte aux lettres peut également confirmer l’heure et le pare-feu émetteur.

Si le redémarrage s’est produit pendant un processus de firmware ou de hotfix, sauvegardez la version source, la version cible, le build, l’heure de la mise à jour et fwmgmt.log. Un redémarrage fait partie d’un changement normal de firmware ; plusieurs reboots non planifiés ou un build inattendu n’en font pas partie. Pour poursuivre la classification, utilisez la procédure Effectuer une mise à jour du firmware Sophos Firewall.

Kernel hang ou erreur logicielle

Lorsque auto-reboot-on-hang est activé, SFOS peut redémarrer automatiquement lorsque le kernel ne répond plus. La fonction améliore la disponibilité, mais ne laisse pas toujours une preuve locale sans équivoque de la cause. Documentez le statut affiché et ne le modifiez pas pendant le diagnostic. Circonscrivez le cas à l’aide de l’heure, des logs, de System graphs, du CTR et du build exact.

Dans SFOS 22.0 MR2 Build 546, Sophos a corrigé plusieurs cas indépendants de crash et de restart, notamment :

NC-180974 : kernel crash dans sdwan_profile avec failover HA
NC-178354 : kernel crash lors de la correspondance des règles SD-WAN
NC-178745 : redémarrage automatique d’un appareil HA en raison d’un out-of-memory
NC-180433 : crash répété avec du trafic multicast via un tunnel VPN

Ces issue IDs montrent pourquoi Le pare-feu a redémarré ne constitue pas encore un diagnostic. Le chemin de mise à niveau pris en charge vers MR2 Build 546 ou une version approuvée plus récente n’est vérifié que si le build, la fonction, le trafic et l’heure de l’erreur correspondent au cas documenté. Si l’erreur se reproduit sur ce build ou un build plus récent, elle ne doit pas continuer à être automatiquement attribuée à la même ancienne issue ID. Les autres correctifs sont classés dans l’aperçu de SFOS 22.0 MR2.

Ne reproduisez pas intentionnellement un kernel crash au moyen de tests de charge, de multicast, de modifications SD-WAN ou d’un failover forcé. Documentez la configuration et les schémas de trafic, puis évaluez-les avec Sophos Support.

Charge, espace disque ou stockage

L’historique de CPU, Memory, Load et Disk peut montrer si une anomalie persistante était déjà présente avant le reboot. Sophos mentionne en outre /log/system-monitor/cpu_trigger.log pour les états système enregistrés automatiquement en cas de charge CPU élevée. La documentation de SFOS 22 ajoute /log/system-monitor/memory_trigger.log en cas de charge mémoire élevée ; ce fichier ne doit pas être présumé présent sous SFOS 21.5.

Un disque plein, une forte charge I/O ou un défaut SSD sont des problèmes différents. Il ne faut donc pas supprimer des reports ou des logs sur la base d’un soupçon. Pour le contrôle en lecture et le nettoyage prévu, consultez Contrôler l’espace disque et les reports Sophos Firewall ; Contrôler l’état du SSD Sophos Firewall avec SMART explique l’état matériel du périphérique de stockage.

Alimentation, température ou matériel

Sur une XGS physique, contrôlez l’alimentation, les blocs d’alimentation, l’UPS/PDU, la température du rack, le flux d’air, les ventilateurs, les LED, le SSD et la console locale. L’absence de trace de shutdown propre peut correspondre à un événement électrique brutal, mais ne le prouve pas. La chronologie commune du pare-feu, de l’UPS/PDU, de la supervision et de l’environnement est déterminante.

Une température actuelle après le reboot ne constitue également qu’une valeur instantanée. Le contrôle de la température, des ventilateurs et de xgs-healthmond.log explique la branche des causes thermiques. Les erreurs récurrentes de démarrage, I/O, alimentation, NPU ou ventilateur doivent être ajoutées avec les données sauvegardées à la préparation d’un cas matériel et RMA.

Pare-feu virtuel ou cloud appliance

Pour une VM, contrôlez également au même moment les événements de l’hyperviseur, les redémarrages de l’hôte, la latence du datastore, les tâches de snapshot ou backup, les vCPU, la RAM, les disques et les vNIC. Pour AWS ou Azure, les événements de la plateforme, le statut de l’instance et les maintenances planifiées doivent figurer dans la chronologie de l’incident.

Un événement de l’hôte ou de la plateforme peut redémarrer la VM sans que SFOS en soit lui-même la cause. À l’inverse, un hyperviseur sans anomalie ne prouve pas que le guest est exempt d’erreurs. Les deux chronologies doivent donc être évaluées ensemble. Sophos Firewall comme matériel, VM ou cloud appliance explique les différences actuelles entre les plateformes et les ressources.

Contrôler le fonctionnement après le redémarrage

Une page de connexion accessible ne constitue pas encore un test de validation complet. Après la sauvegarde des preuves, contrôlez selon l’environnement :

Control Center sans nouvel avertissement de service, d’interface, de VPN ou de performance ; contrôler en outre System graphs et Notifications pour détecter les anomalies de Memory et Disk
WAN, routage, DNS et accès Internet via le chemin prévu
connexions VPN Site-to-Site et Remote Access importantes
publications centrales DNAT, WAF ou de serveurs
DHCP, RED et Wireless si le pare-feu fournit ces services
pour HA : Health, rôles, synchronisation et uptime des deux nœuds
nouvelles erreurs système, kernel ou matériel depuis le démarrage

Les principaux flux métier réels doivent être testés délibérément et documentés avec l’heure. Si l’uptime reste stable, cela montre uniquement qu’aucun autre reboot ne s’est produit. La cause initiale n’est considérée comme élucidée que lorsque la chronologie, les logs et les observations de la plateforme fournissent une explication fiable.

Préparer le cas de support et la détection future

Un ticket de support Sophos est approprié si le reboot reste inexpliqué, se reproduit, a provoqué une panne HA ou d’un site, ou si des indices concernent le kernel, la mémoire, le stockage, le NPU ou le matériel. Le dossier doit contenir l’heure de l’incident avec fuseau horaire, la plateforme, le build complet, l’uptime, les fonctions affectées, les dernières modifications, les rôles HA, le CTR, les logs pertinents complets et la chronologie externe de l’alimentation ou de l’hyperviseur.

Une supervision préparée améliore les preuves disponibles lors de l’incident suivant :

Faire envoyer des notifications par e-mail pour System started, Restart/Shutdown et les changements de statut HA.
Envoyer les événements système et HA à Syslog ou SIEM afin de préserver la chronologie en dehors du pare-feu.
Superviser l’uptime et l’état du matériel via la supervision SNMP.
Exploiter les alertes UPS/PDU, hyperviseur et cloud avec le même serveur de temps et une attribution claire au site.

Lors du prochain événement, il sera ainsi plus rapide de déterminer si SFOS lui-même, un nœud individuel, la plateforme ou l’environnement électrique et matériel a provoqué la panne.