Rapport de stage - Surveillance Intelligente du Réseau

Promotion 2010-2011

Université de Franche-Comté

UFR Sciences et Techniques

Licence Professionnelle Systèmes Informatiques et Logiciels

RAPPORTde STAGESurveillance Intelligente du Réseau

Vincent Chalnot

REMERCIEMENT

Je tiens à remercier tout particulièrement mon superviseur de stage, Professeur SelvakumarManickam, de m'avoir permis de travailler sur un sujet aussi motivant.

Je remercie également Professeur Jean-Christophe Lapayre, mon tuteur à l'université de Besançonainsi que Guillaume Paquette, responsable de la formation de la licence professionnelle eninformatique.

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.

Rapport de stage - Surveillance Intelligente du Réseau

2

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

[email protected]

www.carnet-de-route.info

Selvakumar Manickam

Superviseur de stage

[email protected]

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

[email protected]

www.inetmon.com


3

TABLE DES MATIÈRES


4

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

1. Introduction 6

1.1 L'entreprise 6

1.2 L'application 6

1.3 Le travail 6

2. L'existant 7

2.1 Solutions existantes 7

2.1.1 iNetmon 72.1.2 Wireshark 82.1.3 AthTek Netwalk 92.1.4 PRTG 10

2.2 Bilan des solutions existantes 11

2.3 LibPCap 11

2.3.1 Open Source 112.3.2 Facilité d'utilisation 11

2.4 Documentation des Protocoles 11

3. Développement 12

3.1 LibPCap 12

3.1.1 Initialisation 13

3.2 Affichage minimal 13

3.3 Principes de base 14

3.3.1 Encapsulation 143.3.2 Désencapsulation 15

3.4 Base de données 19

3.4.1 MySQL 193.4.2 Modèle de base de données 193.4.3 Purge automatisée 21

3.5 Gestion de la mémoire 21

3.5.1 Capture des paquets 213.5.2 Traitement des paquets 22

4. Tests 23

4.1 Utilisation de la mémoire 23

4.2 Stabilité 23

4.3 Stress-tests 23

4.3.1 Débit et perte de paquets 23


5

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

4.3.2 Saturation de la base de données 24

4.4 Environnement de production 24

5. Conclusion 25

6. Annexes 27

6.1 Documentation 27

6.1.1 Description des protocoles 27

6.2 Glossaire 28

6.3 Bibliographie 30

6.4 Blog de développement 32

6.4.1 Linux CentOS installation 326.4.2 Threaded Client 326.4.3 Valgrind memory check 326.4.4 MySQL first results 336.4.5 MySQL robustness 336.4.6 Switched to VMWare 346.4.7 Simple monitoring views 346.4.8 Database Model 356.4.9 Endianess headache, the NUXI problem 35

6.5 Événnements survenus pendant le stage 36

6.5.1 La révolution de jasmin 366.5.2 Le tsunami Japonnais 366.5.3 L'accident nucléaire de Fukushima 366.5.4 Linux a 20 ans 366.5.5 Sony piraté 366.5.6 La mort de Ben Laden 366.5.7 Arrestation de DSK 376.5.8 IPv6 day 37

1. INTRODUCTION

1.1 L'entrepriseiNetmon 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 informatiquesdestinée aux administrateurs.

Le contexte socioculturel de l'entreprise très hétérogène est un point à souligner, la langue principaleest de loin l'anglais en raison de la diversité culturelle du laboratoire : Chinois, Malais et Indienssont les principales ethnies représentées par ordre d'importance.

1.2 L'applicationiNetmon est à l'origine une plateforme développée en Java et utilisant WinPcap pour la capture depaquets. L'utilisation de Java pour un tel logiciel n'est pas justifiée, en effet, de par ses dépendancessur des librairies externes, l'application ne fonctionne que sous Windows et Java perd son intérêtmultiplateforme. De plus, en raison de son exécution dans une machine virtuelle et à la suite denombreuses mises à jour et modifications, le programme est devenu trop lourd, peu performant etbeaucoup de paquets sont perdus lors de la capture. L'interface a souffert de multiples modificationssans 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 enparallèle de la première version dont le développement sera stoppé lorsque la version 2 sera arrivéeà maturité.

1.3 Le travailJ'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 laconvention de nommage des services Linux, nous avons appelé le système de capture de paquetsiNetmond 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 lamémoire. Le choix de la base de données s'est porté sur MySQL en raison de sa facilité d'utilisationet de ses performances honorables. Les informations contenues dans la base de données sontutilisées par une application web (PHP/HTML) pour permettre à l'utilisateur d'interfacer avec cesdonnées.

Au départ, mon superviseur m'a laissé seul sur ce projet pour poser les bases du système avec sonaide, puis j'ai rejoint une équipe de développeurs qui avait pour objectif d'utiliser les donnéeschargées en base MySQL par le moteur de capture pour les traiter et construire l'interface web.


6

2. L'EXISTANT

2.1 Solutions existantesNous nous sommes penchés sur les programmes permettant de surveiller le réseau ou plusgé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éesici.

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 surveillerqui est présent sur le réseau, à quel moment, en associant une adresse MAC aux différentes adressesIP utilisées

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


7

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 desurveillance, 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 analyserun protocole réseau. De par la quantité phénoménale de dissectors présents dans Wireshark, plus de105 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 lastructure des différents protocoles présents dans le paquet. Cette vue qui combine à la fois unearborescence de type clé=valeur et une vue hexadécimale du paquet a été d'une grande aide lors del'écriture de nos propres dissectors.

On note ici le surlignage du champ actif qui permet d'identifier un champ particulier au sein dudump 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 puissanceanalytique.


8

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 parconsé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 pourraitavoir besoin. Cette vue est modulable à volonté ce qui permet à chacun d'adapter ses propresindicateurs.

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


9

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 permettantde surveiller des réseaux distants, des serveurs distants et possédant une grande variété d'interfacesutilisateur dont plusieurs interfaces web.

La principale faiblesse de ce logiciel est sa grande complexité qui ne permet pas une prise en mainrapide, 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 lesmêmes performances et possibilités qu'un ordinateur de bureau.


10

2.1.4.2 Modulabilité

Les différentes interfaces (web, mobile et software) se ressemblent énormément et se basent sur lapossibilité 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 decette solution.

2.2 Bilan des solutions existantesNous avons passé beaucoup de temps à étudier les solutions existantes afin de déterminer quellesfonctionnalités devaient être présentes dans iNetmon 2, ce travail a néanmoins d'avantage servit lesdé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 LibPCapSite web: http://www.tcpdump.org/

LibPcap est incontestablement la librairie Open Source la plus performante pour capturer despaquets 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. Tousles paquets du réseau, même ceux destinés à d'autres hôtes, sont accessibles par le biais de cetteinterface.

2.3.1 Open Source

Comme pour n'importe quel projet Open Source, la force de libpcap provient de son potentield'évolution. Les développeurs ont pu contribuer à améliorer continuellement le code avec l'évolutiondu 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 Ccomme c'est le cas pour notre projet.

2.4 Documentation des ProtocolesLa plus grosse difficulté fut incontestablement de réunir une documentation complète et uniformiséedes protocoles réseau les plus utilisés. En effet, il n'existe à ce jour aucune documentation uniformedécrivant les structures de ces protocoles.

Certainement l'étape la plus chronophage de ce projet, l'écriture d'un manuel des protocoles réseaules plus communément rencontrés a nécessité de réunir toutes les documentations existantes sur lesujet. Cette étape est détaillée en annexe dans la section "Documentation".


11

3. DÉVELOPPEMENT

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

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

#include #include

int main(int argc, char *argv[]){pcap_t *handle; // Session handlechar *dev; // The device to sniff onchar errbuf[PCAP_ERRBUF_SIZE]; // Error messagestruct bpf_program fp; // The compiled filterchar filter_exp[] = "tcp"; // The filter expressionstruct pcap_pkthdr header; // The header that pcap gives usconst 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

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êmesparamè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'erreurvenant 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 dufiltre.

struct pcap_pkthdr header : Est la structure de l'en-tête retournée par Pcap pour chaquepaquet 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 premierpointeur 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 minimalAfin de pouvoir tester la capture des paquets visuellement, on a mis en place une interface minimaleen mode terminal pour représenter chaque paquet capturé.

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


13

3.3 Principes de base

3.3.1 Encapsulation

Un paquet est construit par encapsulation de multiples protocoles. Prenons l'exemple d'unnavigateur web qui veut envoyer une requête à un serveur. Un paquet va être construit ensuperposant des couches de protocoles les unes sur les autres.

Au départ, le navigateur web veut envoyer la requête suivante:

GET / HTTP/1.1Host: 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 leprogrammeur 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 coucheréseau IPv4 et enfin la couche liaison Ethernet. L'exemple utilisé est très simple et en fonction del'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)










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

Ce paquet va transiter sur le réseau à travers une multitude de routeurs, de switch et de répartiteursqui vont probablement encapsuler et désencapsuler la couche Liaison (Ethernet) un grand nombre defois, 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'ilcontient avant d'avoir commencé à le lire.

Il faut donc, pour accéder à l'information de la couche application (ici HTTP), désencapsuler lepaquet.

3.3.2 Désencapsulation

Lorsqu'on veut lire ce que contient un paquet, on doit le désencapsuler, c'est-à-dire retirer lescouches de protocoles une par une en commençant par la plus basse. On gardera ici l'exemple dupaquet précédent, mais il faut garder à l'esprit que l'on ne connait pas la structure du paquet avantd'avoir commencé à l'analyser.

Dans le cas de Pcap, le paquet contenu en mémoire est accessible par l'intermédiaire d'un pointeurnon typé, on peut donc lire n'importe quelle partie du paquet à partir de ce pointeur, mais il fautconnaî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'immensemajorité des cas il va s'agir d'Ethernet. Toutefois, il existe plusieurs types de trame Ethernet, la pluscourante 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 lamémoire en castant chaque champ de la structure d'un paquet Ethernet pour recréer une structurepropre 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 estle problème de l'endianness. L'ordre des octets n'est généralement pas le même entre la machine etle 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 inverserles deux octets du champ type. Si le type venant du réseau a pour valeur 0x2104, la valeurenregistré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

Ce problème, connu sous le nom du NUXI vient du fait que les données transférées sur le réseausont toujours en Big-Endian (on parle de network byte order), alors que l'architecture desprocesseurs x86 est Little-Endian. L'endianness peut changer en fonction de l'architecture duprocesseur, mais aussi en fonction du système, car certains processeurs supportent les deuxarchitectures. De plus, le problème peut devenir plus complexe avec la variation de l'unité atomiquedu 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. Ondoit 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 nouvellestructure.

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'ordredes octets vers celui de la machine. L'exemple donné ici est simplifié par rapport à la version finalequi 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 typedu 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 autrefiltre 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 quepeu 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 dupaquet 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

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 longueurn'est pas un nombre fini d'octets où on a besoin d'appliquer un bitmask pour récupérer la valeurcorrecte du champ. Étant donné qu'il est fortement déconseillé de manipuler en mémoire desvariables de longueur inférieure à un octet (cela peut engendrer des comportements différents enfonction des compilateurs), on préfère enregistrer ces champs dans une variable dont le type estlé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 tantque 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 dupaquet (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 logiquebit à 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

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-cicommence.

La longueur d'un en-tête IPv4 peut changer en fonction du nombre d'options qu'il contient, dansnotre 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 quele 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. Ilest donc crucial de bien appréhender le concept de bitswap et bitmask ainsi que les problèmesd'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 auserveur. Pour le moment iNetmond ne capture pas le contenu de la couche applicative, l'analyse desprotocoles de plus haut niveau sera une des futures étapes du développement de l'application.


18

3.4 Base de donnéesL'étape suivante du développement fut de mettre en place la base de données afin de stocker lespaquets 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éesfiables 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 deuxsystè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 questions'est posée sur le choix du moteur de stockage. Il existe en effet deux moteurs de stockagepopulaires 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èrepas les transactions et les clés étrangères. InnoDB est le moteur le plus couramment utilisé par lesdé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 pointsforts 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 demeilleures performances. L'équipe de développement Web travaille actuellement sur le serveur deproduction 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 noussommes en effet penchés uniquement sur le problème de stocker chaque en-tête de paquet en basede données sans trier ou sélectionner les champs. Au final, on peut interroger la base de donnéesdirectement sur n'importe quel champ de n'importe quel en-tête de n'importe quel paquet capturé.


19

On notera que le nom des tables pour chaque protocole est construit à partir le l'id du protocole dansla 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éveloppeursde la couche supérieure de l'application (les développeurs web dans notre cas) de sélectionnerprécisément les champs dont ils ont besoin pour construire leur propre base de données tout en leurlaissant la possibilité d'accéder ultérieurement à d'autres champs sans avoir besoin de modifier labase de données et le service de capture.


20

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 doncné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 moinsd'informations sur les paquets pour finir par ne garder que les statistiques globales de la journéeaprès un certain temps.

Les différentes options en ce qui concerne la purge de la base de données ont été étudiées, puislaissées entre les mains de l'équipe web.

3.5 Gestion de la mémoireUn soin particulier a été mis sur l'optimisation de la mémoire par le système afin de limiter la pertede 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 estsupposé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érencevers 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. Onne peut pas en effet se permettre que l'analyse de chaque paquet soit bloquante au niveau du systèmede capture de paquets, on utilise donc une mémoire tampon de type FIFO (First-In-First-Out) sous laforme d'une liste chaînée.

À chaque fois qu'un nouveau paquet est capturé, il est copié intégralement dans un nouvel espacemémoire et ajouté en fin de liste.


21

Il s'agit d'un scénario classique de liste chaînée ou chaque structure contient un pointeur vers lastructure 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 lesanalyser et les supprimer de la mémoire tampon. Afin de faire cette opération en parallèle de lacapture 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 dedonnées. Si la mémoire tampon est vide, le thread se met en pause pendant 500 ms puis se lance denouveau. La fin de la capture est signalée par Pcap dans une variable globale ce qui permet auxthreads 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 isoleun paquet pour le traiter, il y a un risque que deux threads isolent en même temps le paquet de têtede 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

4. TESTS

4.1 Utilisation de la mémoireUne des principales forces du langage C est de permettre une allocation précise de la mémoire. Cetavantage peut devenir très rapidement un inconvénient si l'allocation n'est pas effectuéecorrectement. Il n'existe pas de ramasse-miette comme dans les langages de plus haut niveau, si unepartie de la mémoire n'est pas libérée après avoir été allouée, elle restera en utilisation jusqu'à la findu programme.

Afin de détecter des fuites de mémoire qui auraient pour conséquence de faire planter purement etsimplement l'application, nous avons utilisé Valgrind, une application Open Source qui permet dedé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 conseillervivement 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 longuespériodes de temps (plus de 24h), période pendant laquelle nous avons enregistré les ressourcesutilisées, ceci afin de détecter d'éventuelles instabilités. Il s'est avéré que le système étaitextrê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 premierdu nom et son successeur était l'inefficacité du système à supporter de lourdes charges en terme dedébit. Il fallait prouver que le nombre de paquets perdu était inférieur avec iNetmond qu'à celui deson précurseur.

Le teste principal permettant de détecter la perte de paquet consiste à envoyer un grand nombre depaquets en une seule fois sur l'interface réseau de la machine et de comparer le nombre de paquetsinjecté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 environ10 ms pour la machine émettrice et 3 à 4 secondes pour que le système les traites, à chaque fois, onarrivait à un nombre de paquets perdu compris entre 0 et 3, ce qui correspond à un taux inférieur ouégal à 1 %.


23

iNetmon 1 en comparaison affichait un taux de perte d'environ 11 %. Le problème est que les deuxtests n'ont pas été effectués exactement dans les mêmes conditions, notamment en ce qui concerne lesystème d'exploitation (Windows pour iNetmon et Linux pour la version 2), cela indique néanmoinsune 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 paquetscapturé avoisine aisément le million. Nous avons décidé pendant un temps de ne pas remettre à zérola 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 sansqu'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 productionUn des problèmes qui risque de se poser avec un environnement de production est le nombre biensupé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 deproduction (port mirroring sur le routeur), mais il a été décidé d'abandonner les tests en attendant lesré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 lesspécifications finales du système (notamment sur la base de données et sur l'interface) n'ont pasencore été fixées définitivement. Malgré ce fait, iNetmond s'est montré plus que capable dans unenvironnement de test avec une machine de bureau et une utilisation du réseau moyenne.


24

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émentationde 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 informatiquescoï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 enlangage C ainsi que mes connaissances du fonctionnement des réseaux, notamment en ce quiconcerne le fonctionnement des protocoles de la suite Internet: Ethernet, IPv4, IPv6, TCP et UDP. Jemettrais un point particulier sur IPv6 qui n'a jamais été autant d'actualité avec la récente pénuried'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'autresmentalités et plus généralement d'autres gens intéressants.


25


26

6. ANNEXES

6.1 DocumentationUn 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 formatXML pour décrire chaque protocole.

Cette spécification devait résoudre plusieurs problématiques liées à la structure des protocolesré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 certainesvaleurs.

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 adonc 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 valeurprise 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 pasencore implémentées.

La documentation concernant les protocoles est encore en cours de construction et aboutiraprobablement à un livre commercialisé en version papier et électronique.


27

6.2 GlossaireAdresse IP :Numéro d'identification qui est attribué à chaque branchement d'appareil à un réseau informatiqueutilisant le protocole Internet.

Adresse MAC :

Identifiant physique stocké dans une interface réseau et utilisé pour attribuer mondialement uneadresse 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'ungroupe 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'uneperte 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 traitementsinformatiques traditionnellement localisés sur des serveurs locaux ou sur le poste client del'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'espaced'adressage IP d'Internet

Mutex :

Primitive de synchronisation utilisée en programmation informatique pour éviter que des ressourcespartagé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, alorson obtient NUXI.


28

Paquet :

En réseau, le paquet est l'entité de transmission permettant de faire passer un message d'unemachine à 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 unespé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 ilsfont partie.

WinPcap :

Equivalent Windows de la librairie LibPCap permettant de capturer des paquets sur une interfaceréseau.


29

6.3 BibliographieNmap 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

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

6.4 Blog de développementSachant dès le départ que mon code serait amené à être repris par d'autres développeurs pour êtreamélioré et complété, il fallait garder une trace des étapes franchies et des problèmes rencontrés lorsdu 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 thisblog.

6.4.2 Threaded Client


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 wasdetected 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


I think the memory allocation is now pretty good :


32

==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 goingto be a bottleneck.

We're using a standard installation of MySQL with the InnoDB engine, and there is still place for alot of optimizations.

The memory used is not very important but the usage of the CPU will be an important point tomonitor in the futur. (Currently we are using more than 50% of the cpu all the time, but it'srelatively stable)

The programm is running for about 2 hours and seems to work fine, even with a download in thebackground at about 20kb/s.

I'm trying to monitor eventual packets lost between the daemon and the database, but the tests arenot 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


The daemon was launched during 1h30 and captures 200 000 packets that were all succesfullyinserted in the database.

Next step is to record the other informations about all the headers.


33

6.4.6 Switched to VMWare


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 SSHtunnel.

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 ([email protected]) (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


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

6.4.8 Database Model


We are currently working on a database model that will allow several differents levels of precisionon 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 wantto simplify the data so that we can still have interesting informations on the traffic and we want todiscard all unimportants data.

So we will have several layers in the database model that will correspond to the differentstimescales 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 ofthe 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

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

6.5 Événnements survenus pendant le stageJe tiens ici à parler des événements exceptionnels qui sont survenus pendant la période du stage etque 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 despays du Maghreb, notamment l'Egypte et la Libye où les manifestants ont été la cible de violentesré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 Pacifiqueen 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 Daiichiont subi des fusions partielles de cœur, causant d'importants rejets radioactifs et engendrant lacatastrophe 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é parla 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 70millions de données personnelles, incluant adresses, numéros de téléphone, mots de passe etnumé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 mortd'Oussama Ben Laden, le terroriste le plus recherché de la planète.


36

6.5.7 Arrestation de DSK

Le 15 mai, Dominique Strauss-Kahn, patron du Fonds Monétaire International et futur candidat à lapré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éeIPv6.

Rappellns qu'au milieu du mois de mai, l'APNIC a déclaré être à court d'adresse IPv4.


37

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 etlogicielles à l'UFR ST de Besançon, promotion 2011.

Rapport de stage de fin d'étude dans l'entreprise iNetmon situéeau 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'êtreintégré à iNetmon 2, la nouvelle version de l'outil de surveillance etd'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 ofBesançon, 2011 promotion. Trainingship report for the company iNetmon, located inside de USMof Penang, Malaysia.

Development of a packet capture engine in C using MySQL destinated to be integrated to iNetmon2, the last version of the network monitoring tool developped of iNetmon.

Documents

Rapport de stage - Surveillance Intelligente du Réseau