Sophos Firewall Configuration Viewer: auditer et comparer les configurations

19 février 2026 • 15 min read

Bonjour à tous,

si tu as déjà géré une Sophos Firewall dans un vrai contexte business, tu connais le dilemme : la configuration est la “single source of truth”. Mais dès que tu veux la relire en dehors de l’interface web, la documenter proprement, ou comparer un avant/après changement, ça devient vite pénible.

Oui, tu peux faire des captures d’écran. Oui, tu peux exporter des règles individuellement. Mais dès qu’on parle de changements plus conséquents (migration WAN, nouveaux VLAN, nettoyage d’objets, refonte de la logique NAT, “juste rapidement” ajuster quelques VPN), tu veux surtout deux choses :

Une configuration lisible.
Un comparatif qui n’est pas “diff du XML et pleurer”.

C’est exactement là que le Sophos Firewall Configuration Viewer devient utile.

Cet outil ne te retire pas la responsabilité. Tu dois toujours concevoir une configuration propre et tester tes changements correctement. Mais il enlève quelque chose qui coûte un temps fou au quotidien : le problème du format. Il transforme un export techniquement correct mais impossible à lire en une vue exploitable.

Et oui, je suis assez pointilleux là-dessus. Quand je prépare un change, je ne veux pas seulement savoir qu’il y a eu un changement. Je veux savoir quoi exactement a changé, et si j’ai touché par erreur un objet, une règle NAT ou un réglage VPN au passage. Le viewer est un outil étonnamment pragmatique pour ça.

Qu’est-ce que le Sophos Firewall Configuration Viewer ?

Le Sophos Firewall Configuration Viewer est un outil accessible via navigateur qui convertit les configurations Sophos Firewall en un format compréhensible par un humain. Il permet de :

filtrer, trier et rechercher dans la configuration
rechercher des objets/hôtes/FQDN et voir où ils sont référencés
comparer deux configurations (Added/Modified/Removed)
exporter le résultat en rapport HTML

Important : c’est un outil autonome que tu ouvres simplement dans un navigateur. Rien à installer, et tu peux l’utiliser depuis (presque) n’importe quel laptop d’admin. C’est exactement ce que j’aime : ça s’intègre dans les workflows existants, sans friction.

Sous le capot, il travaille avec ce que Sophos te fournit déjà : l’export de configuration en XML (typiquement Entities.xml). La différence, c’est la présentation. Au lieu de fixer des structures XML, tu obtiens une vue qui ressemble à une documentation bien organisée.

Et ce n’est pas seulement “view”. En pratique, trois fonctions reviennent tout le temps :

Lire : une vue structurée de la config, filtrable.
Recherche/Références : trouver des objets et voir où ils sont utilisés.
Comparer : avant/après ou firewall A vs firewall B.

Le point le plus important pour la sécurité et la vie privée : Sophos met en avant que les données sont traitées localement dans ton navigateur et que rien n’est “uploadé”. Parsing, analyse et génération de rapports sont censés rester sur ta machine.

Tu peux accéder à l’outil ici : Sophos Firewall Configuration Viewer

Si tu préfères une démo rapide d’abord, voici le TechVid de Sophos :

Un cas réel dans une PME

Vendredi, 15h30. Une entreprise d’environ 80 personnes : nouvelle connexion Internet, nouvelles IP publiques, et en parallèle un petit projet (nouveau CRM, nouveaux sous-réseaux). La demande de changement est bien cadrée : quelles règles NAT, quels endpoints VPN et quelles règles firewall doivent être ajustés.

Dans la réalité, tu as ce que tu as toujours :

Un objet comme WAN_Public_IPs est utilisé dans trois règles NAT, deux règles “business application”, et une règle WAF “historique” que personne n’a regardée depuis des années.
Un objet FQDN pour un SaaS a été mis dans un groupe un jour, et se retrouve maintenant dans dix règles, mais seulement deux sont encore pertinentes.
Tu veux nettoyer, mais tu ne veux pas l’appel du lundi matin : “Depuis le change, X ne marche plus.”

C’est là que le Configuration Viewer fait gagner du temps, vraiment.

Mon workflow typique dans ces situations :

Exporter avant (sauvegarder une baseline)
Appliquer le change
Exporter après
Faire un diff dans le viewer et joindre l’HTML au ticket
Avant de supprimer des objets : utiliser Usage Reference pour vérifier où ils sont réellement utilisés

Ce n’est pas qu’un confort. Ça rend les changements traçables. Et c’est exactement ce que veulent les audits, les validations internes, et ton toi du futur.

Comment utiliser l’outil en pratique

1) Exporter la configuration (Full ou Selective)

Export directement depuis le firewall :

WebAdmin : Backup & Firmware > Import / Export
Export soit Export full configuration (tout) soit Export selective configuration (certaines parties, optionnellement avec “Include dependent entity”)

Sophos génère un fichier .tar que tu télécharges.

Quelques détails qui font la différence en pratique :

Full export est mon choix par défaut pour le change management (baseline/diff). Tu récupères tout et tu as moins de risques de manquer des dépendances.
Selective export est top quand tu veux review une zone précise (par exemple uniquement interfaces + routing), ou quand tu dois partager quelque chose avec des tiers (ISP/vendor) et que tu veux minimiser ce que tu dévoiles.
Include dependent entity est souvent critique en export sélectif : si tu exportes des règles firewall, tu veux généralement aussi les objets réseau/service référencés. Sinon l’export est incomplet et tu perds le contexte.

Pro tip pour les comparaisons : pour “Compare”, exporte toujours deux configurations avec la même sélection (Full vs Full, ou Selective vs Selective avec les mêmes cases). Si tu compares Full contre Selective, le diff sera spectaculaire, mais la plupart du temps inutilisable.

2) Extraire le TAR et trouver `Entities.xml`

Depuis le .tar, extrais Entities.xml (selon le type d’export, ça peut aussi s’appeler entities.xml).

Sur macOS/Linux :

tar -xvf backup.tar
ls -la

Sur Windows, tu peux utiliser des outils comme 7-Zip.

Si (comme moi) tu veux éviter que ces backups traînent dans Downloads, crée un répertoire de travail temporaire. Exemple sur macOS/Linux :

WORKDIR="$(mktemp -d)"
tar -xvf backup.tar -C "$WORKDIR"
ls -la "$WORKDIR"

À la fin, tu peux supprimer le répertoire. Ça paraît basique, mais c’est exactement ce genre d’hygiène qui évite de laisser des configs sensibles traîner pendant des semaines.

Pour ton radar sécurité : d’après la documentation Sophos, un export sans contenu sensible (par exemple uniquement les interfaces) ne contient souvent que Entities.xml. Dès que des infos sensibles sont incluses (par exemple des users), le TAR peut aussi contenir des fichiers comme hashFile.json et propertyfile.

En pratique : traite tout le TAR comme confidentiel.

3) Rendre une configuration “lisible”

Dans le viewer, choisis “Single configuration” (ou similaire) et upload le Entities.xml. Tu obtiens une vue rendue de la configuration.

Selon la taille, le chargement prend quelques secondes. Ensuite tu as un truc qui me manque souvent dans l’interface web : une vue “documentation” de la config, sans naviguer dans cinquante menus.

Ce que j’aime le plus : tu peux filtrer fort à gauche. Si ton change concerne le routing/NAT, tu n’as pas envie de scroller sur chaque option de reporting, chaque toggle de logs, et chaque feature secondaire. Tu actives juste les sections qui t’intéressent maintenant.

Combinaisons de filtres typiques en prod :

uniquement règles firewall + NAT
uniquement interfaces + routing
uniquement VPN

Quand j’audite ou reprends un environnement pour la première fois, je passe généralement dans cet ordre :

Interfaces/zones (qu’est-ce qui est inside, qu’est-ce qui est outside ?)
Routing/SD-WAN (comment le trafic sort, d’où viennent les routes de retour ?)
NAT (qu’est-ce qui est publié, qu’est-ce qui est réécrit ?)
Règles firewall (quels flux sont réellement autorisés ?)
VPN (site-to-site et remote access, selon le setup)

Ce n’est pas le seul ordre possible, mais ça évite d’évaluer des règles sans comprendre la topologie.

Et si tu as besoin de documentation ou d’approbation : tu peux exporter un rapport HTML à tout moment.

J’aime bien m’en servir comme “pack de review” : exporter le HTML, le joindre au ticket de change (ou le stocker dans une doc interne sécurisée), et quelqu’un d’autre peut relire la config sans avoir accès au firewall. C’est très pratique pour le principe des quatre yeux, les validations internes ou les audits externes.

4) Usage Reference : “Où cet objet est-il réellement utilisé ?”

C’est la killer feature pour moi.

Les configs Sophos reposent beaucoup sur des objets : hôtes, réseaux, services, FQDN, groupes. C’est super, parce que tu peux réutiliser proprement. Le problème : après quelques années, il n’est souvent plus évident de savoir où un objet est référencé.

Et c’est là que les erreurs classiques arrivent :

quelqu’un supprime un objet “parce qu’il a l’air vieux”, et découvre plus tard qu’il était encore utilisé dans une règle NAT
quelqu’un modifie un objet (par exemple élargit une plage IP) et change involontairement plusieurs policies d’un coup

Usage Reference dans le viewer rend ces dépendances visibles. Au lieu de chercher dans l’UI “au feeling”, tu utilises la recherche/Usage Reference pour voir où un objet ou un hostname est référencé.

Exemple du TechVid : tu cherches box et tu vois tout de suite quelles policies/règles NAT référencent l’objet FQDN.

Le côté pratique, c’est le click-through : tu passes de la recherche à l’objet, puis tu vois les références (par exemple quelle policy firewall ou quelle règle NAT l’utilise). Quand je fais un change de nettoyage, j’exporte souvent cette vue en HTML et je l’attache au ticket. Plus tard, c’est clair pourquoi j’ai supprimé ou modifié un objet.

Parfait pour :

nettoyage (supprimer des objets obsolètes)
planification de change (quelles règles doivent vraiment être adaptées)
troubleshooting (pourquoi une règle matche encore quelque part ?)

5) Comparer deux configurations (Before/After)

Sur la page d’accueil, tu peux choisir “Compare” au lieu de “View” et upload deux fichiers Entities.xml.

Ça a l’air simple, mais c’est un pattern très puissant. Je l’utilise par exemple pour :

avant/après de changes (mon classique)
comparer test/staging vs production pour trouver du drift
valider après migrations (nouvelle WAN, nouvelle logique NAT, nouveau VPN)

Ce que j’aime dans le mode compare : ce n’est pas juste un diff texte brut. Il essaye de regrouper les changements de manière logique. Tu n’as pas seulement “du XML différent”, tu as : cet objet a été ajouté, cette règle a été modifiée, cette entrée a été supprimée.

C’est exactement ce qu’il faut pour le change management :

résumé : qu’est-ce qui a été supprimé, modifié, ajouté ?
détails par objet/règle
XML brut côte à côte (optionnel)
export HTML pour ticket/audit

Mon workflow perso est assez direct (mais efficace) :

Lire le résumé : les ordres de grandeur sont cohérents ? (par exemple “j’ai modifié 3 règles” vs “200 objets modified”)
Creuser les zones critiques : interfaces/WAN, routing, NAT, VPN, règles firewall
Sauvegarder l’export HTML pendant que tout est encore frais

Surtout l’étape 1 enlève beaucoup de stress. Si je vois que seuls les objets attendus ont bougé, je dors beaucoup mieux le week-end.

Si tu prends l’habitude de sauvegarder un diff avant/après pour les gros changes, tu vas te simplifier la vie sur le long terme.

Fonctions et features en détail

Jusqu’ici, l’outil est déjà très utile. Mais après quelques utilisations, tu comprends : le viewer est moins “nice to have” qu’une petite boîte à outils pour des questions d’admin typiques. Voici les fonctions que j’utilise réellement souvent, un peu plus en détail.

Human-Readable View : enfin sans marathon de clics

Dans l’interface web Sophos, les réglages sont souvent bien regroupés, mais dispersés sur plein de pages. Pour du quick work, ça va. Pour des audits ou de la planification de change, c’est fatigant parce que tu perds le contexte.

Le viewer transforme ça en une vue compacte. Je m’en sers pour un reality check rapide :

Quelles interfaces/zones existent vraiment ?
Quelles règles NAT publient quels services ?
Quelles règles sont trop larges parce qu’à l’époque “il fallait que ça marche” ?

Ça ne remplace pas un design propre, mais ça rend visible comment le firewall est réellement décrit.

Filtres : se concentrer sur ce qui compte maintenant

Les filtres à gauche semblent simples, mais en pratique, c’est de l’or. La plupart des changes ne concernent pas toute la config, mais une zone précise (WAN, NAT, VPN, routing).

Si j’intègre une nouvelle connexion Internet, je masque tout et je me concentre sur :

interfaces/WAN
routing/SD-WAN
NAT
règles firewall (pour les flux concernés)

Ça a l’air trivial, mais ça évite de partir dans des side quests pendant une review.

Recherche : de “box” à “10.20.30.0/24”

La recherche est un super point d’entrée quand tu viens de l’exploitation et que tu n’as qu’un symptôme :

“Notre service vers box.com ne marche plus”
“Le nouveau réseau de la filiale 10.20.30.0/24 n’a pas accès”
“Pourquoi SMTP est encore ouvert ?”

Tu cherches par nom, IP, FQDN ou objet, et tu arrives vite au bon endroit.

Usage Reference : voir l’impact (avant que ça fasse mal)

Usage Reference est la fonction qui décide le plus souvent si un nettoyage est “courageux” ou “responsable”. Je l’utilise surtout pour trois cas :

Supprimer des objets : vérifier d’abord s’il est référencé quelque part.
Modifier des objets : vérifier d’abord combien de règles/policies seraient impactées indirectement.
Planifier un change : vérifier d’abord quelles règles sont réellement liées au même objet.

Si tu fais ça systématiquement, le nombre de “ah oui, c’était encore lié à ça” chute drastiquement.

Compare + export HTML : mon standard pour le change management

Le mode compare est ma “preuve” qu’un change s’est passé comme prévu.

La plupart du temps je fais comme ça :

Export avant
Export après
Compare
Sauvegarder le diff HTML et le joindre au ticket

Ça paraît un peu pédant, mais ça prend quelques minutes et ça peut éviter des heures de discussion plus tard quand quelqu’un demande ce qui a changé exactement. En équipe, c’est aussi un excellent format de review : tu peux demander à quelqu’un de lire l’HTML diff et de valider uniquement les points critiques.

Sécurité : points forts et limites

1) Privacy-first, oui. S’insouciance, non.

Que Sophos affirme que rien ne sort de ton navigateur est un gros avantage, surtout pour les données de config.

Mais une config firewall est presque toujours sensible. Même sans mots de passe en clair, tu y retrouves souvent :

réseaux internes, VLAN, schémas IP
définitions NAT et endpoints publics
topologies VPN
groupes d’objets (souvent plus révélateurs qu’on ne pense)

2) L’export est le vrai risque

Le viewer t’aide à lire. Mais le risque est généralement avant et après :

pendant le download du TAR
pendant l’extraction
lors de la sauvegarde/partage des rapports HTML

Sophos documente explicitement que les exports contenant des informations sensibles peuvent inclure des fichiers additionnels, et que la question de la secure storage master key est importante lors des imports.

Mes conseils au quotidien :

garder les exports localement le moins longtemps possible (et nettoyer après)
éviter de mettre des rapports dans des tickets “ouverts”
si tu travailles avec des tiers : privilégier les exports sélectifs et ne partager que le nécessaire

3) SSH/Advanced Shell : le viewer ne voit que ce qui est dans l’export

Ça arrive plus souvent qu’on ne l’avoue : pendant un incident, quelqu’un se connecte en SSH et “fixe rapidement” quelque chose dans l’Advanced Shell.

Le point clé, ce n’est pas si le fix survit à un reboot ou non. Le point clé, c’est : si quelque chose n’arrive pas dans l’export (Entities.xml), c’est invisible dans le viewer. Et ça peut arriver avec des ajustements via Advanced Shell/SSH, parce que ça n’apparaît pas toujours comme de la “config normale” dans l’export.

Si tu touches des choses via SSH/Advanced Shell, documente-le à part et prévois de le représenter proprement via la configuration WebAdmin. Sinon, le prochain restore, HA failover ou firmware update est le moment où ça te rattrape, ou tu passes simplement à côté dans le diff.

4) Règles pratiques qui aident en prod

Utilise un profil navigateur sans un zoo d’extensions pour ce genre de tâche.
Stocke TAR/HTML uniquement là où tu stockerais d’autres configs confidentielles.
Si tu dois partager : export minimal (selective) et pense aux dépendances.

Conclusion

Le Sophos Firewall Configuration Viewer ne fait pas les gros titres. Mais honnêtement : ce sont exactement ces outils qui te sauvent la vie au quotidien.

Avec les années, j’ai vu assez de configurations où le vrai stress n’était pas la “tech”, mais la traçabilité : qu’est-ce qui a changé, quand ? Est-ce que cet objet est vraiment inutilisé ? Est-ce qu’on a touché autre chose par accident ? Dans l’UI, on peut trouver beaucoup de choses, mais rarement vite. Et lire un export XML à la main, personne ne fait ça plus de cinq minutes volontairement.

Le viewer comble bien ce trou. Je peux relire une config au calme, la traiter comme de la doc, filtrer, vérifier les références, et sauvegarder un HTML diff. Ça peut sembler “nice”, mais en équipe c’est un vrai levier : les reviews deviennent plus simples, les audits moins douloureux, et tu as moins de surprises le lundi matin.

Si tu ne retiens qu’une chose : crée un petit réflexe.

Avant les gros changes : export une fois, après le change export à nouveau, lance Compare, et archive le HTML diff. Ça prend quelques minutes, mais c’est l’une des façons les plus fiables de lutter contre le “je pense qu’on n’a changé que X”.

Et comme toujours : le viewer rend les configs plus lisibles, mais pas automatiquement plus sûres. Le raisonnement, c’est toujours toi. Il te donne juste enfin un outil qui ne travaille pas contre toi.

Si tu as déjà fait des ajustements “quick and dirty” via SSH dans l’Advanced Shell : garde en tête qu’ils ne se retrouvent pas forcément dans les backups, et donc ils ne seront pas visibles dans le viewer non plus.

Sources et liens utiles

À la prochaine, Joe

Sophos Firewall Configuration Viewer: auditer et comparer les configurations

Table of Contents

Qu’est-ce que le Sophos Firewall Configuration Viewer ?

Un cas réel dans une PME

Comment utiliser l’outil en pratique

1) Exporter la configuration (Full ou Selective)