Sophos Firewall en mode failsafe : vérifier la cause

Lorsqu’un Sophos Firewall démarre en mode failsafe, SFOS a détecté une erreur critique et n’a pas lancé le fonctionnement normal. Selon la cause, le traitement des paquets, les interfaces et l’accès d’administration peuvent être totalement ou partiellement indisponibles. Un port d’administration encore accessible ne permet donc pas de conclure que le firewall continue d’assurer une protection fiable.

La première étape essentielle n’est pas un Factory Reset ou un reimage, mais la conservation de la cause détectée par SFOS :

1. Se connecter via la console locale, série ou de l’hyperviseur.
2. Ouvrir Device Console dans le menu failsafe.
3. Exécuter la commande en lecture seule suivante :

show failure-reason

La console peut ensuite afficher, par exemple :

failsafe> show failure-reason
Unable to apply Firewall Framework

failsafe> est uniquement le prompt et ne doit pas être saisi. Le message exact peut être différent. L’essentiel est de photographier ou de copier la sortie inchangée et les premières lignes visibles de la console. Si SSH fonctionne encore pendant l’incident, Device Console est également accessible par ce moyen ; en cas de panne, la console locale, série ou de l’hyperviseur reste la méthode la plus robuste.

⚠️ Conserver les informations avant un redémarrage : Un reboot peut modifier ou faire disparaître temporairement la situation d’erreur visible. Avant le redémarrage, documenter au minimum le message d’erreur, la version SFOS avec le build, le rôle de l’appliance et l’heure. Reset to Factory Defaults, Remove Firewall Rules et les interventions manuelles sur la base de données ou le système de fichiers ne constituent pas un diagnostic et peuvent détruire une configuration ou des preuves importantes.

Ce que signifie le mode failsafe

Failsafe est un état de protection et de récupération. SFOS l’active lorsqu’un composant indispensable au fonctionnement sécurisé du firewall ne démarre pas correctement. Les messages connus et les incidents réels concernent, par exemple, la base de données de configuration, le framework du firewall, le jeu de règles, le service de logging ou réseau, la base de données de signatures ou, sur un modèle XGS équipé à cet effet, la Network Processing Unit (NPU). Cette liste ne constitue pas une matrice de réparation complète ; la sortie concrète de la console reste déterminante.

Un WebAdmin inaccessible ne prouve pas à lui seul un état failsafe. Si le trafic continue de passer et que seule l’interface ne répond plus, commencer par la vérification ciblée ou le redémarrage de la GUI WebAdmin. Un véritable état failsafe se reconnaît sur la console. Le fait qu’un accès d’administration ou certaines interfaces fonctionnent encore en parallèle dépend de la cause et ne prouve pas que le système est sain.

Cette distinction est importante : lorsqu’un seul service est en panne, un redémarrage ciblé de ce service peut être approprié. En mode failsafe, en revanche, une condition de démarrage critique fait défaut. Redémarrer plusieurs services sur la base de simples suppositions risque alors davantage de masquer la cause que de la corriger.

Vérifier la cause du failsafe avec show failure-reason

show failure-reason doit être exécuté dans Device Console, et non dans Advanced Shell. La commande ne modifie aucune configuration. Elle affiche la catégorie d’erreur détectée par SFOS au démarrage.

La sortie constitue un point de départ et non une procédure de réparation complète. Les groupes de messages suivants facilitent la classification :

• Configuration database : Le firewall n’a pas pu démarrer correctement sa base de données de configuration. Avant toute réparation manuelle, conserver le message d’erreur, le build, la dernière modification et la sauvegarde disponible. Ne pas supprimer ni modifier les fichiers de la base de données.
• Firewall framework ou firewall rules : SFOS n’a pas pu appliquer la base du traitement des paquets ou le jeu de règles. Les dernières modifications de règles, d’objets, de restore ou de firmware sont pertinentes. Supprimer toutes les règles de firewall sans distinction entraînerait une perte de données et ne constituerait pas un diagnostic initial approprié.
• Logging daemon : Un service de logging critique n’a pas démarré. Outre le message d’erreur, vérifier l’état du stockage, le build et les logs. Ne pas effacer aveuglément les reports ou les logs avant d’avoir conservé les données nécessaires.
• Network daemon : Des composants réseau n’ont pas pu démarrer correctement. Pour les appliances virtuelles, les vNIC existantes, l’ordre des adaptateurs et les modifications de l’hyperviseur doivent faire partie de la vérification.
• Signature database : Une base de données de signatures indispensable n’a pas pu être chargée. Le statut des patterns, le stockage et la chronologie par rapport aux mises à jour sont pertinents ; ne pas supprimer manuellement les fichiers de signatures.
• NPU : Sur un modèle XGS équipé d’une NPU, la première ligne de la console peut déjà indiquer Network processing unit error. Même si show failure-reason ne fournit ensuite aucune sortie exploitable, conserver l’intégralité de la console et préparer un dossier de support ou de matériel.

La formulation exacte d’un message peut varier selon la version de SFOS. Pour le support, la sortie inchangée est donc plus utile qu’un résumé rédigé soi-même tel que Le firewall ne démarre pas.

Vérifier la plateforme et la dernière modification

L’étape suivante dépend de la plateforme concernée : matériel, appliance virtuelle ou logicielle, ou cluster HA. Le même message d’erreur ne doit pas conduire automatiquement à la même action.

Firewall virtuel et appliance logicielle

Un firewall virtuel peut passer en mode failsafe simplement à cause de ressources inadaptées. Pour les appliances SFOS 22 exploitées localement sous VMware, Hyper-V, KVM et Citrix, Sophos indique actuellement les valeurs minimales suivantes :

• 1 vCPU
• 4 GB vRAM
• 2 vNICs
• 32 GB Primary Disk
• 80 GB Report Disk

En outre, les vCPU et la vRAM configurés ne doivent pas dépasser la licence achetée. Les valeurs minimales sont uniquement des limites techniques de démarrage et ne constituent pas un dimensionnement de production pour IPS, TLS Inspection ou un débit élevé.

L’Auxiliary Disk incluse dans les images VM correspond à cette Report Disk distincte. Elle n’est pas facultative et ne remplace pas la Primary Disk. Pour AWS et Azure, utiliser à la place les types d’instances cloud pris en charge et les tailles propres à la plateforme.

Dans l’hyperviseur, vérifier que les deux disques et toutes les vNIC prévues sont toujours présents, connectés et affectés dans l’ordre attendu. Toute modification ultérieure du CPU, de la RAM, du contrôleur de disque ou du réseau virtuel doit également figurer dans la chronologie de l’incident. Les différences entre les plateformes et les exigences en matière de ressources sont présentées plus en détail dans un article distinct.

Pour une appliance logicielle SFOS 22, l’architecture x86-64, le mode Legacy BIOS, au moins 4 GB de RAM et deux cartes réseau ne font pas débat. En revanche, deux pages Sophos actuelles se contredisent à propos du disque : la présentation générale des plateformes indique un minimum de 10 GB, tandis que la page plus récente consacrée à l’appliance logicielle indique un minimum de 32 GB et en recommande 64 GB. Il n’existe donc aucune limite Sophos uniforme publiée. Pour les nouvelles installations, Avanet recommande par prudence au moins 32 GB et, si possible, 64 GB ; cette recommandation suit la page produit la plus spécifique et évite un système déjà à court d’espace au démarrage.

Ne pas modifier arbitrairement les ressources à plusieurs reprises pendant une tentative de récupération dont la cause reste incertaine. Documenter d’abord l’état actuel, puis effectuer une correction planifiée avec un test de démarrage défini.

Appliance matérielle et NPU

Sur un XGS physique, tenir également compte des événements d’alimentation, de la température, des ventilateurs, des erreurs SSD ou I/O et des premiers messages de démarrage. Une erreur NPU sur un modèle XGS qui en est équipé ne justifie pas d’essayer des commandes de reset ou de service non documentées. Si le message se répète ou si le diagnostic lui-même échoue, la prochaine étape appropriée consiste à ouvrir un dossier de support avec une éventuelle préparation de RMA.

Un seul redémarrage réussi ne prouve pas qu’un problème matériel est résolu. En cas de pannes répétées, les contrôles existants portant sur la température et les ventilateurs et sur l’état du SSD apportent des informations supplémentaires.

Failsafe dans un cluster HA

Pour HA, déterminer d’abord quel Node est concerné et si le peer traite le trafic de production de manière stable. Documenter Primary ou Auxiliary, l’état du cluster, le dernier changement de rôle et la même heure sur les deux appliances.

Ne pas redémarrer les deux Nodes simultanément et ne pas désactiver HA sur la base de simples suppositions. Une modification non coordonnée peut menacer le chemin encore opérationnel, modifier la répartition des rôles ou forcer une reconstruction. Configurer High Availability sur Sophos Firewall explique les rôles, la synchronisation et les logs propres aux Nodes ; la cause précise du failsafe doit néanmoins être conservée sur le Node concerné.

Après une mise à jour du firmware ou un restore

Si le mode failsafe apparaît immédiatement après un upgrade, un rollback ou un restore, consigner la version source, la version cible et le numéro de build complet. Dans SFOS 22, Sophos a corrigé avec MR2 Build 546 plusieurs causes précises de failsafe, notamment des erreurs après l’upgrade vers GA, un logging daemon qui ne démarrait pas, une partition de configuration pleine et certains objets de service défectueux. La présentation de SFOS 22 MR2 indique les Issue ID corrigés.

Cela ne signifie pas que chaque événement failsafe se résout par une mise à jour. Vérifier d’abord si le message d’erreur et le build installé correspondent réellement à un correctif connu. Un changement de firmware nécessite toujours une sauvegarde, une fenêtre de maintenance, un plan HA et un chemin de retour. Utiliser pour cela la préparation d’une mise à jour du firmware et le contrôle de l’upgrade vers SFOS 22.

Failed to start Red server service

Si le pare-feu affiche exactement ce message en mode failsafe, le symptôme correspond à NC-178906. Sophos a corrigé cette erreur de failsafe dans SFOS 22.0 MR2 Build 546. Sur un build antérieur, évaluer après la conservation des preuves un chemin contrôlé de récupération et d’upgrade vers le build 546 ou une version ultérieure. Si le message apparaît avec le build 546 ou une version ultérieure, l’Issue ID ne suffit pas à prouver la cause ; ouvrir un dossier de support avec les logs conservés.

Avant un redémarrage ou un changement de firmware, conserver le numéro de build complet, l’heure de la panne, le Node HA concerné ainsi que les entrées de sysinit.log, red.log et syslog.log correspondant à l’heure de la panne. Ne pas supprimer sur la base de simples suppositions les interfaces RED, le modèle de firmware RED ou la configuration RED, et ne pas redémarrer plusieurs fois le service RED. Si le pare-feu démarre normalement et qu’un seul tunnel RED reste offline, utiliser plutôt le dépannage RED.

Conserver les preuves avant la récupération ou le redémarrage

Pour permettre une analyse fiable, collecter si possible les éléments suivants avant la première action modifiant l’état :

• sortie complète de show failure-reason et premières lignes de démarrage visibles
• modèle, numéro de série et plateforme matérielle, virtuelle ou logicielle
• version SFOS exacte, y compris MR et build
• heure de la panne et dernière heure de fonctionnement connue
• dernières modifications apportées au firmware, au restore, aux règles, aux objets, aux interfaces, aux ressources VM ou au stockage
• pour HA : Node concerné, rôle, état du peer et heure du dernier failover
• sauvegarde actuelle disponible et Secure Storage Master Key associée
• pour les VM : vCPU, vRAM, vNIC, Primary Disk, Report Disk et limite de licence
• symptômes récurrents tels que reboots ou erreurs I/O, NPU, de température ou de stockage

Si Advanced Shell reste accessible, des extraits de logs appropriés peuvent également être conservés. Ces exemples lisent uniquement les 200 dernières lignes et ne modifient pas le système :

tail -n 200 /log/sysinit.log
tail -n 200 /log/syslog.log
tail -n 200 /log/postgres.log

sysinit.log est le log central du démarrage du système, syslog.log contient les événements du noyau et du système, et postgres.log est utile pour la base de données de configuration. Selon show failure-reason, appliquer la même commande tail en lecture seule au log détaillé correspondant, par exemple :

tail -n 200 /log/networkd.log
tail -n 200 /log/sigdb.log
tail -n 200 /log/npu-startup.log

networkd.log concerne les interfaces physiques et virtuelles, sigdb.log la base de données de signatures et npu-startup.log uniquement les modèles matériels équipés d’une NPU. Tous les fichiers n’existent pas sur toutes les plateformes. L’affectation complémentaire est indiquée dans Services et fichiers de logs de Sophos Firewall. Les extraits de logs peuvent contenir des données confidentielles et doivent être transmis de manière protégée.

Lorsque WebAdmin redevient accessible, conserver également une archive CTR ou de troubleshooting. La procédure est décrite dans Conserver les logs Sophos Firewall pour le support.

Choisir la prochaine étape sûre

Une fois les preuves conservées, le chemin de récupération peut être choisi plus précisément :

1. Écart de ressources évident sur une VM ou une appliance logicielle : Documenter l’état actuel, vérifier les limites de licence et les valeurs minimales actuelles, arrêter la VM de manière contrôlée, corriger exactement l’écart confirmé et observer le prochain démarrage.
2. Indication liée au stockage ou au logging : Vérifier la partition et le type de données concerné en lecture seule. Ne pas supprimer de fichiers avec rm. Vérifier en sécurité l’espace de stockage et les reports présente les méthodes prévues pour le diagnostic et le nettoyage.
3. Erreur immédiatement après un changement de firmware : Comparer le build avec les problèmes connus, puis seulement décider de manière contrôlée entre le Maintenance Release actuel, un rollback ou le support.
4. Indication NPU, I/O ou matérielle récurrente : Préparer un dossier de support et, si nécessaire, une RMA. Un reboot temporairement réussi n’exclut pas un défaut.
5. Erreur de démarrage de la base de données, du framework, des règles ou erreur inconnue : Conserver la sortie et les logs, puis ouvrir un dossier Sophos Support avec la description complète de l’erreur. Ne pas supprimer manuellement les fichiers de base de données, les jeux de règles ou les signatures.
6. Reimage comme méthode de récupération : Ne l’utiliser que si une corruption du système d’exploitation, le support ou le plan de récupération documenté justifie cette approche. La sauvegarde, le mot de passe et la SSMK doivent être disponibles au préalable. La procédure complète est décrite sous Réinstaller le système d’exploitation Sophos Firewall.

Après chaque action, ne pas vérifier uniquement WebAdmin. Les critères décisifs sont le démarrage normal de la console, l’état HA correct, l’état des interfaces et du routage, les connexions Internet et VPN, ainsi que la réapparition éventuelle du même message d’erreur. Si la cause reste incertaine ou se reproduit, ne pas la masquer par d’autres modifications spontanées.