La règle Sophos Firewall ne s'applique pas : Vérifier les causes

Lorsqu’une règle de pare-feu ne s’applique pas, il est rare que le pare-feu soit “défectueux”. Souvent, une condition ne correspond pas, une règle plus générale est placée au-dessus, le NAT modifie la vue du trafic, le matching utilisateur n’est pas respecté ou la journalisation n’est pas correctement activée.

Cette liste de contrôle aide à procéder de manière systématique, plutôt que de modifier les règles au hasard.

Orientation

Commencer par un cas de test clair avant de modifier des règles ou des fonctions de sécurité.

Quel article convient ?

Les problèmes de règles se chevauchent rapidement avec le NAT, le routage, le VPN, l’accès aux appareils ou les fonctionnalités de sécurité. Pour l’analyse, il est d’abord important de savoir quel niveau est concerné :

• Comprendre une règle de pare-feu de fond en comble: Comprendre et configurer correctement les règles Sophos Firewall
• Tester une connexion individuelle avec Log Viewer, Policy Tester et Packet Capture: Tester une règle de pare-feu avec Log Viewer, Policy Test et Packet Capture
• NAT, SNAT, DNAT, MASQ ou PAT est impliqué: Comprendre le NAT sur Sophos Firewall
• Un serveur est publié depuis Internet via DNAT: Publier un serveur via DNAT
• L’accès concerne WebAdmin, VPN Portal, SSH, DNS ou SNMP du pare-feu: Configurer correctement l’accès aux appareils
• Route, SD-WAN ou retour est incertain: Adapter la priorité de routage sur Sophos Firewall
• Les paquets doivent être vérifiés directement sur le pare-feu: Utiliser Packet Capture dans WebAdmin

Cette distinction est importante car une règle de pare-feu ne contrôle pas tous les types d’accès. Les services locaux du pare-feu, les décisions NAT, le routage et les fonctionnalités de sécurité ont leurs propres points de vérification.

Délimitation rapide

Au début, il ne faut pas immédiatement déplacer les règles ou modifier les objets. Il faut d’abord déterminer où le trafic est perdu.

• Le compteur de règles reste à 0: La position de la règle, la zone, la source, la destination, le service ou le planning ne correspond pas
• Log Viewer montre une autre règle: Une règle plus générale ou générée automatiquement est placée plus haut
• Log Viewer ne montre rien: La journalisation manque ou le trafic n’atteint pas le pare-feu
• Packet Capture ne voit aucun paquet: Le problème se situe avant le pare-feu : client, VLAN, switch, passerelle, fournisseur ou groupe de sécurité cloud
• Packet Capture voit des paquets, mais pas de transfert: La règle de pare-feu, le NAT, le routage ou une fonctionnalité de sécurité bloque
• Packet Capture voit le transfert, mais pas de réponse: Vérifiez la route de retour, le système cible, le NAT ou un pare-feu externe

Cette distinction permet de gagner du temps. Si le pare-feu ne voit aucun paquet, aucune modification d’une règle de pare-feu n’aidera. Si le Log Viewer montre une autre ID de règle, l’ordre est plus important que la règle cible concernée. Si le flux de paquets et l’ID de règle sont corrects, l’analyse se déplace vers le NAT, le retour ou les fonctionnalités de sécurité.

Définir clairement le cas de test

Une règle ne peut être testée de manière significative que si le cas de test est clair. Des déclarations comme “Internet ne fonctionne pas” ou “VPN ne fonctionne pas” sont trop larges. Pour le dépannage, un flux concret est nécessaire.

Avant le test, il faut déterminer :

• IP source: Client 10.10.20.35
• Zone source: LAN, VPN, DMZ ou zone personnalisée
• Utilisateur: utilisateur authentifié ou pas de matching utilisateur
• Destination: IP du serveur, FQDN, IP publique ou objet WAN
• Service: TCP 443, UDP 53, ICMP, service personnalisé
• Règle attendue: Nom de la règle ou ID de la règle, si connu
• Règle NAT attendue: ID de la règle NAT ou nom de la règle, si le NAT est impliqué
• Heure du test: heure exacte pour Log Viewer et fichiers journaux ultérieurs

Ensuite, le même test est toujours répété. Si pendant l’analyse l’IP source, la destination, la résolution DNS ou le port changent, on ne compare plus le même cas.

Combiner correctement les outils d’analyse

Sophos Firewall propose plusieurs outils qui répondent à différentes questions. Aucun d’entre eux n’est à lui seul une preuve complète.

• Compteur de règles: Le nouveau trafic de test atteint-il fondamentalement la règle ? Ne montre pas pourquoi une application échoue quand même
• Log Viewer: Quelle ID de règle, ID de règle NAT, action, utilisateur ou fonction de sécurité a été enregistrée ? Dépend de la journalisation et de la fin de session
• Policy Tester: Quelle logique de politique s’appliquerait à un flux défini ? Ne remplace pas un vrai flux de paquets et ne représente pas complètement le SD-WAN
• Packet Capture: Les paquets arrivent-ils, sont-ils transférés ou rejetés ? N’explique pas chaque couche d’application et nécessite des filtres étroits
• Journaux de service: Un module comme Web, IPS, authentification ou VPN a-t-il un problème propre ? Utile seulement lorsque le service concerné est délimité

Pour un diagnostic fiable, combinez au moins Log Viewer et un vrai test. En cas de résultats contradictoires, Packet Capture est généralement l’étape suivante, car il montre si les paquets arrivent réellement et continuent.

Arbre de décision pour le premier test

Pour la première analyse, un court arbre de décision suffit souvent. Il empêche de travailler immédiatement sur les règles, le NAT et le routage en même temps.

• Packet Capture ne voit aucun paquet: Vérifiez le client, le VLAN, le switch, la passerelle, le fournisseur, le groupe de sécurité cloud ou le pare-feu en amont
• Packet Capture voit le paquet, Log Viewer reste vide: Vérifiez la journalisation, le type de journal, la fin de session et le filtre BPF approprié
• Log Viewer montre une autre ID de règle: Comparez l’ordre des règles, les zones, la source, la destination, le service et le planning
• L’ID de règle de pare-feu est correcte, l’ID de règle NAT ne l’est pas: Vérifiez l’ordre du NAT et les champs Original
• L’ID de règle et l’ID NAT sont correctes, mais aucune réponse ne revient: Vérifiez la route de retour, le système cible, le pare-feu local sur le serveur ou un blocage externe
• La règle ne correspond qu’à certains utilisateurs: Vérifiez le matching utilisateur, le groupe, l’authentification et les utilisateurs sans client

Cela permet de garder l’analyse sous contrôle : d’abord, il est prouvé que le trafic atteint le pare-feu. Ensuite, il est vérifié quelle règle et quelle règle NAT s’appliquent réellement. Ce n’est que lorsque ces deux points sont corrects qu’il vaut la peine de chercher dans le retour, les fonctionnalités de sécurité ou la couche d’application.

Comprendre le matching des règles

Sophos Firewall traite les règles dans l’ordre. La première règle adaptée gagne.

Premier principe : La première règle correspondante gagne

Sophos Firewall traite les règles de pare-feu de haut en bas. Dès qu’une règle correspond, les règles suivantes ne sont plus vérifiées. Le même principe de base s’applique également aux règles NAT.

Important :

• La position dans la liste détermine l’évaluation.
• L’ID de règle n’est qu’une référence et ne dit rien sur l’ordre actuel.
• Les groupes de règles aident à la vue d’ensemble, mais ne sont pas une logique de correspondance propre.
• Une règle générale au-dessus peut complètement “engloutir” une règle spécifique en dessous.

Si une règle ne s’applique pas, vérifiez d’abord la position.

Réinitialiser le compteur de règles

En cas de correspondances peu claires, il est utile de réinitialiser le compteur de règles.

1. Ouvrez Rules and policies > Firewall rules.
2. Recherchez la règle concernée.
3. Ouvrez le menu à trois points.
4. Sélectionnez Reset data transfer count.
5. Reproduisez à nouveau le trafic.
6. Vérifiez le compteur après le test.

Si le compteur n’augmente pas, la règle ne correspond pas. S’il augmente, mais que l’application ne fonctionne toujours pas, le problème se situe plutôt au niveau des profils de sécurité, du NAT, du routage, du retour ou du système cible.

Vérifier les champs de correspondance

Une règle de pare-feu ne correspond que si tous les critères pertinents sont corrects.

• Zones source: Mauvaise zone, VLAN dans une autre zone, trafic VPN provenant de VPN
• Réseaux et appareils source: Mauvais objet, mauvaise IP, groupe d’hôtes incomplet
• Zones de destination: Mauvaise zone de destination, surtout avec DNAT ou VPN
• Réseaux de destination: Confusion entre la vue avant NAT et après NAT
• Services: Port manquant, confusion TCP/UDP, application utilisant des ports supplémentaires
• Utilisateurs ou groupes: Utilisateur non authentifié ou mauvais groupe
• Planning: Le planning ne correspond pas actuellement
• Exclusions: Le trafic est exclu de la règle et traité plus bas

Pour le trafic Web, il faut également vérifier si QUIC est actif. Si les navigateurs envoient du trafic via UDP 443, certaines attentes de filtrage Web et de scan fonctionnent différemment que pour le HTTPS classique via TCP.

En savoir plus : Sophos Firewall et le protocole QUIC.

Ne pas négliger DNS, FQDN et IPv6

Une règle peut sembler correcte et pourtant ne pas correspondre si le client atteint une autre cible que prévu. Cela se produit souvent avec les objets FQDN, le DNS fractionné, les services CDN, IPv6 ou les applications utilisant plusieurs cibles en parallèle.

Avant de modifier les règles, il faut donc vérifier :

• Quelle IP le client résout-il réellement ?: Le cache DNS, le DNS fractionné ou un autre résolveur peuvent fournir une adresse différente de celle attendue.
• Est-ce IPv4 ou IPv6 ?: Les règles IPv4 ne correspondent pas au trafic IPv6. Si les clients préfèrent IPv6, la partie IPv6 doit être vérifiée séparément.
• Un hôte FQDN est-il utilisé dans le pare-feu ?: Le pare-feu doit résoudre le FQDN et connaître l’IP cible actuelle. Les services CDN ou cloud peuvent fournir plusieurs IP changeantes.
• L’application utilise-t-elle des cibles supplémentaires ?: Les connexions, API, mises à jour, télémétrie ou chemins multimédias peuvent utiliser d’autres domaines et ports que l’application principale.
• Un client interne utilise-t-il le nom public d’un service interne ?: Dans ce cas, le DNS fractionné, le NAT Loopback ou une résolution publique incorrecte sont des causes possibles.

Pour le dépannage, il est essentiel de noter non seulement le nom d’hôte, mais de comparer l’IP cible réellement utilisée dans le Log Viewer ou Packet Capture. Si une règle pointe vers un objet FQDN ou hôte spécifique, mais que le client utilise une autre IP, la règle ne correspondra pas.

Pour les résolutions de noms internes, des routes de requêtes DNS propres aident. Le processus est décrit dans Configurer les routes de requêtes DNS sur Sophos Firewall. Si IPv6 est actif dans l’environnement, il faut également vérifier si IPv6 est planifié consciemment et si la politique appropriée est en place. Les bases sont expliquées dans Configurer la délégation de préfixe IPv6 sur Sophos Firewall.

Un cas particulier fréquent concerne les objets FQDN. Si les clients privilégient IPv6, mais qu’une règle utilise uniquement des objets IPv4 ou un hôte FQDN résolu en IPv4, le flux IPv6 réel ne correspond pas. La règle semble alors correcte sur le plan technique, mais elle ne traite pas le trafic réellement présent sur le réseau. Dans ces cas, il faut vérifier séparément la réponse DNS, la version IP et la policy.

Le trafic vers le pare-feu lui-même est un cas particulier

Tous les accès à un Sophos Firewall ne sont pas contrôlés par des règles de pare-feu normales. Si le client doit atteindre le pare-feu lui-même, par exemple WebAdmin, User Portal, VPN Portal, SSH, IPsec, SSL VPN, DNS ou SNMP, Device Access et Local service ACL sont décisifs.

Exemples typiques :

• WebAdmin depuis LAN ou WAN: Device Access, Local service ACL, MFA, autorisation admin
• VPN Portal ou User Portal: Device Access, configuration du portail, autorisation utilisateur
• SSH sur le pare-feu: Device Access, Local service ACL, droits admin, réseau source
• Connexion SSL VPN ou IPsec: Device Access pour la zone appropriée, configuration VPN, authentification
• DNS vers le pare-feu: Device Access, configuration DNS, chemin de requête
• SNMP vers le pare-feu: Device Access, configuration SNMP, source de surveillance

Si une règle de pare-feu ne s’applique pas à ce type de trafic, ce n’est souvent pas une erreur de la règle. Le trafic se termine sur le pare-feu et est traité comme un service local. Pour le renforcement de ces services, Sécuriser l’accès à Sophos Firewall : Configurer correctement Device Access est l’article central. Pour les portails, Vue d’ensemble des portails Sophos est également pertinent.

Vérifier NAT, DNAT et les ID

Pour le trafic DNAT, les règles de pare-feu et les règles NAT doivent être lues ensemble.

Lire correctement le DNAT

Avec le DNAT, la vue dans les règles de pare-feu est particulièrement importante. En règle générale, on peut se souvenir :

Les règles de pare-feu pour le trafic DNAT utilisent la zone de destination après NAT, mais l’IP de destination avant NAT.

Exemple :

• Un client externe se connecte à l’IP WAN du pare-feu.
• Le NAT traduit vers un serveur interne dans la DMZ.
• La règle de pare-feu utilise comme zone de destination la zone du serveur interne, par exemple DMZ.
• Le réseau de destination reste cependant l’IP publique ou l’objet WAN que le client a contacté.

Si cette combinaison est incorrecte, la règle NAT peut sembler correcte, mais la règle de pare-feu ne correspondra pas.

En savoir plus : Publier un serveur via DNAT sur Sophos Firewall.

Vérifier les règles NAT

Le NAT ne permet pas le trafic. Le NAT ne fait que traduire. Il faut toujours une règle de pare-feu appropriée en plus.

Sous Rules and policies > NAT rules, vous devez vérifier :

• La règle NAT appropriée est-elle placée au-dessus des règles NAT plus générales ?
• La règle est-elle active ?
• Les sources, destinations et services originaux sont-ils corrects ?
• Les sources, destinations et services traduits sont-ils corrects ?
• MASQ ou une IP SNAT fixe est-elle utilisée ?
• Existe-t-il une règle NAT liée qui s’applique de manière inattendue ?
• Existe-t-il une règle SNAT générique qui correspond avant une règle plus spécifique ?

Sophos recommande pour les environnements simples des règles NAT autonomes, plutôt que de créer une règle NAT liée par règle de pare-feu.

En savoir plus : Comprendre le NAT sur Sophos Firewall : SNAT, DNAT, MASQ, PAT.

Lire ensemble l’ID de règle de pare-feu et l’ID de règle NAT

Si le NAT est impliqué, la question “Quelle règle de pare-feu s’applique ?” ne suffit pas. Une connexion peut atteindre l’ID de règle de pare-feu attendue, mais passer quand même par une mauvaise ID de règle NAT. Inversement, une règle NAT peut sembler correcte, tandis qu’une règle de pare-feu plus générale au-dessus traite déjà le trafic.

Pour le test, il faut donc noter à l’avance :

• ID de règle de pare-feu attendue: Indique si la bonne règle de pare-feu autorise ou bloque le trafic
• ID de règle NAT attendue: Indique si la bonne règle SNAT, DNAT, MASQ ou PAT traduit
• IDs réelles dans le Log Viewer: Prouve si le pare-feu traite le flux comme prévu
• IDs dans Packet Capture: Aide si le Log Viewer semble incomplet ou si le retour est incertain

L’interprétation est relativement simple, mais économise beaucoup de temps de recherche :

• L’ID de règle de pare-feu est correcte, l’ID de règle NAT est incorrecte: Vérifiez l’ordre du NAT, les champs Original et les règles NAT plus générales
• L’ID de règle NAT est correcte, l’ID de règle de pare-feu est incorrecte: Vérifiez l’ordre des règles de pare-feu, les zones, la source, la destination et le service
• Les deux IDs sont correctes, mais la connexion échoue quand même: Vérifiez le retour, le serveur cible, la fonctionnalité de sécurité ou l’application
• Aucune ID de règle NAT visible, bien que le NAT soit attendu: Vérifiez à nouveau le flux de test, les critères NAT, la direction et la journalisation

Il est important de ne pas immédiatement reconstruire les deux ensembles de règles en même temps. Décidez d’abord si le problème réside dans le matching de pare-feu ou dans le matching NAT. Ce n’est qu’ensuite que vous devez modifier une position de règle concrète, un objet ou un champ. L’évaluation NAT plus détaillée est dans la section Lire correctement l’ID de règle de pare-feu et l’ID de règle NAT.

Vérifier utilisateurs, routage et fonctions de sécurité

Le matching utilisateur, le routage, NAT, la journalisation et les profils de sécurité peuvent influencer l’application d’une règle.

Vérifier le matching utilisateur et l’authentification

Les règles avec matching utilisateur ou groupe semblent souvent correctes, mais ne s’appliquent que si le pare-feu peut réellement associer l’utilisateur au trafic à ce moment-là.

À vérifier :

• L’utilisateur est-il visible dans le Log Viewer ?
• Le trafic provient-il de l’appareil attendu ou d’un autre client ?
• L’utilisateur est-il dans le bon groupe de pare-feu ?
• AD SSO, STAS, Captive Portal, RADIUS ou Entra ID SSO fonctionnent-ils ?
• Une règle sans matching utilisateur s’applique-t-elle au-dessus de la règle utilisateur prévue ?
• Existe-t-il des utilisateurs sans client traités différemment ?
• MFA ou l’accès au portail réussit-il, mais la règle de pare-feu pour le trafic utilisateur est-elle incorrecte ?

Pour l’accès à distance, il faut séparer le problème utilisateur du problème VPN. Un utilisateur peut se connecter avec succès, mais ne pas atteindre une application interne si le pool VPN, la règle de pare-feu, le NAT ou le routage ne correspondent pas. Pour les bases AD, Ajouter Active Directory sur Sophos Firewall est pertinent, pour les scénarios d’accès à distance basés sur Entra Microsoft Entra ID SSO pour Sophos Connect et VPN Portal. Si l’utilisateur est connecté via Captive Portal avec Entra ID SSO, Configurer Microsoft Entra ID SSO pour Sophos Firewall Captive Portal est pertinent.

Séparer la connexion utilisateur et le matching de règle

Une connexion réussie au VPN Portal, User Portal, Captive Portal ou via Microsoft Entra ID SSO ne prouve pas encore que la règle utilisateur prévue correspond au trafic réel. La connexion confirme d’abord uniquement l’authentification. Ensuite, le pare-feu doit correctement associer l’utilisateur, l’IP source, le groupe et le flux de trafic.

Pour l’analyse, il faut donc vérifier séparément :

• L’utilisateur se connecte, le compteur de règles reste à 0: Vérifiez le pool VPN, la zone source, le réseau source, la condition de groupe ou la position de la règle
• Le champ utilisateur dans le Log Viewer est vide: Vérifiez STAS, Captive Portal, AD SSO, Entra ID SSO ou les utilisateurs sans client
• L’utilisateur est visible, mais une mauvaise règle s’applique: Vérifiez l’ordre des règles, le filtre de groupe ou une règle plus générale au-dessus
• Seuls les utilisateurs VPN sont concernés: Vérifiez la zone VPN, le pool VPN, la configuration SSL/IPsec et le profil Sophos Connect
• Seuls certains utilisateurs sont concernés: Comparez UPN, adresse e-mail, groupe importé et groupe de pare-feu

Dans les environnements AD locaux, STAS et Ajouter Active Directory sur Sophos Firewall sont utiles. Dans les configurations basées sur Entra, selon le chemin de connexion, Microsoft Entra ID SSO pour Sophos Connect et VPN Portal ou Entra ID SSO pour Captive Portal doivent être vérifiés. Si de nombreux utilisateurs ou utilisateurs sans client sont impliqués, la Limite d’ID utilisateur Sophos Firewall peut également être pertinente.

Vérifier le routage et le SD-WAN

Si la règle correspond, mais que la connexion ne fonctionne pas, le routage peut être le problème.

Il faut vérifier :

• Existe-t-il une route par défaut appropriée ?
• Existe-t-il une route statique ?
• Une route SD-WAN s’applique-t-elle ?
• La passerelle est-elle active ?
• Existe-t-il des routes de retour sur le système cible ou dans le réseau distant ?
• Le retour est-il symétrique ?
• Le trafic passe-t-il par VPN, MPLS ou une autre interface que prévu ?

Important : Le Policy Tester ne représente pas complètement le routage SD-WAN. Il est très utile pour les décisions de politique de pare-feu, SSL/TLS et Web, mais ne remplace pas un vrai test de flux de paquets.

En savoir plus : Adapter la priorité de routage sur Sophos Firewall.

Activer la journalisation

Sans journaux, le dépannage devient fastidieux. Il faut vérifier deux endroits :

1. Dans la règle de pare-feu, Log firewall traffic doit être activé.
2. Sous System services > Log settings, le type de journal approprié doit être activé localement, pour Sophos Central ou pour Syslog.

Le Log Viewer affiche généralement les sessions de pare-feu lorsque le pare-feu termine une connexion et reçoit un événement Destroy. Si une connexion Internet se coupe simplement, il se peut que toutes les sessions n’apparaissent pas comme prévu.

Le Log Viewer s’ouvre en haut à droite dans la console WebAdmin. Les filtres utiles sont :

• IP source
• IP de destination
• Port ou service
• ID de règle
• Nom de la règle
• Action
• Utilisateur
• ID de règle NAT

En savoir plus : Dépannage Sophos Firewall : Services et journaux.

Utiliser Packet Capture

Si Log Viewer et le compteur de règles ne suffisent pas, utilisez Diagnostics > Packet capture.

La question la plus importante est de savoir si le paquet arrive, est transféré ou reste bloqué sur le pare-feu.

• Aucun paquet n’arrive: Le problème se situe avant le pare-feu : client, switch, VLAN, passerelle, fournisseur, groupe de sécurité cloud
• Le paquet entre, mais ne sort pas: Vérifiez la règle de pare-feu, le NAT, le routage ou la fonctionnalité de sécurité
• Le paquet sort, mais aucune réponse ne revient: Vérifiez la route de retour, le système cible, le NAT ou un blocage externe
• Le paquet est affiché avec Violation: Une politique ou une fonctionnalité de sécurité bloque
• Le paquet montre l’ID NAT et l’ID de règle: Comparez spécifiquement les correspondances de règle et NAT

En savoir plus : Utiliser l’outil Packet Capture dans WebAdmin.

Ne pas modifier plusieurs choses à la fois

En cas de problèmes de règles, il est tentant d’ajuster simultanément la position, le service, le NAT, la politique Web et le routage. Cela résout parfois l’accès à court terme, mais rend la cause difficile à comprendre plus tard.

Il est préférable de procéder étape par étape :

1. Notez l’état initial : ID de règle, ID NAT, source, destination, service, heure.
2. Effectuez exactement un changement.
3. Répétez le test avec la même IP source et la même destination.
4. Comparez à nouveau Log Viewer et Packet Capture.
5. Documentez le résultat.
6. Ce n’est qu’après que vous devez vérifier le prochain changement.

Pour les règles productives, il doit également être clair si un changement est permanent ou s’il s’agit uniquement d’une règle de test. Les règles temporaires doivent avoir un propriétaire et une date d’expiration, sinon elles restent souvent dans le jeu de règles pendant des années.

Vérifier les fonctionnalités de sécurité individuellement

Si la règle correspond, mais que l’application ne fonctionne pas, un profil de protection peut intervenir :

• Politique Web
• Règle d’inspection SSL/TLS
• Profil de déchiffrement
• Politique IPS
• Contrôle des applications
• Scan des malwares
• Protection contre les menaces zero-day
• Security Heartbeat
• Shaping du trafic

Pour les tests, vous ne pouvez pas désactiver tout de manière générale et permanente. Il est préférable de vérifier brièvement et spécifiquement, d’observer le Log Viewer et ensuite de résoudre proprement la cause. Pour l’inspection TLS, l’article Déployer progressivement l’inspection TLS sur Sophos Firewall est utile.

Pour les règles productives, il ne faut pas considérer les fonctionnalités de sécurité comme un bloc unique. Il est préférable de délimiter un module après l’autre :

• Catégorie Web ou URL bloquée: Vérifiez la politique Web, la catégorie, l’exception et le Log Viewer
• Application mal reconnue: Vérifiez le contrôle des applications et le journal IPS
• Page HTTPS ne charge que sans inspection: Vérifiez la règle d’inspection SSL/TLS, la distribution CA, le profil de déchiffrement et les exceptions
• Connexion interrompue pour les grandes données: Vérifiez MTU/MSS, chemin VPN, fragmentation et Packet Capture
• Correspondance dans IPS ou Protection contre les menaces zero-day: Évaluez la signature, la politique, le système cible et le risque de faux positif
• Seuls certains utilisateurs sont concernés: Vérifiez le matching utilisateur, Security Heartbeat, le groupe et l’authentification

Si un profil de protection est supprimé pour un test, le changement doit être strictement limité : uniquement la source concernée, uniquement la cible concrète, uniquement pour la période de test. Ensuite, la protection d’origine doit être rétablie ou une exception ciblée documentée.

Vérifier l’historique des modifications

Une règle peut aussi ne plus correspondre parce que quelque chose a changé en arrière-plan. Ce n’est pas forcément la règle elle-même.

• La règle fonctionnait auparavant: Vérifier Audit logs et dernier changement
• Objets modifiés: Comparer hosts, services, zones, groupes et FQDN
• Changement via Sophos Central: Vérifier Task Queue et statut du déploiement
• Plusieurs administrateurs travaillent en parallèle: Clarifier le propriétaire, le ticket et l’heure du changement
• Le problème apparaît après une restauration ou un import: Comparer configuration, interfaces, zones et NAT

Pour le suivi des changements, vérifier les Audit Trail Logs de Sophos Firewall et utiliser Sophos Firewall Config Studio sont utiles. Si le changement vient de Sophos Central, il faut aussi vérifier la Sophos Central Firewall Management Task Queue.

Procédure pratique et causes typiques

La plupart des problèmes de matching se réduisent rapidement avec une séquence de dépannage fixe.

Causes fréquentes

• Le compteur de règles reste à 0: Mauvaise position de la règle, zone source, zone de destination ou service
• Le journal montre une autre règle: Une règle plus générale est placée au-dessus
• Aucun journal visible: La journalisation n’est pas activée ou le trafic n’atteint pas le pare-feu
• DNS fonctionne, Web non: Vérifiez le service, la politique Web, l’inspection TLS ou QUIC
• Le nom d’hôte correspond, mais l’IP cible est différente: Vérifiez DNS, objet FQDN, DNS fractionné, CDN ou IPv6
• HTTPS n’est pas scanné: Aucune règle d’inspection SSL/TLS appropriée ou CA non distribuée
• DNAT ne fonctionne pas: La règle de pare-feu utilise la mauvaise zone de destination ou le mauvais réseau de destination
• Le trafic VPN ne correspond pas: Vérifiez la zone VPN, la route, l’interface de tunnel ou le contexte XFRM
• Seuls certains utilisateurs sont concernés: Vérifiez le matching utilisateur, le groupe, SSO, Captive Portal ou Heartbeat

Processus pratique

1. Notez le problème avec l’IP source, la destination, le port, l’utilisateur et l’heure.
2. Vérifiez la position de la règle.
3. Réinitialisez le compteur de règles.
4. Reproduisez le test.
5. Filtrez Log Viewer avec l’IP source et l’IP de destination.
6. Vérifiez la règle NAT et le routage.
7. Démarrez Packet Capture avec un filtre étroit.
8. Vérifiez les profils de sécurité uniquement de manière ciblée.
9. Documentez le changement.

Pour un processus de test combiné, voir Tester une règle de pare-feu avec Log Viewer, Policy Test et Packet Capture.

Liste de contrôle pour le dépannage des règles

• Cas de test concret défini avec source, destination, service, utilisateur et heure.
• Position de la règle vérifiée et compteur de règles réinitialisé pour le test.
• Log Viewer montre l’ID de règle attendue ou une autre règle compréhensible.
• La résolution DNS, l’IP cible réelle et la version IP ont été comparées avec le cas de test.
• Pour DNAT, la zone de destination après NAT et le réseau de destination avant NAT sont correctement définis.
• L’ID de règle NAT a été vérifiée si le NAT est impliqué.
• Le trafic vers le pare-feu lui-même a été séparé du trafic à travers le pare-feu.
• Le matching utilisateur a été évalué uniquement si l’utilisateur est visible dans le Log Viewer.
• Pour les règles utilisateur, la connexion, l’association utilisateur et la décision de règle réelle ont été évaluées séparément.
• Le routage, le SD-WAN, la passerelle et le retour ont été vérifiés.
• Packet Capture montre Incoming, Forwarded, Violation ou une réponse manquante de manière compréhensible.
• Les fonctionnalités de sécurité ont été vérifiées individuellement et non désactivées de manière générale et permanente.
• Les modifications de test sont documentées et les règles temporaires ont un propriétaire et une date d’expiration.

FAQ