Documenter les règles Sophos Firewall

Les règles de firewall deviennent rapidement difficiles à suivre. Au départ, chaque règle paraît logique : un serveur doit accéder à Internet, un service est publié, un VPN a besoin d’un accès ou une application nécessite des ports spécifiques. Quelques mois plus tard, on ne sait souvent plus pourquoi la règle existe, qui l’a demandée ni si elle est encore nécessaire.

La contre-mesure la plus simple n’est pas une grande CMDB, mais une description propre directement dans la règle Sophos Firewall. Quelques informations cohérentes aident déjà pour le troubleshooting, les audits, le nettoyage et les transmissions.

Pour la structure d’une règle, Comprendre et configurer correctement les règles Sophos Firewall est l’article de base. Après l’enregistrement d’une règle, Tester une règle Sophos Firewall avec Log Viewer et Packet Capture est utile.

Pourquoi documenter les règles

Une règle de firewall n’est pas seulement une autorisation technique. C’est une décision d’exploitation : qui peut accéder à quoi, via quel service, avec quel risque et pour quelle raison ?

Sans documentation, les problèmes typiques apparaissent vite :

• D’anciennes règles restent actives parce que leur objectif n’est plus connu.
• Les règles de test ne sont jamais supprimées.
• Les audits prennent inutilement du temps.
• Les incidents durent plus longtemps parce que l’owner de l’application n’est pas clair.
• Des changements sont faits directement sur la firewall sans documentation compréhensible.
• Les règles ne sont pas nettoyées par crainte d’effets secondaires.

Une bonne description ne supprime pas tous ces problèmes, mais elle réduit nettement les frictions au quotidien.

Où saisir la description

Le champ Description se trouve directement dans la règle firewall. On ouvre la règle sous :

Rules and policies > Firewall rules

Ensuite, modifier la règle concernée et renseigner le champ de description.

Le champ est limité. Il ne doit donc pas remplacer toute la documentation technique, mais rendre visibles les informations d’exploitation les plus importantes. Les détails peuvent rester dans un ticket, un wiki, une demande de changement ou un dossier de projet.

Ce qui doit figurer dans la description

La source, la destination, les services, le NAT et les Security Features sont déjà visibles dans la règle. La description ne doit donc pas tout répéter, mais expliquer ce qui ne sera plus évident plus tard.

Informations utiles :

• Objectif: Pourquoi la règle existe-t-elle ?
• Application / service: Quelle application ou quel processus a besoin de la règle ?
• Owner: Qui est responsable fonctionnellement ?
• Ticket / change: Où le changement est-il documenté ?
• Créateur / modificateur: Qui a créé ou modifié la règle ?
• Date: Quand la règle a-t-elle été créée ou revue pour la dernière fois ?
• Review: Quand la règle doit-elle être revue ou supprimée ?
• Particularité: Exception, dérogation ou risque assumé.

Toutes les règles n’ont pas besoin de tous les champs. Pour une règle client standard, moins d’informations suffisent souvent. Pour DNAT, VPN, management, accès partenaires ou exceptions temporaires, la description doit être plus précise.

Combiner nom et Description

Le nom de la règle doit être court et structuré. La Description explique le contexte. Il n’existe pas un schéma parfait pour toutes les entreprises. L’important est qu’un administrateur comprenne approximativement ce que fait la règle en parcourant la base de règles, sans devoir ouvrir chaque règle.

En pratique, trois approches fonctionnent bien :

• Source, destination, service: VLAN12_WAN_HTTPS. Bonne variante standard pour clients, serveurs et VPN.
• Application, source, destination: ERP_VPNUSERS_SRVERP_HTTPS. Utile lorsque l’application est plus importante que le segment réseau.
• Type de règle comme préfixe: DNAT_WAN_SRVWEB01_HTTPS. Pratique pour DNAT, règles Drop, règles temporaires ou cas particuliers.

Nous utilisons souvent le modèle SOURCE_DESTINATION_PORT, car il reste technique et lisible même après plusieurs mois. L’action ne doit pas forcément être dans le nom, puisque Sophos Firewall affiche déjà Accept, Drop ou Reject dans la règle.

Exemples typiques :

• VLAN12_WAN_HTTPS
• VLAN20_WAN_DNS
• VLANGUEST_WAN_WEB
• SRVEXC01_WAN_SMTP
• WSTONY01_SRVFILE_SMB
• VPNUSERS_SRVERP_HTTPS
• ADMINNET_FIREWALL_HTTPS
• DNAT_WAN_SRVWEB01_HTTPS
• DNAT_WAN_SRVDMS01_TCP5555
• DROP_VLANIOT_INTERNAL_ANY

Selon l’environnement, le schéma peut être légèrement étendu :

• ZONE_SOURCE_DESTINATION_PORT, par exemple LAN_VLAN12_WAN_HTTPS
• APP_SOURCE_DESTINATION_PORT, par exemple ERP_VPNUSERS_SRVERP_HTTPS
• CHANGE_SOURCE_DESTINATION_PORT, par exemple CHG1842_VPNUSERS_SRVERP_HTTPS

Dans les petits environnements, un modèle simple suffit souvent. Dans les environnements plus grands avec de nombreux VLANs, VPNs, réseaux serveurs et règles DNAT, un standard cohérent devient beaucoup plus utile. Des préfixes comme DNAT, DROP ou TEMP sont pertinents lorsqu’ils facilitent la lecture rapide ou indiquent un type de règle particulier.

Les noms très génériques sont à éviter, car ils n’aident plus par la suite :

• Rule1
• Test
• Allow
• Internet
• Temp

Exemple compact

Exemple de règle productive :

DNAT - Synology HTTPS
---
AUTHOR: Patrizio
LAST MODIFIED: 24.06.2026 [PP]
SOURCE: WAN_CH, WAN_DE
DESTINATION: WAN_Public_IP
SERVICE: TCP 5555 -> TCP 443
COMMENT: Access to Synology DSM only from defined countries
DOC: https://ticket/CHG-1842

Si l’espace est limité, on peut faire plus court. L’objectif, l’owner et le ticket doivent toutefois rester visibles :

ERP VPN access, Owner Finance, CHG-1842, Review 2026-12

Pour une règle temporaire, la date d’expiration doit être particulièrement claire :

Temp vendor access pour migration, Owner IT, CHG-1910, remove after 2026-07-31

Ce qu’il ne faut pas écrire dans la Description

Le champ Description ne doit pas contenir :

• des mots de passe,
• des clés API,
• des données personnelles sans raison,
• des données client confidentielles,
• des instructions d’accès complètes pour des tiers,
• de longues URL externes sans contexte interne.

Si des prestataires externes sont impliqués, un contact interne, un ticket ou une référence documentaire suffit généralement. Les détails sensibles doivent rester dans un système de ticketing, de documentation ou de gestion des mots de passe adapté.

Review et nettoyage

La description des règles n’est que la première étape. Le point essentiel est de vérifier régulièrement les règles.

Procédure pratique :

1. Marquer les règles sans Description.
2. Vérifier les règles contenant Test, Temp, Allow any ou un nom peu clair.
3. Examiner les compteurs d’utilisation et Log Viewer.
4. Rechercher l’owner ou le ticket.
5. Désactiver les règles inutiles, les surveiller puis les supprimer plus tard.
6. Documenter le changement.

Lors de chaque nettoyage, Log firewall traffic devrait être activé pour les règles importantes afin que Log Viewer montre si une règle est encore utilisée. Pour les tests après modification, consulter Tester une règle Sophos Firewall avec Log Viewer et Packet Capture.

Standard minimum pour les nouvelles règles

Les nouvelles règles Sophos Firewall devraient au minimum avoir :

• un nom parlant,
• une source et une destination claires au lieu de Any inutile,
• le logging activé pour les règles importantes,
• une Description avec objectif, owner et ticket,
• une date de review pour les règles temporaires ou risquées,
• aucun secret dans le champ Description,
• un test après l’enregistrement.

Pour les serveurs publiés, Publier un serveur avec DNAT sur Sophos Firewall est également pertinent. Pour les bases du NAT, voir Comprendre le NAT sur Sophos Firewall : SNAT, DNAT, MASQ, PAT.

FAQ