Utiliser Packet Capture de Sophos Firewall dans WebAdmin

Sous Diagnostics > Packet capture, il est possible de suivre un flux réseau unique directement dans WebAdmin. Il suffit de définir un filtre BPF précis, de démarrer la capture, de reproduire le problème une fois, puis de vérifier les interfaces, Rule ID, NAT ID, Status et Reason.

Packet Capture montre le flux réel des paquets. La stratégie ayant pris la décision doit également être vérifiée dans Log Viewer. Pour des captures plus longues ou un fichier .pcap, il faut utiliser tcpdump via SSH, car la capture WebAdmin ne peut pas être téléchargée au format PCAP.

Si la connexion est déjà établie et qu’il faut d’abord uniquement trouver la session active avec son utilisateur, ses interfaces, Rule ID, NAT ID ou sa passerelle, commencer par Live Connections et Connection List. Packet Capture intervient ensuite lorsque le chemin réel aller et retour doit être prouvé.

Packet Capture en six étapes

1. Noter la Source IP, la destination, le protocole, le port et l’heure du test. Exemple : client 172.16.10.25 vers 93.184.216.34 via TCP 443.
2. Ouvrir Diagnostics > Packet capture et cliquer sur Configure.
3. Définir et enregistrer une chaîne BPF, par exemple host 172.16.10.25 and port 443.
4. Régler Packet Capture sur Trace On. Dans SFOS 22, les détails des paquets apparaissent dans une nouvelle fenêtre du navigateur.
5. Reproduire exactement un test, puis arrêter la capture avec Trace Off.
6. Lire la séquence de bas en haut et contrôler In/Out interface, Rule ID, NAT ID, Status, Reason et les paquets de réponse.

Si la chaîne BPF est modifiée pendant une capture, régler d’abord Packet Capture sur Trace Off, puis de nouveau sur Trace On afin d’appliquer le nouveau filtre.

⚠️ Une capture large et continue complique l’analyse et collecte inutilement des données d’exploitation. Utiliser un filtre précis, effectuer un test court et désactiver Packet Capture ensuite.

Définir un Capture Filter précis

Le Capture Filter détermine avant la capture quels paquets entrent dans le tampon de 2048 KB. Le Display Filter limite uniquement l’affichage des données déjà capturées. L’interface ne se sélectionne donc pas dans Capture Filter, mais plus tard dans Display Filter.

Pour un test HTTPS, il faut connaître au moins la source, la destination et le port. Si la destination reste incertaine à cause du DNS, d’un CDN ou du NAT, mieux vaut commencer uniquement avec la Source IP, puis affiner le flux visible.

Avant de commencer, les éléments suivants doivent être connus :

• Source IP et Destination IP actuelle
• protocole ainsi que ports source et de destination, s’ils sont pertinents
• interfaces d’entrée et de sortie attendues ou zones correspondantes
• Firewall Rule et NAT Rule attendues
• résultat attendu, par exemple autorisé, bloqué, DNAT, SNAT ou VPN
• heure exacte du test et une seule action reproductible

Exemples BPF

• Hôte : host 10.10.10.1
• Source IP : src host 10.10.10.1
• Destination IP : dst host 10.10.10.1
• Réseau : net 10.10.10.0
• Réseau source : src net 10.10.10.0
• Réseau de destination : dst net 10.10.10.0
• Port : port 443
• Port source : src port 443
• Port de destination : dst port 443
• Protocole : proto TCP, proto UDP ou proto ICMP

Un test web précis peut se présenter ainsi :

host 172.16.10.25 and host 93.184.216.34 and port 443

Pour un test ping, ceci suffit généralement :

host 172.16.10.25 and proto ICMP

Sophos documente ces formes BPF de base. Cela ne garantit pas automatiquement que toute expression tcpdump fonctionne dans WebAdmin.

Deux autres formes documentées permettent des variantes ciblées :

• Plusieurs ports avec OR : port 80 or port 443 capture les paquets utilisant l’un des deux ports, par exemple pour une courte comparaison HTTP/HTTPS. Sans condition sur l’hôte, le filtre s’applique à tous les hôtes ; limiter donc la durée de capture.
• Exclure un port pour un hôte : host 172.16.10.25 and port not 22 capture cet hôte, mais omet les paquets dont le port source ou de destination est 22. Cela peut masquer le trafic d’administration SSH, mais capture toujours tous les autres ports de cet hôte.

Les opérateurs or, and et port not font partie de la syntaxe. Les adresses IP et numéros de port sont des valeurs d’exemple : remplacer l’adresse de l’hôte par celle de l’hôte de test et les ports par ceux des services réellement examinés. La destination de l’exemple web existant, 93.184.216.34, n’est pas non plus un point de terminaison de test confirmé et doit être remplacée par l’adresse IP de destination actuelle. Après un court test, vérifier que les paquets souhaités sont visibles et que les ports exclus sont absents ; le filtre ne modifie pas les règles de pare-feu.

Avec le NAT, le point de vue est important : un filtre sur l’adresse IP interne du client peut masquer l’entrée côté WAN après MASQ. S’il manque des paquets, filtrer d’abord uniquement par source, destination ou port, puis vérifier que les deux directions restent visibles.

Tampon et options de capture

• Number of bytes to capture (per packet) définit le nombre d’octets enregistrés par paquet. Les données d’en-tête suffisent souvent pour un premier test.
• Sans Wrap capture buffer once full, la capture s’arrête automatiquement à 2048 KB. Avec Wrap, les données les plus anciennes sont écrasées.
• Clear vide le tampon avant un nouveau test. Enregistrer d’abord les lignes de diagnostic nécessaires, car elles seront supprimées.
• Buffer used indique l’occupation actuelle, de 0 à 2048 KB, et non la capacité totale fixe. Cela permet de voir si la capture approche de la limite du tampon.
• Les détails des paquets capturés peuvent être actualisés. Pour obtenir une vue à jour, actualiser les détails et consulter Buffer used ; ce n’est pas la même opération que vider le tampon avec Clear.
• La capture continue lors du passage à une autre page de WebAdmin. Il faut donc la régler volontairement sur Trace Off après le test.

Lire correctement les résultats

Un flux apparaît plusieurs fois, car le pare-feu capture l’entrée et la sortie sur les interfaces. Un aller-retour ping comprend généralement quatre lignes : la requête arrive sur LAN, sort sur WAN, la réponse arrive sur WAN et sort sur LAN. Les entrées les plus récentes figurent en haut ; pour suivre l’ordre chronologique, lire la liste de bas en haut.

Les champs les plus importants

• In interface / Out interface : Où le paquet arrive et par quelle interface il repart.
• Source IP / Destination IP / Ports : Quel flux est examiné.
• Rule ID : Quelle règle de pare-feu traite le trafic.
• NAT ID : Quelle règle NAT intervient.
• Status : Ce que fait le pare-feu à cette étape du traitement.
• Reason : Pourquoi un paquet est rejeté.

Time, Ethernet Type et Packet Type permettent de situer chaque ligne dans le temps et d’identifier le protocole. La liste contient aussi Connection ID, Connection status, Gateway ID, Username, ainsi que les ID des stratégies Web, Application, IPS, Remote Access et Bandwidth appliquées. Pour le paquet sélectionné, la vue détaillée affiche également les en-têtes et les données Hex et ASCII.

Pour une corrélation plus précise, distinguer les métadonnées supplémentaires :

• Served by: L’aide Sophos pour SFOS 22 et 23 décrit ce champ avec les valeurs de connexion Established, TIME_WAIT et NONE. Il se lit séparément du champ Connection status, également présent, et du champ de paquet Status, qui décrit l’étape de traitement, par exemple Incoming ou Forwarded. Cette description documentée ne permet de tirer aucune conclusion sur FastPath ou sur le déchargement matériel.
• Connection flags : Indicateurs système de la connexion ; ne pas les confondre avec le champ Status du paquet.
• User group : Appartenance de l’utilisateur à un groupe, et non son Username.
• Master connection ID : ID de la connexion principale associée à la connexion actuelle ; Connection ID identifie la connexion actuelle elle-même.
• Application ID / Application category ID : Identifiant de l’application ou de sa catégorie, respectivement.
• Application filter ID : Identifiant de la stratégie de filtrage applicatif appliquée au trafic de la connexion, et non celui de l’application.
• Web category ID / Web filter ID : Catégorie web ou stratégie de filtrage web appliquée, respectivement. Les ID de catégorie et de stratégie correspondent à des associations différentes.

Interpréter correctement Status

• Incoming : Le paquet a été reçu sur une interface ; cela ne prouve pas encore une décision ultérieure.
• Forwarded : Le pare-feu a transféré le paquet via une interface de sortie.
• Consumed : Le paquet est destiné au pare-feu lui-même, par exemple à WebAdmin, VPN Portal, SSH, DNS ou un service VPN.
• Generated : Le pare-feu a généré le paquet, par exemple comme réponse ou via un service système.
• Violation : Le pare-feu a rejeté le paquet en raison d’une violation de stratégie.

Avec Consumed, Administration > Device access, une Local Service ACL ou le service de pare-feu concerné sont souvent déterminants. Sécuriser Device Access de Sophos Firewall explique la configuration correspondante.

Vérifier ensemble Rule ID, NAT ID et Reason

Une Rule ID inattendue ne prouve pas qu’une règle est défectueuse. Vérifier d’abord l’ordre des règles, les zones et la correspondance dans Log Viewer. La procédure complète est décrite dans Tester correctement une règle Sophos Firewall.

Avec le NAT, le même flux peut apparaître avec des adresses différentes avant et après la traduction. La NAT ID attendue, In/Out interface et les paquets de réponse sont déterminants. Comprendre le NAT sur Sophos Firewall explique la logique de traduction.

Si Reason affiche par exemple LOCAL_ACL, IPS, APPLICATION_FILTER, USER_IDENTITY ou IP_SPOOF, vérifier le module correspondant dans Log Viewer. Une classification détaillée figure dans Analyser les paquets rejetés sur Sophos Firewall.

Pour comparer avec Log Viewer :

1. Ouvrir Log Viewer et Packet Capture en parallèle.
2. Définir Capture Filter et reproduire exactement un test.
3. Dans Packet Capture, contrôler les interfaces, les paquets de réponse, Rule ID et NAT ID.
4. Dans le module approprié de Log Viewer, vérifier quelle règle ou Security Policy a pris la décision.
5. Ensuite seulement, examiner précisément la règle, le NAT, le routage ou le module de sécurité concerné.

Dans SFOS 22, Log Viewer propose également Open PCAP lorsque Packet Capture est actif afin d’ouvrir les informations des paquets. L’absence d’une entrée de journal Firewall pendant un test en cours ne prouve pas un problème de capture : les sessions Firewall ne sont normalement consignées que lorsque le pare-feu reçoit l’événement Connection Destroy. La liste des paquets reste donc la référence pour analyser immédiatement le chemin.

Utiliser Display Filter

Display Filter est utile lorsque la liste contient déjà des paquets. Il permet notamment de filtrer par interface, IPv4/IPv6/ARP, Packet type, Source/Destination IP et port, Reason, Status, Rule ID, User ou Connection ID. Allowed est également disponible comme valeur de filtre pour les paquets autorisés ; les lignes de paquets montrent les étapes de traitement telles que Incoming ou Forwarded.

Sous User, sélectionner un utilisateur dans la liste des utilisateurs déjà existants. Outre les exemples expliqués plus haut, la liste déroulante Reason propose d’autres valeurs documentées : Firewall, DOS_ATTACK, INVALID_TRAFFIC, INVALID_FRAGMENTED_TRAFFIC, ICMP_REDIRECT, SOURCE_ROUTED_PACKET, FRAGMENTED_TRAFFIC, MAC_FILTER, IPMAC_FILTER, NEIGHBOR_POISONING, SSL_VPN_ACL_VIOLATION, VIRTUAL_HOST et ICMP ERROR MESSAGE. Firewall est ici la valeur de sélection exacte, et non une simple désignation générale du produit. Conserver l’écriture, espaces compris. Sélectionner la valeur correspondant à l’entrée observée pour limiter l’affichage et corréler l’heure du test, le flux, Rule ID et NAT ID avec les journaux correspondants. Même pour INVALID_TRAFFIC, SSL_VPN_ACL_VIOLATION ou VIRTUAL_HOST, le nom seul ne remplace pas la recherche de la cause dans le module Log Viewer concerné.

Pour les problèmes ARP ou NDP, Contrôler le cache des voisins ARP et NDP montre comment comparer la capture au cache local des voisins et aux associations statiques.

Save applique le filtre et Clear le réinitialise. Pour le trafic VPN, régler par exemple Capture Filter sur un hôte ou un réseau. Si l’interface tunnel ou XFRM attendue est proposée dans Display Filter, limiter l’affichage à cette interface. Sinon, lire directement In/Out interface dans les lignes de paquets.

Analyse rapide des erreurs

Aucun paquet visible : Vérifier Capture Filter et Display Filter. Pour les FQDN et CDN, contrôler l’adresse IP de destination actuelle ; avec le NAT, filtrer d’abord uniquement par Source IP. Si la liste reste vide, vérifier la passerelle du client, le VLAN, le port du commutateur et les équipements en amont.

Le client n’accède pas à Internet : Filtrer sur l’adresse IP du client et, par exemple, TCP 443. Si rien n’arrive, la cause se situe avant le pare-feu. Si la requête arrive sans être transférée, vérifier la règle de pare-feu, le NAT et le routage.

Seul Incoming est visible : Rechercher Forwarded, Consumed ou Violation et vérifier que le filtre ne masque pas les étapes suivantes. Dans SFOS 22.0.1 MR1 Build 490, le Known Issue NC-178387 peut faire apparaître les rejets par défaut avec Firewall ID 0 sans ligne Violation Firewall. Selon l’entrée de Known Issues, Sophos prévoit une correction dans la prochaine version de maintenance ; l’entrée ne nomme aucune version ni aucun build précis dont la correction soit confirmée. La disponibilité de MR2 ne prouve donc pas à elle seule la correction. Tant que la correction n’est pas confirmée pour le build utilisé, comparer avec Policy tester ou créer, pour le flux concerné, une règle de rejet explicite avec journalisation à la fin de la liste des règles. Définir précisément les zones source et de destination ; les détails figurent dans Analyser les paquets rejetés sur Sophos Firewall.

Forwarded, mais aucune réponse : Vérifier la route de retour, le NAT, le système cible, le pare-feu local de la cible et l’extrémité distante. Forwarded prouve uniquement que Sophos Firewall a transmis le paquet.

Rule ID ou NAT ID inattendue : Comparer les ID avec Log Viewer et la position de la règle. Ne pas modifier plusieurs règles à la fois ; La règle Sophos Firewall ne correspond pas aide à résoudre les problèmes de correspondance.

DNAT ne fonctionne pas : Vérifier si la requête arrive sur WAN, quelle NAT ID la traite et si elle est transférée vers le serveur interne. Si rien n’apparaît sur WAN, la cause se situe souvent avant le pare-feu. Publier un serveur avec DNAT présente la configuration complète.

Le trafic VPN est absent : Capturer par hôte, réseau ou protocole. Sélectionner l’interface tunnel ou XFRM attendue dans Display Filter si elle y est proposée. Sinon, vérifier les valeurs In/Out interface dans les lignes de paquets. Pour poursuivre l’analyse, consulter Dépannage IPsec sur Sophos Firewall.

Le filtre web bloque de façon inattendue : Packet Capture montre le flux, mais pas la décision complète de Web, Application Control ou SSL/TLS. La vérifier dans le module Log Viewer approprié.

Les petits tests fonctionnent, mais les transferts volumineux se bloquent : Dans WebAdmin, surveiller les réponses manquantes et la taille des paquets. Les retransmissions peuvent être analysées de manière fiable avec un fichier PCAP dans Wireshark. Vérifier aussi MTU et MSS.

Packet Capture ne démarre pas : Vérifier d’abord si la nouvelle fenêtre du navigateur peut s’ouvrir. Avant d’utiliser Clear ou de redémarrer un service, enregistrer les lignes de diagnostic nécessaires avec l’heure du test, le flux, les interfaces, Rule ID et NAT ID, par exemple sous forme de capture d’écran ou de texte copié ; respecter les consignes de confidentialité ci-dessous. Clear supprime les détails des paquets capturés jusque-là.

Le service Packet capture and Live connections est partagé par Packet Capture et Live Connections. Un redémarrage interrompt aussi temporairement l’affichage Live Connections et peut affecter les captures de diagnostic en cours. Avant de redémarrer, se coordonner donc avec les autres administrateurs ou membres du support qui utilisent actuellement ces fonctions de diagnostic et obtenir l’accord de la personne responsable.

1. Après avoir enregistré les lignes nécessaires, vider le tampon avec Clear et vérifier à nouveau si Packet Capture démarre.
2. Si le problème persiste, redémarrer une seule fois le service Packet capture and Live connections sous System services > Services.
3. Définir ensuite un Capture Filter précis pour le flux de test connu, activer Trace On et reproduire exactement un test court. Actualiser les détails des paquets et vérifier si de nouvelles lignes de paquets correspondantes apparaissent ; actualiser également l’affichage Live Connections et vérifier s’il se charge à nouveau.
4. Pour terminer, régler Packet Capture sur Trace Off. Si Packet Capture ou l’affichage Live Connections reste indisponible, ne pas répéter les redémarrages, mais transmettre le cas au support avec la version et le build de SFOS, l’heure de l’erreur, les filtres et les observations enregistrées.

Confidentialité et passage à tcpdump

Les données de capture peuvent contenir des adresses IP internes, des noms d’hôte, des noms d’utilisateur, des relations de communication et, avec des protocoles non chiffrés, des données utiles. Avant de les partager, vérifier le destinataire, l’étendue et la conservation ; quelques lignes pertinentes suffisent souvent au lieu de la capture complète.

Pour des captures plus longues, une interface précise, un nombre fixe de paquets, Snap Length ou un fichier .pcap, utiliser tcpdump sur Sophos Firewall. Transférer ensuite le fichier de manière sécurisée et le supprimer du pare-feu.