Analyser les paquets rejetés par Sophos Firewall

Un paquet rejeté n’est pas automatiquement le signe d’une erreur. Le pare-feu peut bloquer le trafic comme prévu, rejeter de manière inattendue un trafic légitime ou ne pas voir le flux du tout. La procédure suivante permet de déterminer rapidement si la règle, NAT, le chemin de retour, un module de sécurité ou un système situé en amont du pare-feu est responsable.

Délimiter les rejets en quelques minutes

1. Consigner le cas de test : Noter l’IP source, l’IP de destination, le port, le protocole, l’heure et la direction attendue. Pour une erreur sporadique, noter également l’utilisateur, l’application et la dernière modification de configuration.
2. Filtrer Log Viewer : Dans le module Firewall, rechercher l’adresse IP, le port et l’heure. Selon le cas, ouvrir également Web, SSL/TLS inspection, Application filter, IPS, Active threat response, Web server protection ou VPN.
3. Démarrer Packet Capture : Sous Diagnostics > Packet capture, définir un filtre précis, activer la capture et effectuer exactement un test reproductible.
4. Lire le statut du paquet : Incoming, Forwarded, Consumed, Generated ou Violation indique si le paquet arrive, est transféré, est traité localement, est généré par le pare-feu ou est rejeté.
5. Attribuer la décision : Comparer Rule ID, NAT ID et Reason avec les règles de pare-feu et NAT attendues. Pour un résultat Web, IPS ou Application, vérifier également l’ID de la politique concernée.
6. Capturer le retour : Si le trajet aller est transféré, mais qu’aucune réponse n’est visible, vérifier la route de retour, le système cible, NAT, SD-WAN et le routage asymétrique.
7. Modifier seulement ensuite : Ne pas créer de règle Allow large ou d’exception globale avant d’avoir identifié le module responsable et la cause réelle.

Pour le matching général des règles et Policy Tester, consultez le guide détaillé Tester une règle Sophos Firewall avec Log Viewer et Packet Capture.

Lire ensemble Log Viewer et Packet Capture

Log Viewer et Invalid traffic

Le Log Viewer s’ouvre en haut à droite de WebAdmin. Il affiche non seulement les décisions du pare-feu, mais aussi les événements des modules de sécurité concernés. Pour un trafic Web Proxy, le module Firewall peut par exemple indiquer Allowed tandis que le module Web signale simultanément Blocked : la règle de pare-feu autorise la connexion au proxy, alors que la Web Policy bloque le contenu. Il faut donc toujours corréler les modules pour le même moment de test. Les filtres, Detailed view, le moment de la session et Log occurrence sont expliqués dans Utiliser correctement le Log Viewer de Sophos Firewall.

Deux conditions doivent être vérifiées séparément pour le trafic du pare-feu :

• Log firewall traffic est activé dans la règle concernée. Les règles SSL/TLS disposent de leur propre option Log connections.
• Sous System services > Log settings, la destination de sortie nécessaire est activée pour Log Viewer sous Local reporting, Sophos Central ou Syslog.

Les sessions du pare-feu apparaissent généralement lorsque celui-ci reçoit un événement Destroy lors de la fermeture de la connexion. Si une connexion se termine sans cet événement, l’entrée attendue peut manquer. Pour une conservation plus longue, utilisez Central Firewall Reporting ou Syslog vers un SIEM.

Invalid traffic signifie que Conntrack ne peut pas associer un paquet à une connexion actuelle. Une session expirée ou des paquets TCP RST et FIN supplémentaires peuvent générer de tels événements sans qu’il s’agisse automatiquement d’une erreur. Si des problèmes de connexion surviennent en même temps, capturer les deux directions et vérifier les causes possibles, comme une route de retour manquante, un chemin asymétrique ou un changement de rôle HA. Un délai Conntrack plus long peut seulement réduire le nombre d’entrées de journal ; il ne corrige pas la cause.

Si le motif exact du rejet est Invalid TCP reserved bit, Accurate ECN peut être en cause plutôt qu’une règle de pare-feu. L’article Résoudre Invalid TCP reserved bit causé par Accurate ECN explique comment le confirmer et évaluer l’impact du contournement CLI global sur la sécurité.

Status, Rule ID, NAT ID et Reason

Packet Capture affiche les paquets qui passent par une interface et ajoute les informations de traitement du pare-feu, de NAT et des modules de sécurité. La documentation actuelle de SFOS 22 définit les statuts suivants :

• Incoming : Le paquet arrive sur une interface. Cela ne prouve pas encore qu’il est transféré.
• Forwarded : Le pare-feu transfère le paquet vers une interface de sortie. Si la réponse manque, il faut ensuite se concentrer sur le système cible et le chemin de retour.
• Consumed : Le paquet est destiné au pare-feu lui-même, par exemple à WebAdmin, SSH, DNS ou un portail VPN.
• Generated : Le pare-feu génère lui-même le paquet, par exemple comme réponse ou trafic système.
• Violation : Une violation de politique provoque le rejet. Rule ID, Reason et le module responsable indiquent le prochain point à vérifier.

Les champs Rule ID, NAT ID, Reason, Connection ID, Web filter ID, Application ID, IPS policy ID et Username sont également importants. Une valeur inattendue peut signifier qu’une règle plus générale placée plus haut s’applique, que NAT modifie les adresses visibles ou que l’utilisateur n’a pas été identifié.

Reason est une indication, pas un rapport complet sur la cause racine. Selon la version, des valeurs comme Firewall, LOCAL_ACL, INVALID_TRAFFIC, APPLICATION_FILTER, IPS, USER_IDENTITY, IP_SPOOF, SSL_VPN_ACL_VIOLATION ou VIRTUAL_HOST peuvent mener au module responsable. Lire d’abord le statut et les ID, puis ouvrir la section correspondante dans Log Viewer. Sophos Firewall Packet Capture explique l’utilisation et le filtrage.

Firewall ID 0 et journaux de rejet manquants

Si aucune règle de pare-feu explicite ne correspond, la règle intégrée Drop all, située à la fin de la base de règles, s’applique avec Policy ou Firewall ID 0. Elle ne génère pas d’entrée normale dans le journal du trafic du pare-feu. Pour rendre ces rejets traçables dans Log Viewer, Central Reporting ou Syslog, créer à la fin de la base une règle distincte avec Action: Drop et Log firewall traffic activé.

Sélectionner individuellement les zones source et destination nécessaires et ne pas utiliser Any indistinctement pour les zones. Les services locaux restent ainsi accessibles. Si la règle finale reçoit beaucoup de trafic légitime, une règle Allow adaptée manque probablement plus haut ou un réseau a été mal classé.

Pour SFOS 22.0.1 MR1 Build 490, Sophos documente également le problème connu NC-178387 : les rejets par défaut avec l’ID 0 sont absents de Dropped Packet Capture et de drppkt ; dans Packet Capture normal, seul Incoming peut apparaître sans entrée Violation Firewall correspondante. Le trafic est tout de même rejeté. Sophos n’indique pas de version de correction confirmée dans la liste des problèmes connus. Ce comportement ne doit donc pas être présumé en dehors du build indiqué.

En cas de rejet par défaut suspecté :

1. Vérifier l’ordre des règles et Policy Test.
2. Comparer le résultat avec un véritable Packet Capture.
3. Si la journalisation est nécessaire, créer une règle finale avec des zones ciblées et sa propre Rule ID.
4. Répéter le test et confirmer la nouvelle Rule ID dans le journal ou la capture.

Policy Tester sous Diagnostics > Tools ne tient pas compte des routes SD-WAN et ne constitue donc jamais une preuve suffisante à lui seul. Sur SFOS 22.0 GA, NC-177587 pouvait également afficher des résultats de règles incorrects ; les journaux de production et Packet Capture restent déterminants.

Déterminer la cause à partir du constat

Règle, NAT et chemin de retour

Si la Rule ID ne correspond pas à la règle attendue, vérifier les zones source et destination, les objets réseau, le service, le protocole, l’utilisateur, le calendrier et l’ordre des règles. Avec DNAT, il faut déterminer si le test cible l’adresse publique et quelle NAT ID s’applique réellement. Les bases sont décrites sous Comprendre les règles du pare-feu et Publier un serveur avec DNAT.

Si Packet Capture affiche Forwarded, mais aucune réponse, une autre règle Allow est rarement la solution. Les causes fréquentes sont l’absence de SNAT/MASQ ou de route de retour, une règle NAT liée désactivée, un blocage local sur le système cible ou SD-WAN qui renvoie la réponse par un autre chemin. Les deux directions doivent passer par le même pare-feu stateful.

Session, routage asymétrique et HA

Des messages comme Could not associate packet to any connection signifient qu’aucune entrée Conntrack correspondante n’a été trouvée. Les causes possibles comprennent une session expirée, des flags TCP inattendus, un chemin de retour asymétrique ou un flux que le pare-feu ne voit que dans une direction. Après un changement de rôle HA, le nœud sur lequel la connexion a été établie peut également être pertinent.

Un seul événement RST ou FIN sans problème pour l’utilisateur ne nécessite pas de modification immédiate. En cas d’interruptions reproductibles, vérifier les deux directions avec le même filtre, puis le routage, SD-WAN, les chemins VPN et le statut HA.

Consumed et services locaux du pare-feu

Consumed n’est pas un rejet normal de trafic transitant. La destination est le pare-feu lui-même, par exemple WebAdmin, User Portal, VPN Portal, SSH, DNS, DHCP, IPsec, SSL VPN ou SNMP. Ces connexions sont généralement contrôlées par Administration > Device access et Local service ACL, pas par une règle de pare-feu normale. Sécuriser Device Access sur Sophos Firewall décrit la configuration sûre.

Modules de sécurité, VPN et MTU

Une règle de pare-feu peut autoriser le trafic avant qu’un module en aval ne le bloque. Si les ID ou Reasons l’indiquent, vérifier aussi Web Policy, SSL/TLS inspection, Application Control, IPS, Active Threat Response et WAF. Lors d’un résultat IPS, évaluer la signature et le contexte de la règle avant de créer une exception ; la procédure est décrite dans Tester IPS de Sophos Firewall en toute sécurité.

Pour les problèmes Web et TLS, QUIC sur UDP 443 peut modifier le traitement attendu. Bloquer QUIC et HTTP/3 montre le contrôle approprié.

Avec VPN, PPPoE, SD-WAN ou des tunnels imbriqués, MTU, MSS et la fragmentation provoquent plutôt des blocages ou des interruptions partielles qu’un rejet clair. Consultez les guides sur MTU et MSS et le dépannage VPN IPsec.

Lorsque les vérifications standard ne suffisent pas

Aucune entrée dans Log Viewer ou Packet Capture

Si une entrée de journal manque, vérifier d’abord la journalisation de la règle, Log settings, le filtre temporel et le module responsable. Si Packet Capture n’affiche aucun paquet non plus, contrôler les points suivants avant de diagnostiquer le réseau :

• Packet Capture est réellement actif et le test a été effectué seulement après son activation.
• Le filtre contient les bonnes adresses, les bons ports, la bonne direction et la bonne interface ; l’élargir légèrement pour un test.
• Le tampon de 2048 Ko n’est pas plein. Lorsqu’il est plein, l’enregistrement s’arrête automatiquement et doit être redémarré après avoir sélectionné Clear.
• Sous System services > Services, Packet capture and Live connections est en cours d’exécution ; en cas de problème de démarrage, redémarrer ce service de manière contrôlée.

Ce n’est que lorsqu’un test reproductible avec une capture fonctionnelle ne montre aucun paquet entrant qu’il faut déplacer l’analyse en amont du pare-feu : client, VLAN, switch, passerelle, routeur amont ou mauvaise cible de test.

tcpdump, Drop Capture et archives de journaux

Pour des captures plus longues, des fichiers PCAP ou des filtres BPF précis, se connecter par SSH et sélectionner Option 4: Device Console. Voici un exemple de capture ciblée pour deux hôtes et HTTPS :

tcpdump 'host 192.0.2.10 and host 198.51.100.20 and port 443'

Pour les paquets rejetés par les règles de pare-feu, le même filtre peut être utilisé avec drop-packet-capture :

drop-packet-capture 'host 192.0.2.10 and host 198.51.100.20 and port 443'

drop-packet-capture n’aide pas pour les problèmes de couche applicative. Pour un fichier PCAP, tcpdump prend en charge l’option filedump ; le fichier se trouve temporairement sous /tmp. Garder la capture aussi courte et ciblée que possible, car les paquets peuvent contenir des données sensibles, puis supprimer le fichier après l’analyse. D’autres exemples figurent sous tcpdump sur Sophos Firewall.

Si le support a également besoin de journaux de service, identifier d’abord le journal concerné et ne collecter que la période nécessaire. Services et journaux de Sophos Firewall et Collecter les journaux pour le support et l’analyse expliquent la procédure.

Corriger et documenter en toute sécurité

Une exception n’est appropriée que lorsque le module, l’objectif légitime et la portée minimale sont connus. Ne pas autoriser une exception TLS globale, une règle Allow avec Any ou des réseaux entiers simplement parce que le service fonctionne ensuite. Des hôtes, services et utilisateurs précis, assortis d’une date de révision ou d’expiration, sont préférables.

Avant de terminer, documenter :

• Source, destination, port, protocole, heure et utilisateur.
• Rule ID et NAT ID attendues et réellement visibles.
• Status, Reason et module de sécurité concerné.
• Directions aller et retour ou point auquel le flux s’arrête.
• Modification, propriétaire, ticket et date de révision ; consigner également l’absence volontaire de modification.

Répéter ensuite le même test. La connexion autorisée doit fonctionner et une source de comparaison non autorisée doit rester bloquée. Une correction rapide ne se transforme ainsi pas en faille de sécurité permanente.

Questions fréquentes