Aller au contenu
Avanet

Créer ou restaurer une sauvegarde Sophos Firewall

Sophos Firewall

Une sauvegarde Sophos Firewall constitue la base des mises à jour du firmware, des remplacements de matériel, des opérations de reimage, des travaux HA et des migrations. Le fichier seul ne suffit toutefois pas : une restauration fiable nécessite également le mot de passe de la sauvegarde, le Secure Storage Master Key (SSMK) correspondant, une version cible compatible et un accès de gestion fonctionnel.

⚠️ Important : Avant toute modification risquée, le fichier de sauvegarde, le mot de passe, le SSMK, la version cible, l’adresse IP de gestion et la procédure de restauration doivent être disponibles et vérifiés. Une sauvegarde qui se trouve uniquement sur le firewall ou dont la clé est manquante ne constitue pas une solution de repli fiable.

La vidéo présente la sauvegarde et la restauration sur Sophos Firewall et complète les conseils pratiques de récupération de cet article.

Procédure de récupération et prérequis

Choisir la procédure de récupération adaptée

Une restauration n’est pas la bonne première mesure pour chaque problème :

Une sauvegarde de restauration est presque toujours nécessaire avant un reimage. En revanche, un rollback du firmware ne remplace pas une sauvegarde, car le slot du firmware et l’état de configuration sauvegardé sont deux procédures de récupération distinctes.

Mot de passe de sauvegarde et Secure Storage Master Key

Les sauvegardes Sophos Firewall actuelles sont chiffrées par un mot de passe. Si la sauvegarde a été créée après la configuration du SSMK, la restauration nécessite le mot de passe de la sauvegarde ainsi que le SSMK en vigueur à ce moment-là.

Le SSMK protège les informations sensibles telles que les mots de passe, secrets et clés. Il est configuré par le compte admin par défaut et doit être conservé dans un gestionnaire de mots de passe ou une autre procédure de récupération protégée. Au moins deux personnes autorisées doivent savoir où il se trouve.

Si le SSMK est modifié ultérieurement, les anciennes sauvegardes restent liées à la clé précédente. Les versions actuelles et antérieures du SSMK doivent donc être conservées avec leur période et le firewall auquel elles se rapportent.

Les sauvegardes legacy sans SSMK peuvent être restaurées sans Master Key. Si une sauvegarde planifiée sans SSMK est restaurée, sa planification enregistrée continue de s’appliquer, mais la fréquence ne peut être modifiée qu’après la configuration d’un SSMK. Une nouvelle sauvegarde manuelle doit alors être créée immédiatement.

L’aide de SFOS 22/23 se contredit au sujet du Factory Reset : la page dédiée au reset et Device Management > Reset to factory defaults décrivent la conservation du SSMK ; Control center et la section générale Firmware décrivent sa suppression. Boot with factory default configuration est également décrit explicitement comme conservant la clé. Cela ne garantit pas le résultat d’une méthode de reset et d’un build précis. Avant chaque reset, conserver donc à l’extérieur la sauvegarde, son mot de passe et les SSMK actuels et précédents, puis vérifier l’état de la clé après l’opération. Si le plan de récupération dépend de sa conservation, clarifier la méthode et le build avec Sophos Support avant le reset ; ne pas effectuer un reset pour le découvrir. Préparer un Factory Reset en toute sécurité explique les différentes procédures. Selon l’aide Firmware, un reimage supprime le SSMK actuel. Un rollback du firmware active la configuration de la partition précédente ; l’historique des clés reste également nécessaire.

Un SSMK doit être configuré avant de créer une nouvelle sauvegarde manuelle ou planifiée. Sur une nouvelle installation, il se crée dans le Setup Assistant. Si un firewall sans SSMK a été mis à niveau vers SFOS 20.0, la clé se crée sous Control center avec le compte admin par défaut. Les autres administrateurs voient l’invite, mais ne peuvent pas créer la clé avec leurs propres comptes.

Le SSMK est synchronisé entre les deux équipements HA en mode active-active comme en mode active-passive. La désactivation de HA sur l’un des équipements laisse la clé sur les deux ; un équipement autonome conserve également son SSMK. En active-passive, la clé ne peut être définie ou réinitialisée que via le Primary. Un changement HA ne remplace donc pas la conservation externe de l’historique des clés.

Réinitialiser le SSMK uniquement comme changement break-glass planifié

Le Secure Storage Master Key ne peut être réinitialisé via la CLI qu’avec le Super Administrator par défaut admin. L’option de menu apparaît seulement après la création d’un SSMK. Un autre administrateur ne peut pas effectuer ce changement. Un SSMK perdu ne peut pas être récupéré ; la réinitialisation crée une nouvelle clé, mais ne retrouve pas celle qui a été perdue.

⚠️ Le nouveau SSMK ne peut pas déchiffrer les anciennes sauvegardes créées avec la clé précédente. Une réinitialisation ne remplace donc ni l’historique des clés conservé ni l’ancien SSMK. Cette opération n’est pas un test sans risque.

Avant la réinitialisation, conserver à l’extérieur une sauvegarde actuelle et son mot de passe ; si le SSMK précédent est encore disponible, le conserver aussi. S’il manque, documenter explicitement que cette sauvegarde ne peut pas être restaurée sans sa clé d’origine. La nouvelle clé permet seulement de créer une nouvelle sauvegarde après la réinitialisation, pas de récupérer via cet ancien fichier. Accéder ensuite à 2. System Configuration > 5. Reset secure storage master key :

  1. Saisir le mot de passe du admin par défaut.
  2. Saisir le nouveau SSMK.
  3. Saisir une seconde fois la nouvelle clé pour confirmation.

La nouvelle clé doit comporter au moins 12 caractères, dont au moins une majuscule, une minuscule, un chiffre et l’un des caractères spéciaux pris en charge par SFOS :

! # $ % & ( ) * + , - . / : ; < = > ? @ [ ] ^ _ ` { | } ~

L’enregistrer immédiatement avec le firewall, le numéro de série et la date d’activation dans le système de récupération protégé, jamais dans un ticket, une capture d’écran ou l’historique du shell.

Après la réinitialisation, créer immédiatement une nouvelle sauvegarde manuelle et la stocker en externe. Vérifier également les sauvegardes planifiées, les identifiants enregistrés, les VPN, les certificats, la connexion Central et l’accès d’administration. Conserver les anciennes sauvegardes avec leur SSMK respectif ; la nouvelle clé ne les rend pas restaurables.

Kit de récupération par firewall

En plus de la sauvegarde, chaque site ou tenant doit disposer d’un kit de récupération protégé :

  • dernière sauvegarde vérifiée avec date et objet
  • mot de passe de la sauvegarde ainsi que SSMK actuel et précédents
  • nom du firewall, numéro de série, modèle et version de SFOS
  • identifiants WAN, informations du fournisseur et Default Gateway
  • affectation des interfaces, VLAN, LAG, bridges et ports HA
  • accès administrateur local et break-glass
  • affectation de la licence et de Sophos Fusion (anciennement Sophos Central)
  • services critiques avec des tests d’acceptation concrets

La sauvegarde et les identifiants ne doivent pas être stockés ensemble sans protection. Le kit de récupération doit être mis à jour après toute modification concernant le personnel, le fournisseur, les ports, HA ou le site.

Créer et exploiter les sauvegardes en toute sécurité

Sauvegarde manuelle avant les modifications

Backup & Firmware > Backup & Restore
Créer une sauvegarde de la configuration SFOS
Sophos Firewall Backup & Restore : créer une sauvegarde manuelle et configurer des sauvegardes planifiées

Backup Now crée une sauvegarde immédiate. Le fichier doit ensuite être stocké à l’extérieur et documenté au minimum avec le nom du firewall, son numéro de série, la version de SFOS, la date et l’objet de la modification.

Sous Download, il est possible de choisir Download encrypted backup ou Encrypt backup with a different password before you download. Le second mot de passe ne s’applique qu’à cette copie téléchargée ; il ne modifie pas l’Encryption password enregistré pour les backups suivants. Le fichier et le mot de passe réellement utilisé doivent donc être associés sans ambiguïté au dossier de récupération.

Une sauvegarde manuelle est particulièrement importante avant :

  • des modifications du firmware, des interfaces, des VLAN, du routing, de SD-WAN ou du VPN
  • la configuration de HA, un changement de rôle ou la maintenance du cluster
  • des modifications importantes des règles NAT, WAF ou firewall
  • un reimage, un Factory Reset, un remplacement de matériel ou une migration de plateforme

Pour les modifications importantes, Sophos Firewall Config Studio peut également mettre en évidence les différences de configuration. Une comparaison de Entities.xml ne remplace toutefois pas une sauvegarde destinée à la restauration.

Si seule une partie clairement délimitée de la configuration doit être transférée ou modifiée, exporter et importer sélectivement la configuration décrit la procédure WebAdmin séparée. Cet import ne remplace pas non plus la voie de récupération complète.

Enregistrer les paramètres de sauvegarde

Avant la première sauvegarde, configurer le SSMK comme décrit plus haut et conserver à l’extérieur les sauvegardes existantes nécessaires. Sous Backup & Firmware > Backup & Restore, enregistrer les paramètres de la destination prévue :

  1. Choisir la destination sous Backup mode : Local enregistre sur le firewall ; FTP et Email enregistrent également en local et envoient le fichier à la destination choisie. Pour FTP, saisir l’adresse IPv4 ou IPv6 du serveur, le nom d’utilisateur, le mot de passe et FTP path. Pour Email, indiquer l’adresse e-mail du destinataire autorisé. Le serveur, le compte, le répertoire et le destinataire doivent correspondre au stockage protégé de l’organisation.
  2. Définir un identifiant de firewall sans ambiguïté dans Backup prefix et choisir la fréquence souhaitée sous Frequency. La section sur les sauvegardes automatiques explique les restrictions de caractères et la conservation.
  3. Définir Encryption password, ou modifier un mot de passe existant avec Change encryption password. Associer ce mot de passe à la sauvegarde concernée dans le stockage de récupération protégé ; les anciens fichiers nécessitent toujours leur mot de passe d’origine.
  4. Cliquer sur Apply pour enregistrer les paramètres avant de créer la sauvegarde configurée ou d’utiliser la planification.
  5. Contrôler à nouveau le mode, la destination et la fréquence enregistrés. Pour la prochaine sauvegarde, vérifier ensuite l’envoi ou le stockage local, la récupération et le déchiffrement. En cas d’échec, contrôler d’abord l’adresse de destination, le chemin FTP, les permissions ou le destinataire ; une planification enregistrée ne prouve pas à elle seule qu’une sauvegarde a réussi.

Sauvegardes automatiques

Sous Frequency, il est possible de configurer des sauvegardes quotidiennes, hebdomadaires ou mensuelles. Selon la configuration, les destinations disponibles sont le stockage local, FTP et l’e-mail.

Points importants pour l’exploitation :

  • Une sauvegarde locale ne sert à rien si l’appliance tombe en panne ou est réinstallée.
  • Seule la dernière sauvegarde locale reste sur le firewall ; les versions antérieures nécessaires doivent être conservées à l’extérieur.
  • Les sauvegardes FTP et par e-mail ne sont considérées comme opérationnelles qu’après un véritable test d’envoi, de récupération et de déchiffrement.
  • SFOS 22 limite Backup prefix à 32 caractères et n’accepte notamment pas /, \, :, *, ?, ", <, >, |, ~, `, .. ni les lettres UTF-8 autres que les lettres anglaises. Le nom d’utilisateur FTP ne doit pas contenir \ ; les seuls caractères spéciaux pris en charge dans le nom d’utilisateur et le mot de passe FTP sont @, / et $. Le nom d’hôte dans l’objet d’une sauvegarde par e-mail est limité à 25 caractères.
  • Les sauvegardes automatiques ne remplacent pas une sauvegarde manuelle récente juste avant une modification risquée.
  • La durée de conservation, les accès et la procédure de suppression doivent être adaptés aux besoins de protection de la configuration.

Les sauvegardes de firewall contiennent des informations confidentielles sur les réseaux, règles, VPN, certificats et comptes. L’accès doit être limité aux administrateurs et responsables de la récupération ; le mot de passe et le SSMK restent séparés, mais doivent pouvoir être retrouvés en cas d’urgence.

Sauvegardes Sophos Fusion

Sophos documente actuellement deux chemins de navigation dans Central selon la vue et la page d’aide :

Global Settings > Products and Services > Firewall
My Products > Firewall Management > Backup

Le firewall doit être connecté à Sophos Fusion et autorisé à transmettre des sauvegardes de configuration. Connecter Sophos Firewall à Sophos Fusion décrit la configuration de la connexion. L’option Send configuration backup to Sophos Central nécessite Use Sophos Central management. Un Super admin du tenant Sophos Fusion concerné effectue cette approbation ; les droits locaux WebAdmin ou l’enregistrement par OTP ne la remplacent pas.

Toujours vérifier explicitement la planification au lieu de supposer une valeur par défaut. Lorsque le premier firewall est automatiquement ajouté à une planification vide définie sur Never, Central peut la faire passer une fois sur Monthly et le premier jour du mois. Les planifications existantes ne sont pas modifiées.

Autres propriétés fixes :

  • Les sauvegardes sont exécutées à 08:00 dans le fuseau horaire de la région Central ; cette heure ne peut pas être modifiée.
  • Central tente la création jusqu’à cinq fois, puis génère une alerte et un e-mail à l’administrateur.
  • Les cinq sauvegardes les plus récentes sont conservées ; une seule sauvegarde supplémentaire peut être stockée de façon permanente.
  • Lors du téléchargement, la sauvegarde est chiffrée à nouveau avec un nouveau mot de passe.
  • Si le firewall est supprimé de Central Management, Sophos efface les sauvegardes Central correspondantes. Les fichiers nécessaires doivent être téléchargés avant un changement de compte, un RMA ou un nettoyage du tenant.
  • Avec HA, Primary et Auxiliary sont ajoutés à la planification, mais la sauvegarde est créée par le Primary.

Si un firewall enregistré ne figure pas dans la planification, l’ajouter sous Schedule Backup. Si Send configuration backup to Sophos Central est déjà activé, décocher la case, appliquer, la cocher à nouveau, appliquer encore une fois, puis accepter dans Sophos Fusion l’autorisation de service en attente. Un Super admin du tenant Sophos Fusion concerné effectue cette approbation ; les droits locaux WebAdmin ou l’enregistrement par OTP ne la remplacent pas.

Central constitue un bon emplacement de stockage supplémentaire, mais ne remplace pas le SSMK, l’accès local, les données WAN et une copie de sauvegarde accessible indépendamment.

Si Sophos Support a besoin d’une sauvegarde protégée par SSMK pour un dossier précis, sa lecture nécessite le mot de passe de chiffrement réellement utilisé et le SSMK correspondant de l’époque. Confirmer d’abord l’objet du dossier et le destinataire autorisé par la procédure de support existante. Fournir ensuite seulement les deux secrets par un canal protégé convenu pour leur transmission, séparément du fichier de sauvegarde. Ne jamais les placer dans le texte du ticket, des captures d’écran ou des pièces jointes ordinaires. Il ne s’agit pas d’une consigne générale de partage des identifiants administrateur.

Préparer et effectuer une restauration

Préparation et test de restauration sécurisé

Avant la restauration, vérifier les points suivants :

  • le fichier de sauvegarde correct, le mot de passe et le SSMK de l’époque sont disponibles
  • la version source, la version cible, le modèle et la plateforme sont compatibles
  • une sauvegarde de l’état actuel de la configuration est stockée à l’extérieur
  • l’adresse IP de gestion issue de la sauvegarde et l’accès local sont connus
  • les données WAN, NTP, DNS, de licence et de Central sont documentées
  • la cible HA et l’ordre de restauration sont définis
  • le mappage des interfaces et les différences d’affectation des ports sont préparés

⚠️ Attention : Une restauration écrase la configuration actuelle et redémarre le firewall. Un avertissement concernant un chemin de migration non pris en charge ne doit pas être confirmé systématiquement ; le firewall pourrait ensuite démarrer avec sa configuration d’usine.

Un véritable test de restauration doit être effectué sur un firewall de laboratoire ou de remplacement approprié. Avant le test, désactiver ou isoler les connexions WAN, VPN et Central de production afin d’éviter les conflits d’adresses, les tunnels ou les enregistrements en double.

Sans appareil de test, il est au moins possible d’effectuer un test organisationnel : récupérer la sauvegarde depuis le stockage prévu, vérifier son affectation, confirmer le mot de passe et le SSMK, évaluer la plateforme cible et parcourir dans le runbook l’accès de gestion et les tests d’acceptation. Cela ne remplace pas une véritable restauration, mais élimine de nombreux problèmes classiques en cas d’urgence.

Restaurer une sauvegarde

Backup & Firmware > Backup & Restore
  1. Accéder au firewall cible via WebAdmin.
  2. Sauvegarder l’état actuel si cela est encore possible.
  3. Sous Restore configuration, sélectionner le fichier de sauvegarde avec Choose file.
  4. Saisir Encryption password et, pour une sauvegarde protégée par un SSMK, également le SSMK en vigueur à ce moment-là.
  5. Lancer Upload and Restore.
  6. Attendre le redémarrage et la restauration.
  7. Ouvrir WebAdmin via l’adresse IP de gestion issue de la sauvegarde.
  8. Vérifier le fuseau horaire, NTP et l’heure actuelle.
  9. Valider le réseau, les services, le VPN, HA et la connexion à Central.

La restauration supprime la sauvegarde stockée localement sur le firewall cible. Le fichier utilisé doit donc rester disponible à l’extérieur. Sur une nouvelle appliance, terminer d’abord l’assistant de configuration, puis restaurer la sauvegarde.

Le SSMK saisi lors de la restauration sert uniquement à ouvrir la sauvegarde. Il ne remplace pas le SSMK propre au firewall cible. Après les tests d’acceptation, créer une nouvelle sauvegarde de l’état cible et l’associer dans le kit de récupération au SSMK de la cible et au mot de passe de sauvegarde réellement utilisé. Une restauration réussie ne signifie pas que les clés source et cible sont identiques ; aucune réinitialisation du SSMK n’est nécessaire pour cela.

Ce qu’une restauration ne résout pas automatiquement

À l’exception du mot de passe du compte admin par défaut, SFOS restaure la configuration, y compris les tokens MFA de tous les utilisateurs, les utilisateurs VPN, RED, les configurations VPN site-to-site et d’accès distant, ainsi que Sophos Connect. ApplianceCertificate, Default CA, SecurityAppliance_SSL_CA et les clés pre-shared proviennent également de la sauvegarde. Dès que le routing et les interfaces redeviennent actifs, ces relations de confiance et ces tunnels peuvent reprendre effet. Une restauration de laboratoire reste donc isolée jusqu’à la vérification des VPN, de RED, des certificats, de Central et des réseaux cibles.

  • Le mot de passe du compte admin par défaut n’est pas restauré depuis la sauvegarde ; le firewall cible conserve son mot de passe actuel. S’il est perdu, l’article séparé sur la récupération du mot de passe explique la récupération série pour les appliances physiques et les limites des firewalls virtuels et cloud.
  • Après le redémarrage, l’adresse IP de gestion, Device Access, les routes et les services proviennent à nouveau de la sauvegarde.
  • Les valeurs personnalisées de date et d’heure sous Administration > Time ne sont pas incluses dans le backup. Seuls le fuseau horaire et les serveurs NTP sont restaurés ; les valeurs horaires manuelles doivent être reconfigurées et vérifiées après la restauration.
  • Les valeurs dépendantes du modèle ou de l’instance peuvent revenir aux valeurs par défaut si elles ne conviennent pas à la cible. Sophos cite le nombre d’instances IPS comme exemple : S’il est modifié pour le modèle cible pendant la restauration, la cible applique sa valeur par défaut au lieu de celle du backup.
  • Sophos Fusion reste enregistré uniquement lors d’une restauration sur le même firewall. Un autre firewall ou un cluster HA doit être enregistré à nouveau ; vérifier ensuite Security Heartbeat, ZTNA, Central Management, Backup, Reporting, Task Queue et l’affectation aux groupes.
  • Les logs, reports et données de supervision externes ne font pas partie d’un rollback complet de la configuration.

Lors d’une migration vers le mode FIPS 140-3, l’état de la sauvegarde est également décisif : Une sauvegarde avec FIPS désactivé restaure l’état sans FIPS et constitue donc une voie de retour, pas un transfert inchangé vers le mode FIPS.

Restaurer sur un autre matériel et d’autres plateformes

Compatibilité et versions de SFOS

Avant une migration, noter la version source, la version cible, le modèle cible et la plateforme. Le Backup-restore compatibility check fait désormais partie de Sophos Firewall Config Studio. Y ouvrir Backup-restore compatibility et vérifier la compatibilité des modèles XG et XGS Appliance ainsi que des modules Flexi Port et des transceivers utilisés. L’outil s’applique à SFOS 20.0 MR2 et versions ultérieures ; tenir également compte des informations de mise à niveau des release notes actuelles et des indications du SFOS 22 Upgrade Check.

Des limites strictes s’appliquent à SFOS 22 :

  • SFOS 22.0 GA et les versions ultérieures ne prennent pas en charge le matériel XG ou SG.
  • Les sauvegardes comportant un legacy CLI VLAN tagging sur des interfaces bridge ne peuvent pas être restaurées sur SFOS 22.0 GA ou une version ultérieure. Le nettoyage est décrit dans Vérifier les Bridge VLAN avant SFOS 22.
  • Legacy Remote Access IPsec bloque la mise à niveau vers SFOS 22.0 MR1 et les versions ultérieures. Lors d’une restauration ou d’un import sur ces versions, l’ancienne configuration n’est pas migrée ; il faut d’abord passer à la méthode prise en charge. La procédure figure sous Migrer Legacy Remote Access IPsec.

Pour les cibles sous SFOS 20.0 MR2 ou ultérieur, ces limites de format s’appliquent également. Desktop désigne les équipements de bureau, 1US et 1UL les modèles rack 1U plus petits et plus grands respectivement, et 2U les modèles rack 2U ; vérifier le format du modèle précis dans Compatibility Check. Le sens source → cible est déterminant :

  • Desktop → Desktop, 1US/1UL, 2U ou virtuel : autorisé en principe par la matrice.
  • 1US → Desktop : autorisé uniquement sur XGS 126/126w, XGS 136/136w, XGS 128/128w ou XGS 138. 1US → 1US/1UL, 2U ou virtuel est autorisé en principe.
  • 1UL ou 2U → Desktop : non autorisé. 1UL ou 2U → 1US/1UL, 2U ou virtuel est autorisé en principe.
  • Virtuel → Desktop, 1US/1UL, 2U ou virtuel : autorisé en principe.

Un sens autorisé dans la matrice ne valide pas toutes les configurations. Vérifier encore la version SFOS, la paire de modèles précise, les limites Wireless et bridge, ainsi que les modules de ports. En particulier, les sauvegardes Desktop de XG ou Gen.1 XGS restaurées sur Gen.2 XGS restent soumises aux restrictions Wireless ci-dessous. Un nombre inférieur de ports sur la cible ou l’Assistant ne rend pas une paire de modèles interdite compatible.

Backup-Restore Assistant et mappage des interfaces

L’Assistant apparaît uniquement si toutes les conditions sont remplies :

  • La sauvegarde provient d’un XG, d’un SG avec SFOS, d’une XGS Appliance, d’une appliance virtuelle ou Cloud avec SFOS 19.5 MR4 ou une version ultérieure.
  • La cible exécute SFOS 20.0 MR2 ou une version ultérieure.
  • La cible est une XGS Appliance, virtuelle ou Cloud.

L’Assistant n’apparaît pas sur les cibles XG ou SG, ni avec les sauvegardes de SFOS 19.5 MR3 ou d’une version antérieure. Le firewall effectue alors automatiquement le mappage ; les interfaces, zones, gateways, VLAN, HA-Link, SD-WAN, NAT et VPN doivent ensuite être contrôlés avec une attention particulière.

L’Assistant peut également être utilisé sur la même appliance compatible pour déplacer des VLAN ou des configurations d’interface vers un autre port physique.

L’Assistant affiche uniquement les ports physiques pour le mappage. Il présente ensemble les modèles source et cible, les détails des interfaces et les mappages disponibles. En survolant une interface source, SFOS affiche son adresse IP, son masque de sous-réseau, son type d’attribution IP et son link mode. Avant le mappage, ces valeurs sont comparées au plan de ports et au câblage ; un nom de port similaire ne constitue pas à lui seul un critère suffisant.

Par défaut, SFOS mappe les ports équivalents. Si le port correspondant n’existe pas sur l’appareil cible, il sélectionne le prochain port disponible. Cette automatisation n’est qu’une proposition et doit être vérifiée ; avec Don’t map. Creates Pseudo port, la configuration est volontairement conservée sur un pseudo-port non fonctionnel.

Interfaces source non liées : lors de la restauration, SFOS ne les mappe pas vers des ports cibles et ne crée pas de pseudo-ports pour elles. Les interfaces non liées comportant une configuration VLAN constituent l’exception. En tenir compte dans le plan de ports ; cette exception est distincte des règles ci-dessous pour supprimer des pseudo-ports existants.

Interfaces physiques et logiques

  • Port physique : le mapper volontairement vers un port cible ou ne pas le mapper ; vérifier le câblage, la zone et la fonction WAN/LAN.
  • VLAN ou alias : suit l’interface parent mappée ; le parent port doit être correct sur le plan opérationnel.
  • LAG ou bridge : est recréé à partir des ports physiques mappés ; contrôler le nombre de members et la configuration du switch.
  • RED ou Cellular : la configuration associée est migrée ; tester spécifiquement la connexion après la restauration.

Pseudo-ports, breakout, management et HA

  • Pseudo-port : conserve la configuration, mais ne traite aucun trafic. Déplacer le routing, NAT, les VLAN et les règles vers un port actif.
  • Breakout Root Port : seuls les root ports, et non les members individuels, peuvent être mappés. La cible doit disposer d’un nombre et d’une combinaison de ports pris en charge. Configurer les interfaces breakout explique la création, le redémarrage et la vérification.
  • Management-Port : est mappé par défaut vers le port de gestion de la cible ; s’il n’existe pas, la configuration est conservée comme Pseudo-Port. Lors d’une restauration vers des XGS Appliances ou des firewalls virtuels ou Cloud, l’Assistant peut aussi mapper le port de gestion vers un autre port. Consigner d’abord l’IP de gestion, le port WebAdmin, les identifiants et le câblage de ce port cible, préparer un accès local de secours et vérifier l’accès après le redémarrage. Un Pseudo-Port de gestion ne fournit pas d’accès fonctionnel.
  • Dedicated HA-Link : le type de port doit rester identique ; l’Assistant ne peut pas modifier le port HA-Link. Pour un LAG, le nombre de members doit correspondre ; pour un VLAN, le VLAN ID ; et pour les monitored ports, l’état cible.

Un pseudo-port a le statut Not available et porte normalement le nom matériel Pseudo<port number>. Pour les backups de SFOS 19.5 MR3 ou version antérieure, le nom de port d’origine peut s’afficher à la place, mais l’interface reste non fonctionnelle. Pour le breakout, la cible doit avoir au moins autant de breakout ports configurés que le backup. Seuls les root ports sont mappés ; un port physique source peut être mappé vers un breakout root port pris en charge.

Avant de supprimer un Pseudo-Port, déplacer toutes les routes et configurations NAT, firewall et VLAN qui en dépendent. Ensuite, sous Network > Interfaces, définir la zone sur None et redémarrer le firewall pendant une fenêtre de maintenance. Vérifier ensuite que le port a été supprimé ; les Pseudo-Ports non liés comportant une configuration VLAN ne sont pas supprimés automatiquement.

Le Backup-Restore Assistant réaffecte les interfaces, mais ne rend pas compatible une configuration Wireless ou bridge qui n’est pas prise en charge sur la cible. Ces dépendances doivent être corrigées sur la source avant de créer la sauvegarde de migration ou être repensées pour la cible.

Cibles HA, Wireless, virtuelles et Cloud

Une sauvegarde contenant une configuration HA peut aussi être restaurée sur un équipement autonome, mais SFOS ne restaure alors que le reste de la configuration, pas HA. Pour conserver HA, configurez d’abord le nouveau cluster et restaurez la sauvegarde sur le Primary actuel, ou restaurez d’abord puis configurez HA. Il n’est pas possible de restaurer une sauvegarde sur l’Auxiliary.

Sur un cluster active-passive ou active-active existant, le Primary actuel redémarre après la restauration sans failover. La restauration entraîne donc une interruption dans les deux modes HA. Si la sauvegarde contient une configuration HA, le Primary synchronise l’Auxiliary après le redémarrage. Une restauration sur un cluster HA désenregistre également les deux firewalls de Sophos Fusion. Réenregistrez les deux firewalls dans Sophos Fusion et, si le Primary servait de passerelle Sophos ZTNA, ajoutez-le à nouveau comme passerelle. Si une sauvegarde sans configuration HA est restaurée sur le Primary actuel, HA est désactivé et doit être reconfiguré. Vérifiez ensuite spécifiquement les rôles, la version du firmware, le Dedicated HA link et les monitored ports.

Sophos distingue trois groupes Wireless pour ce restore : Gen.2 comprend XGS 88w, 108w, 118w et 128w ; Gen.1 comprend XGS 87w, 107w, 116w, 126w et 136w ; et la série XG comprend XG 86w, 106w, 115w, 125w et 135w. L’appartenance à l’un de ces groupes détermine le sens de restore pris en charge ; un nom de modèle similaire ne suffit pas.

Les migrations Wireless ont des limites supplémentaires :

  • Pour Wireless-to-Non-Wireless, les Wireless Networks doivent être supprimés avant la sauvegarde.
  • Les sauvegardes de modèles Gen.2 XGS Wireless ne peuvent pas être restaurées sur des modèles XG ou Gen.1 XGS Wireless.
  • Lors de la migration d’anciens modèles Wireless vers Gen.2 XGS, des limites supplémentaires s’appliquent aux SSID, WPA, au bridge mode et aux bandes radio.

LocalWiFi et configurations bridge lors de la migration

La restauration d’une sauvegarde XG Wireless ou Gen.1 XGS Wireless sur un modèle Gen.2 XGS W est soumise aux prérequis et restrictions suivants :

  • Seuls des SSID utilisant au minimum WPA2 sont affectés à LocalWiFi0 et LocalWiFi1.
  • Le chiffrement n’utilise ni TKIP ni TKIP/AES.
  • Aucune interface Wireless n’est membre d’un bridge physique.
  • LocalWiFi0 et LocalWiFi1 utilisent ensemble au maximum huit SSID uniques.
  • Si les deux radios utilisent la même bande de fréquence, seuls les paramètres de LocalWiFi0 sont restaurés.

La différence entre les bridges est déterminante. Pour un Wireless Network du type Bridge to AP LAN, les modèles Gen.1 XGS 87w, 107w, 116w, 126w et 136w relient le réseau Wi-Fi local au LAN au moyen d’un bridge physique. Les modèles Gen.2 XGS 88w, 108w, 118w et 128w ne prennent pas en charge cette conception ; ils utilisent Bridge to Ethernet avec exactement un port Ethernet et la zone LAN sous Wireless > Access points > LocalWiFi > Advanced settings. Configurer le Wi-Fi directement sur Sophos Firewall décrit la configuration sur Gen.2.

Si la sauvegarde Gen.1 contient encore un bridge physique avec l’interface d’un Wireless Network du type Bridge to AP LAN, la restauration sur Gen.2 échoue. Sophos répertorie ce comportement comme Known Issue NC-135094. Si OSPF, OSPFv3, RIP, SPX Portal Setting ou Quarantine font référence à cette interface, la restauration aboutit, mais la configuration dépendante ne fonctionne pas sur Gen.2.

Avant de créer la sauvegarde de migration, vérifier sous Network > Interfaces si une interface Wireless appartient à un bridge et documenter tous les paramètres dépendants. Ne pas supprimer un bridge de production sans préparation : migrer d’abord l’adresse IP, la zone, DHCP, les ports connectés et les dépendances de routing vers une conception compatible avec Gen.2 pendant une fenêtre de maintenance. Créer ensuite une nouvelle sauvegarde. Configurer Bridge to Ethernet sur la cible, puis tester spécifiquement les SSID, le Security mode, les bandes de fréquence, DHCP ainsi que les services qui dépendaient auparavant de l’interface.

Avant une migration de XG vers une XGS Appliance, la comparaison entre XG et XGS Appliance peut également être utile.

Pour les firewalls virtuels et Cloud, la procédure intégrée de sauvegarde et restauration Sophos est la seule voie de récupération SFOS prise en charge. Sophos ne prend pas en charge les snapshots d’hyperviseur, les images Cloud ou les sauvegardes tierces à cette fin, car ils peuvent entraîner des problèmes d’intégrité des données ou des configurations non prises en charge.

Valider après la restauration

Contrôle technique

Immédiatement après la restauration, vérifier :

  • l’adresse IP de WebAdmin, les réseaux de gestion autorisés et Device Access
  • les interfaces, zones, VLAN, bridges, LAG et alias interfaces
  • le WAN, PPPoE, Default Gateway, les routes statiques et les routes SD-WAN
  • les règles firewall, NAT et WAF, y compris leur ordre
  • IPsec, SSL VPN, Sophos Connect, RED et Remote Access
  • les certificats, TLS Inspection, DNS, DHCP, NTP et Authentication Server
  • l’état HA, les rôles et la synchronisation
  • l’état de la licence, Pattern Updates, Hotfixes et la synchronisation avec Central
  • Log Viewer, Syslog, Central Reporting et le reporting local

Selon le problème, Log Viewer, Policy Test et Packet Capture, Packet Capture dans WebAdmin et la vue d’ensemble Services et logs peuvent être utiles. Sophos ne fournit aucun chemin de logs SSH universel et fiable pour les erreurs générales de restauration ; aucune commande shell n’est donc suggérée ici.

Selon Sophos, un message d’erreur détaillé dans WebAdmin n’est garanti que pour un chemin de restauration plus restreint : le backup provient d’une appliance compatible sous SFOS 19.5 MR4 ou version ultérieure, la cible exécute SFOS 20.0 MR2 ou version ultérieure et il s’agit d’un XGS 88/88w, 108/108w, 118/118w, 128/128w ou 138. Sur les autres cibles, l’absence de message dans l’interface ne signifie pas qu’aucune erreur ne s’est produite. Il faut donc consigner l’heure, les versions source et cible, les modèles et l’action de restauration exacte, puis les corréler avec les logs ou un dossier de support. Les révisions matérielles Rev.1, Rev.2 et Rev.3 suivent les mêmes règles de compatibilité, mais la paire de modèles concrète doit toujours être vérifiée dans Compatibility Check.

Tests d’acceptation

Un WebAdmin accessible ne prouve pas que le trafic de production fonctionne. Pour chaque site, la source concrète, la cible, la règle attendue et l’entrée de log attendue doivent être documentées pour les tests suivants :

  • Gestion : accès depuis le réseau de gestion et seconde connexion d’administrateur.
  • Internet : un client de test atteint une cible externe définie via la règle, NAT et la route WAN appropriées.
  • DNS et DHCP : un client reçoit une adresse et résout les noms internes et externes.
  • Site-to-Site VPN : les hosts définis sont joignables dans les deux sens.
  • Remote Access : un utilisateur de test vérifie le login, MFA, le profil, DNS et une cible interne.
  • WAF ou DNAT : un test externe confirme le certificat, la règle, le backend et le logging.
  • Authentification : AD, LDAP, RADIUS, STAS ou Entra SSO identifie correctement un utilisateur de test.
  • Logging : le trafic de test est visible dans Log Viewer, Syslog, Central Reporting ou SIEM.
  • HA : les rôles, l’état du cluster et la synchronisation correspondent au plan.

Si WAN, DNS, Remote Access ou HA ne fonctionne pas, ne pas modifier plusieurs zones à la fois. Délimiter l’erreur à l’aide de l’heure, de la source de test, de la cible, de la règle et d’un extrait de log, puis retester après chaque correction.

Troubleshooting et exploitation

Erreurs typiques

  • La sauvegarde se trouve uniquement sur le firewall : elle est inaccessible en cas de panne ou de reimage ; la stocker à l’extérieur et de manière protégée.
  • Le SSMK est manquant : les données protégées ne peuvent pas être restaurées ; documenter les clés actuelles et antérieures.
  • Le fichier ne comporte aucune référence à l’appareil ou à la version : une mauvaise sauvegarde est sélectionnée ; consigner le nom du firewall, le numéro de série, la version et la date.
  • Aucune sauvegarde de l’état actuel avant la restauration : aucune voie de retour vers l’état précédent n’est disponible.
  • L’adresse IP de gestion restaurée est inconnue : le firewall semble hors ligne ; documenter l’adresse et l’accès local au préalable.
  • L’heure ou NTP est incorrect : les VPN, certificats, l’authentification et Central peuvent échouer.
  • Un chemin de restauration non pris en charge est confirmé : la restauration échoue ou la cible démarre avec la configuration d’usine.
  • Le mappage des interfaces n’est pas vérifié : le WAN, les VLAN, le VPN ou le HA-Link aboutissent sur les mauvais ports.
  • Les limites Wireless sont ignorées : la sauvegarde est incompatible ou la configuration sans fil ne fonctionne pas comme prévu.
  • Le contexte HA est ignoré : la configuration ou les rôles du cluster sont perdus ou démarrent incorrectement.
  • Central est l’unique copie : la suppression du firewall de Central efface aussi ses sauvegardes.
  • Seul WebAdmin est vérifié : les dysfonctionnements du routing, NAT, VPN, WAF, DNS ou logging ne sont pas détectés.

Rythme d’exploitation

Régulièrement :

  • vérifier les sauvegardes automatiques, leur envoi, leur récupération et leur conservation
  • contrôler le stockage des sauvegardes, les autorisations ainsi que les SSMK actuels et antérieurs
  • maintenir à jour le kit de récupération et les tests d’acceptation
  • vérifier ponctuellement le fichier, le mot de passe, le SSMK et la compatibilité de la cible

Avant les modifications importantes :

  • créer une sauvegarde manuelle, la stocker à l’extérieur et l’étiqueter clairement
  • définir l’accès de gestion, la procédure de restauration et les critères d’interruption
  • pour une migration, vérifier la compatibilité, la version de SFOS et le mappage des interfaces

Après une restauration :

  • documenter intégralement le contrôle technique et les tests d’acceptation
  • corriger les écarts et les comparer avec Config Studio si nécessaire
  • créer une nouvelle sauvegarde de l’état cible vérifié et mettre à jour le kit de récupération