Sophos Firewall en mode failsafe : agir en toute sécurité

Lorsqu’un Sophos Firewall signale failsafe, il faut traiter la situation comme un incident de récupération. La documentation publique de SFOS 22 ne décrit aucune commande de diagnostic générale capable d’identifier de façon fiable la cause de chaque état failsafe. Ce runbook n’utilise donc volontairement ni show failure-reason ni une commande de remplacement inventée.

Conserver d’abord le message affiché sans le modifier, puis examiner la plateforme, le rôle HA, le build du firmware et la dernière modification. Tant que la cause n’est pas prouvée, ne modifier manuellement ni bases de données, ni signatures, ni règles, ni fichiers système.

⚠️ Documenter avant de redémarrer : Un redémarrage peut modifier l’erreur visible. Photographier toute la console, y compris les premiers messages de boot, puis noter l’heure, le modèle, le numéro de série, la version SFOS complète avec son build et, en HA, le Node concerné. Reset to Factory Defaults, Remove Firewall Rules et les interventions manuelles sur la base de données ou le système de fichiers ne sont pas des diagnostics initiaux sûrs.

Capturer le message failsafe en sécurité

1. Utiliser la console directe disponible : locale ou série pour le matériel, console de l’hyperviseur pour une VM. Elle reste utilisable lorsque WebAdmin ou le réseau sont inaccessibles.
2. Photographier mot pour mot le message et les lignes de boot qui le précèdent. Ne pas remplacer le message réel par un exemple trouvé sur Internet.
3. Noter plateforme et modèle, numéro de série, build SFOS complet, heure de la panne et dernière heure de fonctionnement connue.
4. Consigner les modifications récentes, notamment upgrade du firmware, rollback, restore, règles ou objets, ressources VM, disques virtuels, vNIC et événements de stockage.
5. En HA, noter le Node concerné, son rôle, l’état du peer et le dernier changement de rôle. Ne pas redémarrer les deux Nodes ensemble ni désactiver HA sur la base d’une supposition.

Un WebAdmin inaccessible ne prouve pas à lui seul un état failsafe. Si le firewall démarre normalement et que le trafic passe encore, mais que seule l’interface ne répond plus, commencer par le contrôle ciblé ou le redémarrage de la GUI WebAdmin. Un message failsafe explicitement affiché est en revanche traité comme un problème de démarrage ou de récupération.

Délimiter les causes documentées

Sophos documente plusieurs déclencheurs précis, mais non exhaustifs, pour SFOS 22. Les Release Notes de SFOS 22.0 MR2 Build 546 citent notamment une partition de configuration pleine (NC-181331), un logging daemon qui ne démarre pas sur l’appareil HA Primary (NC-180110), le passage en mode failsafe de l’appareil Primary initial après l’upgrade vers 22.0 GA (NC-177441) et Failed to start Red server service (NC-178906). Ces entrées établissent des défauts connus et corrigés, pas une matrice générale de réparation.

Si l’état observé, la plateforme ou le rôle HA et l’historique des versions correspondent précisément à une entrée des Release Notes, inclure l’Issue ID et le build installé dans le dossier de support. Une correspondance partielle ne prouve ni la même cause, ni qu’un changement de firmware non coordonné rétablira le firewall. Sophos ne cite le message affiché mot pour mot que pour NC-178906. Si le firewall démarre normalement et que seul un tunnel RED est hors ligne, suivre plutôt le dépannage RED.

Appliance logicielle

Pour une appliance logicielle SFOS 22 installée sur son propre matériel, Sophos fixe notamment les exigences minimales suivantes pour le système en fonctionnement et indique expressément que le firewall passe en mode fail-safe si elles ne sont pas respectées :

• CPU x86-64 et Legacy BIOS
• au moins 4 GB de RAM
• HDD ou SSD d’au moins 32 GB ; 64 GB sont recommandés
• 2 cartes réseau

Documenter l’état actuel avant toute modification. En cas d’écart confirmé, demander à Sophos Support si une adaptation de ressources prise en charge suffit ou si un reimage contrôlé est nécessaire. Ne pas improviser de modification du disque ou du mode de démarrage. Les différences entre plateformes et exigences de ressources détaillent les appliances matérielles, virtuelles et logicielles.

Appliance virtuelle et matérielle

Pour une VM, relever les vNIC et disques virtuels présents et connectés, le CPU, la RAM, le contrôleur de disque et les dernières modifications de l’hyperviseur. Les plateformes cloud et hyperviseurs ont leurs propres exigences prises en charge ; ne pas appliquer automatiquement les valeurs de l’appliance logicielle à tout déploiement virtuel.

Pour le matériel, joindre au dossier de support les erreurs de boot récurrentes, événements d’alimentation, indices I/O ou SSD, température et ventilateurs. Un redémarrage réussi n’exclut pas un défaut. Les contrôles de température et ventilateurs, d’état du SSD et la préparation de RMA aident à préparer le dossier.

Conserver les logs et la sauvegarde

Si Advanced Shell reste accessible, sysinit.log, syslog.log et, en cas d’indice lié à la base de données, postgres.log sont des logs de troubleshooting officiels pertinents. Pour le message RED documenté, ajouter red.log. Ce runbook ne fournit volontairement aucune commande shell pour copier, supprimer ou réparer : le chemin d’accès et les outils disponibles peuvent différer en état de récupération.

Lorsque WebAdmin redevient disponible, générer une archive de troubleshooting ou CTR. La procédure est décrite dans Conserver les logs Sophos Firewall pour le support. Les logs et archives peuvent contenir des données confidentielles de réseau, d’utilisateur et de configuration ; ils ne sont transmis de façon protégée qu’aux destinataires autorisés.

Avant un restore ou un reimage, disposer d’une sauvegarde appropriée, de son mot de passe et du Secure Storage Master Key associé. Sauvegarde et restore de Sophos Firewall explique ces dépendances.

Utiliser fsck-on-nextboot uniquement avec Sophos Support

system fsck-on-nextboot n’est pas un contrôle général de l’état du système. Sophos avertit qu’il ne faut l’utiliser que sur recommandation de Sophos Support. Il est destiné aux erreurs de montage de /sig, /conf ou /var ; si le matériel ou le SSD n’est pas sain, le contrôle peut endommager le système de fichiers.

La syntaxe documentée de Device Console est :

system fsck-on-nextboot [on | off | show]

on force le contrôle de toutes les partitions au prochain redémarrage, off l’annule avant ce redémarrage et show affiche la configuration actuelle ; la valeur par défaut est off. SFOS peut planifier automatiquement le contrôle en mode failsafe si la base de données de configuration, de rapports ou de signatures ne démarre pas, si une migration ne peut pas être appliquée ou si le deployment mode est introuvable.

Ne pas redémarrer uniquement parce que on est affiché. Intégrer d’abord au même plan de maintenance la recommandation du support, un accès console stable, l’alimentation, la sauvegarde, les éventuelles erreurs I/O et, en HA, l’état du peer. Sophos n’indique ni durée fixe ni garantie de réussite.

Choisir un chemin de récupération sûr

• Exigence logicielle clairement inférieure au minimum : Conserver l’état actuel, puis appliquer pendant une fenêtre de maintenance l’adaptation ou le reimage confirmé par Sophos Support. Observer le prochain démarrage sur la console.
• Message correspondant à un problème connu des Release Notes : Conserver le build complet et l’Issue ID. Faire confirmer par Sophos Support le chemin de récupération, d’upgrade ou de rollback adapté à cet état.
• Incident HA : Protéger le peer encore opérationnel. Pas de redémarrage simultané ni de changement imprévu de rôle ou de cluster. Voir High Availability sur Sophos Firewall.
• Erreur de stockage, base de données, règle, NPU, I/O ou inconnue : Ne retirer aucun fichier ou élément de configuration sur la base d’une supposition. Escalader à Sophos Support avec la console, les logs et la chronologie.
• Reimage : L’utiliser uniquement si Sophos Support ou un plan de récupération documenté le justifie et si toutes les conditions de restore sont réunies. Voir Réinstaller Sophos Firewall OS.

Après toute mesure, ne pas vérifier uniquement WebAdmin et la connexion. Contrôler le démarrage normal sur console, l’état HA, les interfaces, le routage et les connexions Internet et VPN requises. Si le message revient, ajouter l’heure et la sortie inchangée au dossier au lieu d’improviser d’autres modifications.

Escalader à Sophos Support

Escalader un incident failsafe dès que sa cause ne peut pas être limitée à un écart de ressources documenté et corrigible sans risque. Le dossier Sophos Support doit contenir au minimum :

• photo ou copie de tous les messages failsafe et de boot
• modèle, numéro de série, plateforme et build SFOS complet
• heure de la panne, dernière heure de fonctionnement et chronologie des modifications
• en HA : Node, rôle, état du peer et dernier changement de rôle
• logs pertinents ou CTR et indices de stockage, I/O, NPU ou alimentation
• sauvegarde disponible et état du mot de passe et de la SSMK, sans divulguer de secrets dans le ticket
• redémarrages ou modifications déjà effectués et leur résultat

Si WebAdmin est disponible et que Sophos demande un accès distant, activer temporairement Support access sous Diagnostics > Support access. Ne communiquer l’Access ID générée que par le canal de support convenu ; l’accès peut être désactivé à tout moment.