Exporter et importer sélectivement la configuration Sophos Firewall

Sous Backup and firmware > Import export, Sophos Firewall peut exporter toute la configuration ou une partie sélectionnée. L’export peut être examiné sur un système d’administration protégé, modifié de manière contrôlée et réimporté sous forme de fichier .tar. Cette fonction convient aux modifications d’objets clairement délimitées, aux migrations et aux changements en masse documentés.

Un import n’est toutefois pas un restore. Il ne remplace pas toute la configuration actuelle, mais ajoute de nouveaux paramètres et remplace les paramètres correspondants par ceux du paquet importé. Les paramètres absents du paquet sont conservés. Avant tout import en production, il faut donc une sauvegarde complète du pare-feu avec son mot de passe et son SSMK, une voie de secours pour l’administration et un plan de test.

⚠️ Important : Entities.xml peut contenir des mots de passe, des secrets, des utilisateurs, des objets réseau, des règles et d’autres données sensibles. Traiter les fichiers uniquement sur un système d’administration fiable, ne pas les distribuer via un stockage cloud ou une messagerie non contrôlés, puis les archiver ou les supprimer de façon protégée après le changement.

Réaliser un import sélectif en dix étapes

1. Documenter l’objectif, les types d’objets concernés et les changements attendus.
2. Créer une sauvegarde complète de restauration et vérifier le mot de passe ainsi que le Secure Storage Master Key.
3. Relever le firmware cible, la version des patterns, la plateforme, le nombre de ports et la compatibilité du modèle.
4. Sous Backup and firmware > Import export, sélectionner Export selective configuration.
5. Sélectionner uniquement les types de configuration nécessaires et inclure consciemment les dépendances.
6. Stocker le fichier .tar exporté de façon protégée et le conserver intact comme référence.
7. Extraire le paquet, examiner Entities.xml et ne modifier que les champs planifiés.
8. Recompresser Entities.xml et les éventuels fichiers associés, avec leurs noms inchangés, dans un fichier .tar.
9. Importer le paquet pendant une fenêtre de maintenance et saisir le SSMK si des informations sensibles sont concernées.
10. Vérifier les objets, les stratégies dépendantes, la Firewall Rule ID attendue, les journaux et le trafic réel.

Si l’import présente une portée inattendue, si une dépendance manque ou si la compatibilité de la plateforme cible n’est pas claire, ne pas l’effectuer en production. Le paquet exporté intact sert de comparaison et la sauvegarde complète sert de voie de secours.

Ne pas confondre import/export et sauvegarde

Une sauvegarde complète représente le pare-feu sous forme de paquet de récupération. Lors d’un restore, elle remplace la configuration actuelle, active l’adresse d’administration contenue dans la sauvegarde et redémarre le pare-feu. La zone d’import/export travaille au contraire avec des objets de configuration :

• Les nouveaux paramètres du paquet sont ajoutés.
• Les paramètres existants correspondants sont mis à jour avec les valeurs importées.
• Les paramètres absents du paquet restent inchangés.
• Un import sélectif ne supprime donc pas automatiquement les anciens objets ni les valeurs antérieures en dehors de l’objet importé.
• Un import réussi ne prouve ni que toutes les dépendances existent, ni que le chemin du trafic fonctionne.

Pour un remplacement matériel, un reimage, une récupération complète ou un changement important de modèle, backup et restore restent la procédure principale. L’import/export convient lorsque la portée est clairement limitée, que les dépendances sont comprises et que l’effet peut être validé séparément.

Préparer l’export

Définir la portée et les dépendances

Sous Export selective configuration, sélectionner les types de configuration requis. Include dependent entity inclut les objets dépendants. Cette option est utile, mais ne remplace pas un contrôle du contenu.

Une règle firewall qui fait référence à des hôtes, des services, un schedule, une Web Policy ou des objets NAT en est un exemple. Si seule la règle est exportée, des dépendances peuvent manquer sur le pare-feu cible ou pointer vers des objets portant d’autres noms. Avant l’export, documenter :

• l’objet principal à modifier ou à transférer ;
• les hôtes, réseaux, services, groupes, profils et stratégies qui en dépendent ;
• les objets de même nom déjà présents sur la cible ;
• les flux de production susceptibles d’être affectés après l’import ;
• la méthode de restauration de l’état précédent.

Une exception est documentée pour les configurations RED : REDDevice n’exporte pas automatiquement la configuration DHCP Server requise, même avec Include dependent entity. Il faut sélectionner DHCPServer en plus ou recréer le serveur DHCP de manière contrôlée après l’import.

Vérifier la version et la plateforme cible

Sophos autorise l’import vers la même version de firmware ou une version ultérieure. La version des patterns du pare-feu cible doit également être identique ou ultérieure. Si elle est plus ancienne, mettre d’abord les patterns à jour, puis replanifier l’import.

Les configurations sélectives ne peuvent être transférées que d’un modèle inférieur vers le même modèle ou un modèle compatible supérieur. La cible doit disposer d’au moins autant de ports Ethernet. Si les noms de ports ou les fonctions de plateforme diffèrent, clarifier l’affectation au préalable. Pour de telles migrations, le Backup Restore Assistant est souvent plus adapté qu’une modification XML manuelle.

Les modèles wireless ont des limites supplémentaires pour LocalWiFi, les bandes de fréquences, les SSID, les anciens Security Modes, TKIP et les affectations de bridge. Un import partiel réussi ne signifie pas que toute la configuration wireless a été reprise. Contrôler la configuration cible objet par objet.

Classer le SSMK et les informations sensibles

Le Secure Storage Master Key n’est pas saisi lors de l’export. Il devient toutefois essentiel pendant l’import si le paquet contient des mots de passe, des secrets, des clés ou des configurations dépendantes.

• Sur un autre pare-feu, ou après Factory Reset ou reimage, saisir le SSMK associé à l’export.
• Sans le SSMK correspondant, SFOS peut importer le reste, mais les informations sensibles et les configurations dépendantes sont perdues.
• Si l’export ne contient aucune information sensible, aucun SSMK n’est nécessaire.
• Un import sans message d’erreur ne prouve donc pas que tous les secrets et toutes les dépendances ont été repris.

Le SSMK n’est pas stocké avec le fichier exporté. Protéger séparément l’export, la sauvegarde complète, le mot de passe et le SSMK, tout en les associant sans ambiguïté au même pare-feu et à la même période pour la récupération.

Contrôler et modifier le paquet exporté en sécurité

Comprendre le contenu du paquet

Après l’export, un fichier .tar est disponible. Un paquet sans informations sensibles peut ne contenir que Entities.xml. Pour les configurations sensibles, il contient aussi :

• hashFile.json
• propertyfile

Extraire le paquet dans un répertoire de travail dédié :

tar -xvf <fichier-export>.tar

Ne pas renommer Entities.xml. Si hashFile.json et propertyfile sont présents, conserver également ces fichiers et les réintégrer. Un export de fichiers n’est pas un format adapté aux remplacements globaux non contrôlés.

Préparer des modifications traçables

Pour les rapports, les comparaisons et une préparation structurée, Sophos Firewall Config Studio peut analyser Entities.xml localement dans le navigateur. La même règle s’applique : examiner la configuration produite avant de l’importer. Interfaces, zones, NAT, VPN, Device Access, Authentication, certificats et HA exigent notamment une validation propre.

Avant une modification manuelle, copier le fichier Entities.xml intact. Ne modifier ensuite que les valeurs planifiées et examiner le diff par rapport à l’original. Ne pas reconstruire au hasard les noms d’éléments, les ID, les références ou les noms de fichiers. Si la signification d’un champ n’est pas claire, le processus s’arrête avant l’import.

Recompresser les fichiers dans un paquet TAR :

tar -cvf <fichier-import>.tar Entities.xml hashFile.json propertyfile

Si l’export initial ne contenait que Entities.xml, n’inclure que ce fichier. Ne pas inventer de fichiers associés vides ni les reprendre d’un autre export.

Importer la configuration

1. Conserver une session Full Admin existante et une autre voie d’administration ouvertes.
2. Confirmer la fenêtre de maintenance, le fichier de sauvegarde, le mot de passe, le SSMK et la décision de rollback.
3. Ouvrir Backup and firmware > Import export.
4. Sous Import file, sélectionner uniquement le paquet .tar préparé.
5. Lancer Import et saisir le SSMK correspondant lorsque SFOS le demande.
6. Documenter intégralement le succès, les avertissements et les objets rejetés.
7. Avant tout import supplémentaire, valider d’abord l’effet de ce paquet.

Pour un changement, plusieurs petits paquets séparés logiquement sont généralement plus sûrs qu’un grand import non spécifique. Ils rendent la portée d’une erreur, les dépendances et la voie de secours plus compréhensibles. Il s’agit d’une décision d’exploitation, pas d’une garantie que n’importe quels objets peuvent être importés indépendamment.

Pour une automatisation récurrente sous SFOS 22.0 MR2 ou version ultérieure, suivre la procédure distincte exporter et importer une configuration via l’API Sophos Central. L’import local WebAdmin reste pertinent pour des modifications manuelles ciblées et un contrôle indépendant.

Valider complètement l’import

La validation commence par l’objet et se termine par le chemin de trafic réel :

1. Ouvrir les objets importés et leurs valeurs dans WebAdmin.
2. Contrôler les hôtes, services, groupes, profils et stratégies dépendants.
3. Pour les mots de passe, secrets ou clés, tester la fonction, pas seulement la ligne d’objet visible.
4. Ouvrir la règle firewall, NAT, web, VPN ou Authentication concernée et vérifier l’ordre et les références.
5. Effectuer un test positif et un test négatif contrôlés.
6. Dans Log Viewer, comparer Firewall Rule ID, Action, utilisateur, Source, Destination et Service attendus.
7. En HA, contrôler séparément l’état du cluster et le fonctionnement après un changement de rôle planifié ; ne pas supposer la continuité des sessions.
8. Documenter Audit Trail, l’heure, le fichier d’import, le résultat des tests et la décision de rollback.

Pour une validation multicouche des stratégies, consulter Tester systématiquement les règles firewall. En cas d’erreur d’import, apiparser.log, validation.log, validationError.log, applog.log et le journal du service concerné peuvent être utiles. Services et journaux Sophos Firewall donne la correspondance.

Délimiter les erreurs courantes en sécurité

L’import signale une version incompatible

Comparer le firmware actif, la version d’export et l’état des patterns sur les deux pare-feu. Ne pas tenter d’adapter une cible plus ancienne par des modifications XML manuelles. Établir d’abord un firmware et un état de patterns pris en charge ou revoir la voie de migration.

Des objets manquent malgré un import réussi

Vérifier si Include dependent entity a été utilisé et quelles dépendances le type d’objet possède réellement. Pour RED, contrôler également DHCPServer. Ne pas masquer les dépendances manquantes avec des objets de remplacement trop larges ou Any.

Des utilisateurs, OTP ou secrets manquent

Les utilisateurs authentifiés en externe qui sont apparus automatiquement en local lors de leur connexion ne sont pas exportés comme les utilisateurs créés manuellement. Pour la MFA, OTPSettings exporte les paramètres ; OTPTokens ne contient que les tokens émis pour les utilisateurs locaux créés manuellement. Vérifier aussi le SSMK et la cible de l’import.

Si des informations sensibles manquent, ne pas simplement superposer un nouveau secret à l’objet existant. Déterminer d’abord si la cause est un mauvais SSMK, un export sans protection SSMK ou une identité externe non exportable. Tester ensuite l’effet sur les utilisateurs et groupes avec une nouvelle connexion. Le cycle de vie des comptes est décrit dans Créer et gérer des utilisateurs locaux.

Le fichier TAR est rejeté

Vérifier les noms de fichiers et le contenu du paquet. SFOS attend un fichier .tar ; Entities.xml ne doit pas être renommé. Les fichiers hashFile.json et propertyfile présents doivent provenir du même export. Ne pas simplement renommer un fichier ZIP en .tar.

L’import a réussi, mais le trafic ne fonctionne pas

Vérifier les références d’objets, les zones, l’ordre des règles, le NAT, le routage, le contexte utilisateur/groupe et la Firewall Rule ID attendue. Un état d’import vert confirme uniquement l’opération de configuration, pas son effet fonctionnel.

Rollback et checklist

Un import sélectif n’a pas de bouton d’annulation universel. Pour de petites modifications d’objets entièrement documentées, les valeurs précédentes peuvent être rétablies de manière contrôlée. Si la portée ou les dépendances ne sont pas claires, utiliser la voie de restore complète préparée.

Avant de terminer, tous les points suivants doivent être remplis :

• la sauvegarde complète, le mot de passe et le SSMK sont disponibles ;
• le paquet exporté intact et la version modifiée sont archivés séparément ;
• la version cible, les patterns et la compatibilité du modèle sont confirmés ;
• seuls les objets et dépendances nécessaires ont été importés ;
• les avertissements et les objets partiels en échec ont été analysés ;
• les secrets et fonctions dépendantes ont été testés en pratique ;
• les trafics positif et négatif de production atteignent la règle attendue ;
• les journaux et Audit Trail correspondent au changement ;
• en HA, l’état des deux nœuds a été vérifié ;
• aucune copie de travail non protégée ne reste sur le système d’administration.

Questions fréquentes