Utiliser tcpdump en sécurité sur Sophos Firewall

tcpdump est l’outil approprié lorsque vous devez examiner de plus près quels paquets arrivent réellement sur le Sophos Firewall, par quelle interface ils passent et si un problème survient avant, sur ou derrière le pare-feu. Il complète Log Viewer, WebAdmin Packet Capture et service logs, mais ne les remplace pas.

Pour des analyses rapides via navigateur, utiliser Sophos Firewall Packet Capture dans WebAdmin est souvent plus pratique. Pour des captures plus longues, des filtres très précis, des fichiers PCAP ou des cas de support, tcpdump via SSH est généralement plus approprié.

⚠️ Important : Les captures de paquets peuvent contenir des données sensibles : adresses IP internes, noms d’hôtes, noms d’utilisateurs, requêtes DNS, détails de certificats ou données utiles non chiffrées. Elles doivent donc être filtrées de manière stricte, enregistrées seulement aussi longtemps que nécessaire, documentées et transmises uniquement par des canaux sécurisés. Une capture non filtrée sur any peut générer beaucoup de données sur des pare-feux en production.

Choix de l’outil et prérequis

Quel article convient ?

tcpdump n’est pas le premier pas pour chaque analyse. Selon la question, un autre point de départ peut être plus rapide :

• Voir rapidement dans WebAdmin si des paquets arrivent, sont transférés ou rejetés : Utiliser Sophos Firewall Packet Capture dans WebAdmin.
• Valider une règle de pare-feu avec Log Viewer, Policy tester et Packet Capture : Tester proprement une règle Sophos Firewall.
• Focus sur Drop, Violation, Rule ID, NAT ID ou raisons de drop : Analyser les paquets rejetés par Sophos Firewall.
• Chercher le fichier log local pour VPN, Web, IPS, GUI ou services système : Associer correctement les service logs Sophos Firewall.
• Préparer SSH ou Advanced Shell : Se connecter à Sophos Firewall via SSH.
• Préparer un cas de support avec archive /log, données IPsec ou debug logs : Sauvegarder les journaux Sophos Firewall pour le support et l’analyse.
• PCAP, longue capture ou filtres CLI très précis nécessaires : cet article.

Cette séparation permet de gagner du temps et de réduire les risques. tcpdump fournit des données de paquets puissantes, mais pas de décision de politique spécifique à Sophos. Rule ID, NAT ID, Drop Reason, Web Policy, IPS ou inspection SSL/TLS doivent être vérifiés en parallèle dans le Log Viewer, le WebAdmin Packet Capture ou dans les fichiers journaux appropriés.

Prérequis

Pour ce guide, vous aurez besoin de :

• Accès administratif au Sophos Firewall.
• Accès SSH au pare-feu ou accès à l’Advanced Shell.
• L’IP source, l’IP de destination, le port de destination et le protocole concerné.
• Suffisamment d’espace libre si un fichier PCAP doit être écrit.
• Wireshark ou un autre outil d’analyse sur le client administrateur si un fichier PCAP doit être évalué.

Comment préparer SSH en toute sécurité est expliqué dans Se connecter à Sophos Firewall via SSH. Pour les bases générales de la CLI, consultez également Dépannage CLI Sophos Firewall : commandes importantes.

Quand tcpdump est-il le bon choix ?

tcpdump ne doit pas être automatiquement le premier choix. Si vous voulez simplement savoir quelle règle de pare-feu, règle NAT, Web Policy ou règle d’inspection SSL/TLS a été appliquée, le Log Viewer est plus rapide et plus lisible. Si vous souhaitez voir dans le navigateur si des paquets individuels arrivent, sont transférés ou rejetés, Packet Capture dans WebAdmin suffit souvent.

tcpdump devient particulièrement utile lorsque l’un de ces points s’applique :

• La capture doit être évaluée en tant que fichier PCAP dans Wireshark ou par le support.
• La capture WebAdmin est trop courte, trop confuse ou le tampon est plein.
• Le test doit durer plus longtemps pendant une fenêtre de maintenance, un appel téléphonique ou une erreur utilisateur reproductible.
• Des filtres CLI précis sont nécessaires, par exemple pour VoIP, DNS, IPsec, plusieurs hôtes ou plages de ports.
• Le trafic pertinent doit être comparé d’abord sur any puis sur une interface spécifique.

Il est important de comprendre que tcpdump montre les paquets, mais pas de décision de Rule ID, NAT ID, Drop Reason ou Web Policy spécifique à Sophos. Ces informations doivent être vérifiées en parallèle via le Log Viewer, le WebAdmin Packet Capture ou les fichiers journaux appropriés.

Advanced Shell ou Device Console ?

tcpdump peut apparaître dans deux contextes CLI sur Sophos Firewall. La Sophos Device Console contient sa propre commande tcpdump avec une syntaxe Sophos et des options comme filedump. L’Advanced Shell fournit en plus le tcpdump proche de Linux, souvent plus pratique pour les cas de support parce que la gestion des processus, scp, /tmp et d’autres outils shell sont disponibles.

Cette distinction est importante :

• Device Console : adaptée à la commande Sophos CLI tcpdump. Avant de l’exécuter, il faut vérifier la syntaxe avec Tab ou ?. Selon Sophos, une sortie créée avec filedump est enregistrée sous /tmp.
• Advanced Shell : adaptée aux workflows shell classiques avec tcpdump, ps, df, grep, scp, accès aux fichiers et arrêt ciblé des processus en cours.

Cet article utilise volontairement l’Advanced Shell, car les fichiers PCAP, les processus en arrière-plan, scp et le nettoyage y sont plus faciles à suivre. Si tcpdump est utilisé dans la Device Console, les mêmes règles de base s’appliquent : filtres précis, fenêtre de capture courte, contrôle de l’espace libre et comparaison du résultat avec Log Viewer ou WebAdmin Packet Capture.

Si vous n’êtes pas sûr de la console dans laquelle vous vous trouvez, consultez Associer correctement les service logs Sophos Firewall.

Préparer la capture

Délimiter avant de commencer

Avant une capture, notez les paramètres d’analyse :

• Source IP : par exemple 172.16.10.25.
• Destination IP : par exemple 198.51.100.20.
• Protocole : par exemple TCP.
• Destination Port : par exemple 443.
• Interface attendue : LAN, WAN ou VPN-Interface.
• Moment du test : heure précise avec fuseau horaire.
• Résultat attendu : connexion autorisée, bloquée, DNAT, SNAT, VPN ou Drop.
• Vérification parallèle : Log Viewer, Packet Capture, service log ou ticket support.

Plus le filtre est précis, meilleur est le résultat. Une capture sans filtre est généralement utile uniquement sur des pare-feux très calmes.

Le test doit être reproductible. Si plusieurs personnes modifient les paramètres en même temps ou si plusieurs clients testent, la capture devient difficile à interpréter. Il est préférable d’avoir un seul client de test, un cadre temporel restreint et une question claire : le paquet arrive-t-il ? Sort-il ? La réponse revient-elle ? Quelle règle, règle NAT ou policy était visible en parallèle ?

Pour les tests de règles, consultez également Tester une règle Sophos Firewall avec Log Viewer et Packet Capture. Si l’accent est mis sur Drop, Violation, Rule ID ou NAT ID, Analyser les paquets rejetés par Sophos Firewall est l’article de suivi approprié.

Exécuter tcpdump

Exécuter tcpdump en direct

Pour un premier contrôle en direct, un filtre d’hôte suffit souvent :

tcpdump -i any -nn host 198.51.100.20

Les paramètres :

• -i any : capturer sur toutes les interfaces.
• -nn : ne pas effectuer de résolution de noms DNS ou de ports.
• host 198.51.100.20 : afficher uniquement les paquets de ou vers cette IP.

Pour un test Web, un filtre de port supplémentaire est utile :

tcpdump -i any -nn 'host 198.51.100.20 and port 443'

Les expressions de filtre avec and, or ou not doivent être placées entre guillemets simples. Cela permet de garder l’expression intacte et de ne pas la faire décomposer par le shell.

Exemples de filtres fréquents

• Hôte spécifique : tcpdump -i any -nn 'host 198.51.100.20'
• IP source spécifique : tcpdump -i any -nn 'src host 172.16.10.25'
• IP de destination spécifique : tcpdump -i any -nn 'dst host 198.51.100.20'
• Réseau spécifique : tcpdump -i any -nn 'net 172.16.10.0/24'
• Port spécifique : tcpdump -i any -nn 'port 443'
• Hôte et port : tcpdump -i any -nn 'host 198.51.100.20 and port 443'
• ICMP / Ping : tcpdump -i any -nn 'proto ICMP'
• DNS : tcpdump -i any -nn 'port 53'
• Tous les ports sauf SSH : tcpdump -i any -nn 'host 198.51.100.20 and port not 22'

Pour les problèmes de VPN, VLAN ou de routage, il peut être utile de ne pas se limiter à any, mais de se concentrer sur une interface spécifique. Les noms d’interface doivent correspondre au pare-feu concerné. En pratique, cette séquence aide souvent :

1. Vérifier brièvement sur any si l’hôte ou le port attendu est visible.
2. Capturer ensuite sur l’interface d’entrée supposée.
3. Capturer ensuite sur l’interface de sortie supposée.
4. Comparer les trois observations avec Log Viewer, NAT ID, Rule ID ou Drop Reason.

On voit ainsi plus vite si le trafic n’atteint pas le pare-feu, s’il est arrêté sur le pare-feu ou si la réponse manque au retour.

Limiter la capture

Une capture doit être limitée pour ne pas durer inutilement longtemps.

Avec -c, tcpdump s’arrête après un nombre fixe de paquets :

tcpdump -i any -nn -c 100 'host 198.51.100.20 and port 443'

Pour des tests courts, c’est souvent plus propre qu’un processus en arrière-plan. Vous démarrez la capture, reproduisez le problème et obtenez automatiquement la sortie par la suite.

Écrire un fichier PCAP

Si la capture doit être analysée plus tard dans Wireshark ou par le support, écrivez un fichier PCAP dans /tmp.

tcpdump -i any -nn -s 0 -w /tmp/sophos-capture.pcap 'host 198.51.100.20 and port 443'

Paramètres importants :

• -s 0 : capturer des paquets complets.
• -w /tmp/sophos-capture.pcap : écrire la sortie dans un fichier PCAP.
• -nn : désactiver la résolution de noms.

-s 0 est utile si une capture complète est nécessaire. En même temps, cela augmente le risque pour la protection des données, car plus de contenu de paquets est capturé. Pour des questions de flux ou d’en-tête uniquement, une capture en direct sans fichier PCAP ou une capture courte avec un filtrage précis suffit souvent.

Avant les captures plus importantes, vérifiez l’espace libre :

df -h /tmp
df -h /var

Si le problème doit être reproduit brièvement, vous pouvez également ajouter -c :

tcpdump -i any -nn -s 0 -c 500 -w /tmp/sophos-capture.pcap 'host 198.51.100.20 and port 443'

Après le démarrage, reproduisez immédiatement le test et ne laissez pas la capture se poursuivre inutilement. Un PCAP contenant cinq minutes de trop est non seulement plus grand, mais contient souvent aussi plus d’informations sensibles.

Pour les cas de support, le nom du fichier doit contenir un contexte neutre, mais aucun nom de client, nom d’utilisateur ou hostname confidentiel. Des noms comme /tmp/ticket-12345-wan-443.pcap ou /tmp/vpn-test-20260629.pcap sont préférables.

Démarrer et arrêter un processus en arrière-plan

Parfois, une capture doit être en cours pendant qu’un autre test est effectué. tcpdump peut alors être démarré en arrière-plan.

tcpdump -i any -nn -s 0 -w /tmp/voip-test.pcap 'host 192.0.2.50 and portrange 5060-5090' &

Afficher les tâches en cours :

jobs

Arrêter une tâche :

kill %1

Si plusieurs processus tcpdump sont en cours ou si la tâche n’est plus visible dans le shell actuel, vérifiez d’abord les processus :

ps | grep tcpdump

Ensuite, terminez le processus approprié. killall tcpdump ne doit être utilisé que si vous êtes sûr qu’aucune autre capture importante n’est en cours.

Après l’arrêt, vérifiez si le fichier PCAP a été écrit et a une taille plausible :

ls -lh /tmp/*.pcap

Si une capture en arrière-plan est planifiée pour un rendez-vous support, il faut déterminer à l’avance qui la démarre, qui l’arrête et où le fichier est ensuite déposé. Une capture oubliée n’est pas un problème de dépannage rare, mais un risque opérationnel évitable.

Exemple : Analyser VoIP ou 3CX

Pour les problèmes de VoIP, la signalisation SIP et le flux média RTP doivent souvent être considérés séparément. Une capture unique sur port 5060 ne montre qu’une partie du problème.

Pour un premier test 3CX, vous pouvez capturer l’hôte PBX :

tcpdump -i any -nn -s 0 -w /tmp/3cx-test.pcap 'host 192.0.2.50'

Si le trafic est trop large, vous pouvez vous concentrer plus précisément sur SIP :

tcpdump -i any -nn -s 0 -w /tmp/3cx-sip.pcap 'host 192.0.2.50 and portrange 5060-5090'

Pour les problèmes audio, le port RTP réellement utilisé doit également être vérifié. Cela dépend du système téléphonique et de sa configuration.

Pour les sujets VoIP sur Sophos Firewall, consultez également Optimiser les paramètres VoIP de Sophos Firewall.

Analyse et nettoyage

Télécharger et nettoyer le fichier PCAP

Un fichier PCAP peut être copié sur un serveur interne via scp :

scp /tmp/sophos-capture.pcap adminuser@192.0.2.10:/tmp/

Selon l’environnement, une autre méthode de transfert sécurisée peut être utilisée. Évitez FTP avec des identifiants enregistrés.

Après un transfert réussi, le fichier doit être supprimé du pare-feu :

rm /tmp/sophos-capture.pcap

Pour des archives de journaux complètes et des cas de support, Sauvegarder les journaux Sophos Firewall pour le support et l’analyse est le guide approprié.

Contexte pour le support ou une analyse externe

Un fichier PCAP sans contexte est difficile à analyser. Pour Sophos Support, Avanet ou un partenaire d’analyse externe, il faut au moins fournir ces informations :

• Fenêtre temporelle : par exemple 2026-06-29, 14:05-14:08 Europe/Zurich.
• Flow attendu : par exemple client 172.16.10.25 vers serveur 198.51.100.20:443.
• Fonction concernée : DNAT, IPsec, SSL VPN, Webfilter, VoIP, DNS ou routing.
• Observation : par exemple SYN visible, pas de SYN-ACK, drop dans le Log Viewer ou pas de réponse de la cible.
• Vérifié en parallèle : Rule ID, NAT ID, Packet Capture et service logs pertinents.
• Changement avant l’erreur : firmware, changement de règle, changement de fournisseur, certificat ou SD-WAN route.

Avant la transmission, il faut vérifier si le fichier contient des noms internes, adresses privées, IP publiques de clients ou données non chiffrées. Si le contenu ne peut pas être anonymisé, les destinataires, le canal de transmission et la conservation doivent être décidés consciemment.

Analyser correctement tcpdump

Lors de l’analyse, il ne s’agit pas seulement de savoir si des paquets sont visibles. Ce qui manque est crucial.

• Aucun paquet visible du client : le problème se situe avant le pare-feu. Vérifier client, VLAN, gateway, switch ou routage vers le pare-feu.
• Les paquets entrent, mais ne sortent pas : vérifier règle de pare-feu, NAT, routage, Security Feature ou Policy.
• Les paquets sortent, mais aucune réponse ne revient : vérifier système cible, route de retour, pare-feu opposé, NAT ou fournisseur.
• Seulement SYN, pas de SYN-ACK : la cible ou le chemin de retour ne répond pas.
• ICMP Request visible, Reply manquant : vérifier route de retour, pare-feu cible ou contrepartie.
• Requête DNS visible, pas de réponse : vérifier serveur DNS, route, règle ou upstream.
• Paquet visible uniquement sur any, mais pas sur l’interface attendue : vérifier hypothèse d’interface, zone, route ou affectation tunnel.
• Paquet visible sur l’interface d’entrée, mais pas sur l’interface de sortie : vérifier règle, NAT, route, Security Feature ou Drop Reason.

tcpdump montre le flux de paquets. La décision de politique elle-même est vérifiée en parallèle dans le Log Viewer. Pour les questions de pare-feu et de NAT, la combinaison du Log Viewer, du Packet Capture et de tcpdump est souvent la plus rapide.

Pour les erreurs NAT, il est important de comprendre que NAT ne fait que traduire le trafic, mais ne l’autorise pas. La base appropriée est Comprendre NAT sur Sophos Firewall : SNAT, DNAT, MASQ, PAT. Pour les tunnels IPsec, consultez également Dépannage VPN IPsec Sophos Firewall et les journaux VPN appropriés.

Erreurs fréquentes et checklist

Erreurs typiques

• Capture sans filtre : trop de données, difficile à analyser. Toujours limiter avec hôte, réseau, port ou protocole.
• Capture non arrêtée : l’espace disque et les performances peuvent en souffrir. Utiliser -c ou arrêter proprement le processus en arrière-plan.
• Seulement any évalué : un problème d’interface ou de tunnel reste invisible. Après le premier hit, comparer ciblé l’interface d’entrée et de sortie.
• Seule la direction aller vérifiée : le problème de retour est ignoré. Considérer les deux directions.
• Mauvaise interface choisie : les paquets pertinents manquent. D’abord any, puis cibler l’interface.
• PCAP partagé sans chiffrement : des données sensibles peuvent être exposées. Utiliser un transfert sécurisé et un groupe de destinataires minimal.
• Fichier laissé après un cas de support : consommation d’espace inutile et risque de données. Supprimer le PCAP après transfert.

Liste de contrôle

• IP source, IP de destination, port et protocole connus.
• Accès SSH au pare-feu configuré en toute sécurité.
• Décidé à l’avance si le Log Viewer ou le WebAdmin Packet Capture suffirait.
• Filtre choisi aussi précisément que possible.
• Capture limitée avec -c ou processus d’arrêt clair.
• Fichier PCAP écrit uniquement si nécessaire.
• Pour les questions d’interface, d’abord any, puis interface d’entrée et de sortie comparées.
• Problème reproduit spécifiquement pendant la capture.
• Heure du test documentée.
• Log Viewer vérifié en parallèle.
• Rule ID, NAT ID, Drop Reason ou service log noté si visible.
• PCAP transféré en toute sécurité.
• Fichier PCAP temporaire supprimé du pare-feu.

FAQ