Snort Inline

1. Introduction

Les menaces à destination d'un réseau interne sont de plus en plus présentes à cause de la démocratisation d'internet, donc d'applications riches, donc de vecteurs d'attaques amplifiés et le tout automatisé par des vers ou virus. Malheureusement, ces attaques deviennent extrêmement complexes, à tel point qu'il n'est pas possible pour un être humain normalement constitué d'ingurgiter la masse d'information vue la rapidité de diffusion des vulnérabilités et des attaques.

Heureusement, il existe un logiciel libre qui est capable de mettre en relation le flux réseau avec des signatures, de la même façon qu'un anti-virus va mettre en relation des signatures avec des binaires statiques. Ce logiciel s'appelle Snort et est disponible sur le site http://www.snort.org.

Mais attention, ne téléchargez pas cette version, car nous allons utiliser une variante qui s'appelle Snort Inline et qui est un projet à part entière, et a son propre site : http://snort-inline.sourceforge.net (là, vous pouvez télécharger).

Nous allons prendre les sources, version snort_inline-2.6.1.5.

Snort est découpé en 3 parties principales, comme le sera cet article. La première partie est celle de la capture du flux réseau :

- Capture : Alors que le Snort classique se base sur la libpcap, qui est la bibliothèque qui fût développée pour écrire le sniffeur tcpdump, Snort inline utilise la libnetfilter queue.

- Signatures : Il existe plusieurs milliers de signatures qui fonctionnent à plusieurs niveaux. Nous allons en voir quelques-unes pour comprendre comment en écrire, mais aussi comment elles peuvent se configurer dans le snort_inline.conf.

- Alerte : Ce qui est remonté à l'administrateur lorsqu'une attaque est détectée. Nous allons voir que des alertes nous sont remontées dans des cas où il n'y a pas forcément d'attaque. Cela s'appelle les « faux positifs ».

 

 

Nous allons mettre en place Snort Inline en mode pont, c'est-à-dire que la machine n'aura pas d'adresse IP.

Pour couper court à une guerre de religion récurrente sur la détection d'intrusions, la machine sera placée derrière le pare-feu, car seuls les paquets qui arrivent sur notre réseau nous intéressent. Il est insensé de mettre la machine devant le pare-feu, car internet regorge d'activités malveillantes (vers, scans, etc.) qui ne vous concerne pas forcément. Cela augmente votre charge de travail inutilement, car vous devrez filtrer les faux positifs de vraies attaques, et ,au final, vous n'utiliserez pas l'outil. Le seul cas où c'est intéressant de le faire est pour le fun, pour constater en vrai ces activités malveillantes (et encore, difficile d'être mort de rire avec ça ! Ahahahah !).

Le but de cet article étant de pouvoir mettre en pratique sur votre réseau une installation de Snort Inline, nous irons à l'essentiel.

2. Installation

Nous prenons une Debian Lenny comme distribution de référence. Snort Inline peut se compiler sous toutes les grandes distributions sans problème. Il suffira d'adapter les packages par rapport à ce qui est disponible.

Dans un premier temps, il faut récupérer les sources, puis décompresser.

On a besoin des bibliothèques de Netfilter et de la libpcap pour la capture :

Comme Snort dépend de la libpcre (Perl Compatible Regular Expression) pour permettre l'emploi d'expressions régulières pour la recherche de motifs, on l'installe aussi :

Enfin, Snort utilise la libdumbnet pour le premier décodage des paquets :

On récupère le patch qui va bien chez l'ami Pierre (parce que, sous Debian, on utilise dumbnet et pas dnet, qui n'a rien à voir) :

Puis, on lance la régénération du configure.in avec le patch dumbnet, puis le script configure qui va bien (support nfnetlink, utilisation de dumbnet et support des pthreads), pour enfin compiler, puis installer :

On copie la configuration :

Quand Snort et sa configuration sont installés, malheureusement tout ne fonctionne pas comme prévu. Plutôt que de vous faire croire que nous sommes dans le monde des Pokémons comme n'hésitent pas à le faire certaines personnes machiavéliques et dont je tairais le nom, nous allons voir étape par étape comment comprendre l'erreur et la régler.

La capture se faisant via Netfilter, il faut positionner une règle lui disant d'aller envoyer les paquets à nfqueue. Dans notre cas, nous faisons une installation sur une passerelle, tout passe par FORWARD :

Du coup, nous pouvons démarrer Snort avec sa configuration par défaut :

Le répertoire /var/log/snort n'existant pas, on le crée :

On relance :

Ceci est dû au fichier classification.config qui n'existe pas dans le répertoire voulu. On va d'abord configurer la variable RULE_PATH (ligne 48) :

Enfin, il ne nous reste plus qu'à commenter toutes les lignes incluant des signatures à partir de la ligne 666 dans le fichier snort_inline.conf.

Par défaut, les signatures ne sont pas installées. Il existe un projet communautaire de signatures Snort du nom d'Emerging threats, qui distribue ses signatures via le site web http://www.emergingthreats.net/.

Nous allons récupérer toutes les signatures dans un seul fichier, téléchargeable à l'adresse :

http://www.emergingthreats.net/rules/emerging-all.rules

À la fin du fichier snort_inline.conf, on rajoute la ligne pour inclure ce fichier de signatures :

Et là, quand on lance Snort, on peut enfin voir un message qui fait plaisir :

Ne vous inquiétez pas, il ne décode pas depuis eth0, mais depuis NFQUEUE. L'astuce consiste à traduire ce qui vient de Netfilter en PCAP, afin de toucher le moins possible au code de Snort.

Pour tester, vous pouvez lancer un nmap et regarder /var/log/snort/alerts l'alerte arriver :

Si vous ne voyez rien, faites bien attention à l’endroit où vous capturez avec Netfilter. Dans le pire des cas, essayez de rajouter la règle de capture sur la chaîne INPUT :

Cependant, faites attention de ne surtout pas vous couper l'accès à la machine ! Dans le même ordre d'idée, il vaut mieux ne pas filtrer les flux sur l'interface loopback.

Évidemment, il reste encore des réglages à faire, que nous allons développer un peu plus loin. Mais, vous avez déjà une installation fonctionnelle vous permettant de tester.

3. La détection d'intrusion réseau

Maintenant que le paquet est arrivé, il y a toute une série d'opérations que Snort va faire afin d'empêcher une intrusion sur votre réseau.

3.1 La fragmentation des paquets

Si un paquet trop grand est émis sur le réseau (plus grand que le paramètre MTU), il va être fragmenté en plusieurs paquets, et envoyé en plusieurs morceaux. Cependant, le réassemblage ne se fera pas de la même façon suivant la pile du système d'exploitation sur lequel le NIDS fonctionne comparé au système cible. C'est-à-dire que le motif d'une attaque peut se retrouver dans plusieurs paquets qui ne se réassembleront pas pareil (en jouant sur l'overlapping), et ainsi l'attaquant contournera Snort.

 

 

Le problème avec la fragmentation provient du fait que lorsque la RFC sur IP a été transformée en code, certaines parties n'étaient pas suffisamment détaillées. Cela a eu pour résultat d'avoir les systèmes d'exploitation implémentant de manière différente certains mécanismes permettant d'ailleurs à p0f ou à nmap de déduire le système d'exploitation uniquement avec quelques tests actifs ou passifs sur la pile.

Il faut bien comprendre que le système de détection d'intrusion n'est pas le système d'exploitation cible et que certains outils comme Fragroute (http://monkey.org/~dugsong/fragroute/) exploitent ces faiblesses.

Il y a plusieurs manière d'empêcher ce problème : Snort, à travers son préprocesseurs frag3, permet de créer des pseudo-paquets qui sont entièrement réassemblés à la manière du système d'exploitation cible configuré.

Une autre méthode consiste à empêcher complètement l'overlapping, car il n'est pas normal d'en avoir sur son réseau.

3.2 Le décodage

Une fois que nous sommes sûrs de récupérer les paquets réassemblés et que l'on arrive à capturer tous les flux réseau, il nous reste une étape importante : le décodage.

Il s'agit d'arriver à empêcher un attaquant de faire de l'évasion de signatures en exploitant les faiblesses des applications.

Par exemple, si nous prenons une signature faisant de la reconnaissance d'attaque en se basant sur une URL web, la signature contiendra le motif dans l'option uricontent comme ceci :

Dans le cas où la machine ciblée par l'attaque n'utilise pas le serveur web Apache mais IIS, le signe backslash « \ » pourra être utilisé à la place de slash « / » et, du coup, la signature pourra être contournée simplement parce que le contenu des paquets ne correspondra pas à la signature.

Cela s'applique aussi à l'UTF-8, où les signatures sont en général écrites dans le jeu de caractères ISO-8859-1 et, du coup, la correspondance ne se fera pas... sauf par l'application ciblée et pouvant elle décoder ces caractères et du coup subir l'attaque.

En langage Snort, les décodeurs sont appelés préprocesseurs et sont activables directement depuis la configuration. Ils ont aussi un sens d'activation logique, qui suit ce qui est défini dans cette configuration.

Il y a aussi un sens selon lequel ils doivent être activés. Regardons de plus près 3 préprocesseurs :

 

Nom	Lignes de code	Description
Frag3	4479	Réassembleur de flux, détection d'attaques concernant la fragmentation...
Stream5	11292	Suivi de connexion (tcp, udp et icmp), envoi d'alertes sur des attaques ciblant des anomalies sur les protocoles qu'il suit...
http_inspect	3497	Normalisation des URI, création du buffer uricontent pour récupérer depuis les signatures uniquement la requête. Envoi d'alertes ciblant http...

Le nombre de lignes de codes est donné à titre indicatif pour que vous compreniez la complexité de ces différents modules (et donc de leurs vulnérabilités potentielles ;)).

Le sens d'activation de ces différents décodeurs est important, tout simplement parce qu'il y a une chaîne de dépendances : on activera d'abord frag3, puis stream5 et enfin http_inspect. Il n'est pas possible de faire correctement de la récupération d'URI si le flux n'a pas tout d'abord été réassemblé, puisque nous sommes dans l'état où nous recevons le PUSH | ACK dans le sens client->serveur.

Comme dit un peu plus haut, les décodeurs se configurent directement depuis le fichier de configuration de Snort Inline.

3.3 La recherche de motifs

Rechercher une chaîne de caractères n'est pas si simple. Il existe un tas d'algorithmes qui sont en général utilisés par les applications type éditeur de texte. Linux possède aussi une API de recherche de texte (TextSearch API) et, d'ailleurs, Netfilter peut manipuler des paquets réseau par rapport aux motifs qu'ils contiennent.

Il peut être utile sur une machine limitée de changer l'algorithme que Snort utilise. Par exemple, dans le fichier de configuration, on peut activer le mode de recherche utilisant le moins de mémoire possible en ajoutant la ligne :

Par défaut, Snort utilisera l'algorithme Aho-Corasick NFA (L'algo Aho-Corasick standard ayant pour complexité O(|X|+ n)). Mais, il est possible d'en changer. Voici la liste des choix possibles :

 

Nom	Description	Mémoire consommée	Performances
ac	Aho-Corasick complet	élevée	Le meilleur de tous
ac-std	Aho-Corasick Standard	moyenne	élevées
ac-bnfa	Aho-Corasick NFA	faible	élevées
acs	Aho-Corasick Sparse	faible	moyennes
ac-banded	Aho-Corasick Banded	faible	moyennes
ac-sparsebands	Aho-Corasick Sparse-Banded	faible	élevées
lowmem	Utilisation faible de la mémoire	faible	faibles

Beaucoup de choix algorithmiques sont là tout simplement parce que, Snort étant un logiciel libre, c'est tout naturellement que les chercheurs en détection d'intrusion l'ont modifié et y ont contribué dans le cadre de leurs publications.

Dans une signature, cette recherche de motifs se fait à travers l'option content. Mais, Snort permet aussi de faire de la recherche de motifs grâce aux fameuses Perl Compatible Regular Expressions (PCRE), qui s'utilisent via l'option pcre.

Du coup, vient la question : « Comment Snort gère la recherche de texte entre les algorithmes standards et ceux de PCRE ? ».

Tout d'abord, faire des expressions rationnelles sur des paquets réseau est extrêmement coûteux en performances.

La recherche de motifs se fait dans le fichier fpcreate.c et Snort cherche d'abord à récupérer les motifs les plus longs dans les signatures (fonction fpAddLongestContent()). Le trafic passe ensuite dans une phase de préqualification appelée « MPSE ». Ici, les signatures sont testées de manière séquentielle.

Tant que le trafic n'a pas passé cette phase de MPSE, l'option pcre est ignorée. Une fois que la phase est passée, il ne reste que très peu de signatures à tester (généralement une ou deux) et on peut donc appliquer directement l'algorithme DFA ou NFA que PCRE appliquera.

Si les recherches de motifs efficaces vous passionnent, il vous faut alors un site passionnant sur ce sujet, et je ne peux que vous recommander d'aller plus loin grâce au travail formidable sur ce sujet de Thierry Lecroq (http://www-igm.univ-mlv.fr/~lecroq/).

3.4 Les alertes

Lorsque votre Snort tourne, il ne faut en général pas longtemps pour que vous ayez des alertes (et si ce n'est pas le cas, Nessus est votre ami).

Les alertes sont stockées dans un fichier plat, qui, sur beaucoup de configurations, est /var/log/snort/alerts, mais qui, pour le cas de la version de Snort que nous utilisons, est configuré par défaut pour aller dans output alert_full: snort_inline-full.

Dans le snort_inline.conf, tout est configuré par les directives output et deux modes sont activés :

Le mode full enregistrera toutes les en-têtes des paquets, tandis que fast imprimera tout sur une seule ligne au moyen de quelques suppressions d'informations.

On retrouve ces fichiers dans /var/log/snort/.

Si on regarde les alertes générées, on retrouvera deux types d'alertes.

Les alertes de signatures :

et les alertes des préprocesseurs :

La différence entre les deux est que dans le cas de l'alerte par signature, si l'on estime que l'alerte est un faux positif, il suffit de repérer le Snort ID de la signature (sur la première ligne, c'est le deuxième nombre entre crochets ; dans notre cas, c'est le numéro 2466) et d'aller éditer les signatures pour rajouter un # devant la ligne de l'alerte.

Dans le deuxième cas, lorsqu'il s'agit d'une alerte de préprocesseur, on voit son nom apparaître sur la première ligne entre parenthèses, avant la description de l'attaque. Il s'agit ici du module de détection de scan de ports portscan.

Cependant, il faut faire très attention avant d'enlever les signatures que vous estimez ne pas être une attaque : il ne faut pas que ça joue contre vous et que, du coup, vous manquiez de réelles attaques. Il vaut mieux améliorer la signature et envoyer vos modifications au projet Emerging threats.

Ce qui peut être compliqué, c'est que, dans certains cas, la signature concerne bien une attaque, mais que, dans votre cas bien précis, ce ne soit qu'un mode de fonctionnement du réseau de votre entreprise (oui, toi qui me lis et qui transmets par tes applications le contenu de tes documents par URL et qui reçoit les alertes parce que l'URL est > 1024 caractères, je pense à toi !).

Si on regarde la signature de notre première alerte, nous avons ceci :

La complexité de la règle nous montre qu'il y a vraiment peu de chances pour que ce soit un positif.

Pour tous vous dire, il s'agit de la machine principale du chapitre honeynet Français, et un Nepenthes tourne dessus pour simuler des vulnérabilités Windows et récupérer ainsi des virus et vérifier le niveau de détection de ClamAV, ainsi que des évolutions des virus. Il est donc normal qu'il y ait ce type d'alertes.

En ce qui concerne la suppression de faux positifs sur les préprocesseurs, cela devient un peu plus compliqué. Il faut en général se renseigner dans la documentation sur le type d'alertes générées par le préprocesseur, et, dans le cas où nous sommes sûrs d'avoir un faux positif, le désactiver dans la configuration de Snort. Par exemple, sur smtp, la configuration est :

Chaque ligne est une option que l'on peut supprimer ou modifier en fonction de notre environnement : si jamais votre entreprise a un nom de domaine tellement long et des noms d'utilisateurs tellement longs aussi, vous aurez tout à gagner à modifier la valeur de alt_max_command_line_len 300 { RCPT }, sous peine d'avoir une alerte pour chaque courriel reçu.

Certes, ce cas-là est un peu extrême, mais songer d'abord à paramétrer les préprocesseurs correspondant aux alertes que vous recevez, afin d'écarter au maximum les faux positifs.

4. Les signatures

Si l'on regarde d'un peu plus près les signatures, elles ont un format bien spécifique. Prenons une signature pour l'exemple :

Il s'agit ici de détecter une injection SQL sur l'application Cacti.

Une signature est divisée en deux grandes sections :

- l’en-tête : alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS

- l’option : (msg:... et tout le reste

L'en-tête décrit à partir de quel moment il faut aller plus loin dans l'introspection du paquet. Par exemple, ici, on cherche une vulnérabilité qui sera exploitée sur le protocole tcp depuis le réseau externe ($EXTERNAL_NET), depuis n'importe quel port (le premier any) vers (->) les serveurs HTTP ($HTTP_SERVERS) écoutant sur les ports classiques HTTP ($HTTP_PORTS).

Ensuite, nous regardons le sens des flux. Il faut qu'il soit connecté au sens TCP du terme. En général, c'est quand on a les flags PUSH et ACK (flow:established,to_server;). Il faut que l'URL contienne tree.php?, leaf_id=, UPDATE et UPDATE avec SET plus loin (que l'on recherche en Aho-Corasick). Le nocase veut simplement dire que l'on cherche ce motif quelle que soit la casse.

Enfin, il ne nous reste plus qu'à classifier et mettre des informations. Il s'agit d'une attaque sur une application web, possédant un CVE et un numéro de bugtraq (vous permettant de retrouver un éventuel exploit pour tester vos applications).

Le rev:2 nous montre qu'il y a eu deux révisions sur la règle.

Vous pouvez bien sûr vous inspirer d'autres signatures pour faire les vôtres, et participer au projet Emerging threats pour envoyer vos signatures.

Une fonctionnalité du mode Inline est de pouvoir supprimer les attaques, et cela ne peut se faire que grâce à la fonction drop, que l'on met à la place de alert en tout début de règle. Ainsi, Netfilter fera le choix de bloquer le paquet non plus sur des simples états, destinations où sources, mais sur de véritables intrusions qui n'atteindront même pas les machines cibles.

5. Pour aller plus loin

Maintenant que vous savez utiliser Snort et comprenez quelques-uns des rouages de la détection d'intrusion, je ne peux que vous recommander d'aller un petit peu plus loin avec la sélection des paquets et la gestion des alertes.

Pour la sélection des paquets, puisque Netfilter permet de faire de la sélection basée sur l'API TextSearch du noyau Linux, nous n’allons envoyer dans la NFQUEUE que les paquets qui auront été choisis parce que leur texte est disponible directement dans les signatures de Snort.

Le projet FWSnort (http://cipherdyne.org/fwsnort/) permet de traduire les signatures de Snort en règles Netfilter avec cette sélection de paquet. Malheureusement, il n'est pas possible d'avoir toutes les signatures par ce biais, mais c'est cependant très pratique quand on laisse le noyau faire la recherche de motifs à la place de Snort.

En ce qui concerne la gestion des d'alertes, il existe le projet Prelude IDS (http://www.prelude-ids.org) qui permet de normaliser les alertes que Snort envoie au format IDMEF (Intrusion Detection Message Exchange Format). Snort peut ainsi profiter de l'interface graphique Prewikka, et coupler ses informations à d'autres logiciels de détection d'intrusions comme OSSEC, voire d'autres Snort à différents endroits du réseau afin d'agréger les alertes et aussi de pouvoir les corréler et récupérer des alertes plus pertinentes.

6. Conclusion

Snort peut se mettre en place assez facilement, et rapidement détecter des intrusions comme des comportements sur votre réseau. D'autant plus qu'en mode Inline Snort peut bénéficier de tous les avantages de Netfilter. Cependant, il ne faut pas négliger l'affinage des règles pour arriver petit à petit à un système qui vous remonte des alertes de façon assez fiable.