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.

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 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.

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.

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.
  • Ne pas utiliser de caractères spéciaux dans Backup prefix, le nom d’utilisateur FTP ou le mot de passe sans les avoir testés.
  • 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 Central

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 Central et autorisé à transmettre des sauvegardes de configuration. Connecter Sophos Firewall à Sophos Central décrit la configuration de la connexion.

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 Central l’autorisation de service en attente.

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.

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.

Ce qu’une restauration ne résout pas automatiquement

  • 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.
  • Le fuseau horaire, NTP et l’heure doivent être vérifiés comme état opérationnel actuel.
  • 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 Central 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/XGS 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.

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’un XGS, 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 appliance XGS, 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.

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.
  • Management-Port : est mappé vers un Management-Port existant ou conservé comme Pseudo-Port. Planifier au préalable le réseau de gestion et l’accès local.
  • 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.

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

Pour conserver la configuration HA, une sauvegarde HA ne peut être restaurée que sur un cluster HA. Il est possible de configurer d’abord le nouveau cluster et de restaurer la sauvegarde sur le Primary, ou de restaurer d’abord et de configurer HA ensuite. Vérifier ensuite les rôles, la version du firmware, le Dedicated HA-Link et les monitored ports.

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 XG vers XGS, la comparaison entre XG et XGS 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.

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