Vous êtes sur la page 1sur 39

Université de Franche-Comté

UFR Sciences et Techniques

Licence Professionnelle Systèmes Informatiques et Logiciels

RAPPORT
de STAGE
Surveillance Intelligente du Réseau
Vincent Chalnot Promotion 2010-2011
Rapport de stage - Surveillance Intelligente du Réseau

REMERCIEMENT
Je tiens à remercier tout particulièrement mon superviseur de stage, Professeur Selvakumar
Manickam, de m'avoir permis de travailler sur un sujet aussi motivant.
Je remercie également Professeur Jean-Christophe Lapayre, mon tuteur à l'université de Besançon
ainsi que Guillaume Paquette, responsable de la formation de la licence professionnelle en
informatique.
Enfin, j'aimerais remercier toute l'équipe du laboratoire Nav6 ainsi que mes collègues stagiaires,
tout particulièrement Julien Lamy, Sébastien Barbier et Yohann Pollonghini avec qui j'ai partagé
cette expérience.

2
Rapport de stage - Surveillance Intelligente du Réseau

UNIVERSITÉ DE FRANCHE-COMTÉ
-
LICENCE PROFESSIONNELLE D'INFORMATIQUE
Systèmes Informatiques et Logiciels
Conception et Développement Orienté Objet d'Applications Multi Tiers

Vincent Chalnot
Stagiaire
vincent.chalnot@gmail.com
www.carnet-de-route.info

Selvakumar Manickam
Superviseur de stage
selva@nav6.org

iNetmon Sdn. Bhd.


Entreprise d'accueil
Tingkat 2 Blok C,Sains@USM,
No. 10 Persiaran Bukit Jambul,
11900 Bayan Lepas,
Penang, Malaysia.
Tel: +6 604 653 5721
enquiry@inetmon.com
www.inetmon.com

3
Rapport de stage - Surveillance Intelligente du Réseau

TABLE DES MATIÈRES


1. Introduction 6
. . . .L'entreprise
1.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. .. .6.
. . . .L'application
1.2
. . . .Le
1.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. .. .6.
. . travail
..............
2. L'existant 7
. . . .Solutions
2.1 . . . . . . . . existantes
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.
2.1.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ............................7.
. . . . . iNetmon
2.1.2
. . . . . Wireshark
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8.
2.1.3
. . . . . AthTek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9.
. . . . . . .Netwalk
2.1.4
. . . . . PRTG
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10 ..
. . . .Bilan
2.2 . . . . .des
. . .solutions
. . . . . . . .existantes . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 . . . . . . ....
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. .11
. . . .LibPCap
2.3 . ..
2.3.1
. . . . . Open . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..........................11
. . . . . Source ...
2.3.2
. . . . . Facilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11
. . . . . . .d'utilisation ..
. . . .Documentation
2.4 . . . . . . . . . . . . .des . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ................................11
. . .Protocoles ....
..............
3. Développement 12
. . . .LibPCap
3.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 ..
3.1.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..13
. . . . . Initialisation . . . . . . . . . . . . ...
. . . .Affichage
3.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ................................13
. . . . . . . . .minimal ....
. . . .Principes
3.3 . . . . . . . .de . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. .14
. . base . ..
3.3.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..........................14
. . . . . Encapsulation ...
3.3.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15
. . . . . Désencapsulation ..
. . . .Base
3.4 . . . . de . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ................................19
. . .données ....
3.4.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..........................19
. . . . . MySQL ...
3.4.2
. . . . . Modèle
. . . . . . .de. . base
. . . . de . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19
. . .données ..
3.4.3
. . . . . Purge
. . . . . automatisée
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21 ..
. . . .Gestion
3.5 . . . . . . .de
. . la
. . mémoire . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 . . . . . . ....
3.5.1
. . . . . Capture
. . . . . . . des . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..........................21
. . . paquets ...
3.5.2
. . . . . Traitement
. . . . . . . . . .des
. . .paquets
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22 ..
..................
4. Tests 23
. . . .Utilisation
4.1 . . . . . . . . .de. . la
. . mémoire
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 ..
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23
. . . .Stabilité
4.2 . . . . . . . . . . . . . ..
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. .23
. . . .Stress-tests
4.3 . ..
4.3.1
. . . . . Débit
. . . . . et
. . perte
. . . . .de . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..........................23
. . paquets ...
..................

4
Rapport de stage - Surveillance Intelligente du Réseau

4.3.2
. . . . . Saturation
. . . . . . . . . de
. . .la. .base
. . . .de. .données
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24 ..
. . . .Environnement
4.4 . . . . . . . . . . . . .de
. . production . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 ....
..............
5. Conclusion 25

6. Annexes 27
. . . .Documentation
6.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 ..
6.1.1
. . . . . Description
. . . . . . . . . . des . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..27
. . . protocoles . . . . . . . . . . . . ...
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ................................28
. . . .Glossaire
6.2 ....
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. .30
. . . .Bibliographie
6.3 . ..
. . . .Blog
6.4 . . . . de . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. .32
. . .développement . ..
6.4.1
. . . . . Linux
. . . . . .CentOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..........................32
. . . . . . .installation ...
6.4.2
. . . . . Threaded . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32
. . . . . . . . Client ..
6.4.3
. . . . . Valgrind
. . . . . . . .memory
. . . . . . . check
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32 ..
6.4.4
. . . . . MySQL
. . . . . . . first
. . . . results
.......................................... . . . . . . . . . . . . . . . . ..
33
6.4.5
. . . . . MySQL
. . . . . . . robustness
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33 ..
6.4.6
. . . . . Switched
. . . . . . . . to
. . VMWare
........................................... . . . . . . . . . . . . . . . . ..
34
6.4.7
. . . . . Simple
. . . . . . .monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34
. . . . . . . . .views ..
6.4.8
. . . . . Database
. . . . . . . . Model
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35 ..
6.4.9
. . . . . Endianess
. . . . . . . . .headache,
. . . . . . . . the
. . . NUXI
. . . . . .problem
........................... . . . . . . . . . . . . . . . . ..
35
. . . .Événnements
6.5 . . . . . . . . . . . survenus
. . . . . . . .pendant . . . . . . . . . . . . . . . . . . . . . . . . . . . . ................................36
. . . . . . .le. .stage ....
6.5.1
. . . . . La
. . .révolution
. . . . . . . . .de . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..........................36
. .jasmin ...
6.5.2
. . . . . Le
. . .tsunami . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36
. . . . . . .Japonnais ..
6.5.3
. . . . . L'accident
. . . . . . . . .nucléaire
. . . . . . . .de
. . Fukushima
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36 ..
6.5.4
. . . . . Linux
. . . . . .a.20
. . .ans
........................................... . . . . . . . . . . . . . . . . ..
36
6.5.5
. . . . . Sony . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36
. . . . .piraté ..
6.5.6
. . . . . La
. . .mort
. . . . de
. . Ben
. . . . Laden
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36 ..
6.5.7
. . . . . Arrestation
. . . . . . . . . .de
. . DSK
......................................... . . . . . . . . . . . . . . . . ..
37
6.5.8
. . . . . IPv6
. . . . .day
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37 ..
..................

5
Rapport de stage - Surveillance Intelligente du Réseau

1. INTRODUCTION

1.1 L'entreprise
iNetmon fait partie du laboratoire Nav6 lui-même intégré à l'Université de Sciences de Malaisie
(plus communément appelée USM) de Penang.
L'entreprise iNetmon développe une suite logicielle de surveillance des réseaux informatiques
destinée aux administrateurs.
Le contexte socioculturel de l'entreprise très hétérogène est un point à souligner, la langue principale
est de loin l'anglais en raison de la diversité culturelle du laboratoire : Chinois, Malais et Indiens
sont les principales ethnies représentées par ordre d'importance.

1.2 L'application
iNetmon est à l'origine une plateforme développée en Java et utilisant WinPcap pour la capture de
paquets. L'utilisation de Java pour un tel logiciel n'est pas justifiée, en effet, de par ses dépendances
sur des librairies externes, l'application ne fonctionne que sous Windows et Java perd son intérêt
multiplateforme. De plus, en raison de son exécution dans une machine virtuelle et à la suite de
nombreuses mises à jour et modifications, le programme est devenu trop lourd, peu performant et
beaucoup de paquets sont perdus lors de la capture. L'interface a souffert de multiples modifications
sans jamais qu'une chartre graphique claire n'ait été définie.
L'idée de Professeur Selva fut de repartir de zéro pour développer la version 2 du logiciel en
parallèle de la première version dont le développement sera stoppé lorsque la version 2 sera arrivée
à maturité.

1.3 Le travail
J'ai été chargé de développer le moteur de capture de paquets, c'est-à-dire la partie du système qui
écoute sur une interface réseau pour mettre en base de données les paquets capturés.
Cette application étant destinée à tourner en tant que service sous Linux, et afin de respecter la
convention de nommage des services Linux, nous avons appelé le système de capture de paquets
iNetmond pour iNetmon Daemon. Daemon étant l'appellation des services Linux.
Afin d'optimiser au maximum les performances d'iNetmond, le moteur de capture de paquets a été
développé en C, ce qui permet de contrôler au maximum des appels systèmes et l'optimisation de la
mémoire. Le choix de la base de données s'est porté sur MySQL en raison de sa facilité d'utilisation
et de ses performances honorables. Les informations contenues dans la base de données sont
utilisées par une application web (PHP/HTML) pour permettre à l'utilisateur d'interfacer avec ces
données.
Au départ, mon superviseur m'a laissé seul sur ce projet pour poser les bases du système avec son
aide, puis j'ai rejoint une équipe de développeurs qui avait pour objectif d'utiliser les données
chargées en base MySQL par le moteur de capture pour les traiter et construire l'interface web.

6
Rapport de stage - Surveillance Intelligente du Réseau

2. L'EXISTANT

2.1 Solutions existantes


Nous nous sommes penchés sur les programmes permettant de surveiller le réseau ou plus
généralement de capturer les paquets transitant sur une interface réseau pour les analyser.
Pour chaque logiciel, on a surtout retenu les fonctionnalités les plus intéressantes qui sont présentées
ici.

2.1.1 iNetmon
Site web : http://www.inetmon.com/

Le prédécesseur de l'application sur laquelle nous avons travaillé, que nous avons toujours considéré
avec un pied d'égalité par rapport aux autres solutions disponibles pour éviter de se limiter à
reproduire une solution identique.

2.1.1.1 Le carnet d'adresses


Incontestablement la fonctionnalité la plus utile de la distribution, elle permet en effet de surveiller
qui est présent sur le réseau, à quel moment, en associant une adresse MAC aux différentes adresses
IP utilisées

Cet outil permet de détecter l'installation de nouvelles machine sur le réseau ainsi que les
changements d'adresses IP ou de nom d'hôte. Il est possible d'associer des informations
supplémentaires manuellement sur chaque machine afin notamment d'identifier les personnes
physiques ou les services utilisant une machines.

7
Rapport de stage - Surveillance Intelligente du Réseau

2.1.2 Wireshark
Site web : http://www.wireshark.org/

Wireshark est avant tout un logiciel d'analyse de paquets et de trafic plus qu'un logiciel de
surveillance, et dans ce domaine il est de loin le meilleur.

2.1.2.1 Les " Dissectors"


Dans le jargon des développeurs de Wireshark, les dissectors sont les filtres utilisés pour analyser
un protocole réseau. De par la quantité phénoménale de dissectors présents dans Wireshark, plus de
105 000 à la version 1.4.5, celui-ci s'impose comme la référence en matière d'analyse.
La présentation des différents en-têtes pour un paquet permet de comprendre en un coup d'oeil la
structure des différents protocoles présents dans le paquet. Cette vue qui combine à la fois une
arborescence de type clé=valeur et une vue hexadécimale du paquet a été d'une grande aide lors de
l'écriture de nos propres dissectors.

On note ici le surlignage du champ actif qui permet d'identifier un champ particulier au sein du
dump hexadécimal de l'en-tête du paquet.
Même si Wireshark n'entre pas exactement dans la catégorie des logiciel de surveillance du réseau,
il n'en reste pas moins une référence incontournable dans le domaine en raison de sa puissance
analytique.

8
Rapport de stage - Surveillance Intelligente du Réseau

2.1.3 AthTek Netwalk


Site web : http://www.athtek.com/netwalk.html

Ce logiciel fait partie des solutions professionnelles les plus simples du marché, il est par
conséquent moins abouti que ses concurrents, mais possède une particularité appréciable.

2.1.3.1 Le tableau de bord


Regroupe en une seule vue l'ensemble des éléments important dont un administrateur réseau pourrait
avoir besoin. Cette vue est modulable à volonté ce qui permet à chacun d'adapter ses propres
indicateurs.

Ce logiciel ne nous a pas convaincu lors de son utilisation, ses fonctionnalités sont trop limitées par
rapport aux autres solutions existantes, mais le tableau de bord nous a agréablement surpris par son
aspect pratique et fonctionnel.

9
Rapport de stage - Surveillance Intelligente du Réseau

2.1.4 PRTG
Site web : http://www.paessler.com/prtg/

Développé par Paessler, PRTG est une solution de surveillance de réseaux très aboutie permettant
de surveiller des réseaux distants, des serveurs distants et possédant une grande variété d'interfaces
utilisateur dont plusieurs interfaces web.
La principale faiblesse de ce logiciel est sa grande complexité qui ne permet pas une prise en main
rapide, même pour un administrateur réseau confirmé.

2.1.4.1 Interface web


Parce que les applications se développent de plus en plus dans le Cloud, et parce qu'il y a nécessité
pour un administrateur réseau de pouvoir accéder aux informations de ses serveurs à tout instant,
une interface web est aujourd'hui une fonctionnalité incontournable pour tout logiciel de gestion.
Une interface web offre aussi la possibilité d'être utilisée sur un smartphone avec presque les
mêmes performances et possibilités qu'un ordinateur de bureau.

10
Rapport de stage - Surveillance Intelligente du Réseau

2.1.4.2 Modulabilité
Les différentes interfaces (web, mobile et software) se ressemblent énormément et se basent sur la
possibilité pour l'administrateur d'éditer toutes les vues de l'application. Néanmoins, le jargon utilisé
pour décrire les différents éléments du système manquent de clarté et compliquent l'utilisation de
cette solution.

2.2 Bilan des solutions existantes


Nous avons passé beaucoup de temps à étudier les solutions existantes afin de déterminer quelles
fonctionnalités devaient être présentes dans iNetmon 2, ce travail a néanmoins d'avantage servit les
développeurs de la partie interface dont je ne faisais pas partie.
Participer à cette étude m'a tout de même permis de donner mon avis sur les choix techniques à
implémenter ou non.

2.3 LibPCap
Site web: http://www.tcpdump.org/

LibPcap est incontestablement la librairie Open Source la plus performante pour capturer des
paquets sur une interface réseau. Nombre de logiciels prestigieux embarquent cette librairie ou son
équivalent Windows WinPCap.
Cette librairie propose une interface de haut niveau pour les systèmes de capture de paquets. Tous
les paquets du réseau, même ceux destinés à d'autres hôtes, sont accessibles par le biais de cette
interface.

2.3.1 Open Source


Comme pour n'importe quel projet Open Source, la force de libpcap provient de son potentiel
d'évolution. Les développeurs ont pu contribuer à améliorer continuellement le code avec l'évolution
du matériel et des systèmes.

2.3.2 Facilité d'utilisation


L'autre atout de LibPCap est sa facilité d'implémentation dans un programme, particulièrement en C
comme c'est le cas pour notre projet.

2.4 Documentation des Protocoles


La plus grosse difficulté fut incontestablement de réunir une documentation complète et uniformisée
des protocoles réseau les plus utilisés. En effet, il n'existe à ce jour aucune documentation uniforme
décrivant les structures de ces protocoles.
Certainement l'étape la plus chronophage de ce projet, l'écriture d'un manuel des protocoles réseau
les plus communément rencontrés a nécessité de réunir toutes les documentations existantes sur le
sujet. Cette étape est détaillée en annexe dans la section "Documentation".

11
Rapport de stage - Surveillance Intelligente du Réseau

3. DÉVELOPPEMENT
Le développement d'iNetmond a commencé le 20 mars après avoir jeté les bases du système sur
papier. On décrira ici les étapes principales du développement aussi bien en terme de problèmes
rencontrés que de solutions trouvées. iNetmon 2 est toujours en cours de développement à l'heure
actuelle, mais fonctionne en partie, notamment pour ce qui est de la capture de paquets.

3.1 LibPCap
Une des premières étapes du développement fut de tester la librairie libpcap pour se familiariser
avec ses méthodes. Ci-dessous un exemple de programme utilisant libpcap dans lequel on a retiré la
gestion des exceptions pour plus de simplicité.

#include
#include
int main(int argc, char *argv[]){
pcap_t *handle; // Session handle
char *dev; // The device to sniff on
char errbuf[PCAP_ERRBUF_SIZE]; // Error message
struct bpf_program fp; // The compiled filter
char filter_exp[] = "tcp"; // The filter expression
struct pcap_pkthdr header; // The header that pcap gives us
const u_char *packet; // The actual packet

/* Define the device */


dev = pcap_lookupdev(errbuf);
/* Open the session in promiscuous mode */
handle = pcap_open_live(dev, BUFSIZ, 1, 1000, errbuf);
/* Compile and apply the filter */
pcap_compile(handle, &fp, filter_exp, 0, net);

pcap_setfilter(handle, &fp);
/* Grab a packet */
packet = pcap_next(handle, &header);
/* Print its length */
printf("The captured packet has a length of [%d]\n", header.len);

/* And close the session */


pcap_close(handle);

return(0);
}

12
Rapport de stage - Surveillance Intelligente du Réseau

3.1.1 Initialisation
Pour gérer une session de capture avec libpcap, on a besoin d'initialiser les variables suivantes:

pcap_t * handle : Le gestionnaire de session qui permet à la librairie de conserver les mêmes
paramètres lors d'une session de capture.
char * dev : Indique le périphérique utilisé pour la capture de paquets.
char errbuf[PCAP_ERRBUF_SIZE] : Sert de buffer pour récupérer les messages d'erreur
venant de la librairie.
struct bpf_program fp : Est une structure utilisée par libpcap pour filtrer les paquets entrants.
char filter_exp[] : Est la chaîne de caractères humainement lisible contenant l'expression du
filtre.
struct pcap_pkthdr header : Est la structure de l'en-tête retournée par Pcap pour chaque
paquet capturé.
const u_char* packet : Le pointeur vers le début du paquet.

Pendant une capture, Pcap charge en mémoire un paquet et retourne deux pointeurs. Le premier
pointeur donne la structure contenant les informations relatives au paquet capturé, comme le temps,
la taille et le numéro du paquet. Le second pointeur pointe sur le début du paquet en mémoire, c'est
à partir de là qu'on va commencer à lire le contenu de la mémoire pour désencapsuler le paquet.

3.2 Affichage minimal


Afin de pouvoir tester la capture des paquets visuellement, on a mis en place une interface minimale
en mode terminal pour représenter chaque paquet capturé.

À partir de là, on a pu commencer à disséquer les paquets individuellement pour afficher leurs
informations dans le terminal.

13
Rapport de stage - Surveillance Intelligente du Réseau

3.3 Principes de base

3.3.1 Encapsulation
Un paquet est construit par encapsulation de multiples protocoles. Prenons l'exemple d'un
navigateur web qui veut envoyer une requête à un serveur. Un paquet va être construit en
superposant des couches de protocoles les unes sur les autres.
Au départ, le navigateur web veut envoyer la requête suivante:

GET / HTTP/1.1
Host: www.google.com

Cette requête va être encapsulée pour être envoyée sur le réseau, ce n'est généralement pas le
programmeur qui s'occupe de l'encapsulation, mais la couche réseau du système d'exploitation.
Chaque couche va être ajoutée successivement, d'abord la couche transport TCP puis la couche
réseau IPv4 et enfin la couche liaison Ethernet. L'exemple utilisé est très simple et en fonction de
l'application, l'encapsulation peut devenir très compliquée.
Au final, le paquet peut être représenté ainsi:

Bytes 0 1 2 3

Bits 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 0 Destination

4 32 Destination (Continuation) Source


8 64 Source (Continuation)

12 96 Ethertype Version IHL TOS


16 128 Total Length Identification

20 160 Flags Offset TTL Protocol


24 192 Checksum Source

28 224 Source (Continuation) Destination


32 256 Destination (Continuation) Source port

36 288 Destination port Sequence number


40 320 Sequence number (Continuation) Acknowledgment number

44 352 Acknowledgment number (Continuation) Data offset Reserved Flags


48 384 Window size Checksum

52 416 Urgent pointer HTTP DATA


56 448 HTTP DATA (Continuation)

60 480 HTTP DATA (Continuation)


64 512 HTTP DATA (Continuation)

68 544 HTTP DATA (Continuation)


72 576 HTTP DATA (Continuation)

76 608 HTTP DATA (Continuation)


80 640 HTTP DATA (Continuation)

84 672 HTTP DATA (Continuation)


88 704 HTTP DATA (Continuation)

92 736 HTTP DATA (Continuation)

On peut voir, en jaune tout en haut la couche Ethernet, puis juste en dessous en vert la couche IPv4,
la couche TCP en bleu et les données HTTP en blanc.

14
Rapport de stage - Surveillance Intelligente du Réseau

Ce paquet va transiter sur le réseau à travers une multitude de routeurs, de switch et de répartiteurs
qui vont probablement encapsuler et désencapsuler la couche Liaison (Ethernet) un grand nombre de
fois, mais le paquet arrivera à destination avec la même information qu'au départ.
La principale problématique lorsqu'on veut analyser un paquet vient du fait qu'on ne sait pas ce qu'il
contient avant d'avoir commencé à le lire.
Il faut donc, pour accéder à l'information de la couche application (ici HTTP), désencapsuler le
paquet.

3.3.2 Désencapsulation
Lorsqu'on veut lire ce que contient un paquet, on doit le désencapsuler, c'est-à-dire retirer les
couches de protocoles une par une en commençant par la plus basse. On gardera ici l'exemple du
paquet précédent, mais il faut garder à l'esprit que l'on ne connait pas la structure du paquet avant
d'avoir commencé à l'analyser.
Dans le cas de Pcap, le paquet contenu en mémoire est accessible par l'intermédiaire d'un pointeur
non typé, on peut donc lire n'importe quelle partie du paquet à partir de ce pointeur, mais il faut
connaître d'avance ce que l'on veut récupérer, notamment le type de la variable.

3.3.2.1 Ethernet
On doit connaître la couche la plus basse du paquet avant de pouvoir l'analyser, dans l'immense
majorité des cas il va s'agir d'Ethernet. Toutefois, il existe plusieurs types de trame Ethernet, la plus
courante est Ethernet type II mais on peut aussi trouver de l'Ethernet IEEE 802.3 avec LLC et
éventuellement SNAP. On ne peut pas savoir d'avance à quel type de paquet on a affaire.
La première étape est de considérer qu'il s'agit d'une trame Ethernet type II. On va donc lire dans la
mémoire en castant chaque champ de la structure d'un paquet Ethernet pour recréer une structure
propre en mémoire.

#define ETHER_ADDR_LEN 6
struct layer_ethernet {
u_char destination[ETHER_ADDR_LEN];
u_char source[ETHER_ADDR_LEN];
u_short type;
}

Le principal problème lors de la manipulation de structures de mémoire en provenance du réseau est


le problème de l'endianness. L'ordre des octets n'est généralement pas le même entre la machine et
le réseau, on ne peut donc pas caster la structure directement comme suit:

struct layer_ethernet * ethernet = (struct layer_ethernet *) packet;

Ici, le pointeur vers le début du paquet est packet et le fait de caster le paquet de la sorte va inverser
les deux octets du champ type. Si le type venant du réseau a pour valeur 0x2104, la valeur
enregistrée dans la structure ethernet sera 0x0421. Le problème ne se pose pas pour les adresses
étant donné qu'on les stocks dans des tableaux d'octets, l'ordre est respecté.

15
Rapport de stage - Surveillance Intelligente du Réseau

Ce problème, connu sous le nom du NUXI vient du fait que les données transférées sur le réseau
sont toujours en Big-Endian (on parle de network byte order), alors que l'architecture des
processeurs x86 est Little-Endian. L'endianness peut changer en fonction de l'architecture du
processeur, mais aussi en fonction du système, car certains processeurs supportent les deux
architectures. De plus, le problème peut devenir plus complexe avec la variation de l'unité atomique
du système et la possibilité d'avoir une architecture en Middle-Endian.
Dans notre cas, la solution nécessite une réécriture plus complexe de la méthode précédente. On
doit commencer par libérer un espace en mémoire pour la nouvelle structure.

struct layer_ethernet* packet_ethernet = (struct layer_ethernet*) malloc


(sizeof(struct layer_ethernet));

On veut ensuite prendre individuellement chaque valeur du paquet pour les copier dans la nouvelle
structure.

u_short i;
for( i = 0; i < ETHER_ADDR_LEN; i++ ){
packet_ethernet->destination[i] = (*(u_char*) (packet + i));
}
for( i = ETHER_ADDR_LEN; i < (ETHER_ADDR_LEN * 2); i++ ){
packet_ethernet->source[i] = (*(u_char*) (packet + i));
}
packet_ethernet->type = ntohs(*(u_short*) (packet + 12));

Lors de la conversion du type ou Ethertype, on utilise la fonction ntohs() afin de convertir l'ordre
des octets vers celui de la machine. L'exemple donné ici est simplifié par rapport à la version finale
qui utilise d'avantage de fonctions pour standardiser la copie en mémoire quelque soit le protocole.
Une fois la structure en mémoire, on peut s'intéresser à la valeur de l'Ethertype qui indique le type
du protocole supérieur et qui peut éventuellement permettre de corriger le type de la frame Ethernet.

≤ 0x05DC : Indique que la trame Ethernet est en fait de type IEEE 802.3, dans ce cas, un autre
filtre doit être appelé pour analyser de nouveau le paquet depuis le début.
0x0800 : IPv4
0x86DD : IPv6
0x0806 : ARP
0x8100 : IEEE 802.1Q
0x.... : Il existe plus de 3000 valeurs enregistrées.
Il existe une liste exhaustive des protocoles correspondant aux Ethertype, cette liste ne présente que
peu d'intérêt car elle n'a jamais été mise à jour avec l'évolution du matériel.
http://standards.ieee.org/develop/regauth/ethertype/eth.txt

Dans le cas de notre paquet, le type est IPv4 0x0800, ce qui nous permet de continuer la lecture du
paquet en sachant quelle type de grille de lecture appliquer.
On veut faire avancer le pointeur vers la trame suivante, on écrit donc:

packet = (const u_char *) packet + 14;

16
Rapport de stage - Surveillance Intelligente du Réseau

Ce qui permet d'avancer le pointeur en mémoire de 14 octets qui correspond à la longueur d'un en-
tête Ethernet type II.

3.3.2.2 IPv4
Le principe est toujours le même avec quelques subtilités concernant les champs dont la longueur
n'est pas un nombre fini d'octets où on a besoin d'appliquer un bitmask pour récupérer la valeur
correcte du champ. Étant donné qu'il est fortement déconseillé de manipuler en mémoire des
variables de longueur inférieure à un octet (cela peut engendrer des comportements différents en
fonction des compilateurs), on préfère enregistrer ces champs dans une variable dont le type est
légèrement supérieur.
Dans l'exemple utilisé, IPv4 contient les champs version et header_len dont la longueur est égale à
4 bits, soit un demi-octet. Lors de la définition de la structure IPv4, on préfère les enregistrer en tant
que u_char, c'est à dire sur un octet.

struct layer_ipv4 {
u_char version;
u_char header_len;
...
}

Au moment de l'enregistrement de la structure du paquet en mémoire, on utilise les opérateurs >>


(bitswap) et & (bitmask) afin de ne garder que les valeurs correctes des champs.

packet_ipv4->version = (*(u_char*) packet) >> 4;


packet_ipv4->header_len = (*(u_char*) packet) & 0x0f;

Penchons-nous un peu plus en détail sur cette opération, et considérons la structure suivante où
version=4 (0100b) et header_len=5 (0101b). On part du premier octet casté depuis le pointeur du
paquet (qui commence maintenant au début d'IPv4): (*(u_char*) packet)

Bits 0 1 2 3 4 5 6 7
0 1 0 0 0 1 0 1

Lorqu'on effectue la première opération >> 4, on décale de 4 bits le champ vers la droite.

Bits 0 1 2 3 4 5 6 7
0 0 0 0 0 1 0 0

On obtient bien un octet de valeur 4.


En ce qui concerne l'autre opérateur, on applique un bitmask, c'est-à-dire qu'on fait un ET logique
bit à bit qui retourne 0 si un des deux bits est égal à 0 et 1 si les deux bits sont égaux à 1.

Bits 0 1 2 3 4 5 6 7

0 0 0 0 1 1 1 1
0 1 0 0 0 1 0 1

Ici, le bitmask appliqué est 0x0f ce qui correspond à 00001111b et le résultat est bien la valeur 5:

17
Rapport de stage - Surveillance Intelligente du Réseau

Bits 0 1 2 3 4 5 6 7
0 0 0 0 0 1 0 1

Il s'agit ensuite de savoir quel est le protocole suivant et à partir de quel adresse mémoire celui-ci
commence.
La longueur d'un en-tête IPv4 peut changer en fonction du nombre d'options qu'il contient, dans
notre cas on considérera que le header_len prend la valeur 5 : la longueur de l'en-tête IPv4 en égale
à 5 word, soit 5*4=20 octets qui est en fait la longueur minimale d'un en-tête IPv4. On sait donc que
le prochain protocole commence 20 octets plus loin:

packet = (const u_char *) packet + header_len*4;

Pour connaître le type du prochain protocole, on s'en réfère au champ protocol de l'en-tête IPv4:

0 - HOPOPT: IPv6 Hop-by-Hop Option


1 - ICMP: Internet Control Message
2 - IGMP: Internet Group Management
3 - GGP: Gateway-to-Gateway
4 - IPv4: IPv4 encapsulation
5 - ST: Stream
6 - TCP: Transmission Control
... Il existe à ce jour 142 protocoles référencés.
La liste complète est gérée et maintenue à jour par l'IANA et on peut récupérer la version XML à
l'adresse suivante:
http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xml

Dans notre cas, le numéro 6 indique que la trame supérieure est de type TCP.

3.3.2.3 TCP
Les principes vus pour Ethernet et IPv4 s'appliquent sur toutes les structures des autres protocoles. Il
est donc crucial de bien appréhender le concept de bitswap et bitmask ainsi que les problèmes
d'endianness pour automatiser la mise en mémoire des protocoles.

3.3.2.4 HTTP
Enfin, une fois toutes les couches retirées, on obtient la requête HTTP envoyée par le client au
serveur. Pour le moment iNetmond ne capture pas le contenu de la couche applicative, l'analyse des
protocoles de plus haut niveau sera une des futures étapes du développement de l'application.

18
Rapport de stage - Surveillance Intelligente du Réseau

3.4 Base de données


L'étape suivante du développement fut de mettre en place la base de données afin de stocker les
paquets capturés dans l'attente d'un traitement par une autre partie du système.
MySQL a été un choix difficile, il existe en effet à ce jour deux gestionnaires de base de données
fiables et performants sous licence libre : MySQL et PostgreSQL. Après un long moment passé à
s'interroger sur les bienfaits et les désavantages de l'un ou de l'autre, il s'est avéré que les deux
systèmes étaient si proches l'un de l'autre qu'il était impossible de les départager objectivement.
Nous avons au final choisi MySQL par simple préférence, car nous connaissions déjà le système et
étions familiers de son fonctionnement.

3.4.1 MySQL
Une fois décidé d'utiliser MySQL comme gestionnaire de base de données, une nouvelle question
s'est posée sur le choix du moteur de stockage. Il existe en effet deux moteurs de stockage
populaires sur MySQL: MyIsam et InnoDB.
MyIsam est le moteur par défaut de MySQL, il est supposé être plus rapide qu'InnoDB car il ne gère
pas les transactions et les clés étrangères. InnoDB est le moteur le plus couramment utilisé par les
développeurs nécessitant une base de données transactionnelle et relationnelle.
Nous avons pu trouver une revue de test sur internet mettant en évidence les faiblesses et les points
forts de ces deux moteurs (ainsi que d'un troisième moins connu: Falcon). Ces tests sont disponibles
à l'adresse suivante:
http://www.mysqlperformanceblog.com/2007/01/08/innodb-vs-myisam-vs-falcon-benchmarks-part-1/

Il ressort de ces tests qu'InnoDB est en fait plus performant que MyIsam à quelques exceptions près.
Le choix s'est donc porté sur InnoDB.
Nous n'avons pas modifié particulièrement l'installation du serveur MySQL sur la machine de test,
mais il semblerait qu'il y aurait possibilité d'optimiser les paramètres du serveur pour obtenir de
meilleures performances. L'équipe de développement Web travaille actuellement sur le serveur de
production pour améliorer ce point.

3.4.2 Modèle de base de données


Le modèle de la base de données côté capture des paquets est extrêmement simple, nous nous
sommes en effet penchés uniquement sur le problème de stocker chaque en-tête de paquet en base
de données sans trier ou sélectionner les champs. Au final, on peut interroger la base de données
directement sur n'importe quel champ de n'importe quel en-tête de n'importe quel paquet capturé.

19
Rapport de stage - Surveillance Intelligente du Réseau

On notera que le nom des tables pour chaque protocole est construit à partir le l'id du protocole dans
la table protocol. Ainsi, la première ligne de la table protocol correspond à Ethernet donc proto_1
correspond à la table Ethernet.
Ce modèle présente des inconvénients en terme d'espace de stockage, mais permet aux développeurs
de la couche supérieure de l'application (les développeurs web dans notre cas) de sélectionner
précisément les champs dont ils ont besoin pour construire leur propre base de données tout en leur
laissant la possibilité d'accéder ultérieurement à d'autres champs sans avoir besoin de modifier la
base de données et le service de capture.

20
Rapport de stage - Surveillance Intelligente du Réseau

3.4.3 Purge automatisée


Comme nous avons pu le voir précédemment, tous les champs sont enregistrés en base de données,
ce qui présente un inconvénient en terme d'espace de stockage utilisé.
Une fois les informations désirées extraites par la couche supérieure de l'application, il est donc
nécessaire de purger la base de données pour libérer la mémoire.
L'idée de base est qu'il faut, à différents instants dans le temps, conserver de moins en moins
d'informations sur les paquets pour finir par ne garder que les statistiques globales de la journée
après un certain temps.
Les différentes options en ce qui concerne la purge de la base de données ont été étudiées, puis
laissées entre les mains de l'équipe web.

3.5 Gestion de la mémoire


Un soin particulier a été mis sur l'optimisation de la mémoire par le système afin de limiter la perte
de paquets qui survient lorsque la mémoire tampon de Pcap est pleine.

3.5.1 Capture des paquets


Lorsque Pcap retourne le pointeur vers le paquet en mémoire, il attend que la fonction qui est
supposée traiter le paquet se termine pour écraser le paquet en mémoire et écrire le paquet suivant.
Concrètement, on utilise la fonction pcap_loop() qui prend comme paramètre principal la référence
vers la fonction qui traite chaque paquet.

pcap_loop(pcap_handle, NUM_PACKETS, buffer_packet, NULL);

La fonction en question est buffer_packet() dont le constructeur doit être comme suit:

void buffer_packet(u_char *args, const struct pcap_pkthdr *header, const u_


char *packet);

Lorsqu'on lance la fonction pcap_loop() (qui est un appel bloquant), Pcap va capturer NUM_
PACKETS paquets en appelant à chaque fois la fonction buffer_packet().
L'objectif ici est de minimiser le temps pris par la fonction buffer_packet() à chaque exécution. On
ne peut pas en effet se permettre que l'analyse de chaque paquet soit bloquante au niveau du système
de capture de paquets, on utilise donc une mémoire tampon de type FIFO (First-In-First-Out) sous la
forme d'une liste chaînée.
À chaque fois qu'un nouveau paquet est capturé, il est copié intégralement dans un nouvel espace
mémoire et ajouté en fin de liste.

21
Rapport de stage - Surveillance Intelligente du Réseau

Il s'agit d'un scénario classique de liste chaînée ou chaque structure contient un pointeur vers la
structure suivante, ce qui permet de parcourir la liste que dans un seul sens.

3.5.2 Traitement des paquets


Une fois les paquets insérés dans la mémoire tampon tel qu'expliqué précédemment, il faut les
analyser et les supprimer de la mémoire tampon. Afin de faire cette opération en parallèle de la
capture de paquets, on utilise des threads.
Un thread s'occupe de traiter le paquet en haut de la liste afin de l'analyser et de le mettre en base de
données. Si la mémoire tampon est vide, le thread se met en pause pendant 500 ms puis se lance de
nouveau. La fin de la capture est signalée par Pcap dans une variable globale ce qui permet aux
threads de s'arrêter à partir du moment où la mémoire tampon est vide.

Il est à noter que lorsque plusieurs threads travaillent en concurrence, au moment où un thread isole
un paquet pour le traiter, il y a un risque que deux threads isolent en même temps le paquet de tête
de liste, ce qui aurait pour conséquence le double traitement d'un paquet. Afin de prévenir à cette
éventualité, on place un verrou mutex au moment de l'isolation, cela permet de bloquer les threads
qui tenteraient d'accéder simultanément au paquet de tête.

22
Rapport de stage - Surveillance Intelligente du Réseau

4. TESTS

4.1 Utilisation de la mémoire


Une des principales forces du langage C est de permettre une allocation précise de la mémoire. Cet
avantage peut devenir très rapidement un inconvénient si l'allocation n'est pas effectuée
correctement. Il n'existe pas de ramasse-miette comme dans les langages de plus haut niveau, si une
partie de la mémoire n'est pas libérée après avoir été allouée, elle restera en utilisation jusqu'à la fin
du programme.
Afin de détecter des fuites de mémoire qui auraient pour conséquence de faire planter purement et
simplement l'application, nous avons utilisé Valgrind, une application Open Source qui permet de
débugger et de profiler un exécutable sous Linux.
Il s'avère que les tests incluant Valgrind étaient nécessaires puisqu'ils ont permis de détecter à
plusieurs reprises des portions de mémoire qui n'étaient pas libérées correctement.
Valgrind à été d'une aide précieuse lors du développement d'iNetmond, et je ne peux que conseiller
vivement son utilisation par tous les développeurs C.

4.2 Stabilité
A plusieurs reprises lors du développement, iNetmond a été laissé en marche pendant de longues
périodes de temps (plus de 24h), période pendant laquelle nous avons enregistré les ressources
utilisées, ceci afin de détecter d'éventuelles instabilités. Il s'est avéré que le système était
extrêmement stable et ne semblait pas être affecté par la durée pendant laquelle il était en marche.

4.3 Stress-tests

4.3.1 Débit et perte de paquets


Le principal argument en faveur du changement de plateforme et de langage entre iNetmon premier
du nom et son successeur était l'inefficacité du système à supporter de lourdes charges en terme de
débit. Il fallait prouver que le nombre de paquets perdu était inférieur avec iNetmond qu'à celui de
son précurseur.
Le teste principal permettant de détecter la perte de paquet consiste à envoyer un grand nombre de
paquets en une seule fois sur l'interface réseau de la machine et de comparer le nombre de paquets
injectés et le nombre de paquets enregistrés par le système.
Nous avons injecté à plusieurs reprises 3000 paquets sur l'interface réseau, ce qui prenait environ
10 ms pour la machine émettrice et 3 à 4 secondes pour que le système les traites, à chaque fois, on
arrivait à un nombre de paquets perdu compris entre 0 et 3, ce qui correspond à un taux inférieur ou
égal à 1 %.

23
Rapport de stage - Surveillance Intelligente du Réseau

iNetmon 1 en comparaison affichait un taux de perte d'environ 11 %. Le problème est que les deux
tests n'ont pas été effectués exactement dans les mêmes conditions, notamment en ce qui concerne le
système d'exploitation (Windows pour iNetmon et Linux pour la version 2), cela indique néanmoins
une progression certaine entre les deux systèmes.

4.3.2 Saturation de la base de données


Après avoir laissé fonctionner la capture de paquet pendant plus de 24h, le nombre de paquets
capturé avoisine aisément le million. Nous avons décidé pendant un temps de ne pas remettre à zéro
la base de données afin de tester sa résistance à la saturation.
Au bout d'un temps, un peu plus de 10 millions de paquets étaient présents en base de données sans
qu'aucun problème notable soit survenu.
Le principal problème avec la présence d'autant de paquets était lors de l'interrogation de la base où
des requêtes, même simples, pouvaient prendre plusieurs minutes pour s'exécuter.

4.4 Environnement de production


Un des problèmes qui risque de se poser avec un environnement de production est le nombre bien
supérieur de paquets à insérer dans la base de données et il se pourrait que MySQL puisse être le «
bottleneck », le goulot d'étranglement du système.
Nous avons commencé à préparer une machine pour tester iNetmond dans un environnement de
production (port mirroring sur le routeur), mais il a été décidé d'abandonner les tests en attendant les
résultats de l'équipe de développement web sur le système de purge de la base de données.
Aucun résultat acceptable n'a donc pour l'instant permis de juger de la capacité d'iNetmond à
fonctionner en environnement de production.
Il s'agit là d'une lacune, mais il faut rester conscient que le projet n'est qu'à ses débuts et que les
spécifications finales du système (notamment sur la base de données et sur l'interface) n'ont pas
encore été fixées définitivement. Malgré ce fait, iNetmond s'est montré plus que capable dans un
environnement de test avec une machine de bureau et une utilisation du réseau moyenne.

24
Rapport de stage - Surveillance Intelligente du Réseau

5. CONCLUSION
Ce projet a été très motivant dès le départ pour plusieurs raisons:

D'une part, Professeur Selva m'a réellement intégré dans le processus de réflexion visant à
définir les choix techniques nécessaires au développement du projet.
Professeur Selva m'a aussi accordé une grande confiance en ce qui concernait l'implémentation
de ces choix techniques et cela m'a permis de repousser mes limites en tant que développeur.
D'autre part, le but de l'application finale qui est de surveiller les réseaux informatiques
coïncide pleinement avec une problématique de plus en plus courante: la sécurité des réseaux.
Ce sujet me passionne, notamment en raison de sa perpétuelle évolution.

Au final, j'ai eu l'occasion de perfectionner énormément mes compétences en programmation en


langage C ainsi que mes connaissances du fonctionnement des réseaux, notamment en ce qui
concerne le fonctionnement des protocoles de la suite Internet: Ethernet, IPv4, IPv6, TCP et UDP. Je
mettrais un point particulier sur IPv6 qui n'a jamais été autant d'actualité avec la récente pénurie
d'adresses IPv4 et la journée d'hier: le 8 juin 2011 était l'IPv6 day.
Ce stage m'a apporté énormément, aussi bien humainement que professionnellement. La Malaisie a
été une expérience nouvelle et formidable qui m'a permis de découvrir d'autres cultures, d'autres
mentalités et plus généralement d'autres gens intéressants.

25
Rapport de stage - Surveillance Intelligente du Réseau

26
Rapport de stage - Surveillance Intelligente du Réseau

6. ANNEXES

6.1 Documentation
Un certain nombre d'outils de suivi ont été mis en place sur le projet que nous détaillerons ici.

6.1.1 Description des protocoles


Afin de standardiser au maximum la documentation sur les protocoles, nous avons créé un format
XML pour décrire chaque protocole.
Cette spécification devait résoudre plusieurs problématiques liées à la structure des protocoles
réseau.

Champs : La structure d'un protocole est séparée en champs.


Valeurs possibles : Sur certains champs, on veut pouvoir décrire les effets de certaines
valeurs.
Encapsulation : Des champs peuvent être encapsulés dans d'autres champs.
Dynamisme : Un champ peut avoir une taille variable dans la structure d'un paquet, il y a
donc nécessité de faire référence à la valeur d'un autre champ dans certaines propriétés.
Présence conditionnelle : Certains champs peuvent apparaître ou non en fonction de la valeur
prise par un champ précédent, on veut pouvoir indiquer la présence conditionnelle de certains
éléments

Ces deux dernières spécificités ont été abordées lors de la création du format, mais ne sont pas
encore implémentées.
La documentation concernant les protocoles est encore en cours de construction et aboutira
probablement à un livre commercialisé en version papier et électronique.

27
Rapport de stage - Surveillance Intelligente du Réseau

6.2 Glossaire
Adresse IP :
Numéro d'identification qui est attribué à chaque branchement d'appareil à un réseau informatique
utilisant le protocole Internet.
Adresse MAC :
Identifiant physique stocké dans une interface réseau et utilisé pour attribuer mondialement une
adresse unique au niveau de la couche de liaison.
Bitmask :
Désigne des données utilisées pour des opérations bit à bit, permettant de modifier les valeurs d'un
groupe de bits en une seule opération.
Bitswap :
Opération visant à décaler les bits en mémoire d'un nombre de « cases » définies.
Bottleneck :
Littéralement « Goulot de bouteille », désigne une partie d'un système pouvant être la cause d'une
perte de performances ou d'informations.
Buffer :
Mémoire tampon, partie de la mémoire que l'on réserver pour travailler avec.
Cloud :
Le Cloud Computing est un concept qui consiste à déporter sur des serveurs distants des traitements
informatiques traditionnellement localisés sur des serveurs locaux ou sur le poste client de
l'utilisateur.
Daemon :
Désigne un processus qui s'exécute en arrière-plan plutôt que sous le contrôle direct d'un utilisateur
Dissectors :
Filtre permettant de disséquer un paquet pour l'analyser.
Encapsulation :
Procédé consistant à inclure les données d'un protocole dans un autre protocole.
Endianness :
Certaines données telles que les nombres entiers peuvent être représentées sur plusieurs octets.
L'ordre dans lequel ces octets sont organisés en mémoire ou dans une communication est appelé
endianness (mot anglais traduit par « boutisme » 1 ou par « endianisme »).
FIFO :
First In First Out, premier arrivé premier servi.
IANA :
L'Internet Assigned Numbers Authority est une organisation dont le rôle est la gestion de l'espace
d'adressage IP d'Internet
Mutex :
Primitive de synchronisation utilisée en programmation informatique pour éviter que des ressources
partagées d'un système ne soient utilisées en même temps.
NUXI :
Le problème NUXI fait référence à un problème d'endianness. Si on veut envoyer la chaîne « UNIX
» en regroupant deux octets par mot entier de 16 bits sur une machine de convention différente, alors
on obtient NUXI.

28
Rapport de stage - Surveillance Intelligente du Réseau

Paquet :
En réseau, le paquet est l'entité de transmission permettant de faire passer un message d'une
machine à une autre.
Pcap :
Packet Capture, fait généralement référence à la librairie LibPcap.
Pointeur :
Un pointeur est une variable contenant une adresse mémoire.
Protocole :
Dans les réseaux informatiques et les télécommunications, un protocole de communication est une
spécification de plusieurs règles pour un type de communication particulier.
Thread :
Les threads sont des processus partageant la même mémoire virtuelle avec le programme dont ils
font partie.
WinPcap :
Equivalent Windows de la librairie LibPCap permettant de capturer des paquets sur une interface
réseau.

29
Rapport de stage - Surveillance Intelligente du Réseau

6.3 Bibliographie
Nmap TCP-IP reference :
http://nmap.org/book/tcpip-ref.html

SolarWinds: Network Management Software & Network Monitoring :


http://www.solarwinds.com/

MySQL :: MySQL 5.0 Reference Manual :


http://dev.mysql.com/doc/refman/5.0/

IPv4 Wikipedia :
http://en.wikipedia.org/wiki/IPv4

IPv6 Wikipedia :
http://en.wikipedia.org/wiki/IPv6_packet

Ethernet :
http://telecom.tbi.net/frmlan.html
http://standards.ieee.org/develop/regauth/ethertype/eth.txt
http://fr.wikipedia.org/wiki/Ethernet
http://wiki.wireshark.org/Ethernet
http://tools.ietf.org/html/rfc826

Page de manuel : PTHREAD_ATTR_INIT(3) :


http://www.linux-kheops.com/doc/man/manfr/man-html-0.9/man3/pthread_attr_init.3.html

Time C reference :
http://www.cplusplus.com/reference/clibrary/ctime/

Protocols Numbers :
http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xml

POSIX Thread programming :


https://computing.llnl.gov/tutorials/pthreads/#PassingArguments
http://www.yolinux.com/TUTORIALS/LinuxTutorialPosixThreads.html
http://franckh.developpez.com/tutoriels/posix/pthreads/
http://www.lirmm.fr/~dijorio/dl/Thread/thread.pdf
http://www.linuxquestions.org/questions/programming-9/priority-scheduling-with-pthreads-459117/

Pcap Lib :
http://www.tcpdump.org/pcap.html
http://linux.die.net/man/3/pcap
http://www.manpagez.com/man/7/pcap-filter/

30
Rapport de stage - Surveillance Intelligente du Réseau

Valgrind :
http://valgrind.org/docs/manual/index.html

C Memory Managment :
http://en.wikibooks.org/wiki/C_Programming/Memory_management
http://ilay.org/yann/articles/mem/mem1.html
http://www.suite101.com/content/c-memory-management--malloc-a3680
http://en.wikipedia.org/wiki/Memory_debugger
http://www.cs.cf.ac.uk/Dave/C/node13.html
http://www.codeproject.com/KB/cpp/endianness.aspx
http://www.dylanleigh.net/notes/c-cpp-tricks.html

31
Rapport de stage - Surveillance Intelligente du Réseau

6.4 Blog de développement


Sachant dès le départ que mon code serait amené à être repris par d'autres développeurs pour être
amélioré et complété, il fallait garder une trace des étapes franchies et des problèmes rencontrés lors
du développement de l'application. Un blog est le meilleur moyen de partager ces informations.

6.4.1 Linux CentOS installation


Posted on March 18, 2011 by Vincent

We just finished the installation of CentOS and for now we are using it as a web server to host this
blog.

6.4.2 Threaded Client


Posted on March 30, 2011 by Vincent

I just finished a first draft of the iNetmon2 daemon, so far I am able to:

1. Capture packets and put them in a FIFO buffer in memory (linked-list)


2. Process the buffer with several threads. (thread-safe)
3. Analyse the packets for the following protocols : Eth II, IPv4, IPv6, TCP.
4. Display the basic informations about each packet

The daemon is running for a few hours with 100 threads (just for testing purpose), no problem was
detected so far. I’ve checked very carefully all possible memory leak so it should be allright.
Next step is to implement the mysql link.

6.4.3 Valgrind memory check


Posted on March 31, 2011 by Vincent

I think the memory allocation is now pretty good :

32
Rapport de stage - Surveillance Intelligente du Réseau

==11554==
==11554== HEAP SUMMARY:
==11554== in use at exit: 0 bytes in 0 blocks
==11554== total heap usage: 3,751 allocs, 3,751 frees, 220,357 bytes
allocated
==11554==
==11554== All heap blocks were freed -- no leaks are possible
==11554==
==11554== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 34 from 8 )
==11554==
==11554== 1 errors in context 1 of 1:
==11554== Syscall param socketcall.setsockopt(optval) points to
uninitialised byte(s)
==11554== at 0x4B6117: setsockopt (in /lib/libc-2.5.so)
==11554== by 0x543C68: pcap_setfilter (in /usr/lib/libpcap.so.0.9.4)
==11554== by 0x804975A: main (main.c:94)
==11554== Address 0xbea30642 is on thread 1's stack
==11554== Uninitialised value was created by a stack allocation
==11554== at 0x542E53: ??? (in /usr/lib/libpcap.so.0.9.4)
==11554==
--11554--
--11554-- used_suppression: 34 dl-hack3
==11554==
==11554== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 34 from 8 )

6.4.4 MySQL first results


Posted on April 1, 2011 by Vincent

So far, I'm only inserting data for the ethernet layer but it seems that MySQL is definitly not going
to be a bottleneck.
We're using a standard installation of MySQL with the InnoDB engine, and there is still place for a
lot of optimizations.
The memory used is not very important but the usage of the CPU will be an important point to
monitor in the futur. (Currently we are using more than 50% of the cpu all the time, but it's
relatively stable)
The programm is running for about 2 hours and seems to work fine, even with a download in the
background at about 20kb/s.
I'm trying to monitor eventual packets lost between the daemon and the database, but the tests are
not conclusive yet.
[edit]
More than 212 000 packets captured in 1h50, no packets lost between the daemon and the database.
The packet buffer of the daemon is not growing so this is a very good sign !

6.4.5 MySQL robustness


Posted on April 4, 2011 by Vincent

The daemon was launched during 1h30 and captures 200 000 packets that were all succesfully
inserted in the database.
Next step is to record the other informations about all the headers.

33
Rapport de stage - Surveillance Intelligente du Réseau

6.4.6 Switched to VMWare


Posted on April 19, 2011 by Vincent

I just switched the blog on the VMWare, I'm still fighting to administrate the server remotly,
currently I'm using in parallel:

Putty for SSH with tunnels for VNC port.


VNC (over SSH) to use some graphical features.
MySQL WorkBench to administrate the MySQL database, connected with an other SSH
tunnel.
FileZilla in SFTP (SSH) to upload/download files from my computer to the server.
My web browser to test the web server.

Currently, the server configuration is the following:


CentOS 5.4 (Final) - Linux version 2.6.18-164.el5 (mockbuild@builder10.centos.org) (gcc version 4.1.2 20080704 (Red
Hat 4.1.2-46)) #1 SMP Thu Sep 3 03:28:30 EDT 2009

Only opened ports:

22: SSH
80: HTTP
443: HTTPS

6.4.7 Simple monitoring views


Posted on April 20, 2011 by Vincent

Bandwidth usage per minute on a vertical time scale:


http://10.207.160.171/bandwidth.php

Protocol distribution at Ethernet level:


http://10.207.160.171/protocols.php

This is just a basic demo of what we can already do with the database.

34
Rapport de stage - Surveillance Intelligente du Réseau

6.4.8 Database Model


Posted on April 21, 2011 by Vincent

We are currently working on a database model that will allow several differents levels of precision
on the monitoring.
We want to be able to see a precise view of the network for the last 2-4 hours, but after that we want
to simplify the data so that we can still have interesting informations on the traffic and we want to
discard all unimportants data.
So we will have several layers in the database model that will correspond to the differents
timescales used:

1. Full headers informations: That's what we were doing before


2. Only Importants Defragmented packets and simple statistics per minutes
3. Full statistics and no more packets
4. Simple statistics
This is just a quick draft of the second layer:

6.4.9 Endianess headache, the NUXI problem


Posted on May 10, 2011 by Vincent

The data structures of the packets on the network are stored in big-endian whereas the endianess of
the system is generally little-endian.
This causes a lot of problem for all the types bigger than a single byte.
I'm still fighting to understand if this problem can also affect smaller types like nibbles (half bytes).

http://en.wikipedia.org/wiki/Endianness

35
Rapport de stage - Surveillance Intelligente du Réseau

http://betterexplained.com/articles/understanding-big-and-little-endian-byte-order/

6.5 Événnements survenus pendant le stage


Je tiens ici à parler des événements exceptionnels qui sont survenus pendant la période du stage et
que nous avons suivis avec assiduité.

6.5.1 La révolution de jasmin


Débutée en décembre 2010, la révolution tunisienne s'est progressivement étendue à l'ensemble des
pays du Maghreb, notamment l'Egypte et la Libye où les manifestants ont été la cible de violentes
répressions jusqu'à encore très récemment.

6.5.2 Le tsunami Japonnais


Le 11 mars 2011, un très violent séisme de magnitude 8,9 a dévasté les côtes Japonaises Pacifique
en faisant des milliers de morts et d'importants dommages matériels.

6.5.3 L'accident nucléaire de Fukushima


Suite au tsunami du 11 mars, trois des six réacteurs de la centrale nucléaire de Fukushima Daiichi
ont subi des fusions partielles de cœur, causant d'importants rejets radioactifs et engendrant la
catastrophe nucléaire la plus importante de l'histoire à égalité avec celle de Tchernobyl.

6.5.4 Linux a 20 ans


En 1991, Linus Torvald créé Linux. 20 ans plus tard, Linux est le système d'exploitation utilisé par
la majorité des superordinateurs, des systèmes boursier, des téléphones, des distributeurs de billets,
des serveurs web et la liste est encore longue.

6.5.5 Sony piraté


Le 22 avril 2011, le Playstation Network de Sony se fait pirater et les hackers volent plus de 70
millions de données personnelles, incluant adresses, numéros de téléphone, mots de passe et
numéros de carte de crédit.

6.5.6 La mort de Ben Laden


10 ans après les attentats du 11 septembre, le 1er mai 2011, les États-Unis annoncent la mort
d'Oussama Ben Laden, le terroriste le plus recherché de la planète.

36
Rapport de stage - Surveillance Intelligente du Réseau

6.5.7 Arrestation de DSK


Le 15 mai, Dominique Strauss-Kahn, patron du Fonds Monétaire International et futur candidat à la
présidence française se fait arrêter pour tentative de viol par la police dans son hôtel new-yorkais.

6.5.8 IPv6 day


Le 8 juin, le web mondial a testé durant 24h le protocole IPv6. Plusieurs centaines d’entreprises,
services en ligne, opérateurs et constructeurs d’équipements réseau, ont participé à cette journée
IPv6.
Rappellns qu'au milieu du mois de mai, l'APNIC a déclaré être à court d'adresse IPv4.

37
Rapport de stage - Surveillance Intelligente du Réseau

L'équipe de développement du Professeur Selvakumar Manickam.

De gauche à droite:

Vincent Chalnot
Nanthan Palakarnim
Christopher Ooi
La femme de Professeur Selvakumar
Professeur Selvakumar Manickam et son fils
Soo Ling
Lingeswari V. Chandra
Fiona Lim
Malligadevi Neelamegan

38
Vincent Chalnot
Étudiant en licence professionnelle systèmes informatiques et
logicielles à l'UFR ST de Besançon, promotion 2011.
Rapport de stage de fin d'étude dans l'entreprise iNetmon située
au sein de l'USM de Penang, Malaisie.

Développement d'un moteur de capture de paquets en langage


C avec une base de donnée MySQL dont la destination est d'être
intégré à iNetmon 2, la nouvelle version de l'outil de surveillance et
d'administration de réseaux informatiques développé par iNetmon.

iNetmon : Intelligent Network Monitoring


“ Your security is our concern. ”

Professionnal bachelor degree student in computer sciences from the UFR ST University of
Besançon, 2011 promotion. Trainingship report for the company iNetmon, located inside de USM
of Penang, Malaysia.
Development of a packet capture engine in C using MySQL destinated to be integrated to iNetmon
2, the last version of the network monitoring tool developped of iNetmon.