RAPPORT. Surveillance Intelligente du Réseau. Vincent Chalnot. Licence Professionnelle Systèmes Informatiques et Logiciels

Transcription

1 Université de Franche-Comté UFR Sciences et Techniques Licence Professionnelle Systèmes Informatiques et Logiciels RAPPORT destage Surveillance Intelligente du Réseau Vincent Chalnot Promotion

2 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

3 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 vincentchalnot@gmailcom wwwcarnet-de-routeinfo Selvakumar Manickam Superviseur de stage selva@nav6org inetmon Sdn Bhd Entreprise d'accueil Tingkat 2 Blok C,Sains@USM, No 10 Persiaran Bukit Jambul, Bayan Lepas, Penang, Malaysia Tel: enquiry@inetmoncom wwwinetmoncom 3

4 TABLE DES MATIÈRES 1 Introduction 6 11 L'entreprise 6 12 L'application 6 13 Le travail 6 2 L'existant 7 21 Solutions existantes inetmon Wireshark AthTek Netwalk PRTG Bilan des solutions existantes LibPCap Open Source Facilité d'utilisation Documentation des Protocoles 11 3 Développement LibPCap Initialisation Affichage minimal Principes de base Encapsulation Désencapsulation Base de données MySQL Modèle de base de données Purge automatisée Gestion de la mémoire Capture des paquets Traitement des paquets 22 4 Tests Utilisation de la mémoire Stabilité Stress-tests Débit et perte de paquets 23 4

5 432 Saturation de la base de données Environnement de production 24 5 Conclusion 25 6 Annexes Documentation Description des protocoles Glossaire Bibliographie Blog de développement Linux CentOS installation Threaded Client Valgrind memory check MySQL first results MySQL robustness Switched to VMWare Simple monitoring views Database Model Endianess headache, the NUXI problem Événnements survenus pendant le stage La révolution de jasmin Le tsunami Japonnais L'accident nucléaire de Fukushima Linux a 20 ans Sony piraté La mort de Ben Laden Arrestation de DSK IPv6 day 37 5

6 1 INTRODUCTION 11 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 12 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é 13 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

7 2 L'EXISTANT 21 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 211 inetmon Site web : 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 2111 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

8 212 Wireshark Site web : 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 2121 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 à la version 145, 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

9 213 AthTek Netwalk Site web : 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 2131 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

10 214 PRTG Site web : 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é 2141 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

11 2142 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 22 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 23 LibPCap Site web: 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 231 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 232 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 24 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

12 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 31 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", headerlen); /* And close the session */ pcap_close(handle); } return(0); 12

13 311 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 32 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

14 33 Principes de base 331 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/11 Host: wwwgooglecom 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 Bits Destination 4 32 Destination (Continuation) Source 8 64 Source (Continuation) Ethertype Version IHL TOS Total Length Identification Flags Offset TTL Protocol Checksum Source Source (Continuation) Destination Destination (Continuation) Source port Destination port Sequence number Sequence number (Continuation) Acknowledgment number Acknowledgment number (Continuation) Data offset Reserved Flags Window size Checksum Urgent pointer HTTP DATA HTTP DATA (Continuation) HTTP DATA (Continuation) HTTP DATA (Continuation) HTTP DATA (Continuation) HTTP DATA (Continuation) HTTP DATA (Continuation) HTTP DATA (Continuation) HTTP DATA (Continuation) HTTP DATA (Continuation) 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

15 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 332 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 3321 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 8023 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

16 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 8023, 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 8021Q 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 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

17 Ce qui permet d'avancer le pointeur en mémoire de 14 octets qui correspond à la longueur d'un entête Ethernet type II 3322 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 Lorqu'on effectue la première opération >> 4, on décale de 4 bits le champ vers la droite Bits 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 Ici, le bitmask appliqué est 0x0f ce qui correspond à b et le résultat est bien la valeur 5: 17

18 Bits 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: Dans notre cas, le numéro 6 indique que la trame supérieure est de type TCP 3323 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 3324 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

19 34 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 341 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: 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 342 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

20 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

21 343 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 35 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 351 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

22 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 352 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

23 4 TESTS 41 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 42 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 43 Stress-tests 431 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

24 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 432 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 44 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

25 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

26 26

27 6 ANNEXES 61 Documentation Un certain nombre d'outils de suivi ont été mis en place sur le projet que nous détaillerons ici 611 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

28 62 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

29 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

30 63 Bibliographie Nmap TCP-IP reference : SolarWinds: Network Management Software & Network Monitoring : MySQL :: MySQL 50 Reference Manual : IPv4 Wikipedia : IPv6 Wikipedia : Ethernet : Page de manuel : PTHREAD_ATTR_INIT(3) : Time C reference : Protocols Numbers : POSIX Thread programming : Pcap Lib :

31 Valgrind : C Memory Managment :

32 64 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 641 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 642 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 643 Valgrind memory check Posted on March 31, 2011 by Vincent I think the memory allocation is now pretty good : 32

33 ==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 socketcallsetsockopt(optval) points to uninitialised byte(s) ==11554== at 0x4B6117: setsockopt (in /lib/libc-25so) ==11554== by 0x543C68: pcap_setfilter (in /usr/lib/libpcapso094) ==11554== by 0x804975A: main (mainc: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/libpcapso094) ==11554== used_suppression: 34 dl-hack3 ==11554== ==11554== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 34 from 8 ) 644 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 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! 645 MySQL robustness Posted on April 4, 2011 by Vincent The daemon was launched during 1h30 and captures packets that were all succesfully inserted in the database Next step is to record the other informations about all the headers 33

34 646 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 54 (Final) - Linux version el5 (mockbuild@builder10centosorg) (gcc version (Red Hat )) #1 SMP Thu Sep 3 03:28:30 EDT 2009 Only opened ports: 22: SSH 80: HTTP 443: HTTPS 647 Simple monitoring views Posted on April 20, 2011 by Vincent Bandwidth usage per minute on a vertical time scale: Protocol distribution at Ethernet level: This is just a basic demo of what we can already do with the database 34

35 648 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: 649 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) 35

36 65 É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é 651 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 652 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 653 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 654 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 655 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 656 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

37 657 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 658 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

38 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

39 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 Yoursecurityisourconcern 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