Sur un poste Windows, quand un superviseur tombe à l’orange et que personne ne sait si le problème vient du switch, du firewall ou d’un client trop bavard, disposer d’un sniffer réseau fiable fait la différence entre une matinée perdue et un diagnostic posé en dix minutes. Historiquement, TCPdump règne côté Unix, mais côté Windows le terrain est plus éclaté : ports non officiels, drivers de capture, WSL, outils graphiques. L’enjeu n’est pas de tout connaître, mais de choisir une chaîne simple qui permet une capture de paquets propre, reproductible et partageable avec l’équipe. Pour une PME industrielle, un bureau d’étude ou un homelab sérieux, la combinaison TCPdump + quelques alternatives gratuites comme Wireshark ou Nmap couvre déjà 95 % des cas d’analyse réseau.
Imaginons Lucas, responsable IT d’une usine qui a migré son MES sur une VM Windows. Une fois par semaine, certains postes de production décrochent. Les logs applicatifs ne disent rien, le fournisseur évoque « le réseau ». Lucas a besoin d’un outil CLI pour capturer précisément ce qui transite sur l’interface de la VM, envoyer un fichier .pcap au support, et en parallèle vérifier lui-même via une interface graphique. Il va installer TCPdump sous Windows, mémoriser quelques commandes utiles ciblées, puis garder sous le coude deux ou trois outils complémentaires gratuits. Le but n’est pas de devenir analyste SOC, mais d’outiller la discussion : « voici la capture sur 10 minutes, voici les timeouts TCP, voici la résolution DNS qui part en vrille ».
En bref
- TCPdump sur Windows se déploie sans douleur à condition d’installer d’abord un driver de capture type Npcap en mode compatible WinPcap.
- Deux voies pratiques coexistent : un binaire TCPdump natif pour Windows, ou l’utilisation de Windows Subsystem for Linux (WSL) pour retrouver l’expérience Linux classique.
- Quelques commandes utiles suffisent pour démarrer : lister les interfaces, filtrer par IP ou port, écrire un fichier .pcap et le relire dans Wireshark.
- Pour aller plus loin, plusieurs alternatives gratuites complètent bien TCPdump : Wireshark, Tshark, Nmap, tcpflow, dumpcap, voire des outils graphiques orientés Windows.
- Sur un poste de prod ou une VM critique, l’objectif est clair : une chaîne de capture standardisée, documentée, que plusieurs personnes peuvent réutiliser sans bricolage.
Installer TCPdump sur Windows sans transformer la machine en labo
Sur Windows, TCPdump ne vient pas avec le système, contrairement à beaucoup de distributions Linux. Il faut donc assembler trois briques : un driver pour accéder aux interfaces réseau, un exécutable TCPdump compatible, et un environnement de ligne de commande propre (PowerShell ou WSL). La bonne nouvelle, c’est que tout cela reste gratuit et stable depuis plusieurs années.
Pour des postes de production ou des serveurs applicatifs, la stratégie raisonnable consiste à privilégier des composants maintenus et bien documentés. C’est pour cette raison qu’en 2026, le duo Npcap + binaire TCPdump ou Npcap + WSL reste la voie la plus saine. Les anciennes piles type WinPcap tiennent encore la route sur un parc figé, mais leur absence d’évolution les rend moins intéressantes pour de nouvelles installations.
Préparer Windows pour la capture de paquets avec Npcap
La première marche consiste à doter Windows d’un moteur de capture. Par défaut, Windows ne fournit pas l’équivalent de libpcap. Npcap joue ce rôle et expose une API compatible WinPcap, ce qui permet à TCPdump de fonctionner sans réécriture du code source côté application.
Sur un parc géré, ces quelques points méritent d’être systématisés dans une procédure interne :
- Vérifier le système cible (Windows 10 ou 11 de préférence, édition serveur ou poste).
- Prévoir des droits administrateur pour l’installation de Npcap.
- Documenter les options choisies lors de l’installation pour pouvoir les reproduire.
Une fois ces garde-fous posés, la mise en place devient un geste banal, au même titre que l’installation d’un agent de supervision.
Installer TCPdump pour Windows ou passer par WSL
Le choix entre un binaire TCPdump natif Windows et TCPdump dans WSL dépend surtout du profil de l’équipe. Des administrateurs habitués à Linux auront tendance à privilégier WSL pour retrouver leurs repères, tandis que des équipes Windows-only préféreront un exécutable unique posé dans C:tcpdump.
Dans les deux cas, le point clé reste identique : s’assurer que l’outil voit bien les interfaces fournies par Npcap et que la syntaxe des commandes reste alignée avec ce qui est utilisé sur les serveurs Linux de référence. Cela évite les surprises quand on compare des captures issues de deux environnements différents.
Npcap, WinPcap, WSL : choisir un socle propre pour TCPdump
Avant même de taper « tcpdump -i », il faut trancher sur la manière dont Windows va exposer le trafic aux outils d’analyse réseau. Le trio le plus courant réunit Npcap, les anciens binaires WinPcap et l’option Windows Subsystem for Linux. Chacun a ses avantages, mais ils n’ont pas le même avenir.
Pour un SI vivant, qui évolue encore, il est difficile de recommander autre chose que Npcap et WSL. L’un apporte un driver de capture soutenu par une communauté active, l’autre donne accès à tout l’écosystème Linux (dont TCPdump, mais aussi tshark, Nmap, etc.). Les binaires historiques WinPcap, eux, rendent surtout service dans des contextes figés ou certifiés, où l’on ne touche à rien tant que ça tourne.
Npcap vs WinPcap et rôle de WSL dans une stack Windows moderne
Npcap a pris la relève de WinPcap, qui n’est plus vraiment mis à jour. Sur des chaînes de production reliées à Internet, continuer à installer WinPcap sur de nouveaux postes n’a plus beaucoup de sens. Les correctifs de sécurité et la compatibilité avec les versions récentes de Windows jouent clairement en faveur de Npcap.
WSL apporte une couche supplémentaire intéressante. Au lieu de chercher un binaire TCPdump spécifique pour chaque version de Windows, on installe une distribution Linux (Ubuntu, Debian, etc.) et l’on retrouve le traditionnel « apt install tcpdump ». Pour les équipes mixtes IT/OT qui jonglent déjà entre Linux et Windows, cette homogénéité vaut de l’or.
| Option | Type | Maintenance | Cas d’usage conseillé | Remarque terrain |
|---|---|---|---|---|
| Npcap | Driver de capture | Active | Nouvelles installations TCPdump/Wireshark sur Windows 10/11 | Mode compatible WinPcap à activer pour les outils anciens |
| WinPcap | Driver de capture | Figée | Environnements hérités non connectés, applis très anciennes | À éviter pour de nouveaux déploiements |
| WSL | Compatibilité Linux | Active | Admins habitués à Linux, scripts communs Linux/Windows | Permet d’utiliser apt, tcpdump, Nmap, tshark sans portage |
Commandes TCPdump utiles sur Windows pour diagnostiquer vite
Une fois TCPdump opérationnel, le piège classique consiste à tester dix options différentes sur un incident, puis à ne plus se souvenir de ce qui a vraiment servi. Pour garder l’outil efficace, mieux vaut se limiter à un noyau de commandes utiles qui couvrent les scénarios les plus fréquents : vérifier que ça cause, filtrer par IP, filtrer par port, écrire un fichier lisible par Wireshark.
Dans plusieurs ateliers avec des équipes mixtes, la même constatation revient : quatre ou cinq lignes bien maîtrisées remplacent sans problème une page A4 de mémo. Au final, ce qui compte, c’est de pouvoir rejouer exactement la même capture deux semaines plus tard, au moment où le fournisseur revient vers vous.
Lister les interfaces et lancer une capture ciblée
Sur Windows comme sur Linux, la première chose à faire est de connaître le nom des interfaces visibles par TCPdump. Sans cette étape, on risque de capturer sur la mauvaise carte ou de passer à côté d’un VLAN.
Les commandes de base à garder sous la main sont par exemple :
Exemples concrets (syntaxe classique TCPdump, à adapter au contexte Windows/WSL) :
- Lister les interfaces :
tcpdump -Dpour afficher les interfaces disponibles et leurs identifiants. - Capturer sur une interface donnée :
tcpdump -i 2si l’interface utile est la n°2 dans la liste. - Limiter la verbosité : ajouter
-npour ne pas résoudre DNS et afficher les IP brutes, ce qui évite du bruit en cas de souci de résolution.
Une équipe qui documente simplement « pour la VM MES, utiliser l’interface 2 et l’option -n » se donne déjà une base commune pour toutes les futures analyses.
Filtrer par IP, port ou protocole et écrire un .pcap exploitable
La vraie puissance de TCPdump vient de son langage de filtres. Sur une machine bruyante, lancer une capture sans filtre revient à chercher une vis tombée par terre dans un atelier en pleine production. Pour un incident donné, mieux vaut délimiter le champ d’observation dès le départ.
Quelques patterns reviennent constamment en production :
Filtres typiques pour analyse réseau sous pression :
- Filtrer sur une IP distante :
tcpdump -i 2 host 192.168.10.25pour se concentrer sur un automate ou un serveur particulier. - Filtrer sur un port applicatif :
tcpdump -i 2 port 502pour le Modbus/TCP, ouport 443pour du HTTPS. - Filtrer sur un protocole :
tcpdump -i 2 tcpouudpselon la pile étudiée. - Écrire dans un fichier :
tcpdump -i 2 -w incident-mes.pcappour ouvrir ensuite le fichier dans Wireshark.
Sur le terrain, une bonne habitude consiste à nommer les fichiers .pcap avec la date, le système concerné et le type d’incident. On gagne un temps précieux au moment de croiser les captures avec les journaux applicatifs.
Alternatives gratuites à TCPdump sur Windows pour compléter la boîte à outils
TCPdump reste un couteau de précision, mais tout le monde n’a pas forcément envie de lire des paquets hexadécimaux dans un terminal. D’autres outils gratuits viennent le compléter, soit pour offrir une interface graphique, soit pour automatiser des tests, soit pour tracer les flux d’une manière plus visuelle. L’idée n’est pas de remplacer TCPdump, mais de l’inscrire dans une panoplie cohérente.
Le trio le plus utilisé en complément sur Windows réunit Wireshark, Tshark et Nmap. Le premier brille pour l’analyse détaillée, le second pour les scripts, le troisième pour explorer la surface d’attaque réseau et vérifier rapidement les ports réellement ouverts. Autour de ce noyau gravitent quelques outils plus spécialisés, comme tcpflow ou dumpcap.
Wireshark, Tshark, Nmap, tcpflow et dumpcap : quand les utiliser
Wireshark est souvent la porte d’entrée. Une fois le fichier .pcap obtenu avec TCPdump, l’ingénieur ou le support l’ouvre dans cette interface graphique, applique des filtres d’affichage, suit un flux TCP, reconstruit une session HTTP. Pour un débogage applicatif, ce confort visuel fait gagner des heures, surtout pour ceux qui ne vivent pas dans le terminal au quotidien.
Tshark reprend le moteur d’analyse de Wireshark mais en ligne de commande. Il se prête bien aux pipelines automatisés : captures périodiques, filtrage côté serveur, export en CSV de champs bien précis pour corréler avec d’autres métriques. Nmap, de son côté, ne sert pas à capturer des paquets, mais à scanner un réseau, dresser l’inventaire des services exposés et vérifier la cohérence entre ce que la DSI pense avoir ouvert et ce que le réseau expose vraiment.
Pour certains cas particuliers, tcpflow s’avère très pratique : il reconstruit les flux TCP et facilite l’analyse de protocoles applicatifs simples, par exemple pour inspecter des échanges HTTP sans passer par une interface graphique. Enfin, dumpcap (fourni avec Wireshark) permet de capturer en mode très léger et d’enregistrer les données pour une analyse ultérieure, en laissant le moins de traces possible sur une machine de production.
TCPdump sur Windows nécessite-t-il toujours Npcap ou un driver équivalent ?
Sur Windows, TCPdump ne peut pas accéder directement aux interfaces réseau sans driver intermédiaire. Dans la pratique, il s’appuie sur une bibliothèque de capture compatible libpcap, fournie par des projets comme Npcap ou, historiquement, WinPcap. Pour un nouveau déploiement, Npcap est recommandé, car il reste maintenu et fonctionne en mode compatible WinPcap, ce qui assure le bon fonctionnement de TCPdump et d’autres outils d’analyse réseau comme Wireshark.
Faut-il privilégier un binaire TCPdump Windows ou passer par WSL ?
Les deux options fonctionnent, la décision dépend donc surtout du contexte. Sur un poste d’admin ou une machine de test, WSL apporte l’écosystème Linux complet et simplifie la gestion via apt ou dnf. Sur un serveur applicatif où l’on veut limiter les couches logicielles, un exécutable TCPdump natif Windows posé dans un répertoire dédié reste plus simple à auditer. Dans beaucoup d’équipes, on retrouve d’ailleurs les deux : WSL pour les analyses poussées, un binaire léger pour les captures ponctuelles en prod.
Pourquoi utiliser encore TCPdump si Wireshark est disponible gratuitement ?
TCPdump et Wireshark répondent à des usages complémentaires. TCPdump excelle pour lancer rapidement une capture ciblée, scriptable, avec un impact limité sur la machine, surtout en environnement serveur ou distant. Wireshark, lui, est redoutable pour l’analyse fine, grâce à ses filtres d’affichage, ses graphiques et ses dissectors nombreux. Le schéma le plus robuste consiste souvent à capturer avec TCPdump, puis à analyser les fichiers .pcap avec Wireshark sur un poste dédié.
Peut-on utiliser TCPdump pour déchiffrer du trafic HTTPS ou des VPN ?
TCPdump voit tout ce qui circule sur l’interface, mais ne casse pas le chiffrement par magie. Sur du HTTPS, il affichera des en-têtes et des métadonnées utiles (adresses IP, ports, tailles de paquets, timing), mais la charge utile restera chiffrée. Pour analyser le contenu applicatif, il faut disposer de clés privées, de mécanismes de déchiffrement côté proxy, ou utiliser des approches spécifiques de type SSLKEYLOGFILE selon l’environnement. TCPdump reste néanmoins précieux pour vérifier les handshakes, les timeouts et les erreurs de transport.
Quelles bonnes pratiques adopter pour capturer en production sans perturber le système ?
Sur une machine critique, la prudence s’impose. Il est conseillé de limiter la durée de capture, de filtrer au maximum (par IP, port ou protocole), et d’écrire dans un répertoire disposant de suffisamment d’espace disque. Sur Windows comme ailleurs, éviter de lancer plusieurs outils de capture en parallèle sur la même interface réduit les risques de conflit. Enfin, documenter quelques scénarios de capture standardisés par type d’incident permet aux équipes de gagner du temps sans improviser en situation de crise.