Mise à jour du micrologiciel Sophos Firewall : préparation et meilleures pratiques

Les mises à jour du micrologiciel maintiennent un Sophos Firewall sécurisé, stable et pris en charge. Néanmoins, vous ne devez pas la traiter comme une mise à jour normale d’un package. Une mise à niveau de SFOS peut affecter le comportement du HA, les tunnels VPN, les certificats, la protection Web, le TLS Inspection, l’accès à distance, l’intégration centrale et le routage.

Pour le contexte global de hardening, consulter le hub Sophos Firewall Hardening : bonnes pratiques pour une configuration sécurisée.

Cet article constitue la liste de contrôle de planification et d’exploitation avant une mise à jour du firmware Sophos Firewall. Il aide à décider si une mise à jour peut être validée maintenant, quelles dépendances doivent être contrôlées avant la fenêtre de maintenance et quand un rollback est plus judicieux que de poursuivre le dépannage. L’installation concrète via WebAdmin est décrite dans l’article Effectuer la mise à jour du firmware Sophos Firewall.

⚠️ Important : Avant chaque mise à jour du micrologiciel, une sauvegarde actuelle, la clé principale de stockage sécurisé appropriée et un plan de restauration testé sont requis. Pour SFOS 22 ou version ultérieure, l’article Vérification Sophos Firewall avant la mise à niveau de SFOS 22 doit également être traité car la plate-forme, l’espace de stockage, les noms d’interface, STAS et l’accès à distance hérité IPsec y sont spécifiquement vérifiés.

Quel article de mise à jour convient ?

Les sujets relatifs au micrologiciel se chevauchent rapidement. Il est donc important que les administrateurs choisissent d’abord le bon processus :

• Préparer les mises à jour, vérifier les risques et planifier les fenêtres de maintenance: Cet article
• Téléchargez ou installez l’image du micrologiciel dans WebAdmin: Sophos Firewall Effectuer la mise à jour du micrologiciel
• Préparez-vous à effectuer une mise à niveau vers SFOS 22 ou une version plus récente: Vérifiez Sophos Firewall avant la mise à niveau SFOS 22
• Vérifiez la sauvegarde, la clé principale de stockage sécurisé et la capacité de restauration: Sophos Firewall Créer ou restaurer une sauvegarde
• Réinstallez complètement le système d’exploitation du pare-feu ou restaurez-le après une réimage: Réinstaller le système d’exploitation Sophos Firewall : réimager avec une clé USB
• Planifier le cluster HA avant la maintenance, le basculement ou la mise à niveau: Variantes de cluster Sophos Firewall HA
• La tâche de mise à jour ou de pare-feu contrôlée de manière centralisée se bloque: Sophos Central Vérifier la file d’attente des tâches de gestion du pare-feu
• Évaluez la plateforme XG, SG ou XGS avant la mise à niveau: Sophos XG vs XGS : différences, fin de vie et migration
• Collecter le numéro de série, l’état de la licence ou les données de support pour le changement: Trouver le numéro de série du Sophos Firewall

Cette séparation évite les erreurs typiques. Une mise à jour du firmware n’est pas la même chose qu’une réimage, un rollback ne remplace pas un backup, et un téléchargement réussi ne prouve pas encore que le chemin d’upgrade, l’éligibilité au support, l’état HA et le plan de recovery sont corrects. Cet article de planification ne répète donc pas chaque clic de l’installation, mais clarifie surtout la décision de validation.

Lorsqu’une mise à jour doit être préparée

Une brève vérification est souvent suffisante pour les petites versions de maintenance. Une préparation structurée est obligatoire si au moins un de ces points s’applique :

• Pare-feu productif avec plusieurs liaisons montantes WAN, VPN, règles NAT ou publications WAF.
• Cluster HA ou emplacement distant sans accès physique facile.
• Saut de version sur plusieurs versions ou passage à une nouvelle version majeure telle que SFOS 22.
• XG, SG, logiciel, appliance virtuelle ou cloud avec des problèmes de plate-forme ou de licence.
• Dépendances critiques telles que Microsoft Entra ID, RADIUS, LDAP, Certificats, DNS, DHCP, SD-WAN ou Sophos Central.
• Problèmes connus de performances, d’espace de stockage ou de SSD sur l’appliance.

Plus le changement est important, plus la mise à jour doit être traitée comme un changement avec un runbook, un plan de test et une restauration.

1. Vérifiez les notes de version et le chemin de mise à niveau

Avant la mise à jour, vérifiez d’abord si la version cible correspond à l’environnement actuel.

• Vérifiez les Notes de version Sophos pour voir si la version cible est publiée et s’il existe des notes sur votre propre branche de version.
• Vérifiez également les notes de version officielles de la version cible et les Problèmes connus afin que les problèmes connus n’apparaissent pas seulement après la mise à jour.
• Documenter la version existante, la version cible et le chemin de mise à niveau pris en charge.
• Important : sélectionnez uniquement les chemins de mise à niveau pris en charge. Si le chemin de mise à niveau n’est pas pris en charge, le pare-feu peut être réinitialisé aux paramètres d’usine après la mise à jour du micrologiciel.
• Pour SFOS 22, notez que le matériel XG et SG n’est plus pris en charge.
• Pour SFOS 21.5, noter que tous les chemins cibles ne mènent pas automatiquement à SFOS 22 GA. Les release notes de la version cible précise font foi.
• Pour de nombreuses interfaces VLAN, Bridges, LAG, RED ou XFRM, vérifiez si les noms d’interface avec de longs blocs de chiffres peuvent déclencher un problème d’affichage WebAdmin.
• Pour Legacy Remote Access IPsec, vérifiez si une mise à niveau vers SFOS 22 MR1 ou une version plus récente est bloquée.
• Pour les règles STAS et basées sur l’utilisateur, vérifiez si les notes de mise à niveau connues sont pertinentes pour votre propre configuration.
• Pour les pare-feu logiciels, virtuels, Azure ou AWS BYOL, précisez si le pare-feu doit être revendiqué dans Sophos Central avant la mise à niveau.
• S’il y a des sauts de versions incompatibles, ne prévoyez pas une mise à jour normale, mais préparez plutôt un concept de réimage.

Pour les décisions concrètes de mise à niveau, ce ne sont pas les annonces qui comptent, mais plutôt les notes de version, les problèmes connus, les chemins de mise à niveau pris en charge et la planification locale du micrologiciel. Si une version semble intéressante, mais que le chemin de mise à niveau, la plate-forme, l’éligibilité au support ou la restauration ne sont pas clairs, la modification ne doit pas encore être publiée.

En pratique, une courte décision directement dans le changement a fait ses preuves : version actuelle, version cible, chemin pris en charge, bloqueurs connus, plateforme concernée et retour attendu. Il reste ainsi compréhensible plus tard pourquoi cette version précise a été installée, et pas simplement « la plus récente ».

2. Clarifier l’éligibilité à la licence et au support

Depuis SFOS 19.0 MR1, Enhanced Support ou Enhanced Plus Support est requis pour les mises à niveau régulières du firmware après les trois upgrades gratuits. Sans éligibilité de support adaptée, le firmware peut parfois être affiché ou téléchargé, mais les upgrades réguliers ultérieurs peuvent être bloqués.

Des exceptions s’appliquent, entre autres, aux mises à jour de modèles, à Hotfixes, à la réimage, aux mises à niveau obligatoires du micrologiciel et aux mises à niveau du micrologiciel de l’assistant. Toutefois, ces exceptions ne remplacent pas une bonne planification des mises à jour.

Avant d’effectuer le changement vous devez donc vérifier :

• Administration > Licensing affiche une licence valide et l’éligibilité au support.
• Sophos Central affiche le pare-feu avec le numéro de série correct.
• L’accès au support et les personnes de contact sont connus.
• Le téléchargement de la version cible est possible.
• Si nécessaire, un accès au support Avanet ou Sophos est préparé.

Si vous souhaitez qu’Avanet prenne en charge le changement, l’article Configuration de l’accès au support Avanet à Sophos Firewall est approprié.

3. Préparer le backup, le SSMK et le rollback

Une mise à jour du micrologiciel est installée sur un deuxième emplacement de micrologiciel. Un retour à la version précédente est donc souvent possible. Néanmoins, un rollback ne remplace pas une sauvegarde car l’état de la configuration, la compatibilité de la restauration et l’état de fonctionnement doivent être vérifiés séparément.

Le point le plus important est souvent sous-estimé : Sophos Firewall conserve le firmware actif et le firmware précédent avec l’état de configuration correspondant dans des partitions séparées. Un rollback ne remet donc pas seulement l’ancien code SFOS en service, mais aussi la configuration précédente. Les changements effectués après l’upgrade peuvent ensuite manquer ou produire un autre effet.

Avant la mise à jour :

• Téléchargez une nouvelle sauvegarde de configuration.
• Vérifiez la clé principale de stockage sécurisé dans le gestionnaire de mots de passe.
• Fournissez un mot de passe de sauvegarde et un accès administrateur.
• Documenter la version existante du micrologiciel et la version cible.
• Documentez la configuration actuelle, les captures d’écran critiques et l’heure de modification.
• Pour les modifications plus importantes, vérifier également un backup Central ou un backup stocké en externe.

Le processus de backup et de restore est décrit en détail dans Créer ou restaurer une sauvegarde Sophos Firewall. Si un changement normal de firmware n’est pas possible, l’article Réinstaller Sophos Firewall OS : reimage avec une clé USB aide.

À partir de SFOS 20.0, la firewall peut, lors de certains problèmes pendant la migration de configuration, revenir automatiquement à la version précédente et à l’état de configuration précédent. C’est une fonction de sécurité, mais pas une autorisation pour des mises à jour non préparées. Après un rollback automatique, la cause doit être clarifiée avant la tentative suivante.

4. Préparez une preuve de modification

Pour les versions de maintenance simples, une sauvegarde, une capture d’écran de la page du firmware et une courte note de modification suffisent souvent. Pour les mises à jour plus importantes, vous devez également enregistrer quelle configuration était valide avant la fenêtre de maintenance et quelles modifications ont été apportées lors de la vérification de suivi.

Ces outils répondent à des questions différentes :

• Backup : Quel état de configuration peut être restauré ?
• Config Studio : Quelles différences existent entre deux états de configuration ?
• Audit Trail : Qui a effectué quelle modification de configuration prise en charge, et quand ?

Sophos Firewall Config Studio est utile si vous souhaitez comparer les états de configuration avant et après une mise à niveau. Cela ne remplace pas une sauvegarde, mais cela aide à déterminer si des règles, des objets, des interfaces ou des politiques ont été modifiés de manière inattendue au cours d’une fenêtre de maintenance.

La Piste d’audit Sophos Firewall convient à la traçabilité temporelle. Cela s’avère particulièrement utile lorsque plusieurs administrateurs sont impliqués ou lorsqu’une modification contrôlée de manière centralisée s’est déroulée parallèlement à la mise à jour du micrologiciel. Si la mise à jour ou une modification de configuration est déclenchée via Sophos Central, la File d’attente des tâches de gestion du pare-feu Sophos Central fait également partie de la vérification de suivi.

5. Vérifiez l’espace de stockage et la santé du système

Un espace de stockage insuffisant, des journaux anciens ou un état HA instable peuvent rendre une mise à jour inutilement risquée. Avant une mise à niveau majeure, vous devez consciemment vérifier l’état du système.

Dans WebAdmin :

• Consultez le Centre de contrôle pour les avertissements.
• Ouvrez Sauvegarde et micrologiciel > Micrologiciel et vérifiez les versions disponibles.
• Vérifiez Diagnostics > Visionneuse de journaux pour les erreurs système récurrentes.
• Vérifiez les Services système et les services concernés.
• Pour SFOS 22, regardez également le pare-feu Health Check, si disponible.

L’espace de stockage libre peut être vérifié à l’aide de SSH ou Advanced Shell :

df -kh

Si une partition est très pleine, vous ne devez pas la mettre à jour aveuglément. Précisez d’abord si les anciens fichiers locaux, journaux, rapports ou sauvegardes de support occupent de l’espace. Si la cause n’est pas claire, une demande d’assistance est plus sûre que la suppression manuelle du Advanced Shell. Le processus pratique se trouve dans Sophos Firewall Vérifier l’espace de stockage et gérer les rapports.

Si l’appliance est ancienne, écrit de nombreux rapports locaux ou présente déjà des problèmes d’E/S ou de base de données, l’état de santé du SSD via SMART doit également être vérifié et documenté.

Sophos Firewall Dépannage : Services et journaux, Sophos Firewall Utiliser Packet Capture dans WebAdmin et [Sophos Firewall] aide pour l’analyse de l’état et des journaux Comment utiliser Health Check correctement](/fr/kb/sophos-firewall-health-check/).

6. Planifiez le cluster HA séparément

Les clusters HA ne doivent pas être traités comme des pare-feu individuels. Sophos écrit que HA n’a pas besoin d’être désactivé pour la mise à jour du micrologiciel. Néanmoins, une mise à jour HA nécessite plus de contrôle car les appareils, les emplacements de micrologiciel, les rôles et le comportement de basculement sont affectés.

Avant la mise à jour :

• Vérifiez l’état du HA dans WebAdmin.
• Identifier clairement les appareils principaux et auxiliaires.
• Vérifiez le lien et la synchronisation HA.
• Assurer la même situation initiale du firmware sur les deux appareils.
• Prévoir également des fenêtres de maintenance pour Active-Passive-HA.
• Communiquer la courte interruption prévue lors du changement de rôle.

Dans l’état HA connecté, la mise à jour du firmware est démarrée sur l’appareil Primary et traitée par le cluster pour les deux appliances. Typiquement, l’appliance Auxiliary est d’abord mise à jour et redémarrée, puis un changement de rôle a lieu, avant que l’ancien Primary soit mis à jour. Selon la configuration HA, le Primary préféré peut redevenir actif à la fin. L’appliance Auxiliary ne doit pas être mise à jour séparément. Pattern Updates et Hotfixes sont appliqués indépendamment aux appareils.

Pour les environnements HA, Sophos Firewall HA Cluster : Active-Passive, Active-Active and Auxiliary Appliance doit également être lu.

7. Définir les fenêtres de maintenance et les tests

Une bonne fenêtre de maintenance inclut non seulement le temps d’installation, mais également des tests clairs par la suite.

Définir avant la mise à jour :

• Heure de début, dernière heure d’abandon et décision de restauration.
• Personne responsable du pare-feu, du réseau, des serveurs, des applications et du support.
• Liste de tests pour Internet, DNS, DHCP, VLANs, NAT, VPN, WAF, Mail, Web Protection et applications critiques.
• Accessibilité via un port de gestion local ou un accès alternatif.
• Pause de surveillance ou mode maintenance dans le système de surveillance.
• Chemin de communication en cas d’échec de l’accès à distance lors du changement.

Les tests ne doivent pas consister uniquement en des pings. Pour les pare-feu productifs, les véritables contrôles de connexion sont plus importants : connexion VPN, accès aux applications internes, résolution DNS, accès Web, services publiés, flux de messagerie, routes SD-WAN et authentification centrale.

Si la mise à jour du firmware est planifiée via Sophos Central, le fuseau horaire de la firewall fait partie du changement. Sophos Central démarre les firmware upgrades planifiés selon le fuseau horaire de la firewall concernée. Pour des sites répartis à l’international, l’heure pertinente n’est donc pas l’heure locale du navigateur de l’administrateur, mais l’heure applicable à la firewall.

Par ailleurs, Sophos Central n’affiche les firmware upgrades que pour les firewalls appropriées. Si un bouton de téléchargement ou de planification manque dans Central, il ne faut pas supposer immédiatement une erreur d’interface. Vérifier d’abord : la firewall fonctionne-t-elle avec un firmware GA, est-elle en ligne, est-elle correctement gérée dans Central, l’éligibilité licence/support est-elle correcte et la version cible est-elle validée pour cette plateforme ?

8. Valider après mise à jour

Après le redémarrage, le changement n’est pas encore terminé. Vous devez d’abord vérifier si le pare-feu fonctionne réellement dans l’état attendu.

Juste après la mise à jour :

• Vérifiez la version active du SFOS.
• Vérifiez si le slot firmware attendu est actif et si un rollback automatique a eu lieu.
• Vérifiez l’état de la mise à jour de la licence et du modèle.
• Vérifiez les journaux du système et du noyau pour détecter les erreurs notables.
• Vérifiez les interfaces, les itinéraires SD-WAN, les tunnels VPN et l’état HA.
• Validez les règles de pare-feu, NAT, Web Protection, TLS Inspection et WAF avec des tests réels.
• Sophos Central Vérifier la synchronisation.
• Réactiver la surveillance.
• Ajouter une documentation sur les modifications avec les résultats, les délais et les écarts.

Si une mise à jour du micrologiciel a été planifiée ou déclenchée via Sophos Central, la File d’attente des tâches de gestion du pare-feu Sophos Central fait également partie de la vérification de suivi. Vous pouvez y vérifier si la tâche centrale a été exécutée avec succès ou si une tâche ayant échoué bloque les modifications ultérieures.

Si des erreurs inattendues se produisent après la mise à jour, la différence entre un problème de configuration, un bug du micrologiciel, un problème de licence et un problème de système externe doit d’abord être réduite. Log Viewer, Packet Capture et les journaux de service ciblés sont plus utiles que les redémarrages multiples immédiats.

Un rollback ne doit pas être déclenché par nervosité, mais pas trop tard non plus. Si WAN, HA, les VPN centraux ou les publications critiques pour la production ne peuvent pas être stabilisés dans la fenêtre d’analyse définie, le chemin de retour planifié est souvent plus propre que des corrections ponctuelles successives pendant une panne en cours. Si, en revanche, seule une règle, un objet ou un service externe est suspect, Log Viewer, Packet Capture et les service logs fournissent généralement une meilleure réponse.

Erreurs typiques avec les mises à jour du firmware

• Mise à jour sans nouvelle sauvegarde: La restauration ou la restauration devient inutilement risquée; Vérifiez la sauvegarde et SSMK avant de modifier
• Les notes de version ne sont lues que superficiellement: Les bugs connus, les bloqueurs de plateforme ou les chemins de mise à niveau non pris en charge sont ignorés; Documenter les notes de version de Sophos, les problèmes connus et le chemin de mise à niveau pris en charge
• Contrôle SFOS-22 ignoré: Les bloqueurs de plate-forme, d’espace de stockage, d’interface, STAS ou IPsec hérités ne sont remarqués que dans la fenêtre de maintenance; Avant SFOS 22 ou version ultérieure, effectuez la vérification de mise à niveau distincte
• HA supposé être sans panne: Le basculement peut interrompre les sessions et les connexions individuelles; Planifiez également la fenêtre de maintenance et le plan de test pour HA
• Pas d’accès d’urgence local: Le changement à distance peut rester bloqué sur le problème VPN ou WAN; Clarifier l’accès hors bande ou l’option sur site
• Ping testé uniquement: Les problèmes d’application, DNS, TLS ou VPN ne sont pas détectés; Définir les tests techniques par service
• Le retour en arrière a été décidé trop tard: Les temps d’arrêt deviennent plus longs que nécessaire; Déterminer à l’avance l’heure de résiliation et les critères de restauration
• Planification Central mal comprise: pour les mises à jour planifiées dans Central, le fuseau horaire de la firewall compte. C’est particulièrement important pour les sites dans d’autres pays.
• Central n’affiche aucune mise à jour firmware: la firewall n’est peut-être pas sur un firmware GA, n’est pas éligible, est hors ligne ou n’est pas adaptée à la version cible. Vérifier licence, statut Central, plateforme et release notes.

Liste de contrôle

• Version cible et chemin de mise à niveau vérifiés.
• Notes de version Sophos, notes de version officielles, problèmes connus et chemin de mise à niveau pris en charge vérifiés.
• SFOS 22 Vérification de mise à niveau effectuée sur les mises à niveau pertinentes, y compris la plate-forme, les noms d’interface, l’espace de stockage, STAS et l’accès à distance existant IPsec.
• Licence et support amélioré vérifiés.
• Sauvegarde téléchargée et SSMK disponible.
• Changez la preuve préparée avec Backup, Config Studio, Audit Trail ou Central Task Queue si plusieurs administrateurs ou Central sont impliqués.
• Espace disque et état du système vérifiés.
• Statut et rôles HA documentés.
• Fenêtre de maintenance, plan de test et critères de rollback définis.
• Pour les mises à jour Sophos Central, fuseau horaire de la firewall et heure planifiée vérifiés.
• Si le bouton de mise à jour Central manque, firmware GA, statut en ligne, licence, plateforme et version cible vérifiés.
• Fichier de micrologiciel ou téléchargement de l’interface graphique préparé.
• Accès à la gestion locale ou alternative clarifié.
• Version vérifiée, services, VPN, NAT, WAF, journaux, file d’attente de tâches centrale et surveillance après la mise à jour.

FAQ