Wireshark, capturer et lire des trames réseau avec filtres et TLS

Wireshark, capturer et lire des trames réseau avec filtres et TLS

Wireshark enregistre ce qui passe réellement sur une interface réseau et le décode protocole par protocole, de la trame Ethernet jusqu’à la requête applicative. C’est l’outil qui remplace « normalement ça devrait marcher » par ce qui a effectivement circulé sur le fil. Cette fiche couvre ce qu’il montre, ce qu’il ne montrera jamais, où se placer pour capturer, et ce que la loi dit de l’écoute.

Explication de la marmotte

Wireshark ressemble à un agent posté au bord d’une route, qui note chaque camion qui passe : d’où il vient, où il va, sa taille, l’heure. Si la remorque est bâchée, impossible de voir la marchandise, mais le carnet reste précieux pour comprendre un embouteillage ou reconstituer ce qui s’est passé après un accident.

→ Lire l’explication complète de la marmotte

À quoi sert Wireshark, qui l’édite et sous quelle licence

Wireshark est un analyseur de protocoles réseau. Il fait deux choses distinctes : capturer (copier dans un fichier les trames vues par une interface) et disséquer (décoder chaque trame selon les protocoles qu’elle transporte). La seconde fonction marche très bien sans la première : on peut ouvrir un fichier capturé ailleurs, par un autre outil, sur une machine sans écran.

Le projet est porté par la Wireshark Foundation, organisation à but non lucratif, et développé par une communauté de contributeurs. Il descend d’Ethereal, renommé pour une question de marque. Le code est publié sous GNU GPL (General Public License) version 2 ou ultérieure. Il tourne sur Linux, Windows et macOS.

Prérequis de plateforme : la capture s’appuie sur libpcap sous Linux et macOS, sur le pilote Npcap sous Windows. Elle exige des privilèges sur l’interface. Le paquet fournit plusieurs programmes, qu’il vaut mieux connaître par leur nom :

• wireshark, l’interface graphique ;
• tshark, le même moteur de dissection en ligne de commande ;
• dumpcap, le petit programme qui se contente de capturer et d’écrire ;
• editcap et mergecap, pour découper, convertir et fusionner des fichiers.

Deux formats de fichier coexistent. Le format pcap (packet capture) est l’ancien : un en-tête, puis des paquets horodatés, lisible par tout l’écosystème. Le format pcapng (pcap next generation) est celui que Wireshark écrit par défaut : plusieurs interfaces dans un même fichier, commentaires, métadonnées, et même les secrets de déchiffrement embarqués. Ce dernier point est un piège, détaillé plus bas.

Quand sortir Wireshark, et quand le laisser au placard

On sort Wireshark quand deux équipes se renvoient un problème et que les journaux applicatifs ne départagent personne. La capture répond à des questions fermées : le paquet est-il parti, est-il arrivé, qui a coupé la connexion, combien de temps le serveur a-t-il mis à répondre. L’expérience montre que « c’est le réseau » et « c’est l’appli » sont deux hypothèses de force égale tant que personne n’a regardé les trames.

Le compromis central est là : la capture donne la vérité du fil, et rien d’autre. Elle coûte un accès à un point d’écoute, du stockage, et un risque juridique, puisqu’un fichier de capture est un concentré de données personnelles et parfois de secrets. La position défendue ici : capturer court, filtré, sur un périmètre autorisé, et commencer par les métriques et les journaux quand ils existent. Wireshark est un instrument de preuve, pas un tableau de bord.

Il ne remplace pas non plus la découverte active. Pour savoir quels ports écoutent sur une machine, on interroge avec Nmap ; Wireshark, lui, ne voit que ce qui circule spontanément. Les deux se complètent : lancer un scan et le regarder passer dans une capture reste le meilleur moyen de comprendre ce que fait un scanner. Les autres fiches sont dans la rubrique Outils.

Où se placer pour capturer : sa machine, port miroir ou TAP

Une capture ne vaut que par son point d’écoute. Sur un réseau commuté, le commutateur apprend quelle adresse MAC (Media Access Control) se trouve derrière quel port et ne délivre une trame qu’au port du destinataire. Une machine quelconque ne reçoit donc que son propre trafic, les diffusions (les requêtes ARP, Address Resolution Protocol, par exemple), le multicast, et les rares trames dont le commutateur ne connaît pas encore le destinataire. Le mode promiscuité, qui demande à la carte d’accepter les trames destinées à d’autres, n’y change rien : on ne peut pas accepter ce qu’on ne reçoit pas. Le mécanisme de commutation est détaillé dans la page Ethernet, trames et commutation.

Trois placements légitimes existent :

• Sa propre machine : immédiat, suffisant pour diagnostiquer un client ou un serveur. Attention à deux artefacts. Quand le calcul des sommes de contrôle est délégué à la carte réseau, les paquets sortants apparaissent avec une somme fausse, puisque la capture les voit avant la carte. Quand la segmentation est déléguée de la même façon, on voit des segments énormes qui n’ont jamais existé sous cette forme sur le câble. Ni l’un ni l’autre n’est une panne.
• Port miroir, ou SPAN (Switched Port Analyzer) : le commutateur recopie le trafic d’un port ou d’un réseau virtuel vers un port d’écoute. Gratuit et configurable à distance, mais le commutateur sacrifie la copie dès qu’il est chargé, sans prévenir, et les trames erronées ne sont en général pas recopiées. Une capture miroir sans perte apparente ne prouve pas l’absence de perte.
• TAP (Test Access Point) : un boîtier inséré physiquement sur le lien, qui duplique le signal. Il voit tout, erreurs comprises, et ne dépend pas de la bonne volonté du commutateur. Il impose une coupure du lien à la pose et un passage en salle.

La topologie ci-dessous montre le cas du port miroir : la sonde ne participe pas à l’échange, elle reçoit une copie du lien montant.

Règle de choix : pour un diagnostic ponctuel, le port miroir suffit ; pour une preuve ou une mesure de performance, le TAP. Sur du Wi-Fi, voir le trafic des autres demande un mode de surveillance spécifique de la carte et, sur un réseau protégé, les clés.

Filtres de capture BPF et filtres d’affichage : deux syntaxes, deux moments

C’est la confusion la plus fréquente, et l’interface n’aide pas : deux champs de saisie, deux langages qui ne se ressemblent pas.

Le filtre de capture s’écrit en syntaxe BPF (Berkeley Packet Filter) et s’applique avant l’enregistrement, dans le noyau. Ce qui ne passe pas le filtre n’est jamais écrit, et ne sera jamais récupérable. Le filtre d’affichage utilise la syntaxe propre à Wireshark, s’applique après, sur des paquets déjà disséqués, et ne détruit rien : il masque.

Ce qu’il faut y lire : la seule étape irréversible est la deuxième.

	Filtre de capture	Filtre d’affichage
Syntaxe	BPF : host 192.0.2.10 and tcp port 443	Wireshark : ip.addr == 192.0.2.10 && tcp.port == 443
Moment	avant écriture	après dissection
Finesse	adresses, ports, protocoles de bas niveau	n’importe quel champ de n’importe quel protocole
Erreur typique	filtrer trop serré et perdre la cause du problème	croire qu’il réduit la taille du fichier

La recommandation : filtre de capture large (une machine, un sous-réseau, sans le trafic d’administration de la session en cours), filtre d’affichage fin. Un filtre de capture limité au port 443 fait disparaître la résolution DNS (Domain Name System) qui a échoué juste avant, et c’est précisément elle qu’on cherchait.

Dissection couche par couche et suivi d’un flux TCP

L’écran principal a trois volets : la liste des paquets, le détail du paquet sélectionné, les octets bruts. Le volet de détail est un arbre qui reproduit l’empilement des protocoles : trame Ethernet, paquet IP (Internet Protocol), segment TCP (Transmission Control Protocol), puis l’application, par exemple HTTP (Hypertext Transfer Protocol). Cliquer sur un champ surligne les octets correspondants. Aucun cours sur le modèle en couches ne vaut dix minutes passées à déplier cet arbre.

Un point de méthode : le dissecteur applicatif est choisi par heuristique, souvent d’après le port. Un service sur un port inhabituel sera mal décodé jusqu’à ce qu’on impose le bon protocole par la fonction « Décoder comme ». Une dissection est une interprétation, pas un fait.

Pour lire une conversation plutôt que des paquets épars, la fonction « Suivre le flux TCP » réassemble les segments dans l’ordre et affiche le dialogue, une couleur par sens. Elle pose au passage un filtre d’affichage du type tcp.stream eq 4, où le numéro est l’index que Wireshark attribue à chaque connexion. Sur un protocole en clair, tout apparaît, mots de passe compris, ce qui règle en général le débat sur l’intérêt de chiffrer.

Les filtres d’analyse rendent le diagnostic rapide : tcp.analysis.retransmission isole les retransmissions, tcp.flags.reset == 1 montre qui a fermé brutalement. Une retransmission vue au point de capture indique une perte en aval de ce point, du segment ou de son acquittement ; son absence ne dit rien de l’amont.

Ce que TLS cache et ce qu’il laisse voir dans une capture

TLS (Transport Layer Security) chiffre le contenu de la session : requêtes, réponses, en-têtes, cookies. Le fonctionnement du protocole est traité dans la page TLS expliqué. Vu depuis Wireshark, le chiffrement n’est pas un voile opaque, c’est une bâche. Restent lisibles :

• les adresses IP source et destination, les ports ;
• les horaires, les volumes, la taille et le rythme des échanges ;
• le nom du serveur demandé, transmis dans l’extension SNI (Server Name Indication) du premier message du client, tant qu’elle n’est pas chiffrée par ECH (Encrypted Client Hello) ;
• les versions et suites cryptographiques proposées ;
• le certificat du serveur jusqu’à TLS 1.2 (il est chiffré à partir de TLS 1.3) ;
• les requêtes DNS qui précèdent, si elles circulent en clair.

Conséquence d’architecture : le chiffrement protège le contenu, pas les métadonnées. Savoir qu’un poste a contacté tel service, à telle heure, pendant telle durée, suffit souvent à un attaquant comme à un enquêteur. La confidentialité des métadonnées doit venir d’ailleurs (tunnel, résolution DNS chiffrée, ECH), et aucune de ces mesures ne masque les volumes ni les horaires.

Autre règle à retenir : avec un échange de clés éphémère, systématique en TLS 1.3, posséder la clé privée du serveur ne permet pas de déchiffrer une capture. L’ancienne méthode consistant à charger cette clé dans Wireshark ne fonctionne plus que sur des configurations qu’il faudrait de toute façon retirer.

Exemple : capturer avec tshark et déchiffrer son propre trafic TLS

Les commandes suivantes couvrent le cycle complet. tshark partage les dissecteurs et les filtres de l’interface graphique ; c’est lui qu’on utilise sur un serveur.

# Lister les interfaces disponibles pour la capture
tshark -D

# Capturer sur eth0, filtre de capture BPF, écriture dans un fichier pcapng
tshark -i eth0 -f "host 192.0.2.10 and tcp port 443" -w capture.pcapng

# Relire le fichier avec un filtre d'affichage : les retransmissions TCP
tshark -r capture.pcapng -Y "tcp.analysis.retransmission"

# Extraire deux champs : adresse de destination et nom de serveur (SNI)
tshark -r capture.pcapng -Y "tls.handshake.type == 1" \
  -T fields -e ip.dst -e tls.handshake.extensions_server_name

Pour une capture longue, dumpcap écrit en tampon circulaire : les fichiers les plus anciens sont écrasés, le disque ne se remplit pas.

# 20 fichiers d'environ 100 Mo chacun (filesize est exprimé en kilo-octets)
dumpcap -i eth0 -b filesize:100000 -b files:20 -w tampon.pcapng

Reste le déchiffrement. La méthode qui fonctionne avec toutes les versions de TLS repose sur un journal de clés de session : quand la variable d’environnement SSLKEYLOGFILE est définie, les clients qui la prennent en charge (Firefox, les navigateurs basés sur Chromium, curl selon sa compilation) écrivent dans ce fichier les secrets de chaque session. Wireshark les relit et déchiffre.

Le schéma montre la dépendance : sans coopération du client, pas de secrets, donc pas de déchiffrement. C’est son propre trafic qu’on déchiffre, pas celui du voisin.

# Terminal 1 : capturer
tshark -i eth0 -f "tcp port 443" -w tls.pcapng

# Terminal 2 : générer du trafic en journalisant les secrets de session
SSLKEYLOGFILE="$HOME/cles-tls.log" curl -s -o /dev/null https://example.org/

# Relire la capture en fournissant le journal de clés
tshark -r tls.pcapng -o tls.keylog_file:"$HOME/cles-tls.log" -Y "http or http2"

Dans l’interface graphique, le même fichier se renseigne dans les préférences du protocole TLS. Conditions d’exploitation : ce journal vaut le clair de toutes les sessions qu’il couvre. Il se protège comme un secret, se supprime après usage, et la variable ne reste jamais définie dans un profil utilisateur ou un service de production. Variante du même piège : editcap sait injecter ces secrets dans un fichier pcapng, qui devient alors déchiffrable par quiconque le reçoit. Avant de transmettre une capture à un tiers, vérifier ce qu’elle embarque.

Limites de Wireshark et surface d’attaque de l’outil

Ce que Wireshark ne garantit pas :

• L’exhaustivité. Il montre ce que l’interface a reçu et que le système a eu le temps de copier. Sous forte charge, des paquets sont perdus à la capture ; les statistiques de fin de capture le signalent, encore faut-il les lire.
• Le passage à l’échelle. L’interface graphique charge le fichier en mémoire avec l’état de dissection. Au-delà de quelques centaines de mégaoctets, on capture avec dumpcap, on découpe avec editcap, on trie avec tshark, et on n’ouvre dans l’interface que l’extrait qui compte.
• Le sens. L’outil signale une retransmission, pas sa cause. Les couleurs alarmantes de la liste sont des indices ; un réseau sain en produit aussi.
• L’activité locale. Ce qui ne passe pas par l’interface écoutée (communication interne à la machine, autre carte, tunnel observé du mauvais côté) n’existe pas dans la capture.
• L’horodatage absolu. Les heures sont celles de la machine de capture. Sans synchronisation d’horloge, corréler deux captures ou une capture et un journal devient un exercice de divination.

La surface d’attaque, elle, est rarement évoquée. Wireshark embarque des dissecteurs pour des milliers de protocoles, écrits en C, dont le métier consiste à analyser des données fournies par autrui. Des vulnérabilités y sont corrigées régulièrement. D’où trois règles : ne pas lancer l’interface avec les droits d’administration (la capture se délègue à dumpcap, auquel on accorde les seuls privilèges nécessaires, typiquement par un groupe dédié), tenir l’outil à jour, et ouvrir une capture d’origine douteuse sur une machine isolée. Un outil d’analyse de sécurité tournant en administrateur sur le poste de l’analyste, c’est une cible de choix avec un badge d’accès.

Le fichier de capture est le second risque. Il contient identifiants, jetons de session, contenus en clair et données personnelles. Chiffrement au repos, accès restreint, durée de conservation décidée avant la capture, suppression vérifiée après.

Usage défensif, écoute passive et détection

Côté défense, la capture sert trois usages. Le diagnostic, déjà évoqué. La vérification : rien ne vaut une capture pour constater qu’un flux réputé chiffré part en clair, qu’un mot de passe transite en clair dans un protocole d’annuaire, ou qu’une vieille version de protocole est encore négociée. La preuve après incident : une capture horodatée, à l’intégrité protégée, établit ce qui est sorti et vers où. Pour qu’elle tienne devant un tiers, la méthode compte autant que le contenu (empreinte du fichier, chaîne de conservation, horloge) ; le sujet est traité dans le guide préparer une capture réseau qui vaille preuve.

Côté attaque, l’écoute est passive : l’interface reçoit, elle n’émet rien. Aucun paquet ne trahit sa présence. La détection est donc indirecte :

• sur une machine : interface passée en mode promiscuité (visible dans l’état de l’interface et dans les journaux du noyau), processus de capture en cours, installation d’un pilote de capture sur un poste qui n’en a aucun besoin ;
• sur le réseau : port miroir que personne ne se rappelle avoir configuré, d’où l’intérêt d’auditer la configuration des commutateurs ; boîtier inconnu sur un lien, d’où l’intérêt de contrôler l’accès physique.

Un attaquant qui veut voir davantage que son propre trafic sur un réseau commuté doit devenir actif (usurper des réponses ARP, saturer la table d’un commutateur), et là il fait du bruit, donc il se détecte. La contre-mesure de fond ne consiste pas à traquer les oreilles : elle consiste à supposer qu’elles existent et à chiffrer tout ce qui circule, y compris en interne. Le « réseau de confiance » est une catégorie administrative, pas une propriété physique.

Cadre légal de l’interception en France

Capturer du trafic, c’est potentiellement intercepter des correspondances et traiter des données personnelles. Trois textes encadrent la pratique ; ils se lisent à la source, sur Légifrance.

• Secret des correspondances : l’article 226-15 du code pénal punit d’un an d’emprisonnement et de 45 000 euros d’amende le fait, commis de mauvaise foi, d’intercepter, de détourner, d’utiliser ou de divulguer des correspondances émises, transmises ou reçues par la voie électronique, ainsi que l’installation d’appareils permettant ces interceptions.
• Atteintes aux systèmes : les articles 323-1 et suivants du code pénal répriment l’accès et le maintien frauduleux dans un système de traitement automatisé de données. Se brancher sur un réseau sans y être autorisé pour y poser une sonde peut en relever.
• Données personnelles : adresses IP, identifiants et contenus sont des données personnelles au sens du RGPD (Règlement général sur la protection des données). Une capture est un traitement : finalité définie, minimisation, durée de conservation, sécurité.

La règle de conduite tient en une phrase : on n’écoute que ce qu’on a le droit d’écouter. En pratique, un périmètre défini, un accord écrit de celui qui a autorité sur le réseau, une capture filtrée au strict nécessaire, et une durée de conservation fixée d’avance. Être administrateur du réseau donne les moyens techniques de tout lire, pas le droit de le faire. Dire si une capture précise, dans une organisation précise, est licite relève d’un juriste, pas d’une fiche d’outil.

FAQ

Wireshark permet-il de voir le trafic des autres machines du réseau ?

Pas sur un réseau commuté, sauf placement particulier. Une machine ne reçoit que son trafic, les diffusions et le multicast. Voir le reste suppose un port miroir, un TAP, ou une position sur le chemin (passerelle, pare-feu, hyperviseur). Le mode promiscuité seul ne suffit pas.

Peut-on déchiffrer du HTTPS capturé sur le réseau ?

Seulement avec les secrets de session, fournis par l’une des deux extrémités via un journal de clés. Sans eux, le contenu reste illisible, y compris avec la clé privée du serveur dès que l’échange de clés est éphémère. Les métadonnées, elles, restent visibles dans tous les cas.

Faut-il préférer pcap ou pcapng ?

Le format pcapng par défaut : plusieurs interfaces, commentaires, horodatage plus fin. Le format pcap garde un intérêt pour alimenter un outil ancien qui ne lit que lui ; editcap convertit de l’un à l’autre.

Quelle différence entre Wireshark et tshark ?

Le moteur est le même, seule l’interface change. tshark s’utilise sur un serveur sans écran, dans un script, ou pour extraire des champs en masse. L’interface graphique sert à explorer un extrait de taille raisonnable.

🐝 Ce qui arrive si on s’en passe

Sans capacité de capture, un incident réseau se règle par hypothèses : chaque équipe lit ses propres journaux, lesquels ne décrivent que ce que chaque logiciel croit avoir envoyé ou reçu. Une coupure imposée par un équipement intermédiaire, une réponse qui arrive trop tard, un paquet modifié en chemin restent invisibles, puisqu’aucun des deux bouts ne les a journalisés. Après une intrusion, l’absence de trames enregistrées interdit de dire ce qui est sorti, vers quelle adresse et en quelle quantité : il ne reste que les déclarations des systèmes compromis, donc de témoins peu fiables. Enfin, personne ne vérifie qu’un flux annoncé comme chiffré l’est réellement, et les protocoles en clair survivent des années dans des schémas d’architecture qui affirment le contraire.

🦫 Explication de la marmotte 🍫

Quand deux ordinateurs échangent, les données voyagent en petits morceaux, chacun portant l’adresse de l’expéditeur, celle du destinataire et un bout du message. Wireshark recopie ces morceaux dans un fichier au moment où ils traversent la carte réseau, puis les décode étage par étage : d’abord l’enveloppe du réseau local, puis les adresses, puis la conversation, enfin le message de l’application. Deux tris existent. Le premier agit pendant l’enregistrement : ce qu’il écarte est perdu pour de bon. Le second agit à la lecture : il masque sans rien effacer. L’outil ne voit que ce qui arrive jusqu’à sa carte ; or l’équipement qui relie les machines d’un réseau ne remet chaque morceau qu’à son destinataire. Pour observer d’autres machines, il faut donc demander à cet équipement une copie, ou brancher un boîtier sur le câble. Quand la conversation est chiffrée, le message devient illisible, mais les adresses, les heures, les quantités et souvent le nom du site restent visibles. On ne peut lire le contenu que si l’un des deux ordinateurs fournit les clés de la session, ce qui limite l’opération à son propre trafic. Écouter ne produit aucun signal, donc se repère mal. Et écouter un réseau sans autorisation est puni par la loi.

À lire aussi

• Kali Linux pour les tests d'intrusion, usages, limites et détectionKali Linux est une distribution Debian d'OffSec pour les tests d'intrusion, avec ses usages, ses limites, sa détection sur un réseau et son cadre légal.
• Captures, observabilité et diagnostic multi-coucheFournir une méthode de dépannage structurée, du câble à l’application, avec outils système, captures paquet, logs, flux, géolocalisation et investigation.
• Configurer Suricata sur un segment réseau critiqueGuide pas-à-pas pour déployer Suricata en écoute ou en coupure, charger ET Open, réduire le bruit et valider une première règle personnalisée.
• Suivre un flux de bout en boutApprendre à raconter un échange complet depuis une action utilisateur jusqu’au service distant, en distinguant nom, adresse, chemin, transport, chiffrement et réponse applicative.

Pages voisines

La citent

• Kali Linux pour les tests d'intrusion, usages, limites et détection
• Analyse mémoire et réseau après un incident
• Google Street View Wi-Spy 2010 : trames Wi-Fi en clair et droit
• Sécuriser un canal: TLS, HTTPS et mTLS

Wireshark, capturer et lire des trames réseau avec filtres et TLS

Elle cite

• ⇄Lien dans les deux sens :Couches, normes et vocabulaire de paquets
• ⇄Lien dans les deux sens :Préparer la capture réseau pour des preuves légales
• Nmap pour cartographier un réseau, des hôtes aux services exposés
• Attaque de l'intercepteur par ARP, DHCP, DNS, Wi-Fi et proxy TLS
• Chiffrer les flux est-ouest dans un data center
• Comprendre TLS : mécanismes, garanties et limites
• DNSSEC, DoH, DoT, ODoH et perte de visibilité pour la défense
• Ethernet, trames et commutation locale

⇄ : les deux pages se citent l’une l’autre.