Ce billet est la première partie d’un article écrit par Guillaume Lehmann sur les méthodologies de capture et d’analyse du trafic réseau. Celui-ci sera découpé en trois parties distinctes :

1. Introduction et présentation de l’outil Wireshark (ce billet)
2. Les outils existants périphériques à Wireshark
3. Découverte d’un outil « maison » d’analyse réseau

Bonne lecture !

————————————————————————–

Douce et paisible introduction :

Parmi les ambitieux objectifs qui m’étaient confiés pour ce début d’année, je devais monter une formation sur l’utilisation des sondes. Les maîtres du temps et du planning n’ayant pas voulu étendre les journées au-delà de 24 heures, je me vois dans l’obligation de ne pas devoir l’animer. J’ai donc résumé quelques points sur lesquels j’ai travaillé ces derniers mois et qui pourraient vous être utile.

Je vais me concentrer sur l’outil Wireshark et les autres outils qui font parti du projet (eh oui, il y en a d’autres !). Cet article parle donc de technique, de méthodologie et parfois de sexe.

Rapidement un peu d’histoire :

Au début, Gérald Combs créa un analyseur réseau nommé Ethereal. Puis paf, un jour il s’appella Wireshark (je vous avez dit que ce serait un historique rapide …). En conclusion, wireshark est la continuité d’Ethereal.

Présentation générale :

Ethereal permet de faire des captures de trafic en appliquant des filtres à la capture, mais également à l’affichage. On retrouve des filtres par adresse IP (source, destination, les 2), par adresses ethernet, par protocole (de n’importe quelle couche), ect.

Quand on parle de capturer le trafic, cela veut dire enregistrer tout ce que remonte la carte réseau brut de fonderie. Etudier le comportement d’un réseau en analysant 750000 trames représentant environ 60 secondes de trafic sur un lien chargé à 10Mb/s, c’est un peu chercher une aiguille dans une botte de foin. Wireshark nous aide un peu :

• application de filtres d’affichage pour élager petit à petit le « bruit »
• coloration
• affichage sous 3 formes : résumé de trame (ordre de capture, timestamp de capture, adresses IP source et destinataire, protocole de niveau 4 ou 7, informations complémentaires), détail de chaque en-tête sous forme d’arborescence, et enfin la trame sous forme hexadécimale (avec une traduction approximative en code ASCII).

Avant de continuer, 2 messages subliminaux écrits pour ceux qui disent connaître les analyseurs réseaux, mais pas tant que ça en fait :

• Un analyseur réseau est comme un thermomètre ; ce n’est pas en lisant la température que vous déterminerez la maladie. En plus clair, arrêtez de croire que l’analyseur réseau nous écrit en gros caractères « ton problème est sur le switch 192.168.10.20 où le spanning-tree est activé en version 1 alors que selon la directive N55220-89 de la Direction Informatique & Télécom, tu dois le désactiver. Attends un petit moment, je suis en train de te générer un batch pour corriger tout ça … ». Même un analyseur à 15000 euros ne fait pas ça.
• Un analyseur requiert évidemment des compétences pour l’utiliser, mais surtout pour comprendre ce qu’il nous affiche. C’est un peu plus complexe qu’un thermomètre quand même.

Où placer la sonde :

(Euh … mon illustration avec le thermomètre atteint ici ses limites !)

Logiquement, là où est suceptible de passer tout le trafic que nous voulons observer et si possible là où le trafic dont nous nous fichons ne passe pas. Une fois que nous avons trouvé la bonne planque pour espionner le réseau il reste à placer la sonde. Soit nous l’insérons en coupure, soit si cela n’est pas possible, nous nous connectons au switch où nous voulons surveiller le trafic entrant/sortant d’un port donné, et nous activons la recopie de trafic de ce port vers le port où est connectée la sonde. Il est préférable de se mettre en coupure car plusieurs problèmes peuvent subvenir :

• Le port où est connecté la sonde ne permet pas de monter à un débit aussi élevé que celui généré sur le port surveillé
• La recopie de trafic ne recopie généralement que le trafic valide. Si c’est le cas de votre switch, ne perdez pas votre temps à essayer de capter des trames ethernet erronnées, elles ne vous parviendront pas !
• Sur certains équipements, la recopie de port ne permet pas d’envoyer/recevoir du trafic à/depuis la sonde connectée sur ce port. Si votre sonde ne dispose que d’une carte ethernet qui fait à la fois office d’interface de capture et de point d’entrée pour la PMAD, vous aller vous enquiquiner à chaque fois que vous voudrez voir le résultat de la capture (arrêter la recopie de port et donc perdre quelques secondes ou minutes de capture, pour ensuite faire la PMAD). Impossible donc de voir à distance ce qui est capturé en temp-réel.

Effectuer des captures avec Wireshark :

Vous avez installé Wireshark sur votre PC MS Windows en suivant la procédure très complexe que voici : cliquer sur « Suivant » jusqu’à qu’il n’apparaisse plus, cliquer alors sur « Terminer ».

Sur les unix, c’est différent, mais pas compliqué non plus vu que ce logiciel est empaqueté dans les distributions.

Puis fébrile, ne pouvant vous contenir, vous lancez votre première capture sur le backbone du réseau au plus fort de la journée. Les trames défillent à tout allure, les chiffres s’incrémentent, vous voyez le monde défiler sous vos yeux, votre vue se brouille et vous finissez par vous évanouir submergé par l’émotion de vous sentir l’âme d’un expert réseau

Quelques minutes voir quelques heures après, vous reprenez vos esprits et vous arrêtez la capture. Si votre PC n’a pas explosé sous la charge RAM induite par Wireshark, vous vous retrouvez avec quelques centaines de milliers de trames et un fichiers de plusieurs centaines de Mo, voir Go. En effet, vous avez lancé une capture n’importe comment et vous vous retrouvez avec un fichier inexploitable car trop volumineux. N’ayons pas honte de le reconnaître, nous sommes tous passés par là, même les meilleurs d’entres-nous.

Eh oui, car quand on lance une capture, il faut programmer certains paramètres :

• L’interface de la machine sur laquelle réaliser la capture (si plusieurs cartes réseaux … attention aux interfaces virtuelles comme les VPN IPSec).
• Analysons-nous tout le trafic qui passe (mode promiscuité activé) ou seulement le trafic à destination ou source de la machine ?
• Filtre à la capture : intéressant pour alléger plus tard le traitement du fichier, mais seulement dans le cas où déjà nous savons ce que nous cherchons ; donc pas en première approche d’un dépannage.
• Est-ce que nous nous intéressons aux données transportées ou juste aux-têtes des trames ? Dans le second cas, inutile de capter les maximum 1500 octets d’une trame ethernet si seulement les adresses IP sources et destination nous intéressent (14 octets pour l’en-tête ethernet, 20 pour IP). Le minimum est de 68 octets. Nos fichiers de captures grossiront moins vite.
• De quand à quand faisons-nous la capture ? Wireshark ne permet pas de programmer de capture, mais d’autres outils sont utilisables dans des scripts permettant d’effectuer un démarrage différé. Nous verrons ces outils plus tard.
• Est-ce que nous capturons le trafic dans un fichier ? Sauf capture de quelques minutes et en direct, je le conseille fortement. En effet, si Wireshark plante, nous ne perdrons pas les trames déjà capturées, et cela permet aussi à Wireshark de ne pas garder tout le trafic en RAM (et donc d’exploser votre RAM).
•  evons-nous enregistrer le trafic dans un fichier circulaire ? C’est utilisé quand nous mettons un analyseur pour étudier un phénomène observable au moment où il se passe, récurrent mais non prévisible. Ainsi, nous n’avons que les X dernières minutes ou dernières heures au moment de l’arrêt de la capture, et non les 10 jours sans intérêt précédant l’évènement.
• Voulons-nous plusieurs fichiers ou un seul ? Je conseille également, à utiliser le stockage dans un fichier, d’utiliser plusieurs fichiers. A priori notre capture va être volumineuse, donc autant découper pour retraiter ensuite par petits bouts. Viens alors la question suivante :
• Qu’est-ce qui détermine le passage d’un fichier à l’autre ? La taille (maximum 50Mo par exemple pour une gestion simplifiée) ou le temps (un test dure une heure, puis l’autre démarre en suivant et nous voulons que la trace de chaque test soit dans son propre fichier) ?
• Est-ce que la capture doit s’arrêter automatiquement ? Si oui, cela peut être après x paquets, ou lorsque nous avons capturé une certaine quantité de trafic ou encore au bout d’un temps donné.

Viennent ensuite quelques autres options secondaires que vous découvrirez par vous-mêmes.

Ayant pris le temps de poser les choses cette fois-ci, on se dit que ce que l’on veut vraiment, c’est connaître le débit global, les couples IP les plus bavards et que la période d’observation soit une journée entière.

Nous lançons donc la capture :

• Interface en mode promiscuité sur l’interface eth1
• Seuls les 68 premiers octets sont gardés
• Stockage dans des fichiers, sans le mode « ring-buffer »
• Nous voulons des fichiers de 50Mo maximum, sans limite de nombre (attention à la taille disque !). Nous choisissons 50Mo seulement car ce qui charge Wireshark ce n’est pas la taille du fichier, mais le nombre de trames, même incomplètes, qu’il contient)
• Nous stoppons la capture au bout de 1 jour.

Le lendemain nous nous retrouvons avec des fichiers suffisamment petits pour les traiter au fur et à mesure. Dans le menu « statistiques » nous avons un ensemble d’outil permettant d’afficher, entre autres, les couples IP les plus consommateurs, une courbe du trafic global ou correspondant à un filtre particulier.

Le problème c’est que nous voulions le couple IP le plus bavard sur la totalité de la journée et non par petit bout. Nous sélectionnons tous les fichiers et on fait un glisser-déposer dans l’interface graphique pour concaténer toutes les captures en une seule à partir de laquelle seront calculées les statisques. Et là, l’affichage se fige, le disque dur se met à gratter et au bout de quelques minutes, Wireshark nous insulte pour tentative d’obésité-sation et nous quitte sans même un dernier regard. Eh oui, si un fichier de 1Go est trop gros, ce n’est pas 200 fichiers de 50Mo qui vont mieux passer. Nous atteignons là une première limite de Wireshark (Wireshark plante sur MS Windows, mais pas sous GNU/Linux. Sur ce dernier il consomme toute la RAM puis la swap jusqu’à figer la machine … guère mieux). Nous verrons plus tard comment contourner cela sans devoir piller les barrettes RAM du magasin informatique du quartier (héhé !).

Autre limite que vous avez surement constaté lors de la capture, c’est que pour passer d’un fichier à l’autre, il ferme la fenêtre de capture en cours et en ouvre une autre pour le fichier suivant. Or si la machine est très sollicitée, il n’a pas toujours le temps de « bien fermer » la fenêtre. Cela n’est pas génant en soit si ce n’est que l’on a une fenêtre ouverte en plus pour rien. Or, au bout de 24h, si 50% des fenêtres ne se sont pas closes, on se retrouve avec 100 fenêtres ouvertes, chacune consommant sa part de RAM. Si la capture est arrivée à son terme, nous pouvons les fermer à la main (en forçant parfois la fermeture), mais il arrive que cela fasse planter wireshark avant la fin et on se rend compte le lendemain que l’on n’a que les 5 premières heures de captures sur les 24 désirées. Nous verrons plus tard comment coutourner cet autre problème (re héhé). En fait non, nous allons le voir desuite avec le paragraphe suivant.

A suivre !

Rédigé par Guillaume LEHMANN