Les 25 ans de Wireshark : l’e-mail qui a tout lancé et les leçons apprises

• L’e-mail de publication de Ethereal 0.2.0 envoyé par Gerald Combs le 14 juillet 1998 a conduit, 25 ans plus tard, à Wireshark, transformant un outil personnel en projet open source pérenne
• À l’époque, les analyseurs de protocoles avec interface graphique relevaient surtout des produits commerciaux coûteux, et les options gratuites étaient des outils en ligne de commande comme tcpdump ou snoop ; il a donc publié en open source l’analyseur qu’il avait créé lui-même
• Quelques jours après la publication, des patchs ont commencé à arriver et une communauté de développeurs s’est formée ; Wireshark est désormais utilisé pour améliorer les performances, la fiabilité et la sécurité des réseaux, ainsi que pour l’enseignement
• Faire durer un projet nécessite non seulement des utilisateurs, des formateurs et des développeurs, mais aussi un soutien juridique, comptable et en infrastructure ; l’étendue du soutien requis varie selon la taille du projet
• Soutenu au fil du temps par CACE Technology, Riverbed et Sysdig, Wireshark a récemment été transféré à la Wireshark Foundation, se dotant d’une base pour croître de manière indépendante

---

De la publication d’Ethereal aux 25 ans de Wireshark

• Il y a 25 ans, Gerald Combs envoyait un e-mail intitulé ANNOUNCE: Ethereal 0.2.0
  • Ethereal était un analyseur réseau capable de capturer le contenu des trames Ethernet et de les explorer de manière interactive
  • Les données de paquets pouvaient être lues depuis un fichier ou en temps réel depuis une interface réseau locale
  • Il proposait une distribution des sources et des informations supplémentaires, et indiquait que les retours et les patchs étaient les bienvenus
• Le projet ne s’est pas appelé Wireshark dès le départ : il a été renommé Wireshark en 2006
• Au moment de sa publication, les analyseurs de protocoles n’étaient pas courants, et les analyseurs avec interface graphique étaient souvent des produits coûteux
  • Pour examiner l’état du réseau, on pouvait utiliser des outils gratuits en ligne de commande comme tcpdump ou snoop
  • Si l’on avait besoin d’un analyseur graphique, il fallait acheter un produit commercial onéreux
• Faute de disposer de l’analyseur dont il avait besoin pour son travail, Gerald Combs a créé un outil simple lui-même, puis l’a publié en open source

Une croissance portée par la communauté

• Quelques jours après la publication d’Ethereal, le premier patch est arrivé, et les contributions ont continué par la suite
• Parti d’un petit outil, le projet a rencontré une communauté active de développeurs et a grandi bien au-delà des attentes
• Aujourd’hui, Wireshark est utilisé dans le monde entier pour rendre les réseaux plus rapides, plus stables et plus sûrs
• Les formateurs utilisent Wireshark pour enseigner le fonctionnement de bas niveau des réseaux à la prochaine génération d’ingénieurs sécurité et réseau

Ce qu’il faut pour faire durer un projet open source

• Pour qu’un projet open source grandisse et se maintienne, plusieurs catégories de besoins doivent être satisfaites ensemble

• Support aux utilisateurs

  • Les utilisateurs réels vont des habitués expérimentés aux débutants
  • Ils ont parfois besoin d’aide, et les formes de support nécessaires diffèrent selon les cas

• Support aux formateurs

  • Les experts et utilisateurs avancés peuvent apprendre à d’autres à mieux exploiter le projet
  • Les formateurs ont eux aussi besoin d’un soutien continu

• Support aux développeurs

  • Plus il est facile de contribuer du code ou d’améliorer le projet, plus le projet et sa communauté sont en bonne santé

• Support juridique et comptable

  • Les domaines réglementaires, juridiques et financiers, comme le droit de la propriété intellectuelle ou le remboursement de frais de déplacement, nécessitent une aide extérieure
  • GitHub ou GitLab ne suffisent pas à résoudre ces sujets

• Infrastructure

  • Il faut des serveurs, des conteneurs et des services permettant une présence en ligne et la collaboration
  • Le fait que GitHub ou GitLab suffisent dépend des besoins concrets du projet

Une structure de support qui varie selon la taille du projet

• Ces cinq catégories ne correspondent pas exactement à une pyramide de Maslow de l’open source, mais elles ont une structure similaire
• Les frontières entre utilisateurs, formateurs et développeurs peuvent être floues
  • En général, les utilisateurs et les formateurs dépendent de ce que produisent les développeurs
  • Le projet dans son ensemble a besoin d’une infrastructure robuste permettant à tous de collaborer
• Tous les projets n’ont pas besoin du même modèle de support
  • Une petite bibliothèque de traitement d’images à objectif unique peut n’avoir besoin que d’infrastructure et de développeurs
  • Dans ce cas, la communauté d’utilisateurs est probablement elle aussi composée d’autres développeurs, et GitHub ou GitLab peuvent suffire
  • Une grande application d’édition d’images riche en fonctionnalités peut avoir besoin de ressources dans les cinq catégories, ainsi que d’un modèle économique pour les soutenir

Le modèle d’exploitation de Wireshark et le transfert à la Foundation

• Wireshark est un projet proche d’une grande application, qui exige donc beaucoup de gestion et de support
• Jusqu’à récemment, les ressources nécessaires étaient obtenues en demandant aux employeurs de Gerald Combs d’héberger le projet
• CACE Technology, Riverbed et Sysdig ont fourni à Wireshark des ressources allant au-delà de GitHub ou GitLab
  • Par exemple SharkFest, une conférence dédiée à l’analyse de protocoles
• Ces dernières années, le besoin pour le projet de voler de ses propres ailes s’est accru ; avec l’aide de Sysdig, il a été transféré au début de cette année à la Wireshark Foundation
• Ce transfert à la Foundation constitue une base permettant à Wireshark de continuer à grandir et de soutenir sa communauté

Les conseils qui restent 25 ans plus tard

• Lorsque Gerald Combs a envoyé son e-mail il y a 25 ans, il n’imaginait pas qu’il écrirait aujourd’hui un billet de blog sur ce projet
• L’expérience du support et de la gestion de Wireshark lui a offert une excellente carrière et l’occasion de rencontrer et de travailler avec des personnes remarquables
• À celles et ceux qui souhaitent lancer un projet open source, il laisse le message de ne pas hésiter
• Il est important de permettre à une communauté de partager ses idées précieuses
• Si l’on n’a pas peur de commencer quelque chose de nouveau, on ne peut pas savoir où cela mènera 25 ans plus tard

[GN⁺]

Commentaires Hacker News

• Wireshark est un peu le marteau proverbial qui fait ressembler tous les problèmes réseau à des clous.
  Même quand il existe des outils plus spécialisés, si l’on attaque le problème avec Wireshark, on finit généralement par en trouver la cause.
  Je suis toujours surpris de voir autant de gens se dire spécialistes réseau sans avoir jamais utilisé Wireshark, ou sans le comprendre ; c’est peut-être l’outil le plus important pour comprendre ce qui se passe réellement sur un réseau.
  Pas plus tard qu’hier, j’ai traqué au moyen d’une capture de paquets le comportement étrange d’un système Asterisk/FreePBX mis à niveau : sans cela, j’aurais passé des jours à conjecturer, alors qu’en regardant ce qui se passait sur le réseau j’ai pu réduire immédiatement le champ des possibles.

  • C’est comme un débogueur pour le réseau, et étonnamment beaucoup de programmeurs ne savent même pas utiliser un débogueur.
  • Je me demande s’il existe de bonnes ressources pour bien comprendre Wireshark.
    Je ne suis pas spécialiste réseau, mais j’ai eu à m’en servir de temps en temps dans mon travail ; on sent sa puissance, mais sans un problème très petit et très précis, c’est un outil intimidant au premier abord.
    Je me demande aussi si c’est le genre d’outil qu’on apprend au fil des besoins.
  • Si tu as le temps, ce serait intéressant que tu partages en quoi consistait ce problème Asterisk/FreePBX et comment la capture de paquets l’a résolu.
    Ça ferait un billet de blog très intéressant.
  • Wireshark m’a beaucoup aidé même dans des domaines moins concrets et moins hardcore que le réseau.
    Vers 2013, chez Amazon, je devais réaliser en une semaine une preuve de concept Node.js pour une ancienne appli/un ancien service Spring/Java, avec de l’authentification entre services et de la messagerie Tibco dans la boucle.
    Je n’ai pas trouvé d’implémentation publique du client Tibco, et à cause du principe de leadership axé sur la frugalité, obtenir les spécifications officielles était quasiment impossible ; il me fallait seulement quelques détails de structure des paquets pour certaines requêtes.
    Vous pouvez deviner quel outil m’a sauvé, et même le Principal Engineer de l’époque a été surpris qu’un tel outil existe.

• En 1983, je travaillais chez un sous-traitant de la défense dans la Silicon Valley, à l’époque où Ethernet utilisait encore de gros câbles coaxiaux et des vampire taps.
  Nous développions un produit de pont Ethernet reliant les LAN DECnet des stations au sol DSCS (Defense Satellite Communications System) du monde entier via des lignes chiffrées à 9600 bps, et j’ai écrit, dans une partie du code, un dumper de paquets qui mettait la carte Ethernet en mode promiscuous.
  Il n’y avait pas d’analyseur comme Wireshark, mais le simple fait de pouvoir dumper les paquets bruts en hexadécimal dans un terminal était un avantage énorme pour déboguer le réseau.
  Quand j’installe un nouveau système, Wireshark fait partie des tout premiers outils que j’installe.

  • Je me demande comment Ethernet est passé des gros câbles et des vampire taps au RJ45.
    Je ne sais même pas si c’est exactement le même protocole qu’à l’époque, ni si « protocole » est le bon terme.
    Ça me donne envie de creuser davantage le réseau.

• Je suis la personne qui a créé Wireshark.
  Lire tous ces mots chaleureux et ces souvenirs a illuminé ma matinée.

  • Wireshark m’a permis de résoudre beaucoup de problèmes pendant des années, mais aujourd’hui j’ai presque cessé de l’utiliser parce qu’il ne semble pas suivre les débits de données courants sur les serveurs modernes.
    L’analyse semble monothread, il ne semble pas y avoir de cache, et il peine même avec « seulement » quelques Go de capture, ce qui ne représente que quelques secondes sur un lien 10 Gbps.

• C’est depuis le début un outil indispensable dans mon travail.
  tcpdump était correct, mais pouvoir faire un clic droit sur un paquet puis follow TCP stream pour voir toute la conversation en une seconde, ça a tout changé.
  « right click->filter out this stream » aussi ; et comme Ethereal/Wireshark pouvait lire les fichiers sauvegardés par tcpdump, on pouvait se connecter en ssh à un serveur distant, lancer tcpdump, puis examiner côté client les flux réseau des deux côtés avec Wireshark.
  Les NAT d’ISP suspects sautaient aux yeux, et les réseaux MPLS mal configurés pouvaient être mis en évidence par des preuves, de sorte que l’équipe routage ne pouvait plus se contenter de dire « de notre côté, ça a l’air bon ».
  Je voudrais toutefois corriger un point de l’article : Ethereal n’était pas le premier analyseur gratuit de paquets réseau avec interface graphique ; à l’époque de Windows NT, il existait déjà des outils comme netmon de Microsoft.

  • Cet outil s’appelait Network Monitor, alias netmon, et en interne on l’appelait aussi Bloodhound.
    Il avait aussi une API documentée ; son support était ambigu, mais elle était facile à brancher, et avant Ethereal j’avais déjà construit un wrapper tcpdump par-dessus.
    Avec l’arrivée de la pile TCP « nouvelle génération » de Longhorn/Vista, cette API et netmon sont devenus obsolètes.
    Microsoft Message Analyzer est ensuite arrivé ; basé sur ETW, il permettait d’analyser le réseau et d’autres traces ETW, et d’écrire n’importe quel gestionnaire de protocole avec son DSL de support.
    On pouvait aussi lui faire parser des fichiers de logs et filtrer/analyser les données ; c’était tellement puissant et utile pour les développeurs Windows que Microsoft a fini par le supprimer.
  • S’il ne fonctionnait que sous Windows, il est discutable de dire qu’il était vraiment gratuit.
    Au final, c’était un outil inclus dans un système d’exploitation qu’on avait payé.

• Wireshark est à l’électronique ce que le multimètre est au réseau.
  Le monde continue de tourner sans lui, mais quand quelque chose tombe en panne, on est fichu si on ne l’a pas.

  • Wireshark et tcpdump m’ont permis de trouver un nombre incroyable de problèmes étranges sur le réseau du campus.

• Cet outil, qui s’appelait alors Ethereal, était vraiment précieux dans mon travail de Senior Tech Support pour la gamme de produits WebLogic.
  Je pouvais le faire exécuter directement par le client et lui répondre des choses comme : « toutes les connexions du grand pool de connexions JDBC ont été silencieusement coupées par un pare-feu réseau dont le client ignorait l’existence, ce qui explique pourquoi la première transaction du matin est retardée d’une heure ; toutes les connexions du pool ont dû expirer puis être réinitialisées ».
  Il m’a aussi permis de trouver des problèmes du type : « Internet Explorer interrompt la connexion TCP d’une ressource déjà en cache, ce qui provoque une erreur non standard au niveau réseau dans l’installation WebLogic sur serveur IBM ».
  J’y ai perdu la moitié de mes cheveux ; sans Ethereal, j’aurais perdu tout le reste, et ma santé mentale avec.

• J’ai utilisé Wireshark tous les jours pendant plus de dix ans en assurant le support des load balancers sur les réseaux clients.
  Les pcap et les core dumps étaient les données les plus intéressantes à manipuler ; apprendre libpcap, puis finir par en créer ma propre version, m’a permis de passer du support produit au développement.
  Je suis entré comme ingénieur support et j’en suis ressorti Principal Software Engineer, écrivant moi-même le code que je supportais auparavant ; grâce à Wireshark et gdb, j’ai pu apprendre énormément par moi-même sans aller à l’université.

  • J’aime appeler ça les problèmes du type : « on ne sait pas ce qui cloche, donc c’est forcément le réseau ».

• C’est vraiment un excellent outil, et totalement gratuit.
  Je l’utilise souvent pour déboguer des problèmes réseau et voir où des appareils se connectent ; comme quelqu’un l’a dit, c’est un multimètre pour le réseau.
  Je m’en suis aussi servi pour apprendre l’établissement de connexion avec des points d’accès Wi-Fi, et on peut voir à la fois les paquets beacon et les paquets Wi-Fi.

  • J’ai adopté Ethereal très tôt.
    L’équipe avait un PC Sniffer, mais il était souvent utilisé par quelqu’un d’autre, ou son décodage des protocoles n’était pas suffisant.

• C’est un logiciel vraiment remarquable.
  Il y a 20 ans, sur le site d’un client, j’étais bloqué à chercher un problème d’interopérabilité de notre équipement réseau ; je me souviens qu’en écrivant pendant deux semaines un plugin d’analyse de protocole, cela m’a aidé assez facilement.
  Au final, c’était un bug de notre côté : en passant l’implémentation de select() à epoll(), nous n’avions pas supprimé l’application du bitmask prévue pour select().
  En substance, c’était une erreur de corruption mémoire sur 1 bit, dont les effets pouvaient apparaître très tard.
  Étrangement, ce genre de souvenir reste longtemps.

  • J’envie la capacité à trouver du plaisir dans ce genre de choses.
    Au début de ma carrière, dans une installation sécurisée où l’installation de Wireshark n’était pas autorisée, j’ai passé une semaine à disséquer un bug réseau agaçant uniquement avec tcpdump.
    Au final, c’était la combinaison d’un bug atroce dans la bibliothèque standard GNAT (Ada) vieille de 10 ans et d’une erreur de configuration ARP ; en fait, le bug de la bibliothèque avait déjà été corrigé sept ans plus tôt.
    Cette semaine a été tellement horrible qu’elle a beaucoup pesé dans ma décision de partir vers un meilleur endroit ; il faut un tempérament particulier pour aimer ça.

• Les gens imaginent souvent changer le monde, mais il y a aussi des gens qui changent réellement le monde.