Ce billet est la dernière partie de l’article consacré à la capture et au traitement du trafic réseau. Ainsi, il est fortement conseillé (voire même impératif) de consulter les deux premières parties afin de prendre connaissances des différents éléments abordés et d’appréhender donc mieux le sens de cette dernière partie.

• Capturer et traiter du trafic réseau – première partie
• Capturer et traiter du trafic réseau – deuxième partie

Bonne lecture !

——————————————————-

Analyse avec un super nouvel outil :

 

C’est bien beau d’avoir réussi à stocker son fichier sans que sa barrette de RAM parte en sublimation, mais on n’est toujours pas capable d’exploiter l’ensemble de la capture d’un coup. Soit ca vous va de travailler par petits bouts, soit vous travaillez sur chaque fichier pour l’alléger et ne garder que les trames qui vous intéressent (pas de chance dans notre cas, voulant voir tout le trafic, nous devons tout garder) et finalement réduire chaque fichier pour que la somme de tous soit raisonnable pour Wireshark. Vous pouvez également effectuer les traitements et les statistiques à l’aide de Tshark.

Enfin, dernière solution, coder votre propre outil … je sens un mouvement de foule d’un seul coup, j’ai dit quelque chose qui dérange ?

J’ai codé un outil que je vais vous présenter rapidement. Après consultation des plus grands stratèges logiciels du monde, j’ai décidé de l’appeller « Sonde.pl ».

Nous lui donnons un fichier de capture en entrée (capture faite par Wireshark ou par dumpcap). Il met tout cela dans une base de données, fait des stats de base comme :

• Classement des couples IP les plus bavards sur la période d’observation
• Débit (par seconde) utilisé par chaque couple IP (2 valeurs, une pour chaque direction)
• Broadcast ethernet

Il permet également de faire des histogrammes (format svg, lisible par exemple par Firefox ou Epiphany browser) :

• Trafic TCP, trafic UDP et trafic ICMP
• Trafic non IP, trafic IP non TCP/UDP/ICMP
• Trafic minimum/moyen/maximum sur une période choisie avec une granularité définie (minimum 10 secondes).

 

Ci-dessous des exemble de trafic Min (bleu), Moyen (jaune), Max (gris) sur 1 heure et sur 1 jour, avec des granularités de 10 secondes :

 

 

 

 

 

 

 

 

 

 

 

Sur 1 jour, même chose avec des granularités différentes et des couleurs différentes :

 

 

 

 

 

 

 

 

 

 

D’autres couleurs cette fois pour les gothiques …

 

 

 

 

 

 

 

 

 

 

Limites :

L’outil ne connait que le trafic :

• Ethernet II
• Ethernet 802.3 (traitement des en-têtes Ethernet et LLC)
• Ethernet II et IP
• Ethernet II et IP et TCP
• Ethernet II et IP et ICMP
• Ethernet II et ARP

  Pas d’analyse du spanning-tree ou d’IPX. Le premier sera traité dans l’Ethernet 802.3, le second sera classé dans le trafic Ethernet II sans plus de précision aux côtés par exemple de SCTP et DCCP. Il est assez aisé pour une personne parlant le Perl d’étendre la liste des protocoles reconnus par l’outil.

 

 Secret de fabrication :

La stabilité de l’outil réside dans la simple idée qu’il vaut mieux décortiquer et stocker le résultat dans une base de données qui gère bien mieux le stockage et les manipulations de gros volumes de données plutôt que dans un fichier ou une variable tableau. Ainsi, pour calculer les statistiques et ensuite en extraire les résultats pour réaliser des graphiques ou des tableaux, nous consultons la base de données (MySQL) en SQL.

 

Performances :

J’ai fait des tests avec gestion de plus de 2 millions de trames ethernets ce qui représentait un fichier de plus de 1Go. Capture de trames entières à l’aide de dumpcpap. Wireshark ne peut même pas ouvrir le fichier (plantage après plusieurs minutes d’agonie).

Le traitement du fichier, par cet outil codé en perl, a duré 53 minutes. Ensuite le calcul des statistiques a duré environ 20 minutes. La génération de tous les graphiques environ 6 minutes. La CPU était chargée, mais pas la RAM (machine équipée de 768Mo de RAM seulement). Jouer avec la commande « nice » permet de garder un poste toujours réactif malgré les lourds calculs en tâches de fond.

Sur des fichiers moins volumineux, il s’avère que le traitement du fichier est aussi rapide sous Wireshark que sous Sonde.pl. La génération des graphiques est cependant plus rapide sous Sondes.pl.

Ces tests ont été fait sur une machine monoprocesseur simple coeur. On peut imaginer des gains substanciels sur une machine multi-processeurs et/ou multi-coeurs à partir du moment où nous avons plusieurs fichiers que nous traitons en parrallèle en chargeant une instance de Sonde.pl pour chacun.

Le stockage et la consultation peuvent être réalisés de manière asynchrone.

 

Mais pourquoi ?! :

Parce que j’en avais besoin pour retraiter des captures très volumineuses et wireshark tenait difficilement la phase de capture, et pas du tout la phase de traitement.

 

Où est-il disponible ? :

Il faut me le demander avec la seule contrainte que la phrase commence par « s’il te plait » et finisse par « merci ».

 

Comment l’utiliser ? :

Voici le manuel qui s’affiche en tapant ./Sonde.pl -h :

 Quelques exemples :

Donc pour ajouter une capture dans un base de données que l’on initialise préalablement :

Puis on génère les statistiques :

Enfin on génère tous les graphiques :

 

On peut biensûr cumuler les options dans n’importe quel ordre :

 

Pour les machines multi-processeurs, on peut lancer plusieurs processus en même temps. Pour lancer le traitement de 2 fichiers de capture en même temps (fichier2.cap plus récent que fichier1.cap), taper dans une première console :

Puis dans la seconde :

Ainsi, la première commande insère dans la base de données le résultat du traitement de fichier1.cap et la seconde commande fait de même pour fichier2.cap même si le traitement de fichier1.cap est toujours en cours. Comme ce sont 2 processus différents et indépendants, ils occuperont chacun une CPU différente exploitant ainsi au mieux les capacités multi-coeurs des nouveaux processeurs. Cela n’est pas limité à 2 CPU !

 

Autre et dernier cas : vous avez lancé le traitement d’un fichier fichier10.cap que vous avez arrêté en cours de traitement. Soit vous réinitialisez tout et cela peut prendre du temps de tout recommencer, soit vous ne traitez que ce qui manquait à stocker avec l’option -ajout :

Cette option est également utilisable avec -stat.

 

 En synthèse :

 

Je vous ai fait une petite introduction sur la démarche à suivre pour réaliser une capture avec Wireshark. Ensuite j’ai évoqué l’existence d’autres outils liés au projet Wireshark. Enfin j’ai parlé des limites de Wireshark et comment les contourner, en utilisant dumpcap, Tshark et pourquoi pas un petit outil que j’ai codé.

Ah oui, quand je disais en introduction qu’il serait question de sexe dans cet article, bhen … j’ai menti !

 

Rédigé par Guillaume LEHMANN

Tags: Logiciel Réseaux Sniffer, Outil Réseaux Wireshark

Cet article a été posté le Vendredi, 24 avril 2009 à 23 h 09 min et est classé dans Logiciels, Outils, Réseaux. Vous pouvez suivre les réponses à cet article via le flux RSS 2.0. Vous pouvez laisser un commentaire, ou faire un Rétrolien depuis votre propre site.