PROJET D ADMINISTRATION RÉSEAUX - TRAFIC SNMP

(1)

PROJET D’ADMINISTRATION RÉSEAUX - TRAFIC SNMP

GROUPE PROJET :

Philippe Perrault, Franck Ortiz, Emmanuel Bédrune

M A S T E R 1 - A S R - 2 0 0 7

Université d’Evry

(2)

S OMMAIRE

1. Introduction 4

1.1. Objet du projet 4

1.2. Présentation du protocole Syslog 4

1.3. Présentation du protocole SNMP 6

2. Outils 8

2.1. Présentation des outils 8

2.1.1. Cacti 8

2.1.2. Snare 10

2.1.2.1. Le Serveur

10

2.1.2.2. Les agents Snare

12 2.2. Cacti 13

2.2.1. Description 13

2.2.2. Installation 14

2.2.2.1. Linux

14

2.2.2.2. Windows

14

2.2.2.3. Plugins

15

2.2.2.4. Configuration

16 2.3. Snare 18

2.3.1. Description 18

2.3.2. Configuration et options micro-server 18

2.3.3. Installation Agent 20

2.3.3.1. Installation de l’agent Linux

20

2.3.3.2. Configuration de l’agent sous Linux par l’interface Web

21

(3)

2.3.3.4. Installation et configuration de l’agent Windows

26 3. Mise en oeuvre, Cacti et Adventnet 29

3.1. Adventnet Simulation Toolkit 29

3.2. Architecture Adventnet simulée 31

3.3. Limites d’Adventnet 32

3.4. Interactions Cacti - Adventnet 33

4. Conclusion. 35

4.1. Résultats 35

4.1.1. Snare 35

4.1.2. Cacti et Adventnet 35

4.2. Résumé et remarques 35

4.2.1. Snare 35

4.2.2. Cacti et Adventnet 35

5. annexes 36

5.1. Simulation de trafic SNMP 36

5.1.1. MIMIC SNMP Agent Simulator 36

5.1.2. NetDecision SNMP Agent Simulator 36

5.1.3. iReasoning SNMP Agent Simulator 37

5.2. Snare Generator 38

5.3. Exemple avec la configuration d’un événement: 40

5.4. Scénario Snare sous Windows 41

6. Glossaire 44

7. Bibliographie 45

U n i v e r s i t é d ’ E v r y - M a s t e r 1 A S R - 2 9 s e p t e m b r e 2 0 0 7 P r o j e t d ’ A d m i n i s t r a t i o n R é s e a u x

(4)

1. I NTRODUCTION

1.1. OBJET DU PROJET

L’objet de ce projet est de mettre en place une architecture permettant de récupérer des paquets SNMP (Simple Network Management Protocol) et qui ait un système de gestion réseau.

Pour cela nous avons du utiliser différents logiciels tels que: Cacti, Snare et Adventnet. Nous allons vous présenter pour chaque outil utilisé, leurs descriptions, l’installation pour Cacti et Snare et la configuration de chacun des outils.

Nous avons décidé de créer plusieurs plates-formes utilisant différents systèmes d’exploitation (Linux et Windows), cela permettra de mettre en valeur les différences en matière d’installation mais aussi de configuration. Nous donne- rons les résultats obtenus ainsi que les problèmes rencontrés durant ce projet.

1.2. PRÉSENTATION DU PROTOCOLE SYSLOG

Syslog est protocole permettant le transit d'événements système sur un réseau. Son intérêt est donc de permettre une centralisation des journaux d'événements.

Les administrateurs sont ainsi plus à même de tracer les défaillances.

Un journal au format syslog comporte dans l'ordre les informations suivantes : la date a laquelle a été émis le log, le nom de l'équipement ayant généré le log (hostname), une information sur le processus qui a déclenché cette émission, le niveau de gravité du log, un identifiant du processus ayant généré le log et enfin un corps de message. Certaine de ces informations sont optionnelles.

exemple : date nom_de_machine info_processus service[gravité] id_processus détail_événement

(5)

Les niveaux de gravité Syslog sont au nombre de huit représentés par un chiffre de 0 à 7 : 0 - Emergency

1 - Alert 2 - Critical 3 - Error 4 - Warning 5 - Notice 6 - Informational 7 - Debug

Ce protocole se repose sur une partie client et une partie serveur communiquant entre eux via le port 514. Les serveurs collectent l'information et se chargent de créer les journaux.

Sous Linux, un daemon (service) permet la collecte des informations Syslog.

(6)

1.3. PRÉSENTATION DU PROTOCOLE SNMP

Le protocole SNMP (Simple Network Management Protocol), apparu en mai 1990, permet la gestion d’équipements réseau et le diagnostic d’incidents.

Ceci repose sur trois éléments principaux:

un superviseur : console depuis laquelle on peut consulter et agir sur l’état du réseau)

des nœuds : équipements du réseau que l’on souhaite gérer et composés d’objets de gestion contenus dans une base de données spéciale appelée Management Information Base. Cette base est hiérarchisée en arborescence et contient plusieurs types d’objets (propres au protocole, au type d’équipement, et au constructeur).

des agents : application de gestion hébergée au sein d’un nœud et chargé d’effectuer la transmission des informations contenues dans la MIB, au superviseur. Cette transmission peut se faire soit sur requête du superviseur (polling), soit de lui-même sur occurrence d’un événement précis (trapping).

SNMP utilise le protocole User Datagram Protocol pour transporter ses messages.

Nous pouvons détailler le message SNMP suivant cette structure :

(7)

Ces messages peuvent être :

Soit des messages envoyés depuis la console vers le port UDP 161 Soit des messages reçus par la console (trap) sur le port UDP 162 Les messages envoyés depuis la console aux agents peuvent être de plusieurs type :

Get : Pour la consultation d’une valeur d’un stockée en MIB

GetNext : Pour la consultation de la valeur de l’objet suivant de la MIB Set : Change une valeur de la MIB

Il est à noter que les agents et la console d’administration sont associés à une « communauté » qui, par défaut, est nommée "public". Ce nom peut être changé afin de sécuriser un peu mieux le trafic SNMP et éviter que quelqu'un d'autre n'ait accès aux informations des stations que l'on gère. En effet, un agent n’acceptera des interrogations que de la part d’une console appartenant à la même communauté que lui.

Pour plus d’informations, se référer à la RFC 1157 qui définit se protocole.

Voyons maintenant les outils que nous allons utiliser dans le cadre de ce projet.

(8)

2. O UTILS

2.1. PRÉSENTATION DES OUTILS 2.1.1. Cacti

Dans le monde du monitoring réseau, il est un outil incontournable : MRTG (Multi Router Traffic Grapher). Célèbre car pionnier dans le monde du graphage de données réseau, il n'est pas pour autant le seul dans sa catégorie. Il y en a un autre, qui mériterai d'être plus connu : Cacti.

Cacti stocke l’information nécessaire afin de créer des graphiques et les rassembler avec leur données associées dans une base MySQL. L’interface d’accueil repose entièrement sur du codage PHP. En plus de maintenir des graphiques, des données sources, ainsi que des RRA (Round Robin Archives) en base de données, Cacti s’occupe de la collecte des données.

Afin de collecter ces données, nous pouvons préciser à Cacti les chemins à tout script externe en accord avec nos besoins. Cacti les rassemblera ensuite régulièrement afin de peupler la base MySQL et les RRA.

Après avoir défini les options pour RRDTool indiquant par exemple comment stocker les données issues de pings vers des machines hôtes, nous pouvons être à même de définir toute autre information supplémentaire pouvant être re- quise. Ceci fait, ces données sont automatiquement maintenues à jour toutes les 5 minutes.

Cacti est un outil de création de graphes à la fois puissant, rapide et relativement simple d'utilisation et de prise en main. Il se distingue de MRTG par l'interface graphique complète de paramètrage qu'il propose et les nombreuses options de personnalisation qu'il offre. Il possède des caractéristiques pour le moins avantageuses :

Gratuit / Sous licence GNU v2. Ce qui est un excellent point que ce soit pour les PME à revenus limités ou encore les grosses firmes désireuses de limiter les coûts de monitoring tout en ayant un outil performant.

OpenSource. Des améliorations sont donc disponibles rapidement par le biais d’une communauté de passionnés. On peut également faire évoluer le produit afin de répondre à nos propres besoins, et en faire profiter le plus grand nombre. Ce point rend Cacti très complet et quasiment sans limites.

Fonctionne sous différentes plates-formes dont GNU/Linux et Microsoft Windows. Que l’entreprise ait fait le choix d’un parc hétérogène ou non, Cacti s’intègre donc facilement du fait de son indépendance face un OS particulier.

Basé sur RRDTool pour le système graphique et la conservation des données. Un outil, organisé autour d’une base de données, reconnu dans le monde de l’industrie permettant de générer des graphes complets.

Permet de récupérer les données à grapher en SNMP ou grâce à des scripts librement réalisables. SNMP étant un protocole dédié au management de réseau, être capable de recevoir des données via SNMP est un réel atout, voire même un pré-requis quasi-indispensable dont Cacti s’acquitte très bien.

(9)

Configurable grâce à une interface web sécurisée très conviviale. L’interface web bien que disposant des outils de base et prête à l’emploi, il est possible de la compléter encore plus afin d’affiner les fonctionnali- tés de Cacti via un système de modules. C’est précisément ce système de modules qui en fait un concur- rent redoutable face aux autres outils payants.

Graphiques totalement personnalisables avec un système de modèles exportables en XML. Et bien d'autres fonctionnalités toutes plus intéressantes les unes que les autres.

Le seul gros point noir de ce logiciel serait un support limité face à la montée en charge. Il n’est donc pas conçu à priori pour monitorer de grands réseaux, à moins de les découper en autant d’instances de Cacti que nécessaire.

Cacti utilise 2 moyens pour stocker les données : La base MySQL (où sont stockés les caches et informations sur vos hôtes) et les RRD (où sont stockées les données brutes collectées pour vos graphiques).

Parlons plus avant des graphiques complets que Cacti peut générer.

Une fois qu’une ou plusieurs données source ont été définies, un graphique (base sur les données stockées par RRDTool) peut être créé. Cacti nous fournit un large panel de types de graphiques pouvant être générés.

Nous pouvons également affecter des couleurs précises à ces graphiques ainsi que du texte par défaut afin de les rendre encore plus accessibles.

Comme nous commençons à l’introduire, Cacti ne se contente pas de créer des graphiques , mais multiplie les possibili- tés de les afficher.

Outre l’affichage standard « vue liste » et « mode prévisualisation », nous avons un choix d’affichage en arborescence.

Celui-ci nous autorise à insérer les graphiques de manière hiérarchique dans l’arborescence des hôtes monitorés.

Un autre point important dans l’utilisation de Cacti est sa gestion des utilisateurs.

Le foisonnement de fonctions offertes par Cacti impose un outil propre de gestion d’utilisateurs.

Nous pouvions ainsi ajouter des utilisateurs et leur donner des droits d’accès à certaines zones de Cacti. Ceci autorisera donc quelqu’un à créer des utilisateurs pouvant changer les paramètres des graphiques, tandis que d’autres ne pour- ront que seulement les visualiser.

Chaque utilisateur maintient également ses propres préférences en matière de consultation des graphiques.

Tout un système de modèles, apparu récemment, peut également enrichir Cacti. Il peut ainsi construire un modèle graphique ou de données définissant n’importe quel graphique ou source de données qui y sera associé.

Des modèles d’hôtes peuvent également définir les attributs de ceux-ci. Ainsi Cacti peut les interroger pour obtenir des informations additionnelles pour de nouveaux hôtes.

(10)

2.1.2. Snare

Snare (System iNtrusion Analysis and Reporting Environment) est un outil de vigie reposant sur une série d’agents interrogés à distance par un serveur fournit en tant qu’appliance (dont le noyau est basé sur une distribution Linux).

Ce type de distribution induit dont une parfaite maîtrise du matériel et du logiciel ainsi embarqué et limite donc l’in- disponibilité et les risques de pannes.

Snare est un outil prometteur et de plus en plus utilisé comme le montre le graphique suivant.

On constate que les téléchargements de Snare n’ont cessé de progressé depuis deux ans, signe d’une reconnaissance croissante.

2.1.2.1. Le Serveur

Le serveur Snare est capable de recevoir des logs d’équipements tels que des routeurs Cisco, des commutateurs, de pares-feux ou encore depuis l’outil de collecte de logs 'WhatsUp' par l’intermédiaire du protocole Syslog.

Ce serveur fournit également la capacité de se connecter à l’interface d’administration de routeurs ou pares-feux et de récupérer une copie des configurations des contrôles d’accès.

Ils peuvent ainsi être comparés avec une collection de règles « autorisées » (définies par l’administrateur). Les différen- ces entre ces fichiers sont surlignées afin que soient prises les mesures de correction nécessaires.

(11)

Le serveur Snare peut récupérer un large panel d’informations incluant : Dates/heures

Adresse source Adresse de destination Port de destination

Code de retour des paquets (success/failure/information) Criticité de l'événement

Action prise par l’équipement (accept / drop) Interface source

Port source Protocole utilisé

Tous les événements de sécurité et de gestion, connexions et déconnexions (réussies ou échouées), création ou suppression de comptes sont loggés. De même, on peut procéder à la surveillance de fichiers/répertoires et de processus sys- tème donnant lieu à la constitution de rapports.

Cependant, il faudra utiliser la surveillance de répertoires avec précaution car ce genre d’audit peut être générateur de nombreux événements et ainsi engorger le réseau. Ainsi il pourra être utile d’orienter ce type de log vers des répertoi- res à accès critiques (contenant des données sensibles par exemple).

La configuration d’un tel audit peut se faire soit en utilisant l’interface utilisateur dont dispose le serveur, ou bien par le micro serveur web dont sont pourvus tous les agents Snare.

Cette surveillance inclut évidemment l’ensemble des utilisateurs ayant accès à ce type de données.

Si il n’existe pas de processus de log (à base de Syslog) de mis en place afin que le serveur Snare récupère ces événe- ments, l’équipe d’InterSect Alliance assure un support afin de trouver les outils appropriés.

Il est à noter également que le serveur Snare collecte de manière automatique tous les événements lui étant envoyés via les ports 6161 TCP/UDP ou via le port 514 UDP (Syslog).

Ceux-ci seront stockés dans la table « Generic Log ».

Il est aussi nécessaire d’affiner les réglages du serveur car, par défaut, seuls sont en vigueur les paramètres recomman- dés.

Le serveur Snare offre ainsi des possibilités très étendues, dont celle de surveillance de l’espace pris par la base de don- née ou même de procéder à l’archivage des logs vers support CD ou DVD. Tâche qu’il est possible d’automatiser.

(12)

2.1.2.2. Les agents Snare

Comme dit précédemment, il existe également toute une collection d’agents Snare permettant de remonter les évène- ments vers le serveur. Ils sont disponibles sur une large gamme de systèmes tels que Linux, Windows, Solaris, IIS, Lo- tus Notes, Irix, AIX, ISA/IIS et bien plus encore. Ceci permet de monitorer à peu près tous les équipements réseau pré- sents couramment dans les entreprises.

Leurs avantages sont nombreux :

Interface GUI très simple d'utilisation (délivrée par un micro-serveur web embarqué) Gestion des logs Active Directory et DNS sous un système Windows 2003

Possibilité de configurer la forme des logs envoyés (niveau, facilité) Tournant sous forme de service pour un lancement propre au démarrage Entièrement configurables à distance via une interface Intranet (port 6161)

Possibilité d'ajouter des filtres pour définir les logs (ID événements, facilité) à envoyer suivant les besoins

La famille d’agents Snare vient d’en accueillir un nouveau, nommé Epilog. Ce nouvel agent a pour but de contrôler tout log au format texte et de faire remonter tout changement vers le serveur. Epilog gère ces fichiers par noms et assure le roulement de fichiers.

Epilog pour Windows assure également le support de fichiers de logs datés tels que les logs de traçage des messages IIS, ISA, SMTP et Exchange.

Cette famille d’agents est, pour l’instant, disponible sur plate-forme Windows. Leur support sur Linux et Solaris de- vraient être disponibles prochainement.

Comme nous avons donc pu le remarquer, InterSect a développé une suite d’outils (certes payante) adaptable à tout équipement. Cette grande adaptabilité est facilitée par l’utilisation d’agents spécialement développés, et remontant ainsi des événements spécifiques à la plate-forme sur laquelle ils sont placés. Ils sont également facilement gérables par l’intermédiaire d’un serveur complet et robuste car maîtrisé de bout en bout tant au niveau hardware que software.

A cette suite nous pouvons ajouter un outil (aussi payant) appelé Sawmill et qui peut se charger d’analyser les logs Snare et générer des statistiques dynamiques. Sawmill possède également la faculté, au combien pratique, d’analyser les logs Snare et de les importer dans une base de données SQL.

Il est ainsi possible d’agréger ces journaux et de fournir des rapports filtrés dynamiquement, le tout à travers une interface web.

Cet outil fonctionne sur n’importe quelle plate-forme incluant Windows, Linux, FreeBSD, OpenBSD, Mac OS, Solaris, autres UNIX et quelques autres.

Cet outil est actuellement une valeur montante dans le domaine professionnel, comme en atteste ce graphique mon- trant le l’évolution du nombre de téléchargements de Snare. Ceux-ci connaissent une grande évolution et ont même doublé en un an.

(13)

2.2. CACTI

2.2.1. Description

Cacti est un outil de supervision en temps réel basé sur RRDtool permettant de surveiller l’activité de son architecture informatique à partir de graphiques et avec un historique sous Windows 2000 Pro. L'avantage non négligeable de ce logiciel est qu'il est un freeware, de plus en plus populaire, il est utilisé depuis peu par free pour donner les audiences TV de la Freebox http://audience.free.fr/.

Une fois l'ensemble des logiciels installés sur le serveur, il sera possible de voir les statistiques mises en place à partir d'une simple fenêtre d’un navigateur Web.

Afin de faire fonctionner Cacti, nous avons tout d’abord besoin de nous munir des outils suivants :

Un serveur web (exemple : Apache ou Windows IIS) pour l’accès aux pages web d’administration de Cacti

Cacti, se présentant sous la forme d’une archive ZIP contenant l’ensemble des pages PHP permettant la génération et la consultation des informations récoltées. Ce paquet sera à placer dans le répertoire d’accès du serveur web.

Cactid qui est un poller pour Cacti. On pourra l’utiliser en lieu et place de celui déjà intégré à Cacti si le réseau à gérer est grand. En effet il a été conçu dans un objectif de rapidité d’exécution.

RRDTool qui s’occupera de stocker les informations recueillies par Cacti, sous forme de fichiers .rrd PHP version 4.3.6 et supérieure qui se chargera de l’interprétation des pages PHP de Cacti.

MySQL 4.x ou 5.x grâce auquel nous créerons une base de données pour stocker les variables utilisées par Cacti.

(Optionnel) Cygwin, offrant sous Windows un environnement proche de ce que l'on trouve sous Unix.

Celui-ci nous fournira donc l’accès à des commandes du monde Unix dont Cacti ou ses plugins pourrait avoir besoin (exemple : Sendmail pour l’envoi de mails d’alerte).

(Optionnel) Net-SNMP qui est une suite d’applications utilisant SNMP afin de recueillir des informations sur les équipements managés.

(14)

2.2.2. Installation

2.2.2.1. Linux

La distribution que nous avons choisie afin de monter la plate-forme Cacti sous Linux est Debian. Nous nous sommes orientés vers cette distribution car nous recherchions une distribution légère, modulable et rapide à mettre en place.

En ce qui concerne la configuration de la distribution, nous avons installé les paquets par défaut de l’installation mini- male puisqu’aucune interface graphique et très peu de services sont nécessaires. La commande apt-get install suivie d’un nom de paquet permet d’installer ce paquet ainsi que tous les paquets dont il dépend.

Pour installer Cacti sur cette machine, il suffit de deux commandes d’installation de paquets et de quelques éditions de fichiers de configuration.

Il nous faut un serveur Web pour supporter Cacti. Le choix s’est porté sur Apache2 en raison de sa souplesse et de sa fiabilité. Une fois Apache2 installé, nous l’avons configuré pour qu’il ne fonctionne qu’en HTTPS (flux HTTP crypté en SSL). Ainsi, notre serveur n’accepte les connexions que sur le port 443 et fourni un certificat SSL que nous avons généré via la commande : apache2-ssl-certificate.

Ensuite, nous avons entrepris l’installation de Cacti, la commande apt-get install cacti a provoqué l’installation de tous les paquets nécessaires au bon fonctionnement de Cacti. Outre Cacti à proprement dit, php4, mysql, rrdtools furent automatiquement installés (ainsi que leurs dépendances). À la fin de l’installation des paquets, Cacti nous demande les options de configuration nécessaires à son bon fonctionnement. Voici les paramètres que nous avons spécifiés :

Nom de la base de données : cacti Serveur de base de données : localhost Utilisateur de la base de données : cactiuser

Mot de passe d’accès à la base de données : passcacti Port d’accès à la base de données : 3306

L’installeur nous demande ensuite les paramètres nécessaires pour créer son utilisateur et sa base de données et créé tout ce dont Cacti a besoin.

À la fin de cette étape, la page d’administration de Cacti est accessible à l’adresse : https://<adresse_du_serveur_cacti>/cacti/, il ne reste plus qu’à installer les éventuels plugins et ajouter sur l’interface de Cacti les machines à monitorer.

2.2.2.2. Windows

Nous allons partir d’une machine virtuelle Windows 2000 Server sur laquelle nous allons commencer par installer EasyPHP qui a pour avantage d’inclure un serveur web Apache et un interpréteur PHP.

Nous pouvons à présent mettre le contenu de l’archive de Cacti dans le répertoire « www » d’EasyPHP et commencer l’installation de MySql 5.0.

Cette installation simple de l’archive autoextractible nous donne accès à une console en ligne de commande afin de pouvoir créer notre base de données pour Cacti.

(15)

Il faut d’abord mettre un mot de passe (ici « cactiuser ») pour le super utilisateur « root » à l’aide d’une console de commande classique :

cd mysql\bin

mysqladmin --user=root password cactiuser mysqladmin --user=root --password reload

Nous allons ensuite passer par le client MySql afin de créer une base de données nommée “cacti” en ligne de commandes, en tant que root

create database cacti

Il nous reste ensuite à importer le script sql de Cacti pour créer les tables dont il aura besoin.

mysqladmin --user=root --password cacti < c:\Program Files\EasyPHP\www\cacti\cacti.sql

Par la suite nous créerons un utilisateur « cactiuser » n’ayant des droits que sur la base de données de Cacti.

Cactid sera lui décompressé dans un dossier qui lui sera propre (à part). RRDtool sera placé avec Cactid et on exécutera le fichier « install.cmd » (ayant besoin d’un compilateur Perl, nous en avons installé un).

En dernier lieu, Cygwin sera mis en place avec les packages suivants :

Base (include all items)

Libs

libart_lgpl

libfreetype26

libpng12

zlib

openssl

Utils

patch

Web

wget

2.2.2.3. Plugins

Afin de compléter les fonctionnalités de Cacti et l’adapter un peu plus à notre besoin, nous allons lui ajouter les plugins :

(16)

Thold : fonction d’envoi de mail automatique sur déclenchement d’un événement Monitor : fonction de visualisation directe (et sonore) de l’état des machines monitorées.

Update : récupération d’informations sur les plugins installés et vérification de présence de mises à jour

Ces plugins nécessitent de patcher Cacti en lui ajoutant le contenu du package « Plugin Architecture ». Ce dernier mo- difie des fichiers de configuration et ajoute un répertoire « plugins ». A présent Cacti peut recevoir les plugins nommés ci-dessus.

Pour les installer, c’est simple, il suffit de :

Placer le contenu de l’archive du plugin dans le répertoire « plugins »

Ajouter « $plugins[] = ‘Nom_dossier_plugin’ ; » après « $plugins = array() ; » dans le fichier

« config.php » (situé dans le dossier « include » de l’arborescence Cacti du serveur web)

Nous avons à présent tous les outils sont réunis pour former notre console de management.

Il ne reste plus qu’à passer à la configuration ! 2.2.2.4. Configuration

Dans le fichier cacti_web_root/cacti/include/config.php, il nous faut à présent rajouter les lignes nécessaires à l’accès de Cacti à la base de données MySql qui lui a été dédiée.

$database_default = "cacti"

$database_hostname = "localhost"

$database_username = "cactiuser"

$database_password = "cacti"

$database_port = "3306"

Nous allons également donner l’accès au réseau monitoré par l’ajout d’une route vers le réseau 192.168.101.0/24 par la passerelle 192.168.195.221.

Ici, pour l’accès au réseau simulé par le serveur cacti : route add -net 192.168.101.0 mask 255.255.255.0 192.168.195.221

(17)

Le plugin « Thold » nécessite également une configuration que nous allons effectuer une fois connecté à l’interface web de Cacti.

M A S T E R 1 - A S R - 2 0 0 7

(18)

2.3. SNARE

2.3.1. Description

Snare vous permettra de récupérer sous forme de trames Syslog compatibles à la norme RFC la majorité des évène- ments de vos systèmes. A la différence de Cacti, il a besoin de deux parties pour fonctionner. Une partie serveur et une partie client. La partie serveur récupère les logs envoyés par la partie client.

Ses avantages sont nombreux :

Interface GUI très simple d'utilisation.

Gestion des logs Active Directory et DNS sous un système W2K3.

Possibilité de configurer la forme des logs envoyés.

Tournant sous forme de service pour un lancement propre au démarrage.

Entièrement configurable à distance via une interface Intranet (port 6161)

Possibilité d’ajouter des filtres pour définir les logs à envoyer suivant vos besoins.

2.3.2. Configuration et options micro-server

Le serveur Snare étant fourni sous forme d’une appliance sous OS propriétaire (basé sur un noyau Linux), nous utilise- rons un serveur Snare allégé et gratuit pour Windows.

Il se présente comme suit :

Pour comparaison, voici un aperçu de l’interface du serveur Snare complet :

M A S T E R 1 - A S R - 2 0 0 7

(19)

Etant une version allégée, il n’offre que peut d’options de configuration :

: donne accès au statut du serveur et à d’autres informations (la date à laquelle il a été démarré, le nombre de paquets reçus sur le port Snare et sur le port SNMP)

: applique les changements et redémarre le serveur.

: configure le serveur en donnant le chemin de stockage des fichiers de log, et leur format de nommage.

: efface les événements de l’interface.

Il est également à noter la présence d’un produit appelé « Snare Generator » et destiné à la génération artificielle d'évé- nements à destination de serveurs Snare. Cet outil s’avère pratique pour qui veut tester le bon fonctionnement du serveur. Plus de détail sur ce produit est donné en annexe.

(20)

2.3.3. Installation Agent

2.3.3.1. Installation de l’agent Linux

Pour le système utilisé, nous avons choisi la distribution Debian de Linux. Nous avons du utiliser la version 2.4 du noyau car lors du début de ce projet, le patch Snare pour Debian 2.6 n’existait pas encore. La version pour le kernel 2.6 est disponible depuis peu et il suffit de suivre la même explication qu’avec le noyau précédent. Pour notre part, nous avons utilisé le kernel 2.4 avec le patch de Snare qui correspond. Pour commencer, il suffit de récupérer l’archive choisi sur ce lien: http://www.gweep.net/~malk/snare_debian.shtml pour la version 2.4 et sur : http://www.intersectalliance.com/projects/Snare/ pour la version 2.6. Il faut aussi récupérer l’Audit Daemon qui est la même pour les deux versions et qui est téléchargeable sur les liens précédents.

Une fois Snare téléchargé, il suffit de décompresser l’archive à l’aide de la commande “tar” puis de patcher le noyau avec la commande:

dpkg -i kernel-image-2.4.26-1-386-snare_2.4.26-2.snare_i386.deb

Une fois le noyau patché, il faut installer l’audit avec la commande:

dpkg -i --force-depends snare-gui-0.9.6-2_i386.deb

Il est cependant possible de ne pas utiliser le GUI pour configurer le client Snare, nous pouvons utiliser un navigateur Web pour cela.

Ces opérations terminées, Snare est installé et il faut redémarrer Linux avec le nouveau noyau patché pour que Snare démarre en tant que service.

(21)

2.3.3.2. Configuration de l’agent sous Linux par l’interface Web

La configuration de Snare par la page Web est répartie en trois parties que nous allons étudier maintenant.

M A S T E R 1 - A S R - 2 0 0 7

(22)

Network configuration (configuration du réseau)

Clientname : C’est le nom de l’agent Snare. C’est ce nom qui permet de savoir qui envoie les logs.

Destination Server address : L’adresse du serveur Snare ici: 192.168.1.110 Destination UDP Port : Port par lequel les logs sont envoyés

Destination FileName : Chemin réseau du fichier du serveur Snare (Ici un windows NT).

M A S T E R 1 - A S R - 2 0 0 7

(23)

Remote Control Configuration (Configuration du contrôle a distance).

Allow remote control of SNARE agent : Permettre ou non le contrôle à distance de Snare.

Les deux champs suivant sont pour filtrer les adresses IP qui peuvent contrôler à distance l’agent Snare.

Require a password et le champ suivant servent à définir un mot de passe pour pouvoir modifier l’agent Snare.

Web Server Port : Port par lequel on l’agent Snare écoute pour la configuration à distance.

M A S T E R 1 - A S R - 2 0 0 7

(24)

Objectives configuration (configuration des objectifs)

Cette page permet de définir ce que l’on veut surveiller sur l’agent et la priorité de ces actions. La priorité permet de rendre plus clair la lecture au niveau du serveur en utilisant des couleurs. Par exemple, vert pour les informations et rouge pour les événements critiques.

2.3.3.3. Configuration de l’agent sous Linux par l’interface graphique Pour lancer le GUI, il suffit de taper dans une console: snare

M A S T E R 1 - A S R - 2 0 0 7

(25)

Controle de l’audit.

Log to File or Network : Permet de choisir si l’on surveille l’agent sur cette machine, sur un serveur ou sur les deux. Ici sur les deux ce qui permet de pouvoir comparer les informations entre le serveur et l’agent.

Log File Name : Chemin réseau du fichier du serveur Snare (Ici un windows NT).

Network Parameters : Nom de l’agent, Adresse IP du serveur Snare et Port d’envoi des Logs.

Objectifs.

Avec cet onglet nous pouvons définir ce que l’on veut surveiller et leurs priorités.

(26)

Contrôle à distance.

Paramètre de contrôle à distance de l’agent Snare.

2.3.3.4. Installation et configuration de l’agent Windows

L’installation est simple et se fait par l’exécution d’une archive auto-extractible donnant accès, via le menu « démar- rer », à un fichier .cmd restaurant les paramètres d’accès par défaut (en cas de mauvaise manipulation) ainsi qu’à un exécutable démarrant l’agent Snare.

L’agent est configurable via une interface web accessible par défaut sur le port 6161. Le menu de configuration se pré- sente comme suit :

M A S T E R 1 - A S R - 2 0 0 7

(27)

Latest Events : Donne accès aux derniers événements qui se sont produits sur la machine et enregistrés par l’agent suivant des règles qu’il est possible de définir par l’item « Objectives Configuration ».

Network Configuration : Permet de configurer l’adresse du serveur Snare ainsi que les options de transmission des événements à celui-ci.

Remote Control Configuration : Options de sécurité pour l’accès distant à l’agent.

(28)

Objectives Configuration : Configuration des événements devant être enregistrés par l’agent Snare.

View Audit Service Status : Affiche le statut actuel de l’agent.

Apply the Latest Audit Configuration : Après changements de configuration, permet de reparcourir la liste des événe- ments à surveiller et de réappliquer la nouvelle configuration.

Le reste des items donne des informations d’administrations de la machine auditée (telles que la liste des utilisateurs ou même un accès au contenu de la base de registre).

(29)

3. M ISE EN OEUVRE , C ACTI ET A DVENTNET

3.1. ADVENTNET SIMULATION TOOLKIT

Set complet de simulateurs d’agents et de réseaux permettant de tester à moindre coût les applications de gestion de réseaux (aussi appelées Network Management System) dans un environnement réaliste contenant des équipements de marques et de types différents. Tout un réseau peut ainsi est modélisé que ce soit sous Windows, Linux, ou Solaris, le tout avec des équipements de connexion Cisco.

Qui dit environnement de gestion de réseaux, dit également agents, et AdventNet Simulation Toolkit offre un support d’agents SNMP et TL1 (autre protocole de gestion utilisé notamment dans les réseaux de type SONET).

De plus, ce Simulation Toolkit est développé en Java ce qui favorise sa portabilité. Il peut simuler jusqu’à 20 nœuds en version gratuite, et plus de 50 000 avec achat de la licence. On peut également noter que ce kit de simulation supporte SNMPv3.

(30)

Comme tout kit, il comprend différents outils :

Network Simulator : Pour simuler un réseau entier avec des équipements SNMP, TL1, TFTP, FTP, Telnet ou fonctionnant sous l’OS de Cisco (IOS).

SNMP Agent Simulator : Pour simuler un agent (ou équipement) SNMPv1/ v2 /v3 avec des données utilisateurs de configurées et des valeurs pré-enregistrées.

TL1 Agent Simulator :Pour simuler un element réseau TL1 avec des données utilisateurs de configu- rées.

SNMP Trap Stormer : Pour configurer et envoyer des traps, tester la fiabilité des applications de gestion dans la réception de n’importe quelle quantité de notifications (traps) à intervalle régulier.

Network recorder : Pour enregistrer de vrais réseaux SNMP. Les échanges de messages ainsi enregistrés sur ces réseaux peuvent être instantanément rejoués dans un réseau simulé.

Trap Recorder : Pour enregistrer des notifications (traps). Elles peuvent ainsi être utilisées pour communiquer entre un agent créé par l’outil SNMP Agent Simulator et un réseau issu de l’outil Network Simulator.

M A S T E R 1 - A S R - 2 0 0 7

(31)

3.2. ARCHITECTURE ADVENTNET SIMULÉE

L’architecture que nous avons mise en place se compose de dix-neuf machines de trois types différents.

D’une part, nous avons un Routeur/Pare-feu et trois Commutateurs. Ensuite nous avons trois imprimantes.

En ce qui concerne les postes de travail, nous avons opté pour cinq machines Linux et cinq Windows. Pour compléter le tout, nous avons inclus deux postes Solaris.

Voici une capture de l’interface d’Adventnet où sont listées toutes les machines simulées ainsi que leurs adresses et ports d’accès.

Après avoir sélectionné les machines de notre réseau, nous pouvons dessiner la topologie de ce dernier.

Dans notre cas, nous avons choisi de définir des groupes de postes regroupés par système d’exploitation autour d’un commutateur. Dans chaque groupe, nous avons aussi inséré une imprimante.

M A S T E R 1 - A S R - 2 0 0 7

(32)

On obtient la topologie suivante :

3.3. LIMITES D’ADVENTNET

Le Simulation Toolkit d’Adventnet comporte deux limitations assez gênantes dans notre contexte.

Pour commencer, le trapping ne fonctionne pas. C’est à dire que les machines simulées ne peuvent communiquer leur état, de leur propre chef, au serveur. Les “traps” émises sont en fait cantonnées au simulateur et de ce fait, notre serveur, externe au simulateur, ne peux les recevoir.

D’autres part, la topologie n’est qu’une présentation des machines. Elle n’intervient pas dans le fonctionnement du réseau. Ainsi, si on fait tomber le Commutateur d’adresse 192.168.101.11 de notre plate-forme, toutes les machines y étant attachées seront encore accessible, on pourra donc toujours pinguer 192.168.101.9 ou 192.168.101.19.

Pour finir, une limite nous est imposée, non pas par Adventnet lui-même, mais par la simulation du réseau. Ce réseau est simulé sur une seule machine. De plus, cette machine ne fait que simuler des entités imitant le comportement de machines fixes et peu modulables. De ce fait, impossible d’avoir des services tels que DNS ou DHCP. Ainsi quelques modules de Cacti tels que Discovery s’avèrent totalement inutiles dans notre maquette.

Le module Discovery permet de détecter les machines qui ne sont pas encore supervisées par notre serveur. Cela permet d’éviter la tâche rébarbative d’ajout de toutes les machines du réseau à la liste de machines à superviser.

M A S T E R 1 - A S R - 2 0 0 7

(33)

3.4. INTERACTIONS CACTI - ADVENTNET

Une fois la tâche d’ajout des machines simulées dans Cacti, on peut choisir quelles informations peuvent être sujettes à une supervision. De nombreuses sources d’informations sont paramètrables et permettent le tracé de graphes.

On peut donc avoir des informations sur les taux de transfert de chaque interface réseau, le taux d’occupation de chaque disque, le nombre de processus actifs ou d’utilisateurs logués, etc.

Deux modules autres que Discovery s’avèrent indispensables :

Thold, dont nous avons déjà parlé, permet l’envoi par mail d’alertes paramètrables.

Monitor, affiche une page très simple représentant par des icônes de couleur les différentes machines du réseau. En fonction de l’état de chaque machine, la couleur change. On aura donc en vert les machines en ligne, en rouge celle hors ligne et en bleu celle qui sont en cours d’interrogation.

Si on coupe la machines Windows d’adresse 192.168.101.7 :

(34)

On obtiendra sur la page de la liste de machines gérées par Cacti :

Et sur la page Monitor :

M A S T E R 1 - A S R - 2 0 0 7

(35)

4. C ONCLUSION .

4.1. RÉSULTATS 4.1.1. Snare

La communication entre un serveur Snare sous Windows et un agent Snare sous Linux fonctionne correctement, nous avons des informations sur plusieurs événements telle que la commande PING effectuée sur l’agent se verra sur le serveur, mais aussi des événements tel que le log d’un utilisateur ou même la suppression d’un processus, tout dépend de la configuration. Le temps de réaction est dans l’ensemble assez rapide, le serveur reçoit les événements en quelques secondes, ce qui permet de contrôler presque en temps réel tout ce qu’il se passe sur les agents.

4.1.2. Cacti et Adventnet

Vous aurez pu le constater, Cacti est un outil indépendant de la plate-forme d’accueil et capable de gérer n’importe quel type d’agent SNMP. Ses fonctions ne sont pas très poussées à l’origine mais ils est possible de le faire évoluer.

Le fonctionnement de Cacti est très intéressant à étudier et ses possibilités d’évolutions par des modules (plugins) sont très attrayantes. L’envoi d’alertes par mail ou l’interface de découverte de machines non gérée peut s’avérer très vite indispensable.

Ces différentes maquettes que nous avons mises en place ont démontré la performance de cet outil et sa facilité de mise en œuvre, surtout sous Linux, où la facilité d’installation est déconcertante.

4.2. RÉSUMÉ ET REMARQUES

Nous disposons à présent d’une plate-forme complète de monitoring de réseau grâce à plusieurs outils. Ainsi nous pouvons également recouper les informations et avoir un diagnostic le plus pointu possible, tout en ayant une trace des activités ayant pu conduire à un éventuel incident.

Par contre, il est à noter que le déploiement de notre solution ne s’est pas faite sans mal et nécessite l’intervention d’un grand nombre d’outils (serveur web, gestionnaire de bases de données, agents, poller, ….) qui représentent autant de points de failles possibles dans la remontée des erreurs. Aussi faudra-t-il par la suite s’intéresser à des outils « tout en un » et disposant de contrat de maintenance adéquat à la fiabilité voulue du réseau.

4.2.1. Snare

Dans l’ensemble Snare est un outil de supervision assez agréable à utiliser mais il manque un serveur Snare sous Linux et un serveur complet sous Windows.

Pour ce qui est de la configuration, cela est assez simple et Snare permet de gérer correctement ses logs de façon dé- taillée. L’interface par contre n’est pas très clair, les messages reçus ne tiennent pas sur la ligne, ce qui gène pour la lecture entière de l’événement. Il suffirait qu’il y est une barre déroulante horizontalement pour pouvoir aller jusqu’au bout de la description.

Dans l’ensemble Snare est un outil plutôt agréable et performant.

4.2.2. Cacti et Adventnet

En ce qui concerne Cacti, il s’agit d’un outil performant et prometteur mais notre maquette de test était très limitée par les fonctionnalité d’Adventnet. En effet, si nous avions eu les moyens matériels et horaires de monter cette même plate- forme avec uniquement des machines virtuelles type VMware (une dizaine de machines pour commencer), nous au- rions pu bien plus éprouver cet outil.

(36)

5. ANNEXES

5.1. SIMULATION DE TRAFIC SNMP 5.1.1. MIMIC SNMP Agent Simulator

Description : MIMIC répond aux requêtes sur n'importe laquelle de ses adresses IP configurées, ainsi c’ est comme si l'application NMS (Network Management System) communique avec les dispositifs réels.

Caractéristiques :

logiciel payant édité par Gambit Communications simule jusqu’à 10 000 dispositifs

inclut beaucoup de MIBs pré-compilées (et peut en compiler grâce à MIMIC compiler) suite de scénarios prédéfinis incluse

support SNMPv3

NB : Existe également « MIMIC IOS Simulator » qui permet de simuler des dispositifs Cisco.

Source : http://www.gambitcomm.com/site/products/french/frtopproducts.shtml

5.1.2. NetDecision SNMP Agent Simulator

Description : Autorise la simulation d’agents SNMP en créant des valeurs par défaut pour n’importe quelle MIB SNMPv1 et v2. La modélisation d’agents SNMP et de génération de « trap » peut être fait aisément grâce à un méca- nisme de scripts.

Combiné avec « SNMP Trap Simulator » et « SNMP Trap Vision » procure une suite complète d’applications de test de gestionnaire SNMP.

Caractéristiques :

logiciel payant édité par NetMechanica interface graphique “user-friendly”

enregistrement des “dialogues” SNMP interface personnalisable

support SNMP v3

Source : http://www.netmechanica.com/products/?prod_id=1019

(37)

5.1.3. iReasoning SNMP Agent Simulator

Description : Application Java (compatible toutes plates-formes) pouvant simuler des agents SNMP v1/2/3.

Caractéristiques :

logiciel payant édité par iReasoning Networks simulation d’erreurs et de traps

nombre d’agents fonction des ressources CPU disponibles enregistre et rejoue les simulations

simple d’utilisation

Source : http://www.ireasoning.com/snmpsimulator.shtml

M A S T E R 1 - A S R - 2 0 0 7

(38)

5.2. SNARE GENERATOR

Snare Generator est un outil développé pour un environnement Linux et destiné à la génération artificielle d’évène- ments à destination de serveurs Snare. Actuellement, il est capable de générer cinq types d’évènements (Windows, So- laris, IRIX, Syslog et PIX –Cisco firewall-).

Ces évènements artificiels sont envoyés sur le réseau sur les ports TCP/UDP 6161 ou 514 (Syslog). Les événements PIX ou Syslog seront envoyés par le port 514. A noter que ces ports ne sont pas configurables.

Le Snare Generator se présente dans une interface semblable à celle du micro-server.

M A S T E R 1 - A S R - 2 0 0 7

(39)

Cependant, contrairement au micro-server, Snare Generator s’avère nettement plus complet au niveau de la configuration. On peut ainsi :

choisir le type d'événement à générer

simuler des événements « réels » ou juste se contenter d’en envoyer un nombre à définir entrer un délai entre l’envoi de deux événements

indiquer l’adresse du serveur Snare destinataire choisir le protocole d’envoi à utiliser (TCP ou UDP)

entrer une liste d’utilisateurs fictifs à l’origine de ces événements artificiels sélectionner la date de début à indiquer pour les événements

M A S T E R 1 - A S R - 2 0 0 7

(40)

5.3. EXEMPLE AVEC LA CONFIGURATION D’UN ÉVÉNEMENT:

Nous allons faire un exemple avec une suppression de fichier ou de dossier.

Tout d’abord, nous allons créer un objectif qui permettra de capturer les événements de suppression de dossier ou fichier.

Capture de la configuration.

Une fois l’agent configuré pour l’envoi de cet événement, il suffit de créer un dossier sur la machine Linux et de le supprimer pour voir si le serveur réagi a cet événement.

Création de dossier: #mkdir test (ceci crée un dossier test, je me suis placé dans le dossier /home/franck) Le dossier /home/franck/test créé, il suffit de le supprimer à l’aide de la commande: #rmdir test/

Voyons maintenant la capture effectuée après l’opération de suppression.

Nous pouvons constater que le dossier /home/franck/test a bien été supprimé par l’utilisateur root avec la commande rmdir.

M A S T E R 1 - A S R - 2 0 0 7

(41)

5.4. SCÉNARIO SNARE SOUS WINDOWS

But : Nous allons ajouter un nouvel objectif (l’audit d’un répertoire précis) pour capturer un événement sur l’agent, puis vérifier la remontée de l’information vers le micro-serveur.

Configuration de l’objectif :

Via l’interface web de l’agent Snare, nous précisons donc qu’il faut enregistrer tout accès à un fichier ou répertoire (nous prendrons le répertoire « C:\ArchInstall » contenant toutes les archives des logiciels installés).

Nous allons enregistrer cet événement pour n’importe quel utilisateur (on inclut tous les utilisateurs dans le spectre de recherche => « Include », et étoile dans le champ « User Search Term »).

L'événement concernera toutes les alertes de réussite et d’échec de l'événement (on coche « Success Audit » et « Failure Audit ») et sera remonté en tant que « Warning »

A présent, il ne reste plus qu’à se rendre dans le répertoire « ArchInstall » et créer un document. Bien que l’accès appa- raisse également dans ce type de configuration, nous allons tracer l'événement d’ajout du fichier.

M A S T E R 1 - A S R - 2 0 0 7

(42)

Résultats :

Immédiatement l’interface web de l’agent Snare affiche le résultat :

Un rapide coup d’œil sur l’interface du micro-serveur nous indique également qu’il a reçut l'événement.

M A S T E R 1 - A S R - 2 0 0 7

(43)

On pourra également avoir le contenu exact dans le fichier de log que le micro-serveur a créé.

Date/Heure Source Type de log Détail

F e b 1 5 16:42:27

agent_snare_win MSWinEventLog

2 (Warning)

Security 50 Thu Feb 15 16:42:20 2007 560 Security Administrateur User Suc- cess Audit AGENT_SNARE_WIN Accès aux objets Objet Ouverture : Objet Serveur : Security Objet Type : File Objet Nom : C:\ArchInstall Nº du nouveau handle : 1180 Nº d'opération : {0,323182} Nº de processus : 980 Nom d'utilisateur principal : Administrateur Domaine principal :

AGENT_SNARE_WIN Nº de la session prin- cipale : (0x0,0x80C8) Nom d'utilisateur du client : - Domaine du client : - Nº de ses- sion du client : - Accès DELETE

READ_CONTROL SYNCHRONIZE Lecture données (ou liste de répertoire) Écriture don- nées (ou ajout fichier) Ajout données (ou ajout sous-répertoire ou créer instance de canal) Rea- dEA WriteEA ReadAttributes WriteAttributes Privilèges - 41

Contenu du fichier de log

(44)

6. G LOSSAIRE

A) Active Directory

Active Directory est un annuaire au sens informatique et technique chargé de répertorier tout ce qui touche au ré- seau comme le nom des utilisateurs, des imprimantes, des serveurs, des dossiers partagés, etc. L'utilisateur peut ainsi trouver facilement des ressources partagées, et les administrateurs peuvent contrôler leurs utilisations grâce à des fonctionnalités de distribution, de duplication, de parti- tionnement et de sécurisation des accès aux ressources répertoriées.

B) Agent (SNMP)

Un agent est l'équivalent d'un robot logiciel. C'est un pro- gramme qui accomplit des tâches à la manière d'un auto- mate et en fonction de ce que lui a demandé son auteur.

C) Appliance

Appareil dédié à une fonction bien précise, par opposition à un micro-ordinateur généraliste. Certains considèrent que le routeur est l'exemple type des appareils de réseau.

On a désigné par Internet Appliance un dispositif léger (écran, clavier, unité de calcul très réduite) qui permettait de se connecter au réseau, d'échanger des messages et d'afficher des pages Web mais qui ne possédait pas de disques propres : tous les fichiers étaient mémorisés sur le réseau. On évitera d'employer appliance à tort et à travers car ce mot, même en anglais, ne signifie rien de plus qu'appareil, instrument, dispositif. En français, il s’agit d’un serveur applicatif.

D) Distribution

On parle souvent de distribution pour désigner un ensemble de logiciels formant un tout cohérent et prêts à installer, incluant des jeux de paquetages, le noyau du système d'exploitation (en particulier le noyau Linux pour les distributions Linux (comme Debian, Red Hat, Mandri- va, etc.)), un système d'installation et des utilitaires de configuration.

E) Licence GNU

La Licence publique générale GNU, ou GNU GPL pour GNU General Public License en anglais, est une licence qui fixe les conditions légales de distribution des logiciels libres du projet GNU. Richard Stallman et Eben Moglen, deux des grands acteurs de la Free Software Foundation,

la GNU GPL version 2 de 1991 et une troisième version est en cours d'écriture.

F) Log

le terme log est employé en informatique pour désigner un historique d'événements et par extension le fichier contenant cet historique.

G) MySQL

MySQL est un gestionnaire de base de données libre. Il est très utilisé dans les projets libres et dans le milieu indus- triel.

H) OpenSource

Le terme OpenSource indique que le produit inclut la permission d’utiliser son code source, documents associés ou contenu.

I) Paquet

Un paquet est un fichier qui permet d'installer un logiciel, une bibliothèque, etc.

J) RRA

Round Robin Archive, collection de fichiers rrd de RRDTool.

K) RRDTool

RRDtool est un outil de gestion de base de données RRD créé par Tobi Oetiker. Cet outil a été créé pour superviser des données serveur, telles que la bande passante, la tem- pérature d'un processeur... Le principal avantage d'une base RRD est sa taille fixe.

RRDTool inclut également un outil permettant de repré- senter graphiquement les données contenues dans la base.

RRDTool est sous licence GNU GPL.

M A S T E R 1 - A S R - 2 0 0 7

(45)

7. B IBLIOGRAPHIE

RFC n°1157, Simple Network Management Protocol : http://www.alaide.com/rfc.php?doc_id=RFC1157 RFC n°3164, The BSD Syslog Protocol: http://www.alaide.com/rfc.php?doc_id=RFC3164

RFC n°3195, Reliable Delivery for Syslog : http://www.alaide.com/rfc.php?doc_id=RFC3195 Le protocole SNMP - en français : http://www.commentcamarche.net/internet/snmp.php3 Syslog, sur Wikipedia - en français : http://fr.wikipedia.org/wiki/Syslog

Exemple de fichiers de journalisation (log) - en français : http://etudiant.univ-mlv.fr/~slamps/exemples.php Site officiel de Snare : http://www.intersectalliance.com/

Ressources Snare : http://sourceforge.net/projects/snare/

Documentation SNMP : http://fr.wikipedia.org/wiki/Snmp Site officiel de Cacti : http://cacti.net/

Plugins pour Cacti : http://cactiusers.org/