UV libre Réseau : Système de Détection d Intrusions SNORT

Transcription

1 UV libre Réseau : Système de Détection d Intrusions SNORT Encadrants : Frédéric Baucher (professeur ASI), Samir Délimi (administrateur réseau ASI). Intervenant : Franck Le Guillous (administrateur réseau INSA). Département Architecture des Systèmes d Informations Institut National des Sciences Appliquées de Rouen 2002/2003

2 Sujet de l UV: Les objectifs de cette UV réseau étaient : Faire une étude générale des principes des différents types de Systèmes de Détection d Intrusions (IDS) avec les avantages et les inconvénients de chacun. Se renseigner sur l architecture du réseau informatique de l Institut National des Sciences Appliquées (INSA) de Rouen et plus particulièrement celui du département Architecture des Systèmes d Information (ASI). En collaboration avec les administrateurs de ce réseau, déterminer le(s) meilleur(s) emplacement(s) pour mettre en place Snort avec le meilleur choix technique au niveau matériel. Etudier l installation et la mise en place de Snort sur machine afin de réaliser un rapport technique pour sa mise en place ultérieure sur le réseau par les administrateurs. Voir les différentes configurations possibles. Voir les diverses possibilités offertes par un tel outil avec les principaux outils. Se renseigner et tester tout le nécessaire pour une mise en production de Snort : pour que le système soit viable, tant au niveau performances qu au niveau maintenance. 2

3 SOMMAIRE I. Introduction II. Les différents types d IDS A. IDS basé sur le réseau B. IDS basé sur l hôte C. IDS basé sur la pile III. Les avantages de chaque type d IDS A. Les avantages de l IDS basé sur le réseau B. Les avantages de l IDS basé sur l hôte C. L atout de chaque IDS en fonction de l attaque IV. Surveillance d une connexion switchée à Internet A. Le span port B. Hub C. Tap V. Emplacement de SNORT dans une l architecture A. Les phases de tests VI. Présentation de SNORT VII. Gestion des configurations : logiciels requis VIII. Guide de prise en main A. Installation de MySQL B. Installation de Snort C. Configuration de MySQL D. Connexion à la base de données E. Configuration de l accès aux règles F. Test de Snort IX. Réglages de Snort A. Réglages de snort : snort.conf Section 1 : réglage des variables réseau Section 2 : les préprocesseurs Section 3 : les modules de sortie Section 4 : choix des règles B. Adodb, gd, phplot, module MySQL pour PHP, librairies graphiques PHP, libgd, zlib, libpng, libjpeg C. Installation de Apache et PHP D. Gestion graphique de snort.conf : module webmin E. Plugins de sortie de Snort SnortSnarf snort Analysis Control for Intrusion Databases : ACID X. Gestion des règles A. Le réglage et l écriture de règles B. La mise à jour des règles C. Le choix des règles pour la sonde Snort Choix d un groupe de règles du même type Choix d une règle en particulier XI. Les différents modes de Snort A. Mode sniffeur

4 B. Mode enregistreur de paquets C. Mode détection d intrusions Options de sortie Configuration haute-performance Modifier l ordre des alertes Divers Le bruit dans les alertes Obtenir plus d information XII. Pour compléter ce travail XIII. Contacts XIV. Sources I. Introduction S.N.O.R.T est un IDS (c est-à-dire un Système de Détection d Intrusion en français) en réseau dont les sources sont libres de droits. Les IDS recherchent des signatures d attaques qui sont des marques spécifiques de tentatives malicieuses ou suspicieuses. 4

5 Les IDS se posent aujourd hui comme des outils indispensables dans la politique de sécurité des réseaux informatiques. Un réseau sécurisé dépourvu de système de détection d intrusion serait un peu comme une forteresse dans laquelle on ne laisserait entrer que les personnes en uniforme sans en faire le contrôle. L IDS vient en complément du simple pare-feu qui se trouve situé à l entrée des réseaux. Ces pare-feux, gardiens des réseaux, sont bien souvent de mauvais filtreurs vers les voies d accès inutilisées ou pouvant porter atteinte à l intégrité du réseau, notamment par les ports 80, 21, 79 ou autres. Ceux-ci obéissent à un certains nombre de règles définies par l administrateur du réseau, et celles-ci présentent bien souvent devant la complexité des protocoles et des communications à gérer sur les différents ports des failles que des pirates malintentionnés peuvent exploiter. Le port le plus exploité pour s infiltrer frauduleusement dans les réseaux apparaît comme étant le port 80, celui du Web. Les pare-feux ne suffisant pas, il faut donc les compléter avec un véritable système de surveillance : un Système de Détection d Intrusions qui sera chargé de contrôler en permanence l identité des requêtes en circulation sur le réseau. Ces systèmes sont indispensables pour parvenir à un niveau de sécurité vraiment optimal car ils sont les seuls à vérifier l identité de chaque requête en détail, en analysant le contenu de chaque trame. Ils peuvent ainsi détecter les intrus dans le flot du trafic courant qui transite sur les ports laissés ouverts par les ports laissés ouverts du pare-feu et entreprendre diverses actions (envoies de mail, interdire le trafic de l attaquant, ). L utilisation des IDS reste trop faible, car les administrateurs n ont pas conscience de l importance du problème et les réseaux d entreprises ou publics restent sous-équipés. Les systèmes de détection d intrusion commencent tout de même à percer, mais restent trop cantonnés aux frontaux ou aux zones ultra-sensibles, telles les zones démilitarisées (DMZ). Les coûts d installation et de maintenance de SNORT sont nuls car SNORT est libre de droits et facilement téléchargeable sur Internet ( Malgré ça, il faut prendre le temps de se pencher sur l outil pour bien comprendre la détection d intrusion et la manière de configurer SNORT en vue d une utilisation optimale. En effet, une charge de travail supplémentaire va venir s ajouter pour l administrateur pour que l IDS ne tombe pas aux oubliettes et restent à mis à jour dans la surveillance du réseau. Tous les IDS sont en quelques sortes des sondes, qui vont comparer le flot de données qu elles analysent aux attaques dûment répertoriées dans leurs propres bases de données. Les attaques qui sont listées n ont donc aucune chance de ne pas être détectées. L efficacité d un IDS demeure importante, à condition de veiller chaque jour au bon fonctionnement du système, et d installer le bon IDS au bon endroit sur le réseau contre les attaques internes (80% du total) et externes. II. Les différents types d IDS Lorsque les IDS cherchent des signatures d attaques dans le trafic du réseau via une interface en mode promiscuité, ils sont alors considérés comme des IDS basés sur le réseau (Network Based IDS). 5

6 Le second type d IDS est l IDS basé sur un hôte (Host Based IDS). Il en existe trois formes: la première examine les logs de l hôte cherchant les traces d une attaque, la seconde examine les traces dans le trafic du réseau (comme l IDS basé sur le réseau en mode promiscuité), la troisième est une solution qui exécute à la fois l IDS basé sur les logs et sur la pile. A. IDS basé sur le réseau L IDS basé sur le réseau utilise les paquets bruts du réseau comme sources de données. Il utilisé typiquement une interface réseau en mode promiscuité qui écoute et analyse tout le trafic en temps réel lors de son parcours sur le réseau. Un premier filtre est normalement appliqué pour déterminer quel trafic doit être analysé pour un module de reconnaissance d attaque de celui qui doit être ignoré. Ce premier niveau aide à la performance de l IDS et à sa précision pour rejeter le trafic qui n est pas dangereux. Ce filtre doit être bien réglé pour ne pas laisser passer trop de trafic ou au contraire trop en filtrer. Dans le module de reconnaissance d attaque, l une des trois méthodologies sont typiquement utilisées pour les signatures d attaques, la détection est basé sur la trajectoire, la fréquence, les anomalies. Une fois qu une attaque est détectée, un module de réponse fournit une variété d options pour notifier, alerter, et agir en fonction du type d attaque. B. IDS basé sur l hôte Ce type d IDS date du début des années 80 et des réseaux. Aujourd hui ils sont utilisent des audits de logs variés qui sont automatisés, sophistiqués et en temps réel avec leurs détections et leurs réponses. Les systèmes basés sur l hôte utilisent des logiciels qui surveillent de manière continue les logs spécifiques. Sur Windows NT, ceux-ci incluent systèmes, évènements, et logs de sécurité tandis que sur la plupart des UNIX, ils comprennent Syslog et les fichiers de log spécifiques au Système d Exploitation. Dès qu il y a un changement dans ces fichiers, l IDS compare l information avec ce qui est configuré dans la politique de sécurité en place et répond alors en accord avec le changement. Une méthode de ce type d IDS est de surveiller l activité des logs en temps réel, tandis que d autres solutions consistent à faire tourner des processus qui vérifient périodiquement les logs pour les nouvelles informations et les changements. La détection et la réponse sont alors considérées quasi temps réel avec une fréquence élevée. L IDS basé sur l hôte peut aussi écouté l activité d un port et alerter lorsqu il y a des accès sur des ports spécifiques. C. IDS basé sur la pile 6

7 Il s agit de la dernière technologie d IDS et varie énormément d un vendeur à un autre. Ce type d IDS travaille avec la pile TCP/IP, permettant aux paquets d être analysés tandis qu ils traversent les couches du modèles OSI en montant. Cette analyse permet de rejeter les paquets hors de la pile avant qu ils ne soient traités par l OS ou la couche Application. De plus, ces IDS peuvent analyser le trafic du réseau entrant et sortant sur le système. En surveillant les paquets du réseau destinés à un seul hôte, le principe est que l IDS prenne peu de ressources et puisse être installé sur toutes les machines du réseau. III. Les avantages de chaque type d IDS A. Les avantages de l IDS basé sur le réseau L IDS basé sur le réseau a des avantages dû à sa capture de paquets et son analyse en temps réel qui ne peuvent pas être facilement réalisés avec un IDS basé sur un hôte. Les principaux avantages qui en font un élément de sécurité nécessaire à un réseau sont: 1. Le coût de propriété L IDS basé sur le réseau permet un déploiement stratégique aux points critiques et ne nécessite donc pas de charger et manager des programmes sur des hôtes différents comme l IDS basé sur l hôte. Avec peu de points de détection, le coût de gestion devient plus efficace pour un environnement d entreprise. 2. L analyse de paquets L IDS basé sur le réseau examine tous les entêtes de paquets pour détecter les signes d une activité suspicieuse et malicieuse. Beaucoup d attaques avec «denial of service» basées sur l IP sont détectées en regardant les entêtes de paquets qui traversent le réseau. Avec le temps réel, ce type d IDS peut détecter de suite les attaques éclairs. Il peut aussi détecter les attaques qui utilisent des paquets fragmentés. L IDS basé sur l hôte ne peut pas détecter ces deux types d attaques. En plus d analyser les entêtes, l IDS basé sur le réseau peut aussi inspecter le contenu de la charge utile des paquets pour voir les commandes ou la syntaxe utilisée dans une variété d attaques. L IDS basé sur l hôte ne peut pas non plus détecter ce type d attaque. 7

8 3. La preuve de l effacement L IDS basé sur le réseau utilise la détection en temps réel. Une fois capturées, les données contiennent l attaque et les informations pour l identification du pirate. L IDS basé sur l hôte s est montré vulnérable car dans certains cas les pirates effaçaient ou altéraient ces informations connaissant leur emplacement. 4. La détection et la réponse en temps réel L IDS basé sur le réseau détecte l attaque en temps réel et permet donc une réponse immédiate( pour stopper son attaque par exemple ou récolter davantage d informations sur le pirate). 5. La détection d une intention malicieuse L IDS basé sur le réseau peut, bien qu il soit situé derrière le pare-feu et que celui-ci ait rejeté des tentatives d attaques, détecté celles-ci. L IDS basé sur l hôte ne peut pas car l attaque n a pas atteint l hôte. 6. Le complément et la vérification L IDS basé sur le réseau peut aussi complété des composants existants de la politique de sécurité mise en place. Il peut par exemple détecté du trafic non-crypté qui devrait l être. Il peut venir en complément d un pare-feu, pour vérifier si ses règles sont effectivement bien respectées. 7. L indépendance des Systèmes d Exploitation L IDS basé sur le réseau est indépendant du système d exploitation sur lequel il tourne, pas comme l IDS basé sur l hôte. Une solution basée sur un hôte nécessite que le Système d Exploitation fonctionne correctement et ne soit pas corrompu de quelque manière que ce soit. B. Les avantages de l IDS basé sur l hôte Un IDS basé sur l hôte tourne sur des hôtes spécifiques et utilise les informations fournies par le Système d Exploitation, cela ajoute des capacités qu il n y a pas avec l IDS basé sur le réseau. Les avantages de ce type d IDS sont : 1. La vérification d attaque 8

9 L IDS basé sur l hôte contient des enregistrements qui permettent de savoir si des attaques ou des exploits ont été fructueux. Ce type de détection apparaît comme moins sujet à avoir de fausses alertes. Les IDS basés sur le réseau ne savent pas si une attaque a déjà réussie ou pas. 2. L activité spécifique à un système L IDS basé sur l hôte peut surveiller en permanence l activité des utilisateurs et l accès aux fichiers. Toutes les procédures de connexion et de déconnexion peuvent être surveillées en suivant la politique de sécurité. Il peut vérifier les droits d un utilisateur à accéder à un fichier, surveiller l activité qui ne devrait être réalisée que par un administrateur lui-même. L ajout, la modification et la suppression d un utilisateur est détectée immédiatement. Si des changements dans la politique d audit de sécurité sont effectuées affectant ce que le système enregistre ou pas, toute cette activité sera alors collectée. L IDS basé sur le réseau ne peut pas détecter ces types de changement administrateur. 3. Les environnements cryptés et commutés Les logiciels IDS basés sur l hôte sont implantés sur des hôtes variés à travers l entreprise ce qui leur permet de surmonter des difficultés auxquels les IDS basés sur le réseau font face. Dans un environnement purement commuté avec des segments et des domaines de collision séparés, c est un véritable challenge de déployer un IDS basé sur le réseau car il ne peut résider que sur un segment à la fois et plusieurs ont besoin d être protégés. Avec l IDS basé sur l hôte, il suffit d en déployer sur plusieurs hôtes critiques. Le cryptage est aussi un challenge pour l IDS basé sur le réseau, car celle-ci dépend du lieu où elle réside dans la pile de protocoles. Ce type d attaque laisse l IDS basé sur le réseau aveugle. Il n y a pas ce problème avec l IDS basé sur l hôte, car l IDS basé sur la pile qu il contient, lui permet d analyser les paquets cryptés avant que le Système d Exploitation ou l Application aient vu les paquets, après que la couche TCP/IP ait décodé les paquets. 4. La surveillance de composants clés L IDS basé sur l hôte permet de surveiller les composants clés plus en détails, comme les registres, les DLL pour Windows NT, tous les fichiers qui pourraient servir à ouvrir des brèches dans la sécurité. La limitation de l usage de l espace disque peut être surveillée et alertée lorsque certains niveaux sont atteints, si un pirate utilise votre disque dur pour du stockage par exemple. Un IDS basé sur le réseau ne peut pas détecter ce type d attaque. 5. La détection et la réponse en quasi-temps réel Un IDS basé sur l hôte peut être lorsqu il est bien implémenté, quasi-temps réel. Des intervalles de surveillances des fichiers de logs sont mis en place. La plupart des IDS 9

10 basés sur l hôte peuvent aujourd hui détecter immédiatement une attaque, la comparer aux signatures d attaques et la stopper avant que des dommages ne soient causés. 6. La détection et la réponse en temps réel L IDS basé sur la pile peut examiner en temps réel les paquets entrants et sortants et déterminer en temps réel si une attaque est exécutée, ce qui permet une réponse en temps réel. 7. Pas de matériel en plus L IDS basé sur l hôte ne nécessite pas de matériel en plus, il réside sur les ressources réseaux déjà existantes (serveurs de fichiers, serveurs Web, et les autres ressources partagées ou critiques). Il permet d économiser de l argent, et ne nécessite donc pas sur le réseau une «boîte» avec adresse, maintenance, et gestion. 8. Firecell Firecell est une technologie qui fait partie de la sonde du serveur IDS basé sur la pile. Il s agit d une sorte de pare-feu avec des règles qui permet de rejeter des paquets. Si les serveurs http sont interdits dans une entreprise, la règle qui correspond va alors rejeter tous les paquets qui arrivent sur le port 80. C. L atout de chaque IDS en fonction de l attaque Les 2 types d IDS ont leurs propres avantages l un sur l autre. Dans le futur, les IDS devrait à la fois intégré un composant réseau et un composant hôte pour améliorer la résistance du système à une attaque. 10

11 IV. Surveillance d une connexion switchée à Internet Il y a principalement 3 façons de mettre sur écoute une connexion commutée, chacune d entre elle a ses avantages et ses désavantages. Ces trois méthodes sont : TAPS, Hub et Recouvrement de ports. Imaginons que nous ayons un switch connecté à un routeur : 11

12 A. Le span port L analyseur de port de Switch (SPAN) est typiquement mis en place pour être utilisé par un sniffeur de réseau pour surveiller le trafic. Le switch est configuré pour copier le TX (émission) /RX (réception) / et les 2 à la fois d un port ou VLAN vers un autre port. Dans le cas de figure ci-dessous, le switch est configuré de manière à spanner à la fois le RX et le TX du port auquel le routeur est connecté vers le port auquel l IDS est connecté. L IDS peut ainsi surveiller tout le trafic entre ces deux éléments actifs de réseau (ex : entre Internet et un réseau). Les avantages de cette solution : La facilité d installation : l IDS peut être placé sans modifier le cœur de l infrastructure. La gestion de l IDS ne nécessite pas de matériel en plus ou des changements dans la configuration. Les sessions de résiliation et les reconfigurations de pare-feu ne sont pas influencées. Les désavantages de cette solution : Un seul port peut être spanné. Pour en surveiller plus d un, on doit spanner une gamme de ports (ex : ports de 1-5) ou spanner un VLAN entier. 12

13 Spanner plus d un port n est pas faisable en full-duplex à cause d une surcharge. Sans changement additionnel sur l IDS, il est vulnérable aux attaques. Ceci peut être évité en implémentant l IDS en mode discret (Stealth) qui consiste à utiliser 2 cartes d interface dans l IDS. La carte de surveillance a tous les protocoles de réseau non liés à partir de la carte. Ceci empêche l interface exposée d être attaquée. La seconde interface est alors routée vers un LAN de management via un réseau sécurisé. Sans utiliser une configuration discrète, les alertes générées par l IDS peut générer des problèmes avec la surcharge de port. Dégradation des performances du switch. Des ports spannés sont unidirectionnels donc les sessions de résiliation ne sont pas supportées. Incapacité à refléter les erreurs tels que les paquets avec des tailles trop petites, trop grandes et des paquets avec un mauvais CRC. B. Hub Cette configuration n est pas conseillée car les chances de causer un problème réseau majeur sont élevées. Utiliser des hubs ou des taps est très similaire; ils sont placés entre les connexions à surveiller (entre un routeur et un switch, ou un serveur et un switch, etc). Dans la configuration ci-dessous, le hub copie l intégralité du trafic qu il reçoit du routeur vers le switch. 13

14 Les avantages de cette solution : Facilité de configuration. Aucun matériel en plus n est nécessaire pour configurer ou manager l IDS. Les sessions de résiliation et les reconfigurations de pare-feu ne sont pas influencées. Les hubs 4 ports sont très économiques. Les désavantages de cette solution : A cause de la limitation des médias partagées, cette solution ne peut pas être utilisée si la connexion entre le routeur et le switch est en full-duplex, car les collisions vont dégrader le signal. Pour la même raison, la gestion de l ISD à travers le hub va augmenter le nombre de collisions, ayant ainsi un impact sur le flot de trafic entre le routeur et le switch. Le faible coût des hubs peut induire des défaillances. C. Tap La solution Tap est très similaire à la solution Hub. L intérêt principal du Tap, est qu il sépare les flots qui les traversent suivant le sens : ils peuvent ainsi séparés le TX et le RX. Des sondes peuvent alors être placées pour analyser un flot seulement montant ou seulement descendant. Les taps sont de conception résistants aux coupures de courant avec une alimentation incorporée. Une fois que le tap est en place, il existe plusieurs manières de router le trafic qu il collecte. 14

15 Les configurations d un tap diffèrent par le nombre de connexions qu il surveille (1, 4, 8 et 12 ports). Les avantages de cette solution : Résiste aux coupures de courant sur la connexion entre routeur et switch et ne nécessite pas d énergie pour fonctionner. Tap n influe pas sur le flot de trafic. Une fois que tap est en place, les changements sur l IDS n influent pas sur l ensemble du réseau. Les connexions directes à l IDS sont prohibées, celui-ci est donc protégé des attaques. V. Emplacement de SNORT dans une l architecture CENSURE A. Les phases de tests Etapes de tests: Pour tester la détection des attaques par SNORT, l installation, la configuration : 15

16 C est la solution de tests la plus simple à mettre en place car elle peut ne nécessiter que 2 machines : l une à la fois Attaque et Victime (le hub renvoie l attaque vers l expéditeur de celle-ci) et l autre dédiée à la sonde SNORT. Bien entendu, il serait possible de mettre une 3 ème machine en dissociant Attaque et Victime par exemple. Pour tester l exécution des règles par exemple en contactant d autres machines sur le réseau et en faisant une surveillance interne du réseau. Cette étape de tests constitue le début de la mise en place des sondes SNORT sur les (sous) réseaux 16

17 Cette dernière étape de tests constitue la première configuration d installation de SNORT sur le réseau. Pour cela nous allons mettre en place une machine Attaque avant le switch et la sonde SNORT également avant le switch (voir schéma cidessous). Grâce à une duplication de port en monitorant le switch, la sonde SNORT va également recevoir les attaques orientées vers les réseaux qui partent du switch. 17

18 VI. Présentation de SNORT Nous allons maintenant nous atteler à la présentation du Système de Détection d Intrusion étudié SNORT à partir du man anglophone. SNORT est, comme nous l avons déjà dit un Système de Détection d Intrusion réseau en sources ouvertes, capable d effectuer l analyse du trafic sur un réseau en temps réel et de la journalisation de paquets sur des réseaux IP. Il peut effectuer de l analyse de protocoles, de la recherche / correspondance de contenu et peut être utilisé pour détecter une variété d attaques et de scannages listés dans sa base de données, tels que des débordements de tampons, des scannages de ports furtifs, des attaques CGI, des scannages SMB, des tentatives d identification d OS, et bien plus. SNORT utilise un ensemble de règles flexibles pour décrire le trafic qu il doit collecter ou laisser passer, ainsi qu une architecture modulaire de plugins. Il possède aussi des capacités modulaires d alertes temps réel, incorporant des plugins d alerte et de journalisation pour syslog, de fichiers textes en ASCII, de sockets UNIX, de messages WinPopup à des clients Windows en utilisant smbclient de Samba, de base de données (MySQL / PostgreSQL / Oracle / ODBC) ou XML. SNORT a fondamentalement 3 utilités : Sniffer le réseau comme un simple renifleur de paquets comme tcpdump. Générer des logs comme un enregistreurs de paquets (utile pour déboguer le trafic réseau, etc). Détecter des intrusions comme un système complet de détection d intrusion réseau. Apprendre le fonctionnement de SNORT ne pause pas trop de problèmes, c est sa mise en œuvre qui demande davantage d efforts. Mais de très bonnes documentations sont disponibles sur Internet, notamment sur le site officiel en langue anglaise : VII. Gestion des configurations : logiciels requis Dans notre cas, l installation sera effectuée sur une distribution Woody Debian de Linux. Les versions des différents packages utilisés sont explicitées ci-dessous, mais il est conseillé de toujours utiliser les versions les plus récentes mises à disposition sur le Web, car des bogues et divers problèmes sont résolues au fur et à mesure du temps. o Snort v

19 Logiciel de Détection d Intrusions capable de faire une analyse du trafic en temps réel et du log de paquets sur des réseaux IP. Il constitue un ensemble de logiciels pour collecter les informations d un réseau. o Librairie libpcap-dev Libpcap est une librairie qui permet aux applications de capturer des paquets sur un réseau, sauver ces paquets capturés dans un fichier puis de relire ces fichiers. Elle peut être utilisée par les applications comme les analyseurs de réseaux (comme tcpdump). o Webmin v1.x Webmin est une interface web pour administrer les serveurs installés sur la machine Linux. Il fournit une interface graphique pour la plupart des services et des options de configuration qui sont disponibles au niveau de la ligne de commande. Webmin est écrit en Perl et de nouveaux modules (plugins) sont créés régulièrement. Parmi ceuxci, il y a un module Snort qui permet d administrer Snort graphiquement. (ci-dessous) o Snort Webmin Module v1.1 o MySQL v4.0 Standard (serveur, client, headers) MySQL est un serveur de Base de Données pour une grande variété de plate-formes et il est le mieux supporté pour stocker les alertes Snort. Toutes les alertes sont stockées dans la base MySQL. o Apache v Apache est le serveur Web de la majorité des sites de la toile. Le seul but d Apache est d héberger la console Web ACID. o ACID v0.9.6b21 ACID est une application Web pour voir les logs d un pare-feu ou/et les alertes d un Système de Détection d Intrusion. C est là où sont traitées toutes les informations pour être visualisées. 19

20 o o o o o PHP v Module PHP-MySQL ADODB v2.x PHPLOT v GD v o SnortSnarf v Un autre module de sortie pour visualiser les résultats obtenus par la sonde SNORT. VIII. Guide de prise en main La procédure d installation, détaillée par la suite étape par étape, en est une parmi tant d autres dans le monde Linux. Suivie consciencieusement, elle doit permettre à l utilisateur de mettre convenablement en place une sonde Snort avec les quelques outils indispensables. Ce petit guide de prise en main doit permettre de rendre Snort fonctionnel avec le minimum d opérations nécessaires à cela. Dans la partie qui suit nous aborderons les réglages de Snort et des logiciels utiles pour le rendre réellement fonctionnel. 2 options principales s offrent à l utilisateur concernant le stockage des résultats obtenus à partir de la sonde Snort installée : Stocker les résultats dans des fichiers : la solution la plus simple et la plus rapide à mettre en place, mais impensable dans le contexte de surveillance d un réseau à long terme et le stockage d une grande quantité d informations avec archivage. Stocker les résultats dans une base de données : un peu plus lourde à mettre en place, mais beaucoup plus souple, performante et raisonnable pour assurer la sécurité d un réseau devant la grande quantité d informations à stocker et à traiter. C est cette méthode avec les composants nécessaires à installer qui sera expliciter par la suite. A. Installation de MySQL 20

21 Nous allons dans un premier temps installer un Système de Gestion de Base de Données sur notre Linux. Cette base servira à stocker les alertes et les différentes informations relatives aux attaques détectées par notre sonde Snort. Ici, il s agit de MySQL. Snort peut fonctionner avec différentes base de données telles que PostgreSQL, Oracle pour ne citer que celles-ci. Dans notre cas, nous avons choisi MySQL pour sa simplicité d utilisation, le fait qu elle soit OpenSource et très bien adaptée à l utilisation qu en fait Snort. Dans notre cas, il s agit de la version 4.0 standard de MySQL, qui inclut à la fois le côté serveur et client de MySQL. Après avoir récupérer les sources, il faut les décompresser et les compiler. #./configure # make # make install Remarque: Cette remarque vaut pour tous les différents logiciels que nous allons installer. La plupart du temps, certains de ces logiciels seront déjà installés par défaut avec la distribution Linux concernée. Il est préférable de les désintaller lorsqu ils sont déjà présents pour faire une installation plus claire et avec les options de compilation et d exécution nécessaires à l administrateur et aux différents utilisateurs. B. Installation de Snort Dans notre cas le répertoire de travail sera /etc/snort. A partir du package Snort téléchargé : # cp snort tar.gz /etc/snort # cd /etc/snort # tar xzvf snort tar.gz # cd /etc/snort/snort #./configure with-mysql # make # make install La commande./configure prend l option with-mysql pour prendre en compte le support de base de données MySQL. C. Configuration de MySQL Nous allons à cette étape-ci, régler MySQL en créant les différents utilisateurs et la base de données qui sera associée à Snort. Affectation d un mot de passe à root et création de la base de données associée à Snort. 21

22 # mysql u root mysql> set password for localhost =password( mot_de_passe_root) ; mysql> create database snort; mysql> exit Note: Pour démarrer le service mysql au run level 3 si nécessaire. # chkconfig level 3 mysql on Après l étape précédente, il est nécessaire de rentrer un mot de passe pour se connecter à la base en tant que root. Par exmple : # mysql u root p Les tables de la base de données ont maintenant besoin d être installées. Ceci est fait à partir du script de création de base contenu dans Snort, dans notre cas, /etc/snort/snort-1.9.0/contrib. Comme on peut le voir, il y a les scripts pour l ensemble des bases auxquelles Snort peut se connecter, ici nous nous intéresserons à celui spécifique à MySQL : create_mysql. On se place donc dans le répertoire /etc/snort/snort-1.9.0/contrib pour utiliser ce script. # cd /etc/snort/snort-1.9.0/contrib Création des tables de la base de données. # mysql u root p mysql> connect snort mysql> source create_mysql Autre solution pour la création des tables de la base: # mysql D snort u root < create_mysql Création des utilisateurs avec leurs droits. Dans notre cas, nous allons créer 2 utilisateurs : 1 utilisateur snort avec tous les droits d administrateur. 1 utilisateur acidviewer avec des droits limités sur la base qui ne pourra pas effacer d enregistrements. mysql> grant CREATE, INSERT, SELECT, DELETE, UPDATE on snort.* to snort; On peut désormais se connecter localement avec ce compte snort qui possède tous les droits. mysql> grant CREATE, INSERT, SELECT, DELETE, UPDATE on snort.* to snort@localhost; On crée également un compte acidviewer avec des droits restreints, qui ne pourra pas effacer les alertes de la base de données. mysql> grant CREATE, INSERT, SELECT, UPDATE on snort.* to acidviewer; Pour se connecter localement avec ce compte. 22

23 mysql> grant CREATE, INSERT, SELECT, UPDATE on snort.* to Mise en place des mots de passe pour ces comptes. mysql> connect mysql mysql> set password for localhost =password( mot_de_passe_snort_local ); mysql> set password for % =password( mot_de_passe_snort ); mysql> set password for localhost =password( mot_de_passe_acidviewer _local ); mysql> set password for % =password( mot_de_passe_acidviewer ); mysql> flush privileges; mysql> exit D. Connexion à la base de données Une fois MySQL installé et configuré en ayant suivi les étapes précédentes, la dernière étape pour rendre Snort fonctionnel, est que Snort se connecte à la base «snort» qui vient d être créer pour y stocker outes les alertes, les attaques détectées avec toutes les informations nécessaires. Tous les paramètres à régler de Snort se trouve dans le fichier snort.conf situé dans le répertoire /etc/snort/snort-1.9.0/etc. On se place dans ce répertoire. # cd /etc/snort/snort-1.9.0/etc Puis on ouvre le fichier de configuration de Snort avec un éditeur (VI, Emacs, nano, ). Dans la section 3 de ce fichier, qui correspond à la configuration des plugins de sortie, nous nous plaçons à la partie base de données. Il faut alors décommenter la ligne correspondant à MySQL en supprimant le # en début de ligne, puis rentrer les informations nécessaires : user, password, dbname et host. L utilisateur correspond à celui qui a les droits administrateurs que nous avons créé précédemment. Voici un extrait du fichier snort.conf concerné : # database: log to a variety of databases # # See the README.database file for more information about configuring # and using this plugin. # output database: log, mysql, user=snort password=snort dbname=snort host=localhost E. Configuration de l accès aux règles 23

24 Une fois toutes les étapes précédentes réalisées, il reste un dernier réglage à réaliser toujours dans le fichier snort.conf. Il s agit de spécifier à Snort l emplacement des règles ou plutôt des signatures qu il va devoir surveiller. Dans la section 1 de ce fichier se trouve la variable RULE_PATH qu il faut régler convenablement avec un chemin relatif ou absolu. Le répertoire contenant l ensemble des règles peut être placé à l endroit désiré par l utilisateur. Dans notre cas, nous conserverons l emplacement initial lors de l installation de Snort pour lequel cette variable est déjà réglée par défaut, à savoir dans notre cas : /etc/snort/snort-1.9.0/rules. # Path to your rules files (this can be a relative path) var RULE_PATH../rules F. Test de Snort Lorsque l utilisateur a convenablement effectué toutes les étapes précédentes, Snort doit alors être fonctionnel. L utilisateur peut alors réaliser un test en lançant l application Snort, pour voir si celui-ci se lance correctement, à savoir notamment : si les règles sont bien trouvées, si ce n est pas le cas la variable RULE_PATH de snort.conf est mal configurée ou il n y a pas les bons droits d accès aux fichiers. si la connexion à la base de données par Snort s effectue correctement, si ce n est pas la cas, les utilisateurs ou la base de données sont mal configurés dans MySQL, ou il y a de mauvais réglages dans le fichier snort.conf. Pour lancer Snort, on se place dans le répertoire /etc/snort/snort-1.9.0/src et on lance l exécutable snort. # cd /etc/snort/snort-1.9.0/src #./snort A full c../etc/snort.conf L option c correspond à l emplacement du fichier snort.conf de Snort. Par défaut, ce fichier se trouve bien dans le répertoire /etc/snort/snort-1.9.0/etc. L utilisateur peut le placer ailleurs, il faut alors qu il modifie le chemin à ce fichier. Lorsque Snort est lancé avec cette commande dans une console, toutes les informations qui concernent son initialisation sont affichées : le nombre de règles trouvées, la connexion à la base, En cas de problème, il suffit de voir ce qui s affiche dans la console et en chercher la source. 24

25 IX. Réglages de Snort Une fois que Snort a été rendu fonctionnel dans la partie précédente, il faut maintenant le régler correctement en fonction des attentes de l utilisateur, de la configuration de son réseau et mettre en forme les résultats obtenus avec les outils nécessaires. A. Réglages de snort : snort.conf Tous les paramètres à régler de Snort se trouvent dans le fichier snort.conf situé dans le répertoire /etc/snort/snort-1.9.0/etc. Dans ce fichier comme dans la plupart des fichiers de configuration sous Linux, une quantité importante d informations est fournie en commentaire pour permettre à l utilisateur de connaître l utilité de chaque section, de chaque variable et être capable de faire une configuration correcte. Cette partie décrit les différentes sections de ce fichier snort.conf. L utilisateur peut aller modifier directement ce fichier avec un éditeur de texte, (ce qui me semble la meilleure solution), ou utiliser le module Snort de Webmin explicité plus loin dans ce rapport en utilisant une interface graphique. On se place dans ce répertoire. # cd /etc/snort/snort-1.9.0/etc Puis on ouvre le fichier de configuration de Snort avec un éditeur (VI, Emacs, nano, ). 1. Section 1 : réglage des variables réseau La configuration d un Système de Détection d Intrusion sur un réseau dépend naturellement de la topologie de ce réseau, de ses plages d adresses, des serveurs dont il est équipé, Par défaut, Snort va analyser toutes les paquets de toutes les adresses IP du réseau. En effet, la variable la plus importante HOME_NET est réglée comme suit : var HOME_NET any Si l utilisateur, ne veut analyser les paquets que de certaines adresses IP, il peut rentrer des intervalles d adresses, des IP particulières, etc. Un grand nombre d exemples lui sont fournis en commentaires dans cette section. Il peut également configurer les adresses IP et les ports des serveurs SMTP, AIM, présents sur son réseau, pour avoir une analyse plus performante et éliminer pas mal de bruit parmi les attaques. 25

26 Si l utilisateur n est pas sûr ou n a pas une connaissance certaine de son réseau, il peut laisser les paramètres par défaut. Snort fera ainsi une analyse de toutes les signatures de tous les paquets qui passent sur le réseau. 2. Section 2 : les préprocesseurs Les préprocesseurs ont été introduits dans la version 1.5 de Snort. Ils permettent d étendre les fonctionnalités de Snort en autorisant les utilisateurs et les programmeurs à rajouter ou supprimer des modules facilement. Le code d un préprocesseur est exécuté avant que l engin de détection ne soit appelé, mais après que le paquet ait été décodé. Le paquet peut être modifié ou analysé. Les préprocesseurs sont chargés et configurés en utilisant le préprocesseur de mot-clef. Le format de directive d un préprocesseur est de la forme: preprocessor <name> : <options> Les préprocesseurs: minfrag, HTTP decode, Portscan Detector, Portscan Ignorehosts, Defrag, Frag2, Stream4, Spade, Back Orifice, RPC decode, ARPspoof, Les informations concernant leur fonction et leur configuration sont fournies en commentaires dans le fichier snort.conf. Pour mettre utiliser un préprocesseur, il suffit de le décommenter et de mettre les options correspondantes. Dans notre cas, nous avons laissé cette section telle quelle avec les préprocesseurs déjà sélectionnés. 3. Section 3 : les modules de sortie Les modules de sortie ont été introduits dans la version 1.6. Ils permettent à Snort d être plus souple dans la mise en forme et la présentation de la sortie aux utilisateurs. Les modules de sortie fonctionnent lorsque les sous-systèmes d alerte ou de logging de Snort sont appelés, après les préprocesseurs et l engin de détection. Le format des directives est très celui des préprocesseurs. De multiple modules de sortie peuvent être spécifiés dans le fichier de configuration de Snort. Lorsque plusieurs modules du même type (log, alert) sont spécifiés, ils sont empilés et appelés en séquence lorsqu un événement survient. Comme les systèmes standards de logs et d alertes, les modules de sortie envoient leurs données dans /var/log/snort par défaut ou un répertoire utilisateur spécifié avec l option l en ligne de commande. Les modules de sortie sont chargés lors de l exécution en spécifiant le mot clef de sortie : 26

27 output <name> : <options> Pour mettre utiliser un module de sortie, il suffit de le décommenter et de mettre les options correspondantes. Dans notre cas, nous n avons spécifié que les paramètres de sortie pour se connecter à la base de données «snort» (cf ci-dessus). 4. Section 4 : choix des règles Cette section de snort.conf est une suite d «include» de fichiers de règles. En effet, les règles pour un certain type d attaques sont regroupées dans un même fichier au nom explicite avec l extension «.rules» dans le répertoire rules, par exemple : ddos.rules, dns.rules, Pour que Snort utilise un fichier de règles, il suffit que cette ligne soit décommenter. Pour omettre un fichier de règles, il faut commenter la ligne avec un #. #========================================= # Include all relevant rulesets here # # shellcode, policy, info, backdoor, and virus rulesets are # disabled by default. These require tuning and maintance. # Please read the included specific file for more information. #========================================= include $RULE_PATH/bad-traffic.rules include $RULE_PATH/exploit.rules include $RULE_PATH/scan.rules include $RULE_PATH/finger.rules include $RULE_PATH/ftp.rules include $RULE_PATH/telnet.rules include $RULE_PATH/rpc.rules include $RULE_PATH/rservices.rules include $RULE_PATH/dos.rules include $RULE_PATH/ddos.rules include $RULE_PATH/dns.rules include $RULE_PATH/tftp.rules include $RULE_PATH/web-cgi.rules include $RULE_PATH/web-coldfusion.rules include $RULE_PATH/web-iis.rules include $RULE_PATH/web-frontpage.rules include $RULE_PATH/web-misc.rules include $RULE_PATH/web-client.rules include $RULE_PATH/web-php.rules include $RULE_PATH/sql.rules include $RULE_PATH/x11.rules include $RULE_PATH/icmp.rules include $RULE_PATH/netbios.rules include $RULE_PATH/misc.rules include $RULE_PATH/attack-responses.rules include $RULE_PATH/oracle.rules 27

28 include $RULE_PATH/mysql.rules include $RULE_PATH/snmp.rules include $RULE_PATH/smtp.rules include $RULE_PATH/imap.rules include $RULE_PATH/pop3.rules include $RULE_PATH/nntp.rules include $RULE_PATH/other-ids.rules # include $RULE_PATH/web-attacks.rules # include $RULE_PATH/backdoor.rules # include $RULE_PATH/shellcode.rules # include $RULE_PATH/policy.rules # include $RULE_PATH/porn.rules # include $RULE_PATH/info.rules # include $RULE_PATH/icmp-info.rules # include $RULE_PATH/virus.rules # include $RULE_PATH/chat.rules # include $RULE_PATH/multimedia.rules # include $RULE_PATH/p2p.rules include $RULE_PATH/experimental.rules include $RULE_PATH/local.rules Il est également possible de sélectionner les signatures individuellement dans les fichiers «.rules» en commentant ou non les lignes de la même manière. Pour la gestion des règles par l utilisateur, nous verrons une gestion graphique des règles avec un module de Webmin. B. Adodb, gd, phplot, module MySQL pour PHP, librairies graphiques PHP, libgd, zlib, libpng, libjpeg Ces logiciels seront par la suite utile pour PHP et le plugin de sortie Snort ACID, notamment dans la connexion à MySQL et la génération de graphiques. Je ne détaillerai que l installation de adodb, gd et phplot. A charge à l utilisateur d installer les librairies utiles pour la suite de la liste ci-dessus. Adodb, gd, phplot Nous placerons par la suite la racine de notre serveur Web au répertoire : /var/www. On se place donc à cet endroit de l arborescence de fichiers. Puis, on crée un répertoire html. # cd /var/www # mkdir html Après avoir téléchargé les sources correspondantes, on les décompresse. 28

29 # tar xzvf adodb2.x.tgz C /var/www/html # tar xzvf gd tgz C /var/www/html # tar xzvf phplot tgz C /var/www/html Une fois ces sources décompressées, on renomme les dossiers pour enlever les numéros de versions. # mv adodb2.x adodb # mv gd gd # mv phplot phplot pour gd On se place dans le répertoire /var/www/html/gd, puis on exécute les scripts. # cd /var/www/html/gd #./configure prefix=/usr # make # make install Par la suite, on exécutera un patch gd pour PHP. Ici graphique généré pour tester la bonne configuration de phplot et la librairie graphique GD. C. Installation de Apache et PHP 29

30 Pour utiliser les plugins de sortie Web de Snort, nous allons installer un serveur Web sur notre machine avec PHP et les logiciels nécessaires. Ce serveur avec lequel nous mettrons en place des droits d accès spécifiques, permettra de visualiser les résultats mis en forme par divers plugins de sortie de Snort, dans notre cas il s agira de SnortSnarf et d ACID. PHP sera également utile pour certains plugins notamment ACID, que nous aborderons par la suite. On décompresse les sources de PHP et ensuite on les compile. Les arguments des options dépendent des emplacements où sont installés les composants sur la machine en question. # tar xzvf php tar.gz # cd php #./configure --enable-calendar with-mysql with-apache=../../apache/apache withgd =/usr/local with-png-dir=/usr/local with-zlib-dir=/usr/local # make # make install Nous allons maintenant appliquer un patch gd pour PHP. En effet, jusqu à la version de PHP (la version que j ai utilisée), il y a des problèmes de reconnaissance d extensions de fichiers qui ne sont pas reconnues par PHP. Ce problème devrait être résolue dans une version ultérieure de PHP. Après avoir récupérer ce patch sur nous allons l appliquer sur notre PHP. On se place dans le répertoire des sources décompressées de PHP et on applique le patch nommé php gd patch. # patch p1 < php gd patch On se place dans le répertoire dans lequel se trouve le package téléchargé de Apache. On décompresse les sources et on les compile avec les options désirées. # tar xzvf apache tar.gz # cd apache #./configure activate-module=src/modules/php4/libphp4.a # make # make install On copie le fichier de configuration de PHP dans /usr/local/lib/php.ini # cp../php-4.2.3/php.ini-dist /usr/local/lib/php.ini 30

31 D. Gestion graphique de snort.conf : module webmin En utilisant Webmin et le module Snort, l utilisateur pourra facilement régler sa sonde Snort et agir sur tous les paramètres des 4 sections de snort.conf vues précédemment. L utilisation la plus intéressante que j ai trouvé à ce module Snort, est la gestion des règles grâce à une interface graphique, mais ce module peut également servir à régler les autres paramètres de Snort (préprocesseurs, variables réseau, logs et alertes) et d avoir accès au fichier de configuration snort.conf avec lequel il interagit. Après avoir installer Webmin et un serveur Web, la première chose à faire est de se connecter à l une des sondes mises en place. Dans notre cas, il y a une sonde sur le localhost. Nous allons ainsi nous connecter au Webmin de la machine locale en tant que root, en entrant l URL suivant : puis en entrant comme login : root Password : le mot de passe root a) Configuration du SSL Nous allons commencer par configurer le SSL pour davantage de sécurité. Dans notre cas, cette étape n avait pas été réalisée car nous travaillions sur la machine où était située la sonde, Webmin et sur laquelle nous nous connections à Webmin. On clique sur «Webmin Configuration», puis «SSL Encryption», 31

32 ensuite on sélectionne «Enable SSL support if available» et puis on sauve avec le bouton «Save». b) Configuration du proxy Si la machine à partir de laquelle l utilisateur se connecte se trouve derrière un proxy, il soit réaliser cette étape dans Webmin sinon il la saute. Dans notre cas, cette étape avait également été omise. 32

33 On sélectionne l icône «Proxy Servers», puis on entre la configuration du proxy et on sauve avec le bouton «Save». c) Installation du module Snort de Webmin L utilisateur commence par sélectionner l icône «Webmin Configuration» comme précédemment. Ensuite il sélectionne l icône «Webmin Modules», 33

34 puis il installe le module à partir de l URL suivante comme ci-dessous : et clique sur le bouton «Install», (site officiel de ce module : Pour ma part, j ai d abord téléchargé le fichier en local sur ma machine, puis j ai réalisé l installation du module à partir du fichier téléchargé. 34

35 d) Configuration du module Snort Concernant la configuration du module Snort, après avoir sélectionné l icône «Servers» en haut de la page Web, l utilisateur sélectionne l icône «Snort IDS Admin» qui ressemble à une tête de cochon, ensuite il sélectionne l onglet «Module Config» dans le coin supérieur gauche, il doit ensuite arriver sur un écran tel que celui ci-dessous. Après avoir entrer les informations concernant les différents champs, l utilisateur doit alors cliquer sur le bouton «Save». 35

36 La configuration de ces champs doit correspondre à peu près à cela : Full path to Snort executable (with options) = /etc/snort/snort-1.9.0/src/snort A c /etc/snort/snort-1.9.0/etc/snort.conf Full path to Snort configuration file = /etc/snort/snort-1.9.0/src/snort.conf Full path to Snort rule files directory = /etc/snort/snort Full path to Snort PID file = /var/run/snort_eth1.pid Command to start Snort (optionnal) = Pour ma part, l utilisation de ce module concernait surtout la gestion des règles. Les variables importantes à configurer étaient donc le chemin au fichier de configuration de Snort, et le chemin au dossier rules de Snort. Les variables : Le chemin exécutable vers Snort avec les options : cette ligne doit être configurée si l utilisateur souhaite lancer Snort à partir de Webmin. Elle dépend aussi dans quel mode Snort est lancé et des options choisies. Le chemin vers le fichier de configuration de Snort : à configurer. Le chemin complet vers le dossier contenant les règles à configurer. Le chemin vers le fichier PID de Snort : si celui-ci est connu par l utilisateur, pour ma part je ne l avais pas entré. La commande pour démarrer Snort : optionnelle. L URL vers ACID, un plugin de sortie si celui-ci est installé (nous verrons son installation par la suite). e) Choix des groupes de règles L utilisateur peut grâce à l interface graphique (ci-dessous) du module Snort choisir des paquets de règles que Snort sera chargé d exécuter sur les paquets analysés. Il suffit pour cela 36

37 de cliquer sur les liens Action correspondant pour activer «Enable» ou désactiver «disable» un ensemble de règles. (les groupes de règles désactivés sont en fait mis en commentaire dans le fichier snort.conf par un #). Remarque importante: Au moment de la réalisation de mon installation de Snort et de ce rapport, j ai découvert un bogue dans le module Snort de Webmin concernant la variable d emplacement des règles de 37

38 Snort. En effet, le module de Webmin fait une erreur lorsqu on entre une valeur pour cette variable, et il n arrive pas à trouver ces fameuses règles. Si l utilisateur entre, comme vu précédemment, dans la configuration du module le chemin jusqu au dossier de règles : /etc/snort/snort-1.9.0/rules (dans notre cas) et que l on clique ensuite sur un dossier de règle l URL appelée devient : /etc/snort/snort-1.9.0/$rule_path/groupe_regles.rules ce qui bien évidemment ne renvoie nulle part. Sachant que : le $RULE_PATH de cette URL correspond à celui de snort.conf la sonde Snort doit continuer à pouvoir fonctionner en ayant le bon chemin vers les règles (c est quand même le plus important!) si l utilisateur ne rentre pas de valeur pour le chemin aux règles dans la configuration du module, ça ne plait pas à Webmin La solution provisoire que j ai trouvée, est de supprimer de l URL «$RULE_PATH/» pour qu elle soit correcte et recharger la page. J utilisais le module Snort de Webmin 1.1 et j ai espoir que ce bogue soit un jour corrigé dans les versions ultérieures. f) Choix d une règle individuelle Pour une plus grande précision dans le choix des règles, il est également possible pour l utilisateur de choisir individuellement les règles à activer et désactiver, obtenir des informations sur celles-ci, toujours avec des liens dans la colonne Action d une page Web du module Snort de Webmin. (une règle désactivée est mise en commentaire # dans le fichier «.rules» concerné). Cf Remarque précédente pour l accès aux règles individuelles 38

39 g) Autres options Comme on peut le voir dans ce module Snort de Webmin, il est également possible de régler les paramètres réseau, les préprocesseurs du fichier snort.conf, les logs et alertes. C est au choix de l utilisateur de choisir s il veut directement aller dans le fichier snort.conf ou passer par ce module qui lui offre une interface graphique. 39