PROJET D ADMINISTRATION RÉSEAUX - TRAFIC SNMP

Transcription

1 M A S T E R 1 - A S R Université d Evry PROJET D ADMINISTRATION RÉSEAUX - TRAFIC SNMP GROUPE PROJET : Philippe Perrault, Franck Ortiz, Emmanuel Bédrune o r t i z f r a n c g m a i l. c o m p e r r a u l t. p h i l i p p g m a i l. c o m e m m a n u e l. b e d r u n f r e e. f r

2 SOMMAIRE 1. Introduction Objet du projet Présentation du protocole Syslog Présentation du protocole SNMP 6 2. Outils Présentation des outils Cacti Snare Le Serveur Les agents Snare Cacti Description Installation Linux Windows Plugins Configuration Snare Description Configuration et options micro-server Installation Agent Installation de l agent Linux Configuration de l agent sous Linux par l interface Web Configuration de l agent sous Linux par l interface graphique 24 P a g e 2 s u r 45

3 Installation et configuration de l agent Windows Mise en oeuvre, Cacti et Adventnet Adventnet Simulation Toolkit Architecture Adventnet simulée Limites d Adventnet Interactions Cacti - Adventnet Conclusion Résultats Snare Cacti et Adventnet Résumé et remarques Snare Cacti et Adventnet annexes Simulation de trafic SNMP MIMIC SNMP Agent Simulator NetDecision SNMP Agent Simulator ireasoning SNMP Agent Simulator Snare Generator Exemple avec la configuration d un événement: Scénario Snare sous Windows Glossaire Bibliographie 45 P a g e 3 s u r 45

4 1. INTRODUCTION 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 donnerons les résultats obtenus ainsi que les problèmes rencontrés durant ce projet 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 P a g e 4 s u r 45

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. P a g e 5 s u r 45

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 : P a g e 6 s u r 45

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. P a g e 7 s u r 45

8 2. OUTILS 2.1. PRÉSENTATION DES OUTILS 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 requise. 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. P a g e 8 s u r 45

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 fonctionnalités de Cacti via un système de modules. C est précisément ce système de modules qui en fait un concurrent 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 possibilité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 pourront 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. P a g e 9 s u r 45

10 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 indisponibilité 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 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érences entre ces fichiers sont surlignées afin que soient prises les mesures de correction nécessaires. P a g e 10 s u r 45

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 systè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épertoires à 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énements, 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 recommandés. Le serveur Snare offre ainsi des possibilités très étendues, dont celle de surveillance de l espace pris par la base de donnée ou même de procéder à l archivage des logs vers support CD ou DVD. Tâche qu il est possible d automatiser. P a g e 11 s u r 45

12 Les agents Snare Comme dit précédemment, il existe également toute une collection d agents Snare permettant de remonter les évènements vers le serveur. Ils sont disponibles sur une large gamme de systèmes tels que Linux, Windows, Solaris, IIS, Lotus 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 devraient ê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 montrant 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. P a g e 12 s u r 45

13 2.2. CACTI 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 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 : Cacti Un serveur web (exemple : Apache ou Windows IIS) pour l accès aux pages web d administration de 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 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. P a g e 13 s u r 45

14 Installation 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 minimale 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 : il ne reste plus qu à installer les éventuels plugins et ajouter sur l interface de Cacti les machines à monitorer 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. P a g e 14 s u r 45

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 Plugins Afin de compléter les fonctionnalités de Cacti et l adapter un peu plus à notre besoin, nous allons lui ajouter les plugins : P a g e 15 s u r 45

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 modifie 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! 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 /24 par la passerelle Ici, pour l accès au réseau simulé par le serveur cacti : route add -net mask P a g e 16 s u r 45

17 M A S T E R 1 - A S R Université d Evry Le plugin «Thold» nécessite également une configuration que nous allons effectuer une fois connecté à l interface web de Cacti. o r t i z f r a n c g m a i l. c o m p e r r a u l t. p h i l i p p g m a i l. c o m e m m a n u e l. b e d r u n f r e e. f r

18 M A S T E R 1 - A S R Université d Evry 2.3. SNARE Description Snare vous permettra de récupérer sous forme de trames Syslog compatibles à la norme RFC la majorité des évènements 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 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 utiliserons 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 : o r t i z f r a n c g m a i l. c o m p e r r a u l t. p h i l i p p g m a i l. c o m e m m a n u e l. b e d r u n f r e e. f r

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. P a g e 19 s u r 45

20 Installation Agent 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: pour la version 2.4 et sur : 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 snare_ snare_i386.deb Une fois le noyau patché, il faut installer l audit avec la commande: dpkg -i --force-depends snare-gui _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. P a g e 20 s u r 45

21 M A S T E R 1 - A S R Université d Evry 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. o r t i z f r a n c g m a i l. c o m p e r r a u l t. p h i l i p p g m a i l. c o m e m m a n u e l. b e d r u n f r e e. f r

22 M A S T E R 1 - A S R Université d Evry 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: 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). o r t i z f r a n c g m a i l. c o m p e r r a u l t. p h i l i p p g m a i l. c o m e m m a n u e l. b e d r u n f r e e. f r

23 M A S T E R 1 - A S R Université d Evry 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. o r t i z f r a n c g m a i l. c o m p e r r a u l t. p h i l i p p g m a i l. c o m e m m a n u e l. b e d r u n f r e e. f r