Vérification avant la mise à niveau vers SFOS 22 de Sophos Firewall

SFOS 22 introduit des changements architecturaux importants dans Sophos Firewall. Pour les administrateurs, il est donc essentiel de savoir non seulement quelles nouvelles fonctionnalités seront disponibles après la mise à jour, mais surtout si leur pare-feu peut être mis à jour correctement vers SFOS 22.

Ce guide sert de vérification préalable à la mise à niveau. Cet article ne remplace pas le guide général de mise à jour du firmware de Sophos Firewall, mais le complète avec des points qui peuvent rapidement poser problème avec SFOS 22 : plateforme supportée, noms d’interfaces, espace de stockage, sauvegarde, état du HA, IPsec Remote Access Legacy, IPsec basé sur des politiques, NAT et plan de retour en arrière.

Guide vidéo

Quand cette vérification est-elle utile

La vérification doit être effectuée avant chaque mise à niveau planifiée vers SFOS 22 ou une version ultérieure. Elle est particulièrement importante si l’une des situations suivantes s’applique :

• le pare-feu fonctionne encore sur du matériel XG ou SG
• l’appliance a déjà été mise à jour sur plusieurs versions majeures
• il y a de nombreux VLANs, alias, ponts, LAGs, interfaces RED ou XFRM
• il s’agit d’une petite appliance de bureau, d’un pare-feu virtuel ou d’une appliance logicielle
• le pare-feu fonctionne dans un cluster HA
• le VPN IPsec Remote Access est ou a été utilisé dans le passé
• IPsec Site-to-Site basé sur des politiques, règles SNAT spécifiques ou règles VPN-NAT sont en usage
• STAS ou une autre authentification basée sur l’utilisateur contrôle des règles de pare-feu productives
• le pare-feu est géré via Sophos Central ou doit être mis à jour via celui-ci

Si le pare-feu est déjà instable au quotidien, que des services doivent être redémarrés régulièrement ou que les partitions sont fortement remplies, la mise à niveau ne doit pas être considérée comme une tentative de réparation. Dans ce cas, stabilisez d’abord l’état actuel et identifiez la cause.

1. Vérifier la plateforme et le chemin de mise à niveau

SFOS 22.0 et les versions ultérieures ne prennent plus en charge les appliances matérielles XG et SG. Ceux qui exploitent encore ces appareils doivent d’abord planifier la migration vers XGS, un pare-feu virtuel, une appliance logicielle ou un déploiement cloud. Pour décider entre les anciennes et les nouvelles générations de matériel, l’article Quelle est la différence entre un pare-feu XG et XGS ? peut aider.

Sur les plateformes supportées, il faut également vérifier à partir de quelle version la mise à jour est effectuée. Les notes de version de SFOS 22 indiquent quelles versions peuvent être migrées directement vers SFOS 22. Si un chemin non supporté est choisi, le pare-feu peut démarrer avec une configuration d’usine après confirmation. Ce risque doit être exclu avant une fenêtre de maintenance.

Procédure pratique :

1. Noter la version actuelle du firmware sous Backup & Firmware > Firmware.
2. Documenter le modèle, le numéro de série et le type de plateforme.
3. Vérifier dans les notes de version officielles de Sophos si le chemin de mise à niveau direct est supporté.
4. Pour le matériel XG ou SG, ne plus traiter la planification de SFOS 22 comme une mise à jour normale, mais comme un projet de migration.

2. Vérifier les noms d’interfaces avant la mise à niveau

Un point de mise à niveau facilement négligé concerne les noms des interfaces. Les interfaces physiques ou logiques peuvent ne pas être visibles ou dépliables dans la vue WebAdmin sous Network > Interfaces si un nom d’interface, un nom de matériel ou un nom de branche se termine par dix chiffres ou plus.

C’est désagréable car le trafic peut continuer à être traité, mais l’administration dans WebAdmin semble soudainement montrer que des interfaces manquent. Cela doit être vérifié avant la mise à niveau, surtout lors de migrations, de schémas de nommage automatisés, de configurations importées ou de noms de VLAN avec des numéros de site, de client ou d’inventaire.

Exemples critiques :

Procédure pratique :

1. Ouvrir Network > Interfaces.
2. Vérifier les interfaces physiques, VLANs, alias, ponts, LAGs, interfaces RED et XFRM.
3. Rechercher des noms se terminant par dix chiffres ou plus.
4. Modifier les noms concernés avant la mise à niveau pour une écriture plus courte ou clairement séparée.
5. Après la modification, vérifier si les règles de pare-feu, les règles NAT, les routes SD-WAN, DHCP, VPN et la documentation sont toujours compréhensibles.

Il est préférable d’avoir des noms où les chiffres ne sont pas un long bloc à la fin. Par exemple, au lieu de VLAN_1234567890, VLAN-1234567890-Client ou un nom fonctionnel comme Client-VLAN-100 est plus lisible et opérationnellement plus robuste.

Si après une mise à niveau, des interfaces manquent dans la vue WebAdmin, ne supposez pas immédiatement que la configuration réseau est perdue. Vérifiez d’abord si le comportement correspond au problème de nom d’interface, si le trafic continue de circuler et si les noms concernés doivent être ajustés. Pour la planification générale des interfaces, consultez Configurer les zones et interfaces de Sophos Firewall.

3. Vérifier l’espace de stockage et les indications du firmware

SFOS 22 nécessite un espace de stockage supplémentaire pour les nouvelles fonctionnalités et les changements architecturaux. La plupart des appliances répondent aux exigences, mais certains déploiements de bureau, virtuels et logiciels peuvent nécessiter une vérification ou une correction manuelle. Si le pare-feu affiche un message concernant les exigences d’espace de stockage sur la page Control Center ou Firmware, il ne doit pas être ignoré.

Via SSH, vous pouvez vérifier grossièrement le niveau de remplissage des partitions :

df -kh

La sortie ne remplace pas une vérification de compatibilité Sophos, mais aide à évaluer si /, /var, /content ou d’autres partitions sont remarquablement pleines. Si une partition est très serrée, ne mettez pas simplement à jour à l’aveugle. Clarifiez d’abord quelles données y sont stockées, si des journaux ou des fichiers anciens peuvent être nettoyés et si un avis Sophos existe pour l’appliance concernée.

La planification du temps est également importante : si le pare-feu doit ajuster les partitions pendant la mise à niveau, la mise à jour peut prendre plus de temps qu’une version de maintenance normale. La fenêtre de maintenance ne doit donc pas être planifiée trop serrée.

4. Préparer la sauvegarde et la récupération

Avant la mise à niveau, une sauvegarde récente est nécessaire. Cela peut sembler banal, mais c’est crucial pour les versions majeures. La sauvegarde doit non seulement être créée, mais aussi être trouvable, déchiffrable et attribuable à un appareil spécifique. L’article Créer ou restaurer une sauvegarde de Sophos Firewall explique les points clés concernant la sauvegarde, la restauration et la clé maître de stockage sécurisé.

Avant SFOS 22, au moins ces points doivent être accomplis :

• créer une sauvegarde de configuration actuelle et la stocker à l’extérieur
• documenter la clé maître de stockage sécurisé si des sauvegardes chiffrées sont utilisées
• vérifier l’accès administrateur local et via le réseau de maintenance
• vérifier le statut de la licence et l’accès à Sophos Central
• garder à portée de main l’image du firmware actuel et le firmware cible
• définir la décision de retour en arrière : quand attendre, quand revenir en arrière

Pour les sites critiques, il doit également être clair qui a accès à l’appliance sur place et comment effectuer une réinstallation si nécessaire. La réinstallation est une procédure différente d’une mise à jour de firmware normale. Pour cela, il existe le guide séparé Réinstaller Sophos Firewall OS.

5. Définir le Go/No-Go avant la fenêtre de maintenance

Une mise à niveau SFOS-22 ne doit pas être décidée pendant la fenêtre de maintenance. Il doit être clair à l’avance dans quelles conditions commencer, attendre, annuler ou revenir en arrière. Cela réduit les décisions précipitées si le pare-feu prend plus de temps, si un nœud HA ne se synchronise pas ou si un service critique ne fonctionne pas après le redémarrage.

Points de Go/No-Go pertinents :

Pour les sites distribués, il doit également être clair qui est joignable pendant la fenêtre de maintenance : personne de contact technique, contact sur site, personne avec accès physique et décideur pour le retour en arrière. Si la mise à niveau est effectuée à distance, vérifiez également si un accès alternatif est disponible au cas où le VPN, le WAN ou la gestion centrale ne fonctionnerait pas temporairement.

Un plan de retour en arrière n’est pas une faiblesse du changement. Il empêche que lors d’une perturbation, le firmware, le routage, le VPN, le HA et le commutateur soient modifiés simultanément. Si un service critique tombe en panne après la mise à niveau, le plan de validation défini doit être suivi en premier. Ce n’est qu’après que l’on décide si un retour en arrière, une restauration, une réinstallation ou une correction ciblée est plus judicieuse.

6. Préparer correctement le cluster HA

Pour les clusters HA, il ne faut pas seulement considérer le pare-feu actif. Les deux nœuds doivent être supportés, avoir le même état de départ sensé et se synchroniser correctement. Une mise à niveau sur un cluster HA déjà défaillant augmente le risque de pannes inutiles.

Avant la fenêtre de maintenance, vérifiez :

• System services > High availability montre un statut HA sain.
• Les deux appliances sont du même modèle ou une combinaison HA supportée.
• Version du firmware, statut de la licence et abonnement sont plausibles.
• Le lien HA, les ports surveillés et les ports de commutateur connectés sont stables.
• Il est documenté quel appareil était actif avant la mise à niveau.

Pour la planification générale du HA et les particularités de l’Active-Passive, Active-Active, la licence et la maintenance, l’article Variantes de cluster HA de Sophos Firewall est approprié.

7. Rechercher l’IPsec Remote Access Legacy

À partir de SFOS 22.0 MR1, le VPN IPsec Remote Access Legacy n’est plus supporté. Les pare-feux avec cette configuration Legacy ne peuvent pas être mis à jour vers SFOS 22.0 MR1 ou une version ultérieure. C’est un blocage typique de mise à niveau, car l’IPsec Remote Access est souvent configuré une fois dans les environnements plus anciens et n’est plus touché par la suite.

Avant la mise à niveau, vérifiez donc si des configurations IPsec Remote Access Legacy sont présentes. Si oui, il faut d’abord migrer vers la configuration IPsec Remote Access actuelle, SSL VPN, ZTNA ou un autre design de Remote Access approprié. La procédure concrète est décrite dans Migrer l’IPsec Remote Access Legacy avant SFOS 22 MR1. Pour le dépannage général de l’IPsec, consultez également Dépannage du VPN IPsec de Sophos Firewall.

Procédure pratique :

1. Ouvrir la section Remote access VPN dans WebAdmin.
2. Vérifier si une configuration IPsec Remote Access Legacy est présente.
3. Documenter les utilisateurs concernés, les profils, les pools, l’authentification et les configurations Sophos Connect distribuées.
4. Planifier la configuration de remplacement et la tester avec quelques utilisateurs test.
5. Après une migration réussie, supprimer la configuration Legacy et vérifier à nouveau la mise à niveau du firmware.

Si Sophos Connect est utilisé, les guides existants pour la configuration du pare-feu Sophos Connect, l’installation Windows et l’installation macOS doivent également être pris en compte.

8. Vérifier l’IPsec basé sur des politiques et le NAT

SFOS 22.0 GA et les versions ultérieures modifient le comportement du VPN IPsec Site-to-Site basé sur des politiques. De plus, les notes de version de SFOS 22 documentent un problème résolu où le trafic IPsec basé sur des politiques pouvait échouer si la règle SNAT par défaut était configurée avec une adresse IP statique au lieu de MASQ.

Ce n’est pas une raison pour reconstruire chaque configuration IPsec à l’avance. Mais c’est une bonne raison de tester consciemment l’IPsec basé sur des politiques avant et après la mise à niveau. Cela est particulièrement important si le pare-feu utilise plusieurs VPN, des réseaux qui se chevauchent, des règles SNAT spécifiques, une règle SNAT par défaut ajustée ou des réseaux partenaires avec des attentes IP source fixes.

Avant la mise à niveau, vérifiez :

1. Identifier les tunnels Site-to-Site basés sur des politiques.
2. Documenter les réseaux locaux et distants ou les sélecteurs de trafic.
3. Vérifier les règles NAT sur le trafic VPN, en particulier la SNAT par défaut, MASQ, les règles SNAT spécifiques et l’ordre des règles.
4. Définir un cas de test par tunnel important avec source, destination, service et direction attendue.
5. Documenter la contrepartie et le chemin de retour pour qu’un test post-mise à niveau ne se résume pas à “Ping ne fonctionne pas”.

Après la mise à niveau, ne mélangez pas ces tests avec des vérifications globales. Il est préférable de faire un test ciblé par tunnel : comparer le Log Viewer, le Packet Capture, l’ID de règle de pare-feu, l’ID de règle NAT et le compteur d’octets dans ipsec statusall. Si le tunnel est vert mais qu’aucun trafic utile ne passe, consultez Dépannage du VPN IPsec de Sophos Firewall. Pour comprendre le NAT, consultez Comprendre le NAT sur Sophos Firewall.

9. Vérifier le STAS et les règles basées sur l’utilisateur

Si STAS est actif, il ne doit pas être simplement coché comme “fonctionne au quotidien” avant SFOS 22.0 MR1 ou une version ultérieure. La liste des problèmes connus documente un problème où l’option Restrict client traffic during identity probe peut bloquer une mise à niveau vers SFOS 22.0 MR1 ou entraîner des sondages d’identité répétés avec des interruptions de trafic après la mise à niveau.

Cela concerne principalement les environnements où STAS est utilisé non seulement pour le reporting, mais pour des règles de pare-feu productives basées sur l’utilisateur. Si l’association utilisateur-IP s’interrompt brièvement, cela peut rapidement ressembler à un problème de règle, de DNS ou d’application en production.

Avant la mise à niveau, vérifiez :

1. Ouvrir Authentication > STAS.
2. Vérifier le statut STAS et les collecteurs utilisés.
3. Vérifier si Restrict client traffic during identity probe est actif.
4. Identifier les règles basées sur l’utilisateur qui dépendent de STAS.
5. Connecter un utilisateur test et vérifier les utilisateurs en direct ainsi que le Log Viewer.

Si cette option est active ou si des interruptions courtes sont déjà remarquées, ce point doit être clarifié avant la fenêtre de maintenance. Le processus détaillé est décrit dans Configurer STAS sur Sophos Firewall.

10. Valider spécifiquement après la mise à niveau

Après le redémarrage, la mise à niveau n’est pas automatiquement terminée. Ce n’est que lorsque les principales fonctions opérationnelles ont été vérifiées que la fenêtre de maintenance est correctement terminée.

Vérifiez au minimum :

• la bonne version du firmware est active
• Network > Interfaces affiche les interfaces physiques et logiques de manière plausible
• l’accès Internet et les règles de pare-feu centrales fonctionnent
• le VPN Site-to-Site et le VPN Remote Access fonctionnent
• les tests IPsec basés sur des politiques montrent l’IP source attendue et la règle NAT appropriée
• le statut HA est à nouveau synchronisé
• STAS, AD SSO ou une autre association utilisateur fonctionne, si utilisé en production
• la gestion et le reporting Sophos Central envoient des données
• le Log Viewer ne montre pas de nouvelles erreurs critiques
• les services importants comme DNS, DHCP, Web Protection, IPS et l’authentification fonctionnent comme prévu

Si le VPN, le routage ou les règles ne fonctionnent pas comme prévu, ne changez pas immédiatement plusieurs choses à la fois. Limitez d’abord avec le Log Viewer, le Policy Test, le Packet Capture et les journaux de service concernés. Pour un dépannage structuré, Tester une règle de pare-feu avec Log Viewer, Policy Test et Packet Capture et Dépannage de Sophos Firewall : Services et journaux sont des compléments utiles.

11. Sécuriser la preuve et la documentation opérationnelle

Une mise à niveau n’est proprement terminée que lorsque le résultat est documenté de manière traçable. Cela aide lors de perturbations ultérieures, d’audits, de cas de support et lors de la prochaine fenêtre de maintenance. Juste après la mise à niveau, il ne faut donc pas seulement noter “fonctionne à nouveau”, mais sécuriser des preuves concrètes.

Preuves utiles :

Si des modifications ont été apportées aux règles, interfaces, hôtes ou services, les journaux de piste d’audit doivent également être vérifiés. Dans les environnements avec une conservation des journaux plus longue, un contrôle de Central Firewall Reporting ou Syslog fait également partie de la clôture.

Pour plusieurs pare-feux, il est également important que les sauvegardes puissent être clairement attribuées. Dans les versions SFOS plus récentes, les e-mails de sauvegarde contiennent plus de données d’identification comme le nom d’hôte, la version du firmware, le numéro de série et le modèle. Néanmoins, il est toujours conseillé de tenir une note de mise à niveau simple en interne : pare-feu, emplacement, ancienne version, nouvelle version, fenêtre de temps, personne responsable, résultat du test et points ouverts.

Si des avertissements concernant le stockage, le matériel ou le SSD apparaissent après la mise à niveau, cela ne doit pas être perdu dans le ticket de firmware. Pour cette vérification, consultez Vérifier l’état de santé du SSD sur Sophos Firewall.

Liste de contrôle pour la fenêtre de maintenance

Avant la mise à niveau

• Plateforme et chemin de mise à niveau vérifiés
• Notes de version et avis connus lus
• Noms d’interfaces avec dix chiffres ou plus à la fin exclus
• Espace de stockage et indications du firmware vérifiés
• Sauvegarde créée et stockée à l’extérieur
• Clé maître de stockage sécurisé disponible
• Décision Go/No-Go, plan de retour en arrière et responsables définis
• État HA documenté
• IPsec basé sur des politiques, VPN-NAT et trafic de test documentés, si utilisés
• STAS et règles basées sur l’utilisateur vérifiés, si utilisés
• IPsec Remote Access Legacy exclu ou migré
• Plan de retour en arrière défini

Pendant la mise à niveau

• Documenter les messages de statut
• Ne pas effectuer de modifications parallèles sur le routage, le VPN ou le commutateur
• Observer le basculement et la synchronisation dans les clusters HA
• Respecter le point de décision pour attendre, analyser les erreurs ou revenir en arrière
• Ne pas confirmer aveuglément les messages inattendus, mais vérifier la cause

Après la mise à niveau

• Vérifier la version du firmware et le statut de la licence
• Tester le VPN, le routage, le DNS, le DHCP et les règles de pare-feu centrales
• Vérifier l’IPsec basé sur des politiques avec un test source/destination défini, si utilisé
• Vérifier STAS, AD SSO et les règles basées sur l’utilisateur avec un utilisateur test
• Vérifier la synchronisation HA et la connexion Sophos Central
• Contrôler le Log Viewer et les journaux de service pertinents
• Sécuriser les preuves de firmware, HA et audit
• Documenter le résultat et les points ouverts dans le journal opérationnel

FAQ