IUT Dpartement R&T TRC9 G.

Urvoy-Keller
Dans ce TP, vous allez utilisez Wireshark pour tudier diffrents scnarios d'analyse de trafic dans un contexte de supervision de rseau ou d'tudes d'attaques. Ce sera aussi l'occasion de manipuler les nombreuses fonctions avances de Wireshark. Tlcharger le fichier traces.tar.gz et dezipper/dtarer le fichier pour obtenir les traces sur lesquelles nous allons travailler.

I Analyse d'une trace vers un serveur Web.

Soit la trace http_espn.dmp. Ouvrez la avec Wireshark. Il s'agit de trafic li au tlchargement de la page d'entre d'un site Web. 1. Quelle est la composition protocolaire de la trace en terme UDP/TCP et d'applications au dessus de ces 2 couches transports? Utilisez la fonction protocol hierarchy du menu statistics. 2. Zoomez sur le trafic HTTP et donnez la dcomposition en terme de type d'objets HTTP. 3. Dzoomer un peu sur le trafic en filtrant le trafic TCP seulement. Pourquoi est-ce que la fraction de trafic HTTP descend tellement? 4. Combien y a t-il de conversations au niveau IP, TCP et UDP dans cette trace? Utilisez la fonction conversations du menu statistics . 5. Que vous fait comprendre le niveau Ethernet de la fonction conversations du menu statistics? 6. Concentrons nous sur le trafic DNS. Crer un filtre pour ne rcuprer que les demandes de rsolutions. Pour cela, il faut se placer sur un paquet DNS o il y a une requte, placer vous sur le champ dans l'en-tte applicative o apparat le code qui indique que c'est une requte puis faites un click droit et Prepare As filtered puis Selected. Combien en trouvez-vous? 7. Passons aux requtes HTTP. Pour les trouver, nous allons utiliser la fonction HTTP Requests du menu Statistics. 1. Interprtez les 2 premires colonnes du rsultat? 2. En quoi ce rsultat est compatible avec l'analyse DNS faite prcdemment? 3. Crez un filtre pour calculer le nombre d'objets effectivement tlchargs. Combien y en a-t-il? Ce rsultat est-il en adquation avec le rsultat de la sous-question 1 ci-dessus.

II Dpannage
Soit un utilisateur de votre rseau (vous avez t promu ingnieur rseau flicitations!) n'arrive pas accder Internet. Il arrive en revanche accder aux ressources internes (serveurs de donnes, mail, imprimantes, etc.). Vous capturez la trace nowebaccess1.pcap sur le commutateur d'attachement de la machine de l'utilisateur. Quelques informations : l'adresse IP de la machine de l'utilisateur est 172.16.0.8 et les serveurs DNS

configurs sur la machine sont 4.2.2.2 et 4.2.2.1. Analysez la trace et donnez votre diagnostic. Il faut tre prcis et dire ce qui a priori fonctionne et ce qui ne fonctionne pas dans le rseau. Si par exemple, vous pensez qu'une machine est utilise comme passerelle, vous devez dire quels lments vous font penser cela. Notez qu'il y a plusieurs diagnostics possibles.

III Dpannage
Un autre utilisateur se plaint de ne pas pouvoir accder certains sites Web (mais pas tous). Vous capturez nouveau une trace de trafic qui s'appelle nowebaccess3.pcap. Analysez la trace et montrez qu'elle permet de montrer que le problme se situe l'extrieur du rseau de l'entreprise qui ne comprend que des machines dans la plage d'adresses 172.16/24.

V La fable du dveloppeur et de l'ingnieur rseau

Soit une entreprise dans laquelle vous tes ingnieur rseau. L'entreprise a de multiples branches. Un dveloppeur a conu une application simple qui va, sur le serveur de chacune des branches rcuprs des fichiers des ventes de la journe, sous la forme de fichier csv (comma separated values). Le dveloppeur se plaint que ses fichiers soient corrompus lors du transport sur le rseau. Vous convenez d'un test o vous allez rcuprer un fichier transmis au niveau du serveur en capturant le trafic sur le switch de rattachement de ce dernier. La somme du contle md5 du fichier est :

La trace s'appelle tickedoffdevelopper.pcap. Chargez la dans wireshark. 1. Combien y-a-t-il de conversations au niveau IP et TCP? 2. Quels sont les protocoles de niveau applicatif prsents? 3. En vous appuyant sur votre connaissance du protocole, vous allez extraire la transmission du fichier en vous plaant sur un paquet de niveau applicatif quelconque correspondant ce transfert et en utilisant l'option 'Follow TCP stream' qui extrait les donnes au niveau applicatif. 4. Est-ce que le rseau est blmer ou non?

VI Processus d'Attaque
Parmi les machine que vous grez (vous tes toujours dans le mme rle d'ingnieur rseau), vous en avez une pour laquelle votre systme de dtection d'intrusion couine trs fort. Vous capturez du trafic sur le commutateur de rattachement de cette machine. La trace s'appelle attaque1.pcap. 1. Combien y-a-t-il de conversations au niveau IP et TCP?

2. Quels sont les services prsents sur la machine? (expliquez comment vous avez fait pour les trouver) 3. Expliquez la diffrence entre le cas ou le serveur rpond par un RST et le cas o il ne rpond pas. Pour vous aidez, faites des telnet sur la machine physique sur des ports ouverts ou non et voyez la raction de la machine au nivau TCP (Rappel (?) : on utilise netstat pour voir les ports ouverts ou non et la commande tcpdump pour voir le trafic)

VII OS fingerprinting
Des outils comme nmap (que l'on verra dans un autre TP) permettent de dterminer quel est l'OS implant sur une machine et les services ouverts sur la machine. Nmap est un outil passif : il injecte du trafic dans le rseau. Nous allons nous intresser ici aux empreintes digitales obtenues de manire passive, c'est--dire en analysant le trafic de l'utilisateur. Voici des tableaux donnant des valeurs de paramtres par dfaut typiques de certains systmes d'exploitation. En vous aidant de ces tableaux, relevez pour les 2 paquets les valeurs caractristiques et donnez une prdiction sur le systme d'exploitation implant par les machines dont des paquets ont t capturs dans la trace passiveosfingerprinting.pcap, sachant qu'il n'y aura pas de correspondance exacte.

VIII Goulet d'tranglement

Soit un ensemble de traces latency1.pcap, latency2.pcap, latency3.pcap et latency4.pcap correspondant un mme change au niveau applicatif. Elles sont captures ct client. Le fichier latency1 correspond au cas nominal o tout va bien. 1. Calculez les RTT pour chaque paquet de chaque trace. 2. Dterminer pour chaque trace, o se situe le goulet d'tranglement qui peut tre : le rseau qui induit des grandes latences, des temps d'attente ct client ou des temps d'attente ct serveur.