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

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 :

• 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.
• 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. Vérifier la position de la règle et le compteur d’utilisation.
4. Reproduire le test exactement une fois.
5. Filtrer le Log Viewer par IP source, IP de destination et service.
6. Noter la Rule ID et la NAT ID à partir de l’entrée de log réelle.
7. Utiliser le Policy tester uniquement pour la logique de politique.
8. Démarrer Packet Capture si le Log Viewer et le Policy tester ne correspondent pas.
9. 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.

É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 ?

Si vous testez une nouvelle règle, réinitialisez le compteur d’utilisation de la règle. Cela permet de mieux voir si la règle a vraiment été touchée lors du test.

Étape 2 : Ouvrir le Log Viewer

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

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.

É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 règles 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 ?

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.

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.

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.

SFOS 22 : Le Policy tester peut afficher des résultats incorrects

Avec SFOS 22.0 GA et SFOS 22.0 MR1, les résultats des tests de politique doivent être évalués avec prudence. Policy Test et Policy Route Test peuvent afficher le trafic comme bloqué ou l’attribuer à une règle incorrecte dans certains cas, même si le trafic productif passe correctement à travers le pare-feu.

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 règles 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
• 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.

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.

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.

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. Réinitialiser le compteur de règles.
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
• 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