Installation et configuration du logiciel PRTG Network Monitor

DIPLOME d’INGENIEUR
SPECIALITE : INFORMATIQUE
OPTION : RESEAUX, SYSTEMES ET MULTIMEDIA

La supervision de réseau

La gestion de réseau avec SNMP

Historique du protocole SNMP

Pour répondre aux difficultés de surveillance et de maintien des réseaux informatiques, un protocole d’administration, intitulé SNMPv1 (Simple Network Management Protocol) a été finalisé en 1990. Ce protocole permet de modifier la configuration des équipements, de détecter et d’analyser les problèmes du réseau par interrogation ou remontée d’alarmes, de surveiller ses performances et de réaliser des statistiques.
Dans cette première version, le protocole est défini par un standard IETF (Internet Engineering Task Force) intitulé RFC (Request For Comments) 1157 « A Simple Network Management Protocol (SNMP) » datant de mai 1990. Le but de cette architecture est de faciliter son utilisation, d’être suffisamment extensible pour être compatible dans le futur et qu’elle soit indépendante de l’architecture et des mécanismes des hôtes ou serveurs particuliers. (IETF, 1990)
La sécurité de SNMPv1 est basée sur des noms de communautés qui sont utilisés comme des mots de passe pour accéder à une arborescence de données de l’équipement appelée MIB (Management Information Base). Le nom de la communauté est transmis en clair dans le message SNMP.
La première version n’étant pas sécurisée, le protocole SNMP a ainsi évolué en une deuxième version finalisée en janvier 1996, intitulée SNMPv2C (RFC 1901 à 1908). La sécurité de cette version est encore faible car elle s’appuie sur le modèle de SNMPv1 en réutilisant les noms de communauté, d’où la lettre C de SNMPv2C. Cependant, elle comble des lacunes de la version 1, en particulier au niveau de la définition des objets, du traitement des notifications et du protocole lui-même.
Une troisième version finale, intitulé SNMPv3, a été approuvée comme projet de norme en avril 1999. Elle est devenue un standard en décembre 2002 (RFC 3410 à 3418). Elle a pour but principal d’assurer la sécurité des échanges.

L’architecture SNMP

La technologie SNMP s’appuie sur le modèle OSI (Open System Interconnection). Ce modèle de communication mis en place par l’Organisation internationale de normalisation (ISO : International Organization for Standardization) comporte 7 couches (1 = Physique, 2 = Liaison Données, 3 = Réseau, 4 = Transport, 5 = Session, 6 = Présentation et 7 = Application). Le rôle du modèle OSI, décrit dans lanorme ISO 7498-1, est de standardiser la communication entre les machines.
SNMP est un protocole situé entre la couche 4 et lacouche 7 de ce modèle OSI. Il s’appuie sur le protocole de télécommunication UDP (User Datagram Protocol). Le paquet UDP est encapsulé dans un paquet IP (Internet Protocol). UDP est plus simple à utiliser que TCP (Transmission Control Protocol) car il fonctionne en mode non connecté. Le mode non connecté n’oblige pas les deux entités à établir une connexion entre elles avant de transférer des données puis de mettre fin à leur connexion. Enrevanche, UDP ne permet pas de savoir si les datagrammes sont bien arrivés et s’ils sont arrivés dans un ordre différent de celui d’émission.
Cette architecture SNMP fonctionne sur un modèle client-serveur. Le client correspond à la station de gestion de réseau, souvent appelée Manager ou encore Network Management Station (NMS) par certains éditeurs. Les serveurs correspondent aux agents SNMP qui enregistrent en permanence des informations les concernant dans leur MIB. La station interroge les MIB des différents agents pour récupérer les informations qu’elle souhaite.

La MIB

La MIB est une base d’informations de gestion. Elle comprend des informations à consulter, des paramètres à modifier, ainsi que des alarmes à émettre. La MIB est structurée sous une forme arborescente. Chaque objet de la MIB est identifié par un nom et un OID. Le chemin suivi pour aller de la racine à l’objet constitue l’OID de celui-ci. Les OIDs permettent de parcourir la MIB jusqu’à atteindre la variable souhaitée pour en lire ou modifier les attributs.
Ce sont des identifiants universels permettant d’assurer l’interopérabilité entre différents logiciels indépendamment du matériel.
Les objets administrés (aussi bien les objets de type scalaire que tabulaire) sont composés d’une ou plusieurs instances d’objets, lesquelles sont essentiellement des variables. Les objets scalaires définissent une seule instance d’objets alors que les objets tabulaires définissent plusieurs instances liées d’objets, et celles-ci sont regroupées dans des tables MIB. Chaque niveau de l’arborescence est repéré par un index numérique.

L’agent SNMP

Pour être supervisé, chaque équipement doit comporter un agent SNMP. Le but étant de remonter les informations de la MIB au Manager. L’implantation des agents n’étant pas standardisée, ils peuvent ainsi être intégrés dans les équipements sous la forme d’un firmware, dans l’OS (Operating System) ou dans un programme additionnel. L’agent nécessite des ressources en processeur et en mémoire. Il reste à l’écoute d’éventuelles requêtes sur le port UDP 161. Il répondra aux requêtes reçues uniquement si le demandeur a les droits nécessaires correspondant à sa demande. L’agent peut fournir des informations à un ou plusieurs Managers.
De plus, l’agent SNMP peut également être paramétré pour émettre des alertes concernant des points critiques de l’équipement, comme la surchauffe de l’équipement, sans avoir auparavant reçu une requête du Manager.

La station de gestion de réseau

Le Manager contient le protocole de communication ainsi que les applications de gestion. Il se compose d’une console, d’une base de données représentant tous les périphériques gérés du réseau et de toutes les variables MIB des équipements du réseau. Elle permet de récupérer et d‘analyser les données relatives aux différents équipements reliés au réseau et de les gérer. Le Manager peut ensuite interpréter ces informations pour faire des rapports d’incidents. Le Manager envoie des requêtes aux agents sur le port UDP 161 et reste à l’écoute d’éventuels messages d’alarme, appelés traps, envoyés sur le port UDP 162 par un agent SNMP.

La communauté SNMP

La communauté SNMP est utilisée dans les échanges entre le Manager et l’agent SNMP. Elle définit à la fois l’authentification et le contrôle d’accès. L’agent peut être configuré de trois façons : lecture-seule, lecture-écriture et trap. Le nom de communauté est utilisé comme un mot de passe pour accéder aux informations de la MIB de l’équipement. Il peut y avoir autant de communautés que d’agents. Vice versa, un agent peut avoir une communauté par Manager.
Le paramétrage de la communauté en lecture-seule permet au Manager de lire ces informations mais ne permet pas de modifier certaines valeurs. Le nom de la communauté par défaut est « public ». Le mode lecture-écriture permettra de modifier des valeurs dans la MIB de l’équipement sans avoir à s’y connecter. Le nom de la communauté par défaut est « private ». Cela permet par exemple de remettre facilement des compteurs à zéro. Enfin, le mode trap permet l’envoi d’alertes uniquement de l’agent vers le Manager.

Les requêtes

SNMPv3 utilise les mêmes requêtes que SNMPv2 et SNMPv1.
On retrouve donc GetRequest, GetNextRequest, GetBulk, Response, SetRequest, Inform, SNMPV2-Trap.

User-based Security Model

USM intègre trois mécanismes afin de contrer différents types d’attaques. Le premier est un mécanisme d’authentification permettant d’assurer la non modification d’un paquet SNMPv3 lors de sa transmission et de vérifier la validité du mot de passe de l’expéditeur de la requête.
Le deuxième est un mécanisme de chiffrement. Il permet d’empêcher la lecture des informations de gestion d’un paquet SNMPv3. Enfin, le troisième est un mécanisme d’horodatage empêchant la réémission d’un paquet SNMPv3 déjà envoyé.

Authentification

La phase d’authentification de l’information a pour but d’empêcher la modification du contenu du paquet sans connaître un mot de passe connu seulement par l’émetteur et le receveur du paquet. L’authentification n’a pas pour rôle d’empêcher l’envoi de données en clair sur le réseau malgré le fait qu’elle s’appuie sur un algorithme de hachage cryptographique, comme MD5 (Message Digest 5) ou SHA-1 (Secure Hash Algorithm 1).
Elle permet de vérifier que l’émetteur du paquet est bien celui prévu grâce à cet algorithme de hachage. Prenons comme exemple le mécanisme d’authentification avec l‘algorithme de hachage cryptographique MD5. MD5 travaille avec un message de taille variable et produit une séquence de 128 bits ou 32 caractères en notation hexadécimale.

Chiffrement

Afin que les données ne soient pas envoyées en clair sur le réseau, un mécanisme de chiffrement, basé sur un mot de passe connu du Manager et de l’agent SNMP, est alors utilisé. SNMPv3 utilise deux mots de passe afin d’augmenter la sécurité des échanges. Le premier est utilisé dans la phase d’authentification décrite précédemment et le deuxième est utilisé dans cette phase de chiffrement.
SNMPv3 s’appuie sur l’algorithme de chiffrement parbloc DES (Data Encryption Standard) de 64 bits (8 octets) pour le chiffrement des paquets. Le principe est de chiffrer les données (Data) par blocs de 64 bits en entrée avec un bloc de 64 bits contenant une clé (Key) et d’obtenir en sortie les données chiffrées (Coded) par blocs de 64 bits. L’algorithme effectue des combinaisons, des substitutions et des permutations entre les données à chiffrer et la clé.
Les étapes de permutation et de substitution, appelés rondes, sont répétées 16 fois. Pour déchiffrer, il suffit de soumettre les blocs de données chiffrées avec la clé de chiffrement de 56 bits à l’algorithme DES pour obtenir les données déchiffrées.

Analyse et conception de la plateforme

L’objectif est de superviser l’infrastructure informatique de toute la clinique, afin d’être avertis lorsqu’un équipement réseau, un serveur ou même un service précis d’un serveur ne fonctionne plus. Cela permet de réagir plus vite pour rétablir son fonctionnement. Une alerte pourra également être envoyée lorsqu’un seuil défini comme critique est atteint.

Choix du logiciel de supervision

Le logiciel de supervision ne doit pas excéder 1 000 €. L’environnement à superviser comprend 20 serveurs et 25 équipements. Il faut que la solution puisse être évolutive. Nous pouvions envisager plusieurs logiciels open source ou certains logiciels propriétaires.

Logiciels open source

Nagios

Nagios est un logiciel open source de supervision. Il permet de surveiller aussi bien les réseaux que les systèmes. Il peut, par exemple, suivre l’évolution d’une charge processeur, le fonctionnement d’un service précis ainsi que la bande passante internet. Une fois une anomalie détectée il est capable d’alerter d’un dysfonctionnement.
Nagios est composé d’un moteur d’application (permettant d’organiser les tâches de supervision), d’une interface web (permettant de visualiser l’état du fonctionnement du système d’information) et de plugins (permettant d’ajouter de nouvelles fonctionnalités au logiciel). Ces plugins peuvent être écrits dans de nombreux types de langages.
Ce logiciel a l’avantage de pouvoir superviser tous les types de ressources et de services grâce à des centaines de plugins. Nagios est bien adapté aux systèmes d’information de taille moyenne et aussi de taille importante. Nagios a comme défaut d’être difficile à administrer et de ne fonctionner que sous Linux ou une variante Unix.
Afin de simplifier son implantation au sein des entreprises, Nagios Enterprises a lancé une version payante, appelée Nagios XI. Ainsi, Nagios Enterprises propose donc une version communautaire gratuite appelée Nagios Core et cette version payante. Nagios XI s’appuie sur le moteur Nagios Core mais inclut une nouvelle interface de gestion plus simple à mettre en place. Cette version payante permet de configurer les sondes directement depuis l’interface web alors que la version gratuite conserve sa méthode de paramétrage consistant à modifier des fichiers en lignes de commandes. Le prix varie en fonction du nombre d’hôtes à superviser. Nagios XI coûte pour 1 à 50 hôtes 1 295$, pour 51 à 100 hôtes 1 995 $ et est illimité en nombre d’hôtes pour 2 495 $.

Cacti

Cacti est un logiciel libre ayant pour but principal de mesurer les performances du réseau. Il permet de réaliser principalement des graphiques et de faire des statistiques grâce à ces graphiques. Il fonctionne grâce à un serveur web et une base de données. Il est possible d’ajouter des plugins afin de lui apporter des services supplémentaires. Cacti est gratuit. Il fonctionne aussi bien sous Unix que Windows. Il peut déclencher des alertes par mail en cas de dépassement de certains seuils d’alerte par l’ajout d’un plugin appelé Thold.

Logiciels propriétaires

Trois solutions ont été étudiées afin de connaître ce qui était proposé sur le marché, sans tenir sans tenir compte a priori des contraintes budgétaires.

HP – OpenView

OpenView est un ensemble de modules permettant la supervision des infrastructures informatiques. Chaque module a sa spécificité et possède un coût élevé. Seuls les trois modules ci-dessous correspondent aux besoins.
Le module OpenView Network Node Manager est un logiciel permettant d’avoir une représentation cartographique d’un réseau selon la typologie des équipements. Les alertes sont ainsi visibles par un code couleur. A partir d’une alarme, il est possible de zoomer sur la partie du réseau en dérangement afin de mieux comprendre la panne pour intervenir plus efficacement. Les alertes peuvent également être envoyées par mail. Network Node Manager Starter Edition 250 nœuds coûte 8 300 € HT. La version Starter Edition illimitée en nombre de nœuds coûte 49 000 € HT. La version la plus élevée, intitulée Advanced Edition illimitée coûte 208 000 € HT. Ce logiciel fonctionne aussi bien sous Windows que Linux ainsi que d’autres systèmes d’exploitation.

Choix de la plateforme

Le logiciel PRTG ayant été choisi, ses prérequis doivent être pris en compte, notamment le fait qu’il ne fonctionne que sur une plateforme Windows (PC, serveur ou machine virtuelle). Trois possibilités existent.
La première possibilité consiste à installer le logiciel sur un PC. Cette solution engendre un problème de performance à moyen et long terme, dû à une accumulation de données et de sauvegarde, d’autant plus qu’il n’est pas prévu de licence pour la sauvegarde de ce PC. Cette solution n’est donc pas envisageable.
La deuxième possibilité est d’installer le logiciel sur un serveur physique. Les performances du serveur étant bien supérieurs à celles d’un PC, il n’y a aucun risque de rencontrer des problèmes de lenteur. Cependant, le problème de sauvegarde persiste car aucune licence n’est prévue pour ce serveur. Il faut donc en acquérir une. Pour des raisons de budget cette solution n’est pas non plus envisagée.
Enfin, la troisième possibilité consiste à installer PRTG sur une machine virtuelle positionnée sur dans la nouvelle infrastructure de virtualisation. Cette solution répond aux attentes car elle évite les problèmes de performance et de sauvegarde.
La clinique a donc décidé d’installer le logiciel PRTG dans la nouvelle infrastructure de virtualisation sur une machine virtuelle sous Windows Server 2003, afin de pouvoir ajouter d’autres fonctionnalités que la simple supervision du réseau. Cette machine virtuelle pourra être sauvegardée grâce au logiciel VMware Data Recovery sans aucun coût supplémentaire.

Table des matières

Introduction 
1 Contexte du projet 
1.1 Environnement Technique
1.2 Objectifs
1.3 Cahier des charges
2 La supervision de réseau 
2.1 La gestion de réseau avec SNMP
2.2 Autres méthodes de gestion de réseau
2.3 Fonctionnement des remontées d’alertes
3 Analyse et conception de la plateforme 
3.1 Choix du logiciel de supervision
3.2 Choix de la plateforme
3.3 Choix de l’infrastructure de messagerie
3.4 Choix des terminaux GSM
4 Réalisation et mise en place de la solution
4.1 Installation et configuration du logiciel PRTG Network Monitor
4.2 Choix des sondes
4.3 Mise en place du push-mail
4.4 Suivi du projet
Conclusion

Mots clés : Supervision de réseau, SNMP, sondes, push-mail, alertes, protocole.

Télécharger le rapport complet