L'écriture de règles Snort <author>version originale par Martin Roesch &nl;traduction française par Denis Ducamp <date>24 janvier 2001 - version 1.7 / traduction française 29 avril 2001 <abstract>Comment écrire des règles Snort et garder son équilibre mental <toc> <sect>Les bases <p>Snort utilise un langage simple et léger de description de règles qui est flexible et assez puissant. Il y a nombre d'indications simples à se souvenir en développant des règles Snort. <p>La première est que les règles Snort doivent être complètement contenues sur une seule ligne, l'analyseur de règles de Snort ne sait pas comment traiter des règles sur plusieurs lignes. <p>Les règles Snort sont divisées en deux sections logiques, l'entête de la règle et les options de la règle. L'entête de règle contient comme informations l'action de la règle, le protocole, les adresses IP source et destination et les masques réseau, et les ports source et destination. La section options de la règle contient les messages d'alerte et les informations sur les parties du paquet qui doivent être inspectées pour déterminer si l'action de la règle doit être acceptée. <p>Voici une règle d'exemple : <table> <tabular ca="c"> <bf>alert tcp any any -> 192.168.1.0/24 111 (content:"|00 01 86 a5|"; msg: "mountd access";)</bf> </tabular> </table> <p>Figure 1 - Exemple de règle Snort <p>Le texte jusqu'à la première parenthèse est l'entête de règle et la section entourée par les parenthèses est les options de la règle. Les mots avant les deux-points dans la section des options de la règle sont appelés les mots clés des options. Notez que la section des options de la règle n'est spécifiquement requise par aucune règle, elles sont juste utilisées pour le bien de rendre plus strictes les définitions des paquets à collecter ou à alarmer (ou à ignorer, d'ailleurs). Tous les éléments dans cette composition de règle doivent être vrais pour que l'action de règle indiquée soit acceptée. En les prenant ensembles, les éléments peuvent être considérés comme formant la déclaration d'un ET logique. En même temps, les diverses règles dans un fichier bibliothèque de règles Snort peuvent être considérées comme formant une large déclaration d'un OU logique. Commençons par parler à propos de la section d'entête de règle. <sect1>Les inclusions <p>Le mot clé include permet à d'autres fichiers de règles d'être inclus dans le fichier de règles indiqué sur la ligne de commande de Snort. Il fonctionne beaucoup comme un "#include" du langage de programmation C, lisant le contenu de fichier nommé et les mettant en place dans le fichier à la place où l'include apparaît. <p>Format : <p><bf>include: <répertoire/nom du fichier include></bf> <p>Notez qu'il n'y a pas de point-virgule à la fin de la ligne. Les fichiers inclus substitueront toute valeur de variable prédéfinie dans le fichier de règles de Snort. <sect1>Les variables <p>Des variables peuvent être définies dans Snort. Ce sont de simples substitutions des variables fixées avec le mot clé var comme dans la Figure 2. <p>Format : <p><bf>var: <nom> <valeur></bf> <table> <tabular ca="c"> <bf>var MY_NET [192.168.1.0/24,10.1.1.0/24] &nl;alert tcp any any -> $MY_NET any (flags: S; msg: "SYN packet";)</bf> </tabular> </table> <p>Figure 2 - Exemple de définition et d'utilisation de variable <p>Les noms de variables de règles peuvent être modifiées de plusieurs façons. Vous pouvez définir des méta-variables en utilisant l'opérateur "$". Celles-ci peuvent être utilisées avec les opérateurs de modification de variables, "?" et "-". <itemize> <item>$var - défini la méta-variable <item>$(var) - remplace avec le contenu de la variable "var" <item>$(var:-défaut) - remplace avec le contenu de la variable "var" ou avec "défaut" si "var" est indéfini. <item>$(var:?message) - remplace avec le contenu de la variable "var" ou affiche le message d'erreur "message" et quitte </itemize> <p>Voir Figure 3 pour un exemple de ces modificateurs de règles en action. <table> <tabular ca="c"> <bf>var MY_NET $(MY_NET:-192.168.1.0/24) &nl;log tcp any any -> $(MY_NET:?MY_NET is undefined!) 23</bf> </tabular> </table> <p>Figure 3 - Exemple d'utilisation avancée de variable <sect>Les entêtes de règle <sect1>L'action de règle <p>L'entête de règle contient l'information qui défini le "qui, où, et quoi" d'un paquet, ainsi que quoi faire dans l'événement où le paquet avec tous les attributs indiqués dans la règle devrait se présenter. Le premier élément dans une règle est l'action de règle. L'action de règle dit à Snort quoi faire quand il trouve un paquet qui correspond aux critères de la règle. Il y a cinq actions accessibles par défaut dans Snort, alert, log, pass, activate, et dynamic. <itemize> <item>alert - génère une alerte en utilisant la méthode d'alerte sélectionnée, et alors journalise le paquet <item>log - journalise le paquet <item>pass - ignore le paquet <item>activate - alerte et alors active une autre règle dynamic <item>dynamic - reste passive jusqu'à être activée par une règle activate, alors agit comme une règle log </itemize> <p>Vous pouvez aussi définir vos propres types de règles et associer un ou plusieurs plugins de sortie avec eux. Vous pouvez alors utiliser le type de règle comme action dans les règles Snort. <p>Cet exemple créera un type qui journalisera juste vers tcpdump : <verb> ruletype suspicious { type log output log_tcpdump: suspicious.log } </verb> <p>Cet exemple créera un type de règle qui journalisera vers syslog et une base de données mysql : <verb> ruletype redalert { type alert output alert_syslog: LOG_AUTH LOG_ALERT output database: log, mysql, user=snort dbname=snort host=localhost } </verb> <sect1>Les protocoles <p>Le champ suivant dans une règle est le protocole. Il y a trois protocoles IP que Snort analyse actuellement pour des comportements suspicieux, tcp, udp, et icmp. Dans le futur il pourra y en avoir plus, tels que ARP, IGRP, GRE, OSPF, RIP, IPX, etc. <itemize> <item>tcp <item>udp <item>icmp </itemize> <sect1>Les adresses IP <p>La section suivante de l'entête de règle s'occupe comme information de l'adresse IP et du port pour une règle donnée. Le mot clé "any" peut être utilisé pour définir n'importe quelle adresse. Snort n'a pas de mécanisme pour fournir de la résolution de nom pour le champ de l'adresse IP dans le fichier de règles. Les adresses sont formées par une simple adresse IP numérique et un bloc CIDR. Le bloc CIDR indique le masque réseau qui doit être appliqué à l'adresse de la règle et à tout paquet qui est testé par rapport à la règle. Un masque de bloc CIDR de /24 indique un réseau de classe C, /16 un réseau de classe B, et /32 indique l'adresse spécifique d'une machine. Par exemple, la combinaison d'adresse/CIDR 192.168.1.0/24 devrait signifier le bloc d'adresses de 192.168.1.1 à 192.168.1.255. Toute règle qui utilise cette désignation pour, disons, l'adresse destination devrait correspondre à toute adresse dans cet intervalle. Les désignations CIDR nous donne une façon rapide de désigner de larges espaces d'adresses avec juste quelques caractères. <p>Dans la Figure 1, l'adresse IP source était fixée pour correspondre à tout ordinateur parlant, et l'adresse destination était fixée pour correspondre au réseau de classe C 192.168.1.0 . <p>Il y a un opérateur qui peut être appliqué aux adresses IP, l'opérateur de négation. Cet opérateur dit à Snort de correspondre à toute adresse IP sauf celles indiquées par la liste d'adresses IP. L'opérateur de négation est indiqué par un "!". Par exemple, une modification facile à l'exemple initial est de le faire alerter sur tout trafic qui provient de l'extérieur du réseau local avec l'opérateur de négation comme montré dans la Figure 4. <table> <tabular ca="c"> <bf>alert tcp !192.168.1.0/24 any -> 192.168.1.0/24 111 (content: "|00 01 86 a5|"; msg: "external mountd access";)</bf> </tabular> </table> <p>Figure 4 - Un exemple de règle avec négation d'adresse IP <p>Ces adresses IP de la règle indiquent "tout paquet tcp avec une adresse source ne provenant pas du réseau interne et à destination du réseau interne". <p>Vous pouvez aussi spécifier des listes d'adresses IP. Une liste IP spécifiée en entourant une liste d'adresses IP et de blocs CIDR séparés par des virgules entre crochets. Pour le moment, une liste IP ne peut pas inclure d'espaces entre les adresses. Voir la Figure 3 pour un exemple de liste IP en action. <table> <tabular ca="c"> <bf>alert tcp ![192.168.1.0/24,10.1.1.0/24] any -> [192.168.1.0/24,10.1.1.0/24] 111 (content: "|00 01 86 a5|"; msg: "external mountd access";)</bf> </tabular> </table> <sect1>Les numéros de ports <p>Les numéros de ports peuvent être spécifiés de nombre de façons, incluant "any" (ndt : tous les ports), des définitions de ports statiques, des intervalles et des négations. Les ports "any" sont les valeurs génériques, signifiant littéralement tous les ports. Les ports statiques sont indiqués par un seul numéro de port, tel que 111 pour portmapper, 23 pour telnet, ou 80 pour http, etc. Les intervalles de ports sont indiqués avec l'opérateur d'intervalle ":". L'opérateur d'intervalle peut être appliqué dans nombre de façons pour prendre différentes significations, tel que dans la Figure 5. <table> <tabular ca="c"> <bf>log udp any any -> 192.168.1.0/24 1:1024</bf> &nl;<it>journalise le trafic udp provenant de tout port et à destination de ports dans l'intervalle de 1 à 1024</it><rowsep> <bf>log tcp any any -> 192.168.1.0/24 :6000</bf> &nl;<it>journalise le trafic tcp depuis tout port et allant vers les ports inférieurs ou égaux à 6000</it><rowsep> <bf>log tcp any :1024 -> 192.168.1.0/24 500:</bf> &nl;<it>journalise le trafic tcp depuis les ports privilégiés inférieurs ou égaux à 1024 allant vers les ports supérieurs ou égaux à 500</it> </tabular> </table> <p>Figure 5 - Exemples d'intervalles de ports <p>La négation de port est indiquée en utilisant l'opérateur de négation "!". L'opérateur de négation peut être appliqué à tous les autres types de règles (excepté "any", qui se traduirait en aucun, combien ce serait Zen...). Par exemple, si pour quelque raison tordue vous voulez tout journaliser sauf les ports X Windows, vous pourriez faire quelque chose comme la règle dans la Figure 6. <table> <tabular ca="c"> <bf>log tcp any any -> 192.168.1.0/24 !6000:6010</bf> </tabular> </table> <p>Figure 6 - Exemple de négation de port <sect1>L'opérateur de direction <p>L'opérateur de direction "->" indique l'orientation, ou la "direction", du trafic auquel la règle s'applique. L'adresse IP et les numéros de ports du côté gauche de l'opérateur de direction est considéré comme le trafic provenant du système source, et les informations d'adresse et de port du côté droit de l'opérateur est le système destination. Il y a aussi un opérateur bidirectionel, qui est indiqué par le symbole "<>". Ceci dit à Snort de considérer les paires adresse/port ou bien en source ou bien en destination de l'orientation. C'est utile pour enregistrer/analyser les deux côtés d'une conversation, tel que des sessions telnet ou POP3. Un exemple de l'opérateur bidirectionel étant utilisé pour enregistrer les deux côtés d'une session telnet est montré en Figure 7. <table> <tabular ca="c"> <bf>log !192.168.1.0/24 any <> 192.168.1.0/24 23</bf> </tabular> </table> <p>Figure 7 - Une règle Snort utilisant l'opérateur bidirectionel <sect1>Les règles activate/dynamic <p>Les paires de règles activate/dynamic donnent à Snort une capacité puissante. Vous pouvez maintenant avoir une règle qui en active une autre pour un nombre fixé de paquets quand son action est accomplie. Ceci est très utile si vous voulez configurer Snort pour effectuer l'enregistrement de ce qui suit quand une règle spécifique "se désactive". Les règles d'activation se comportent juste comme les règles alert, excepté qu'elles ont un champ d'option *obligatoire* : "activates". Les règles dynamiques se comportent juste comme les règles log, mais elles ont un champ d'option différent : "activated_by". Les règles dynamiques ont également un second champ obligatoire, "count". Quand la règle "activate" se désactive, elle active la règle dynamique qui lui est liée (indiquée par les numéros d'option activates/activated_by) pour "count" paquets (50 dans ce cas). Mettez les ensembles et elles ressemblent à ceci : <table> <tabular ca="c"> activate tcp !$HOME_NET any -> $HOME_NET 143 (flags: PA; content: "|E8C0FFFFFF|\bin|; activates: 1; msg: "IMAP buffer overflow!";) &nl; &nl;dynamic tcp !$HOME_NET any -> $HOME_NET 143 (activated_by: 1; count: 50;) </tabular> </table> <p>Figure 8 - exemple de règles activate/dynamic <p>Ces règles disent à Snort d'alerter quand il détecte un débordement de tampon dans IMAP et collecte les 50 prochains paquets destinés au port 143 provenant de l'extérieur de $HOME_NET et destinés à $HOME_NET. Si le débordement de tampon arrive et a réussi, il y a de très bonnes possibilités que des données utiles seront contenues dans les prochains 50 (ou quel que soit) paquets allant au même port de service sur le réseau, ainsi il y a avantage à collecter ces paquets pour une analyse ultérieure. <sect>Les options de règle <p>Les options de règle forment le coeur du moteur de détection d'intrusion de Snort, combinant facilité d'utilisation, puissance et flexibilité. Toutes les options de règle de Snort sont séparées les unes des autres par un caractère point virgule ";". Les mots clés des options de règle sont séparés de leurs arguments avec un caractère deux points ":". Au moment de la rédaction, il y a 15 mots clé d'option de règle disponibles dans Snort : <itemize> <item>msg - affiche un message dans les alertes et journalise les paquets <item>logto - journalise le paquet dans un fichier nommé par l'utilisateur au lieu de la sortie standard <item>ttl - teste la valeur du champ TTL de l'entête IP <item>tos - teste la valeur du champ TOS de l'entête IP <item>id - teste le champ ID de fragment de l'entête IP pour une valeur spécifiée <item>ipoption - regarde les champs des options IP pour des codes spécifiques <item>fragbits - teste les bits de fragmentation de l'entête IP <item>dsize - teste la taille de la charge du paquet contre une valeur <item>flags - teste les drapeaux TCP pour certaines valeurs <item>seq - teste le champ TCP de numéro de séquence pour une valeur spécifique <item>ack - teste le champ TCP d'acquittement pour une valeur spécifiée <item>itype - teste le champ type ICMP contre une valeur spécifiée <item>icode - teste le champ code ICMP contre une valeur spécifiée <item>icmp_id - teste la champ ICMP ECHO ID contre une valeur spécifiée <item>icmp_seq - teste le numéro de séquence ECHO ICMP contre une valeur spécifique <item>content - recherche un motif dans la charge d'un paquet <item>content-list - recherche un ensemble de motifs dans la charge d'un paquet <item>offset - modifie l'option content, fixe le décalage du début de la tentative de correspondance de motif <item>depth - modifie l'option content, fixe la profondeur maximale de recherche pour la tentative de correspondance de motif <item>nocase - correspond à la procédure de chaîne de contenu sans sensibilité aux différences majuscules/minuscules <item>session - affiche l'information de la couche applicative pour la session donnée <item>rpc - regarde les services RPC pour des appels à des applications/procédures spécifiques <item>resp - réponse active (ferme les connexions, etc) <item>react - réponse active (bloque les sites web) </itemize> <sect1>Msg <p>L'option de règle msg dit au moteur de journalisation et d'alerte le message à imprimer avec une sauvegarde du paquet ou une alerte. C'est une simple chaîne texte qui utilise "\" comme caractère d'échappement pour indiquer un caractère discret qui pourrait autrement rendre confus l'analyseur de règles de Snort (tel que le caractère point virgule ";"). <p>Format : <p><bf>msg: "<message texte>";</bf> <sect1>Logto <p>L'option logto dit à Snort de journaliser tous les paquets qui déclenchent cette règle vers un fichier journal de sortie spécial. C'est spécialement pratique pour combiner les données de choses comme les activités NMAP, les scans CGI HTTP, etc. Il doit être noté que cette option ne marche pas quand Snort est en mode de journalisation binaire. <p>Format : <p><bf>logto: "<nom de fichier>";</bf> <sect1>TTL <p>Cette règle d'option est utilisée pour fixer la valeur time-to-live à tester. Le test qu'il effectué est réussi seulement sur une correspondance exacte. Ce mot de clé d'option était destiné à être utilisé pour détecter les tentatives de traceroute. <p>Format : <p><bf>ttl: "<nombre>";</bf> <sect1>TOS <p>Le mot clé "tos" vous permet de vérifier le champ TOS de l'entête IP pour une valeur spécifique. Le test effectué est réussi seulement sur une correspondance exacte. <p>Format : <p><bf>tos: "<nombre>";</bf> <sect1>ID <p>Ce mot clé d'option est utilisé pour tester une correspondance exacte dans le champ ID de fragment de l'entête IP. Quelques programmes de pirates (et d'autres programmes) fixent ce champ spécifiquement pour différents besoins, par exemple la valeur 31337 est très populaire avec certains pirates. Ceci peut être retourné contre eux en mettant en place une simple règle pour tester ceci et quelques autres "nombres de pirates". <p>Format : <p><bf>id: "<nombre>";</bf> <sect1>Ipoption <p>Si des options IP sont présentes dans un paquet, cette option va chercher l'utilisation d'une option spécifique, tel que le routage par la source. Les arguments valides de cette option sont : <itemize> <item>rr - Record route (ndt : enregistrement de la route) <item>eol - End of list (ndt : fin de liste) <item>nop - No op (ndt : pas d'opération) <item>ts - Time Stamp (ndt : horaire) <item>sec - IP security option (ndt : option de sécurité IP) <item>lsrr - Loose source routing (ndt : routage vague par la source) <item>ssrr - Strict source routing (ndt : routage stricte par la source) <item>satid - Stream identifier </itemize> <p>Les options IP les plus fréquemment regardées sont les routages vague et stricte par la source qui ne sont utilisés dans aucune application Internet. Seulement une seule option peut être spécifiée par règle. <p>Format : <p><bf>ipopts: <option>;</bf> <sect1>Fragbits <p>Cette règle inspecte les bits de fragment et le bit réservé dans l'entête IP. Il y a trois bits qui peuvent être vérifiés, le bit Reserved Bit (RB), le bit More Fragments (MF) et le bit Dont Fragment (DF). Ces bits peuvent être vérifiés pour une variété de combinaisons. Utilisez les valeurs suivantes pour indiquer les bits spécifiques : <itemize> <item>R - Reserved Bit <item>D - DF bit <item>M - MF bit </itemize> Vous pouvez également utiliser des modificateurs pour indiquer des critères logiques de correspondance pour les bits spécifiés : <itemize> <item>+ - Tous les drapeaux, correspond si au moins les bits spécifiés sont positionnés <item>* - Au moins un drapeau, correspond si au moins un des bits spécifiés est positionné <item>! - Aucun drapeau, correspond si aucun des bits spécifiés n'est positionné </itemize> <p>Format : <p><bf>fragbits: <valeurs des bits>;</bf> <table> <tabular ca="c"> <bf>alert tcp !$HOME_NET any -> $HOME_NET any (fragbits: R+; msg: "Reserved IP bit set!";)</bf> </tabular> </table> <p>Figure 9 - Exemple d'utilisation de la détection par fragbits <sect1>Dsize <p>L'option dsize est utilisée pour tester la taille de la charge du paquet. Il peut être fixé à toute valeur, utilise en plus les signes supérieur/inférieur pour indiquer des intervalles et des limites. Par exemple, si vous savez qu'un certain service a un tampon d'une certaine taille, vous pouvez fixer cette option pour regarder les tentatives de débordement de tampons. Cela a l'avantage supplémentaire d'être une façon bien plus rapide de tester contre les débordements de tampons qu'une vérification de contenu de la charge. <p>Format : <p><bf>dsize: [>|<] <nombre>;</bf> <p><it>Note : Les opérateurs > et < sont optionnels !</it> <sect1>Content <p>Le mot clé content est une des fonctionnalités les plus importantes de Snort. Il autorise l'utilisateur de fixer des règles qui recherchent un contenu spécifique dans la charge du paquet et déclencher une réponse basée sur les données. A chaque fois que l'option content de correspondance de motif est exécutée, la fonction de correspondance de motif de Boyer-Moore est appelée et le test (plutôt cher en temps de calcul) est effectué contre le contenu du paquet. Si une donnée correspondant exactement à la chaîne de donnée en argument est contenue n'importe où dans la charge de paquet, le test est réussi et le reste des options de la règle est exécutée. Sachez que ce test fait la différence entre majuscules et minuscules. <p>La donnée d'option pour le mot clé content est quelque peu complexe; il peut contenir du texte et des données binaires mélangées. Les données binaires sont généralement entourées dans des caractères barre verticale ("|") et représentées en tant que bytecode. Un bytecode représente une donnée binaire comme des nombres hexadécimaux et c'est une bonne méthode de raccourci pour décrire des données binaires complexes. La Figure 7 contient un exemple de mélange de textes et de données binaires dans une règle Snort. <table> <tabular ca="c"> <bf>alert tcp any any -> 192.168.1.0/24 143 (content: "|90C8 C0FF FFFF|/bin/sh"; msg: "IMAP buffer overflow!";)</bf> </tabular> </table> <p>Figure 10 - Mélange de bytecode binaire et de texte dans une option de règle content <p>Format : <p><bf>content: "<chaîne de contenu>";</bf> <sect1>Offset <p>L'option de règle offset est utilisée comme un modificateur des règles utilisant le mot clé d'option content. Ce mot clé modifie la position de début de recherche pour la fonction de correspondance de motif depuis le début de la charge du paquet. Il est très utile pour des choses comme des règles de détection de scans CGI où la chaîne de recherche de contenu n'est jamais trouvée dans les quatre premiers octets de la charge. Soin doit être pris à ne pas fixer la valeur offset trop strictement sous peine de manquer potentiellement une attaque ! Ce mot clé d'option de règle ne peut pas être utilisé sans spécifier également l'option de règle content. <p>Format : <p><bf>offset: <nombre>;</bf> <sect1>Depth <p>Depth est une autre modification de l'option de règle content. Ceci fixe la profondeur maximale de recherche dans la fonction content de correspondance de motif de recherche depuis le début de sa région de recherche. Il est utile pour limiter la fonction de correspondance de motif d'exécuter des recherches inefficaces une fois que la région de recherche probable pour un ensemble de contenus donné a été dépassée. (C'est à dire que si vous recherchez "cgi-bin/phf" dans un paquet relatif au web, vous n'avez probablement pas besoin de perdre du temps à rechercher dans la charge après les 20 premiers octets!) Voir la Figure 8 pour un exemple de règle de recherche combinant content, offset et depth. <p>Format : <p><bf>depth: <nombre>;</bf> <table> <tabular ca="c"> <bf>alert tcp any any -> 192.168.1.0/24 80 (content: "cgi-bin/phf"; offset: 3; depth: 22; msg: "CGI-PHF access";)</bf> </tabular> </table> <p>Figure 11 - Règle combinant content, offset et depth <sect1>Nocase <p>L'option nocase est utilisée pour désactiver la différence majuscules/minuscules dans une règle "content". Elle est spécifiée seule dans une règle et tout caractère ASCII qui est comparé à la charge du paquet est traité comme si il était soit en majuscule soit en minuscule. <p>Format : <p><bf>nocase;</bf> <table> <tabular ca="c"> <bf>alert tcp any any -> 192.168.1.0/24 21 (content: "USER root"; nocase; msg: "FTP root user access attempt";)</bf> </tabular> </table> <p>Figure 12 - Règle content avec le modificateur nocase <sect1>Flags <p>Cette règle teste les drapeaux TCP pour une correspondance. Il y a actuellement 8 drapeaux variables qui sont disponibles dans Snort : <itemize> <item>F - FIN (le bit le moins significatif dans l'octet des drapeaux TCP) <item>S - SYN <item>R - RST <item>P - PSH <item>A - ACK <item>U - URG <item>2 - bit réservé 2 <item>1 - bit réservé 1 </itemize> <p>Il y a aussi des opérateurs logiques qui peuvent être utilisés pour spécifier des critères de correspondance pour les drapeaux indiqués : <itemize> <item>+ - Tous les drapeaux, correspond si au moins les bits spécifiés sont positionnés <item>* - Au moins un drapeau, correspond si au moins un des bits spécifiés est positionné <item>! - Aucun drapeau, correspond si aucun des bits spécifiés n'est positionné </itemize> <p>Les bits réservés peuvent être utilisés pour détecter des comportements non usuels, tels que des tentatives d'empreintes digitales de piles IP ou d'autres activités suspicieuses. La Figure 13 montre un règle de détection d'un scan SYN-FIN . <p>Format : <p><bf>flags: <valeurs de drapeaux>;</bf> <table> <tabular ca="c"> <bf>alert any any -> 192.168.1.0/24 any (flags: SF; msg: "Possible SYN FIN scan";)</bf> </tabular> </table> <p>Figure 13 - Exemple de spécification de drapeaux TCP <sect1>Seq <p>Cette option de règle se réfère aux numéros de séquence TCP. Essentiellement, il détecte si le paquet a un numéro de séquence statique fixé, et donc plutôt peu utilisé. Elle a été incluse pour le bien de l'exhaustivité. <p>Format : <p><bf>seq: <nombre>;</bf> <sect1>Ack <p>Le mot clé ack d'option de règle se réfère au champ d'acquittement de l'entête TCP. Cette règle a un propos pratique jusqu'ici : détecter les pings TCP NMAP. Un ping TCP NMAP fixe ce champ à zéro et envoie un paquet avec le drapeau ACK TCP pour déterminer si un système réseau est actif. La règle pour détecter l'activité est montrée dans la Figure 14. <p>Format : <p><bf>ack: <nombre>;</bf> <table> <tabular ca="c"> <bf>alert any any -> 192.168.1.0/24 any (flags: A; ack: 0; msg: "NMAP TCP ping";)</bf> </tabular> </table> <p>Figure 14 - Utilisation du champ ACK TCP <sect1>Itype <p>Cette règle teste la valeur du champ type ICMP. Il est fixé en utilisant la valeur numérique du champ. Pour une liste des valeurs disponibles, regardez dans le fichier decode.h inclus avec Snort ou dans toute référence ICMP. Il doit être noté que les valeurs peuvent être fixées en dehors de l'intervalle pour détecter des valeurs de type ICMP invalides qui sont quelques fois utilisées dans des dénis de services et des attaques en inondations. <p>Format : <p><bf>itype: <nombre>;</bf> <sect1>Icode <p>Le mot clé d'option de règle icode est plutôt identique à la règle itype, fixez juste une valeur numérique ici et Snort va détecter tout trafic en utilisant cette valeur de code ICMP. Les valeurs hors intervalle peut également être fixé pour détecter le trafic suspicieux. <p>Format : <p><bf>icode: <nombre>;</bf> <sect1>Session <p>Le mot clé session est nouveau depuis la version 1.3.1.1 et est utilisé pour extraire les données utilisateurs depuis les sessions TCP. Il est extrêmement utile pour voir ce que les utilisateurs tapent dans telnet, rlogin, ftp et même les sessions web. Il y a deux mots clé disponibles en argument pour l'option de règle session, printable ou all. Le mot clé printable affiche seulement les données que l'utilisateur verrait normalement ou serait capable de taper. Le mot clé all substitue les caractères non imprimables avec leurs équivalents hexadécimaux. Cette fonction peut ralentir considérablement Snort, donc elle ne devrait pas être utilisée dans des situations de charge importante, et est probablement mieux adaptée au post-traitement de fichiers journaux binaires (format tcpdump). Voir la Figure 15 pour un bon exemple de règle de session telnet. <p>Format : <p><bf>session: [printable|all];</bf> <table> <tabular ca="c"> <bf>log tcp any any <> 192.168.1.0/24 23 (session: printable;)</bf> </tabular> </table> <p>Figure 15 - Journalisation des données imprimables d'une session telnet <sect1>Icmp_id <p>L'option icmp_id examine le numéro ICMP ID d'un paquet ECHO ICMP pour une valeur spécifique. C'est utile car quelques programmes de canaux cachés utilisent des champs ICMP statiques quand ils communiquent. Ce plugin particulier a été développé pour activer la règle de détection de stacheldraht écrite par Max Vision, mais c'est certainement utile pour détecter un nombre potentiel d'attaques. <p>Format : <p><bf>icmp_id: <nombre>;</bf> <sect1>Icmp_seq <p>L'option Icmp_seq examine le champ séquence ICMP d'un paquet ECHO ICMP pour une valeur spécifique. C'est utile car quelques programmes de canaux cachés utilisent des champs ICMP statiques quand ils communiquent. Ce plugin particulier a été développé pour activer la règle de détection de stacheldraht écrite par Max Vision, mais c'est certainement utile pour détecter un nombre potentiel d'attaques. (Et oui, je sais que l'information pour ce champ est presque identique à la description de icmp_id, c'est pratiquement la même fichue chose!) <p>Format : <p><bf>icmp_seq: <nombre>;</bf> <sect1>Rpc <p>Cette option regarde les requêtes RPC et décode automatiquement l'application, la procédure et la version de programme, en indiquant un succès quand les trois variables correspondent toutes. Le format de l'option d'appel est "application,procédure,version". Les caractères génériques sont valides pour la procédure et les numéros de version et sont indiquées par une "*". <p>Format : <p><bf>icmp_seq: <nombre,[nombre|*],[nombre|*]>;</bf> <table> <tabular ca="c"> <bf>alert tcp any any -> 192.168.1.0/24 111 (rpc: 100000,*,3; msg:"RPC getport (TCP)";)</bf> <rowsep><bf>alert udp any any -> 192.168.1.0/24 111 (rpc: 100000,*,3; msg:"RPC getport (UDP)";)</bf> <rowsep><bf>alert udp any any -> 192.168.1.0/24 111 (rpc: 100083,*,*; msg:"RPC ttdb";)</bf> <rowsep><bf>alert udp any any -> 192.168.1.0/24 111 (rpc: 100232,10,*; msg:"RPC sadmin";)</bf> </tabular> </table> <p>Figure 16 - Diverses alertes d'appels RPC <sect1>Resp <p>Le mot clé resp met en oeuvre les réponses flexibles (FlexResp) au trafic qui correspond à une règle Snort. Le code FlexResp permet à Snort de fermer activement les connexions en infraction. Les arguments suivants sont valides pour ce module : <itemize> <item>rst_snd - envoie des paquets TCP-RST à la socket expéditrice <item>rst_rcv - envoie des paquets TCP-RST à la socket destinataire <item>rst_all - envoie des paquets TCP_RST dans les deux directions <item>icmp_net - envoie un paquet ICMP_NET_UNREACH à l'expéditeur <item>icmp_host - envoie un paquet ICMP_HOST_UNREACH à l'expéditeur <item>icmp_port - envoie un paquet ICMP_PORT_UNREACH à l'expéditeur <item>icmp_all - envoie tous les paquets ci-dessus à l'expéditeur </itemize> <p>Les options peuvent être combinées pour envoyer des réponses multiples au système cible. Les arguments multiples sont séparés par des virgules. <p>Format : <p><bf>resp: <resp_modifier[, resp_modifier...]>;</bf> <table> <tabular ca="c"> <bf>alert tcp any any -> 192.168.1.0/24 1524 (flags: S; resp: rst_all; msg: "Root shell backdoor attempt";)</bf> <rowsep><bf>alert udp any any -> 192.168.1.0/24 31 (resp: icmp_port,icmp_host; msg: "Hacker's Paradise access attempt";)</bf> </tabular> </table> <p>Figure 17 - Exemples d'utilisation de FlexResp <sect1>Content-list <p>Le mot clé content-list permet à de multiples chaînes de contenu d'être spécifiées à la place d'une unique option de contenu. Les motifs qui seront recherchés doivent pour chacun être spécifiés sur une seule ligne du fichier content-file comme montré dans la Figure 1, mais sinon ils sont traités identiquement aux chaînes de contenue spécifiées comme un argument à la directive standard content. Cette option est la base pour le mot clé react. <table> <tabular ca="c"> <bf># adult sites &nl;porn &nl;adults &nl;hard core &nl;www.pornsite.com &nl;# ... </bf> </tabular> </table> <p>Figure 18 - fichier d'exemple de content-list pour adultes <p>Format : <p><bf>content-list: "<nom de fichier>";</bf> <sect1>React <p>Le mot clé react basé sur les réponses flexibles (FlexResp) met en oeuvre la réaction flexible au trafic qui correspond à une règle Snort. La réaction de base est de bloquer les sites intéressants que les utilisateurs veulent accéder : New York Times, slashdot, ou quelque chose de vraiment important - napster et les sites pornos. Le code Flex Resp permet à Snort de fermer activement les connexions en infraction et/ou d'envoyer un message visible au navigateur (modificateur d'avertissement disponible bientôt). Le message peut inclure votre propre commentaire. Les argument suivants (modificateurs de base) sont valides pour cette option : <itemize> <item>block - ferme la connexion et envoie message visible <item>warn - envoie le message d'avertissement visible (sera disponible bientôt) &nl;L'argument de base peut être combiné avec les arguments suivants (modificateurs supplémentaires) : <item>msg - inclut le texte de l'option msg dans le message visible de bloquage <item>proxy: <port_nr> - utilise le port du relais pour envoyer le message visible </itemize> <p>Des arguments additionnels multiples sont séparés par une virgule. Le mot clé react doit être placé en dernier dans la liste des options. <p>Format : <p><bf>react: <react_basic_modifier[, react_additional_modifier...]>;</bf> <table> <tabular ca="c"> <bf>alert tcp any any <> 192.168.1.0/24 80 (content-list: "adults"; msg: "Not for children!"; react: block, msg;)</bf> <rowsep><bf>alert tcp any any <> 192.168.1.0/24 any (content-list: "adults"; msg: "Adults list access attempt"; react: block;)</bf> </tabular> </table> <p> Figure 19 - Exemples d'utilisation de React <sect>Les préprocesseurs <sect1>Vue d'ensemble des préprocesseurs <p>Les préprocesseurs ont été introduits dans la version 1.5 de Snort. Ils permettent à snort la fonctionnalité d'être étendu en permettant aux utilisateurs et aux programmeurs d'insérer assez facilement dans Snort des "plugins" modulaires. Le code du préprocesseur est exécuté avant que le moteur de détection soit appelé, mais après que le paquet ait été décodé. Le paquet peut être modifié ou analysé de manière non classique au travers de ce mécanisme. <p>Les préprocesseurs sont chargés et configurés en utilisant le mot clé <it>preprocessor</it>. Le format de la directive preprocessor dans les règles de Snort est : <p><bf>preprocessor <nom>: <options></bf> <table> <tabular ca="c"> <bf>preprocessor minfrag: 128</bf> </tabular> </table> <p>Figure 20 - Exemple de Format de la Directive Preprocessor <sect1>Les modules préprocesseurs accessibles <sect2>Minfrag <p>Le préprocesseur minfrag examine les paquets fragmentés pour une valeur limite de taille spécifiée. Quand les paquets sont fragmentés, c'est généralement causé par des routeurs entre la source et la destination. Généralement, il n'y a pas d'équipement réseau commercial qui fragmente les paquets en tailles plus petites que 512 octets, donc nous pouvons utiliser ce fait pour activer la surveillance du réseau pour de petits fragments qui sont généralement indicatifs de quelqu'un essayant de cacher son trafic derrière la fragmentation. <p>Format : <p><bf>minfrag: <valeur limite></bf> <sect2>HTTP Decode <p>HTTP Decode est utilisé pour traiter les chaînes HTTP URI et convertir leurs données en chaînes ASCII non obscurcies. Ceci est fait pour vaincre les scanners évasifs d'URL web et les attaques hostiles qui pourraient autrement échapper aux chaînes d'analyse de contenu utilisées pour examiner dans le trafic HTTP des activités suspicieuses. Le module préprocesseur prend des numéros de ports HTTP (séparés par des espaces) pour être normalisés en arguments (typiquement 80 et 8080). <p>Format : <p><bf>http_decode: <liste de ports></bf> <table> <tabular ca="c"> <bf>preprocessor http_decode: 80 8080</bf> </tabular> </table> <p>Figure 21 - Exemple de Format de la Directive HTTP Decode <sect2>Portscan Detector <p>Le préprocesseur de scans de ports de Snort est développé par Patrick Mullen et (beaucoup) d'autres informations sont disponibles sur sa <htmlurl url="http://spyjurenet.com/linuxrc.org/projects/snort/" name="page web">. <p>Ce que le préprocesseur de scans de ports de Snort fait : <p>Journaliser le début et la fin de scans de ports depuis une unique IP source vers la facilité de journalisation standard. <p>Si un fichier journal est spécifié, il journalise les IP destinations et les ports scannés ainsi que le type de scan. <p>Un scan de ports est défini comme des tentatives de connexion TCP vers plus de P ports en T secondes ou des paquets UDP envoyés à plus de P ports en T secondes. Les ports peuvent être répartis au travers de tout nombre d'adresses IP destinations, et peuvent tous être le même port si ils sont répartis au travers de multiples IP. Cette version fait les scans de ports unique->unique et unique->plusieurs. La prochaine version majeure fera les scans de ports distribués (multiple->unique ou multiple->multiple). Un scan de ports est également défini comme un unique paquet de "scan furtif", tel que NULL, FIN, SYNFIN, XMAS, etc. Ceci signifie que dans scan-lib dans la distribution standard de snort vous devez commenter la section pour les paquets de scans furtifs. Le bénéfice est qu'avec le module de scans de ports ces alertes ne devraient apparaître qu'une fois, plutôt qu'une fois pour chaque paquet. Si vous utilisez la fonctionnalité de journalisation externe vous pouvez voir la technique et le type dans le fichier journal. <p>Les arguments de ce module sont : <itemize> <item>le réseau à surveiller - Le bloc réseau/CIDR à surveiller pour les scans de ports <item>le nombre de ports - le nombre de ports accédés durant la période de détection <item>la période de détection - le nombre de secondes à compter durant laquelle la limite d'accès aux ports est considérée <item>répertoire/fichier - le répertoire/fichier où placer les alertes. Les alertes sont également écrites vers le fichier d'alerte standard. </itemize> <p>Format : <p><bf>portscan: <réseau à surveiller> <nombre de ports> <période de détection> <répertoire/fichier></bf> <table> <tabular ca="c"> <bf>preprocessor portscan: 192.168.1.0/24 5 7 /var/log/portscan.log</bf> </tabular> </table> <p>Figure 22 - Exemple de configuration du module de scans de ports <sect2>Portscan Ignorehosts <p>Un autre module de Patrick Mullen qui modifie le fonctionnement du système de détection de scans de ports. Si vous avez des serveurs qui tendent à activer le détecteur de scans de ports (tels que des serveurs NTP, NFS et DNS), vous pouvez dire au module d'ignorer les SYN TCP et les scans de ports UDP de certains systèmes. Les arguments de ce module sont une liste de blocs IP/CIDR à ignorer. <p>Format : <p><bf>portscan-ignorehosts: <liste de systèmes></bf> <table> <tabular ca="c"> <bf>preprocessor portscan-ignorehosts: 192.168.1.5/32 192.168.3.0/24</bf> </tabular> </table> <p>Figure 23 - Exemple de configuration du module Portscan Ignorehosts <sect2>Defrag <p>Le module defrag (de Dragos Ruiu) permet à Snort d'effectuer de la défragmentation IP, rendant plus difficile pour les pirates de contourner simplement les capacités de détection du système. Il est très simple dans son usage, requérant simplement l'addition d'une directive préprocesseur au fichier de configuration sans aucun argument. Ce module ***supercedes*** généralement la fonctionnalité du module minfrag (c.-à-d. vous n'avez pas besoin d'utiliser minfrag si vous utilisez defrag). <p>Format : <p><bf>defrag</bf> <table> <tabular ca="c"> <bf>preprocessor defrag</bf> </tabular> </table> <p>Figure 24 - Exemple de configuration du préprocesseur defrag <sect2>Stream <p><bf>Ce module est toujours en BETA test, utilisez avec précautions</bf> <p>Le plugin stream fournit la fonctionnalité de réassemblage de sessions TCP à Snort. Les sessions TCP sur les ports configurés avec de petits segments seront réassemblés en un flux de données que Snort peut évaluer proprement pour des activités suspicieuses. Ce plugin prend plusieurs arguments : <itemize> <item>timeout - le temps maximal en secondes pendant lequel une session sera gardée vivante si elle n'a pas vu un paquet pour elle. <item>port - un port serveur à surveiller. Nous ne voulons pas surveiller toutes les sessions tcp (le voulons nous ?) <item>maxbytes - le nombre maximal d'octets dans notre paquet reconstruit </itemize> <p>Format : <p><bf>stream: timeout <temps maximal>, ports <ports>, maxbytes <maximum d'octets></bf> <table> <tabular ca="c"> <bf>preprocessor stream: timeout 5, ports 21 23 80 8080, maxbytes 16384</bf> </tabular> </table> <p>Figure 25 - Exemple de configuration du réassembleur de sessions TCP <sect2>Spade : the Statistical Packet Anomaly Detection Engine <p>Dans l'intéret de l'opportunité et du bon sens, je suggérerais de consulter le fichier README.Spade dans la distribution Snort ainsi que de consulter <htmlurl url="http://www.silicondefense.com/spice/" name="http://www.silicondefense.com/spice/"> <p>Ce module permet à Snort d'être capable d'effectuer de la détection statistique d'anomalies sur votre réseau, et il est essentiellement un nouveau moteur de détection pour Snort. Si vous êtes intéressé dans ce genre de capacité, vous devriez réellement lire la documentation dans la distribution Snort ainsi que celle sur le site <htmlurl url="http://www.silicondefense.com" name="SiliconDefense"> <sect>Les modules de sortie <sect1>Vue d'ensemble des modules de sortie <p>Les modules de sortie sont une nouveauté de la version 1.6. Ils permettent à Snort d'être bien plus flexible dans le formatage et la présentation des sorties à ses utilisateurs. Les modules de sortie son exécutés quand les sous-systèmes d'alerte ou de journalisation de Snort sont appelés, après les préprocesseurs et le moteur de détection. Le format des directives dans le fichier de règles est très similaire à celui des préprocesseurs. Plusieurs plugins de sortie peuvent être spécifiés dans le fichier de configuration de Snort. Quand plusieurs plugins du même type (journal, alert) sont spécifiés, ils sont "empilés" et appelés en séquence quand un événement se produit. Comme avec les systèmes standards de journalisation et d'alerte, les plugins de sortie envoient leurs données à /var/log/snort par défaut ou vers un répertoire désigné par un utilisateur (en utilisant l'option de la ligne de commande "-l"). Les modules de sortie sont chargés au moment de l'exécution en spécifiant le mot clé <it>output</it> dans le fichier de règles : <p><bf>output <nom>: <options></bf> <table> <tabular ca="c"> <bf>output alert_syslog: LOG_AUTH LOG_ALERT</bf> </tabular> </table> <p>Figure 26 - Exemple de Configuration de Module de Sortie <sect1>Les modules de sortie accessibles <sect2>Alert_syslog <p>Ce module envoie les alertes à la facilité syslog (comme l'option -s de la ligne de commande). Ce module permet également à l'utilisateur de spécifier la facilité de journalisation et la priorité dans le fichier de règles de Snort, en donnant aux utilisateurs une plus grande flexibilité dans la journalisation des alertes. <p>Mots clés disponibles : <itemize> <item>Options <itemize> <item>LOG_CONS <item>LOG_NDELAY <item>LOG_PERROR <item>LOG_PID </itemize> <item>Facilités <itemize> <item>LOG_AUTH <item>LOG_AUTHPRIV <item>LOG_DAEMON <item>LOG_LOCAL0 <item>LOG_LOCAL1 <item>LOG_LOCAL2 <item>LOG_LOCAL3 <item>LOG_LOCAL4 <item>LOG_LOCAL5 <item>LOG_LOCAL6 <item>LOG_LOCAL7 <item>LOG_USER </itemize> <item>Priorités <itemize> <item>LOG_EMERG <item>LOG_ALERT <item>LOG_CRIT <item>LOG_ERR <item>LOG_WARNING <item>LOG_NOTICE <item>LOG_INFO <item>LOG_DEBUG </itemize> </itemize> <p>Format : <p><bf>alert_syslog: <facilité> <priorité> <options></bf> <sect2>Alert_fast <p>Ceci imprimera les alertes de Snort dans un format rapide d'une ligne vers un fichier de sortie spécifié. C'est une méthode d'alerte plus rapide que les alertes <it>full</it> car elle n'a pas besoin d'afficher toutes les entêtes des paquets vers le fichier de sortie. <p>Format : <p><bf>alert_fast: <nom du fichier de sortie></bf> <table> <tabular ca="c"> <bf>output alert_fast: alert.fast</bf> </tabular> </table> <p>Figure 27 - Configuration des alertes "fast" <sect2>Alert_full <p>Affiche les messages d'alerte de Snort avec l'intégralité des entêtes des paquets. Cette facilité d'alerte est généralement plutôt lente car elle requière que le programme fasse beaucoup plus d'analyse de données pour formater les données à être imprimées. Les alertes seront écrites dans le répertoire de journalisation par défaut (/var/log/snort) ou le répertoire de journalisation spécifié sur la ligne de commande. <p>Format : <p><bf>alert_full: <nom du fichier de sortie></bf> <table> <tabular ca="c"> <bf>output alert_full: alert.full</bf> </tabular> </table> <p>Figure 28 - configuration des alertes "full" <sect2>Alert_smb <p>Ce plugin envoie des messages d'alerte WinPopup aux noms de machines NETBIOS indiqués dans le fichier spécifié comme argument à ce plugin de sortie. Il doit être noté que l'utilisation de ce plugin <bf>n'est pas</bf> encouragé puisqu'il exécute un exécutable binaire externe (smbclient) au même niveau de privilèges que Snort, communément root. Le format du fichier des stations de travail est une liste de noms NETBIOS des systèmes qui souhaitent recevoir les alertes, un par ligne dans ce fichier. <p>Format : <p><bf>alert_smb: <nom du fichier des stations de travail à alerter></bf> <table> <tabular ca="c"> <bf>output alert_smb: workstation.list</bf> </tabular> </table> <p>Figure 29 - Configuration des alertes "smb" <sect2>Alert_unixsock <p>Configure une socket du domaine UNIX et y envoie les rapports d'alertes. Des programmes / processus externes peuvent écouter cette socket et recevoir les alertes Snort et les données des paquets en temps réel. C'est actuellement une interface expérimentale. <p>Format : <p><bf>alert_unixsock</bf> <table> <tabular ca="c"> <bf>output alert_unixsock</bf> </tabular> </table> <p>Figure 30 - Configuration des alertes "unixsock" <sect2>Log_tcpdump <p>Le module log_tcpdump enregistre les paquets vers un fichier au format tcpdump. Ceci est utile pour effectuer des analyses post traitement sur le trafic collecté avec le grand nombre d'outils qui sont disponibles pour examiner des fichiers au format tcpdump. Ce module ne prend qu'un seul argument, le nom du fichier de sortie. <p>Format : <p><bf>log_tcpdump: <nom du fichier de sortie></bf> <table> <tabular ca="c"> <bf>output log_tcpdump: snort.log</bf> </tabular> </table> <p>Figure 31 - Exemple de configuration du module de sortie "tcpdump" <sect2>Xml <p>Le plugin XML active la journalisation de snort en SNML - simple network markup language alias (snort markup language) vers un fichier ou au travers du réseau. La DTD est disponible dans le répertoire contrib de la distribution de snort et à : http://www.cert.org/DTD/snml-1.0.dtd. Vous pouvez utiliser ce plugin avec une ou plusieurs sondes snort pour journaliser vers une base de données centrale et créer des infrastructures de détection d'intrusion hautement configurables dans votre réseau. Le plugin vous permettra également de rapporter automatiquement les alertes au Centre de Coordination du CERT, votre équipe de réponse, ou votre fournisseur de gestion d'IDS. <p>Ce plugin a été développé par Jed Pickel et Roman Danyliw du Centre de Coordination du CERT comme partie du projet AIRCERT. <p>Soyez conscient que la DTD SNML est dans sa phase précoce de développement et il est probable qu'elle soit modifiée pendant que l'examen public se déroule. <p>Voyez http://www.cert.org/kb/snortxml pour les informations et documentations les plus à jour à propos de ce plugin. <p>La ligne de configuration sera au format suivant : <p><bf>output xml: [log | alert], [liste de paramètres]</bf> <p>Arguments : <p><bf>[log | alert]</bf> - spécifiez log ou alert pour connecter le plugin xml à la facilité de journalisation ou d'alerte. <p><bf>[liste de paramètres]</bf> - La liste de paramètres consiste en paires de clés valeurs. Le format correct est une liste de paires clé=valeur chacune séparée par un espace. <table> <tabular ca="l|l"> file <colsep>quand c'est le seul paramètre il journalisera vers un fichier sur la machine locale. Autrement, si http ou https est employé (voir protocole), c'est le script qui est exécuté sur le système distant. <rowsep>protocol <colsep>Les valeurs possibles pour ce champ sont &nl; &nl;http - envoie un POST dans HTTP à un serveur web (requis : un paramètre [file]) &nl;https - juste comme http mais chiffré et mutuellement authentifié par ssl. (requis : les paramètres [file], [cert], [key]) &nl;tcp - une simple connexion tcp. Vous avez besoin d'utiliser une quelconque sorte de récepteur (requis : un paramètre [port]) &nl;iap - une mise en oeuvre de Intrusion Alert Protocol (ndt : Protocole d'Alertes d'Intrusion) (ceci ne marche pas encore). <rowsep>host <colsep>système distant où les journaux doivent être envoyés <rowsep>port <colsep>le numéro de port auquel se connecter (les ports par défaut sont) &nl; &nl;http 80 &nl;https 443 &nl;tcp 9000 &nl;iap 9000 <rowsep>cert <colsep>le certificat X.509 client à utiliser avec https (au format PEM) <rowsep>key <colsep>la clé privée cliente à utiliser avec https (au format PEM) <rowsep>ca <colsep>le certificat CA utilisé pour valider le certificat du serveur https (au format PEM) <rowsep>server <colsep>le fichier contenant une liste de serveurs valides avec lesquels communiquer. Il est utilisé pour que Snort puisse authentifier le serveur. Chaque serveur est identifié par une chaîne formée par le sujet du certificat X.509 du serveur. Cette chaîne peut être créée par : &nl; &nl;% openssl x509 -subject -in <server certificate>. &nl; &nl;Typiquement seulement quelqu'un déployant le serveur HTTPS aura à effectuer cette tâche (puisqu'ils ont accès au certificat du serveur). Cette entité doit publier cette chaîne sujet pour configuration dans chaque sonde snort. <rowsep>sanatize <colsep>L'argument est une combinaison réseau/masque pour un intervalle d'IP que vous souhaitez être nettoyés. Toute adresse IP dans l'intervalle que vous spécifiez sera représenté par "xxx.xxx.xxx.xxx". Également, pour les alertes nettoyées, aucune charge de paquet ne sera journalisé. Vous pouvez utiliser le paramètre sanitize plusieurs fois pour représenter plusieurs intervalles IP. <rowsep>encoding <colsep>La charge des paquets et les options des données sont binaires et il n'y a pas une façon standard de les représenter en texte ASCII. Vous pouvez choisir l'option de codage binaire qui convient le mieux à votre environnement. Chacun a ses propres avantages et désavantages. &nl; &nl;hex : (défaut) représente les données binaires comme une chaîne hexadécimale. &nl;besoins de stockage... - 2x la taille du binaire &nl;recherches... - très bonnes &nl;lisibilité humaine... - non lisible à moins que vous ne soyez un véritable intello requière du traitement ultérieur &nl; &nl;base64 : représente les données binaires comme une chaîne en base 64. &nl;besoins de stockage... - ˜1.3x la taille du binaire &nl;recherches... - impossible sans traitement ultérieur &nl;lisibilité humaine... - non lisible nécessite du traitement ultérieur &nl; &nl;ascii : représente les données binaires comme une chaîne ascii. C'est la seule option où vous perdrez effectivement des données. Les données non ascii sont représentées en tant qu'un ".". Si vous choisissez cette option alors les données pour les IP et les options tcp seront toujours représentées comme "hex" car cela n'a pas de sens pour ces données d'être en ascii. &nl;besoins de stockage... - Bien plus large que les données binaires car quelques caractères ont besoin d'être échappés (&, <, >) &nl;recherches... - très bonne pour rechercher uns chaîne de texte impossible si vous voulez rechercher du binaire &nl;lisibilité humaine... - très bonne <rowsep>detail <colsep>Combien de données détaillées voulez-vous enregistrer ? Les options sont : &nl; &nl;full : (défaut) journalise tous les détails d'un paquet qui a causé une alerte (en incluant les options ip et tcp et la charge) &nl; &nl;fast: journalise seulement une quantité minimale de données. Vous limitez sévèrement le potentiel de quelques application d'analyse si vous choisissez cette option, mais ceci est toujours le meilleur choix pour quelques applications. Les champs suivants sont journalisés (horaire, signature, ip source, ip destination, port source, port destination, drapeaux tcp et protocole) </tabular> </table> <p>Format : <p><bf>xml: <facilité de sortie></bf> <table> <tabular ca="c"> <bf>output xml: log, file=output</bf> <rowsep><bf>output xml: log, protocol=https host=air.cert.org file=alert.snort cert=mycert.crt key=mykey.pem ca=ca.crt server=srv_list.lst</bf> </tabular> </table> <p>Figure 32 - exemples de configuration du plugin de sortie XML <sect2>Database <p>Ce module de Jed Pickel envoie les données de Snort à une variété de bases de données SQL. Plus d'informations sur l'installation et la configuration de ce module peuvent être trouvées sur la <htmlurl url="http://www.incident.org/snortdb" name="page web d'Incident.org">. Les arguments de ce plugin sont le nom de la base de données vers laquelle journaliser et une liste de paramètres. Les paramètres sont spécifiés avec le format <it>paramètre</it> = <it>argument</it>. Les paramètres suivants sont disponibles. <table> <tabular ca="l|l"> host <colsep>Le système auquel se connecter. Si une chaîne de longueur non nulle est spécifiée, une communication TCP/IP est utilisée. Sans un nom de machine, il se connectera en utilisant une socket du domaine Unix local. <rowsep>port <colsep>Le numéro de port auquel se connecter au système serveur, ou une extension de nom de fichier de socket pour les connexions de domaine Unix. <rowsep>dbname <colsep>Le nom de la base de données <rowsep>user <colsep>Le nom de l'utilisateur de la base de donnée pour l'authentification <rowsep>password <colsep>Le mot de passe utilisé si la base de données demande une authentification par mot de passe <rowsep>sensor_name <colsep>Spécifie votre propre nom pour cette sonde snort. Si vous ne spécifiez pas de nom un sera généré automatiquement <rowsep>encoding <colsep>Parce que la charge du paquet et les options des données sont binaires, il n'y a pas une façon simple et portable de les enregistrer dans une base de données. BLOBS ne sont pas utilisés car ils ne sont pas portable entre les bases de données. Donc je vous laisse l'option de codage. Vous pouvez choisir parmi les options suivantes. Chacune a ses propres avantages et des désavantages : &nl; &nl;hex : (défaut) représente les données binaires comme une chaîne hexadécimale. &nl;besoins de stockage... - 2x la taille du binaire &nl;recherches... - très bonnes &nl;lisibilité humaine... - non lisible à moins que vous ne soyez un véritable intello requière du traitement ultérieur &nl; &nl;base64 : représente les données binaires comme une chaîne en base 64. &nl;besoins de stockage... - ˜1.3x la taille du binaire &nl;recherches... - impossible sans traitement ultérieur &nl;lisibilité humaine... - non lisible nécessite du traitement ultérieur &nl; &nl;ascii : représente les données binaires comme une chaîne ascii. C'est la seule option où vous perdrez effectivement des données. Les données non ascii sont représentées en tant qu'un ".". Si vous choisissez cette option alors les données pour les IP et les options tcp seront toujours représentées comme "hex" car cela n'a pas de sens pour ces données d'être en ascii. &nl;besoins de stockage... - Bien plus large que les données binaires car quelques caractères ont besoin d'être échappés (&, <, >) &nl;recherches... - très bonne pour rechercher uns chaîne de texte impossible si vous voulez rechercher du binaire &nl;lisibilité humaine... - très bonne <rowsep>detail <colsep>Combien de données détaillées voulez-vous enregistrer ? Les options sont : &nl; &nl;full : (défaut) journalise tous les détails d'un paquet qui a causé une alerte (en incluant les options ip et tcp et la charge) &nl; &nl;fast: journalise seulement une quantité minimale de données. Vous limitez sévèrement le potentiel de quelques application d'analyse si vous choisissez cette option, mais ceci est toujours le meilleur choix pour quelques applications. Les champs suivants sont journalisés (horaire, signature, ip source, ip destination, port source, port destination, drapeaux tcp et protocole) </tabular> </table> <p>De plus, il y a une méthode de journalisation et un type de base de données qui doivent être définis. Il y a deux types de journalisation disponibles, <it>log</it> et <it>alert</it>. Fixer le type à log attache la fonctionnalité de journalisation de database à la facilité de journalisation dans le programme. Si vous fixez le type à log, le plugin sera appelé dans la chaîne de sortie log. Fixer le type à <it>alert</it> attache le plugin à la chaîne de sortie alert dans le programme. <p>Il y a quatre bases de données disponibles dans la version courante du plugin qui sont MySQL, PostgreSQL, Oracle et les bases de données compatibles unixODBC. Fixez le type pour correspondre à la base de données que vous utilisez. <p>Format : <p><bf>database: <log | alert>, <type de base de données>, <liste de paramètres></bf> <table> <tabular ca="c"> <bf>output database: log, mysql, dbname=snortuser=snort host=localhost password=xyz</bf> </tabular> </table> <p>Figure 33 - Configuration du plugin de sortie "database" <sect>Construire de bonnes règles <p>Il y a quelques concepts généraux à garder à l'esprit en développant des règles Snort pour maximiser l'efficacité et la vitesse. Je ferai des rajouts à cette section quand ma muse le voudra. :) <sect1>Les règles de contenus différencient majuscules et minuscules (à moins que vous n'utilisiez l'option "nocase") <p>N'oubliez pas que les règles content font la différence entre majuscules et minuscules et que beaucoup de programmes utilisent typiquement les lettres majuscules pour indiquer les commandes. FTP en est un bon exemple. Considérez les deux règles suivantes : <p><bf>alert tcp any any -> 192.168.1.0/24 21 (content: "user root"; msg: "FTP root login";) </bf> <p><bf>alert tcp any any -> 192.168.1.0/24 21 (content: "USER root"; msg: "FTP root login";)</bf> <p>La seconde de ces deux règles va capturer la plupart des tentatives de connexion root automatiques, mais aucune qui utilise les caractères minuscules pour "user". <sect1>Accélérer les règles qui ont des options de contenus <p>L'ordre dans lequel les règles sont testées par le moteur de détection est complètement indépendant de l'ordre dans lequel elles sont écrites dans une règle. Le dernier test de règle qui est effectué (quand nécessaire) est toujours l'option de règle content. Prenez avantage de ce fait en utilisant d'autres options de règles plus rapides qui peuvent détecter si oui ou non le contenu a besoin d'être vérifié. Par exemple, la plupart du temps quand des données sont envoyées du client au serveur après qu'une session TCP soit établie, les drapeaux PSH et ACK sont fixés sur le paquet contenant les données. Ce fait peut être utilisé avantageusement par les règles qui ont besoin de tester le contenu de la charge provenant du client vers le serveur avec un simple test de drapeaux TCP qui nécessite bien moins de ressources en calculs que l'algorithme de correspondance de motifs. En sachant cela, une façon simple d'accélérer les règles qui utilisent l'option content est d'effectuer également un test flag, comme dans la Figure 23. L'idée de base est que lorsque les drapeaux PSH et ACK ne sont pas fixés, il n'y a pas besoin de tester la charge du paquet pour la règle donnée. Si les drapeaux sont fixés, la puissance de calcul additionnelle nécessaire pour effectuer le test est négligeable. <table> <tabular ca="c"> <bf>alert tcp any any -> 192.168.1.0/24 80 (content: "cgi-bin/phf"; flags: PA; msg: "CGI-PHF probe";)</bf> </tabular> </table> <p>Figure 34 - Utilisation des tests de drapeaux TCP pour accélérer les règles de contenu <table> <tabular ca="c"> <it>Version 1.2, Tous droits réservés, © Copyright 1999-2001 Martin Roesch</it> <rowsep><it>traduction française © Copyright 2001 Denis Ducamp</it> </tabular> </table> </article>