Capturer et traiter du trafic rseau

G. Lehmann

Douce et paisible introduction :

Parmi les ambitieux objectifs professionnels qui m'taient confis pour ce dbut d'anne, je devais
monter une formation des collgues concernant l'utilisation des sondes. Les matres du temps et du
planning n'ayant pas voulu tendre les journes au-del de 24 heures, je me vois dans l'obligation
de ne pas devoir l'animer. J'ai donc rsum quelques points sur lesquels j'ai travaill ces derniers
mois et qui pourraient 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 mthodologie et parfois de sexe.

Rapidement un peu d'histoire :

Au dbut, Grald Combs cra un analyseur rseau 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.

Prsentation gnrale :
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 rseau
brut de fonderie. Etudier le comportement d'un rseau en analysant 750000 trames reprsentant
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 : rsum de trame (ordre de capture, timestamp de capture, adresses IP
source et destinataire, protocole de niveau 4 ou 7, informations complmentaires), dtail de chaque
en-tte sous forme d'arborescence, et enfin la trame sous forme hexadcimale (avec une traduction
approximative en code ASCII).
Avant de continuer, 2 messages subliminaux crits pour ceux qui disent connatre les analyseurs
rseaux, mais pas tant que a en fait :
-- un analyseur rseau est comme un thermomtre ; ce n'est pas en lisant la temprature que vous
dterminerez la maladie. En plus clair, arrtez de croire que l'analyseur rseau nous crit en gros
caractres ton problme 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 & Tlcom, tu dois le
dsactiver. Attends un petit moment, je suis en train de te gnrer un batch pour corriger tout
a ... . Mme un analyseur 15000 euros ne fait pas a.
-- un analyseur requiert videmment des comptences pour l'utiliser, mais surtout pour comprendre
ce qu'il nous affiche. C'est un peu plus complexe qu'un thermomtre quand mme.

O placer la sonde :
(Euh ... mon illustration avec le thermomtre 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 rseau il reste placer la sonde. Soit nous l'insrons 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 connecte la
sonde. Il est prfrable de se mettre en coupure car plusieurs problmes peuvent subvenir :
-- le port o est connect la sonde ne permet pas de monter un dbit aussi lev que celui gnr
sur le port surveill ;
-- la recopie de trafic ne recopie gnralement que le trafic valide. Si c'est le cas de votre switch, ne
perdez pas votre temps essayer de capter des trames ethernet erronnes, elles ne vous parviendront
pas !
-- sur certains quipements, la recopie de port ne permet pas d'envoyer/recevoir du trafic /depuis la
sonde connecte 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'entre pour la PMAD, vous aller vous enquiquiner
chaque fois que vous voudrez voir le rsultat de la capture (arrter 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-rel.

Effectuer des captures avec Wireshark :

Vous avez install Wireshark sur votre PC MS Windows en suivant la procdure trs complexe que
voici : cliquer sur Suivant jusqu' qu'il n'apparaisse plus, cliquer alors sur Terminer .
Sur les unix, c'est diffrent, mais pas compliqu non plus vu que ce logiciel est empaquet dans les
distributions.
Puis fbrile, ne pouvant vous contenir, vous lancez votre premire capture sur le backbone du
rseau au plus fort de la journe. Les trames dfillent tout allure, les chiffres s'incrmentent, vous
voyez le monde dfiler 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 rseau.
Quelques minutes voir quelques heures aprs, vous reprenez vos esprits et vous arrtez 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 reconnatre, nous sommes tous passs
par l, mme les meilleurs d'entres-nous.
Eh oui, car quand on lance une capture, il faut programmer certains paramtres :

-- L'interface de la machine sur laquelle raliser la capture (si plusieurs cartes rseaux ... 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 : intressant pour allger plus tard le traitement du fichier, mais seulement dans
le cas o dj nous savons ce que nous cherchons ; donc pas en premire approche d'un dpannage.
-- Est-ce que nous nous intressons aux donnes transportes ou juste aux en-ttes 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 intressent (14 octets pour l'en-tte 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 dmarrage diffr.
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 dj
captures, et cela permet aussi Wireshark de ne pas garder tout le trafic en RAM (et donc
d'exploser votre RAM).
-- Devons-nous enregistrer le trafic dans un fichier circulaire ? C'est utilis quand nous mettons un
analyseur pour tudier un phnomne observable au moment o il se passe, rcurrent mais non
prvisible. Ainsi, nous n'avons que les X dernires minutes ou dernires heures au moment de l'arrt
de la capture, et non les 10 jours sans intrt prcdant l'vnement.
-- 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
dcouper pour retraiter ensuite par petits bouts. Viens alors la question suivante :
-- Qu'est-ce qui dtermine le passage d'un fichier l'autre ? La taille (maximum 50Mo par exemple
pour une gestion simplifie) ou le temps (un test dure une heure, puis l'autre dmarre en suivant et
nous voulons que la trace de chaque test soit dans son propre fichier) ?
-- Est-ce que la capture doit s'arrter automatiquement ? Si oui, cela peut tre aprs 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 dcouvrirez par vous-mmes.
Ayant pris le temps de poser les choses cette fois-ci, on se dit que ce que l'on veut vraiment, c'est
connatre le dbit global, les couples IP les plus bavards et que la priode d'observation soit une
journe entire.
Nous lanons donc la capture :
-- interface en mode promiscuit sur l'interface eth1 ;
-- seuls les 68 premiers octets sont gards ;
-- 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, mme incompltes, 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 problme c'est que nous voulions le couple IP le plus bavard sur la totalit de la journe et non
par petit bout. Nous slectionnons tous les fichiers et on fait un glisser-dposer dans l'interface
graphique pour concatner toutes les captures en une seule partir de laquelle seront calcules 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'obsit-sation et nous quitte sans mme 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 premire 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 ...
gure mieux). Nous verrons plus tard comment contourner cela sans devoir piller les barrettes RAM
du magasin informatique du quartier (hh !).
Autre limite que vous avez surement constat lors de la capture, c'est que pour passer d'un fichier
l'autre, il ferme la fentre de capture en cours et en ouvre une autre pour le fichier suivant. Or si la
machine est trs sollicite, il n'a pas toujours le temps de bien fermer la fentre. Cela n'est pas
gnant en soit si ce n'est que l'on a une fentre ouverte en plus pour rien. Or, au bout de 24h, si 50%
des fentres ne se sont pas closes, on se retrouve avec 100 fentres ouvertes, chacune consommant
sa part de RAM. Si la capture est arrive son terme, nous pouvons les fermer la main (en forant
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 premires heures de captures sur les 24 dsires. Nous
verrons plus tard comment coutourner cet autre problme (re hh). En fait non, nous allons le voir
desuite avec le paragraphe suivant.

La galaxie des logiciels du projet Wireshark :

Wireshark, tout le monde connat. C'est joli, c'est rapide, mais c'est limit.
En s'aidant de la libpcap (sous les Unix) ou winpcap (sous MS Windows), nous pouvons crer un
outil de capture basique en moins de 50 lignes de code Perl, environ une centaine en C. Quelques
centaines de lignes plus tard nous rajoutons le stockage dans plusieurs fichiers. Wireshark, qui fait
des miliers de lignes de code intgre donc tout un tas de code, excut son chargement, mais non
utile pour la capture. Ce code sera utile pour les statistiques, dessiner des courbes, grer les boutons
et menus droulants de l'interface graphique, ect.
C'est l que 2 outils arrivent et vont nous intresser. Le premier est Tshark. C'est Wireshark en
mode console. Il est disponible sous les Unix comme un outil part de Wireshark. Je ne sais pas s'il
est disponible sous MS Windows. Nous pouvons appliquer des filtres l'affichage, stocker le

rsultat dans un ou plusieurs fichiers et tout et tout comme Wireshark. Il affiche galement en
console le rsultat courant de la capture. C'est moins joli et color, mais si nous avons uniquement
accs la sonde en telnet ou ssh, c'est tout de mme bien utile. On peut exporter le rsultat dans un
fichier texte ou postscript ou ...
Le second outil est dumpcap. Il est part (dumpcap.exe) sous MS Windows, mais inclus dans le
paquet Wireshark sous Unix (concernant GNU/Linux Debian du moins). Il est aussi en mode
console, permet de faire des filtres la capture, de capturer seulement x octets de chaque trame
(minimum 68 si la trame fait plus de 68 octets), de mettre tout cela dans plusieurs fichiers avec une
rotation ou pas, ect. La seule diffrence avec Tshark, c'est que le rsultat est crit dans le format
pcap, donc non lisible par l'homme (sauf No et toute sa clique qui ont fait hxadcimal en seconde
langue en sortant de la matrice) et que pendant la capture nous ne voyons pas grand chose d'autre
que le compteur de trames s'incrmentant laconiquement.
Il existe d'autres outils que je ne dtaillerai pas mais qui sont utiles pour manipuler des fichiers de
capture sans passer par l'interface et donc sans mettre genoux le quadriprocesseurs doubles-coeurs
que vous idlatrez. De plus, Wireshark n'tant pas multi-thread, inutile d'avoir des multiprocesseurs ou des processeurs double-coeur ... Donc ces outils dont je ne vous parlerai pas sont :
-- editcap : Editer les fichiers de capture, inclus dans Wireshark. Mode console. Sa principale
fonction est de supprimer les paquets du fichier de capture (quivalent appliquer un filtre de
capture postriori) ou pour convertir le fichier dans un autre format.
-- mergecap : Concatner plusieurs fichiers en un.
-- text2pcap : Convertir un fichier de capture au format ASCII hexadcimal dans le format pcap.
-- capinfos : Donner des informations gnrales sur le fichier de capture (nombre de trames, taille
du fichier, la dure de la capture, ...).
Je vous laisse aller faire un tour l'adresse
http://www.wireshark.org/docs/wsug_html_chunked/AppTools.html
pour avoir plus d'infos sur ces diffrents outils, ainsi que les arguments qu'ils apprcient de voir
renseigns.

Capture avec dumpcap :

Aprs cette grande apparte, revenons notre capture d'une journe. Dj, pour s'assurer qu'elle ne
plante pas vicieusement en pleine nuit suite un nombre trop important de fentres ouvertes, nous
allons utiliser dumpcap.
Sous GNU/Linux :
dumpcap -i eth0 -w /tmp/tutu -a duration:86400 -b filesize:50000 -s 68
En bon franais, nous enregistrons le trafic passant sur l'interface eth0 dans des fichiers qui
commencent par tutu, dans le rpertoire /tmp. Ils seront nomms par l'outil comme, par exemple :
tutu_00004_20090114230857
o 00004 signifie que c'est le 4ime fichier gnr lors de la capture,
et 20090211230857 la date de gnration de ce fichier (11 fvrier 2009 23h08 et 57 secondes,
argh, je devrais tre couch cette heure moi !).
La dure de capture s'exprime en secondes, donc 24 heures = 86400 secondes.
La taille de chaque fichier de capture en Ko, donc 50000Ko dans notre cas.
Enfin nous capturons seulement les 68 premiers octets. Pour ceux qui sont inquiets de savoir
comment calculer le dbit si l'on n'archive que les 68 premiers octets qu'ils se rassurent : il est
stock dans le fichier la taille initiale du paquet avant que celui-ci se fasse retailler et biensr
wireshark prend en compte dans son calcul la taille originale. Ouf, vous avez eu peur, hein ?
Ci-dessous le rsultat de dumpcap -help :

Dumpcap 1.0.2
Capture network packets and dump them into a libpcap file.
See http://www.wireshark.org for more information.
Usage: dumpcap [options] ...
Capture interface:
-i <interface>
name or idx of interface (def: first non-loopback)
-f <capture filter>
packet filter in libpcap filter syntax
-s <snaplen>
packet snapshot length (def: 65535)
-p
don't capture in promiscuous mode
-y <link type>
link layer type (def: first appropriate)
-D
print list of interfaces and exit
-L
print list of link-layer types of iface and exit
-S
print statistics for each interface once every second
-M
for -D, -L, and -S produce machine-readable output
Stop conditions:
-c <packet count>
stop after n packets (def: infinite)
-a <autostop cond.> ... duration:NUM - stop after NUM seconds
filesize:NUM - stop this file after NUM KB
files:NUM - stop after NUM files
Output (files):
-w <filename>
name of file to save (def: tempfile)
-b <ringbuffer opt.> ... duration:NUM - switch to next file after NUM secs
filesize:NUM - switch to next file after NUM KB
files:NUM - ringbuffer: replace after NUM files
Miscellaneous:
-v
print version information and exit
-h
display this help and exit
Example: dumpcap -i eth0 -a duration:60 -w output.pcap
"Capture network packets from interface eth0 until 60s passed into output.pcap"
Use Ctrl-C to stop capturing at any time.

Analyse avec un super nouvel outil :

C'est bien beau d'avoir russi 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'allger et ne
garder que les trames qui vous intressent (pas de chance dans notre cas, voulant voir tout le trafic,
nous devons tout garder) et finalement rduire 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, dernire solution, coder votre propre outil ... je sens un mouvement de foule d'un seul coup,
j'ai dit quelque chose qui drange ?
J'ai cod un outil que je vais vous prsenter rapidement. Aprs consultation des plus grands
stratges logiciels du monde, j'ai dcid de l'appeller Sonde.pl .
Nous lui donnons un fichier de capture en entre (capture faite par Wireshark ou par dumpcap). Il
met tout cela dans une base de donnes, fait des stats de base comme :

-- classement des couples IP les plus bavards sur la priode d'observation ;

-- dbit (par seconde) utilis par chaque couple IP (2 valeurs, une pour chaque sens) ;
-- 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 priode choisie avec une granularit dfinie (minimum
10 secondes).
Ci-dessous des exemble de trafic Min (bleu), Moyen (jaune), Max (gris) sur 1 heure et sur 1 jour,
avec des granularits de 10 secondes.

Sur 1 jour, mme chose avec des granularits diffrentes et des couleurs diffrentes.

D'autres couleurs cette fois pour les gothiques ...

Limites :
L'outil ne connait que le trafic :
-- ethernet II ;
-- ethernet 802.3 (traitement des en-ttes Ethernet et LLC) ;
-- ethernet II et IP ;
-- ethernet II et IP et TCP ;
-- ethernet II et IP et UDP ;
-- 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 prcision aux cts 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 rside dans la simple ide qu'il vaut mieux dcortiquer et stocker le rsultat
dans une base de donnes qui gre bien mieux le stockage et les manipulations de gros volumes de
donnes plutt que dans un fichier ou une variable tableau. Ainsi, pour calculer les statistiques et
ensuite en extraire les rsultats pour raliser des graphiques ou des tableaux, nous consultons la base
de donnes (MySQL) en SQL.
Le stockage et la consultation peuvent tre raliss de manire asynchrone.
Performances :
J'ai fait des tests avec gestion de plus de 2 millions de trames ethernets ce qui reprsentait un fichier
de plus de 1Go. Capture de trames entires l'aide de dumpcpap. Wireshark ne peut mme pas
ouvrir le fichier (plantage aprs 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 gnration de tous les graphiques environ 6 minutes. La
CPU tait charge, mais pas la RAM (machine quipe de 768Mo de RAM seulement). Jouer avec
la commande nice permet de garder un poste toujours ractif malgr les lourds calculs en tches
de fond.
Sur des fichiers moins volumineux, il s'avre que le traitement du fichier est aussi rapide sous

Wireshark que sous Sonde.pl. La gnration 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 parrallle en chargeant une instance de Sonde.pl pour
chacun.
Mais pourquoi ?! :
Parce que j'en avais besoin pour retraiter des captures trs 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 :
-= MANUEL D'UTILISATION =-help : Affichage de cet aide.
==============================
=MODES ET OPTIONS POUR CHACUN=
-rec : (Non cod) Utilisation en tant que sonde uniquement (RECord traffic).
-interface <Nom Interface> : Interface rseau sur laquelle la sonde se met en coute (mode
promiscuit).
-file <Nom Fichier> : Chemin et nom du fichier dans lequel enregistrer la capture.
-surv : Surveillance du trafic pour dtecter une coupure d'un flux. Entre 2 apparitions de flux, le
trafic est enregistr dans un fichier.
-interface <Nom Interface> : Interface rseau sur laquelle la sonde se met en coute (mode
promiscuit).
-chaine <RegExp> : Chane de caractre identifiant le flux surveiller.
-file <Nom Fichier> : Chemin et nom des fichiers o est loggu le trafic lorsqu'il y a un
problme. Le programme rajoute une extension pour distinguer les enregistrements s'il y a une
srie de problmes.
-freq <Nombre> : Dlai maximum, en seconde, d'apparition de la chane de caractre. Si depuis
la dernire apparition il s'est pass plus de temps que dfini ici, alos le mode alarme est
enclench : le trafic depuis la dernire apparition est enregistr dans un fichier jusqu' la
prochaine rapparition.
-init : Suppression de tous les enregistrements des tables CAPTURE, STAT et STATHEURE.
-pcap : Raliser le stockage des informations des trames (du fichier indiqu par -file) dans la base
de donnes.
-ajout : Seuls les paquets, stocks dans le fichier de capture, plus rcents que le plus rcent des
paquets stocks dans la BD, sera insrer dans la base de donnes. Cela permet de rajouter
seulement les paquets non traits d'un fichier, sans doublon ni perte de temps faire ce qui a dj
t fait.
-file <Nom Fichier> : Chemin et nom du fichier traiter par -pcap.
-v : Mode verbeux. Afficher dans la console les en-ttes des trames traites.
-vv : Mode trs verbeux. Afficher dans la console les en-ttes et le contenu des trames traites.

-stat : Gnrer les statistiques sur les paquets capturs et stocks dans la base de donnes. Stocket
le rsultat dans la base de donnes. On peut indiquer la granularit du calcul (impactant seulement
les stats moyennes) :
-ajout : Seules les statistiques non encore gnres sur la priode donne sont calcules. Les
autres sont gardes. Gnralement utile aprs un "-ajout -cap".
-stgranularite <Nombre> : 10 par dfaut. Dure en secondes. Les stats qui sont moyennes
seront calcules sur des intervalles allant de (t) (t + granularit).
-graph : Gnrer les graphiques standards (sur les dernires minutes).
-bp <Nombre> : Bande-passante du lien. Permet de dimensionner l'chelle de l'axe des
ordonnes.
-gpers : Gnrer les graphiques personnaliss (infos concatnes, mais affiches sur plusieurs
heures). Temps de gnration plus long, utile seulement pour une vision globale. Il est ncessaire
d'indiquer les options supplmentaires suivantes :
-nom <Nom Fichier> : Nom du fichier avec extension. Le programme y rajoute automatiquement
"Reporting".
-duree <Nombre> : Dure afficher. S'exprime en secondes.
-bp <Nombre> : Bande-passante du lien. Permet de dimensionner l'chelle de l'axe des
ordonnes.
-abscisse <Nombre> : Taille de l'abscisse en pixels.
-ordonnee <Nombre> : Taille de l'ordonne en pixels.
-granularite <Nombre> : Dure en secondes. Une valeur affiche reprsente le min/moy/max des
valeurs prises entre (t) et (t + granularite).
=========
=OPTIONS=
-abscisse <Nombre> : Voir le mode -gpers.
-ajout : Voir les modes -pcap et -stat.
-bp <Nombre> : Voir les modes -graph et -gpers.
-chaine <RegExp> : Voir le mode -surv.
-duree <Nombre> : Voir le mode -gpers.
-file <Nom Fichier> : Voir les modes -rec, -surv et -pcap.
-freq <Nombre> : Voir le mode -surv.
-granularite <Nombre> : Voir le mode -gpers.
-interface <Nom Interface> : Voir les modes -rec et -surv.
-nom <Nom Fichier> : Voir le mode -gpers.
-ordonnee <Nombre> : Voir le mode -gpers.
-stgranularite <Nombre> : Voir le mode -gpers.
-v : Voir le mode -pcap.
-vv : Voir le mode -pcap.
=================
=!! Attention !!=
-init annule l'effet de -ajout
-cap (sans -ajout) ne fait pas de nettoyage de la BD. Excuter 2 fois la commande sur le mme
fichier va crer des doubons ! Utiliser -init la deuxime fois si l'on veut retraiter tout le fichier mais
en nettoyant la BD avant.
-stat (sans -ajout) nettoie la base de donnes. Il n'est donc pas utile de rajouter -init.

Quelques exemples :
Donc pour ajouter une capture dans un base de donnes que l'on initialise pralablement :
./Sonde.pl -init -pcap -f /tmp/MonFichier.cap
Puis on gnre les statistiques :
./Sonde.pl -stat
Enfin on gnre tous les graphiques :
./Sonde.pl -graph -gpers -nom NomGraphique.svg -duree 86400 -abscisse 20 -ordonnee 100
-granularite 60 -bp 700000
On peut biensr cumuler les options dans n'importe quel ordre :
./Sonde.pl -init -pcap -f /tmp/MonFichier.cap -graph -gpers -nom NomGraphique.svg \
-duree 86400 -stat -abscisse 20 -ordonnee 100 -granularite 60 -bp 700000
Pour les machines multi-processeurs, on peut lancer plusieurs processus en mme temps. Pour
lancer le traitement de 2 fichiers de capture en mme temps (fichier2.cap plus rcent que
fichier1.cap), taper dans une premire console :
./Sonde.pl -pcap -f fichier1.cap
Puis dans la seconde :
./Sonde.pl -pcap -f fichier2.cap
Ainsi, la premire commande insre dans la base de donnes le rsultat du traitement de
fichier1.cap et la seconde commande fait de mme pour fichier2.cap mme si le traitement de
fichier1.cap est toujours en cours. Comme ce sont 2 processus diffrents et indpendants, ils
occuperont chacun une CPU diffrente exploitant ainsi au mieux les capacits 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 arrt
en cours de traitement. Soit vous rinitialisez tout et cela peut prendre du temps de tout
recommencer, soit vous ne traitez que ce qui manquait stocker avec l'option -ajout :
./Sonde.pl -ajout -cap -f fichier10.cap
Cette option est galement utilisable avec -stat.

En synthse :
Je vous ai fait une petite introduction sur la dmarche suivre pour raliser une capture avec
Wireshark. Ensuite j'ai voqu l'existence d'autres outils lis 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 !