ÉCOLE DE TECHNOLOGIE SUPÉRIEURE

UNIVERSITÉ DU QUÉBEC

PROJET PRÉSENTÉ À L’ÉCOLE DE TECHNOLOGIE SUPÉRIEURE

COMME EXIGENCE À L’OBTENTION DE LA

MAITRISE Réseaux de télécommunications

PAR Pierrick Prost

État de l’art sur la supervision et le management des réseaux

MONTRÉAL, LE 29 / 12 / 2012

Pierrick Prost, 2012

Cette licence Creative Commons signifie qu’il est permis de diffuser, d’imprimer ou de sauvegarder sur un autre support une partie ou la totalité de cette œuvre à condition de mentionner l’auteur, que ces utilisations soient faites à des fins non commerciales et que le contenu de l’œuvre n’ait pas été modifié.

I

PRÉSENTATION DU JURY

CE RAPPORT DE PROJET A ÉTÉ ÉVALUÉ

PAR UN JURY COMPOSÉ DE : Mr Jean-Marc Robert, directeur de projet Département Génie logiciel et des TI à l’École de technologie supérieure Mr Michel Kadosh, membre du jury Département Génie électrique à l’École de technologie supérieure

II

REMERCIEMENTS L’entreprise ContactOI Réunion et Mr Jean Gabriel Deshayes pour m’avoir accueillis pour ce projet de 6 mois au sein de leur entreprise. Et à mes parents, pour m’avoir soutenu pendant cette reprise d’études.

III

ETAT DE L’ART SUR LA SUPERVISION ET LE MANAGEMENT DES RESEAUX

PIERRICK PROST

RÉSUMÉ Ce mémoire va s’articuler autour d’un thème ; la supervision des réseaux ainsi que leurs gestions, réalisé en collaboration avec l’entreprise Contact OI m’accueillant pour mon projet d’intervention de fin de maitrise. Deux parties distinctes seront présentées : la première sera un état de l’art sur plusieurs technologies ayant chacun pour références des recherches effectué par la communauté scientifique. La seconde partie sera une mise en application des concepts et technologies de supervision et gestion des réseaux. Cette mise en application se fera sur le réseau existant de l’entreprise Contact OI spécialiser dans le déploiement d’accès internet et point à point sur WIMAX et WiFi. Ce mémoire aura donc double utilité puisque passant de la partie théorique à pratique, il couvrira un large éventail de technologies et de concepts propre à la supervision et au management des réseaux de télécommunications.

IV

STATE OF THE ART ON NETWORK MANAGEMENT AND MONITORING.

PIERRICK PROST

ABSTRACT This report will revolve around a theme, networks monitoring and their management, in collaboration with the company Contact OI, welcoming me for my end mastery’s project. Two parts will be presented in this document: the first is a state of the art, each with several references to research conducted by the scientific community. The second part is an implementation of the concepts and technologies of monitoring and managing networks. This implementation will be based on the existing network of the company Contact OI, specialize in the deployment of Internet access and point-to-point WiMAX and WiFi connection. This report will have dual purpose as from the theoretical to practical, it will cover a wide range of technologies and concepts specific to the supervision and management of telecommunications networks.

V

TABLE DES MATIÈRES

Page

Introduction 1  

Chapitre 1 : Etat de l’art du management des équipements clients (CPE) d'un opérateur ........2  1.1   Introduction ....................................................................................................................2  1.2   Vers la nécessité d'un protocole de gestion des CPE .....................................................3  1.3   Gestion par ligne de commande (CLI) ...........................................................................3  1.4   SNMP, un standard éprouvé mais avec des faiblesses ..................................................4  1.5   NETCONF : l’évolution du SNMP par l’IETF ..............................................................6  

1.5.1   D’une approche orientée variable à une approche objet ............................. 7  1.5.2   Vers une compatibilité SNMP depuis NETCONF ..................................... 8  

1.6   UPnP, un protocole de management côté LAN. ............................................................9  1.6.1   Points faibles et vulnérabilités .................................................................. 10  1.6.2   Pas d’authentification ................................................................................ 11  1.6.3   Requète UPnp depuis le WAN ................................................................. 11  1.6.4   Le futur d’UPnP ........................................................................................ 11  1.6.5   Conclusion ................................................................................................ 11  

1.7   TR-069: vers un protocole de management côté WAN ...............................................11  1.7.1   Architecture du TR-069: ........................................................................... 12  1.7.2   Une extension vers les réseaux LAN, le TR-133 ...................................... 14  1.7.3   Un modèle de données standard pour chaque service et pour chaque

équipement ................................................................................................ 14  1.7.4   Vers une compatibilité entre TR-069 et UPnP ? ....................................... 14  

1.8   TR-069 / NETCONF : est-ce la même chose ? ............................................................16  1.9   Comparaison d’un point de vue performance entre SNMP, NETCONF et TR-069 ...16  1.10   OSGI: le management applicatif distant ......................................................................19  1.11   TR-069 et OSGI : vers un couple gagnant ? ................................................................19  1.12   Conclusion du chapitre ................................................................................................21  

Chapitre 2 : Surveillance et analyse des réseaux IPv6 .............................................................23  2.1   Introduction ..................................................................................................................23  2.2   IPv4 par rapport à IPv6 : quelle différence fondamentale? .........................................24  

2.2.1   Comparaison des en-têtes ......................................................................... 24  2.2.2   Méthode d’attribution d’adresse sous IPv6 ............................................... 26  

2.3   Technologies pour la transition d’IPv4 à IPv6 ............................................................26  2.4   Quid de la surveillance du trafic IPv6 ? .......................................................................28  

2.4.1   Quelle visibilité lors de l’encapsulation IPv6 dans IPv4 (tunneling) ....... 28  2.4.2   IPv6 et l’adressage temporaire .................................................................. 28  2.4.3   Inspection de paquets et sondes NETFLOW / IPFix pour palier au

problème ................................................................................................... 29  2.4.4   Vers une méthode d’agrégation de plusieurs source de données pour la

surveillance IPv6 générés aléatoirement ................................................... 30  

VI

2.4.5   Architecture proposée ............................................................................... 31  2.4.6   Mise en pratique ........................................................................................ 32  2.4.7   Conclusion ................................................................................................ 33  2.4.8   Utilisation de l’extension saut après saut (hop-by-hop) ............................ 33  2.4.9   Qu’est-ce que l’extension Hop-by-hop ..................................................... 33  2.4.10   Performances et surcharge de trafic .......................................................... 35  2.4.11   Conclusion sur la méthode ........................................................................ 36  

2.5   Conclusion du chapitre ............................................................................................... 36  

Chapitre 3 : Les protocoles « FLOWS » pour améliorer la visibilité dans les réseaux. ......... 37  3.1   Introduction ................................................................................................................. 37  3.2   Principes de fonctionnement ....................................................................................... 37  

3.2.1   Les sondes ................................................................................................. 37  3.2.2   Collecteur/analyseur ................................................................................. 39  3.2.3   Bref historique de cette technologie ......................................................... 40  3.2.4   Équivalences chez d’autres constructeurs ................................................. 41  3.2.5   Le protocole Netflow : .............................................................................. 41  3.2.6   La trame Netflow V9: ............................................................................... 42  

3.3   Vers l’optimisation de la gestion et de l’acquisition des « flows ». ........................... 43  3.3.1   Une technologie efficace, mais gourmande en ressources ........................ 43  3.3.2   Méthode d’échantillonnage des flux Flexbile-Netflow ........................... 48  3.3.3   Conclusion sur les performances .............................................................. 48  3.3.4   Parallélisassions du traitement des flows .................................................. 49  3.3.5   Parallélisassions et décomposition des flux .............................................. 49  3.3.6   Résultats et conclusion .............................................................................. 50  

3.4   Augmenter la visibilité dans les centres de données grâce à Netflow-lite .................. 51  3.4.1   L’obligation d’un collecteur Netflow-Lite vers Netflow/IPFIX : Nprobe 53  3.4.2   Optimisations : Round-Robin et PF_RING .............................................. 54  3.4.3   Résultats et conclusions ............................................................................ 55  

3.5   VoIP et surveillance des communications : vers la détection d’attaques grâce aux flows ............................................................................................................................ 57  3.5.1   La VoIP, un marché de plus en plus important ......................................... 57  3.5.2   SIP et RTP : deux protocoles sensibles aux attaques ................................ 57  3.5.3   VoIP et flows : que doit-on surveiller et comment ? ............................... 58  3.5.4   Quels types d’attaques surveiller ? ........................................................... 60  3.5.5   Méthodes de détection .............................................................................. 62  3.5.6   Exemple avec une attaque « RTP Flooding » ........................................... 63  3.5.7   Résultats .................................................................................................... 65  

3.6   Mesure de la perte de paquet grâce à aux flows .......................................................... 66  3.6.1   Genèse des « superflow »s ........................................................................ 66  3.6.2   Méthode et environnement de création des « superflows » ...................... 68  3.6.3   Résultats .................................................................................................... 69  

3.7   Conclusion du chapitre ............................................................................................... 71  

Chapitre 4: La supervision et ses concepts appliqués à un réseau d’entreprise. ..................... 72  

VII

4.1   Prévention et taux de disponibilité ...............................................................................72  4.2   Surveiller quoi et à quel niveau ? .................................................................................73  4.3   Ordonnanceur /superviseur: quel est son rôle .............................................................75  

4.3.1   Nagios, une référence en perte de vitesse ................................................. 76  4.3.2   Shinken : un fork de Nagios performant et modulaire .............................. 77  4.3.3   Architecture interne de Shinken ................................................................ 78  4.3.4   Conclusion sur Shinken ............................................................................ 80  

4.4   Métrologie : quoi représenter et comment ? ................................................................80  4.4.1   Cacti, un acteur majeur de la métrologie .................................................. 80  4.4.2   Fonctionnement d’une base RRD ............................................................. 81  4.4.3   Cacti un outil puissant, mais avec certaines faiblesses ............................. 82  4.4.4   Graphite, un conçurent qui gagne du terrain ............................................. 83  4.4.5   Carbon , l’acquisition simplifiée des données .......................................... 85  4.4.6   Whisper, les différences par rapport à RRDtool ....................................... 85  4.4.7   Création d’une source de donnée, simplicité et efficacité ........................ 86  

4.5   Conclusion du chapitre ................................................................................................86  

Chapitre 5 : Supervision et de métrologie homogène : CollectD, PerfTap, Shinken et Graphite ......................................................................................................88  

5.1   Les besoins en termes de supervision de l’opérateur ContactOI .................................90  5.1.1   Architecture de l’opérateur ContactOI et zones de surveillance .............. 90  5.1.2   Scénrario 1 : Surveillance de l’hyperviseur VMware ESX5 ................... 92  

5.1.2.1   Objectif ...................................................................................... 92  5.1.2.2   Mise en pratique ......................................................................... 93  5.1.2.3   Interprétation des données de performance sur Graphite .......... 94  5.1.2.4   Conclusion ................................................................................. 94  

5.1.3   Scénario 2 : Surveillance des serveurs sous Unix/Linux avec CollectD .. 94  5.1.3.1   Objectif ...................................................................................... 95  5.1.3.2   Mise en pratique ......................................................................... 96  5.1.3.3   Conclusion sur CollectD ............................................................ 97  

5.1.4   Scénario 3 : Surveillance des serveurs sous Windows avec Perftap ou Shinken ..................................................................................................... 97  5.1.4.1   Objectif ...................................................................................... 97  5.1.4.2   Une alternative à PerfTap, le plugin Check_WMI de Shinken. 98  5.1.4.3   Conclusion ................................................................................. 99  

5.1.5   Supervision d’équipement par SNMP, explication du fonctionnement sous SHINKEN ................................................................................................. 99  

5.1.6   Scénario 4 : Surveillance du backbone Cisco ......................................... 101  5.1.6.1   Objectif .................................................................................... 101  5.1.6.2   Mise en pratique ....................................................................... 101  5.1.6.3   Conclusion ............................................................................... 101  

5.1.7   Scénario 5: Surveillance des liaisons Wimax par SNMP ....................... 102  5.1.7.1   Objectif .................................................................................... 102  5.1.7.2   Interrogation SNMP des équipements ..................................... 102  5.1.7.3   Interprétation des données de performance sur Graphite ........ 103  

VIII

5.1.8   Scénario 6 : Création d’un « smokeping » .............................................. 104  5.1.8.1   Objectif .................................................................................... 105  

5.1.9   Scénario 7 : Supervision d’une liaison WAN avec nTop ....................... 105  5.1.9.1   Objectif .................................................................................... 106  

5.1.10   Interface utilisateur pour Shinken ........................................................... 107  5.1.11   Nagvis, cartographie des réseaux et plans interactifs ............................. 109  

5.2   Conclusion du chapitre ............................................................................................. 111  

Chapitre 6: Conclusion générale ........................................................................................... 109  6.1   Retour sur expérience ............................................................................................... 110  

Références 112  

IX

LISTE DES FIGURES

Page

Figure 1 : Ijenko Home Area network [6] .................................................................................2  

Figure 2 : exemple d'environnement SNMP ..............................................................................4  

Figure 3: Modèle en couche NETCONF [18] ............................................................................6  

Figure 4: Intégration du langage YANG dans l'environnement de gestion [18] .......................6  

Figure 5 : Neuf opérations du langage [20] ...............................................................................7  

Figure 6 : Différence entre une communication SNMP et NETCONF .....................................7  

Figure 7 : Récupération d'une configuration complète (plusieurs attributs) [7] ........................8  

Figure 8 : Récupération d'un seul attribut [7] ............................................................................8  

Figure 9 : Pile UPnp source : [21] .............................................................................................9  

Figure 10 : Mécanisme de découverte UPnP [23] ...................................................................10  

Figure 11: pile du protocole TR-069 [30] ................................................................................13  

Figure 12 : méthodes RPC de la norme TR-069 (CWMP) [30] ..............................................13  

Figure 13: Protocole CWMP (TR-069) ...................................................................................14  

Figure 14 : Tunnel UPnP sur le WAN .....................................................................................15  

Figure 15 : Architecture avec double pile TR-069 /UPnP sur le CPE .....................................15  

Figure 16 : Fonctionnement du bridge TR-069 / UPnP ...........................................................16  

Figure 17 : comparaison entre SNMP, NETCONF et TR-069 [35] ........................................17  

Figure 18 : résultat du comparatif SNMP / NETCONF / TR-069 [35] ...................................18  

Figure 19 : pile OSGI wikipedia.org ........................................................................................19  

Figure 20 : Piles OSGI et CWMP réunis .................................................................................20  

Figure 21 : Architecture OSGI et TR-069 réunies ...................................................................20  

X

Figure 22 : disponibilité des pools d'adresse IPv4 par RIR dans le temps [40] ...................... 23  

Figure 23: évolution de l'adoption d'IPv6 [43] ....................................................................... 24  

Figure 24: Fonctionnement des entêtes IPv6 [44] .................................................................. 25  

Figure 25 : Comparaison de l'entête IPv4 et IPv6 [44] ........................................................... 25  

Figure 26 : Architecture 6to4 .................................................................................................. 26  

Figure 27 : architecture TEREDO [49] ................................................................................... 27  

Figure 28: Gabarit de capture IPFix de paquets IPv6-over-IPv4 [37] .................................... 30  

Figure 29 : Données agrégés pour la surveillance du trafic IPv6 [36] .................................... 30  

Figure 30: Protocoles utilisés pour l'agrégation des données [36] .......................................... 31  

Figure 31 : Architecture de l'agrégation des données proposées dans l'article [36] ............... 32  

Figure 32 : pourcentage par type de trafic IPv6 [36] .............................................................. 33  

Figure 33 : traceroute en environnement normal et distribué [39] ......................................... 34  

Figure 34 : fonctionnement d'un traceroute réseaux-linux.fr .................................................. 35  

Figure 35 : traitement de l'extension "hop-by-hop" [59] ........................................................ 35  

Figure 36: Surcharge du trafic en fonction du nombre de nœuds [39] ................................... 36  

Figure 37 : Temps de traitement des deux méthodes .............................................................. 36  

Figure 38: la sonde Netflow [54] ............................................................................................ 38  

Figure 39 : Le collecteur/analyseur [54] ................................................................................. 39  

Figure 40: Architecture Netflow [54] ..................................................................................... 40  

Figure 41 : Historique de la norme Netflow / IPFIX .............................................................. 41  

Figure 42 : trame NETFLOW comprenant un gabarit et des flows de données ..................... 42  

Figure 43: Organisation du template FlowSet renater.fr ......................................................... 43  

Figure 44 : Utilisation du CPU sur un Cisco 1841 (entrée de gamme) [42] ........................... 45  

Figure 45 : Utilisation CPU sur un Cisco 12000 (haut de gamme) [42] ................................. 45  

XI

Figure 46: Résumé du pourcentage de l'augmentation de l'utilisation du CPU lors de l'activation de netflow [42] ........................................................................46  

Figure 47: Comparaison d'utilisation des ressources CPU entre Netflow V5 et V9 ...............47  

Figure 48: Comparaison d'utilisation des ressources CPU entre le Netflow (TNF) et Flexible Netflow (FNF) sur un Cisco 1841 (entrée de gamme) ..............................47  

Figure 49 : diminutions des ressources CPU grâce à l'échantillonnage (Flexible Netflow Cisco) .........................................................................................................48  

Figure 50: comparaison des ressources CPU entre Netflow et Flexible Netflow ....................48  

Figure 51 : Traitement parallèle des flows. .............................................................................49  

Figure 52 : Comparaison des performances avant et après le traitement parallèle des flows .50  

Figure 53 : Rapport entre la perte de paquet et la taille du tampon UDP ................................50  

Figure 54: Différences entre Flexible Netflow et Netflow-lite [69] ........................................52  

Figure 55 : Différence entre Netflow et Netflow-lite [69] .......................................................52  

Figure 56 : Intégration du collecteur Netflow-Lite [65] ..........................................................53  

Figure 57 : Convertisseur NProbe Netflow-lite vers Netflow [65] .........................................54  

Figure 58 : Distribution Roud-Robin des flows sur plusieurs ports UDP [65] ........................54  

Figure 59 : PF_Ring optimisation matérielle Intel 82599 et multi-cœurs ...............................55  

Figure 60 : Architecture de test de la sonde nProbe avec Netflow-Lite ..................................56  

Figure 61 : Exemple de communication SIP voipforo.com .....................................................58  

Figure 62 : métriques SIP/RTP compatibles avec nProbe [48] ...............................................59  

Figure 63 : Architecture d'une communication VoIP [79] ......................................................59  

Figure 64 : Description d'un paquet SIP pour la génération d'un flow [80] ............................60  

Figure 65 : Classification des attaques VoIP [50] ...................................................................61  

Figure 66 : Comportement d'un Proxy lors d'un « SIP flooding » [47] ...................................61  

Figure 67 : nProbe et VoIP ......................................................................................................62  

Figure 68 : Attaque par RTP Flooding ....................................................................................63  

XII

Figure 69 : algorithme de détection d'un "RTP flood" utilisant les flows [73] ....................... 64  

Figure 70 : type d'analyse pour chaque attaque [72] ............................................................... 65  

Figure 71 : performance dans la détection d'attaques VoIP [73] ............................................ 66  

Figure 72 : Précision de PING par rapport à un calcul de perte de paquet de l'article ........... 67  

Figure 73: architecture de test de l’article [89] proche de la technologie Netflow ................. 67  

Figure 74 : environnement de création des "super-flows" [87] .............................................. 68  

Figure 75: création des "super flows" [87] ............................................................................. 68  

Figure 76 : architecture de test des "super flows" [87] ........................................................... 69  

Figure 77 : Résultat des « super flows » par rapport à un dump sur l’estimation de perte de paquet. [87] ............................................................................................... 70  

Figure 78 : taux de disponibilité dans un réseau et nombre d'heures associé monitoring-fr.org ................................................................................................................... 73  

Figure 79 : niveaux de supervision et dépendances ................................................................ 74  

Figure 80 : Environnement de l'ordonnanceur ........................................................................ 75  

Figure 81 : Nagios et ses interfaces de surveillance [95] ........................................................ 76  

Figure 82 : Architecture interne de Shinken [103] ................................................................. 78  

Figure 83 : interface graphique de Cacti [113] ....................................................................... 81  

Figure 84 : scénario de rétention des données [119] ............................................................... 82  

Figure 85 : interface utilisateur de graphite [114] .................................................................. 83  

Figure 86 : API de génération des graphiques depuis l'interface web [114] .......................... 84  

Figure 87 : architecture de graphite ........................................................................................ 84  

Figure 88 : hiérarchie des données métriques ......................................................................... 86  

Figure 89: Architecture globale de supervision ...................................................................... 89  

Figure 90 : Architecture de l'opérateur ContactOI .................................................................. 91  

Figure 91 : Dépendances dans l'architecture de l'opérateur .................................................... 92  

XIII

Figure 92: Hôte Esx et machines virtuelles [129] ....................................................................93  

Figure 93 : Surveillance d'un hyperviseur ESX sous graphite .................................................94  

Figure 94 : architecture interne du démon CollectD [132] ......................................................95  

Figure 95 : Communication entre Perftap StatsD et Graphite .................................................97  

Figure 96 WMI une alternative au démon PerfTab .................................................................98  

Figure 97 : architecture du module SNMP Booster ...............................................................100  

Figure 98 : Interrogation SNMP sur les équipements Alvarion ............................................103  

Figure 99 : SNR montant et descendant entre une BTS et un CPE Alvarion ........................104  

Figure 100 : Graphique Smokeping [??] ................................................................................104  

Figure 101 : SmokePing sous Graphite grâce à l’add on Check_ICMP ................................105  

Figure 102 : boitier TAP et nTOP pour l'analyse d'une liaison WAN ...................................106  

Figure 103 : exemple de graphique d'analyse du trafic sous nTop [66] ................................107  

Figure 104 : tableau de bord de Shinken [94] ........................................................................107  

Figure 105: graphe dynamique de relation service/hôte [95] ................................................108  

Figure 106 Shinken WebUI, une interface claire et bien pensée [95] ...................................108  

Figure 107 : Interface Android mobile pour Shinken [94] ....................................................109  

Figure 108 : Nagvis, cartographie du réseau surveillé [157] .................................................110  

Figure 109 : wheatermap sous nagivs [131] ..........................................................................110  

1

Introduction

Ce mémoire va s’articuler autour d’un thème ; la supervision des réseaux ainsi que leurs gestions. Celui-ci est réalisé en collaboration avec l’entreprise Contact OI m’accueillant pour mon projet d’intervention de fin de maitrise. Dans ce mémoire, deux parties distinctes seront présentées : la première sera un état de l’art sur plusieurs technologies ayant chacun pour références des recherches effectué par la communauté scientifique. A l’heure actuelle, et avec l’évolution grandissante des technologies et le passage au tout IP (over IP), la communauté scientifique tente d’imaginer ce que seront les protocoles et technologies de surveillance de demain. Nous verrons dans le premier chapitre qu’une évolution technologique sur la surveillance (ou monitoring en anglais) nécessite de connaitre l’existant afin de faire évoluer les technologies dans la bonne direction. Ce chapitre sera consacré à la description, la comparaison et l’évolution des protocoles de surveillance et de gestion des CPE (Custom Premises Equipement) d’un opérateur de télécommunication. Puis dans le chapitre deux, nous nous intéresserons à la surveillance IPv6, protocole succédant à IPv4 dans un avenir proche mais dont l’implantation et la connaissance ne permet pas, à l’heure actuelle, une supervision poussée. Le chapitre deux sera donc consacré à un état de l’art des recherches actuelles sur la supervision et l’analyse des réseaux émergeant sous IPv6. Quant au chapitre 3, dernier chapitre ayant un lien avec les recherches en réseaux et télécommunications, il sera question des technologies de type flows crées par Cisco puis reprises et adaptées aux réseaux actuelles (réseaux étendus de type WAN, réseaux de Voix sur IP, réseaux IPv6…). Nous verrons dans ce chapitre des aspects d’échantillonnage, d’inspection et de mesure de perte du trafic. Quant à la seconde partie, il sera question d’une introduction des concepts de surveillance des réseaux de télécommunication au sein de l’entreprise Contact OI, spécialisée dans le déploiement d’accès internet et point à point sur WIMAX et WiFi. Nous verrons dans le chapitre quatre ce qu’est la supervision, son but au sein d’une entreprise ainsi qu’une présentation des deux grandes familles de logiciel que sont les ordonnanceurs et les outils de métrologie. Ce chapitre aura pour objectif de permettre la transition des concepts et des technologies du monde de la recherche vers des technologies applicables en entreprise. Nous terminerons ce mémoire avec un chapitre 5 ayant comme but la définition d’une architecture de supervision du réseau de l’opérateur ContactOI homogène et basée sur une sélection d’outils open source. Plusieurs scénarios, traitant chacun d’une partie de l’architecture de l’opérateur permettront de décrire avec précision le rôle et l’utilité d’une supervision. Ce mémoire aura donc double utilité puisque passant de la partie théorique à pratique, il couvrira un large éventail de technologies et de concepts propre à la supervision et au management des réseaux de télécommunications.

2

Chapitre 1 : État de l’art du management des équipements clients (CPE) d'un opérateur

1.1 Introduction

Ces dernières années sont apparues toute une gamme de services associés au marché de l'accès internet grand public. A l'heure actuelle, les offres de triple-play (voir quadruple) sont courantes et l'utilisateur peut se retrouver dorénavant avec des offres regroupant les données IP, la voix sur IP, la télévision ainsi que d'autres services à la demande comme la VoD (Video On Demand).

Cette augmentation des services fournis par les ISP (Internet Service Provider), rend nécessaire l'avènement d'équipements clients de plus en plus performants et évolués. De nombreux acronymes anglais définissent l'équipement client notamment CPE (Custom Premises Equipement) STB (Set Top Box) ou bien, plus simplement, Gateway. Pour preuve, le récent article [1] donnant une vision de ce que tend à être le HAN (Home Area Network) avec la convergence des appareils électroniques intelligents et de leurs interconnexions. Des standards tels que la ZigBee Alliance [2], le low Power WiFi [3], l'HomePlug[4] visent à rendre les habitations communicantes aussi bien à l'intérieur qu’à l’extérieur.

L'avènement de ces nouvelles technologies et services HAN demandent donc une gestion de plus en plus pointue et importante des CPE. Au point qu'aujourd'hui, comme l'explique l'introduction de l'article[5], il n'y plus de limites aux offres commerciales que peuvent proposer les ISP.

Figure 1 : Ijenko Home Area network [6]

3

Malheureusement, ceux-ci seront limites à cause de problème de gestion, notamment celui des CPE.

Beaucoup d'ISP se retrouvent alors devant une problématique grandissante, la gestion des équipements client (CPE). Maintenir une vue et un accès performant aux paramétrages de ceux-ci permet un gain de temps et d'argent conséquent. La figure 1 est une implémentation commerciale du standard Zigbee [2]. Le constructeur met ici en avant la communication de ses équipements vers l’extérieur (Internet) sans pour autant donné de détail sur la méthode, les protocoles ainsi que le matériel nécessaire à cet effet. La simple passerelle wifi et le nuage Internet de ce schéma cachent en effet des technologies et des protocoles de gestion de ces gateway (ou CPE) qui seront décrits par la suite.

1.2 Vers la nécessité d'un protocole de gestion des CPE

Lorsque l'on parle de gestion des CPE, il faut en fait discerner plusieurs étapes dans la vie de ces équipements. L'introduction de l'article [6] les liste de cette manière :

• installation initiale • configuration • gestion et surveillance

Ces trois étapes du déploiement forment le cycle de vie d'un CPE reliant un client au réseau d'un opérateur. La complexité grandissante et l'augmentation de la taille et du nombre de clients forcent aujourd'hui les opérateurs à ne pas négliger ces trois étapes. L'automatisation de celles-ci va devenir nécessaire sous peine d'alourdir de manière importante la gestion des réseaux des ISP. Nous allons voir dans cette partie du mémoire, différents protocoles et méthodes de gestion des CPE.

1.3 Gestion par ligne de commande (CLI)

Il peut paraitre surprenant de commencer ce tour d’horizon par le CLI (Command Line Interface) mais il faut savoir qu’à l’heure actuelle (soit 2012), l’accès par ligne de commande sur les CPE reste un des moyens les plus efficaces pour gérer un équipement à la fois. Comme l’explique l’article [7] dans leur introduction, l’héritage du mode CLI provient des constructeurs et équipementiers cherchant à fournir un moyen simple et performant de gestion de leurs équipements respectifs. Le mode CLI se basant sur des protocoles comme TELNET [8] et SSH [9] permettant de réaliser toutes les étapes décrites ci-dessus (installation, configuration et gestion / surveillance). Mais quand est-il dans un réseau WAN étendu comportant plusieurs centaines d’équipements nécessitant une maintenance? Seule une intégration au cas par cas, en fonction de la marque et du modèle permet, par l’intermédiaire de langages comme PYTHON, PERL ou BASH de créer des scripts de maintenance permettant l’automatisation des commandes, sur un ou plusieurs équipements à la fois. Le mode CLI ne peut donc pas être considéré comme une méthode de gestion performante et ne peut être qu’une méthode d’appoint pour la gestion des CPE.

4

1.4 SNMP, un standard éprouvé mais avec des faiblesses

Standard de l'IETF défini par la RFC 1157 [10] datant de 1990, ce protocole est aujourd'hui utilisé et implémenté dans la majorité des équipements informatiques et de télécommunication dans le monde. Jusqu'à aujourd'hui SNMP (Simple Network Management Protocol) a toujours été une solution de base pour la gestion et à la surveillance des équipements. Un environnement SNMP de base est formé de quatre composants:

• un agent sur l'équipement à surveiller (RFC 1157); • une MIB (Manage Information Base) qui définit la base des informations de gestion

disponible sur l'équipement (RFC 1066 [11]); • une station de surveillant ou NMS (Network Management System); • un protocole de communication permettant le dialogue entre l’agent et le NMS (ex : SNMP

Request / SNMP Responce) et la réception des alertes (SNMP trap). Au fil des années, le protocole SNMP évolua en 3 versions majeures :

• SNMPv1 : version standard de base du protocole, n’implémentant qu’une sécurité basique sur le nom de communauté de l’agent et des performances médiocres;

• SNMPv2c : amélioration des performances et de la sécurité; • SNMPv3 : sécurisation des échanges entre l’agent et le NMS par l’implémentation de

mécanismes de cryptage DES. Celui-ci se fait sur la base d’un mot de passe partagé. La RFC 3826 [12] introduit également le chiffrement AES sur SNMPv3.

Figure 2 : exemple d'environnement SNMP

5

Son adoption est due notamment à : • sa relative simplicité de mise en œuvre. Le mot relatif prend tout son sens lorsque

l'on cherche à gérer en détail un équipement sur la base des MIB constructeurs. La complexité et le nombre de celles-ci peuvent alors rendre l'opération bien plus compliquée ;

• un protocole de communication asymétrique basé sur le couple IP/UDP, constitué d'un ensemble simple de requêtes questions / réponses et d'un nombre limité d'alertes ;

• une adoption massive de la part des constructeurs et équipementiers en tout genre (télécoms, électriques, industriels...).

Malgré cela, le protocole SNMP est de moins en moins adapté aux réseaux d'opérateurs de grandes tailles. Comme l'explique l'article [6] dans son introduction sur SNMP, l'utilisation d'UDP sur un WAN (Wide Area Network) ne garantit pas la sécurité des communications. La communication "best-effort " d'UDP, rajouté à cela les aléas inhérents un à réseaux WAN (lenteur, gestion de la QoS, perte de paquets, longues distances...) faits que le choix de SNMP pour la gestion des CPE s'en trouve amoindris.

L’article [7] sur la base du document de l’IETF [13] donne également 7 critères remettant en cause le choix de SNMP comme protocole de gestion : SNMP ne gère pas la configuration d’un équipement dans son ensemble. Il permet seulement de comparer un seul paramètre à la fois. Il n’y a donc aucune gestion de l’intégrité de la configuration globale. SNMP souffre de mauvaises performances lors de transfert de gros volumes d’information Le manque d’optimisation dans les requêtes (SNMP Get / SNMP Get Bulk) nécessitant la multiplication de celles-ci au temps de fois qu’il n’y a d’équipements Le manque de documentation sur les modules MIB fournis par les constructeurs d’équipement. Les informations sur comment et où interroger les MIB sont généralement peu ou pas présentes. Le développement d’outils basés sur SNMP n’est pas optimum, dû au langage bas niveau de celui-ci. L’achat et la maintenance d’outils basés sur SNMP sont coûteux. SNMP n’implémente pas de standard de sécurité dans ses versions 1 et 2c. La version 2c (la plus répandue), intègre seulement un mot de passe (string) nommé « community » et facilement déchiffrable par sniffing ou bruteforce. L’IETF a d’ailleurs, depuis 2004, classé les versions 1 et 2c comme « historique », seule la version 3 est aujourd’hui considérée comme un standard exploitable. Il n’en demeure pas moins que la version 2c reste la plus utilisée à ce jour. L’IETF a depuis publié des études [14] démontrant ainsi la nécessité de passer à la version 3. Revers de la médaille, des études [15] montrent l’impact non négligeable sur les performances des requêtes SNMPv3 lors de l’ajout de protocoles sécuritaires (SSH, TLS, DTLS…). Dernier point, l’envoi de SNMP TRAP par les agents ne fournit pas de description compréhensible par le commun des mortels. Ces SNMP TRAP nécessitent souvent un mécanisme de translation une fois celles-ci réceptionnées par le NMS.

6

Ces sept points permettent de remettre fortement en cause la pertinence de l’usage du protocole SNMP dans des environnements où les déploiements deviennent massifs en termes de nombre et de diversité d'équipement et/ou la sécurité est un paramètre important.

1.5 NETCONF : l’évolution du SNMP par l’IETF

Le protocole NETCONF [16] est lui aussi un standard de l'IETF dont la première publication date de décembre 2006. Le but de ce protocole est de fournir un mécanisme de gestion, de manipulation et de configuration d'équipement réseau à la manière de SNMP. L'utilisation de TCP/IP et de ses mécanismes (mode connecté, gestion des erreurs, contrôle des flux…) permet de garantir une qualité de service sur la gestion des équipements. Le protocole utilise la couche RPC (Remote Procedure Call) [17] pour établir le dialogue entre un agent NETCONF et une station de gestion (NMS). Ce protocole se veut modulaire puisque le standard fut défini pour être compatible avec plusieurs protocoles de la couche transport du modèle OSI (voir figure 3), notamment SSH (Secure Shell), TLS (Transport Socket Layer), BEEP (Blocks Extensible Exchange Protocol), SOAP et CLI / TELNET (Commande Line Interface).

Chaque contenu de message de dialogue NETCONF entre l'agent et la station se base sur XML (Extensible Markup Langage) chaque message XML est formaté grâce à un langage de modélisation nommé YANG [18]. La couche opération, gérée par le langage YANG est accompagné d'une librairie type nommée Common YANK Data Types [19]. Celle-ci fournit neuf opérations de base permettant l'interaction avec l'équipement réseau disposant de l'agent NETCONF. On remarquera de grandes similitudes avec les opérations de base du langage SNMP.

Figure 3: Modèle en couche NETCONF [18]

Figure 4: Intégration du langage YANG dans l'environnement de gestion [18]

7

Figure 5 : Neuf opérations du langage [20]

La figure 5 ci-dessus, montrant la liste des opérations possibles sur les objets de configuration au sein de NETCONF permet de mettre en évidence les similitudes entre SNMP et NETCONF au niveau des opérations. Nous verrons dans la section suivante en quoi l’évolution vers NETCONF est une avancée en termes de performance et de fonctionnalité.

1.5.1 D’une approche orientée variable à une approche objet

Comme l’explique l’article [7], la manière de gérer l’équipement est différente de SNMP à NETCONF.

Figure 6 : Différence entre une communication SNMP et NETCONF

8

L’approche orientée variable de SNMP est laissée au profit d’une approche objet. Sous SNMP, la modification de plusieurs attributs (ou OID) passe par l’envoi de plusieurs requêtes SNMP SET, il en découle un nombre important de transactions du faite de la transmission de plusieurs paquets UDP. Sous NETCONF l’approche objet permet d’insérer tous les attributs ayant à subir une modification dans un fichier XML (Extend Markup Language) et cela permet une simplification comme le montre les études réalisées dans l’article [7] puisqu’une seule transmission est nécessaire.

Figure 7 : Récupération d'une configuration complète (plusieurs attributs) [7]

Figure 8 : Récupération d'un seul attribut [7]

Les résultats montrent des gains importants en termes d’économie de transactions lors de la récupération de configurations complètes entre SNMP et NETCONF. Il en résulte une simplification des échanges protocolaires entre l’agent et la station pour une faible augmentation de trafic permettant ainsi une meilleure gestion du trafic NETCONF par rapport à SNMP.

1.5.2 Vers une compatibilité SNMP depuis NETCONF

Depuis l'été 2010, le groupe NETMOD [16] responsable du suivie et de l'évolution de la norme travaille sur l'interopérabilité de la norme NETCONF avec SNMP. En effet, il est logique de penser que l'adoption de NETCONF dans les entreprises passera par une passerelle SNMP/NETCONF, comme proposé dans l’article [7]. Il est aujourd'hui impossible d'envisager l'abandon du protocole SNMP d'une manière plus radicale. Actuellement des travaux de translation entre le langage YANG et le langage SMIlv2 [21] sont en cours. Le langage SMIlv2 étant la structure de modélisation de l’entrée contenue dans la MIB (voir SNMP). Le but de l'IETF étant, pour fin 2012, de proposer un modèle de compatibilité pour communication avec des agents SNMP (v2 et v3) depuis le protocole NETCONF.

9

1.6 UPnP, un protocole de management côté LAN.

Né du besoin de simplifier le paramétrage du CPE par le client, UPnP (Universal Plug and Play) [22] prend tout son sens au sein du LAN (Local Area Network) ou HAN (Home Area Network) d'un client d’ISP (Internet Service Provider) n'ayant pas la compétence technique nécessaire pour le paramétrage du CPE, notamment pour :

• la gestion du NAT (Network Area Translation) et du PAT (Port adresse Translation) entre le LAN (réseau local) et le WAN (réseau public du fournisseur)

• la gestion du pare-feu interne au CPE pour la communication entre le LAN et le WAN des applications.

Le protocole UPnP intègre donc un mécanisme de découverte et de contrôle des équipements tels que les imprimantes, NAS (Network Area Storage)... et les services logiciels nécessitant un paramétrage. Ce standard se base sur des briques existantes (IP, UDP, SSDP, HTTP, SOAP et XML). UPnP est idéal pour la gestion et l'auto configuration dans un LAN client et, à la manière de SNMP, est aujourd'hui massivement supporté dans le secteur des équipements grand public. Mais, comme

décrit dans l'article [6], celui-ci n'a pas la vocation à être utilisé pour la gestion des équipements depuis un réseau public d'opérateur de type WAN. Notamment du fait que celui-ci n'intègre aucun mécanisme de sécurisation des échanges ainsi qu'à l'utilisation du protocole UDP pour la découverte des équipements via SSDP (Simple Service Discovery Protocol).

Figure 9 : Pile UPnp source : [21]

10

En effet, comme le montre la figure 10 issue de la documentation d’architecture du standard UPnP [23], lors de l’ajout d’un équipement (device), celui-ci envoie des messages UDP multicast vers le ou les CPE (control point).

Figure 10 : Mécanisme de découverte UPnP [23]

La diffusion de paquets multicast over UDP peut poser de nombreux problèmes comme :

• la saturation de liaison WAN (flooding) ayant généralement de plus faibles débits qu’une liaison LAN

• des problèmes de relais des paquets multicast à travers les équipements backbone (routeurs, commutateurs…)

• une mauvaise configuration des groupes sur les équipements peut également entrainer du flooding (surcharge et saturation du à un trop fort nombre de communications). Si l’équipement faisant transiter le paquet multicast ne connait pas la destination, il peut alors faire un broadcast du paquet sur toutes ses interfaces.

• La gestion de VLAN (Virtual LAN), tunnels MPLS (Multi Protocol Label Switching) ou GRE (General Routing Encapsulation) afin d’adapter la transmission du multicast sur un WAN.

1.6.1 Points faibles et vulnérabilités

Les sections suivantes ne sont que des exemples parmi une liste relativement importante de faille et problèmes d’implémentation d’UPnP par les constructeurs. Pour une liste exhaustive, il est intéressant de se rendre sur le site [24].

11

1.6.2 Pas d’authentification

UPnp ne dispose d’aucune méthode d’authentification entre le CPE et l’équipement. Par défaut, la communication UPnP entre deux équipements assume qu’ils soient respectivement dignes de confiance. Des extensions non officielles comme celle de l’article [25] proposent une implémentation d’authentification et d’autorisation, mais hélas aucune n’est fournie par défaut et des attaques se basant sur la faiblesse de l’authentification sont envisageables. On peut par exemple citer l’attaque [26] permettant de générer un message SOAP en direction d’un routeur ayant UPnP d’activé. Ce message rajoutant une règle dans le pare-feu du CPE, rendant celui-ci accessible et contrôlable depuis l’extérieur.

1.6.3 Requète UPnp depuis le WAN

Cette faille majeure [27] fut découverte en 2011 et publié à la convention DEFCON 19. Le chercheur Daniel Garcia publia un logiciel capable d’utiliser une faiblesse d’UPnP permettant notamment de mapper une IP externe (Internet). Un grand nombre d’équipements de plusieurs constructeurs (Cisco, Zyxel, Linksys…) furent touchés par cette faille. Elle permet entre autre au routeur d’accepter des requestes UPnP venant de l’extérieur (WAN) chose normalement interdite et seulement possible depuis le réseau local LAN. Des requêtes telles que « AddPortMapping » ou « DeletePortMapping » permettent à un attaquant de contrôler depuis l’extérieur un CPE d’un client. L’article complet sur le déroulement de l’attaque est disponible sur le site de l’événement DEFCON [28].

1.6.4 Le futur d’UPnP

La norme est activement soutenue par l’UPnP forum [22], des évolutions de la normes furent ratifiées par l’UPnP forum et actuellement la version 1.1 [23] se trouve être la dernière mouture. Des évolutions pour supporter le protocole UPnP à travers un réseau WAN comme UPnP IGD (Internet Gateway Device) et UPnP IGD 2 [29] sont également en cour de ratification par le consortium.

1.6.5 Conclusion

Il est bon de confirmer pour conclure sur ce protocole, qu’UPnP est parfaitement adapté à la gestion des CPE depuis le LAN du client. Il est par contre aujourd’hui rare de voir des implémentations de ce protocole sur un WAN de fournisseur d’accès internet. Les vulnérabilités découvertes, la gestion du multicast, le manque d’authentification en font un protocole potentiellement risqué sur les liaisons WAN. Concernant son utilisation sur les réseaux LAN, celle-ci est également entachée dû aux failles découvertes et à la faiblesse de l’authentification. A telle point qu’aujourd’hui, à moins d’avoir un équipement (CPE, Gateway, box…) ayant subi des mises à jour corrigeant les failles de l’UPnP, il est généralement conseillé de le désactiver.

1.7 TR-069: vers un protocole de management côté WAN

Le protocole TR-069 [30] ou appelé aussi CWMP (CPE Wan Management Protocol) est né de l'initiative du Broadband Forum [31] dans le but de combler des limites des autres protocoles de gestion d'équipement, notamment de SNMP. Il se trouve être en concurrence direct avec le

12

protocole NETCONF. Comme l'explique l'article [6], le TR-069 tente d'être la solution promise pour la gestion d'équipement distant depuis un réseau WAN. En effet, celui-ci mets en place une architecture pensé pour les WAN d'opérateur de télécommunication et offre une gestion de service, de contrôle et de diagnostic des CPE à distance tout en répondant à des critères d'indépendance par rapport aux constructeurs d'équipement. Le protocole TR-069, par rapport aux autres protocoles tel que le SNMP, permet de résoudre les problèmes récurrents comme:

• la traversée des NAT par l'intermédiaire de la prise en charge d'un serveur STUN (Simple Traversal of UDP through NATs) [32]

• l’augmentation du niveau de sécurité par rapport au SNMP et de ses failles (utilisation de SSL/TLS)

TR-069 dispose entre autre des fonctionnalités suivantes:

• l'auto configuration des CPE • la gestion du firmware et du logiciel interne des CPE • la surveillance de l'état et des performances des CPE • le diagnostic du matériel

1.7.1 Architecture du TR-069:

L'architecture de mise en place du protocole se compose des éléments suivants: • ACS (Auto Configuration Server) : serveur communicant avec le CPE • OSS / BSS : base de donnée des profils et configurations des CPE • Plusieurs modèles de données (similaire aux MIB du protocole SNMP) • TR-098 : Modèle de données du CPE • TR-106 : Gabarits pour la simplification des configurations • TR-143: Modèle servant au diagnostic et au monitoring • TR-157 : Modèle d'objets communs réutilisables • …

Comme le montre la figure 11, celui-ci est semblable à NETCONF. Les protocoles TCP/IP, SSL/TLS, HTTP et SOAP forment les briques de base pour la communication TR-069.

13

Là où la différence se fait par rapport à NETCONF, est au niveau des méthodes RPC (voir figure 12) définit par la norme pour communiquer avec le CPE (à partir de la couche « DSL Forum Standard »). Cela montre une fois de plus la similitude entre NETCONF et TR-069. Un avantage pouvant déboucher vers une interopérabilité de ces deux normes.

Figure 11: pile du protocole TR-069 [30]

Figure 12 : méthodes RPC de la norme TR-069 (CWMP) [30]

14

1.7.2 Une extension vers les réseaux LAN, le TR-133

Comme l’explique les chercheurs dans l’article [6], TR-069 est en évolution constante. Des modèles standards s’ajoutent à ceux de base afin de définir la gestion des configurations des CPE côté LAN [33]. On peut toute de suite imaginer le champ d’action de celui-ci, remplacer le protocole UPnP de l’UPnP forum.

Figure 13: Protocole CWMP (TR-069)

1.7.3 Un modèle de données standard pour chaque service et pour chaque équipement

Comme expliqué dans les paragraphes ci-dessus, le but du Broandband Forum, à travers le TR-069, est d’avoir un modèle de données pour chaque service / équipement que le fournisseur doit gérer à travers ou en plus du CPE. C’est pour cela que d’autres modèles [30] existent comme :

• TR-104 pour les services VoIP (Voice Over IP) • TR-140 pour les services de stockage SAN (stockage Area Network) • TR-135 pour les STB (Set Top Box) et autres décodeurs vidéo IP • TR-196 pour les FemtoCell (antenne cellulaire intégrée dans certains CPE) • …

La norme étant toujours en développement, de nouvelles versions ainsi que de nouveaux modèles sortent chaque année.

1.7.4 Vers une compatibilité entre TR-069 et UPnP ?

Y a-t-il moyen de rendre un protocole de gestion axé WAN avec un protocole de gestion côté LAN ? C’est ce que l’article [34] tente de démontrer. Les chercheurs ont ici réalisé un prototype intégrant la gestion d’un équipement non TR-069, ayant seulement une compatibilité UPnP, dans un environnement TR-069. En effet, beaucoup de CPE peu coûteux utilisés chez les fournisseurs d’accès ne seront jamais compatible avec le TR-069 faute d’une couche matériel peu puissante ou d’un support à l’arrêt pour cause de matériel obsolète.

15

Comme explique l’article [34] UPnP et TR-069 sont basés sur une architecture similaire, à savoir l’utilisation du protocole SOAP (Simple Object Acces Protocol) pour le dialogue entre les équipements. Les chercheurs, proposent deux architectures potentiellement réalisables. La première architecture étant la création d’un tunnel UPnP à travers le CPE et l’ACS. Cette solution étant la moins couteuse en termes de modification du CPE, puisqu’un modèle comportant seulement les fonctionnalités UPnP est nécessaire. Revers de la médaille, cette architecture (voir figure 14) cause une surcharge de trafic sur le WAN du fournisseur ainsi que la nécessité de garder le tunnel fonctionnel en tout temps.

Figure 14 : Tunnel UPnP sur le WAN

La seconde approche nécessite un CPE puissant comportant à la fois les fonctionnalités TR-069 et UPnP. Elle ne nécessite donc pas de tunnel (permettant ainsi de diminuer le trafic WAN) mais une passerelle sur le CPE permettant la communication. La solution se compose donc :

• d’une simple extension développée sur le contrôleur ACS • une API (Application Programming Interface) CMS (Configuration Management

System) faisant office de passerelle sur le CPE

Figure 15 : Architecture avec double pile TR-069 /UPnP sur le CPE

16

Avec cette architecture, les chercheurs sont parvenus à intégrer la gestion d’un CPE non compatible TR-069 à moindre coût. L’utilisation des protocoles TR-069 et UPnP dans la gestion des équipements (CPE, STB…) peut alors devenir une alternative valable pour un opérateur de télécommunication.

1.8 TR-069 / NETCONF : est-ce la même chose ?

Lorsque l’on examine le modèle de donnée du CPE au sein du TR-069, de grandes similitudes apparaissent entre TR-069 et NETCONF. Bien que ce soit des standards gérés par deux organismes différents, le fait d’utiliser les mêmes technologies (RPC, SOAP, XML) rend ces deux protocoles similaires et l’échange des données au format XML faciliterait l’interopérabilité de ceux-ci. A l’heure actuelle, aux vues des articles présents au sein des bases de données scientifique et par rapport aux travaux effectués par le Broadband forum et l’IETF, il semblerait que TR-069 soit plus avancé et disposerait d’implémentations commerciales performantes. De plus, après recherche, il semblerait qu’aucune recherche ne soit effectuée sur cette interopérabilité, comme beaucoup de guerre entre standards, le choix des industriels des télécommunications pèsera dans la balance pour le choix d’un des deux protocoles.

1.9 Comparaison d’un point de vue performance entre SNMP, NETCONF et TR-069

Après avoir décrit les architectures des différents protocoles cités précédemment, voici une comparaison d’un point de vue performance de ces protocoles de gestion. Cette partie fait suite à l’article [35] où les chercheurs se sont intéressés aux modèles de données utilisés dans les trois protocoles à savoir SNMP, NETCONF et TR-069. Voici un tableau tiré de l’article résumant les 3 protocoles :

Figure 16 : Fonctionnement du bridge TR-069 / UPnP

17

Figure 17 : comparaison entre SNMP, NETCONF et TR-069 [35]

Pour rappel, les protocoles NETCONF et TR-069 sont relativement semblables de par leur architecture. Seule différence, l’utilisation du langage YANG pour NETCONF par rapport aux documents XML natif de TR-069. Cette étude s’est attaché à différencier les trois protocoles sur six points, avec pour chaque point, plusieurs sous critères :

• interopérabilité : est-il possible d’interagir avec d’autres protocoles de manière simple ? • facilité de lecture: le protocole est facilement déchiffrable par une machine et par l’être

humaine ? • modélisation des données: la modélisation est-elle adapté et suffisamment spécifique à

chaque type de donnée ? • conformité: le langage est-il rétro compatible avec les précédentes versions ? • extensibilité: est-il conçu pour être extensible par l’ajout de nouveaux modules ? • sécurité: est-il suffisamment sécurisé pour permettre de transmettre des informations de

manière intègre ? Chaque critère étant noté de 0 à 3 comme suivant :

• 0: incompatible • 1: faible • 2: bon • 3: excellent

La figure 18 ci-dessous montre les résultats donnés pour chaque sous-critère. Il en résulte les conclusions suivantes :

• le langage YANG part avec une longueur d’avance puisqu’il a été développé pour NETCONF. Celui-ci est donc plus performant mais cela le rend dépendant de NETCONF.

• A contrario XML est indépendant de TR-069 et est donc plus polyvalent. • Le langage YANG est un bon compromis entre le langage machine et le langage humain.

Au contraire de SMI, langage machine, complexe à déchiffrer. • YANG permet une notion de contraire dans la définition des données (14 types) au contraire

de TR-069 et SMI (6 types). • YANG intègre la gestion complète des versions et des révisions de n’importe quelle donnée

au sein du langage de modélisation. Côté TR-069, seul les versions hardware et software sont gérées.

18

• L’extension à de nouveaux types de données peut aussi bien être réalisée côté YANG que TR-069. Du côté de SMI, seul l’ajout de nouveaux types de données est possible.

• La granularité en ce qui concerne le contrôle des équipements est bonne dans les 3 langages, avec une préférence pour YANG puisque celui-ci permet un accès multiutilisateurs incluant des mécanismes de blocage (lock) pendant une configuration.

Figure 18 : résultat du comparatif SNMP / NETCONF / TR-069 [35]

19

Au vue de cette comparaison, le langage YANG parait le plus performant sur le papier, suivit du TR-069 puis de SMI (SNMP), reste à savoir quel langage sera adopté par le monde de l’industrie. Car un langage performant n’est pas forcement pratique à utiliser et vice versa. On remarquera également que le langage SMI de SNMP ne se trouve jamais en première position, faute à un langage vieillissant et non adapté au nouveau réseau et équipements de télécommunication.

1.10 OSGI: le management applicatif distant

Le standard OSGI (Open Services Gateway Initiative) est né d'une alliance (OSGI Alliance) [36]de plusieurs grands acteurs de l'industrie du logiciel autour d'un concept: la gestion distante d'une plate-forme de service fondée sur le langage Java. Comme l'explique l'article [6], introduisant également le standard, celui-ci est développé autour de l'environnement applicatif Java et donne un couche d'abstraction et de gestion des composantes logiciels (appelé bundle). A la sortie en 2006 de cet article, le standard ne prévoyait pas de service de gestion de l'adressage réseau, de découverte et de contrôle des équipements. Il aurait alors été impossible d'intégré un tel standard sur des CPE sans une gestion physique de l'équipement comme c’est le cas avec TR-069 ou NETCONF.

Figure 19 : pile OSGI wikipedia.org

1.11 TR-069 et OSGI : vers un couple gagnant ?

Entre temps, des recherches comme celles de l’article [37], on permis de combiner les avantages de TR-069 comme la gestion physique des équipements (firmware, adresse IP, redémarrage…) et la gestion logiciel (rajoute de fonctionnalités logicielles, de services..). La figure 20 montrent les deux

20

piles TR-069 et OSGI, on remarque que celles-ci sont indépendantes les uns des autres et permettent de couvrir l’ensemble des composant logiciel et matériel d’un CPE.

Il est alors facile d’imaginer une implication dans le cas d’une gestion centralisé des CPE chez un ISP comme le montre la figure 21 ci-dessous. Depuis 2007, l’entreprise Alcatel-Lucent détient d’ailleurs un brevet [38] sur l’interopérabilité des deux protocoles et propose dans certains de ces CPE cette fonctionnalité et propose des extensions OSGI au TR069 [39].

Figure 20 : Piles OSGI et CWMP réunis

Figure 21 : Architecture OSGI et TR-069 réunies

21

1.12 Conclusion du chapitre

Dans cette partie, il fut décrit un état de l’art relativement représentatif de l’univers des protocoles de gestion d’équipement ainsi que les dernières recherchent en la matière. Pour conclure, il est nécessaire de comprendre que la performance d’un protocole n’est pas tout dans le choix de celui-ci. Les informations décrites dans les paragraphes précédents permettent d’extraire plusieurs grandes lignes dans le choix d’une technologie de management :

• Depuis quels réseaux (LAN, WAN..) le protocole permet-il de manager les équipements. • Quel est l’étendu des fonctionnalités du protocole (gestion software, Hardware,

configuration multi utilisateur, granularité de la configuration, gestion de la sécurité de l’accès aux équipements.

• Dans quelle mesure le protocole est adopté dans le monde. Est-ce un protocole à l’état de « draft » géré par un consortium, y a-t-il des implémentations commerciales de celui-ci ?

• Le protocole est-il compatible avec d’autres afin d’augmenter la portée du management des équipements (exemple tr-069 et OSGI).

• La simplicité du langage de modélisation associé au protocole (XML, SMI, YANG…) car un langage performant mais nécessitant un grand temps d’adaptation n’est peut-être pas la meilleur solution à adopter en terme de facilité de management.

Toutes ces questions permettent de choisir parmi un panel de technologie afin d’adapter le choix à l’environnement devant être géré et surveillé.

23

Chapitre 2 : Surveillance et analyse des réseaux IPv6

2.1 Introduction

Nous allons voir dans ce chapitre comment la transition des réseaux IPv4 vers IPv6 peut s’opérer d’un point de vue gestion et surveillance. L’utilisation d’IPv6 comme protocole de communication sur les réseaux de télécommunication, ne relève aujourd’hui plus que de la théorie. La saturation des adresses IPv4, comme les montre les différents statistiques [40] des différents RIR (Registre Internet Régional) rend nécessaire la prise en compte de cette transition. Des événements comme le WorldIpV6Launch [41] permettent de sensibiliser l’ensemble des acteurs à ce problème. A date de ce mémoire l’adoption d’IPv6 est plutôt faible (0,73% du trafic de l’internet mondial) comme le montre la figure 22 et la figure 23, seule quelques équipementiers, hébergeurs et grands groupes y participent activement. Certaines statistiques nous permettent de suivre l’évolution de ce manque d’adresses disponibles:

• ceux du WorldIpv6Launch [41]  • ceux de Google (voir figure 23 ci-dessous)  • ceux du laboratoire du RIR LACNIC [42] (région Amérique Sud et Caraïbes)  • ceux du site potaroo.net [40] générant des graphiques par RIR dont provient la

figure 22 ci-dessous.  

Figure 22 : disponibilité des pools d'adresse IPv4 par RIR dans le temps [40]  

24

2.2 IPv4 par rapport à IPv6 : quelle différence fondamentale?

L’IETF publie dès 1995 les spécifications principales d’IPv6 avec la RFC 1883 [30] puis en 1998 avec la RFC 2640 [31]. L’évolution du protocole amène notamment  :  

• Un passage d’un codage sur 32bits (2^32) à un codage sur 128bits (2^128) • Une simplification des paquets IPv6 au niveau de l’entête facilitant le routage et

améliorant les performances d’IPv6 par rapport à IPv4 (voir la section suivante) • L’intégration des mécanismes de QoS, multicast et IPSec directement dans la norme

IPv6

2.2.1 Comparaison des en-têtes

Comme mentionné ci-dessus, la norme IPv6 simplifie l’entête des paquets dans un souci de performance et d’efficacité, notamment grâce à la diminution de la bande passante utilisé pour l’entête ainsi que la diminution du temps de traitement. L’article [44] donne un aperçu des changements au niveau des en-têtes avec notamment :

• Le passage d’une entête de 20 octets minimum (mais d’une taille variable avec les options d’entête) à une entête fixe de 40 octets.

Figure 23: évolution de l'adoption d'IPv6 [43]  

25

• Les champs options dans l’entête IPv6 sont situés après l’entête fixe de 40

octets. Le champ « Next Header » (voir figure 24) permet de donner le type de l’entête suivant. L’intérêt de cette technique se trouve lors de la lecture de l’entête IP par le routeur, seul l’entête recherché (par exemple « routing ») sera analysé, il en résulte un gain de performance lors du routage.

• Le calcul des sommes de contrôle (checksum) n’existe plus avec IPv6. Cette fonction de contrôle est reléguée aux couches supérieurs (UDP, TCP…).

Le renommage du champ TTL en Hop limite mais avec la même fonction que dans IPv4

La figure 25 permet de comparer les entêtes de ces deux versions.

.

Figure 25 : Comparaison de l'entête IPv4 et IPv6 [44]

Figure 24: Fonctionnement des entêtes IPv6 [44]  

26

2.2.2 Méthode d’attribution d’adresse sous IPv6

Comme l’explique l’article [45], DHCPv6  possèdent  plusieurs  méthodes  de  configuration  de  l’adresse  :  

• Configuration manuelle, adresse IPv6fixe donnée par l’administrateur du réseau à chaque terminal connecté. Permet de connaitre précisément le pool d’adresses utilisées mais nécessite une configuration au cas par cas longue et fastidieuse.

• Configuration automatique : • Utilisation du protocole NDP (RFC 4862), NDP fait partie de la suite de protocoles

crées avec IPv6. Il se veut remplacent entre autre des protocoles ARP (Address Resolution Protocol) et ICMPv4 (Internet Control Message Protocol). Permet à un terminal d’acquérir une adresse IPv6 par auto configuration grâce à l’écoute de messages RA (Routeur Advertisement) de type ICMPv6 envoyé par un routeur

• Auto configuration avec adresse aléatoire (RFC 4941) [46] , se base sur l’adresse MAC du client. Cette méthode fut d’ailleurs sujette à polémique du faite de l’apparition de l’adresse MAC dans les 128 bits de l’adresse IPv6. Les communications sont alors facilement traçable et un utilisateur n’est alors plus anonyme puisque son adresse MAC se retrouve dans les logs de communication de l’Internet mondial. Des recherches telles que l’article [47] soulignes tous ces ainsi que des méthodes pour s’en prémunir. L’utilisation de l’adresse MAC peut d’ailleurs être désactivée dans la plupart des systèmes Windows et Unix/Linux et ainsi utilisé une adresse générée aléatoirement.

• Par serveur DHCPv6, reprend trait pour trait la méthode d’attribution dynamique de l’adressage IPv4. On trouve ces méthodes implémentées dans de nombreux systèmes d’exploitation, les serveurs DHCP v6 dérives le plus souvent de leurs homologues DHCPv4.

2.3 Technologies pour la transition d’IPv4 à IPv6

Il est également nécessaire de comprendre les technologies mises en place permettant de faire la transition entre les deux protocoles. A l’heure actuelle, des systèmes comme Windows Vista et 7 implémentent de base une connectivité IPv6.Lorsqu’un système supportent nativement IPv6, sur un réseau IPv4, des technologies d’encapsulation des paquets IPv6 dans IPv4 furent mises au point, voici les principales :

• 6to4 : définit par la RFC 3056, protocole permettant l’encapsulation des paquets IPv6 dans la charge utile des paquets IPv4.

Figure 26 : Architecture 6to4

27

De manière générale, 6to4 est actuellement rendu à l’état de protocole « historique », l’IETF travaille actuellement à rendre le protocole obsolète [48]. Les problèmes d’adressage statique et de non compatibilité avec les technologies NAT (Network Address Translation) ont précipités sa chute au profit de Teredo / ISATAP. • Teredo : Permet de palier à la limitation matérielle des équipements ne supportant

pas la gestion de l’encapsulation par le protocole 6to4. Teredo permet d’être utilisé sur un équipement disposant d’une adresse IPv4 publique faisant office de NAT (Network Address Translation) du réseau privée au réseau publique. La connectivité IPv6 se fait alors entre les hôtes de deux réseaux sans l’intervention d’autres équipements. Comme le montre la figure 27, l’encapsulation est directement intégrée sur les terminaux des clients. On notera la présence de « relay TEREDO » permettant de transiter le trafic IPv6 à travers un tunnel IPv4 et un « serveur TEREDO » aidant à la configuration du NAT et facilitant l’initialisation des connexions IPv6toIPv4 à la manière d’un serveur STUN (Simple Traversal of UDP through NAT) pour la VoIP.

Figure 27 : architecture TEREDO [49]

• ISATAP : Norme publié par l’IETF sous la RFC 5214 [50] est une déclinaison de 6to4 appliqué aux réseaux locaux et est compatible avec celui-ci. Il met en œuvre par l’intermédiaire de routeur compatible double pile « dual stack », une gestion automatique de la création de tunnels IPv6 dans un environnement IPv4 (au niveau de chaque domaine donc localement) ayant des terminaux IPv6 isolés. Ce protocole est implémenté comme le protocole de transition par défaut dans les systèmes d’exploitation Windows depuis Windows Vista (2007).

Une étude [51] de 2010 permet d’ailleurs de rentrer plus en détail sur l’implémentation et les performance de TEREDO et ISATAP.

Ces 3 technologies représentent une grande partie du trafic IPv6, mais l’encapsulation rend la surveillance des entêtes des paquets IPv6 difficile. Ceux-ci étant dans la charge utile

28

(payload) des paquets IPv4 et le trafic IPv6 passe alors toutes les barrières de sécurités. Nous discuterons entre autres dans la section suivante des méthodes et technologies à adopter pour surveiller le trafic encapsuler avec 6to4, Teredo ou ISATAP.

2.4 Quid de la surveillance du trafic IPv6 ?

Nous allons dans cette section tenter de compiler les diverses recherches et techniques visant à surveiller le trafic IPv6.

2.4.1 Quelle visibilité lors de l’encapsulation IPv6 dans IPv4 (tunneling)

Les trois mécanismes de transition présentés précédemment ont comme désavantage une perte de contrôle du trafic encapsulé dans la charge utile (payload) des paquets IPv4. Comme expliqué dans les articles [45] et [52], le fait d’encapsuler contourne tous les mécanismes de sécurité et de surveillance mis en place dans l’environnement IPv4. Les équipements en charge de cette inspection (proxy, pare-feu, routeurs…) travaillant à partir des informations d’entête des paquets ne sont alors pas capables de distinguer un flux IPv4 classique d’un flux IPv6 encapsulé dans un flux IPv4. Des mécanismes de type DPI (Deep Paquet Inspection) ou flows (NETFLOW / IPFIX) sont alors nécessaire pour analyser la charge utile (payload) de chaque paquet.

2.4.2 IPv6 et l’adressage temporaire

L’adressage temporaire est une nouvelle caractéristique du protocole IPv6, comme l’explique l’article [45], cela permet à un nœud du réseau de pouvoir générer automatiquement une adresse IPv6 sur 64 bits à des fins de sécurisation des échanges (voir RFC 4941 [46]). Ce même standard défini comment générer et changer aléatoirement ces adresses. Il est évident que ce mode d’adressage des clients d’un réseau, pose de nombreux problèmes quant à la gestion et à la surveillance des flux transitant sur le réseau. A l’heure actuelle, la RCF 4941 [46] est implémenté dans une grande partie des systèmes d’exploitation du commerce : On peut citer :

• La famille des Windows 7,8 et server • Linux • MacOS X • …

Grace à cette RFC, un identifiant de connexion (les 64 derniers bits de l’adresse IPv6) est généré aléatoirement pour chaque connexion. Une fois la transmission terminée, cette adresse passe au statut obsolète. Comme l’explique Microsoft sur sa base de donnée technet [53], voici les 4 étapes utilisé pour la génération du suffixe aléatoire de 64 bits d’une adresse IPv6 : Extraction de la valeur d'historique stockée et ajout de l'identificateur d'interface en fonction de l'adresse EUI-64 de la carte.

29

Calcul du hachage unidirectionnel MD5 (Message Digest-5) à partir du résultat obtenu à l'étape 1. Enregistrement des 64 derniers bits du hachage MD5 issu de l'étape 2 en tant que valeur d'historique qui servira de base au calcul du prochain identificateur d'interface. Extraction des 64 premiers bits du hachage MD5 issu de l'étape 2 et attribution de la valeur zéro au septième bit. Le septième bit correspond au bit U/L qui, lorsqu'il a pour valeur 0, indique un identificateur d'interface géré localement. Le résultat est l'identificateur d'interface.

Un terminal peut donc avoir à un instant T plusieurs adresses IP générés localement (et non pas assigné par un serveur DHCP comme pour IPv4). Rajoutons à cela la disparition du protocole ARP au profit de NDP faisant disparaitre la table de correspondance MAC – Ipv4, il en devient aisé de comprendre que les sources d’informations nécessaires à la surveillance du trafic IPv6 changent comme démontré dans les sections suivantes.

2.4.3 Inspection de paquets et sondes NETFLOW / IPFix pour palier au problème

Les auteurs de l’article [52] traite de l’analyse du trafic Ipv6 encapsulé (IPv6 over IPv4) à des fins de détection des attaques sur le réseaux. Dans leurs démarches, nous nous intéresserons à la partie en amont de la détection d’attaques à savoir la capture du trafic en lui-même. Depuis sa version 9, le constructeur Cisco System, a implémenté dans son protocole d’inspection et de capture de paquets NETFLOW [54] le protocole IPv6. Entre temps, l’IETF ratifia la norme IPFix (IP Flow Information Export) [55] qui est une implémentation ouverte du protocole Netflow de Cisco. L’intérêt de ces deux protocoles, en plus de leurs compatibilités respective, et de permettre la définition de gabarits de capture de données sur chaque équipement implémentant les sondes IPFix / Netflow. La figure 28 décrit le gabarit permettant de recueillir toutes entêtes nécessaires à l’analyse et à la surveillance du trafic IPv6 encapsulé dans du trafic IPv4 avec notamment :

• L’adresse source et destination du tunnel IPv4 • L’adresse source et destination IPv6 • Le champ trafic class incluant le marquage DSCP

30

• Le port source et destination IPv4 dans le cas d’encapsulation « IPv6toIPv4 ».

2.4.4 Vers une méthode d’agrégation de plusieurs source de données pour la

surveillance IPv6 générés aléatoirement

L’article [45] après avoir souligné le problème lié à l’auto génération d’adresse IPv6 de manière aléatoire explique une méthode de corrélation des données pouvant ainsi permettre la surveillance du trafic IPv6. La technique va consister en l’agrégation de plusieurs sources de données d’authentification afin de pouvoir effectuer une corrélation des évènements et identifier les clients IPv6 lors de la communication. Une version « longue » plus complète est d’ailleurs disponible à cette adresse [56].

Figure 29 : Données agrégés pour la surveillance du trafic IPv6 [36]

Figure 28: Gabarit de capture IPFix de paquets IPv6-over-IPv4 [37]

31

Figure 30: Protocoles utilisés pour l'agrégation des données [36]

Les données proviennent de plusieurs couches du modèle OSI :

• Couche L2 : données provenant des logs RADIUS [57] contenant : • Les login utilisateurs • L’adresse MAC du client • Couche L2: données provenant de la table FDB (Fordwarding database) contenant

les informations de routage • N° de port du commutateur et adresse MAC • Couche L3: Cache « router Neighbors » liée aux échanges du protocole NDP

(Neighbord Discovery Protocol) entre le routeur et le client • Correspondance adresse IPv6 et adresse MAC • Couche L3 : Table ARP du routeur utile dans le cas d’un tunnel IPv6-over-IPv4 • Correspondance adresse IPv4 et adresse MAC • Couche 4-5-6-7 : couches applicatives utilisées par le protocole netflow pour capturer

le trafic • Adresses IPv4 et IPv6, UDP / TCP, ports de connexion, protocoles applicatif utilisé

(HTTP, FTP…)

2.4.5 Architecture proposée

Les auteurs de l’article [45] donnent une vue de l’architecture (figure 31) nécessaire dans son ensemble. On peut ainsi distinguer plusieurs briques :

• Le NMS (Network Management System) recueillant les informations (statistiques, incidents, données agrégées...)

• Le « central registration system » contenant les données d’authentification tels que les logs et les données RADIUS des stations clientes, la correspondance adresse IPv6 / adresse MAC.

• Le collecteur Netflow couplé à une base de données regroupe toutes les données provenant des sondes Netflow des équipements (routeurs et commutateurs). Il est par la même occasion utilisé pour stocker, en base de données également, les enregistrements des tables de routage.

32

Figure 31 : Architecture de l'agrégation des données proposées dans l'article [36]

2.4.6 Mise en pratique

Il est intéressant, toujours dans l’article [45], de noter que les auteurs se sont attachés à donner des statistiques sur la mise en pratique de leurs recherches. Ces données statistiques peuvent donc être réutilisées par d’autres personnes afin de définir l’architecture adéquate par rapport à des besoins différents. On peut donc extraire de l’article plusieurs points intéressants :

• L’université de leurs recherchent a pour effectif 2.500 employés et 23.000 étudiants, avec des crêtes d’utilisations à 6.000 connexions simultanés via un lien Internet à 100Mbps.

• L’agrégation journalière pour la surveillance du trafic s’élève à 9 Giga octets de données compressées (18 Giga octets non compressés).

• Le polling des données intervient toutes les 15 minutes, donnant quelques 600.000 entrées en base chaque semaine.

• Les collecteurs Netflow et bases de données classiques comme MySQL montrent leurs limites dans une architecture de cette taille.

33

• Les protocoles utilisés pour transmettre les données de surveillance (Netflow,SNMP…) utilisent UDP. Une attaque de type DDOS ou la saturation d’un lien peut engendrée une perte de paquets et donc d’informations.

• La transition vers IPv6 effectué relève une proportion plus importante de trafic IPv6 natif par rapport aux statistiques (voir figure 32 ci-dessous)

Figure 32 : pourcentage par type de trafic IPv6 [36]

2.4.7 Conclusion

La méthode de surveillance proposée ici n’est pas parfait mais il est nécessaire de juger les pour et les contre :

• Points positifs : o Permet une très grande finesse et personnalisation de la surveillance. o La montée en charge peut facilement s’adapter en fonction de la taille

et de la charge de trafic à surveiller. • Point négatifs :

o Architecture complexe dont l’installation nécessite la maitrise notamment de SNMP et de NETFLOW.

o Une grande capacité de stockage est nécessaire en se basant sur les statistiques énoncées par les chercheurs.

2.4.8 Utilisation de l’extension saut après saut (hop-by-hop)

Avec IPv6, toute une série d’extensions de l’entête provenant de la RFC 2460 [58] furent définis. L’article [59] décrit une méthode innovante appelée « Surveillance intrinsèque (de l’intérieur) ». La spécificité de cette méthode se trouve être dans l’utilisation de l’extension « hop-by-hop » [58] de l’entête IPv6.

2.4.9 Qu’est-ce que l’extension Hop-by-hop

L’extension « hop-by-hop » si utilisé dans l’entête IPv6 doit être immédiatement à la suite de l’entête IPv6. En effet, cette entête définit par le code 0 du champ « Next Header »de l’entête IPv6 doit être examiné par chaque équipement (ou node) où passe le paquet. Voici un extrait de la RFC 2460 [58] : Comme l’explique précisément ci-dessous ce passage de la RFC 2460, l’option permet de transporter tout au long du trajet d’un paquet des informations inscrites par chaque nœud/équipement. Les auteurs de l’article [59] ont ainsi imaginé une solution intelligente de surveillance des performance du réseaux par l’utilisation de cette extension. Nous allons voir

34

dans le prochain paragraphe comment des informations de performance du réseau peuvent être rajouté à l’entête IPv6 lors du passage du paquet dans un routeur (donc à chaque nœud). Afin de justifier leur méthode, les chercheurs dans l’article [59] donne un aperçu du comportement de la commande traceroute dans un environnement distribué pouvant comporter de la répartition de charge. Pour rappel, que ce soit en environnement IPv4 ou IPv6, la commande traceroute permet de connaitre le chemin emprunté grâce à l’envoi de paquets ICMP (Internet Control Message Protocol) de type ECHO Request tout en incrémentant l’option TimeToLive (IPv4) / Hope limite (IPv6) de 1 à chaque passage d’un routeur.

Figure 33 : traceroute en environnement normal et distribué [39]

Ce schéma permet de visualiser comment les informations remontées par la commande traceroute peuvent ainsi être faussées lors de l’utilisation des mécanismes de répartition de charge. En effet, le fonctionnement interne de traceroute n’exige pas de connaitre le chemin complet et celui-ci peut très bien, en fonction de la charge de trafic sur un lien, être redirigé comme le montre le second schéma de la figure 33. La surveillance des liens ainsi que la remonté des informations de la commande traceroute (comme les latences entre chaque nœud) deviennent alors aléatoires.

35

Figure 34 : fonctionnement d'un traceroute réseaux-linux.fr

Comme le montre la figure 35, la technique proposé dans l’article se révèle mieux optimisé et moins consommatrice en bande passante. Aucun aller-retour de paquet n’est nécessaire dans l’analyse du réseau, contrairement au traceroute (figure 34). L’administrateur du réseau peut alors contrôler nœud par nœud le trajet du paquet IPv6 de surveillance du réseau.

Figure 35 : traitement de l'extension "hop-by-hop" [59]

2.4.10 Performances et surcharge de trafic

La lecture de l’article [59] permet de conclure les choses suivantes en termes de performance des deux méthodes :

• Sur un équipement de routeur équipé d’un noyau linux 2.6.28, le total des données nécessaires à l’envoi d’un traceroute sur un réseau de N équipements est N*612 octets.

• En utilisant le champ « hop-by-hop », un seul paquet transit sur les nœuds, seule sa taille augmente dans un rapport de 20 N + 70 octets.

• Sur un réseau comportant au minimum 6 nœuds, la réduction de la charge de trafic est de l’ordre de 95% par rapport au traceroute traditionnel.

• Comme le montre la figure 36, un traceroute génère de manière exponentielle une importante montée en charge de trafic lors de l’augmentation du nombre de nœud.

36

Figure 36: Surcharge du trafic en fonction du nombre de nœuds [39]

• Le temps de traitement sur chaque nœud est plus important dans le cas d’un traceroute comme le prouve la figure 37. Les chercheurs sont parvenus, dans le cas d’un réseau équipé de 16 nœuds, à diminuer le temps de traitement de 81,5%.

Figure 37 : Temps de traitement des deux méthodes

2.4.11 Conclusion sur la méthode

Les chercheurs livrent ici une méthode performante, relativement simple à mettre en œuvre sur un réseau IPv6 et permettant une réduction notable du trafic de surveillance. Seule véritable ombre au tableau, les tests réalisés ont été effectués sur des routeurs logiciels (des serveurs) ayant un noyau linux facilement modifiables et paramétrables. Il est nécessaire pour implémenter cette méthode que les constructeurs d’équipements réseaux mettent à jour les produits afin qu’ils puissent réaliser le marquage et la gestion de l’entête « hop-by-hop ». Une fois ce problème passé, on peut affirmer que la méthode proposé est ingénieuse et sa mise en application améliorerait grandement la surveillance des réseaux IPv6 tout en ayant le luxe de diminuer le trafic lié à la gestion du réseau.

2.5 Conclusion du chapitre

La surveillance des réseaux IPv6 n’en est encore qu’à ses balbutiements, la faible percer de cette technologie dans les entreprises au profit de la norme IPV4 en est peut-être la raison. Il faudra encore quelques années pour voir apparaitre une méthode performante et plus simple que celles proposées actuellement. Les recherches actuelles, dont une partie est synthétisé dans ce chapitre nécessitent encore de murir.

37

Chapitre 3 : Les protocoles « FLOWS » pour améliorer la visibilité dans les réseaux.

3.1 Introduction

Avec l’explosion de la taille des réseaux, il est nécessaire à l’heure actuelle de disposer d’un protocole de management capable de caractériser, stocker et analyser le trafic d’un réseau. Le terme flows est pour l’instant utiliser dans cette introduction, car nous allons voir plus loin que la famille des protocoles de surveillance des flux (ou flows ) est relativement vaste et est un mélange de protocoles à la fois propriétaires et ouverts. Nous allons dans ce chapitre effectuer un état de l’art sur certaines recherchent gravitant autour des protocoles flows . Mais avant cela, il est nécessaire d’expliquer les fondements ainsi que la terminologie d’un environnement comme celui-ci.

3.2 Principes de fonctionnement

La présentation suivante intègre certaines informations NETFLOW /IPFIX librement inspirées d’un rapport [60] effectué par Yassir Allaoui, Lavoisier Mouoyebe et moi-même. Contrairement aux autres méthodes de supervision comme SNMP et qui sont utilisées principalement pour la surveillance des équipements ainsi que pour la visualisation basique de l’utilisation du réseau, la méthode Netflow permet la caractérisation du trafic IP et apportent une solution à plusieurs problèmes comme :

• Analyser les nouvelles applications et leur impact sur le réseau. • Réduction des pics de trafic. • Détection du trafic non autorisé. • Sécurité et détection des anomalies. • Validation des paramètres de QoS.

Les outils d’analyse du flux de trafic réseau sont généralement constitués de deux éléments :

• le premier est le générateur de flux (ou sonde) soit un commutateur, un routeur ou un terminal équipé d’analyseur de flux de trafic réseau. Chaque équipement transmet un flux de données constant qui contient des informations comme l’adresse IP source et destination, le protocole et l’interface (les flows).

• Le second élément est le collecteur de flux (ou flows) qui reçoit ces données d’un

ou plusieurs générateurs de flux. Le collecteur accumule et emmagasine l’information afin de publier des rapports et offrir une analyse aux administrateurs de réseaux.

3.2.1 Les sondes

Dans la technologie de type flows les équipements IP sont équipés d’une sonde (ou Probe) qui capture le trafic qui passe à travers le routeur lors qu’elle est activée. Les paquets collectés sont regroupés sous forme de Flows, une notion fondamentale. Par exemple, un

38

flow TCP est constitué des paquets qui forment une connexion particulière. Par contre, un flow UDP est formé par les paquets qui ont la même adresse source, destination et port. Cette fonctionnalité est généralement réalisée par un circuit de type ASIC (Application Spécific Integrated Circuit) intégré à l’équipement de niveau 3 (IP). D’une manière générale, un flow est considéré comme complet dans 3 cas :

• la connexion a été inactive pendant un certain temps (par défaut 15 secs), le flow se termine donc.

• Elle a été active trop longtemps (par défaut 30 min), le flow se termine également. • S'il s'agit d'un flux TCP et que les flags FIN ou RST ont été détectés, parle routeur.

Grâce aux attributs relatifs à chaque paquet, la sonde regroupe les paquets qui ont les mêmes attributs dans des Flow IP.

Figure 38: la sonde Netflow [54]

Les attributs des paquets IP utilisés dans le Netflow sont :

• L’adresse IP source du paquet. • L’adresse IP de destination du paquet. • Le numéro du port du paquet source. • Le numéro du port du paquet de destinations. • Le type de protocole de niveau 3. • La classe de service du paquet. • L’interface logique du routeur ou du commutateur par lequel le paquet

traverse. • Le nombre de paquets : donne une idée sur la quantité du trafic. • Le Timestamp du flow IP : pour connaître la durée du trafic.

39

3.2.2 Collecteur/analyseur

D’une manière périodique, quand un flow est complété, il est transféré par le routeur vers un collecteur. Le collecteur a généralement pour fonction de sauvegarde des données et d’effectuer un filtrage de donné. Il permet aussi de supprimer les Flow expirés. Pour cette raison la fonction du collecteur doit être implémentée sur des machines puissantes avec une grande capacité de stockage. Les données sauvegardées dans le collecteur vont nous permettre d’effectuer des analyses et diagnostics de performance ainsi que de sécurité au niveau de la couche IP du réseau.

Figure 39 : Le collecteur/analyseur [54] Le collecteur regroupe les paquets selon les mêmes caractéristiques dans une base de données. L’information peut être consultée directement sur l’équipement ou être exportée sur un serveur. À la différence de SNMP où un serveur doit extraire l’information de l’équipement.

40

La figure 40 représente l’architecture générale de surveillance d’un réseau à l’aide des flows :

Figure 40: Architecture Netflow [54] Comme on peut le constater, on a la possibilité d’avoir accès aux données collectées

par des sites distants. De cette manière, on aura une vue globale sur le trafic dans le réseau et le comportement de ce dernier vis-à-vis les différents types de services.

3.2.3 Bref historique de cette technologie

Crée par Cisco dans les années 1990 sous le nom de Netflow pour ces routeurs et ses commutateurs, la technologie se généralise depuis les années 2000 sur toute une gamme d’équipements de divers constructeurs. L’évolution des équipements fut accompagnée par des révisions ainsi que des évolutions de la technologie dont voici un bref résumé, librement interprété de l’article [61] :

Version Description

v1 1er implementation, maintenant obsolete.

v2 Version interne à Cisco, jamais publiée.

v3 Version interne à Cisco, jamais publiée.

v4 Version interne à Cisco, jamais publiée.

v5 À date de 2009, la version la plus courante utilisée comme standard de compatibilité entre les constructeurs

41

d’équipements de télécommunication pour la capture de flow IPv4.

v6 N’est plus supporté par Cisco.

v7 Similaire à la version 5 mais comporte un champ « router field » compatible avec les produits Cisco Catalyst.

v8 Amélioration de l’agrégation des flow présents dans la version 5.

v9 Rajout de gabarits, évolution majeure de la version 5. Version compatible avec IPv6 et MPLS entre autres. Est la base de la définition du standard IPFIX de l’IETF.

v10 Connu également sous le nom d’IPFIX, l’IETF créa un standard basé sur la version 9 du protocole NetFlow avec l’ajout de quelques extensions.

Figure 41 : Historique de la norme Netflow / IPFIX

3.2.4 Équivalences chez d’autres constructeurs

Comme expliqué dans la section précédente, NETFLOW de Cisco donna naissance à IPFIX ainsi qu’à plusieurs implémentations d’autres constructeurs d’équipements de télécommunication, on peut citer :

• Jflow de Juniper Networks • NetStream de 3Com/HP • NetStream de Huawei Technologies • Cflowd d’Alcatel-Lucent • Rflow de Ericsson • AppFlow de Citrix • sFlow de Allied Telesis

3.2.5 Le protocole Netflow :

Les paquets envoyés par Netflow au collecteur Netflow peuvent prendre différents formats appelés « export version ». La différence entre les versions se trouve au niveau des champs ajoutés au flux exporté par la sonde. On peut citer la version 5 comme la version la plus implémentée sur les routeurs Cisco et la version 9 comme la version qui support IPV6, le MPLS et le multicast. Une version 10 normée IPFIX (IP Flow Information eXchange) viens

42

d’être implémenté par quelques constructeurs d’équipements, cette version est basée sur les travaux de l’IETF [55].

3.2.6 La trame Netflow V9:

Nous étudierons donc ici plus en détail la version 9, car elle introduit la notion de gabarit et elle supporte le multicast, MPLS et IPv6.

Une trame Netflow contient ainsi une entête Templates FlowSets et une succession

de Data FlowSets et de comme le montre la figure 42 :

Figure 42 : trame NETFLOW comprenant un gabarit et des flows de données

L'entête contient les données suivantes :

• Version : la version de Netflow • Count : Nombre de Flowset • System Uptime : Depuis combien de temps le système est démarré • UNIX Seconds : L'heure actuelle, en notation UNIX x • Sequence Number : Un numéro de séquence, incrémenté à chaque trame

envoyée. • Source ID : Champs de 32 bits, utilisé pour garantir la pérennité des données.

Une trame est donc constituée d'une suite de flowset : les templates flowset représentent l'organisation des données, alors que les data flowset contiennent les données elles-mêmes. Chaque data flowset est ainsi associé à un template flowset, que le collecteur aura dû recevoir au préalable comme la montre la figure 43.

43

Figure 43: Organisation du template FlowSet renater.fr

3.3 Vers l’optimisation de la gestion et de l’acquisition des « flows ».

Les recherches en matière d’articles scientifiques ayant pour étude les technologies de captures de flux de type « flows » mettent en avant l’aspect optimisation et traitement de ces flux. En effet, la technologie mise au point par Cisco il y a maintenant plus de 20ans est arrivée à maturation avec la version Netflow 9 / IPFIX et permet de surveiller le trafic de cœur de réseaux (backbone) de manière efficace. Mais quand est-il de l’utilisation des routeurs et de la charge de trafic dans des nœuds ?

3.3.1 Une technologie efficace, mais gourmande en ressources

Il est intéressant de noter qu’une telle technologie a d’énormes avantages en termes de surveillance des performances, mais également des inconvénients. Cisco le précise d’ailleurs dans une série de whites papers [62] [63] , ou il est dit, je cite, en parlant de la version 9 / IPFIX :

Cisco livre également un document de référence [63] de 25 pages sur les performances de la technologie netflow sur ses routeurs. Le but ici ne sera pas de faire un état des lieux des performances sur chaque gamme de routeurs, puisque le document ne s’adresse qu’aux possesseurs d’équipements Cisco. Il va permettre de mettre en avant le paramètre performance et utilisation des ressources comme expliqué plus haut. Voici les paramètres à souligner dans cette étude de performance : • Celle-ci date de 2007, l’évolution des équipements fait que leurs puissances ont

augmenté entre temps, les performances et le temps de traitement s’en trouvent améliorés.

Version 9 slightly decreases overall performance, because generating and maintaining valid template flowsets requires additional processing. [60]

44

• L’étude prend en charge des équipements des séries 1841 (entrée de gamme) à la série 12000(cœur de réseaux / backbones) de Cisco elle n’est donc pas représentative des performances des flows chez les autres fabricants d’équipement de télécommunication.

• Cisco étant le créateur ainsi que le leader dans ce domaine, cette étude peut légitimement être utilisée comme référence.

• Seize cas de test, allant du routeur sans Netflow, en passant par l’utilisation de la version 5 à la version 9 surveillant les échanges BGP (Border Gateway Protocol) entre AS (autonomous System), la liste se veut exhaustive et couvre un grand nombre de scénarios réels.

• Une génération de trafic IP allant de 2,000 trames ayant un débit de 274 PPS (paquets par seconde) à 65,000 trames avec un débit de 8903 PPS. L’utilisation de paquets constants de 64 octets permet, selon Cisco, de stresser au maximum les équipements.

Voici une sélection des résultats les plus intéressants de l’étude, des conclusions seront données à la fin de cette section. Nous n’allons pas commenter tous les cas d’utilisation de Netflow dans ce chapitre, mais il est nécessaire d’en connaitre un minimum afin de comprendre l’impact sur les ressources de l’utilisation faite du protocole. En voici les principaux :

• Baseline : routeur n’utilisant pas la technologie NETFLOW • NF-LOAD : Activation du protocole NETFLOW sur le routeur • NF-ENABLE : protocole NETFLOW activé et ainsi que la surveillance du trafic.

Aucun export des flows à ce stade. • NF-NDE : protocole NETFLOW 5 activé et export des flows vers 1 collecteur • NF-NDE-2 : protocole NETFLOW 5 activé et export des flows vers 2 collecteurs • V9-NDE-1 : protocole NETFLOW 9 activé et export des flows vers 1 collecteur. • FNF-* : l’acronyme FNF pour Flexible Netflow, mise en place d’un

échantillonnage des paquets permettant de diminuer les ressources nécessaires (voir section suivante pour la technologie FNF).

• AS : Acronyme d’Autonomous System, performances lors de l’utilisation de NETFLOW pour surveiller les AS et les échanges BPG entre routeurs.

La figure 44 (page suivante) permet de comparer l’utilisation des ressources processeur (CPU) en pourcentage d’utilisation sur un Cisco 1841 (entrée de gamme de la marque).

45

Figure 44 : Utilisation du CPU sur un Cisco 1841 (entrée de gamme) [42]

La figure 45 quant à elle, montre l’utilisation des ressources processeur sur un Cisco 12000, équipement haut de gamme utilisé par les fournisseurs d’accès Internet dans leurs backbones.

Figure 45 : Utilisation CPU sur un Cisco 12000 (haut de gamme) [42]

46

La figure 46 résume l’utilisation des ressources du processeur en fonction de nombre de flows générés par l’équipement, couvrant de l’entrée de gamme (Cisco 2600) au haut de gamme (Cisco 12000).

Figure 46: Résumé du pourcentage de l'augmentation de l'utilisation du CPU lors de l'activation de netflow [42]

47

La figure 47 de cette page met en lumière le non-écart de performance lors du passage entre NETFLOW V5 et V9.

Quant à la figure 48, celle-ci souligne l’écart de performance entre NetFLOW et Flexible Netflow (FNF).

Figure 47: Comparaison d'utilisation des ressources CPU entre Netflow V5 et V9

Figure 48: Comparaison d'utilisation des ressources CPU entre le Netflow (TNF) et Flexible Netflow (FNF) sur un Cisco 1841 (entrée de gamme)

48

3.3.2 Méthode d’échantillonnage des flux Flexbile-Netflow

Figure 49 : diminutions des ressources CPU grâce à l'échantillonnage (Flexible Netflow

Cisco)

Afin de diminuer les ressources nécessaires à la capture et les créations des flows, les constructeurs, dont Cisco et son Flexible Netflow (NFN), implémentent des mécanismes d’échantillonnages dont le but est de délester le CPU d’une partie du traitement des paquets et de la création des flows. Dans le cas de Cisco, celui-ci préconise un taux de 1/100 (soit un paquet exporté dans le flow pour 100 paquets analysés. On notera que l’utilisation de FNF permettant de faire chuter drastiquement la consommation CPU.

3.3.3 Conclusion sur les performances

Cette sélection de benchmarks de l’étude permet d’en déduire plusieurs points importants et permettant ainsi de mieux comprendre l’enjeu des recherches décrites plus tard dans ce chapitre du mémoire. Notamment le faite que :

L’utilisation de netflow (toutes versions confondues) sur des routeurs d’entrée de gamme est peu consommateur en ressource en dessous des 45000 flows, à partir de cette valeur, la consommation CPU devient dangereusement importante (entre 30 et 60%) sur les équipements (figure 44 et 46) Les équipements haut de gamme ne subissent que de très peu la montée en charge du trafic, l’utilisation du CPU ne varie qu’entre 7 et 15%. 5Figure 45 et 46°

Figure 50: comparaison des ressources CPU entre Netflow et Flexible Netflow

49

Le passage de Netflow V5 à Netflow V9 / IPFIX ne demande pas plus de ressources sur les équipements (figure 47). L’utilisation de Flexible Netflow (FNF) sur les équipements d’entrée de gamme de la marque permet de réduire la consommation CPU d’environ 10% pour des trafics importants (dès 45000 flows). Comme expliqué dans l’étude, l’utilisation sur des équipements plus puissants (milieu et haut de gamme) n’apporte pas de réduction d’utilisation CPU (figure 49).

3.3.4 Parallélisassions du traitement des flows

Selon les auteurs de l’article [64], l’amélioration des performances du protocole Netflow doit passer par l’amélioration de la gestion des flows. L’article [64] donne une série de mesure au niveau de l’agrégation des données, du traitement et de l’analyse statistique des paquets permettant l’amélioration des performances et une diminution de la perte de flows. Leur méthode permet une unification de la gestion des données et de leur réception, nous allons par la suite décrire leurs théories ainsi que les gains apportés.

3.3.5 Parallélisassions et décomposition des flux

La figure 51 tirée de l’article [64] résume de manière simple leur approche dans le traitement des flux. Afin d’optimiser l’arrivée de paquets du tout en évitant le plus de pertes propres aux transmissions UDP, les chercheurs, par la voix de la parallélisassions, optimise le traitement des collecteurs de flows.

Figure 51 : Traitement parallèle des flows.

L’architecture proposée par les chercheurs se décompose comme suit :

o Division du collecteur Netflow en plusieurs tranches parallélisées. Le flow arrivant depuis les équipements de manière continue, il est ensuite redirigé vers des buffers. Le traitement s’effectue par flux temporel de 5minutes, une fois qu’une tache parallélisée a reçu les 5minutes de flows, une source de données est créée.

50

o Chaque « sous- flow » comportant 5 minutes d’enregistrement est ensuite traité par des fonctions mathématiques de décodage. La vérification des timestamp des flows permet de vérifier la continuité des flux, une fusion des paquets peut être opérée lorsque plusieurs quintuples ayant des informations similaires au niveau des entêtes des flows arrivent. La fusion permet de délester les buffers d’entrée.

o Les « sous-flows » sont enregistrés en base, un processus maintient une table de

hachage comportant les « hash » de chaque « sous-flow » afin de pouvoir traiter de manière performante l’arrivée en base , de manière continue, les « sous-flows » de 5minutes qui seront ensuite réassemblés lors de l’analyse statistique.

3.3.6 Résultats et conclusion

Les auteurs de l’article [64], ont réussi à appliquer les concepts apparus en informatique depuis quelques années avec la généralisation des processeurs multi cœurs et la programmation multitâches. Ils ont ainsi optimisé le traitement des flows et ont créé un collecteur / analyseur performant. La figure 52 ci-dessous compare la perte des paquets UDP Netflows arrivant au collecteur avant et après l’optimisation effectuée. La performance d’un collecteur / analyseur Netflow est intrinsèquement liée au nombre de paquet que celui-ci peut capturer (et donc à leurs pertes). La figure 52 permet de démontrer la performance de leur architecture puisque le taux de paquet est nul.

Figure 52 : Comparaison des performances avant et après le traitement parallèle des flows

Figure 53 : Rapport entre la perte de paquet et la taille du tampon UDP

51

La figure 53 quant à elle, donne le rapport entre le nombre de paquets perdus et la taille du buffer UDP en entrée du collecteur. La logique est respectée puisque l’augmentation du tampon sur les piques de trafic permet de diminuer la perte de paquets en entrée. Avec ses améliorations, les chercheurs affirment pouvoir surveiller un lien de cœur de réseaux à 20GB/s avec un simple ordinateur ayant un processeur double-cœur, le traitement des flows ne demandant qu’une surcharge de 38Mo en mémoire vive.

3.4 Augmenter la visibilité dans les centres de données grâce à Netflow-lite

Comme expliqué dans les sections précédentes, la norme Netflow / IPFIX est éprouvée en termes d’efficacité, seul ombre les performances nécessaires à son implantation. Les auteurs de l’article [65] ont effectué une recherche sur l’implémentation de la technologie Netflow en environnement nécessitant une haute disponibilité en terme de ressource, les centres de données (data center). Par définition, un data center supporte une charge de trafic de données supérieur à la normale, puisque stockant et permettant l’accès à ceux-ci. Il n’est pas rare, comme l’explique l’article, d’avoir des transits de données excédé les 100Gb/s (voir Tb/s) sur certains équipements de commutation (switchs). Hors une sonde aura pour conséquence une surcharge en termes d’utilisation processeur ainsi que l’augmentation du trafic dû à la duplication de celui -ci en flows à destination du collecteur. Netflow ne peut donc être considéré comme une technologie « magique » utilisable dans tous les scénarios de surveillance, elle nécessite une adaptation à son environnement. C’est cette adaptation en environnement de type data center que les chercheurs de l’article [65] on tentés d’appliquer. Netflow-Lite reprend les principes de Flexible-netflow, pour rappel, une description de la technologie Flexible-Netflow est disponible deux sections auparavant. Netflow-Lite est porté par trois acteurs :

• Cisco, par l’intermédiaire de sa gamme de commutateurs Catalyst 4000 • Le projet open source Ntop et son créateur Luca Deri [66] • Plixer [67], spécialisé dans les collecteurs Netflow à haute performance

comme Scrutinizer [68]

Une série d’article et de présentations [65] [69] ont ainsi été émis depuis fin 2011 avec l’apparition de Netflow-Lite. Comme le montre la figure 54 ci-dessous, la différence entre NetFlow , Flexible Netflow et Netflow-lite ne saute pas forcement aux yeux. Il faut en fait retenir que la technologie Netflow-Lite dérive de Flexible-Netflow qui dérive elle-même de Netflow. Comme le montre la figure 54 et 55, Netflow lite est allégé à son maximum afin de pouvoir être utilisé sur des commutateurs (les Catalyst 4500), grâce notamment à :

• L’utilisation d’un échantillonnage des paquets • La suppression des « flows caches », les flows sont ainsi directement envoyés au

collecteur (figure 54). Le terme paquet est d’ailleurs utilisé dans la figure 55 pour différencier Netflow de Netflow-lite signe de la simplification de cette technologie.

52

• L’utilisation de FGPA en remplacement des contrôleurs ASIC plus couteux (figure 54).

• L’obligation de passer par un collecteur Netflow-lite (aggregator) rendant le flux compatible avec un collecteur Netflow classique (figure 55).

• Des taux d’échantillonnages allant d’un ratio 1 :1 à 1 :32 du trafic (figure 55)

Figure 55 : Différence entre Netflow et Netflow-lite [69]

Figure 54: Différences entre Flexible Netflow et Netflow-lite [69]

53

3.4.1 L’obligation d’un collecteur Netflow-Lite vers Netflow/IPFIX : Nprobe

La solution proposée dans l’article [65] nécessite comme expliqué précédemment un convertisseur (aggregator). Nprobe est une solution open source développée par Luca Deri, lui-même coauteur de l’article. Nprobe est disponible à l’adresse [66] et permet en autre :

• d’analyser les données de type Nflow-Lite pour en extraire en autre, l’IP source, l’IP de destination, les ports TCP/UDP, la longueur des paquets, etc.

• de construire un cache comportant les flows provenant des sondes Netflow-lite • de faire une corrélation entre le taux d’échantillonnage utilisé et les statistiques. • Convertir les flows au format Netflow-lite vers le standard IPFIX / Netflow V5-

V9 • De conserver en cache (ou en base de données) une partie des statistiques de

trafic afin d’optimiser la corrélation des nouveaux flows arrivant en cache.

Figure 56 : Intégration du collecteur Netflow-Lite [65]

La figure 56, celle-ci permet de mieux cerner l’intégration de la technologie Netflow-lite et de ces briques, avec notamment :

• Les commutateurs compatibles Netflow-Lite effectuant un échantillonnage du trafic du centre de données

• Le cœur de réseau faisant transiter les flows • Le collecteur Netflow-Lite (nProbe) faisant la conversion des flows • Le collecteur Netflow permettant la surveillance et l’analyse du trafic.

1

3

2

4

54

Quant à la figure 57, elle présente ainsi les flux et leurs directions.

Figure 57 : Convertisseur NProbe Netflow-lite vers Netflow [65]

3.4.2 Optimisations : Round-Robin et PF_RING

Il est a noté, comme le souligne l’article [65] que les commutateurs Cisco compatibles avec Netflow-lite disposent d’une fonctionnalité de distribution des flows sur plusieurs ports UDP du collecteur de type Round-Robin (figure 58). Cela permet ainsi d’avoir une répartition de charges (load balancing) homogène lors de l’export de plusieurs milliers voir millions de flows et ainsi améliorer les performances du collecteur.

Figure 58 : Distribution Roud-Robin des flows sur plusieurs ports UDP [65] La figure 59 toujours issue de l’article [65], présente l’architecture interne du module PF-RING. PF_RING est un noyau (kernel) développé par les chercheurs (en particulier Luca Déri par le biais de sa fondation Ntop). PF_RING agit comme un filtre de réception des flows UDP, il augmente les performances de réception en stockant en zone noyau les informations sur les gabarits netflows / IPFIX en cours de réception. Une répartition de charge (load balancing) est effectuée par l’intermédiaire de la fonctionnalité RSS (Resource

55

Side Scaling) implémentée dans les cartes réseau Intel 82599 (cartes réseaux 10Gb/s haut de gamme pour serveurs).

Figure 59 : PF_Ring optimisation matérielle Intel 82599 et multi-cœurs Le noyau PF_RING peut ainsi gérer séparément plusieurs tampons de réceptions de flows (RX Queue) pour ensuite les transmettre au convertisseur nProbe par connexion socket.

3.4.3 Résultats et conclusions

L’architecture de test comme apparente dans la figure 60, comporte les éléments suivants : • Un générateur de trafic supportant la génération de 48 liens de 1 Gb/s

connectés au commutateur • Un commutateur Cisco 4948E compatible avec la technologie Netflow Lite • Un serveur Xeon 8 cœurs sous une distribution Linux 64bits avec nProbe • Un lien 10Gb/s reliant le commutateur au connecteur • Le collecteur Netflow /IPFIX Scrutinizer.

56

Figure 60 : Architecture de test de la sonde nProbe avec Netflow-Lite L’article présenté dans ce chapitre est clairement destiné à des applications commerciales. La technologie présentée dans ce chapitre dispose d’un avantage par rapport au chapitre précédent (« parallélisations du traitement des flows », c’est d’être disponible sur le marché. Comme expliqué dans la conclusion, les recherchent sur l’amélioration des performances du combo PF-RING / nProbe sont toujours en cours, mais paraissent prometteuses. Il est intéressant de démontrer par cet article [65] comment nFlow-Lite peut s’immiscer dans des environnements sensibles comme les centres de données grâce aux avantages suivants :

• Le portage de la technologie des flows des environnements routés vers les environnements commutés (switchs)

• Une gestion « port par port » de l’échantillonnage des flows par commutateur • Une gestion affinée de la ressource utilisée sur les commutateurs • Une compatibilité avec les collecteurs Netflow V5/V9 et IPFIX en passant par un

convertisseur En ce qui concerne les inconvénients, on peut citer le faite que :

• Netflow-Lite est une technologie récente, supportée seulement par quelques modèles d’un seul équipementier (Cisco).

• Le convertisseur nProbe et le noyau PF_RING sont toujours à l’état de développement, le site nTop [66] est également très pauvre en documentation.

• L’utilisation de Netflow-Lite augmente la complexité de l’architecture réseaux et de la gestion des flows de différents types (IPFIX, Netflow V9, Netflow V5…, Netflow-lite)

57

3.5 VoIP et surveillance des communications : vers la détection d’attaques grâce aux flows

3.5.1 La VoIP, un marché de plus en plus important

Depuis maintenant les années 2000, la VoIP (Voice Over IP) a su s’implanter dans la vie de tous jours. Que ce soit par l’intermédiaire de Softphone comme Skype, ou bien par des fournisseurs d’accès internet proposant des abonnements VoIP, de plus en plus d’utilisateurs basculent, sans forcément le savoir, vers la VoIP. Plusieurs pays sont en tête de file dans l’adoption de cette technologie, on peut citer ; la France, la Corée du Sud, les États-Unis, le Japon, etc. Les possibilités en termes d’économie, de couts des équipements et de mutualisation des communications en font une technologie de premier plan. Voici quelques chiffres montrant l’évolution du marché provenant du site slilicon.fr [70] :

• les services de VoIP auraient connu, en 2010, un taux de croissance à deux chiffres : +12,5% par rapport à l’année précédente, relève ITespresso.fr.

• En mars dernier aux États-Unis, la Commission Fédérale des Communications (FCC) avait déjà laissé entrevoir le développement des solutions de voix sur IP, leur taux d’utilisation a bondi de 21% sur le dernier trimestre 2010. Dans le même temps, les lignes téléphoniques traditionnelles sont en recul de 8%.

• Skype compte aujourd’hui 150 millions d’utilisateurs réguliers. Cependant, ils ne sont que 9 millions à s’orienter vers les services payants.

Il est indiscutable que la VoIP replacera à terme les technologies de type PSTN (Public Switched Telephone Network). Des technologies doivent être mises en place pour surveiller ce nouveau trafic, c’est ce que nous allons voir dans les chapitres suivant. Comme et pourquoi surveiller le trafic VoIP.

3.5.2 SIP et RTP : deux protocoles sensibles aux attaques

Les services basés sur SIP (Session Initation Protocol) et RTP (Real Time Protocol) devenus populaires, l’IEE rendu publique une étude [71] sur les vulnérabilités du protocole SIP. Cet article met en lumière une série de faille possiblement exploitable dans un environnement SIP/RTP.

58

SIP est un protocole de signalisation « plein-texte » travaillant sur IP /UDP, il n’inclut par défaut aucun mécanisme de cryptage et d’authentification. Le différent entête utilisé pour la communication entre agents se trouve en clair (voir figure 61). La plupart des fournisseurs actuels de service VoIP ne fournissent qu’une authentification basique, le plus souvent basée sur un nom d’utilisateur et un mot de passe. Très peu proposent des services de sécurisation des échangent pouvant être basé sur TLS (Transport Sécurity Layer) ou SRTP (Secure Real Time Protocol) du faite de l’augmentation non négligeable des ressources nécessaires. L’utilisation des clés d’authentification MD5 lors d’une authentification par proxy SIP ne permet guère d’améliorer la sécurité. Rajoutons à cela le faite que la VoIP emprunte les mêmes canaux de communication que l’Internet mondial, et nous avons ici un protocole des plus vulnérables.

Les articles [72] et [73] prennent en compte les lacunes importantes du protocole SIP et tentent d’apporter une méthodologie dans l’implémentation d’une logique de surveillance des échanges SIP et RTP par le bai de la technologie Netflow V9 / IPFIX.

3.5.3 VoIP et flows : que doit-on surveiller et comment ?

Les technologies de type « flows » de par leur fonctionnement ouvert à base de gabarit (template) permettent de surveiller n’importe quel trafic se basant sur IP. Les chapitres suivants ne parleront que du couple SIP/RTP, devenus par le fil du temps la référence dans les technologies VoIP. H323 [74] et MEGACO [75] n’occupent plus qu’un faible pourcentage du trafic voix mondiale, les recherchent se focalisent donc sur SIP/RTP. L’utilisation des flows et notamment IPFIX / Netflow V9 dans la surveillance du trafic voix en est à ses balbutiements, en témoigne les drafts de l’IETF datant de 2012 sur IPFIX et SIP

Figure 61 : Exemple de communication SIP voipforo.com

59

[76] et sur IPFIX et RTP [77]. La norme IPFIX est elle-même en plein essor, le tracker de l’IETF [78] en est la preuve. Alors que tu côté de l’IETF, les RFC pour IPFIX et la VoIP sont encore à leurs balbutiement, des chercheurs tels Luca Deri et sa fondation nTop [66] implémentes les métriques de surveillance de la VoIP dans la sonde open source nProbe [79]. La figure 62 regroupe les différentes métriques qu’il est possible d’inclure dans des flows sous Nprobe.

Figure 62 : métriques SIP/RTP compatibles avec nProbe [48] Comme l’expliquent les articles [79] et [80], la surveillance de la VoIP nécessite de pouvoir visualiser à la fois le trafic de signalisation SIP/SDP (voir figure 64) et le flux de voix en lui-même (RTP) comme le montrent les figures 61 et 63.

Figure 63 : Architecture d'une communication VoIP [79]

60

Figure 64 : Description d'un paquet SIP pour la génération d'un flow [80]

L’article [80] donne d’ailleurs un résumé relativement complet de ce qu’il est possible de surveiller avec une sonde IPFIX /Netflow en VoIP : Entêtes SIP :

• Les tuples SipFrom (initiateur de la communication), sipTo( invité) et sipCallI , identifiant à eux trois une communication bidirectionnelle VoIP SIP.

• Les méthodes du protocole SIP sipRequestMethod: INVITE, REGISTER, BYE… • Les identifiants URI sipRequestURI • Les codes de réponses au sipRequestMethod : 2xx, 4xx, 5xx …

Informations de médias provenant du protocole SDP :

• sipMediaId (identifiant unique pour la description du média) • sipMediaProtocol (ex. RTP/AVP) • sipMediaType (audio, video, ...) • sipMediaEncoding (G722, GSM, PCMU, ...)

Informations provenant du flux voix RTP:

• rtpPayloadType

Données de performance provenant du flux voix RTP : • Jitter : variation du delay entre deux points • Paket loss : perte de paquet entre les deux points

3.5.4 Quels types d’attaques surveiller ?

Les deux articles [72] et [73] retenus sont de ce point de vus en accord avec les attaques potentiellement nuisibles à un environnement SIP/RTP. Par ailleurs, d’autres publications telles que les articles [81] et [82] recenses également ces attaques. Il est d’ailleurs intéressant de noter comment, selon l’article [81], les attaques VoIP sont classées. Nous verrons que dans les articles présentés, seules les attaques de type « message flooding »sont concernées.

61

Figure 65 : Classification des attaques VoIP [50]

On dénombre 3 attaques de type « Message Flooding » : • « SIP Flooding » : L’attaquant envoi à un proxy ou un autre agent un nombre

important et simultané de requêtes SIP INVITE REGISTER,etc. dans un court délai, causant une montée en charge importante et la saturation des ressources. Pour finir par un blocage du proxy / agent et un rejet des connexions d’autres utilisateurs (voir figure 66).

Figure 66 : Comportement d'un Proxy lors d'un « SIP flooding » [47]

62

• « RTP Flooding » : La technique de flood par RTP repose sur le même principe

que pour le flood par requêtes SIP. Un grand nombre de paquets RTP sont envoyés au proxy ou à un agent afin de le surcharger pour le rendre inopérant (voir figure 68).

• « SIP Scan » : différentes des deux précédentes, l’attaque « SIP Scan ».

L’utilisateur frauduleux tente de s’enregistrer auprès d’un proxy (requête SIP REGISTER) de manière forcée. Similaire à une injection SQL aveugle, l’utilisateur frauduleux va tenter plusieurs variantes d’URI (Uniforme Resource Identifiers) jusqu'à ce que sa requête et son enregistrement soit validé par le proxy. Une fois validé, l’attaquant à accès à la base d’utilisateurs enregistrés. Il peut ainsi récupérer des informations (URI, utilisateur en ligne, etc.) pour les attaques de « flooding »

3.5.5 Méthodes de détection

La proposition de l’article [72] se base sur l’utilisation de nProbe. Nous avons vu dans le chapitre sur la technologie nFlow-Lite que nToP faisait office de convertisseur nFlow-Lite vers nFlow V9 / IPFIX. Dans cet article, nProbe est un composant de la même famille que nTop. La machine où se trouve installé nProbe fait transiter, le trafic VoIP (proxy), la sonde nProbe peut alors générer des flows du trafic SIP/RTP comme expliqué dans la figure 67. Pour rappel, la figure 62 montre les champs qu’il est possible de surveiller grave à Netflow / IFPIX sous nProbe.

Figure 67 : nProbe et VoIP

63

La solution présentée dans l’article [72] n’est qu’une proposition, en effet les chercheurs n’ont pas donné suite en faisant des tests ainsi que des implémentations, l’article [73] tire d’ailleurs la même conclusion en le citant comme « non terminé ». La recherche autour des méthodes de détection est par contre plus poussée sur l’article [73], grâce à celui si, nous pouvons avoir une vue sur les précédentes recherches effectuées en la matière :

• Utilisation du concept de « distance d’hellinger »’ dans l’article [83]. Se basant sur la différence entre une source de donnée échantillonnée au préalable et une source de donnée en surveillance sur la même période. Selon les chercheurs de l’article [73] , cette méthode pose la problématique d’avoir une source échantillonnée fiable, ne subissant pas encore une attaque.

• Utilisation des machines d’état finit pour une approche orientée IDS (Intrusion Detection System) dans l’article [84]. Les chercheurs ne remettent ici pas en cause les performances, mais les ressources nécessaires pour maintenir en mémoire une empreinte de chaque flux. La méthode est donc efficace, mais difficilement implémentable dans un environnement de plusieurs milliers de communications VoIP simultanées.

• Approche orientée IDS également pour l’article [85], utilisant le concept des réseaux de pétri. Article fondé sur des tests en laboratoire, aucune mise en pratique n’a permis de valider cette technologie dans des cas réels.

• L’article [80] quant à lui propose l’ajout d’extension au modèle IPFIX afin de prendre en compte le trafic SIP/ SDP / RTP. Les recherches faites autour des attaques VoIP se limitant par contre au type DOS (Deny Of Service).

3.5.6 Exemple avec une attaque « RTP Flooding »

L’article [73] donne plusieurs algorithmes de détection des attaques, voici, par exemple, la méthode proposée par les chercheurs pour détecter une attaque par « RTP Flooding ». Pour rappel, le RTP Flooding consiste à générer des paquets RTP en plus de ceux générés par une communication entre deux utilisateurs afin d’en saturer les ressources.

Figure 68 : Attaque par RTP Flooding

64

Ci-dessus la figure 69 schématise globalement les flux que l’attaquant envoie à un des utilisateurs afin de saturer son équipement.

Figure 69 : algorithme de détection d'un "RTP flood" utilisant les flows [73] L’algorithme présenté dans la figure 69 se base sur plusieurs informations pour détecter la présence de l’attaque :

• Utilise les champs SSRC (Synchronization Source) et Sequence Number de l’entête RTP. Le champ SSRC est un identifiant unique de l’entête RTP permettant d’identifier la source du flux voix. Les chances que deux flux aient le même SSRC est minime, car ceux-ci étant générés aléatoirement. Quant au champ Sequence Number , il est incrémenté d’un à chaque envoi de paquet RTP. Il permet de reconstruire et gérer la réception des flux lors de pertes de paquets.

• Scan le SSRC de chaque flow contentant le flux RTP, si celui-ci vient à changer sur une même session (donc sur un même appel VoIP), une probable attaque est détectée.

• Vérifie la présence d’un gap entre les numéros de séquence, pour cela, les chercheurs se basent sur les compteurs de numéro de séquence présent à la fois dans les entêtes RTP et RTCP :

o First sequence number o Last sequence number

65

o Min sequence number o Max sequence number

3.5.7 Résultats

Les résultats de la figure 70 tirés de l’article [72] montrent, en fonction du type d’attaque, le type d’analyse devant être effectué par le collecteur Netflow .

Figure 70 : type d'analyse pour chaque attaque [72] Les chercheurs, par cet article, ne donnent pas en détail la méthode utilisée pour implémenter SIP/RTP dans la norme IPFIX. Cette méthodologie est décrite dans un de leurs précédents article [86]. Quant aux résultats de leurs recherches, hormis la figure 70, nous n’avons pas de précisions sur les performances des résultats obtenus. Les chercheurs dans le cas de l’article [73] ont généré 1,946 appelle VoIP sur un réseau opérateur de Corée du Sud, sur certains de ces appels, du trafic simulant des attaques a été injecté. Il en ressort la figure 71, montrant que les algorithmes proposés dans l’article ont un faible taux d’échec lors de la détection des attaques. Chaque ligne du tableau est une attaque, pour chaque attaque, le nom total de flows émis pour l’appel est affiché, suivit du nombre de flows simulant l’attaque. La précision des résultats est donnée en pourcentage, suivit de la précision lors d’un rappel, pour finir par la moyenne harmonisée des deux précédentes.

66

Figure 71 : performance dans la détection d'attaques VoIP [73]

Globalement, les articles [72] et [73] utilisés, permettent de clairement cerner le problème la surveillance des communications VoIP grâce aux flows. Alors que l’article [72] décrit de manière globale le cheminement et l’architecture mis en place pour arriver à une technologie fonctionnelle, l’article [73] donne des algorithmes ainsi que des résultats concrets. Il faut également prendre en compte le fait que ces recherches couvrent seulement une partie des attaques d’un environnement VoIP. Comme le rappelle la figure 65, il existe également des attaques par falsification de données, se basant sur des failles des mécanismes de cryptage et d’authentification. Dans ces cas-ci, la surveillance du trafic grâce aux flows ne serait pas préconisée.

3.6 Mesure de la perte de paquet grâce à aux flows

De nombreux opérateurs et acteurs de la télécommunication implémentent les flows dans leur architecture de cœur de réseaux, dans cette logique de rentabilisation de cette technologie, des recherches tentent d’ajouter de nouvelles fonctionnalités aux statistiques de base disponibles sous Netflow / IPFIX. Les deux articles présentés dans cette section traitent des recherchent effectué autour de la mesure des pertes de paquet entre deux points (ou nœud) d’un réseau IP. Pour rappel, historiquement la commande PING sur ICMP (Internet Control Message Protocol) est utilisée pour mesurer la latence ainsi que la perte de paquet sur un lien réseau et cela de manière simple. L’article [87] expose une méthode permettant, tout en utilisant les flows stockés par un collecteur déjà présent sur un réseau, de mesurer la perte de paquet entre deux points d’un réseau. Nous verrons par la suite que la méthode proposée introduit le concept de « Super Flow ». L’article [88] quant à lui , affine la détection des pertes de paquet en quantifiant et compensant les erreurs du à l’environnement Netflow / IPFIX et notamment à la perte de flows à destination du collecteur.

3.6.1 Genèse des « superflow »

Comme expliqué dans l’article [87], les chercheurs se basent sur les travaux de l’article [89] décrivant lui-même des travaux sur l’analyse et la détection des pertes de paquets sur des

67

liaisons à haut débit (supérieur à 10Gbit/s). Les chercheurs avait ( en 2009) atteins de très bonnes performances, puisque leur technologie était capable de traiter 100% des paquets sur un lien de 12Gbit/s et donnant des performances bien supérieures à un PING sur ICMP comme le montre la figure 72 ci-dessous.

Figure 72 : Précision de PING par rapport à un calcul de perte de paquet de l'article

La méthode d’estimation de l’article [89] se révèle selon les chercheurs efficace à 100% puisque constante dans ses résultats. Il n’en est pas de même pour les PING puisque comme le montre le graphique, l’augmentation du nombre de PING par second (pour arriver à 1000 ping/sec) ne permet que d’arriver à une précision de 25% inférieur à la méthode des chercheurs. La figure 73, toujours issu de l’article [89] montre que même si aucune technologie à base de flows n’est utilisé, le rapprochement peut être fait du fait de l’utilisation de splitter optique pour dupliquer le trafic, chose faite par Netflow de manière logicielle, mais globalement semblable.

Figure 73: architecture de test de l’article [89] proche de la technologie Netflow

68

Après lecture de l’article [89], il est naturel de comprendre que les chercheurs de l’article [87] ont tout simplement transposé et amélioré cette technologie dans un environnement Netflow / IPFIX, rendant ainsi inutile, l’utilisation de TAP ou de splitter optique.

3.6.2 Méthode et environnement de création des « superflows »

Voici comment, grâce à deux nœuds dans un réseau (voir figure 74), les chercheurs de l’article [87]proposent de calculer le taux de perte de paquet sur une liaison :

• Deux routeurs, un comme point d’entrée du trafic (A - ingress) et un comme point de sortie (B - egress).

• Le trafic IP transitant du routeur A au routeur B est analysé et chaque routeur dispose de la technologie flows. Des flows sont générés à l’entrée (A) et à la sortie (B) de la liaison lorsque le trafic IP identifié comme en surveillance traverse les deux équipements.

Figure 74 : environnement de création des "super-flows" [87]

Comme expliqué dans les sections précédentes, un flow est de base identifiée par un tuple de données (adresse source / destination puis port source / destination), lorsque les flows générés par les routeurs A et B arrivent au collecteur, celui-ci identifie les flows ayant un même tuple ainsi que des valeurs timestamp rapprochées pour crée un « super flows ». Comme le montre la figure 75, les flows provenant de A et B peuvent contenir chacun plusieurs paquets provenant de l’échantillonnage.

Figure 75: création des "super flows" [87]

69

Une fois ces « super flows » créent, des méthodes mathématiques se basant sur des affirmations permettent de calculer le taux de perte de paquet entre les points A et B. Afin de valider les recherches, l’architecture de test suivante (figure 76) est proposée :

• Deux machines (A et B) générant des flux IPFIX grâce au logiciel YAF [90] • Les logiciels HARPOON [91] , D-ITG [92] et NMAP [93] servant à générer

respectivement le trafic Web, VoIP et une série de connexion aléatoire. • Deux routeurs R1 et R2 faisant office de routeur d’entrer (ingress) et de sortie

(egress) analyse le trafic de donnée ainsi que les flows générés par A et B. Les informations de routage de R1 et R2 différencient les flows du trafic normal et permettent comme le rappelle la figure 76 le routage des flows vers les collecteurs (machine C et D).

• Une liaison 10Mb/s entre R1 et la machine E, simulant un goulot d’étranglement d’une liaison WAN.

• Une machine E avec le logiciel installé permettant de simuler une variation de la latence entre R1 et R2 toujours dans le but de simuler une liaison WAN.

Figure 76 : architecture de test des "super flows" [87]

3.6.3 Résultats

Afin de mieux comprendre les résultats, voici un rappel des scénarios crées : • Le premier scénario amenant à une perte d’environ 2,5% des paquets.

Représentant une perte pouvant être qualifié de normal sur un réseau WAN. • Un deuxième scénario amenant une perte de 30% de paquets. Représentant un

scénario de saturation d’un lien. Voici les résultats, la figure 77 permet de démettre plusieurs conclusions quant à ces recherches :

• La première ligne contient les performances pour une simulation de perte de trafic ne dépassant pas 2.5% de la charge totale.

• La seconde ligne contient les performances pour une simulation de perte de trafic de 30% de la charge totale.

70

• Les résultats de la colonne de gauche prennent en compte l’utilisation des informations de routage du réseau, nous n’avons pas plus de précisions concernant ces informations.

• Les résultats de la colonne de droite ne prennent pas en compte les informations de routage, mais applique un filtre sur les « super-flows » de petite taille (Φ=1) contenant seulement 1 seul paquet de données par flow. Les « super-flows » de petite taille comme expliquée dans la conclusion de l’article faussent les résultats et tirent vers le bas les performances de la méthode.

• En abscisse, les performances d’analyse de perte de paquet par un dump du trafic. Cette méthode inutilisable en environnement de production permet ici dans le cas de recherche d’avoir la valeur exacte de perte de paquet par rapport à la méthode estimée des « supers-flows ».

• Les auteurs concluent que leur méthode se veut presque aussi fiable qu’un dump du trafic. Il faut toutefois soulignée de grandes déviations de performance lorsque les informations de routage ne sont pas présentes pour aider l’estimation (colonne de gauche).

Figure 77 : Résultat des « super flows » par rapport à un dump sur l’estimation de perte de paquet. [87]

On peut conclure sur l’article [87] en disant que la méthode expérimentée de celui-ci se veut efficace. Comme l’expliquent les auteurs dans leur conclusion, cette méthode peut ensuite

71

évoluer dans plusieurs directions propres aux technologies et réseaux auxquelles elle peut être appliquée. De plus, un point important est soulevé, il serait nécessaire de voir le comportement de cette méthode lors de l’utilisation de méthode d’échantillonnage de flows (flexible netflow, Netflow Lite…) pouvant réduire sa précision.

3.7 Conclusion du chapitre

Ce chapitre a permis de mettre en lumière certaines recherches effectuées autour des technologies de type flow. Il en ressort que :

• les flows, que ce soit Netflow ou IPFIX nécessite une bonne maitrise de la technologie lors de leurs mises en place, car celle-ci est à la fois performante et gourmande en ressource.

• les flows sont comme ce chapitre l’a expliqué, des « duplicatas » des données transitant sur les réseaux. Les recherchent démontrent que les applications possibles sont larges, variés et en pleine évolution.

• le standard IPFIX est en plein essor, dérivant de Netflow V9 et totalement compatible avec celui-ci, IPFIX se veut être l’avenir des technologies flow grâce au standard poussé par l’IETF.

Les statistiques provenant des technologies Netflow / IPFIX ne peuvent être considérées comme valables et justes dès le début de leurs implémentations. De nombreux facteurs comme : • la perte des flows avant leur arrivés au collecteur, • le taux d’échantillonnage, • les sondes et collecteurs utilisés, nécessitent des étalonnages ainsi que des

vérifications préalables à la mise en production.

72

Chapitre 4: La supervision et ses concepts appliqués à un réseau d’entreprise.

Dans ce chapitre, nous allons aborder la supervision d’un réseau de télécommunication d’un point de vue pratique et fonctionnel. Alors que les chapitres précédents prenaient comme bibliographie des articles de recherche ainsi que des publications d’institutions comme l’IETF ou l’ITU, il en sera autrement pour les chapitres suivants. En effet, d’un point de vue pratique, les publications scientifiques sont généralement en avance sur leur temps, les technologies ainsi que les méthodes proposées ne sont généralement pas ou peu implémentées en environnement de production d’entreprise. Nous allons donc dans ce chapitre suivre un cheminement d’un point de vue ingénierie avec la création d’un système de supervision global pour un réseau de télécommunication. Le marché de la supervision est relativement vaste et les logiciels de supervision open source disponibles dans le commerce sont nombreux. Le but du chapitre 4 n’est dans aucun cas de faire une liste complète des programmes pouvant effectuer une ou plusieurs tâches de surveillance d’un réseau, mais bien d’en sélectionner plusieurs pour leurs rôles spécifiques dans un système de surveillance global. Nous allons voir dans les sections suivantes que la supervision d’un réseau de télécommunication est généralement scindée en deux parties :

• La supervision par état : « un équipement répond-il aux requêtes de la supervision ? Est-il allumé ? Le service fonctionne t’-il correctement ? »

• La métrologie des performances ou la surveillance des performances d’un équipement ou de tout type de service par l’intermédiaire de graphique montrant l’évolution des performances.

4.1 Prévention et taux de disponibilité

Les enjeux majeurs de la surveillance d’un réseau sont les suivants :

• Garantir un taux de disponibilité minimum le plus haut possible grâce à la surveillance des points stratégiques afin d’avoir une réaction rapide et adaptée à une panne. Pour rappel, lorsque l’on parle de taux de disponibilité en pourcentage, voici en nombre d’heures à quoi cela correspond (voir figure 78 à la page suivante) :

73

Figure 78 : taux de disponibilité dans un réseau et nombre d'heures associé monitoring-fr.org

• Prévenir de possibles pannes par l’analyse et la remontée rapide d’informations vers la supervision amenant à un comportement « pro actif ».

4.2 Surveiller quoi et à quel niveau ?

Depuis quelques années, la supervision est prise au sérieux par les décideurs informatiques (DSI). Des communautés se forment et des cahiers de charge apparaissent afin de tenter de définir les bonnes pratiques. C’en en autre le cas de la communauté « monitoring-fr » [94] ayant fait un travail de fond sur la définition de ce qu’un environnement de supervision devrait être aujourd’hui, il en ressort les choses suivantes (toujours selon le site [94] ) : Que doit-on superviser :

• le réseau et ses équipements (routeurs, commutateurs, liaisons haut et bas débits…)

• les serveurs (serveur WEB, serveur DNS, serveur mail…) • les périphériques (imprimantes, équipements industriels spécifiques…) • les applications (progiciels, ERP…) • le workflow (chemin d’un flux d’information, exemple une sauvegarde de base

de données) • surveiller les systèmes d’information (de manière globale, le fonctionnement

du système dans son intégralité) • assurer la disponibilité des services (garantir à l’utilisateur le maximum de

confort lors de l’utilisation des services du système d’information). • prévenir les défaillances • détecter les anomalies (sécurité, système). • fédérer l’information d’équipements hétérogènes en un portail unique. • alerter en cas d’interruption d’un service.

74

• … Le site [94] définit d’ailleurs plusieurs niveaux de surveillance permettant de bien saisir chaque aspect d’un système d’information. Supervision environnementale, liée aux conditions dans lequel le système d’information s’exécute :

• température de la pièce • humidité de la pièce • …

Supervision réseau et matériel

• Commutateurs et routeurs : disponibilité, interrogation des sondes, alertes. • Serveurs : disponibilité, interrogation des sondes matérielles, alertes. • Onduleurs : disponibilité, charge, état. • Imprimantes : disponibilité, état de l’imprimante et des consommables.

Supervision des systèmes

• Commutateurs : utilisation des ressources, métrologie, débits des interfaces... • Serveurs : utilisation des ressources.

Supervision des applications et services

• Disponibilité. • Cohérence des réponses aux interrogations. • Performances.

Les niveaux de surveillance décrits par le site [94] peuvent donc être résumés tel que le montre la figure 79 (chaque niveau est dépendant du niveau qui le précède).

Figure 79 : niveaux de supervision et dépendances

Applica>ons  et  Services  

Systèmes  

Réseau  et  Matérielle  

Environnement  

75

4.3 Ordonnanceur /superviseur: quel est son rôle

L’ordonnanceur ou appelé également superviseur (les deux termes apparaissent généralement dans la littérature) est le composant contenant l’intelligence nécessaire permettant d’effectuer des actions suivantes :

• La surveillance des équipements (ordinateurs, serveurs, réseaux ainsi que tous types d’équipements pouvant communiquer sur le réseau)

• La surveillance des services de chaque équipement • Le dialogue avec d’autres applications, plug-ins ou avec des protocoles de

surveillance (ex : SNMP). • La gestion des évènements liés à la surveillance du réseau (perte de

connectivité, manque de ressource, performances dégradées…) • L’affichage sur une interface de contrôle, piloté par un administrateur. • L’ordonnanceur permet ainsi de surveiller tous les niveaux présentés dans la

figure 79 de la section précédente. Quant à la figure 80 ci-dessous, celle-ci permet d’avoir une vue globale de l’environnement autour duquel gravite l’ordonnanceur. Ce schéma est volontairement simpliste afin de bien assimiler le concept de supervision d’un environnement informatique. Il n’est en aucun exhaustif de tout ce qu’il est possible de réaliser.

Figure 80 : Environnement de l'ordonnanceur

76

Nous verrons dans les sections suivantes de ce chapitre l’ordonnanceur Shinken [95] ainsi que plusieurs concepts de supervision présente au sein de celui-ci.

4.3.1 Nagios, une référence en perte de vitesse

Nagios [96] est né de l’initiative d’Etan Galstad, la première version date de 1999. Depuis maintenant 13 ans, Nagios fait figure de logiciel open source indétrônable dans le monde de la supervision sous Unix /Linux. Les nombreuses versions qui se sont succédé ont aujourd’hui donné naissance à un standard. Une foule d’add-ons permettent à l’heure actuelle, par l’intermédiaire de communauté telle Nagios Exchange [97] de surveiller la quasi-intégralité des équipements disponibles dans le commerce.

Nagios de par son évolution et son statut de logiciel historique de supervision a plusieurs points forts [98] :

• Une architecture basée sur l’utilisation de gabarits permettant de définir un hôte ainsi que ses services associés.

• Des centaines d’add-ons et plug-ins développés par la communauté (donc gratuit pour la plupart) permettant de surveiller tous les niveaux (figure 79) d’un environnement informatique.

• Un modèle simple de code de retour permettant de connaitre l’état du service/hôte surveillé.

o Pour les hôtes : § UP : L’hôte répond aux sollicitations du superviseur (exemple

un PING) § DOWN : L’hôte ne répond pas aux sollicitations. § UNREACHABLE : L’équipement reliant l’hôte surveillé est

injoignable. La relation Parent/Enfant dans le réseau permet de créer ce statut.

Figure 81 : Nagios et ses interfaces de surveillance [95]

77

o Pour les services : • OK : Le service fonctionne correctement. • WARNING : Les performances sont un seuil d’alerte défini par

l’administrateur • CRITICAL : Le service ne répond plus ou dépasse un seuil

d’alerte néfaste à son fonctionnement. • UNKNOW : Le service ne répond pas aux requêtes de la

supervision. • Une gestion des alertes paramétrable qui s’adapte à l’environnement (SMS,

MAIL, flux RSS…).

Mais également des points faibles : • Un démon monolithique, supportant mal la montée en charge dans des réseaux

de grandes tailles. • L’absence d’interface de configuration et de création des équipements à

surveiller. Il est nécessaire de maintenir des fichiers plats de configuration dans la plus grande tradition du monde Unix.

• Une interface web vieillissante basée sur CGI (Common Graphic Interface) peu convivial, n’ayant que peu évolué depuis ses débuts.

• Depuis octobre 2009, Nagios fut découpé en deux branches : o La version Nagios Core [99] gratuite ne comporte pas d’amélioration.

Seul le support de la communauté permet de faire vivre cette version. o La version Nagios XI [100] payante dérive de son modèle gratuit

original. Toutes les dernières améliorations (moteur de supervision, refonte de l’interface graphique…) passent dans la version payante.

Le manque de visibilité à long terme produit par la version Nagios XI payante créa un petit séisme dans le monde de la supervision open source. Entre temps, de nombreux projets dérivant des sources de Nagios et compatibles avec son modèle d’architecture interne (on parle alors de compatibilité « Nagios Core ») se créèrent :

• CENTREON [101] • INCIGA [102] • SHINKEN [95]

Ceci n’est qu’une liste non exhaustive des variantes de Nagios. Mais elle représente les trois acteurs susceptibles de grignoter des parts de marcher à la solution historique. Nous verrons que le choix s’est porté dans le cas de ce projet sur l’utilisation de Shinken [95] pour les raisons détaillées dans la section suivante.

4.3.2 Shinken : un fork de Nagios performant et modulaire

Comme expliqué dans la section précédente, Nagios souffre de plusieurs défauts majeurs. Le projet Shinken [95] part de ce constat. Les propositions faites par l’auteur de Shinken Jean Gabes pour améliorer Nagios n’ayant pas eu de suite [103], le projet Shinken vit le jour avec comme ligne directrice :

78

• L’amélioration des performances dans les environnements de plusieurs milliers d’hôtes et de services.

• L’abandon d’un démon monolithique (Nagios) vers plusieurs démons supportant une importante montée en charge et leur répartition (load balancing) de manière simple.

• L’abandon du langage C pour le langage python [104] multi plateforme (Windows, Linux…) et indépendant du système d’exploitation. L’apport de la librairie Pyro [105] permettant une programmation objet et distribuée.

Globalement le projet Shinken est un succès. En termes de performance, il est possible, sans recourir à des architectures compliquées, de mettre en place d’une supervision comportant :

• 100 000 vérifications de service • Surveillant plus de 60 000 équipements • Faisant un polling de 500 000 données de performance (métrologie) vers le

logiciel Graphite (présenté dans la section suivante). Chose impossible sous Nagios de par son architecture interne basé sur un démon monolithique écrit en langage C et très peu mis à jour depuis sa création.

4.3.3 Architecture interne de Shinken

Afin de comprendre la logique derrière le projet Shinken, il est nécessaire de comprendre le rôle de chaque démon écrit en python. En effet, chaque démon joue ici un rôle précis.

Figure 82 : Architecture interne de Shinken [103]

79

Arbiter, le démon lit la configuration globale de la supervision. Il s’occupe de découper la configuration en fonction du nombre N de démons de chaque sorte (Poller,Scheduller,….). Il va également s’occuper de vérifier la disponibilité de chaque démon, déportant la configuration vers un N+1 en cas de panne. L’arbiter va par exemple configurer le ou les reactionner en fonction de la configuration faite par l’administrateur et ainsi mettre en place les alertes (Mail,SMS…) de la supervision. Il peut par exemple acquérir la liste des équipements et des services associées depuis :

• Un script MySQL[106] • GLPI : le gestionnaire de parc informatique open source [107] • LANDSCAPE : le gestionnaire de parc de machines sous Ubuntu [108] • SkonfUI : le service interne de Shinken de découverte du réseau [109] • Découvrant automatiquement les dépendances système hôte/système virtualisé

par des modules VmWare et XenServer [110]. Scheduler : une fois sa configuration faite par l’Arbiter, il initie, garde en mémoire la file d’attente des vérifications en cours (hôte et services) et les réparties vers les pollers. Il transmet également les résultats des vérifications au reactionner. Poller : une fois la demande de vérification envoyée depuis le scheduler au poller, celui-ci s’occupe de lancer la commande effectuant la vérification demandée (un check), celui-ci peut être de plusieurs formes :

• L’exécution d’une commande ou d’un script local au superviseur (PING, traceroute , script Shell,…)

• L’exécution distante de script par l’intermédiaire de technologie comme NRPE [111]

Reactionner : Ce démon s’occupe des notifications auprès des utilisateurs (mails, SMS, flux RSS…). Il permet la communication de la supervision avec l’extérieure grâce un gestionnaire d’événement (event_handlers). Broker : ce démon s’occupe de la rétention des données, une fois les données de surveillance remontée du poller jusqu’au scheduler. Le scheduler envoie les données de surveillance au broker s’occupant du stockage [112] :

• des logs de Shinken dans des fichiers plats • des informations de supervision (hôtes et services) en base de données

(MongoDB, MySQL, Oracle…) • Des informations de performance (métrologie) vers Cacti [113], graphite

[114] et tout autre module de métrologie (voir section suivante). Receiver (optionnel) : Ce démon sert à recevoir les checks passifs. L’intérêt de séparer les check passifs (tels que les trappes SNMP ou les alarmes de toutes sortes) se trouve au niveau du risque de surcharge. Le recever soulage les pollers / scheidulers lors d’un pique d’alarmes et est utilisable avec des technologies telles que :

80

• NSCA, le protocole historique de Nagios permettant la réception passive de check [115]

• Ws_arbiter un module développé par l’équipe de Shinken permettant la réception par http de checks passifs. [116]

Les démons peuvent être répartis sur plusieurs serveurs en fonction de la taille du réseau à surveiller. La supervision d’un réseau de petite taille (une centaine d’hôtes avec chacun plusieurs services) peut être effectuée avec tous les démons sur une seule machine bien dimensionnée en terme de ressource.

4.3.4 Conclusion sur Shinken

Shinken est l’évolution attendue par tous les utilisateurs de Nagios, il suffit de mettre en pratique son installation et son utilisation pour voir les progrès effectués en termes de performance, de facilité de configuration et de fonctionnalités. Il n’est pas simple de résumer l’étendue de ses fonctionnalités dans une présentation du logiciel mais son installation rapide en 10 minutes [117] est un atout majeur.

4.4 Métrologie : quoi représenter et comment ?

La métrologie (ou comment représenter les données de performance issues du réseau surveillé) s’avère être un complément indispensable à une supervision performante. En effet, là où l’ordonnanceur / superviseur comme Shinken (section précédente) permet une surveillance par état (UP, DOWN, OK, WARNING…), des outils comme Cacti [113] ou graphite [114] vont permettre de conserver un historique de données variant dans le temps (débit, température, pourcentage d’utilisation d’un composant…)

4.4.1 Cacti, un acteur majeur de la métrologie

Cacti peut être considéré et à juste titre comme le logiciel open source de métrologie numéro un. Celui-ci se base sur les bases de données RRD (Round Robin Database).Cacti jouie d’une popularité et d’une communauté des plus actives. À tel point qu’à l’heure actuelle, il est possible de trouver des configurations préétablies pour la grande majorité des équipements du commerce. La figure 83 ci-dessous donne un aperçu du type d’interface graphique qui est possible d’avoir lors de l’utilisation du logiciel, une hiérarchie se basant sur des gabarits ainsi que le parc d’équipements supervisés permet d’agréger sur son navigateur internet l’ensemble des données de performance du réseau.

81

Figure 83 : interface graphique de Cacti [113]

4.4.2 Fonctionnement d’une base RRD

Cacti est intrinsèquement lié aux bases de données RRD [118] et à l’outil RRDtools. L’intérêt (mais aussi la faiblesse) des bases RRD se trouve dans la nécessité de connaitre et de définir ses sources de données. En clair, ce que l’on va surveiller (par exemple le taux d’utilisation d’un processeur) et comment ces données vont être stockées et affichées (valeur max, nombre d’enregistrements…). Il est nécessaire de connaitre un minimum l’architecture de RRD (Round Robin Database) afin ensuite de peser le pour et le contre par rapport à d’autres moteurs de métrologie. Une base RRD se compose de la sorte :

• Une source de donnée appelée DS (Data Source) pouvant être du type : o GAUGE : une valeur variable dans le temps (comme une température

ou un espace disque). o COUNTER : un compteur incrémenté, pour par exemple le nombre de

paquets transitant sur une interface réseau.

• Un ou plusieurs fichiers RRA (Round Robin Archive). Chaque fichier RRA se compose alors :

o du type d’agrégation que l’on souhaite sur le DS : § AVERAGE, MIN, MAX, LAST

82

o de l’option XFF : option de consolidation permettant de « combler des trous », apparaissant lorsque les données en entrée sont invalides.

o de l’option STEP, donnant le nombre de points utilisés dans le DS pour faire une consolidation (une entrée en base RRD).

o de l’option ROWS, donnant le nombre d’entrées dans la base. Un graphique sous RRDtools est généralement composé de plusieurs fichiers RRA. Dans le cas d’une rétention de données sur plusieurs années, le principe suivant (figure 84 ci-dessous) est appliqué. Des fichiers RRA par tranche (jour / semaine / mois / année) sont créés. Quatre entrées de RRA jour sont utilisées pour créer une entrée dans le RRA semaine. Cela permet une conservation des données sur plusieurs années tout en garantissant une taille des fichiers RRA acceptables et par ailleurs fixe.

Figure 84 : scénario de rétention des données [119] Ceci n’est qu’une brève présentation de RRDtool servant de base à une comparaison avec l’autre moteur de métrologie (Graphite) présentez plus loin.

4.4.3 Cacti un outil puissant, mais avec certaines faiblesses

Cacti couplé à RRDtool est un outil, comme démontré dans la section précédente, extrêmement puissant. Mais il comporte également des faiblesses qu’il est bon de connaitre avant d’effectuer un choix :

• L’interface graphique (Cacti) de gestion des graphiques RRDtool et permettant la création de gabarits, la gestion des sources de données (DS) et des règles de conservation (RRA) n’est pas des plus ergonomiques. Un long temps d’apprentissage est nécessaire afin de réussir à représenter ce que l’on désire.

• Les fichiers de rétention RRA sont de taille fixe, une fois leurs définitions faites, il n’est pas simple de revenir en arrière et de modifier les propriétés. La modification entraine généralement des pertes de données dans les RRA. Il est

83

nécessaire de contraire exactement ce que l’on veut représenter et comment avant une mise en production.

• L’utilisation d’une agrégation (MIN, MAX, AVERAGE…) des données inappropriée peut avoir comme effet de bord un affichage corrompu.

• Les modifications ne sont pas appliquées en temps réel, il est nécessaire d’attendre le polling (parfois plusieurs minutes) suivant pour voir l’effet sur des modifications des DS et RRA.

• Les incompatibilités entre les versions de Cacti. Il n’est pas rare après des années de rétention de bases RDD de vouloir mettre à jour Cacti et son moteur. Or certains gaps entre les versions du logiciel ne sont pas franchissables de manière simple. Un risque de perte ou de corruption des fichiers RRA est envisageable.

4.4.4 Graphite, un conçurent qui gagne du terrain

Graphite [114] fait figure de nouveau venu dans le paysage de la métrologie open source. Le projet démarra en 2010 et est aujourd’hui une alternative viable à Cacti / RRDtool. Nous allons voir dans les sections suivantes que Graphite est comparable à Cacti / RRDtool, mais rajoute les composantes de flexibilité et de simplicité à son fonctionnement.

Figure 85 : interface utilisateur de graphite [114]

84

Figure 86 : API de génération des graphiques depuis l'interface web [114]

Graphite est composé de trois modules : • Carbon [120] : un démon de gestion des données de métrologie. Il collecte les

données sérialisées en provenance des équipements gérés. Gère également un cache pour les inscriptions en base performante.

• Whisper [121] : une base de données orientée donnée sérialisée, similaire dans son approche à RRDtool, mais avec des spécificités qui seront abordées plus tard.

• Graphite Webapp : une interface web dynamique se basant sur le framework python Django[122].

Figure 87 : architecture de graphite

85

La figure 87 ci-dessus permet de comprendre le workflow des informations de métrologie à savoir, le démon « Carbon » puis l’inscription en base « Whisper » pour être ensuite affiché dans « GraphiteWebapp ».

4.4.5 Carbon , l’acquisition simplifiée des données

Graphite dispose de trois modes d’acquisition des données : • Plaintext (texte brut) : méthode la plus simple pour l’envoi des données de

performance. • Pickle : module provenant du langage python, permet la sérialisation et la dé-

sérialisation à haut volume. Il est utilisé dans les environnements ayant de grands volumes de données de métrologie.

• AMPQ (Advanced Message Queuing Protocol), protocole de couche applicative similaire à XMPP, HTTP et SMTP, il permet une gestion avancée de la communication inter –programme.

4.4.6 Whisper, les différences par rapport à RRDtool

Contrairement à un fichier RRA de RRDtool, l’ajout et la maintenance de données peut être rétroactif. Comme évoquée dans la section précédente, la rétention des données en base RRA est optimisée au point de ne plus pouvoir faire machine arrière. Dans le cas de la base Whisper, il est possible de modifier l’agrégation et la fréquence d’insertion en base des données. De plus les bases RRA sont sensibles aux mises à jour irrégulières des données, une sérialisation irrégulière (latence, données erronées) sera problématique avec un risque de perte des informations en base se traduisant par des graphiques faussés. Graphite supporte les insertions non régulières avec une temporisation entre les points pouvant varier ainsi que des écritures (et réécritures) de données antérieures. On peut également citer les avantages suivants en faveur de Graphite :

• Support de la redondance et la synchronisation de données en différé. • Le système d’affichage des données avec leurs fonctions de calcul (AVG,

MAX, MIN…) est indépendant du stockage en base à l’inverse de RRDtool où les fonctions sont appliquées à même les fichiers RRA.

• Graphite est également compatible avec les bases RRA, cela permet d’effectuer une migration de Cacti à Graphite tout en conservant les anciennes données de métrologie.

• Contrairement à RRDtool, aucune nécessité de définir le DataSource (DS) ainsi que les fichiers RRA. La mise en forme des données et leur agrégation seront réalisées lors de l’affichage.

86

4.4.7 Création d’une source de donnée, simplicité et efficacité

Nous allons voir qu’avec un script de 3 lignes de code, nous pouvons créer une source de donnée Carbon ainsi que sa base Whisper sous Graphite. Carbon ouvre une connexion socket sur le port 2003 et nécessite en entrée :

• Le chemin métrique (la provenance des données), par exemple « serveur1.processeur1.température »

• La donnée métrique, valeur inscrite en base • L’horodatage de la donnée

Le script suivant est écrit en Bash sous Linux et permet en une ligne, de faire les taches mentionnées ci –dessus jusqu'à la création automatique de la base de données Whisper associée.

Le terme chemin métrique est très important, car à la manière d’un langage de programmation objet, les métriques seront ensuite classées dans l’interface Web de manière hiérarchique en fonction du chemin métrique.

Figure 88 : hiérarchie des données métriques

L’ajout, la modification ainsi que l’affichage en temps réel des données de performance sous Graphite apport un réel plus en terme de simplification d’administration de l’outil par rapport à des logiciels comme Cacti.

4.5 Conclusion du chapitre

Nous avons pu introduire dans ce chapitre les prémisses de ce qu’est une supervision informatique en entreprise. L’explication des deux grands fondements (le superviseur et la métrologie) permet de mieux cerner l’architecture qui sera abordé dans le chapitre suivant. Architecture mis en place aux termes des 6 mois d’intervention au sein de l’entreprise ContactOI. Nous avons pu également voir l’importance d’une veille technologique sur les

echo "serveur1.processeur1.température $DONNEEMETRIQUE ` date +% s `" | nc $SERVER $PORT;

87

outils existant ainsi que le gap pouvant exister en terme de fonctionnalité entre deux concurrents (Nagios / Shinken ainsi que Cacti / Graphite). Il est nécessaire de retenir qu’une bonne supervision commence par le choix des outils adaptés et non pas forcément ceux données en exemple dans ce chapitre.

88

Chapitre 5 : Supervision et de métrologie homogène : CollectD, PerfTap, Shinken et Graphite

Ce chapitre va être consacré à la proposition d’une solution de métrologie que l’on pourrait qualifier de novatrice comme le montre la figure 89. En effet, les composants logiciels proposés pour cette architecture sont open source, récents (mais activement supportés par leurs communautés respectives) et de plus pleinement fonctionnels. L’architecture suivante va permettre de surveiller les équipements réseaux ainsi que serveurs (tous systèmes d’exploitation confondus) de manière homogène. Chaque niveau du système et ses dépendances du système de l’opérateur ContactOI [123] seront traités dans les sections suivantes par le biais de scénarios types mettant en scène les composants de l’architecture de supervision (figure 89 ci-dessous). Les outils présentés dans le chapitre précédent (Shinken et Graphite) ayant été jugés en accord avec les demandes de l’entreprise en termes de supervision (voir section suivante), nous allons dans ce chapitre décrire de manière appliqué (et non théorique) par le biais de scénarios de supervision propres à chaque équipement du réseau de l’entreprise ContactOI. La figure 89 présentée page suivante est une architecture logique de cette supervision. Shinken et Graphite y sont représentés ainsi que les flux (données d’état en bleu, de métrologie en orange), les interfaces ainsi que les systèmes d’alertes mis en place. La connaissance des interactions entre tous ces composants est primordiale afin de maitriser l’environnement de supervision présenté dans ce chapitre et permet par la suite de faire le lien avec les spécifications demandés par l’entreprise.

89

Figure 89: Architecture globale de supervision

90

5.1 Les besoins en termes de supervision de l’opérateur ContactOI

Pour des raisons de confidentialité envers l’entreprise m’ayant accueillis, aucun schéma interne lié à la gestion et au fonctionnement de leur réseau ne sera présenté. La supervision d’un système informatique étant universelle et se basant sur les considérations de chaque type d’équipement, il est en revanche possible d’appliquer ces principes tout en restant dans une certaine abstraction du système surveillé. Contact OI [123] peut être présenté comme un opérateur d’accès Internet alternatif de l’île de la Réunion. Celui-ci dispose d’une licence Wimax [124] 3.5Ghz sur la BLR (boucle local radio) française géré par l’ARCEP[125]. L’utilisation du Wimax sur le territoire de la Réunion permet en autre :

• de donner une connexion à internet ou point-à-point aux bâtiments situés en zone blanche (n’ayant pas un accès de type ADSL par ligne téléphonique) reculée.

• de permettre un déploiement rapide lors de manifestations d’un accès temporaire de type Internet ou point-à-point (transmission de flux vidéo pour la télévision, manifestations extérieurs…).

• proposer à des opérateurs tiers des liaisons « point-à-point » et du roaming par la technologie Wimax permettant d’outrepasser les barrières naturelles (ravins, altitude, problèmes de câblage).

5.1.1 Architecture de l’opérateur ContactOI et zones de surveillance

La figure 90 ci-dessous permet de mieux comprendre les différentes zones nécessitant une supervision au sein de l’architecture du réseau de l’opérateur.

• Zone rouge : Serveurs de production, supervision et de service (provisioning). Machines tournant sous système d’exploitation Linux ou Microsoft Windows Server. Une partie de ces machines sont des serveurs dit physiques et une migration vers des machines virtuelles sous VMware ESX5[126] est en cours.

• Zone jaune : Backbone réseaux composés de routeurs du constructeur Cisco (Cisco 3200, 7200, firewall PIX…)

• Zone violète : Sortie WAN reliant l’opérateur à Internet. • Zone bleu : Couverture Wimax, équipements du constructeurs Alvarion [127]

comportant plusieurs BTS (Base Tranceiver Station) chacune couvrant une zone géographique précise et plusieurs CPE (Customer Premises Equipment). Chaque CPE étant rattaché à une BTS en fonction de son emplacement géographique.

• Zone verte : Réseau du client, comportant une NG (Network Gateway) ou tout autre type d’équipement capable de gérer l’accès (routeur, commutateur, équipement Wifi…).

91

Figure 90 : Architecture de l'opérateur ContactOI

92

Quant à la figure 91 ci-dessous, celle-ci met en évidence l’interdépendance de chaque zone et la nécessité d’avoir une supervision de l’ensemble de réseau. On peut alors facilement comprendre qu’une notion de dépendance est nécessaire notamment pour permettre une meilleure gestion des alertes en cas de panne. Chose prévu au sein du superviseur Shinken avec l’utilisation de la notion de d’équipement parent / enfant(s) [128].

Figure 91 : Dépendances dans l'architecture de l'opérateur

Nous allons voir dans les sections suivantes comment certaines surveillances ont étés mis en place.

5.1.2 Scénrario 1 : Surveillance de l’hyperviseur VMware ESX5

Dans le cadre d’une migration de ses machines de production, ContactOI à souhaiter optimiser le parc de machines physiques disponibles en y installant l’hyperviseur VMware ESX en version 5. Comme le montre la figure 92 ci-dessous, l’intérêt de technologie réside dans la mutualisation des ressources d’un serveur physique afin d’y faire tourner plusieurs systèmes d’exploitations en parallèle appelés VM (Virtual Machine), nous allons voir dans ce scénario les outils disponibles pour leur surveillance. 5.1.2.1 Objectif

Il est nécessaire de connaitre l’utilisation à l’instant T des ressources de l’hôte (l’hyperviseur ESX) afin de prévenir une saturation, pouvant entrainer la chute des performances ainsi que du fonctionnement de toutes les machines virtualisées présentes sur l’hôte.

93

Figure 92: Hôte Esx et machines virtuelles [129]

OP5 [130], société qui a développé sa propre version de Nagios, est à l’origine d’une série de d’add-ons compatible avec Nagios (et donc Shinken) dont « check_esx » [131]. Il est à l’heure actuelle le projet le plus abouti en termes de stabilité et d’intégration des différentes ressources surveillées par l’add-on. Seul ombre au tableau, les performances, dans le cas de grosses infrastructures, pouvant chuter les performances du faite de la connexion HTTPS / SLL utilisé par « check_esx ». Dans le cas de l’opérateur ContactOI, le parc d’hyperviseur n’étant pour l’instant que de deux machines, aucune baisse de performances ou latences anormales n’a pu être mesurées. L’utilisation d’add-on de Shinken nous a permis d’effectuer à la fois des vérifications d’états et en même temps un export des données de performance vers Graphite. 5.1.2.2 Mise en pratique

La surveillance des hyperviseurs passe par les points de contrôle suivants: • Processeur

o Utilisation (en %). o Nombre de cœurs du processeur utilisés o Température.

• Mémoire Vive o Utilisation (en %).

• Espace disque o Espace restant sur le datacenter (espace de stockage contenant les machines

virtuelles (VM) o Nombre d’opérations (IO) des disques

• Interfaces Réseaux o Débit montant et descendant pour chaque interface. o Taux d’utilisation (en %).

94

La surveillance d’un hyperviseur n’est guère différente par rapport à un serveur classique, la mutualisation des ressources CPU, disques et mémoire nécessite une surveillance accrue, l’hyperviseur étant comme le rappel la figure 92 à la base d’une architecture de virtualisation. 5.1.2.3 Interprétation des données de performance sur Graphite

L’exemple de la figure 93 ci-dessous est un graphique généré grâce à l’add-on « check_esx » décrit dans la section précédente.

Figure 93 : Surveillance d'un hyperviseur ESX sous graphite

L’intérêt évident de ce type de graphique est dans la visualisation immédiate de la ressource arrivant à saturation. Un comportement « pro-actif » permettra se corriger le problème avant la saturation en réallouant les ressources nécessaires. 5.1.2.4 Conclusion

L’add-on «check_esx » se révèle idéal pour la surveillance de l’hyperviseur. Nous verrons dans la section suivante que nous utiliserons une autre méthode pour surveiller les machines virtuelles (et les serveurs physiques) afin d’avoir une homogénéité au sein de l’environnement de supervision.

5.1.3 Scénario 2 : Surveillance des serveurs sous Unix/Linux avec CollectD

Nous allons voir dans cette section une méthode simple et efficace pour la supervision d’un système d’exploitation de type Linux.

95

5.1.3.1 Objectif Afin de conserver une cohérence au sein de la supervision, la solution choisie se devait d’être pleinement compatible avec les outils Shinken et Graphite. Il a donc fallu trouver un démon pouvant communiquer avec au minimum un des deux outils. Le choix s’est porté sur CollectD pour ses capacités d’intégration avec Graphite. Shinken quand à lui jouera un rôle mineur puisque seul les tests d’état de certains services (FTP, DHCP …) lui seront confiés en plus des graphiques générés par CollectD. CollectD[132] est un démon pour environnement Unix/Linux permettant la collecte d’informations de performance. Il va permettre la remonté d’informations des serveurs linux de production utilisés chez ContactOI.

Figure 94 : architecture interne du démon CollectD [132]

Pourquoi CollectD est-il meilleur que d’autre démon de surveillance ? • Écrit en C, il se veut performant, simple à installer et indépendant des librairies que

pourrait nécessiter un démon écrit en Python ou Perl. • Dispose de plus de 90 plug-ins [133] permettant une interaction avec tout le système

d’exploitation, notamment o Le protocole pour onduleur APC o Les serveurs DNS (BIND et autres) o Le CPU, la mémoire les interfaces réseaux et disques durs o Les protocoles de toutes couches (couche IP, couche applicative…) o Les bases de données (MySQL, PostgreSQL, Oracle…) o Les API de programmation (Java, Python…) o D’autres protocoles de surveillance (SNMP, SYSLOG…) o Les systèmes de fichier (SWAP, NFS, ZFS…)

• Des plug-ins pour écrire directement les informations collectées sur Graphite • Une couche réseau évoluée avec les modes Unicast, Multicast, Proxy

96

5.1.3.2 Mise en pratique Dans le cas d’un opérateur Internet comme ContactOI, plusieurs services vitaux tournant sous Unix/Linux nécessitent une surveillance de premier ordre. L’utilisation du démon CollectD va permettre de centraliser la surveillance ainsi que l’export des informations de performance vers Graphite pour en conserver l’historique. Serveur physique :

• Processeur o Utilisation (en %). o Température.

• Mémoire Vive o Utilisation (en %).

• Espace disque o Espace restant par partition systèmes, swap, données… (en Mo).

• Interfaces Réseaux o Débit montant et descendant pour chaque interface. o Taux d’utilisation (en %).

PING inter Serveurs : Afin de surveiller les performances du réseau entre les serveurs, CollectD dispose d’un plugin permettant de générer une série de PING sur une liste d’hôtes demandés. Permet d’avoir une vue locale des performances du réseau et d’ensuite exporter les données (temps de réponse en milliseconde) vers graphite. Service DHCP:

• Remonté des erreurs SYSLOG (type « ERROR ») sur l’attribution des bailles DHCP. L’export vers graphite permet de conserver un historique du nombre d’erreur dans le temps afin de faire un rapprochement « date / nombre d’erreur par jour ».

• Nombre de baux actifs à l’instant T. • Baux disponibles à l’instant T.

Service DNS :

• Remonté des erreurs SYSLOG (type « ERROR ») sur les requêtes du serveur DNS de l’entreprise. Le principe est similaire à celui du service DHCP, conserver un historique des erreurs dans graphite.

Services FTP / SCP / NTP et autres :

• Services utilisés en interne pour la copie de fichier (FTP, SCP) ou pour la synchronisation de l’heure sur chaque serveur (NTP), seul la vérification de l’état du service (fonctionnel / non fonctionnel) est nécessaire, l’export vers graphite peut être activé afin de surveiller les performances.

97

5.1.3.3 Conclusion sur CollectD Ce démon peut être considéré à juste titre comme le plus évolué pour les systèmes Unix/Linux. A l’instar des autres choix pour cette architecture de supervision, il se veut simple à installer [134], performant et polyvalent dans ses fonctions. Le seul point noir à cette solution se situe au niveau de mise à l’écart de Shinken. En effet, les données transitant directement entre l’agent linux et Graphite, aucun contrôle ni gestion d’alarme ne peut être émis depuis Shinken. La nécessité d’un développement tierce comme un connecteur Shinken pour CollectD peut être alors envisageable.

5.1.4 Scénario 3 : Surveillance des serveurs sous Windows avec Perftap ou Shinken

Nous allons voir dans ce scénario que la supervision de serveurs sous Windows diffère quelque peut se ses homologues sous linux.

5.1.4.1 Objectif PerfTap est une implémentation open source sous Windows du démon Linux StatsD[135]. Perftap fut créé pour combler un vide au sein des démons de surveillance pour les environnements Windows. Bien que doté de moins de fonctions que CollectD ou StatsD sous Linux, il dispose des fonctions de base suivantes :

• Écrit en PowerShell V2, un langage de script performant • Développé pour faire un polling temps réel des données de performance vers

Graphite. D’autres démons de surveillance sous Windows comme NSclient++ [136] existent, mais n’ont pas l’approche de simplicité et de performance de Perftap.

• Développé pour être pleinement compatible avec StatsD, il se connecte à celui-ci pour l’envoi de données vers la base. Perfstap n’intègre pas de connecteur vers les bases de données, il se contente d’effectuer la récupération des données de performance (voir figure 95 ci-dessous). Une fois les données transmises au démon StatD, elles seront inscrites dans Carbon (Graphite).

Figure 95 : Communication entre Perftap StatsD et Graphite

98

• Intègre les compteurs de performance suivants : o Systèmes (CPU, mémoire, swap, disques, interfaces réseau) o Environnement .NET (exceptions, threads, utilisation de la pile…) o Environnement ASP.net (requêtes, erreurs, compteur de sessions…) o Environnement SQL Server (utilisation CPU, temps d’accès en base,

mémoire, taille de la base, nombre d’utilisateurs…) • L’ajout de nouveaux compteurs WMI est également possible afin d’intégrer les

produits non Microsoft au démon. 5.1.4.2 Une alternative à PerfTap, le plugin Check_WMI de Shinken.

Il n’est actuellement pas simple de trouver un démon de surveillance performant et si possible gratuit et open source, sous Windows. Perftap[137] peut remplir ce rôle, mais la surveillance plus poussée sous un système d’exploitation Windows peut amener aux limites de PerfTap. Dans ce cas, une utilisation du plugin check_WMI_plus [138] de Shinken est envisageable. WMI (Windows Management Instrument) [139] est une implémentation en environnement Microsoft du standard CIM (Common Information Model) permettant une surveillance et un contrôle des ressources du système d’exploitation similaire au langage SNMP. Des requêtes en lecture/écriture sur les objets WMI permettent de superviser un environnement Microsoft. On peut alors proposer l’architecture suivante, tirant pleinement partie de deux composants de notre supervision :

• Le plugin « check-WMI_plus » permettant le dialogue entre l’environnement Windows et Shinken

• Le broker Graphite_Perfdata (voir section suivante) pour l’export des données de performance vers Graphite.

Figure 96 : WMI une alternative au démon PerfTab

99

L’intégration sous Shinken se fera grâce à l’utilisation de « pack préconfiguré » [140] permettant la surveillance des éléments suivants:

• Etat de l’hôte par un PING • Vérification de l’espace disque • Vérification des services • Charge du CPU • Mémoire vive et swap • Reboot de l’hôte • Présence d’erreurs dans les logs systèmes (SYSLOG) • Présence de sessions RDP (Remote Desktop Protocol) inactives • Utilisation du CPU par les processus

5.1.4.3 Conclusion

La supervision de l’environnement Microsoft Windows et le peu de choix au niveau des démons de surveillance ne laisse pas énormément de solutions en terme d’architecture de surveillance. PerfTap et le plugin Check_WMI sont deux solutions performantes. Seule une mise en production et des tests à long terme peut permettre de faire émerger une solution par rapport à une autre. Le besoin en surveillance variant d’un système à un autre, le choix se fera généralement au cas par cas.

5.1.5 Supervision d’équipement par SNMP, explication du fonctionnement sous

SHINKEN

Afin de comprendre comment les scénarios suivant se basant sur SNMP on put être réalisés, il est nécessaire de présenter le module SNMP Booster permettant les interactions entre le protocole SNMP et Shinken. SNMP Booster est un module récemment développé pour améliorer la performance du protocole SNMP (connu pour ses faibles performances voir chapitre 1) sous Shinken [141]. La figure 97 ci-dessous illustre son fonctionnement :

100

Figure 97 : architecture du module SNMP Booster

1. Le module SNMP Booster de l’arbiter lit les configurations ainsi que les « check »

demandés dans la configuration. Les clés (hôte / OID SNMP du check) sont inscrites dans les base de données Memcached [142], permettant de conserver un lien entre d’un côté la configuration « hôte / service » de Shinken et de l’autre la configuration « hôte / OID SNMP). Memcached est une base de données objet open source permettant de stocker en mémoire vive (RAM) d’un serveur des données objets afin d’améliorer le temps de réponses des requêtes. De nombreux services Web (youtube, facebook, tweeter…) utilisent cette technologie.

2. Le scheduler initie la configuration des checks SNMP et envoie la demande au poller

3. Le module SNMP Booster du poller effectue un SNMP GET_BULK afin de récupérer d’une seule requête les OID nécessaires à la supervision. L’intérêt du GET_BULK est ici de récupérer l’ensemble des « sous OID », allégeant les échanges protocolaires SNMP entre la supervision et l’équipement.

4. Les données de supervision renvoyées par l’équipement au poller sont inscrites en base de données memcached.

5. La mise en cache à l’étape 4 permet dans le cas d’une demande d’information de la part de la supervision, d’optimiser la latence de la requête et d’éviter les goulets d’étranglement de requêtes SNMP massives.

6. Le scheduler peut également forcer une suppression des données en cache afin d’effectuer une mise à jour non prévue, entre les intervalles de vérification pré définis.

Une fois les données SNMP traitées par Shinken, la polyvalence de celui-ci permet d’effectuer un export via un broker (Graphite_Perfdata) des données de performance. Il est ainsi possible de définir dans la configuration deux types de données SNMP :

101

• Les données dites de performance, OID de type jauges ou compteurs, transitant par Shinken puis inscrite dans Graphite (par l’intermédiaires du broker graphite_Perfdata) afin d’y être visualisées sous forme de graphiques.

• Les données d’états, OID de type binaire (on/off) renseignant sur l’état d’un composant (allumé/éteins, activée/non activée…) restant au niveau de la supervision afin d’être affichées dans les tableaux de bord (voir section ShinkenWebUI, une interface utilisateur pour Shinken).

5.1.6 Scénario 4 : Surveillance du backbone Cisco

Nous allons voir dans cette section la solution retenue pour les équipements réseaux de constructeur Cisco.

5.1.6.1 Objectif A l’heure actuelle, seule deux technologies sont pleinement accessible sur les équipements Cisco pour ce qui est de leur surveillance.

• SNMP • Cisco IP SLA [143]

Pour des raisons de simplicité de mise en pratique (comme le montre la section suivante) il nous a été plus simple d’utiliser SNMP grâce à des pack préconfigurés présents dans Shinken [144]. Quand à Cisco IP SLA, il s’agit ni plus ni moins qu’une supervision intégré au firmware Cisco IOS de l’équipement (généralement les routeurs), les informations sont ensuite exportables en SNMP vers un superviseur comme Shinken. La simplicité étant un critère important, cette deuxième solution n’a pas été retenue. 5.1.6.2 Mise en pratique

A l’instar de la surveillance des hôtes Windows, l’utilisation de pack préconfigurés sous Shinken[145] permet la surveillance des équipements réseaux de marque Cisco (ainsi que d’autre constructeurs tels HP, Nortel, Juniper…). Le pack de configuration contient ainsi les OIDS SNMP nécessaires pour surveiller :

• La disponibilité de l’équipement par un PING . • Le taux d’utilisation (en %) de chaque interface et sous interface du routeur, les débits

montants et descendants ainsi que le taux d’erreur. • La charge du CPU de l’équipement. • L’état physique de chaque port (Câble branché ou débranché). • Le taux d’utilisation de la mémoire. • Le nombre d’opérations par seconde (IOPs) sur toutes les interfaces réseaux

confondus. • Les informations et la version de l’IOS Cisco. • La température.

5.1.6.3 Conclusion

L’utilisation du module pour SHINKEN SNMPBooster présenté précédemment, couplé au pack préconfiguré permet une mise en supervision simple et rapide des équipements Cisco du cœur de réseaux de ContactOI. Les informations d’états (Ports, version de l’IOS,

102

disponibilité) seront ainsi visualisable directement depuis l’interface graphique de Shinken (présentée dans la section Shinken WebUI, une interface utilisateur pour Shinken) tandis que les données de performance (taux d’utilisations, charge CPU, Température…) seront exportés vers Graphite.

5.1.7 Scénario 5: Surveillance des liaisons Wimax par SNMP

Nous allons voir dans cette section la démarche effectué pour surveiller la partie Wimax de l’opérateur.

5.1.7.1 Objectif Le réseau de distribution de l’opérateur ContactOi étant basé exclusivement sur la technologie Wimax, une surveillance accrue doit être effectué sur la qualité du signal. Une détérioration importante de celui-ci peut entrainer une chute des débits au niveau des clients. Il est donc nécessaire d’avoir une remonté des données de performance et des informations suivantes :

• La puissance d’émission et de réception de l’antenne (en dB). • Le rapport signal / bruit (SNR) également pour l’émission et la réception. • La modulation effective du signal (QR6, QR8, QR16…) variant en fonction du SNR

et affectant le débit entre la BTS et les CPE.

5.1.7.2 Interrogation SNMP des équipements La figure 98 ci-dessous, détaille la logique utilisée entre la BTS et les CPE. Un CPE est rattaché à la BTS par son adresse MAC , les interrogations SNMP se font exclusivement sur la BTS. Afin de pouvoir différencier les différents CPE, l’adresse MAC est utilisé comme OID SNMP, prenons l’exemple suivant : un CPE ayant l’adresse MAC 10.E7.41.1.20.3C une fois la conversion décimal effectué donnera 16.231.65.132.60. Dans la hiérarchie SNMP la valeur du SNR pour l’upload entre la BTS et un CPE se trouve à l’OID .1.3.6.1.4.1.12394.1.30.300.20.1.1.4.0. En rajoutant à celui-ci la conversion de l’adresse MAC, nous obtenons l’OID complet pour l’interrogation SNMP, à savoir : .1.3.6.1.4.1.12394.1.30.300.20.1.1.4.0.16.231.65.132.60. La MIB complète du constructeur ALVARION est disponible à cette adresse [146].

103

Figure 98 : Interrogation SNMP sur les équipements Alvarion

5.1.7.3 Interprétation des données de performance sur Graphite

La supervision des liaisons Wimax permet de mettre en avant la nécessité de représenter plusieurs données de performances issues d’un équipement afin de croiser celles–ci par la suite. La figure 99 ci-dessous est un graphique généré à partir des requêtes SNMP effectuées sur les OIDS renseignant le SNR montant et descendant (lignes verte et bleu) entre une BTS et un CPE en décibel.

104

La ligne rouge représente la valeur sous lequel le SNR ne doit pas chuter (de manière constante), ou dans quel des cas une baisse de la modulation et donc du débit va apparaitre.

Figure 99 : SNR montant et descendant entre une BTS et un CPE Alvarion

5.1.8 Scénario 6 : Création d’un « smokeping »

Smokeping [147] crée par l’auteur de RRDTools[148] et MRTG[149], il permet de garder un historique de la latence par PING ICMP. La capture ci-dessous permet de comprendre l’intérêt au terme d’informations statistiques d’un tel service.

Figure 100 : Graphique Smokeping [??]

105

5.1.8.1 Objectif L’objectif va être de se rapprocher le plus possible des fonctionnalités de SmokePing en les intégrants à la supervision de ContactOI. La nécessité d’installer / gérer une base de donnée RRDTools en plus du logiciel de métrologie sélectionné (Graphite dans notre cas) est une motivation supplémentaire dans le choix de cette solution de contournement. Avec comme line directrice :

• La génération de N PING simultanées toutes les X secondes. • Des statistiques sur le nombre de paquets perdus (moyenne, min, max) • Le changement de couleur du graphique en fonction du taux de perte. • Des statistiques sur le RTT (Round Time Trip) moyen, minimum et maximum.

La solution consiste à recréer les graphiques générés par Smokeping (voir figure 101) sous Graphite par l’intermédiaire d’un plugin Nagios / Shinken générant plusieurs PING ICMP simultanées nommée « Check_ICMP » [150].

Figure 101 : SmokePing sous Graphite grâce à l’add on Check_ICMP

Seul point négatif, l’impossibilité sous Graphite de changer la couleur du graphique en fonction du taux de perte (Packet Loss). Cette méthode permet une fois de plus de centraliser sur un seul programme la génération des graphiques de performance.

5.1.9 Scénario 7 : Supervision d’une liaison WAN avec nTop

Le dernier scénario de ce chapitre va aborder l’architecture retenue pour surveiller une liaison WAN. Une liaison WAN (ou étendue) se caractérise généralement par ou plusieurs points d’entrés reliant l’Internet au réseau de l’opérateur. Le trafic entrant et sortant est alors englobé sur un seul et même lien physique. L’architecture de surveillance se décompose en 2 parties :

• La technologie permettant de capter le trafic sans interférer la liaison.

106

• La technologie d’analyse du trafic une fois celui-ci capter.

Nous avons vu dans les chapitres précédents que nTop pouvait être utilisé pour surveiller la VoIP (Chapitre 3 Section 1.14) et servir de collecteur de type « flow ». Dans le cas du projet chez ContactOI, nous avons retenus nTop en temps qu’analyseur de trafic derrière un boitier TAP [151] comme le montre la figure 102 ci-dessous.

5.1.9.1 Objectif L’intérêt d’une telle sonde réseau pour un opérateur est de pouvoir mesurer, contrôler et optimiser son trafic réseau tout en y ajoutant la composante surveillance et sécurité offerte par nTop. Une description plus approfondie des fonctionnalités de cette sonde sont disponibles à ces adresses [152] [153] [154]. La surveillance d’un tel lien permet :

• De connaitre le taux d’utilisation du lien et la consommation complète de tous les clients

• D’effectuer une analyse du trafic (ou DPI pour Deep Packet Inspection) afin de connaitre le taux d’utilisation pour chaque protocole / application / utilisateur.

• De prévoir une future saturation du lien et d’en surveiller son fonctionnement.

Figure 102 : boitier TAP et nTOP pour l'analyse d'une liaison WAN

107

Figure 103 : exemple de graphique d'analyse du trafic sous nTop [66]

Quant à l’interface de nTop, celle-ci permet par l’intermédiaire de rapport et de graphiques tel celui de la figure 103 ci-dessus de connaitre l’activité réseau :

• Par couche protocolaire (IP, TCP, UDP, HTTP, FTP, NFS…). • La distribution des paquets reçus par taille. • Le volume de trafic IP Unicast, Multicast. • L’historique des sessions TCP/UDP actives par hôte. • La bande passante utilisée par hôte. • …

5.1.10 Interface utilisateur pour Shinken

Nous avons vu dans les précédentes sections des scénarios de surveillance de divers composants du réseau de l’opérateur ContactOI. Nous allons dans les sections suivantes parler de la composante interface utilisateur permettant l’affichage de ces surveillances. Shinken (à l’instar de Nagios) intègre une interface utilisateur « SHINKEN Web UI » (figure 104). Depuis la version 1.2 sortie en septembre 2012, celle-ci intègre :

• Un moteur de rendu des pages Web en python rapide et performant, aucune nécessité d’avoir un service HTTP sur le serveur Shinken.

• Un dashboard personnalisable avec des widgets

Figure 104 : tableau de bord de Shinken [94]

108

• Une vue business filtrant les incidents par l’importance de l’impact du problème sur le réseau.

• La création automatique d’un graphique de dépendance, chaque service rattaché à un host est représenté sur un graphique dynamique

• Une interface simple et épurée suffisante dans la majorité des cas. Le parti pris d’une

interface simple et claire rend plus performante la lecture des informations (alarmes, problèmes, baisse de performance…) à l’écran.

Figure 106 Shinken WebUI, une interface claire et bien pensée [95]

Figure 105: graphe dynamique de relation service/hôte [95]

109

• Une interface mobile sous Android, permettant d’installer le reactionner Shinken (voir schéma 86) sur un terminal mobile pour ainsi servir de plateforme de visualisation de la supervision.

Figure 107 : Interface Android mobile pour Shinken [94]

De par sa compatibilité avec l’architecture Nagios, il est également possible d’utiliser les interfaces utilisateurs provenant d’autres projets :

• Centreon [101] • Nagios CGI (interface d’origine sur Nagios) [96] • MK_Multisite [155] • Thruk [156] • …

5.1.11 Nagvis, cartographie des réseaux et plans interactifs

Nagvis [157]est un complément indispensable à une interface utilisateur de type dashboard comme ShinkenUI présenté dans la section précédente. Nagvis va permettre deux choses :

110

• Créer des cartes représentatives des installations informatiques supervisées (figure 108) permettant d’avoir:

o Une vision globale des alarmes de manière graphique o Des groupes d’alarmes par groupe services ou par groupe d’hôtes

Figure 108 : Nagvis, cartographie du réseau surveillé [157]

• Une weathermap (figure 109 ci-dessous) permettant d’avoir une vue graphique globale sur le débit et le taux d’utilisation des liens du réseau

Figure 109 : wheatermap sous nagivs [131]

111

5.2 Conclusion du chapitre

Nous avons vu dans ce chapitre l’application de certains concepts énoncés dans les chapitres précédents ainsi que des technologies open source performantes permettant à moindre frais et suivant le modèle du libre partage de créer une architecture de supervision. Une supervision de réseau de télécommunication évolue avec le réseau qu’elle surveille. Dans le cas de ce projet, certains aspects de la supervisions n’ont pas étés abordées par manque de temps ou simplement parce qu’ils n’étaient pas encore d’actualité au sein du projet. On peut par exemple citer la répartition de charge au sein de Shinken [158] ou la surveillance des chemins MPLS grâce à l’utilisation de la technologie Cisco IP SLA [159]. Tous ces aspects permettent d’augmenter le spectre de surveillance d’une architecture de supervision toujours dans le but d’améliorer le comportement proactif de celle-ci.

112

Chapitre 6: Conclusion générale

Dans le chapitre 1, il fut décrit un état de l’art relativement représentatif de l’univers des protocoles de gestion d’équipement ainsi que les dernières recherchent en la matière. Ce chapitre a permis de mettre en évidence le fait qu’il est nécessaire de comprendre que la performance d’un protocole n’est pas tout dans le choix de celui-ci. Les informations décrites dans le chapitre 1 permettent d’extraire plusieurs grandes lignes dans le choix d’une technologie de management :

• Depuis quels réseaux (LAN, WAN..) le protocole permet-il de manager les équipements.

• Quel est l’étendu des fonctionnalités du protocole (gestion software, Hardware, configuration multi utilisateur, granularité de la configuration, gestion de la sécurité de l’accès aux équipements.

• Dans quelle mesure le protocole est adopté dans le monde. Est-ce un protocole à l’état de « draft » géré par un consortium, y a-t-il des implémentations commerciales de celui-ci ?

• Le protocole est-il compatible avec d’autres afin d’augmenter la portée du management des équipements (exemple tr-069 et OSGI).

• La simplicité du langage de modélisation associé au protocole (XML, SMI, YANG…) car un langage performant mais nécessitant un grand temps d’adaptation n’est peut-être pas la meilleur solution à adopter en terme de facilité de management.

Toutes ces questions permettent de choisir parmi un panel de technologie afin d’adapter le choix à l’environnement devant être géré et surveillé. Quant au chapitre 2, celui-ci a permis de mettre en évidence que la surveillance des réseaux IPv6 n’en est encore qu’à ses balbutiements, la faible percée de cette technologie dans les entreprises au profit de la norme IPV4 en est peut-être la raison. Il faudra encore quelques années pour voir apparaitre une méthode performante et plus simple que celles proposées actuellement. Les recherches actuelles, dont une partie est synthétisé au chapitre deux nécessitent encore de murir. Le chapitre 3 a de son côté permis de mettre en lumière certaines recherches effectuées autour des technologies de type flow. Il en ressort que les flows, que ce soit Netflow ou IPFIX nécessite une bonne maitrise de la technologie lors de leurs mises en place, car celle-ci est à la fois performante et gourmande en ressource. Nous pouvons également comparer les flows à des « duplicatas » des données transitant sur les réseaux, les recherchent démontrent ainsi que les applications possibles sont larges, variés et en pleine évolution. Quand au standard IPFIX dérivant de Netflow V9 et totalement compatible avec celui-ci, il se veut être l’avenir des technologies flow grâce à son adoption poussée par l’IETF. Les statistiques provenant des technologies Netflow / IPFIX ne peuvent être considérées comme valables et justes dès le début de leurs implémentations. De nombreux facteurs comme :

• la perte des flows avant leur arrivés au collecteur, • le taux d’échantillonnage,

113

• les sondes et collecteurs utilisés, Nécessitent des étalonnages ainsi que des vérifications préalables à la mise en production. Nous avons pu introduire dans le chapitre quatre les prémisses de ce qu’est une supervision informatique en entreprise. L’explication des deux grands fondements (le superviseur et la métrologie) à permis de mieux cerner l’architecture abordé dans le chapitre 6 et mis en place aux termes des 6 mois d’intervention au sein de l’entreprise ContactOI. Nous avons pu également voir l’importance d’une veille technologique sur les outils existant ainsi que le gap pouvant exister en terme de fonctionnalité entre deux concurrents (Nagios / Shinken ainsi que Cacti / Graphite). Il est nécessaire de retenir qu’une bonne supervision commence par le choix des outils adaptés et non pas forcément ceux données en exemple au chapitre cinq. Pour terminer, nous avons vu dans le chapitre six l’application de certains concepts énoncés dans les chapitres précédents ainsi que des technologies open source performantes permettant à moindre frais et suivant le modèle du libre partage de créer une architecture de supervision. Une supervision de réseau de télécommunication évolue avec le réseau qu’elle surveille. Dans le cas de ce projet, certains aspects de la supervisions n’ont pas étés abordées par manque de temps ou simplement parce qu’ils n’étaient pas encore d’actualité au sein du projet. On peut par exemple citer la répartition de charge au sein de Shinken [158] ou la surveillance des chemins MPLS grâce à l’utilisation de la technologie Cisco IP SLA [159]. Tous ces aspects permettent d’augmenter le spectre de surveillance d’une architecture de supervision toujours dans le but d’améliorer le comportement proactif de celle-ci. Il est intéressant de noter qu’aujourd’hui encore, la supervision d’un réseau de télécommunication ne fait que rarement partie des taches prioritaires au sein d’un service informatique. Rare sont les entreprises ayant pris conscience de l’intérêt d’une démarche pro active sur la surveillance et le bienfondé d’un tel outil. Même si la valeur ajouté d’une solution de supervision est importante, le marché est tel qu’il est difficile à l’heure actuelle d’en connaitre son étendue.

6.1 Retour sur expérience

Les 6 mois passé au sein de l’entreprise Contact OI ont permis d’élaborer ce projet de supervision de bout en bout. Voici comment, et dans l’ordre chronologique, le projet peut être synthétisé.

1. Assimilation de l’existant : Il arrive souvent qu’une supervision soit déjà en place ou au stade embryonnaire. Il faut regarder l’existant, comprendre l’objectif recherché et voir à quelle étape la mise en place c’est arrêtée. Cette étape peut permettre de gagner un temps précieux lors de la mise en place et du paramétrage de la nouvelle supervision puisque certaines configurations existantes peuvent être reprises.

2. Définition des besoins : chercher à savoir quelles sont les attentes en terme de surveillance des réseaux au sein de l’entreprise, quelles sont les technologies utilisées pour la transmission des données et comment sont t’elles misent en place. La

114

définition des besoins permettra de définir le cadre fonctionnel de la nouvelle supervision.

3. État de l’art de l’existant : comme le prouve ce mémoire, la supervision des réseaux de télécommunication est vaste et nul ne peut se vanter de tout connaitre. Une analyse de l’existant (à la manière de ce mémoire) aussi bien du côté des recherches en laboratoire que des technologies du commerce permet, en fonction de la définition des besoins faite précédemment, de faire ressortir plusieurs technologies de supervision susceptible d’être intégré au réseau de télécommunication visé.

4. Mise en place d’un environnement de test : passer d’un état de l’art à la mise en production n’est généralement pas possible. La mise en place de plusieurs environnements de test, en fonction du nombre d’outils présélectionnés dans l’étape précédente, permet de tester, valider et au finale retenir quels outils sera potentiellement utilisable en production. L’idéal étant de disposer d’équipements réseaux identiques à ceux utilisés en production (routeurs, commutateurs, serveurs…) afin de valider leurs interopérabilités avec l’environnement de supervision.

5. Installation et mise en production : cette étape peut être faite de manière progressive. Afin de tester le bon fonctionnement du système, il est préférable de mettre en supervision une catégorie d’équipement (comme par exemple les routeurs) et de vérifier par exemple la bonne remonté des alertes ainsi que la stabilité des outils de surveillance puis affiner si besoin la configuration de la supervision. La mise en surveillance d’un réseau au complet pouvant comporter plusieurs centaines d’équipements peut engendrer une arrivée massive d’informations vers l’utilisateur et cacher par la même occasion un possible disfonctionnement.

6. Surveillance : afin de faire pleinement confiance par la suite à une architecture de supervision, il est nécessaire lors des premiers mois de garder un œil attentif sur son comportement, sa stabilité et sur la véracité des informations remontés. Une supervision mal configuré n’est guère plus utile qu’aucune supervision.

Ces étapes sont assez génériques et ne sont en aucun cas à suivre religieusement mais permettent d’avoir une idée de la démarche à suivre lorsqu’un projet de supervision nait en entreprise.

115

Références

[1] Caardova and C.E.P. Jordainn, “Overview and Comparison of Leading Communication Standard Technologies for Smart Home Area Networks Enabling Energy Management Systems,” presented at the Universities’ Power Engineering Conference (UPEC), Proceedings of 2011 46th International, Soest, Germany, 2011.

[2] “ZigBee Alliance > Home.” [Online]. Available: http://zigbee.org/. [Accessed: 11-Jul-2012].

[3] “IEEE 802.15.4.” . [4] “Home - HomePlug Powerline Alliance.” [Online]. Available:

https://www.homeplug.org/home/. [Accessed: 11-Jul-2012]. [5] H. Rachidi and A. Karmouch, “A framework for self-configuring devices using TR-

069,” 2011, pp. 1–6. [6] A. E. Nikolaidis, S. S. Papastefanos, G. I. Stassinopoulos, M.-P. K. Drakos, and G. A.

Doumenis, “Automating Remote Configuration Mechanisms for Home Devices,” IEEE Transactions on Consumer Electronics, vol. 52, no. 2, pp. 407–413, May 2006.

[7] J. Yu and I. Al Ajarmeh, “An Empirical Study of the NETCONF Protocol,” 2010, pp. 253–258.

[8] J. Postel and J. K. Reynolds, “Telnet Protocol Specification.” [Online]. Available: http://tools.ietf.org/html/rfc854. [Accessed: 11-Jul-2012].

[9] T. Ylonen and C. Lonvick, “The Secure Shell (SSH) Transport Layer Protocol.” [Online]. Available: http://tools.ietf.org/html/rfc4253. [Accessed: 11-Jul-2012].

[10] “SNMP RFC1157.” [Online]. Available: http://www.ietf.org/rfc/rfc1157.txt. [Accessed: 11-Jul-2012].

[11] “SNMP MIB RFC1066.” [Online]. Available: http://tools.ietf.org/rfc/rfc1066.txt. [Accessed: 11-Jul-2012].

[12] U. Blumenthal F. MainoK. McCloghrie, “The Advanced Encryption Standard (AES) Cipher Algorithm in the SNMP User-based Security Model - RFC3826.” [Online]. Available: http://www.ietf.org/rfc/rfc3826.txt. [Accessed: 05-Sep-2012].

[13] J. Schoenwaelder, “overview of the 2002 IAB network management workshop,” 2003. [Online]. Available: http://www.ietf.org/rfc/rfc3535.txt. [Accessed: 11-Jul-2012].

[14] W. Stallings, “SNMPv3: A security enhancement for SNMP,” IEEE Communications Surveys & Tutorials, vol. 1, no. 1, pp. 2–17, 1998.

[15] J. Schonwalder and V. Marinov, “On the Impact of Security Protocols on the Performance of SNMP,” IEEE Transactions on Network and Service Management, vol. 8, no. 1, pp. 52–64, Mar. 2011.

[16] “NETCONF Data Modeling Language (netmod) - Charter.” [Online]. Available: http://datatracker.ietf.org/wg/netmod/charter/. [Accessed: 12-Jul-2012].

[17] “RFC 1831 - RPC: Remote Procedure Call Protocol Specification Version 2.” [Online]. Available: http://tools.ietf.org/html/rfc1831. [Accessed: 12-Jul-2012].

[18] “YANG Data Type RFC6021.” [Online]. Available: http://www.rfc-editor.org/rfc/rfc6021.txt. [Accessed: 12-Jul-2012].

[19] “YANG Central.” [Online]. Available: www.yang-central.org. [Accessed: 12-Jul-2012].

116

[20] L. Liu, D. Xiao, B. Dong, and Q. Shen, “Implementation of the management of SNMP/NETCONF network devices for the next generation NMS,” 2011, pp. 684–687.

[21] “RFC 2578 - Structure of Management Information Version 2 (SMIv2).” [Online]. Available: http://tools.ietf.org/html/rfc2578. [Accessed: 12-Jul-2012].

[22] “UPnP Forum.” [Online]. Available: http://upnp.org/. [Accessed: 12-Jul-2012]. [23] UPnP Forum, “UPnPTM Device Architecture 1.1.” 15-Oct-2008. [24] “upnp-hacks.org.” [25] T. Sales, L. Sales, H. Almeida, and A. Perkusich, “A UPnP extension for enabling user

authentication and authorization in pervasive systems,” Journal of the Brazilian Computer Society, vol. 16, no. 4, pp. 261–277, Oct. 2010.

[26] pdp - gnu citizen, “GNUCITIZEN  » Hacking The Interwebs.” [Online]. Available: http://www.gnucitizen.org/blog/hacking-the-interwebs/. [Accessed: 06-Sep-2012].

[27] “US-CERT Vulnerability Note VU#357851 - UPnP requests accepted over router WAN interfaces.” [Online]. Available: http://www.kb.cert.org/vuls/id/357851. [Accessed: 06-Sep-2012].

[28] Daniel Garcia, “Universal plug and play (UPnP) mapping attacks,” DEFCON 19. [29] Mika Saaranen ( nokia) - UPnp Gateway Chair, “UPnp Gateway committee  : IGD 2

improvement over IGD 1,” http://www.upnp.org/resources/documents/UPnPIGD2vsIGD1d10032009.pdf.

[30] “Broadband Forum - CWMP - Schemas and models definition.” [Online]. Available: http://www.broadband-forum.org/cwmp.php. [Accessed: 12-Jul-2012].

[31] “Broadband Forum - Home.” [Online]. Available: http://www.broadband-forum.org/. [Accessed: 12-Jul-2012].

[32] “RFC 5389 - Session Traversal Utilities for NAT (STUN).” [Online]. Available: http://tools.ietf.org/html/rfc5389. [Accessed: 12-Jul-2012].

[33] DSL Forum, “LAN-side CPE configuration (TR-133),” Tech. rep. 064, mai 2004. [34] B. A. G. Hillen, I. Passchier, B. H. A. van Schoonhoven, and F. T. H. den Hartog,

“Remote Management of Non-TR-069 UPnP End-User Devices in a Private Network,” 2009, pp. 1–2.

[35] N. D. Tung, “A Comparative Study of Data Modeling Languages in Next Generation Network Management,” 2011, pp. 205–207.

[36] “OSGi Alliance | Main / OSGi Alliance.” [Online]. Available: http://www.osgi.org/Main/HomePage. [Accessed: 10-Oct-2012].

[37] “Event-driven Open Service Platform Based Remote Healthcare System.” [38] “TR69 Based Service Interface For OSGI Bundles - Alcatel Lucent.” [Online].

Available: http://www.freepatentsonline.com/y2007/0220093.html. [Accessed: 10-Oct-2012].

[39] Willem Acke (Alcatel Lucent), “OSGi: remote management support for TR-069,” Feb-2007.

[40] “IPv4 Address Report.” [Online]. Available: http://www.potaroo.net/tools/ipv4/index.html. [Accessed: 10-Oct-2012].

[41] “Measurements | World IPv6 Launch.” [Online]. Available: http://www.worldipv6launch.org/measurements/. [Accessed: 16-Jul-2012].

[42] “IPv6 Traffic Monitoring.” [Online]. Available: http://www.labs.lacnic.net/stats/. [Accessed: 10-Oct-2012].

117

[43] “IPv6 – Google.” [Online]. Available: http://www.google.com/ipv6/statistics.html. [Accessed: 10-Oct-2012].

[44] F. Gao and S. Liu, “Design and Implementation of an IPv6-Supported Network Behavior Analysis System,” 2011, pp. 1–3.

[45] M. Gregr, P. Matousek, M. Sveda, and T. Podermanski, “Practical IPv6 monitoring-challenges and techniques,” 2011, pp. 650–653.

[46] “RFC 4941 - Privacy Extensions for Stateless Address Autoconfiguration in IPv6.” [Online]. Available: http://tools.ietf.org/html/rfc4941. [Accessed: 10-Oct-2012].

[47] S. Groat, M. Dunlop, R. Marchany, and J. Tront, “IPv6: Nowhere to Run, Nowhere to Hide,” 2011, pp. 1–10.

[48] “draft-ietf-v6ops-6to4-to-historic-05.” [Online]. Available: https://datatracker.ietf.org/doc/draft-ietf-v6ops-6to4-to-historic/. [Accessed: 11-Oct-2012].

[49] “Teredo Overview.” [Online]. Available: http://technet.microsoft.com/en-us/library/bb457011.aspx. [Accessed: 11-Oct-2012].

[50] “RFC 5214 - Intra-Site Automatic Tunnel Addressing Protocol (ISATAP).” [Online]. Available: http://tools.ietf.org/html/rfc5214. [Accessed: 11-Oct-2012].

[51] M. Aazam, I. Khan, M. Alam, and A. Qayyum, “Comparison of ipv6 tunneled traffic of Teredo and ISATAP over test-bed setup,” 2010, pp. 1–4.

[52] Y. Lee, S. Shin, S. Choi, and H. Son, “IPv6 Anomaly Traffic Monitoring with IPFIX,” 2007, pp. 10–10.

[53] “Identificateurs d’interface IPv6.” [Online]. Available: http://technet.microsoft.com/fr-fr/library/cc736439(v=ws.10).aspx. [Accessed: 10-Oct-2012].

[54] “Cisco IOS NetFlow - Cisco Systems.” [Online]. Available: http://www.cisco.com/en/US/products/ps6601/products_ios_protocol_group_home.html. [Accessed: 11-Oct-2012].

[55] “IP Flow Information Export (ipfix) - Charter.” [Online]. Available: http://datatracker.ietf.org/wg/ipfix/charter/. [Accessed: 11-Oct-2012].

[56] Matěj Grégr, Petr Matoušek, Tomáš Podermański, Miroslav Švéda, “Practical IPv6 Monitoring on Campus - Best Practice Document,” Produced by the CESNET-led Working Group on Network Monitoring (CESNET BPD 132), May 2011.

[57] “Radius, server for remote user authentication and accounting.” . [58] “RFC 2460 - Internet Protocol, Version 6 (IPv6) Specification.” [Online]. Available:

http://tools.ietf.org/html/rfc2460. [Accessed: 16-Jul-2012]. [59] L. Shi, A. Davy, D. Muldowney, S. Davy, E. Hofig, and Xiaoming Fu, “Intrinsic

monitoring within an IPv6 network: mapping node information to network paths,” 2010, pp. 370–373.

[60] Prost Pierrick, Allaoui Yassir, Mouoyebe Lavoisier, “Monitoring des flux temps réels dans un réseau hétérogène,” Ecole de Technologie supérieur de Montréal (ETS), Projet de cours MGR 820, 2011.

[61] Wikipedia contributors, “NetFlow,” Wikipedia, the free encyclopedia. Wikimedia Foundation, Inc., 13-Sep-2012.

[62] “NetFlow v9 Export Format,” Cisco. [Online]. Available: http://www.cisco.com/en/US/docs/ios/12_3/feature/gde/nfv9expf.html. [Accessed: 18-Sep-2012].

118

[63] “NetFlow Performance Analysis  [Netflow],” Cisco. [Online]. Available: http://www.cisco.com/en/US/technologies/tk543/tk812/technologies_white_paper0900aecd802a0eb9.html. [Accessed: 18-Sep-2012].

[64] Z. Weiwei, G. Jian, G. Wenjie, and C. Shaomin, “NetFlow-based network traffic monitoring,” 2011, pp. 1–4.

[65] Deri, IIT, chou, Cherian, Karmarkar, and Patterson, “Increasing data center network visibility with cisco NetFlow-Lite,” presented at the Network and Service Management (CNSM), 2011 7th International Conference on, Paris, 2011.

[66] “ntop.” [Online]. Available: http://www.ntop.org/. [Accessed: 11-Oct-2012]. [67] “Plixer - Network Traffic Monitoring and Analysis.” [Online]. Available:

http://www.plixer.com/. [Accessed: 11-Oct-2012]. [68] “Scrutinizer  : Network traffic monitoring and analysis with NetFlow and sFlow.”

[Online]. Available: http://www.plixer.com/Scrutinizer-Netflow-Sflow/scrutinizer-flow-analyzer.html. [Accessed: 11-Oct-2012].

[69] Elie Chou (Cisco Product Manager), Luca Deri (Ntop Software developer) and Michael Patterson (Scrutinize Product Manager), “Cisco Netflow-Lite  : Enabling traffic monitoring at data center acces,” May-2011.

[70] “Le marché de la VoIP/ToIP doublé en 2015 | Silicon.” [Online]. Available: http://www.silicon.fr/le-marche-de-la-voiptoip-double-en-2015-54171.html. [Accessed: 27-Sep-2012].

[71] DIMITRIS GENEIATAKIS , TASOS DAGIUKLAS, G EORGIOS KAMBOURAKIS , COSTASLAMBRINOUDAKIS , ANDSTEF ANOS GRITZALIS, U NIVERSITYOF THE AEGEAN, KARLOVASSI SVENEHLERT AND DORGHAM SISALEM , FRAUNHOFER FOKUS I NSTITUTE, “SURVEY OFSECURITY VULNERABILITIES I SESSION INITIATIONPROTOCOL,” EEE Communications Surveys & Tutorials • 3rd Quarter 2006.

[72] Chang-Yong Lee, Hwan-Kuk Kim, Kyoung-Hee Ko, Jeong-Wook Kim, Hyun-Cheol Jeong, “A VoiP Traffic Monitoring System based on NetFlow v9,” International Journal of Advanced Science and Technology 04/2009; 4., Mar. 2009.

[73] H. Son and Y. Lee, “Detecting Anomaly Traffic using Flow Data in the real VoIP network,” 2010, pp. 253–256.

[74] “H.323 : Packet-based multimedia communications systems.” [Online]. Available: http://www.itu.int/rec/T-REC-H.323/. [Accessed: 12-Oct-2012].

[75] “RFC 3525 - MEGACO.” [Online]. Available: http://tools.ietf.org/html/rfc3525. [Accessed: 12-Oct-2012].

[76] “draft-trammell-ipfix-sip-msg-02 - SIP Message Information Export using IPFIX.” [Online]. Available: http://tools.ietf.org/html/draft-trammell-ipfix-sip-msg-02. [Accessed: 28-Sep-2012].

[77] “DRAFT RTP Stream Quality Information Export using IPFIX,” 09-Jul-2012. [Online]. Available: https://tools.ietf.org/id/draft-scholz-ipfix-rtp-audio-quality-00.txt. [Accessed: 28-Sep-2012].

[78] “IP Flow Information Export (ipfix) - Documents.” [Online]. Available: http://datatracker.ietf.org/wg/ipfix/. [Accessed: 28-Sep-2012].

[79] Luca Deri, “Open Source VoIP Traffic Monitoring.”

119

[80] Sven Anderson, “SIPFIX Using IPFIX for VoIP monitoring,” Institute of Computer Science University of Göttingen, Oct-2008.

[81] Sven Ehlerta, , Dimitris Geneiatakisb, Thomas Magedanza, ,, “Survey of network security systems to counter SIP-based denial-of-service attacks,” Computers & Security, vol. Volume 29, Issue 2, March 2010, Pages 225–243.

[82] Dimitris Geneiatakis, , Nikos Vrakas , Costas Lambrinoudakis, “Utilizing bloom filters for detecting flooding attacks against SIP based services,” Computers & Security, vol. Volume 28, Issue 7, October 2009, Pages 578–591.

[83] H. Sengar, Haining Wang, D. Wijesekera, and S. Jajodia, “Detecting VoIP Floods Using the Hellinger Distance,” IEEE Transactions on Parallel and Distributed Systems, vol. 19, no. 6, pp. 794–805, Jun. 2008.

[84] H. Sengar, D. Wijesekera, Haining Wang, and S. Jajodia, “VoIP Intrusion Detection Through Interacting Protocol State Machines,” pp. 393–402.

[85] Y. Ding and G. Su, “Intrusion detection system for signal based SIP attacks through timed HCPN,” 2007, pp. 190–197.

[86] Hyeongu Son, Youngseok Lee, “An Anomaly Traffic Detection Method for VoIP Applications using Flow Data.”

[87] F. Ricciato, F. Strohmeier, P. Dorfinger, and A. Coluccia, “One-way loss measurements from IPFIX records,” 2011, pp. 158–163.

[88] J. Kogel, “One-way delay measurement based on flow data: Quantification and compensation of errors by exporter profiling,” 2011, pp. 25–30.

[89] Ales Friedl, Sven Ubik, Alexandros Kapravelos, Michalis Polychronakis, Evangelos P. Markatos, “Realistic passive packet loss measurement for high-speed networks,” presented at the 1st Traffic Monitoring and Analysis Workshop (TMA), Aachen, Germany, 2009.

[90] “YAF.” [Online]. Available: http://tools.netsa.cert.org/yaf/. [Accessed: 12-Oct-2012]. [91] “Harpoon: Harpoon: A Flow-level Traffic Generator.” [Online]. Available:

http://cs.colgate.edu/~jsommers/harpoon/. [Accessed: 12-Oct-2012]. [92] “..:: D-ITG, Distributed Internet Traffic Generator  ::..” [Online]. Available:

http://www.grid.unina.it/software/ITG/. [Accessed: 12-Oct-2012]. [93] NMAP - Security Scanner. . [94] “Supervision, monitoring, métrologie | Communauté Francophone de la Supervision

Libre.” [Online]. Available: http://www.monitoring-fr.org/. [Accessed: 19-Oct-2012]. [95] “Shinken.” [Online]. Available: http://www.shinken-monitoring.org/. [96] “Nagios.” [Online]. Available: http://www.nagios.com/. [97] “Nagios Exchange - The official site for Nagios projects of all kinds - Nagios plugins,

addons, documentation, extension, and more.” [Online]. Available: http://exchange.nagios.org/. [Accessed: 14-Nov-2012].

[98] “Nagios - Nagios Features.” [Online]. Available: http://www.nagios.org/about/features. [Accessed: 29-Dec-2012].

[99] “Nagios - Nagios Core.” [Online]. Available: http://www.nagios.com/products/nagioscore. [Accessed: 14-Nov-2012].

[100] “Nagios - Nagios XI.” [Online]. Available: http://www.nagios.com/products/nagiosxi. [Accessed: 14-Nov-2012].

120

[101] “Home Centreon.” [Online]. Available: http://www.centreon.com/. [Accessed: 14-Nov-2012].

[102] “Home - Icinga: Open Source Monitoring.” [Online]. Available: https://www.icinga.org/. [Accessed: 14-Nov-2012].

[103] “Project | Shinken.” [Online]. Available: http://www.shinken-monitoring.org/project/. [Accessed: 29-Dec-2012].

[104] “Python Programming Language – Official Website.” [Online]. Available: http://www.python.org/. [Accessed: 14-Nov-2012].

[105] “PYRO - Python Remote Objects.” [Online]. Available: http://packages.python.org/Pyro/. [Accessed: 14-Nov-2012].

[106] “MySQL  :: La Base de Données Open Source la plus Populaire au Monde.” [Online]. Available: http://www.mysql.fr/. [Accessed: 14-Nov-2012].

[107] “GLPI - Gestionnaire libre de parc informatique.” [Online]. Available: http://www.glpi-project.org/. [Accessed: 14-Nov-2012].

[108] “Landscape | Canonical.” [Online]. Available: http://www.canonical.com/enterprise-services/ubuntu-advantage/landscape. [Accessed: 14-Nov-2012].

[109] “Shinken 1.2 is out | Shinken.” [Online]. Available: http://www.shinken-monitoring.org/news/shinken-1-2-is-out/. [Accessed: 14-Nov-2012].

[110] “vmware_arbiter_module [Shinken].” [Online]. Available: http://www.shinken-monitoring.org/wiki/vmware_arbiter_module]. [Accessed: 14-Nov-2012].

[111] “setup_nrpe_booster_module [Shinken].” [Online]. Available: http://www.shinken-monitoring.org/wiki/setup_nrpe_booster_module. [Accessed: 14-Nov-2012].

[112] “the_broker_modules [Shinken].” [Online]. Available: http://www.shinken-monitoring.org/wiki/the_broker_modules?s[]=perfdata. [Accessed: 14-Nov-2012].

[113] “Cacti® - The Complete RRDTool-based Graphing Solution.” [Online]. Available: http://www.cacti.net/. [Accessed: 14-Nov-2012].

[114] “Graphite  : Scalable Realtime Graphing.” [Online]. Available: http://graphite.wikidot.com/.

[115] “Passive Checks.” [Online]. Available: http://nagios.sourceforge.net/docs/3_0/passivechecks.html. [Accessed: 14-Nov-2012].

[116] “ws_daemon_module [Shinken].” [Online]. Available: http://www.shinken-monitoring.org/wiki/ws_daemon_module. [Accessed: 14-Nov-2012].

[117] “shinken_10min_start [Shinken].” [Online]. Available: http://www.shinken-monitoring.org/wiki/shinken_10min_start. [Accessed: 14-Nov-2012].

[118] “RRD Tools - Documentation.” [Online]. Available: http://oss.oetiker.ch/rrdtool/doc/rrdtool.en.html.

[119] “rrdtool Round Robin Database Howto.” generationIP.com. [120] “Graphite - Carbon cache agent.” [Online]. Available:

http://graphite.wikidot.com/carbon. [121] “Graphite - Whisper Database.” [Online]. Available:

http://graphite.wikidot.com/whisper. [122] “Django  : the web framework for perfectionists with deadlines.” [Online]. Available:

https://www.djangoproject.com/. [123] “ContactOI Réunion.” .

121

[124] “WIMAX Forum.” [Online]. Available: http://www.wimaxforum.org/. [Accessed: 30-Dec-2012].

[125] “L’actualité de l’ARCEP.” [Online]. Available: http://www.arcep.fr/. [Accessed: 30-Dec-2012].

[126] “Centre d’information VMware ESXi et VMware ESX : migration vers l’hyperviseur VMware ESXi.” [Online]. Available: http://www.vmware.com/fr/products/datacenter-virtualization/vsphere/esxi-and-esx/overview.html. [Accessed: 30-Dec-2012].

[127] “Alvarion/Wireless Connectivity, Coverage and Capacity - Alvarion.” [Online]. Available: http://www.alvarion.com/. [Accessed: 30-Dec-2012].

[128] “Setup Network and logical dependencies in Shinken.” . [129] “Vmware - Virtualization Software for Desktops, Servers.” . [130] “OP5 Open Source Network Monitoring.” . [131] “Monitoring VMware ESX 3.x, ESXi, vSphere 4 and vCenter Server.” [Online].

Available: http://www.op5.com/how-to/monitoring-vmware-esx-3-x-esxi-vsphere-4-and-vcenter-server/. [Accessed: 30-Dec-2012].

[132] “Start page – collectd – The system statistics collection daemon.” [Online]. Available: http://collectd.org/. [Accessed: 15-Nov-2012].

[133] “Table of Plugins - collectd Wiki.” [Online]. Available: https://collectd.org/wiki/index.php/Table_of_Plugins. [Accessed: 15-Nov-2012].

[134] “First steps - collectd Wiki.” [Online]. Available: https://collectd.org/wiki/index.php/First_steps. [Accessed: 15-Nov-2012].

[135] “StatsD - Simple daemon for easy stats aggregation.” [Online]. Available: https://github.com/etsy/statsd.

[136] “NsClient++ - Monitoring deamon for windows.” [Online]. Available: http://www.nsclient.org/nscp/.

[137] “EastPoint/PerfTap · GitHub.” [Online]. Available: https://github.com/EastPoint/PerfTap. [Accessed: 30-Dec-2012].

[138] “Check WMI plus  : Check plugin for Windows Server on Nagios monitoring server.” [Online]. Available: http://www.edcint.co.nz/checkwmiplus/.

[139] “Windows Management Instrumentation (Windows).” [Online]. Available: http://msdn.microsoft.com/en-us/library/windows/desktop/aa394582(v=vs.85).aspx. [Accessed: 15-Nov-2012].

[140] “packs:windows [Shinken].” [Online]. Available: http://www.shinken-monitoring.org/wiki/packs/windows?s[]=wmi#setup_the_check_wmi_plus_plugin. [Accessed: 15-Nov-2012].

[141] “setup_snmp_booster_module [Shinken].” [Online]. Available: http://www.shinken-monitoring.org/wiki/setup_snmp_booster_module. [Accessed: 15-Nov-2012].

[142] “memcached - a distributed memory object caching system.” [Online]. Available: http://memcached.org/. [Accessed: 15-Nov-2012].

[143] “Cisco IP Service Level Agreements (SLA).” . [144] “Shinken - Monitoring Network Devices.” . [145] “packs:router_or_switch [Shinken].” [Online]. Available: http://www.shinken-

monitoring.org/wiki/packs/router_or_switch?s[]=cisco. [Accessed: 29-Dec-2012].

122

[146] “ipMonitor  :: ALVARION-DOT11-WLAN-MIB: Alvarion BreezeAccessVL.” [Online]. Available: http://support.ipmonitor.com/mibs/ALVARION-DOT11-WLAN-MIB/info.aspx. [Accessed: 29-Dec-2012].

[147] Tobias Oetiker, SmokePing. . [148] “RRD Tools.” [Online]. Available: http://oss.oetiker.ch/rrdtool/. [149] Tobi Oetiker, MRTG. . [150] “check_icmp | Nagios Plugins.” [Online]. Available:

http://nagiosplugins.org/man/check_icmp. [Accessed: 06-Jan-2013]. [151] “Network tap - Wikipedia, the free encyclopedia.” [Online]. Available:

http://en.wikipedia.org/wiki/Network_tap. [Accessed: 11-Jan-2013]. [152] “Ntop [wiki monitoring-fr.org].” [Online]. Available: http://wiki.monitoring-

fr.org/supervision/ntop/start. [Accessed: 11-Jan-2013]. [153] “Présentation de la sonde nTop - Telecom Lille 1.” [Online]. Available:

http://wapiti.telecom-lille1.eu/commun/ens/peda/options/ST/RIO/pub/exposes/exposesrio2007/ATAROFF-COLLIEZ/index.html. [Accessed: 11-Jan-2013].

[154] “nTop official Documentation.” [Online]. Available: http://www.ntop.org/support/documentation/. [Accessed: 11-Jan-2013].

[155] “Multisite.” [Online]. Available: http://mathias-kettner.de/checkmk_multisite.html. [Accessed: 15-Nov-2012].

[156] “Thruk Monitoring Webinterface.” [Online]. Available: http://www.thruk.org/. [Accessed: 15-Nov-2012].

[157] “Nagvis Weathermap.” [Online]. Available: http://www.nagvis.org/. [158] “scaling_shinken [Shinken].” [Online]. Available: http://www.shinken-

monitoring.org/wiki/scaling_shinken. [Accessed: 30-Dec-2012]. [159] “Cisco IOS IP Service Level Agreements User Guide [Cisco IOS IP Service Level

Agreements (SLAs)] - Cisco Systems.” [Online]. Available: http://www.cisco.com/en/US/technologies/tk648/tk362/tk920/technologies_white_paper09186a00802d5efe_ps6602_Products_White_Paper.html. [Accessed: 30-Dec-2012].