Mise à jour du firmware Sophos Firewall : préparation et bonnes pratiques

Une mise à jour du firmware Sophos Firewall ne doit être approuvée qu’une fois le chemin d’upgrade, le backup, l’accès, l’état du système, HA et le plan de retour clarifiés. Effectuer une mise à jour du firmware Sophos Firewall décrit l’installation dans WebAdmin ou via Sophos Fusion (anciennement Sophos Central).

⚠️ Avant chaque mise à jour : Un backup récent, le Secure Storage Master Key correspondant et un plan de rollback concret doivent être disponibles. Pour SFOS 22 ou une version ultérieure, effectuer également le contrôle avant upgrade vers SFOS 22.

Approbation en dix points

Un changement de firmware est prêt lorsque les dix points suivants peuvent recevoir une réponse positive :

1. La version actuelle, la version cible et le chemin d’upgrade pris en charge sont documentés.
2. Les release notes et les known issues ont été vérifiés pour la plateforme et la configuration utilisées.
3. La licence et les droits au support autorisent l’installation.
4. Un backup récent, son mot de passe et le Secure Storage Master Key correspondant sont disponibles.
5. L’espace libre, l’état du système et, pour les modèles XGS Appliance concernés, le firmware SSD répondent aux exigences.
6. L’état, les rôles et la synchronisation HA sont corrects ; les deux nœuds remplissent les conditions.
7. La fenêtre de maintenance, les responsables, l’heure limite et les critères de rollback sont définis.
8. Un accès d’administration local ou alternatif est préparé.
9. Les tests WAN, VPN, DNS, NAT, WAF, authentification et applications centrales sont définis.
10. Le monitoring, la communication et les preuves du changement sont préparés.

Si l’un de ces points manque, la mise à jour ne doit pas être lancée sous la pression du temps. Reporter une fenêtre de maintenance coûte moins cher qu’un reimage ou une intervention sur site imprévus.

Vérifier la version, la plateforme et les droits

Un processus d’exploitation fixe vérifie au moins une fois par mois dans Sophos Fusion ou sous Backup & Firmware > Firmware si une mise à jour est disponible. Les nouvelles release notes et les maintenance releases annoncées doivent également être suivies activement. Chaque MR doit être intégré à la planification, car même une version de maintenance peut contenir des correctifs de sécurité importants. L’installation, les tests et le rollback restent effectués de manière contrôlée pendant une fenêtre de maintenance.

Release notes et chemin d’upgrade

Avant le changement, comparer la version SFOS actuelle, la version cible et le chemin pris en charge dans les release notes. Examiner également les problèmes connus concernant la plateforme, HA, VPN, le routage, l’authentification et les fonctions réellement utilisées.

Sophos Firewall peut afficher un avertissement pour un chemin de migration non pris en charge. Si le changement est tout de même confirmé, le firewall peut démarrer avec la Factory Configuration et perdre la configuration existante. Le rollback automatique ne protège pas contre un chemin d’upgrade non pris en charge. Utiliser uniquement un chemin approuvé ; pour un changement de version incompatible, un reimage suivi d’un restore constitue la méthode correcte.

⚠️ Limite de plateforme : SFOS 21.0 GA et les versions ultérieures ne prennent pas en charge les appliances matérielles XG et SG. Pour ces appareils, planifier une migration vers XGS Appliance avant l’upgrade.

Le contrôle de mise à niveau vers SFOS 22 documente les versions sources autorisant une mise à niveau directe et l’interprétation des blocages pour SFOS 22.0 MR2 Build 546. Cette matrice est propre à ce build et ne constitue pas un chemin universel pour SFOS 22 ; pour tout autre build cible, vérifier juste avant le changement les versions sources prises en charge et les blocages applicables dans les release notes en vigueur.

Deux blocages SFOS 22 doivent être explicitement exclus :

• SFOS 22.0 MR1 et versions ultérieures : Toute ancienne configuration Remote Access IPsec encore présente bloque l’upgrade. La traiter selon les instructions de migration Sophos en vigueur ; une simple désactivation ne suffit pas.
• SFOS 22.0 MR2 et versions ultérieures : L’ancien marquage VLAN configuré en CLI sur des interfaces bridge bloque l’upgrade. Identifier les bridges concernés et traiter d’abord cette configuration conformément aux release notes.

Le contrôle séparé couvre les autres sujets SFOS 22, notamment le stockage, les noms d’interfaces, STAS, le firmware SSD et la plateforme. Pour les autres versions cibles, leurs release notes actuelles font foi.

⚠️ Avant le premier upgrade vers SFOS 21 ou une version ultérieure : Sous Certificates > Certificate authorities, rechercher les noms de CA Let’s Encrypt réservés. Une entrée existante portant exactement le même nom peut interrompre la migration en raison de NC-146082. Ne pas supprimer la CA sans contrôle : sécuriser et vérifier d’abord le backup, la clé privée, les certificats dépendants et les services.

Licence et support

À partir de SFOS 19.0 MR1, trois passages gratuits vers des versions GA, MR ou EAP sont possibles sans Enhanced Support ou Enhanced Plus Support. Ensuite, le firmware peut toujours être téléchargé, mais pas installé ; Install est désactivé.

Les Pattern Updates, hotfixes, reimages, Mandatory Firmware Upgrades et Assistant Firmware Upgrades sont exemptés de cette règle de support. Avant la fenêtre de maintenance, vérifier malgré tout que :

• Administration > Licensing affiche la licence et les droits au support attendus.
• Sophos Fusion affiche le bon firewall et le bon numéro de série.
• La version cible et le téléchargement sont disponibles.
• L’accès au support, les contacts et la procédure d’escalade sont connus.

Si un accès externe est nécessaire pour le changement, le tester au préalable. Pour Avanet, voir Configurer l’accès support à Sophos Firewall.

Vérifier séparément les hotfixes automatiques

Les hotfixes ne sont ni un slot de firmware ni une Pattern Update. SFOS 22 recherche les hotfixes disponibles toutes les 30 minutes et les installe automatiquement par défaut. Sophos recommande de ne pas modifier ce réglage. Lire l’état dans la Device Console avant et après un changement de firmware :

system hotfix show

Pour SFOS 22, Sophos indique que les hotfixes déjà installés sont conservés après un firmware upgrade. En revanche, la liste propre à la version dans SFOS 23 est réévaluée après chaque changement de version, comme l’explique la section suivante. Si le contrôle montre que l’installation automatique est désactivée, déterminer d’abord qui l’a désactivée et pour quelle raison. En l’absence d’exception documentée, la réactiver :

system hotfix enable

system hotfix disable désactive uniquement l’installation automatique et ne constitue pas une étape générale de troubleshooting. Un état activé ne prouve pas non plus qu’un hotfix précis a déjà été appliqué ou que le chemin de téléchargement fonctionne. Pour une erreur concrète, vérifier également le build, l’heure, l’accès à Internet, les logs et la référence d’erreur Sophos.

SFOS 23 : attester les mises à jour de sécurité appliquées

Dans SFOS 23, Backup & firmware > Hotfix: Security updates affiche les mises à jour de sécurité par hotfix appliquées depuis le passage à la version SFOS actuellement en cours d’exécution. Les hotfixes corrigent le système en cours d’exécution sans firmware upgrade et ne doivent pas être confondus avec la liste des images de firmware disponibles. L’installation automatique des hotfixes doit être activée ; elle l’est par défaut. system hotfix show vérifie ce réglage, mais ne prouve pas qu’un correctif de sécurité précis a été appliqué.

Pour consigner les preuves du changement avant et après le changement de firmware :

1. Documenter la version SFOS active, son build et l’heure du contrôle, puis ouvrir la page Hotfix: Security updates.
2. Trier les entrées par date d’application et consigner les mises à jour correspondant au problème étudié. Pour les vulnérabilités décrites publiquement, la colonne Advisory renvoie à l’avis de sécurité correspondant. Les correctifs internes peuvent apparaître sans identifiant CVE ni lien Advisory.
3. En HA, inclure les deux appareils dans le contrôle après la mise à jour : le Primary actuel reçoit le hotfix, se synchronise avec l’Auxiliary, puis le hotfix y est également appliqué. Un contrôle réussi sur un appareil ne remplace pas la preuve pour le cluster.

Une vulnérabilité peut apparaître plusieurs fois, car plusieurs hotfixes peuvent être nécessaires pour la corriger complètement. Une seule entrée correspondante ne constitue donc pas une preuve générale de protection complète. Pour un correctif de sécurité précis, comparer les exigences de l’avis de sécurité correspondant avec le build en cours d’exécution et les mises à jour effectivement appliquées.

Notifications et logs : Sous System services > Notification list, dans la section Firmware, activer l’option Email pour Security updates. Aucune notification SNMP n’est disponible pour ces mises à jour. Les mises à jour de sécurité par hotfix apparaissent également dans le Log viewer ; leurs Audit Logs sont générés et transmis à Sophos Fusion pour Central Firewall Reporting. Ces indications concernant les notifications et les logs s’appliquent aux mises à jour de sécurité par hotfix, et non systématiquement à chaque correction par hotfix. L’absence d’un e-mail ne prouve donc à elle seule ni la réussite ni l’échec.

Après un changement de version : SFOS installe d’abord le nouveau firmware, puis applique les hotfixes disponibles pour cette version. La liste précédente des hotfixes est supprimée et remplacée par celle de la nouvelle version ; elle ne constitue pas une archive couvrant plusieurs versions. Le même correctif peut réapparaître parce qu’il a été appliqué indépendamment à la nouvelle version. Si des correctifs antérieurs sont déjà intégrés au nouveau firmware, ils peuvent ne pas apparaître comme entrées de hotfix distinctes.

Une liste vide signifie uniquement qu’aucune mise à jour de sécurité par hotfix n’a encore été appliquée et affichée pour la version actuelle. Elle ne prouve ni l’absence de protection, ni une protection complète, ni le bon fonctionnement de l’installation automatique. En cas de doute, vérifier conjointement la version active et le build, le réglage CLI, l’avis de sécurité, les release notes et les logs ; ne pas désactiver préventivement l’installation automatique ni décider d’un rollback sur la seule base d’une page vide.

Préparer le backup, la recovery et les preuves

Backup, SSMK et slots de firmware

Avant la mise à jour, télécharger un backup récent de la configuration et vérifier quel Secure Storage Master Key lui correspond. Consigner également dans le changement le mot de passe du backup, l’accès administrateur, la version de firmware active et la version cible.

Sophos Firewall conserve au maximum deux versions de firmware : une active et une inactive. Chaque partition possède son propre état de configuration. Un rollback active donc non seulement le firmware précédent, mais aussi sa configuration. Les changements effectués après l’upgrade peuvent être perdus lors du retour en arrière.

Le rollback automatique est disponible à partir de SFOS 20.0 pour certaines erreurs de migration de la configuration. Il s’agit d’une fonction de sécurité, mais elle ne remplace ni un backup ni l’analyse de la cause et n’est pas disponible pour un chemin d’upgrade non pris en charge.

Le processus complet est décrit dans Sauvegarder ou restaurer Sophos Firewall. Si un changement de version normal est impossible, voir Réinstaller Sophos Firewall OS avec une clé USB.

Définir à l’avance les critères de rollback

Avant le démarrage, définir la durée d’analyse d’une erreur et le moment où le retour commence. Un rollback est pertinent lorsque WAN, HA, les VPN centraux ou les publications critiques pour la production ne peuvent pas être stabilisés dans le délai convenu. Pour une règle, un objet ou un service externe isolé, un troubleshooting ciblé est souvent préférable.

Pour une Maintenance Release normale, un backup, une capture de la page du firmware, la fenêtre et le résultat des tests suffisent comme preuves. Pour les changements plus importants, Sophos Firewall Config Studio facilite la comparaison des configurations et l’Audit Trail consigne les changements effectués pendant la fenêtre de maintenance.

Vérifier l’état du système, le stockage et HA

Stockage et SSD

Avant un upgrade important, vérifier dans WebAdmin que :

• Control center n’affiche aucun avertissement critique non résolu.
• Backup & Firmware > Firmware affiche les slots de firmware attendus.
• Diagnostics > Log viewer ne contient aucune erreur système ou de migration récurrente.
• Les services concernés sont stables.
• Firewall Health Check ne contient aucun point ouvert susceptible d’affecter le changement.

Après la connexion SSH, ouvrir Device Management > Advanced Shell et vérifier l’espace libre :

df -kh

Si une partition est presque pleine, ne pas supprimer aveuglément des fichiers, logs ou reports dans Advanced Shell. Identifier d’abord la cause et utiliser la méthode de nettoyage documentée. Voir Vérifier le stockage de Sophos Firewall et gérer les reports.

SFOS 22 peut exiger de l’espace supplémentaire. Sur certains modèles XGS Appliance, le firmware SSD doit également être mis à jour au préalable ; WebAdmin affiche un message lorsque cela est nécessaire. Dans un cluster HA, chaque nœud est évalué séparément. Si une appliance ne remplit pas les conditions, elle peut bloquer l’ensemble de l’upgrade.

Pour les appliances anciennes ou présentant des problèmes d’I/O, de base de données ou de reports, vérifier également l’état du SSD avec SMART. Sans constat concret, les modifications manuelles des bases de données ou des systèmes de fichiers ne constituent pas une préparation utile.

Sophos mentionne un redémarrage avant l’upgrade uniquement comme moyen facultatif de vider le cache mémoire. Il ne s’agit pas d’une condition préalable et il provoque une interruption supplémentaire. Le redémarrage ne doit donc avoir lieu que dans la fenêtre de maintenance, après la sauvegarde des logs utiles et la confirmation du chemin de récupération de l’accès d’administration. Si le firewall présente une instabilité inexpliquée, l’upgrade est arrêté ; un redémarrage ne doit pas remplacer l’analyse de la cause ni donner temporairement l’impression que le système est sain.

Cluster HA

Il n’est pas nécessaire de désactiver HA pour une mise à jour normale du firmware. Avant l’approbation, les deux appliances doivent toutefois être connectées, synchronisées et clairement identifiées comme Primary et Auxiliary. Une mise à jour HA nécessite également une fenêtre de maintenance, car le failover peut interrompre brièvement certaines sessions, certains tunnels VPN ou certains pings.

Avant le démarrage, documenter :

• Les rôles, l’état HA et la synchronisation.
• L’état du lien HA.
• Les exigences de firmware, de stockage et de SSD des deux nœuds.
• L’accès d’administration alternatif.
• Le failover attendu et les brèves interruptions possibles.

L’appliance Auxiliary ne doit pas être mise à jour séparément. L’article d’exécution décrit la séquence exacte : mise à jour de l’Auxiliary, failover, puis mise à jour de l’ancien Primary. D’autres cas HA sont couverts dans Cluster HA Sophos Firewall : variantes et maintenance.

Les Pattern Updates sont installés sur le Primary puis synchronisés vers l’Auxiliary. Les hotfixes et leur état doivent être considérés séparément et vérifiés sur les deux appareils après la fenêtre de maintenance.

Planifier la fenêtre de maintenance, Central et les tests

Fenêtre de maintenance et accès

Une fenêtre de maintenance ne se limite pas à l’heure d’installation :

• Heure de début, heure limite et décision de rollback.
• Responsables du firewall, du réseau, des serveurs, des applications et du support.
• Contact local, accès out-of-band ou second chemin d’administration.
• Canal de communication en cas de panne WAN ou Remote Access.
• Mode maintenance pour le monitoring et les alertes.
• Ordre des tests pour les principaux processus métier.

Pour les sites distants, ne pas dépendre uniquement de Sophos Fusion ou de la connexion VPN existante. Si ce chemin précis tombe en panne pendant la mise à jour, un accès ou une procédure d’escalade définis doivent rester disponibles.

Planifier le firmware via Sophos Fusion

Les mises à jour du firmware gérées par Central sont préparées et suivies sous My Products > Firewall Management > Firewalls. La Task Queue concerne les stratégies de groupe et les tâches de configuration MDR/API ; elle n’affiche pas les mises à jour du firmware.

Seules les versions cibles ayant atteint la phase Available to all du processus de publication peuvent être installées via Central. Les mises à jour planifiées démarrent selon le fuseau horaire défini sur le firewall, et non selon l’heure du navigateur de l’administrateur. Pour les sites internationaux, consigner dans le changement le fuseau horaire, la fenêtre locale et la version cible.

Pendant l’upgrade, une icône d’état tourne à côté du firewall et disparaît à la fin. La version active du firmware doit néanmoins être vérifiée localement ensuite. En cas de rollback automatique, Central affiche un message correspondant à côté de la version.

Tests fonctionnels réels

Un ping seul ne prouve pas que le firewall fonctionne correctement après la mise à jour. Définir à l’avance des tests concrets avec source, destination et résultat attendu :

• Accès Internet et résolution DNS.
• DHCP, VLAN, uplinks WAN et routes SD-WAN.
• Site-to-Site VPN, Remote Access VPN et RED.
• Règles firewall, NAT et services publiés.
• WAF, Web Protection et TLS Inspection.
• LDAP, RADIUS, Microsoft Entra ID et autres authentifications centrales.
• Flux de messagerie et applications critiques.
• Syslog, SIEM et monitoring.

Valider après la mise à jour

Après le redémarrage, vérifier d’abord la version active et le slot inactif attendu sous Backup & Firmware > Firmware. Ensuite :

• Contrôler les nouveaux avertissements ou un rollback automatique dans Control center.
• Vérifier les interfaces, WAN, SD-WAN, les rôles HA et la synchronisation.
• Valider VPN, RED, DNS, DHCP, règles, NAT, WAF et authentification avec les tests préparés.
• Contrôler l’état des patterns et des hotfixes.
• Vérifier la synchronisation Sophos Fusion ainsi que le monitoring, syslog et SIEM.
• Consigner le résultat, les horaires, les écarts et les éventuels travaux de suivi dans le changement.

Si une seule fonction échoue, utiliser d’abord Log Viewer, Policy Test, Packet Capture et les service logs concernés. Voir Tester une règle firewall avec Log Viewer, Policy Test et Packet Capture et Troubleshooting Sophos Firewall : services et logs.

FAQ