39360.zip
Le système de détection d’intrusion réseau (NIDS) open-source évolutif et efficace Snort utilise une série de règles bien définies pour détecter les paquets anormaux sur votre réseau. La maintenance de ces séries de règles améliore considérablement l’efficacité du système. Quelques techniques de gestion des règles peuvent vous aider à maintenir votre IDS Snort. Tout d’abord, vous pouvez éviter une surcharge d’alertes en resserrant les définitions de variables et en soignant vos règles Snort. Vous pouvez également faire persister vos règles personnalisées lors des mises à jour des jeux de règles. Enfin, vous pouvez déconstruire une règle pour comprendre comment personnaliser les règles pour votre environnement.
Par défaut, Snort contient plus de 1900 règles de stock dans une série de près de 50 fichiers texte organisés par type, comme le montre la figure 1. Ces règles définissent des déclencheurs de réponse à de nombreux exploits de vulnérabilité connus se rapportant à Windows, UNIX et à des applications largement utilisées telles que Microsoft IIS, Apache, Microsoft SQL Server et Oracle SQL. Les règles aident également Snort à fournir des données de reconnaissance et d’éventuels avertissements de configuration pour vous avertir des scans du réseau ou d’une machine qui diffuse une chaîne de communauté par défaut SNMP, par exemple. Comme vous pouvez l’imaginer, Snort peut générer un nombre impressionnant d’alertes. Pour réduire le bruit des règles de stock, la configuration par défaut de Snort n’active qu’environ 1300 des règles par défaut et désactive des types de règles entiers, tels que la politique, le chat et les virus, par défaut. (Un type de règle est généralement contenu dans son propre fichier texte, ainsi les règles de type virus sont contenues dans le fichier virus.rules). Passez en revue tous les groupes de règles désactivés et activez ceux qui pourraient s’appliquer à votre environnement.
Prune Your Rules
Même avec les nombreuses règles que Snort désactive par défaut, votre système IDS Snort va probablement générer de nombreuses alertes. Le fait de passer en revue toutes ces alertes risque d’émousser vos sens pour le trafic réellement suspect. Après avoir installé Snort dans votre environnement, élaguez les règles pour supprimer celles qui ne se rapportent pas à votre environnement ou qui ne vous concernent pas. Par exemple, si vous ne disposez pas du langage de script PHP intégré au HTML : Hypertext Preprocessor (PHP) installé dans votre environnement, vous pouvez désactiver le fichier de règles web-php.rules. Toutefois, lorsque vous décidez des règles à désactiver, tenez compte des utilisateurs qui peuvent avoir divers logiciels sur leurs machines. Par exemple, l’un de vos capteurs Snort pourrait capter des paquets suspects provenant d’un ordinateur personnel compromis via une connexion VPN. Ainsi, pour reprendre l’exemple précédent, même si PHP n’est installé sur aucun des ordinateurs de votre entreprise, l’un de vos utilisateurs finaux peut l’avoir installé chez lui. Si cet ordinateur domestique était compromis par une vulnérabilité PHP, l’attaquant pourrait être en mesure d’accéder à votre réseau d’entreprise alors que l’ordinateur compromis est connecté à distance au réseau d’entreprise (par exemple via un VPN).
La plupart des systèmes d’alerte et de reporting affichent le nom et le SID de chaque règle pour une référence facile. Pour réduire davantage votre liste de règles activées, surveillez vos systèmes, notez les noms ou les SID des règles superflues, puis désactivez ces règles. Pour désactiver manuellement une règle Snort, ouvrez le fichier de règles et insérez un dièse (#) devant la règle. Pour désactiver une classe entière de règles, ajoutez un signe dièse devant le nom du fichier de règles dans le fichier de configuration de Snort. Vous devez redémarrer Snort pour charger les règles modifiées.
Réviser régulièrement vos règles et continuer à éliminer celles qui ne s’appliquent pas à votre réseau diminuera considérablement le nombre d’alertes que Snort génère, ce qui facilitera le repérage et l’identification des paquets vraiment suspects. Et n’oubliez pas de réactiver les règles si nécessaire lorsque vous introduisez une nouvelle technologie que les règles actuellement désactivées protégeraient.
Garder les règles à jour
Snort.org héberge deux versions de règles Snort : snortrules-stable et snortrules-current, qui fonctionnent respectivement avec Snort 2.0x et Snort 1.9x. Les règles les plus récentes contiennent des signatures supplémentaires et des mises à jour des règles existantes afin d’utiliser des variables étendues. Par exemple, les règles de la version 2.0.0 définissent des variables qui décrivent spécifiquement certaines fonctions de la machine (par exemple, les variables HTTP_SERVERS et HTTP_PORTS caractérisent les ordinateurs qui exécutent des services Web et peuvent être sujets à des attaques de services Web). Ces nouvelles variables fonctionnent dans les nouvelles règles pour mieux filtrer les attaques entrantes. Une ancienne règle peut vous alerter d’une requête HTTP suspecte destinée à n’importe quel ordinateur de votre réseau, mais la nouvelle règle ne recherche la même attaque que si elle est destinée à un serveur Web défini par la variable HTTP_SERVERS. Ce processus de classification permet de réduire les fausses alertes.
Snort.org met fréquemment à jour les jeux de règles pour rester au fait des nouvelles découvertes d’exploits. Pour rester à jour, recherchez, téléchargez et appliquez régulièrement les nouvelles règles qui seraient utiles dans votre environnement. Cependant, notez que chaque fois que vous téléchargez un ensemble de nouvelles règles, les fichiers texte contenant les nouvelles règles écrasent ceux contenant les anciennes règles. Vous constaterez rapidement que commenter toutes vos règles inutilisées chaque fois que vous mettez à jour vos fichiers de règles est fastidieux.
Oinkmaster à la rescousse
Heureusement, plusieurs outils open-source peuvent vous aider à surmonter ce problème. Un programme de script Perl appelé Oinkmaster, que vous pouvez télécharger à partir de http://www.algonet.se/~nitzer/oinkmaster, automatise le téléchargement de nouvelles règles et gère les règles désactivées ou modifiées. Adapté aux systèmes UNIX, le script Perl utilise les outils wget, tar et gzip pour récupérer et développer les nouvelles règles à chaque exécution du script. La plupart de ces outils sont installés sur les systèmes UNIX, mais vous pouvez télécharger les outils pour Windows. N’oubliez pas que les solutions open-source disposent d’un support dédié limité (voire inexistant). Cherchez donc en ligne des solutions aux problèmes ou aux questions que vous pourriez avoir. La communauté des logiciels libres (OSS) regorge d’informations utiles. Un bon point de départ est l’inscription à l’une des listes de diffusion de Snort, à laquelle vous pouvez vous inscrire à l’adresse http://www.snort.org/lists.html.
Veuillez consulter le fichier README pour obtenir des instructions d’installation détaillées pour votre plateforme. La procédure d’installation de base d’Oinkmaster consiste à étendre les fichiers oinkmaster.pl et oinkmaster.conf dans votre répertoire Snort (ou un répertoire que vous spécifiez), puis à utiliser oinkmaster.conf pour configurer Oinkmaster.
Ouvrir oinkmaster.conf et suivre les commentaires en ligne pour configurer l’outil. Tout d’abord, confirmez l’emplacement des règles mises à jour sous la forme d’une adresse Web (par exemple, http://www.snort.org/dl/signatures/snortrules.tar.gz). Veillez à diriger Oinkmaster vers un site fiable et réputé, surtout si vous choisissez de télécharger et d’installer les règles automatiquement. Sinon, vous courez le risque de télécharger des règles corrompues (ou pire, trafiquées) qui pourraient compromettre votre IDS.
Puis, indiquez les fichiers à sauter, à modifier et à désactiver. Par défaut, Oinkmaster ne traite pas (c’est-à-dire qu’il saute) local.rules et snort.conf.
La fonction modifysid du script vous permet de modifier les règles nouvellement téléchargées ; pensez à modifysid comme une fonction de recherche et de remplacement pour une règle spécifique que vous identifiez par SID. Avec cette commande, vous pouvez modifier le texte d’une règle spécifique. Par exemple, vous pouvez utiliser modifysid pour activer une règle qui est désactivée par défaut. Pour ce faire, ajoutez une nouvelle commande modifysid identifiant la règle que vous souhaitez activer et demandez-lui de supprimer le caractère de commentaire (#). Chaque fois qu’un nouvel ensemble de règles est téléchargé, ce caractère de commentaire sera supprimé lorsque Oinkmaster analysera cette règle. Vous pouvez également utiliser modifysid pour élever le type d’action d’une règle. Par exemple, la commande
modifysid 2003 "alert" | "sev1"
élève l’alerte avec un SID de 2003 à un type d’action personnalisé de sev1. Oinkmaster fait cela en recherchant « alert » et en le remplaçant par « sev1 ». Et oui, il fera de multiples substitutions, alors utilisez-le avec précaution.
La dernière fonctionnalité d’Oinkmaster, la plus populaire, disablesid, vous permet de désactiver des règles sélectionnées. Spécifiez les SID de toutes les règles que vous voulez garder désactivées. Par exemple, pour désactiver les alertes sur les scans du réseau, vous pouvez commencer par une entrée similaire à
disablesid 469, 615, 618, 620
Après avoir téléchargé et analysé un nouvel ensemble de règles, Oinkmaster recherche les SID spécifiés et commente les règles. Tant que Oinkmaster gère vos règles, les règles resteront désactivées, même à travers les mises à jour des ensembles de règles.
Exécutez manuellement le script chaque fois que vous voulez mettre à jour vos règles. Si vous vous sentez audacieux, programmez l’exécution du script et la mise à jour des règles de manière récurrente. Oinkmaster récupérera les règles, les développera et les copiera dans le répertoire des règles de votre capteur. Comme avec la plupart des logiciels libres, utilisez Oinkmaster avec discernement et apprenez d’abord ce qu’il fait et comment il affectera votre environnement. Par exemple, testez un nouvel ensemble de règles en exécutant Snort en mode autotest (en utilisant snort -T plus vos autres paramètres) avant de déployer les règles dans votre environnement de production.
Oinkmaster vous permet d’éviter les risques de téléchargement de mises à jour douteuses en vous donnant la possibilité de sauvegarder les anciennes règles et en délivrant un journal de ses actions sur la console. Examinez cette sortie, qui montre les règles supprimées, les règles actives modifiées, les révisions de non-règles et les nouveaux fichiers, pour confirmer que Oinkmaster a réussi ses tâches et pour confirmer les règles que Oinkmaster a modifiées. Si vous choisissez de programmer l’exécution automatique d’Oinkmaster, envisagez d’envoyer les résultats par courriel pour faciliter la révision, comme le montre la Figure 2. L’exemple suivant montre comment programmer Oinkmaster pour qu’il s’exécute tous les jours à 6h15 en utilisant la commande crontab de Linux (crontab vous permet de planifier des tâches sous Linux):
15 6 * * * /home/snort/oinkmaster.pl -o /home/snort/rules -b /home/snort/backup 2>&1 | mail -s "Oinkmaster"
Les paramètres de Oinkmaster spécifient le répertoire de règles (-o), le répertoire de règles de sauvegarde (-b) et une commande pour envoyer les résultats par courriel au propriétaire. La commande 2>&1 envoie la sortie StdErr à StdOut (la console) avant de l’envoyer à l’application de messagerie.
Looking at a Snort Rule
En plus de désactiver ou d’apporter des modifications de base aux règles de stock, vous pouvez créer vos propres règles et adapter davantage les règles Snort directement à votre environnement. Par exemple, considérez un déploiement de capteurs qui surveillent le trafic à l’intérieur et à l’extérieur de votre pare-feu. Si savoir combien d’attaques de vers votre pare-feu repousse peut vous intéresser, savoir si l’une de ces attaques provient de l’intérieur de votre réseau vous intéressera probablement encore plus. Récemment, les règles Snort ont inclus des règles » réglées » comme l’exemple ci-dessus, mais il en reste beaucoup d’autres que vous pourriez vouloir personnaliser de la même manière. La liste 1 montre une règle standard qui vous alerte lorsqu’elle détecte le ver SQL Slammer (alias Sapphire). Déconstruisons rapidement cette règle. (Pour des informations détaillées sur tous les paramètres disponibles qui définissent les règles, consultez la documentation approfondie sur les règles Snort à l’adresse http://www.snort.org/docs/writing_rules/chap2.html#tth_sec2.3.26.)
Toutes les règles doivent résider sur une ligne et commencer par une action de règle, qui dans ce cas est
alert
L’action de règle définit la façon dont Snort répond à la règle si elle est déclenchée. Vous pouvez modifier le type de règle (par exemple, en une chaîne de caractères telle que ‘sev1’) pour fournir un traitement personnalisé, par exemple, pour intensifier l’action en cas de correspondance. Cette étape est différente de l’exemple précédent, dans lequel nous avons utilisé Oinkmaster pour modifier le type d’alerte d’une règle existante ; dans cet exemple, nous créons une nouvelle règle en utilisant une règle existante comme modèle.
Le jeu de paramètres
udp $EXTERNAL_NET any -> $HOME_NET 1434
fournit le protocole, l’adresse IP, les informations de port et la direction du trafic pour la règle. Cette règle indique à Snort de trouver tout paquet UDP provenant d’une source réseau (que la variable $EXTERNAL_NET définit) qui tente de se rendre à la variable $HOME_NET sur le port 1434. La plupart des règles par défaut utilisent principalement les variables $EXTERNAL_NET et $HOME_NET. Toutefois, certaines règles utilisent des variables plus spécifiques. Par exemple, les règles qui se rapportent aux serveurs DNS (dans le fichier dns.rules) utilisent la variable $DNS_SERVERS. Définissez ces variables dans le fichier de configuration de Snort (généralement snort.conf). Vous pouvez également créer vos propres variables pour refléter votre topologie (par exemple, $MAIL_SERVERS) et pour les utiliser dans des règles personnalisées. Définissez une variable en utilisant son nom (par exemple, var MAIL_SERVERS= 192.168.0.20/30), puis faites référence à la variable en la faisant précéder du signe dollar ($, par exemple, $MAIL_SERVERS). L’action de la règle et ces paramètres constituent l’en-tête de la règle.
Les options de la règle affinent encore la règle afin qu’un paquet suspect (et seulement un paquet suspect) déclenche une réponse. Comme vous pouvez le deviner, ces signatures peuvent devenir très détaillées et s’étendre bien au-delà de la simple correspondance de ports. Par exemple, imaginez les faux positifs qui résulteraient si cette règle Slammer vous alertait simplement de tout trafic sur le port UDP 1434.
L’option msg
msg:"MS-SQL Worm propagation attempt"
fournit une description simple de l’alerte à utiliser dans les activités d’alerte et de rapport. L’option de contenu
content:"|04|"; depth:1; content:"|81 F1 03 01 04 9B 81 F1 01|";content:"sock"; content:"send";
contient la chaîne de correspondance du motif de charge utile sensible à la casse, en valeurs ASCII ou hexadécimales (entourez les valeurs hexadécimales du caractère pipe-|). Vous pouvez spécifier plusieurs options de contenu. L’option de profondeur suit chaque option de contenu et spécifie le nombre d’octets dans les données utiles que vous souhaitez rechercher pour le contenu spécifié. Dans cet exemple, un paquet déclenchera une réponse s’il contient la valeur hexagonale 04 dans le premier octet ou le contenu restant n’importe où dans la charge utile.
Les règles téléchargées contiennent souvent des références à des informations détaillées sur l’exploit suspect ou la raison de la création de la règle. Certains systèmes de reporting prennent en charge l’option de référence en fournissant des liens directs vers ces informations :
reference:bugtraq,5310; reference:bugtraq,5311;reference:url,vil.nai.com/vil/content/v_99992.htm;
Snort affecte les règles à des classes et attribue à ces classes une priorité élevée, moyenne ou faible. Actuellement, il existe plus de 30 classifications, notamment attempt-admin, trojan-activity, attempted denial of service et network-scan. Dans notre exemple, la classification est
classtype:misc-attack
Snort enregistre la priorité de réponse pour les intrusions détectées. Vous pouvez utiliser un outil ou un script externe pour analyser davantage cette priorité et prendre des mesures avec votre application de reporting.
Dans le dernier segment
sid:2003; rev:2;
sid représente une règle Snort unique, et rev désigne le numéro de révision. Ces propriétés identifient de manière unique la règle.
Tailoring the Rule
Examinons comment modifier cette règle pour fournir une alerte escaladée lorsqu’elle détecte des hôtes infectés internes. Comme nous traitons le même exploit que la règle originale, la définition du contenu de la règle reste la même. Nous devons modifier uniquement les adresses IP et la direction du trafic. Changeons l’adresse IP source en $HOME_NET, comme suit :
udp $HOME_NET any -> $EXTERNAL_NET 1434
Snort.conf définit $EXTERNAL_NET comme « any », donc cette règle attrapera toujours les paquets corrompus qui ciblent les hôtes internes (comme la règle originale). Cependant, maintenant que nous avons une règle dédiée qui ne suit que les adresses IP sources internes, nous pouvons modifier le type d’action en un type d’action personnalisé qui déclenche une alerte escaladée.
Les règles Snort actuelles incluent cette règle de détection de ver Slammer sortant dans l’ensemble de règles par défaut. Cependant, lorsqu’un nouveau ver, virus ou autre exploit commence à se répandre, envisagez de créer de nouvelles règles qui mettent en évidence des intrusions spécifiques.
Faire vos règles
En plus des règles existantes ou personnalisées que vous pouvez modifier ou créer, vous pouvez inclure des règles que vous obtenez d’une autre source. Par exemple, lorsque la nouvelle d’un nouveau ver se répand sur Internet, les sites de sécurité et les groupes de discussion s’empressent de publier des règles Snort ponctuelles capables de détecter le nouveau ver. Collez ces nouvelles règles dans le fichier local.rules, puis redémarrez Snort pour que les nouvelles règles prennent effet.
Snort fournit le cadre d’un IDS peu coûteux et personnalisable. Porté par un ensemble de règles soutenues par la communauté, Snort reste un système flexible et efficace. Maintenir vos règles à jour augmentera votre vigilance et diminuera le bruit qui résulte d’alertes inefficaces. Comme pour tout projet open-source, prendre le temps de comprendre son fonctionnement et se familiariser avec ses modules complémentaires développés par la communauté améliorera considérablement votre confort avec le système et augmentera son efficacité dans votre environnement.