Tester proprement une règle Sophos Firewall

Il ne suffit pas de sauvegarder une règle de pare-feu, il faut aussi la tester de manière ciblée. Surtout avec le filtrage Web, l’inspection TLS, le NAT, l’IPS ou le User Matching, une règle peut sembler correcte visuellement mais ne pas fonctionner comme prévu.

Plusieurs outils sont adaptés pour le test :

• Log viewer pour les événements réels et les décisions de règles
• Live Connections pour les sessions actuellement établies, les interfaces, Rule ID, NAT ID et la passerelle
• Policy tester pour la logique des politiques Web, de pare-feu et SSL/TLS
• Packet capture pour le flux réel des paquets
• tcpdump pour des captures plus longues, des fichiers PCAP et des cas de support

L’ordre correct est important : d’abord, vérifiez que le test est bien défini et que la règle génère des logs. Ensuite, le Log Viewer montre quelle décision le pare-feu a réellement enregistrée. Le Policy tester aide à comprendre la logique attendue de la politique, mais ne prouve pas le flux réel des paquets. Packet Capture est la meilleure preuve lorsque le routage, le NAT, le VLAN, le VPN, le fournisseur ou un système cible peuvent être impliqués. Si le test doit durer plus longtemps, nécessite un fichier PCAP ou si le support Sophos doit analyser la capture, tcpdump sur le Sophos Firewall est l’outil le plus approprié.

Un bon test de règle ne répond donc pas seulement à la question de savoir si une règle “fonctionne”. Il montre quelle Rule ID a réellement matché, quelle NAT ID était impliquée, si des Security-Features sont intervenues et si l’aller et le retour empruntent le chemin attendu.

Utiliser correctement Live Connections et Connection List explique comment regrouper une session déjà établie, filtrer un flux et lire ses champs de politique et de chemin.

Quel article convient ?

Cet article est une bonne introduction si vous souhaitez tester une tentative de connexion spécifique avec une IP source, une destination, un service et une heure. Pour des problèmes similaires, un article plus spécifique est souvent plus rapide :

• L’utilisateur manque dans Live Users ou apparaît avec le mauvais groupe ou la mauvaise IP source : Résoudre méthodiquement les erreurs d’authentification sur Sophos Firewall.
• Une règle ne matche pas du tout ou une autre règle l’emporte : Vérifier les causes d’une règle Sophos Firewall qui ne correspond pas.
• DNAT, SNAT, MASQ ou l’ordre NAT est impliqué : Comprendre le NAT sur Sophos Firewall.
• Un serveur interne est publié depuis Internet : Publier un serveur via DNAT.
• Packet Capture montre des drops, Violation ou des raisons de drop inattendues : Analyser les paquets rejetés par Sophos Firewall.
• L’ensemble de Log Viewer n’affiche plus de nouveaux événements : Vérifier précisément les filtres, Local reporting et le problème Garner connu.
• SSL VPN est connecté, mais les cibles internes ne fonctionnent pas : Configurer l’accès à distance SSL VPN sur Sophos Firewall.
• Site-to-Site IPsec ou Remote-Access IPsec pose des problèmes : Dépannage IPsec VPN sur Sophos Firewall.
• Les outils WebAdmin ne suffisent pas et des logs locaux sont nécessaires : Associer correctement les service logs Sophos Firewall.
• Un cas de support nécessite une archive de logs, des données IPsec ou des fichiers PCAP : Sauvegarder les logs de Sophos Firewall pour le support et l’analyse.

Cette distinction empêche d’examiner trop largement un problème spécifique de NAT, VPN, routage ou service avec un test de règle général.

Bien classer les outils

• Log viewer : montre Rule ID, NAT ID, Action, utilisateur et décisions de Security-Features. Il ne prouve pas les paquets qui n’atteignent pas du tout le pare-feu.
• Policy tester : montre la politique firewall, Web et SSL/TLS attendue pour des entrées définies. Il ne prouve pas le vrai retour, le comportement SD-WAN, les pertes de paquets ou le comportement du fournisseur.
• Packet capture : montre si les paquets arrivent, sont transférés et si des réponses reviennent. Il n’explique pas automatiquement l’intention fonctionnelle derrière une règle ou Web Policy.
• tcpdump : utile pour des captures plus longues, des filtres BPF très précis, des fichiers PCAP et l’analyse Wireshark. Rule ID, NAT ID ou décisions Web Policy ne sont pas visibles directement dans WebAdmin avec cet outil.
• Central Reporting ou Syslog : aide pour l’historique, les rapports, la corrélation SIEM et l’analyse ultérieure. Pour le flux de paquets live et les détails de services locaux, les outils locaux restent généralement plus rapides.

Si une règle est prétendument “non appliquée”, il ne faut donc pas immédiatement la modifier. Souvent, la cause réside dans le NAT, le routage, une règle supérieure, un manque de journalisation ou une fonctionnalité de sécurité. Pour une recherche systématique des erreurs, consultez également Vérifier les causes d’une règle Sophos Firewall qui ne correspond pas.

Pour le live troubleshooting, le Log Viewer local reste généralement plus rapide que Central Reporting ou un SIEM. Les logs centralisés sont importants lorsque les événements doivent être compris, corrélés ou conservés plus longtemps. Pour la mise en place, consultez Central Firewall Reporting et Envoyer les journaux Syslog à un SIEM.

Procédure rapide pour le test de règle

Pour la plupart des cas de support, une procédure claire suffit :

1. Définir le cas de test avec IP source, destination, service, utilisateur et heure.
2. Activer Log firewall traffic dans la règle concernée.
3. Sous System services > Log settings, vérifier si le type de journal correspondant est activé pour Local reporting, Central reporting ou Syslog.
4. Vérifier la position de la règle et le compteur de données transférées.
5. Reproduire le test exactement une fois.
6. Filtrer le Log Viewer par IP source, IP de destination et service.
7. Noter la Rule ID et la NAT ID à partir de l’entrée de log réelle.
8. Utiliser le Policy tester uniquement pour la logique de politique.
9. Démarrer Packet Capture si le Log Viewer et le Policy tester ne correspondent pas.
10. Documenter le résultat avant de déplacer ou de modifier une règle.

Il est important de ne modifier qu’un seul cas de test par passage. Si la position de règle, NAT, DNS, routage et client changent en même temps, le succès ultérieur ne peut plus être attribué proprement.

Cette procédure empêche de modifier inutilement une règle fonctionnelle alors que le problème réel réside dans le NAT, le routage, le DNS, l’inspection TLS ou un système cible.

Avant le test

Il faut d’abord noter précisément ce qui doit être testé :

• Source IP : 172.16.10.25
• Utilisateur : user@domain.local
• Source zone : LAN
• Destination : https://www.example.com
• Service : HTTPS
• Règle attendue : LAN_to_WAN_Clients
• Action attendue : autorisé, bloqué, decrypted, non decrypted

Ensuite, activer Log firewall traffic dans la règle de pare-feu concernée. Sans journalisation, le Log Viewer est d’une utilité limitée.

La journalisation comporte ici deux niveaux. Premièrement, la règle concernée doit elle-même journaliser, par exemple avec Log firewall traffic. Deuxièmement, les types de journaux adaptés sous System services > Log settings doivent être actifs pour la destination souhaitée : Local reporting pour Log Viewer, Central reporting pour Sophos Fusion (anciennement Sophos Central) et les destinations Syslog configurées pour les serveurs de journaux externes. Si l’option est activée dans la règle mais que le type de journal correspondant n’est pas stocké localement ou à l’extérieur, la recherche d’erreurs devient vite contradictoire.

Pour de courts tests en direct, Log Viewer suffit. Si un test doit rester traçable plus tard, il faut vérifier à l’avance si Central Reporting ou Syslog reçoit également le type de journal pertinent. Sinon, la preuve peut ne plus être disponible après une rotation des journaux ou un redémarrage.

Étape 1 : Vérifier la position de la règle

Ouvrez Rules and policies > Firewall rules et vérifiez :

• La règle est-elle au-dessus des règles plus générales ?
• Est-elle active ?
• La vue IPv4 ou IPv6 correcte est-elle sélectionnée ?
• Est-elle dans un groupe de règles pertinent ?
• Y a-t-il des exclusions ?
• Y a-t-il une règle créée automatiquement au-dessus ?

Pour disposer d’une base de comparaison nette, ouvrez More options pour la règle et sélectionnez Reset data transfer count. Cette action remet à zéro le compteur de données transférées, et non un compteur de correspondances distinct. Une nouvelle valeur après le test indique que des données ont transité par la règle ; confirmez néanmoins la Rule ID et l’Action dans Log Viewer.

Étape 2 : Ouvrir le Log Viewer

Ouvrez le Log viewer en haut à droite dans la console WebAdmin.

L’utilisation complète des modules, des filtres temporels et de champ, de Detailed view, de src_trans_ip, de Log occurrence et de l’export CSV est expliquée dans Utiliser correctement le Log Viewer de Sophos Firewall.

Filtres utiles :

• Module : Firewall
• IP source
• IP de destination
• Port de destination
• Rule ID
• Nom de la règle
• Action
• Utilisateur

Pour le trafic Web, vérifiez également :

• Web filter
• SSL/TLS inspection
• Application filter
• IPS

Le Log Viewer se met à jour automatiquement. Pour une analyse tranquille, vous pouvez mettre la vue en pause, filtrer, puis reprendre.

Les sessions firewall n’apparaissent pas nécessairement immédiatement : Sophos Firewall écrit normalement le journal de session lorsqu’il reçoit un événement Destroy et ferme la connexion. Si une connexion se termine sans événement Destroy, par exemple lors d’une perte de connectivité Internet, l’entrée peut manquer. Les connexions SSL/TLS sont journalisées une fois le handshake terminé et à la fermeture. Pour un test court, fermez donc volontairement la connexion de test, puis actualisez Log Viewer ; examinez une session encore ouverte sous Current activities > Live connections.

Étape 3 : Reproduire le test

Le test doit être effectué à partir d’un client défini :

• Ouvrir un site Web
• Envoyer un ping
• Tester un port
• Lancer une application
• Établir une connexion VPN
• Télécharger un fichier

Si possible, ne faites qu’un test à la fois. Sinon, les logs et les compteurs de règles se mélangent.

Ensuite, vérifiez :

• Le compteur de données transférées augmente-t-il ?
• Voyez-vous un log dans le Log Viewer ?
• Quelle Rule ID est affichée ?
• Quelle NAT Rule ID est affichée ?
• Le trafic est-il autorisé ou bloqué ?
• Une fonctionnalité de sécurité est-elle appliquée ?

Pour une connexion de longue durée, ouvrez Current activities > Live connections, regroupez par Source IP address ou Username, puis cliquez sur le nombre dans Total. L’heure de début, les interfaces entrante et sortante, la source, la destination, les ports, la Firewall Rule ID et la NAT Rule ID doivent correspondre au cas de test. Si la connexion n’y figure pas alors que le client l’établit, utilisez ensuite Packet Capture ; recherchez plutôt une connexion déjà fermée dans Log Viewer.

Si le Log Viewer reste vide, ce n’est pas encore une preuve contre la règle. Vérifiez d’abord la journalisation, le filtre temporel, le filtre de module et le flux réel des paquets. Souvent, le trafic n’atteint pas le pare-feu, la règle ne logge pas, le mauvais type de log est désactivé ou le test utilise une autre IP cible que prévu.

Étape 4 : Utiliser le Policy tester

Le Policy tester est utile pour vérifier quelle règle de pare-feu, règle d’inspection SSL/TLS ou politique Web s’appliquerait théoriquement au trafic Web.

Chemin du menu :

Diagnostics > Tools > Policy tester

Entrées typiques :

• URL
• Utilisateur
• Heure et jour
• IP source
• Zone source
• Méthode de test

Comme méthode de test, choisissez par exemple Firewall, SSL/TLS, and web, si vous souhaitez vérifier la combinaison de la règle de pare-feu, de la règle d’inspection SSL/TLS et de la politique Web.

Pour Source zone, Auto-detection peut déterminer la zone à partir de l’IP source. Sélectionnez explicitement la zone si l’outil en détecte une mauvaise ou si le test doit être limité à une zone précise. L’URL détermine le protocole et le port par défaut : https://www.example.com teste HTTPS sur le port 443 ; sans protocole, le testeur utilise HTTP. Indiquez un port de destination différent dans l’URL, par exemple testexample.com:21.

Le Policy tester ne montre pas seulement Accepted ou Blocked, mais aussi la règle de pare-feu correspondante, la destination reconnue, la zone source et, selon la méthode de test, d’autres informations Web ou SSL/TLS. Cela permet de voir rapidement si le trafic atterrit fondamentalement dans la règle attendue.

Le nom d’une règle correspondante est un lien qui ouvre la table de règles concernée. Après une modification, relancez le même test sans changer les entrées. Avec Web policy only, aucune règle firewall n’est appliquée ; cette méthode teste uniquement HTTP et HTTPS avec la politique Web sélectionnée.

Important :

⚠️ Le Policy tester ne remplace pas un vrai test de flux de paquets. Les résultats des tests de politique ne reflètent pas de manière fiable les routes SD-WAN. Le comportement réel peut donc différer si SD-WAN, routage ou passerelles sont impliqués.

Le test du trafic Web utilise le modèle Transparent Mode. Il ne reproduit pas complètement une connexion Direct Web Proxy avec un proxy configuré explicitement. Les règles contenant des adresses MAC sous Source networks and devices ne peuvent pas non plus être mises en correspondance. Dans ces cas, un test réel depuis le client, Log Viewer et Packet Capture sont déterminants.

Erreur de SFOS 22.0 GA corrigée dans MR1

Le problème connu NC-177587 affectait SFOS 22.0.0 GA-Respin Build 411 et a été corrigé dans SFOS 22.0.1 MR1 Build 490. Dans la version GA, Policy Test et Policy Route Test pouvaient afficher à tort le trafic comme bloqué ou l’attribuer à une règle incorrecte, alors que le trafic de production était traité correctement.

Indépendamment de cette erreur corrigée, il reste important de comparer les journaux et paquets réels, car le Policy tester ne reproduit pas un flux de paquets complet.

Pour les administrateurs, la conséquence est importante : si le Policy tester montre un résultat inattendu, mais que le Log Viewer, le compteur de données transférées et le Packet Capture confirment le flux réel des paquets, il ne faut pas immédiatement modifier les règles de pare-feu ou les règles NAT. Vérifiez d’abord si cela concerne uniquement l’affichage du diagnostic.

Procédure pratique en cas de résultats contradictoires :

1. Documenter précisément le test avec IP source, destination, service et utilisateur.
2. Filtrer le Log Viewer par IP source, IP de destination et service.
3. Vérifier la Rule ID et la NAT Rule ID à partir de l’entrée de log réelle.
4. Démarrer Packet Capture avec un filtre étroit.
5. Comparer le trafic entrant, transféré et de retour.
6. Considérer le résultat du Policy tester uniquement comme une indication, pas comme une preuve unique.
7. Vérifier la version du firmware et les problèmes connus de Sophos avant de modifier les règles productives.

Cette prudence vaut particulièrement pendant les fenêtres de maintenance. Un mauvais résultat de diagnostic ne doit pas conduire à réordonner des règles productives fonctionnelles ou à adapter des règles NAT sans preuve.

Le Policy tester est particulièrement bon pour :

• Politique Web
• Catégorisation des URL
• Contexte utilisateur
• Planification
• Règle d’inspection SSL/TLS
• Correspondance des règles de pare-feu pour le trafic Web

Il est moins bon pour :

• décisions de routage réelles
• retour NAT
• règles avec adresses MAC sous Source networks and devices
• pertes de paquets
• problèmes de fournisseur ou de commutateur
• applications avec plusieurs connexions et ports

Étape 5 : Utiliser Packet Capture

Si le Log Viewer et le Policy tester ne suffisent pas, utilisez Diagnostics > Packet capture.

Le filtre doit être étroit, par exemple :

• IP source du client
• IP de destination du serveur
• Port de destination
• Protocole

Ensuite :

1. Démarrer Packet Capture.
2. Reproduire le test.
3. Arrêter Packet Capture.
4. Comparer les événements entrants et transférés.
5. Comparer la Rule ID et la NAT ID avec le Log Viewer.

Avant de démarrer, ouvrez Configure. Number of bytes to capture (per packet) limite le nombre d’octets enregistrés par paquet et Enter BPF string reçoit le filtre de capture précis. Le tampon fait 2048 KB. Sans Wrap capture buffer once full, la capture s’arrête automatiquement lorsqu’il est plein ; avec cette option, les données les plus anciennes sont écrasées. Pour un test reproductible, une capture courte sans écrasement est généralement plus facile à analyser.

Packet Capture ne montre pas seulement des paquets individuels sur une interface. Dans la sortie WebAdmin, des détails de traitement peuvent aussi apparaître selon le paquet, par exemple Firewall Rule ID, NAT ID, utilisateur, contexte de filtre Web ou Application, et si un paquet a été transféré, consommé, généré ou rejeté. C’est précisément ce qui rend Packet Capture si utile lorsqu’une règle ne semble pas s’appliquer : il relie mieux le flux de paquets et la vue policy qu’un simple outil de ping ou de test de port.

Interprétation :

• Aucun paquet n’arrive : vérifier client, VLAN, switch, gateway, fournisseur ou Cloud Security Group.
• Le paquet entre mais ne sort pas : vérifier règle de pare-feu, NAT, routage ou Security Feature.
• Le paquet sort, mais la réponse manque : vérifier route de retour, système cible, NAT ou pare-feu externe.
• Le paquet a le statut Violation : vérifier Policy, IPS, Webfilter ou Application Control.
• La NAT ID est inattendue : vérifier l’ordre NAT et les règles NAT génériques.

Pour en savoir plus : Utiliser l’outil Packet Capture dans WebAdmin. Si des paquets sont rejetés, Analyser les paquets rejetés par Sophos Firewall est également utile.

Lire ensemble Log Viewer et Packet Capture

Le Log Viewer montre la décision, Packet Capture montre le flux de paquets. En pratique, les deux points de vue sont souvent nécessaires.

• Log Viewer montre la Rule ID attendue, Packet Capture montre Forwarded : le test de règle est plausible pour le pare-feu. Le retour et le système cible restent à vérifier séparément.
• Log Viewer montre la Rule ID attendue, Packet Capture ne montre aucune réponse : vérifier système cible, route de retour, NAT ou pare-feu externe.
• Packet Capture montre Incoming, mais aucun log correspondant : vérifier journalisation, filtre de module, règle par défaut, Device Access ou analyse des drops.
• Packet Capture montre Consumed : le trafic se termine sur le pare-feu lui-même. Vérifier Device Access et Local Service ACL.
• Packet Capture montre Violation : comparer Reason, Rule ID, NAT ID et module de sécurité avec le Log Viewer.

Si les deux outils semblent contradictoires, le cas de test doit d’abord être resserré. Un seul client, une cible, un port et un court moment de test valent mieux qu’une capture large avec beaucoup de trafic de fond.

Cas particulier du trafic Web sur les ports 80 et 443

Un journal firewall indiquant Allowed ne prouve pas à lui seul que l’accès du navigateur a été autorisé. Lorsqu’une règle firewall avec l’Action Drop correspond au trafic sur le port 80 ou 443, le firewall peut transmettre le paquet entrant au Web Proxy. Le module Firewall indique alors Allowed, tandis que Web filter enregistre Blocked et renvoie une page de blocage. Avec Reject, le journal firewall reste Rejected.

Pour HTTP et HTTPS, vérifiez donc au minimum les modules Firewall et Web filter au même moment. Sophos précise aussi que les Web Exceptions peuvent s’appliquer malgré l’Action Drop. Si l’accès fonctionne contre toute attente, contrôlez les entrées correspondantes sous Web > Exceptions au lieu de considérer la Rule ID comme une preuve suffisante.

Utiliser des filtres de Packet Capture étroits

Packet Capture n’est utile que si le filtre est suffisamment étroit. Une capture trop large montre rapidement trop de trafic de fond, surtout sur les pare-feu en production avec du trafic Web, DNS, VPN ou serveur. Le filtre doit donc être dérivé du cas de test défini.

Exemples pratiques de BPF :

• Client unique vers une cible : host 172.16.10.25 and host 203.0.113.10, si la source et la destination sont connues.
• Client vers une cible HTTPS : host 172.16.10.25 and port 443, si la cible peut changer via DNS ou CDN.
• Trafic sortant uniquement d’un client : src host 172.16.10.25, si l’on vérifie d’abord si le client envoie réellement.
• Trafic de réponse uniquement vers le client : dst host 172.16.10.25, si la route de retour ou les paquets de réponse manquent.
• Test DNS : host 172.16.10.25 and port 53, si la résolution de noms et le test de règle doivent être vérifiés séparément.
• Test ICMP : icmp and host 172.16.10.25, si un ping sert de test simple de disponibilité.

Pour les tests DNAT ou VPN, faites particulièrement attention à la direction du regard. Un filtre sur l’IP du serveur interne ne montre pas nécessairement l’accès initial à l’IP publique. Inversement, un filtre sur l’IP publique ne montre pas automatiquement si le trafic arrive après NAT sur le serveur interne. Dans de tels cas, deux captures courtes sont souvent plus propres : d’abord sur le côté public, puis sur la cible interne.

Après le test, arrêtez immédiatement la capture. Les captures longues augmentent le risque de capturer des données inutiles, des noms d’hôtes internes ou des connexions étrangères.

Quand passer à tcpdump

Le Packet Capture de WebAdmin est idéal pour des tests rapides. Mais il ne suffit pas pour tous les cas. Passez à tcpdump si l’un de ces points s’applique :

• La capture doit être analysée en tant que fichier PCAP dans Wireshark ou par le support.
• Le test dure plus longtemps qu’un court test de reproduction manuel.
• Des filtres BPF très précis sont nécessaires, par exemple pour VoIP, VPN, DNS ou plusieurs hôtes.
• Le tampon WebAdmin est plein ou ne montre qu’un extrait.
• Le trafic pertinent doit être observé sur une interface spécifique sur une période prolongée.

Avec tcpdump, il est également important de : définir des filtres étroits, noter le temps de test, garder la capture courte et supprimer le fichier après le transfert. Le guide pratique CLI est disponible dans Sophos Firewall tcpdump : Capturer des paquets via CLI.

Étape 6 : Valider individuellement les fonctionnalités de sécurité

Si la bonne règle correspond, mais que le trafic ne fonctionne pas, les fonctionnalités activées doivent être vérifiées individuellement.

• Web policy : vérifier catégorie, utilisateur, schedule et ordre des policies.
• Scan HTTP and decrypted HTTPS : HTTPS n’est scanné que s’il est déjà decrypted.
• SSL/TLS inspection : vérifier règle appropriée, Decryption Profile et certificat CA sur les clients.
• IPS : vérifier signature, policy et possibles False Positives.
• Application Control : vérifier application reconnue, catégorie et détection Cloud App.
• Security Heartbeat : vérifier si l’Endpoint envoie le Heartbeat et si le statut est vert, jaune ou rouge.
• Traffic Shaping : vérifier si la policy est active et correspond à la bonne application ou règle.
• NAT : vérifier la bonne règle SNAT, DNAT ou PAT et l’ordre des règles.

Pour HTTPS : une règle de pare-feu avec filtrage Web ne suffit pas pour examiner le contenu HTTPS. Il faut également une règle d’inspection SSL/TLS appropriée avec déchiffrement et certificat CA distribué.

Pour en savoir plus : Déployer progressivement l’inspection TLS sur Sophos Firewall. Pour les erreurs NAT, Comprendre le NAT sur Sophos Firewall est approprié, car une règle NAT ne permet pas le trafic, elle ne fait que traduire les adresses ou les ports.

Étape 7 : Vérifier les fichiers de log

Si les outils WebAdmin ne suffisent pas, les fichiers de log appropriés doivent être vérifiés.

Fichiers typiques :

• Règle de pare-feu : firewall_rule.log
• NAT : nat_rule.log
• Connexions de pare-feu : fwlog.log
• IPS et DPI : ips.log
• Web Proxy : awarrenhttp.log
• IPsec : strongswan.log, charon.log
• SSL VPN : sslvpn.log
• DNS : dnsd.log, dnsgrabber.log
• DHCP : dhcpd.log

Le fichier journal qui correspond à chaque module est résumé dans Associer correctement les service logs Sophos Firewall.

Dans les cas de support, une archive de logs ou un CTR n’est vraiment utile que si l’heure de test et les IDs attendues sont documentées. Un gros paquet de logs sans source, destination, port, utilisateur, Rule ID et NAT ID entraîne souvent seulement des questions supplémentaires.

Annuler les modifications en toute sécurité

Effectuez le premier passage sans modifier de politique. Si vous devez ensuite changer la position d’une règle, un filtre ou une règle de test temporaire, notez d’abord la valeur d’origine et ne changez qu’un élément par passage. Après le test, rétablissez la valeur ou la position initiale et répétez le même test client. Log Viewer doit de nouveau afficher la Rule ID et l’Action initiales ; désactivez ou supprimez ensuite toute règle de test temporaire. Arrêtez Packet Capture et effacez son affichage afin de ne pas conserver inutilement des données de paquets dans le tampon.

Exemple : Tester une règle Web de LAN à WAN

1. Créer la règle de pare-feu LAN_to_WAN_Clients.
2. Activer la journalisation.
3. Définir les services sur HTTP et HTTPS.
4. Sélectionner la politique Web.
5. Laisser activé Block QUIC protocol.
6. Activer Scan HTTP and decrypted HTTPS.
7. Créer une règle d’inspection SSL/TLS pour le groupe de test.
8. Installer le certificat CA sur le client de test.
9. Sélectionner Reset data transfer count.
10. Ouvrir un site Web.
11. Filtrer le Log Viewer par IP source.
12. Exécuter le Policy tester pour la même URL.
13. En cas de divergence, démarrer Packet Capture.

Cela permet de voir si la règle correspond, si HTTPS est vraiment déchiffré et si le filtrage Web, l’IPS ou l’Application Control interviennent.

Documenter le résultat du test

Après un test de règle, le résultat doit être brièvement documenté. C’est particulièrement important si un cas de support, une fenêtre de maintenance ou un nettoyage ultérieur des règles en découle.

Il est utile de noter :

• Date et heure du test
• IP source, utilisateur, destination, service et URL ou application testée
• destinations de journalisation activées, par exemple Log Viewer, Sophos Fusion ou Syslog
• Rule ID attendue et réellement correspondante
• NAT Rule ID, si le NAT est impliqué
• Action dans le Log Viewer
• Capture d’écran ou exportation de Packet Capture, si le flux de paquets était pertinent
• Règle modifiée, politique Web, règle d’inspection SSL/TLS ou règle NAT
• Point ouvert, si le comportement n’est pas encore entièrement expliqué

Pour les modifications productives, notez également si la règle est destinée à un pilote, permanente ou comme solution temporaire. Les règles de test temporaires devraient avoir une date d’expiration ou un propriétaire clair pour éviter qu’elles ne deviennent des reliques dans le jeu de règles.

Si le test de règle débouche sur un cas de support, il faut aussi documenter l’archive de logs, Packet Capture ou PCAP tcpdump, la période concernée et les causes déjà exclues. Pour cette partie, consultez Sauvegarder les logs de Sophos Firewall pour le support et l’analyse.

FAQ