Utilisation de la capture de paquets Sophos Firewall dans WebAdmin

La capture de paquets est l’un des outils de dépannage les plus importants dans WebAdmin de Sophos Firewall. Elle montre si les paquets arrivent à une interface, s’ils sont transférés, quelle règle ou ID NAT est impliquée et si un paquet est rejeté.

Le Log Viewer montre la décision du pare-feu. La capture de paquets montre le flux des paquets. Ensemble, ils sont souvent le moyen le plus rapide de trouver la cause. Si une règle de pare-feu doit être testée spécifiquement, le processus dans Tester une règle Sophos Firewall avec Log Viewer, Policy tester et Packet Capture est également adapté.

Il est important de bien situer : cet article décrit la version WebAdmin de la capture de paquets. Pour un premier contrôle, elle est idéale car on voit directement dans le navigateur si les paquets arrivent, sont transférés ou rejetés. Pour des enregistrements plus longs, des filtres très précis, l’exportation PCAP ou les cas de support, un tcpdump via SSH est souvent plus approprié.

Choix de l’outil

Quel article convient ?

La capture de paquets est particulièrement efficace lorsque le flux réel des paquets est incertain. Pour des questions connexes, un autre point de départ peut être plus rapide :

Cette distinction est importante : la capture de paquets montre les paquets et le statut au niveau des paquets. Elle ne remplace pas le Log Viewer pour les décisions de politique, ni l’article sur le NAT pour la logique de traduction, ni tcpdump lorsqu’un fichier PCAP exploitable est nécessaire.

Quand la capture de paquets est-elle utile ?

La capture de paquets est particulièrement utile pour des questions telles que :

• Le trafic arrive-t-il à la pare-feu ?
• Le trafic sort-il par l’interface attendue ?
• Une règle de pare-feu s’applique-t-elle ?
• Une règle NAT s’applique-t-elle ?
• Un paquet est-il rejeté par une politique, IPS ou routage ?
• Une réponse revient-elle du système cible ?
• Un autre port ou protocole est-il utilisé que prévu ?

Si rien n’est visible dans le Log Viewer, la capture de paquets est souvent l’étape suivante. On peut alors voir si le problème se situe avant le pare-feu ou si le pare-feu traite le trafic.

Si l’accent est mis sur les rejets, Violation, Rule ID, NAT ID ou les paquets rejetés, Analyser les paquets rejetés par Sophos Firewall est également adapté.

Chemin du menu

L’outil se trouve sous :

Diagnostics > Packet capture

La capture de paquets s’ouvre directement dans WebAdmin. Selon la version SFOS et l’affichage du navigateur, elle apparaît comme une fenêtre de diagnostic distincte au sein de l’interface WebAdmin.

Avant de l’ouvrir, le cas de test doit déjà être défini. L’outil est le plus efficace lorsqu’on reproduit un flux unique et qu’on ne réfléchit pas à ce qu’on cherche pendant l’enregistrement.

Après l’ouverture, il faut d’abord utiliser Configure et définir le filtre de capture avant de déclencher le test. Si la destination, la cible CDN ou la vue NAT ne sont pas encore claires, un premier filtre sur l’IP source est souvent préférable à un filtre trop étroit avec une mauvaise adresse de destination. Après le test reproduit, l’enregistrement doit être arrêté pour éviter que l’affichage ne soit encombré par le trafic de fond.

Log Viewer, Packet Capture ou tcpdump ?

Log Viewer, Packet Capture dans WebAdmin et tcpdump répondent à des questions différentes. Utiliser le mauvais outil en premier conduit souvent à chercher au mauvais endroit.

Un bon exemple est un ping. Dans le Log Viewer, on voit souvent seulement une entrée ou une décision résumée concernant la connexion. Dans la capture de paquets, on voit les paquets ICMP individuels : Echo Request vers la cible et Echo Reply en retour. Windows envoie par défaut quatre ICMP Echo Requests avec ping. Dans la capture de paquets, on s’attend donc à plusieurs paquets aller-retour. Si seuls les Requests sont visibles mais pas les Replies, c’est un problème différent que si aucun Request n’arrive à la pare-feu.

En pratique, cela signifie :

• Log Viewer répond : Quelle règle ou quel module a décidé ?
• Packet Capture répond : Les paquets sont-ils vraiment arrivés et quel chemin prennent-ils ?
• Pour les problèmes de routage, NAT, VLAN, passerelle ou retour, Packet Capture est souvent plus révélateur.
• Pour les décisions de filtrage Web, Application Control, IPS ou inspection SSL/TLS, le Log Viewer est également nécessaire.
• Pour les enregistrements à envoyer au support Sophos ou à des partenaires d’analyse externes, tcpdump est généralement préférable à une capture d’écran de WebAdmin.

Préparer la capture

Délimiter proprement avant de commencer

La capture de paquets ne doit pas être lancée sans filtre. Dans les réseaux productifs, cela génère beaucoup de données et rend la sortie difficile à lire.

⚠️ La capture de paquets ne doit jamais être exécutée en tant qu’enregistrement large et continu sur des pare-feu en production. Un filtre étroit, un test court et un moment précis réduisent la quantité de données, le risque de confidentialité et les mauvaises interprétations.

Il faut d’abord noter :

• Source IP
• Destination IP ou FQDN
• Protocole
• Port source, si pertinent
• Port de destination
• Interface ou zone
• Heure du test
• Application concernée
• Règle de pare-feu ou règle NAT attendue, si connue
• Résultat attendu : autorisé, bloqué, DNAT, SNAT, VPN, politique Web ou IPS

Pour un test Web, la délimitation pourrait ressembler à ceci :

En pratique, il faut toujours reproduire un seul cas de test à la fois. Plusieurs modifications parallèles de la règle de pare-feu, du NAT, du routage et de la configuration du client rendent la sortie de la capture difficile à évaluer. Si le test concerne un problème utilisateur, il faut également noter l’utilisateur connecté, l’appareil concerné et l’heure exacte.

Configurer le filtre de capture

Via Configure, on définit un filtre aussi étroit que possible.

Filtres typiques :

• IP source du client
• IP de destination du serveur
• Port de destination
• Protocole TCP, UDP ou ICMP
• Interface

Si le serveur cible est inconnu, on peut d’abord filtrer uniquement par l’IP source. Si trop de paquets sont visibles ensuite, restreindre davantage.

Sophos Firewall utilise pour cela la syntaxe Berkeley Packet Filter, abrégée BPF. Le filtre de capture décide quels paquets sont écrits dans le tampon de capture. Il doit donc être défini proprement avant le test.

Exemples typiques de BPF :

Pour un test Web très ciblé, un filtre pourrait ressembler à ceci :

host 172.16.10.25 and host 93.184.216.34 and port 443

Pour un test de ping, il suffit souvent de :

host 172.16.10.25 and proto ICMP

Si le filtre est trop étroit

Un filtre de capture étroit est important, mais il ne doit pas masquer l’erreur. Surtout avec DNS, NAT, CDN et retours, il faut décider consciemment si on filtre d’abord suffisamment large ou immédiatement très précisément.

Pièges typiques :

Pour le premier passage, un filtre sur l’IP source est souvent plus judicieux qu’un filtre trop précis avec une mauvaise IP de destination. Si le flux pertinent est visible, on peut filtrer plus étroitement lors du second passage. En cas d’erreurs NAT, il faut également vérifier si l’on regarde avant ou après la traduction.

Dans l’interface WebAdmin, on voit après l’enregistrement la chaîne BPF active au-dessus de la liste des paquets. La première capture d’écran montre la configuration du filtre, la seconde capture d’écran la liste des résultats avec le filtre actif.

⚠️ Les données PCAP peuvent contenir des adresses IP, des noms d’hôtes, des détails de protocole et, selon le protocole, également des données utilisateur. Les captures ne doivent être partagées qu’avec des personnes ou des partenaires autorisés à voir ces données.

Exécuter la capture

Démarrer et reproduire la capture

1. Définir le filtre.
2. Activer la capture de paquets via le curseur.
3. Reproduire le problème de manière ciblée.
4. Arrêter la capture.
5. Analyser les résultats.
6. Vider la capture si un nouveau test est lancé.

Sophos Firewall affiche le statut et le tampon :

Si le tampon est plein, la capture s’arrête automatiquement. Ensuite, il faut vider avec Clear avant de pouvoir enregistrer à nouveau de manière significative. C’est pourquoi un filtre étroit est important.

Dans les paramètres de filtrage, on peut également définir combien d’octets par paquet sont capturés. Pour de nombreuses premières analyses, les informations d’en-tête suffisent. Si plus de données utilisateur sont nécessaires, il faut capturer plus d’octets, mais en gardant à l’esprit la confidentialité et la taille du tampon.

Interpréter la sortie

Comprendre les colonnes importantes

La capture de paquets affiche de nombreux champs. En pratique, ceux-ci sont particulièrement importants :

Ces champs sont précieux car ils comblent le fossé entre “la règle semble correcte” et “le trafic fonctionne réellement ainsi”.

Via Show additional properties ou la vue détaillée, on voit selon la version d’autres informations comme l’ID de connexion, l’ID de filtre Web, l’ID d’application, l’ID de catégorie Web, l’ID de passerelle, le nom d’utilisateur ou d’autres ID de politique. Ces détails aident lorsqu’un paquet est traité non seulement par une règle de pare-feu, mais aussi par le Web, Application Control, IPS ou d’autres modules.

Interpréter correctement le statut

Si on ne voit que Incoming et pas Forwarded, le paquet est probablement bloqué sur la pare-feu. Il faut alors vérifier la règle de pare-feu, le NAT, le routage et les fonctions de sécurité.

Si Forwarded est visible mais qu’aucune réponse ne revient, le problème se situe souvent au niveau du système cible, du retour, du NAT ou d’une contrepartie.

Pour un ping réussi, on voit généralement des paquets dans les deux sens. Si Windows envoie quatre pings, on voit plusieurs ICMP Echo Requests du client vers la cible et plusieurs Echo Replies en retour. Si les Replies manquent, on vérifie la route de retour, le système cible, le pare-feu local du système cible, le NAT ou une contrepartie. Si les Requests manquent déjà, on vérifie le client, la passerelle, le VLAN, le port du commutateur ou si le trafic atteint la Sophos Firewall.

Lire correctement Consumed et Generated

Consumed et Generated sont souvent mal interprétés. Ces statuts ne signifient pas automatiquement qu’une règle de pare-feu normale manque.

Des exemples de Consumed sont les accès à WebAdmin, User Portal, VPN Portal, SSH, DNS, SNMP, IPsec ou SSL VPN de la pare-feu elle-même. Ce type de trafic n’est pas traité comme un trafic de passage normal par une règle LAN-to-WAN ou WAN-to-DMZ. Si un paquet dans la capture montre Consumed, il faut d’abord clarifier si le client voulait vraiment atteindre la pare-feu elle-même.

Pour ces cas, Administration > Device access et Local Service ACL sont plus importants qu’une règle de pare-feu normale. Le renforcement de ces accès est décrit dans Sécuriser l’accès à Sophos Firewall : configurer correctement l’accès au dispositif.

Utiliser le filtre d’affichage

Le filtre de capture limite quels paquets sont enregistrés. Le Display filter filtre uniquement l’affichage déjà enregistré. C’est pratique si on a intentionnellement démarré la capture un peu plus large et qu’on souhaite ensuite n’afficher que certains paquets.

Dans le Display filter, on peut filtrer entre autres par ces champs :

• Nom de l’interface
• Type Ethernet, par exemple IPv4, IPv6 ou ARP
• Type de paquet
• Source IP et port source
• Destination IP et port de destination
• Raison
• Statut
• Rule ID
• Utilisateur
• Connection ID

Pour le dépannage, Status, Reason, Rule ID, Source IP, Destination IP et Destination port sont particulièrement utiles. Si de nombreux paquets sont présents dans la capture, on peut ainsi rapidement réduire à la partie pertinente sans devoir redémarrer immédiatement le test.

Lire le NAT dans la capture de paquets

Avec le NAT, il faut noter qu’un paquet avant et après le NAT a un aspect différent. La capture de paquets peut rendre visibles l’ID NAT, l’ID de règle et les adresses modifiées.

En cas de problèmes NAT, il faut vérifier :

• Voit-on le paquet avec l’adresse d’origine ?
• Voit-on le paquet après la traduction ?
• L’ID NAT attendu est-il affiché ?
• Le paquet passe-t-il par l’interface de sortie attendue ?
• Une réponse revient-elle ?

Pour le DNAT, il est en plus important de noter : la règle de pare-feu utilise la zone de destination après NAT, mais l’IP de destination avant NAT. Cela peut sembler inhabituel au premier abord.

Plus d’informations : Comprendre le NAT sur Sophos Firewall : SNAT, DNAT, MASQ, PAT.

Combiner Packet Capture et Log Viewer

Le meilleur processus est :

1. Ouvrir le Log Viewer.
2. Démarrer Packet Capture avec un filtre étroit.
3. Reproduire le test.
4. Vérifier dans Packet Capture si les paquets arrivent et sont transférés.
5. Vérifier dans le Log Viewer quelle règle ou quel module a décidé.
6. Si nécessaire, passer au fichier journal approprié.

Le Log Viewer montre par exemple les événements de pare-feu, Web, inspection SSL/TLS, IPS ou Application Control. Packet Capture montre en revanche le flux des paquets au niveau de l’interface.

Surtout pour le ping ou les connexions TCP simples, la combinaison est importante. Le Log Viewer peut seulement montrer qu’une connexion a été autorisée ou bloquée. Packet Capture montre en plus si les paquets de réponse reviennent, si le NAT s’applique, si la bonne interface de sortie est utilisée et si le retour est correct.

Cas d’analyse typiques

Le client n’atteint pas Internet : Configurer la capture sur l’IP source et TCP 443. Si aucun paquet n’arrive, vérifier le client, le VLAN, la passerelle ou le commutateur. Si le paquet entre mais ne sort pas, vérifier la règle de pare-feu, le NAT ou le routage.

Le DNAT ne fonctionne pas : Configurer la capture sur l’IP de destination publique et le port externe. Si aucun paquet n’arrive, vérifier le routeur du fournisseur, le transfert de port, le groupe de sécurité cloud ou le WAN. Si le paquet arrive mais ne va pas au serveur interne, vérifier la règle DNAT et la règle de pare-feu.

Le trafic VPN ne passe pas : Configurer la capture sur l’interface du tunnel, l’interface XFRM ou les réseaux source/destination pertinents. Vérifier également strongswan.log, charon.log ou xfrmi.log.

Le filtre Web bloque de manière inattendue : Dans Packet Capture, on voit généralement seulement le flux des paquets. La décision elle-même est mieux vérifiée dans le Log Viewer sous Web, Application Control ou inspection SSL/TLS.

Les petits tests fonctionnent, les transferts importants bloquent : Configurer la capture sur le client concerné et la cible, et surveiller les retransmissions, les réponses manquantes ou les tailles de paquets inhabituelles. Si le ping, la connexion ou les petites requêtes HTTP fonctionnent, mais que les téléchargements plus importants, RDP, VoIP ou les applications VPN bloquent, il faut également vérifier la MTU, MSS, PPPoE, le surcoût VPN et la fragmentation. Le processus est décrit dans Vérifier la MTU et MSS de Sophos Firewall en cas de problèmes VPN.

Interprétations erronées typiques

Packet Capture montre beaucoup de choses, mais pas toujours ce qu’on attend d’abord. Certaines interprétations erronées sont particulièrement fréquentes dans les cas de support.

Si la capture de paquets montre un ID de règle inattendu, il ne faut pas immédiatement modifier plusieurs règles. Il est préférable de d’abord comparer avec le Log Viewer et la position de la règle. Pour un matching systématique, Vérifier les causes d’une règle Sophos Firewall qui ne s’applique pas est adapté.

Limites, confidentialité et partage

Confidentialité et partage des captures

Les données de capture de paquets sont des données opérationnelles. Même si souvent seuls les en-têtes sont visibles, elles peuvent révéler des adresses IP internes, des cibles publiques, des noms d’utilisateur, des noms d’hôte, des ports, des protocoles et des relations de communication. Avec des protocoles non chiffrés, des données utilisateur peuvent également être visibles.

Avant de partager, il faut donc vérifier :

• La capture contient-elle des noms de clients, des noms d’hôte internes ou des adresses IP publiques ?
• Les utilisateurs, systèmes ou applications sont-ils reconnaissables ?
• Le destinataire est-il autorisé à voir ces informations ?
• Une capture d’écran des lignes pertinentes suffit-elle ou faut-il vraiment un fichier PCAP ?
• La capture doit-elle être raccourcie ou anonymisée au préalable ?

Pour les cas de support, une capture tcpdump ciblée avec un filtre propre est souvent meilleure qu’une capture WebAdmin large. Si des fichiers journaux sont également nécessaires, Sauvegarder les journaux Sophos Firewall pour le support et l’analyse est utile.

Quand tcpdump est-il meilleur ?

La capture de paquets WebAdmin est idéale pour des analyses rapides directement dans le navigateur. On voit rapidement si les paquets arrivent, sont transférés, consommés, générés ou rejetés. Pour une première délimitation, c’est généralement le bon départ.

tcpdump est meilleur lorsque l’enregistrement n’est pas seulement nécessaire en tant qu’affichage à l’écran, mais en tant que fichier exploitable ou en tant que trace technique plus longue.

La différence la plus importante : tcpdump montre des paquets, mais pas de décision spécifique à Sophos. Si on doit savoir quelle règle de pare-feu, règle NAT, politique Web, politique IPS ou règle d’inspection SSL/TLS était impliquée, on a toujours besoin de Log Viewer, de la capture de paquets WebAdmin ou du fichier journal approprié.

Avant tcpdump, SSH ou Advanced Shell doivent être délibérément activés. La capture doit être étroitement filtrée, limitée dans le temps et supprimée après l’analyse. Une capture PCAP large sur un pare-feu en production peut rapidement contenir des données sensibles et beaucoup de trafic inutile.

Plus d’informations : Sophos Firewall tcpdump : capturer des paquets via CLI.

Liste de contrôle

• Noter le cas de test avec source, destination, port, protocole et heure.
• Connaître la règle de pare-feu et la règle NAT attendues, si possible.
• Définir un filtre de capture étroit.
• Pour DNS, NAT ou cibles CDN, vérifier si le filtre capture vraiment les directions aller et retour.
• Reproduire un seul cas de test à la fois.
• Arrêter la capture de paquets après le test.
• Distinguer consciemment Incoming, Forwarded, Consumed, Generated et Violation.
• Comparer l’ID de règle et l’ID NAT avec le Log Viewer.
• En cas de réponse manquante, vérifier le retour, le NAT, le système cible et la contrepartie.
• Pour les transferts importants bloqués, vérifier MTU/MSS, fragmentation et surcoût VPN.
• Vérifier les captures pour les données sensibles avant de les partager.
• Utiliser tcpdump pour des enregistrements plus longs ou des fichiers PCAP.

FAQ