Détecter les attaques avec snort - Sécurité des réseaux informatiques

Détecter les attaques

Nessus permet de détecter des vulnérabilités répertoriées, des outils tels Metasploit montrent encore plus les

risques encourus, mais comment être informé si ces outils (ou d’autres) servent lors de tentatives d’intrusions ?
Les détecteurs d’intrusions répondent à cette question, ils permettent de détecter des activités anormales sur un réseau ou sur une machine.

Les HIDS détectent les activités suspectes en effectuant des études comporte-mentales (analyse des journaux du système et des applications) ou en vérifant l’intégrité des fchiers ainsi que celle du noyau. Les NIDS agissent comme des sondes qui analysent tous les paquets pour les comparer à une base de signatures d’attaques connues et répertoriées. La suite de ce chapitre présente snort, un des NIDS les plus utilisés.

1 - snort

snort est un NIDS développé sous licence GPL par la société Sourcefire. Snort s’appuie sur une bibliothèque de signatures dont la distribution et la mise à jour nécessitent une souscription annuelle de 399 $.

snort capture et analyse les paquets qu’il voit passer et peut être utilisé comme snifer (avec ou sans écriture dans un journal) ou comme NIDS.

    
Le fonctionnement de snort comme NIDS est basé un fchier de configuration (snort.conf) ainsi qu’une base de signatures (les règles). Parmi les options de snort configurables dans snort.conf, on peut citer les suivantes :

 

   
– HOME_NET : une liste des réseaux à surveiller ([10.1.1.0/24,192.168.1.0] par exemple)

– DNS_SERVERS, HTTP_SERVERS, ... : une liste des serveurs à surveiller. Il n’est pas utile de traiter les attaques qui sont sans objets, i.e qui ciblent des machines n’hébergeant pas le service attaqué.

– RULE PATH : le répertoire contenant la base des signatures (/usr/local/etc/snort/rules par défaut).

1.1 - Les règles de snort

Les paquets capturés par une sonde snort sont analysés en fonction de règles qui décrivent des attaques ou des vulnérabilités connues. Les règles dont l’utilisation est configurable dans snort.conf sont regroupées par nature dans des fichiers comme dans les exemples suivants  :

– bad-traffic.rules : des signatures figurant du trafic qui ne devrait jamais apparaître sur n’importe quel réseau ;

– web-php.rules : des signatures de scripts php réputés vulnérables ;

– scan.rules : des signatures figurant les scanners (nmap, ...) ;

Les règles de snort sont écrites dans un langage qui permet de décrire un paquet à analyser. Une règle est divisée en deux parties : la première permet de sélectionner les paquets ciblés, la seconde indique le sous-ensemble du paquet à inspecter en détail ainsi que le message d’alerte à générer si l’analyse est positive.

L’exemple suivant est extrait de x11.rules qui ici génère une alerte si un usage de l’authentification MIT-MAGIC-COOKIE-16 est détecté :

          
La ligne 1 correspond à l’entête de la règle, elle sélectionne les paquets à analyser de la manière suivante :

– alert : l’action à déclancher si l’analyse est positive. Ici alert indique de générer une alerte dans le fichier alert. Par défaut, le paquet sera aussi journalisé (démarrer snort avec l’option -N pour supprimer la journalisation des paquets engendrant des alertes) ;

– tcp : sélection du protocole ;

– $EXTERNAL_NET : adresse IP source (cf. snort.conf) ;

– any : port source ;

– $HOME_NET : adresse IP destination (cf. snort.conf) ;

– 6000 : port destination ;

Les lignes 2,3 et 4 sont des options de la règle :

– msg : le message qui sera indiqué dans l’alerte ;

– content : le texte qui est recherché dans le contenu du paquet ;

– flow : le sens du trafic TCP;

– reference : des références de la vulnérabilité sur des sites (bugtraa, cve, nessus, arachnids, ...) dédiés aux attaques ;

Une documentation sur l’écriture des règles de snort est disponible dans le Snort Users Manual

1.2 - Comment placer la sonde snort

cf. section 1.1.

1.3 Utiliser snort

Le démarrage de snort comme NIDS peut s’effectuer avec la ligne de commande suivante qui indique un démarrage comme daemon (NIDS), avec un fichier de configuration situé dans /usr/local/etc/snort :

snort -d -c /usr/local/etc/snort/snort.conf

Pour utiliser snort dans de bonnes conditions, il convient de décider quelles sont les règles qui doivent être utilisées. La configuration des règles s’effectue dans le fichier snort.conf, il faut commenter les règles inutiles. Par exemple, un site quin’exploite pas de serveurs IIS a intérêt à ne pas générer d’alertes s’il reçoit des attaques sur ce type de service.

Il convient également de configurer une méthode de propagation des alertes adaptée aux administrateurs des réseaux à surveiller. Le fichier des alertes de snort(/var/log/snort/alert) n’est pas de lecture aisée (cf. figure 1), un mail relatif à chaque alerte peut très rapidement s’avérer inexploitable : une interface de consultation exploitant le fichier des alertes est nécessaire.

 

Fig. 1 – Le fichier des alertes de snort

1.3.1 Gérer les alertes de snort avec BASE

BASE (Basic Analysis and Security Engine) est une interface de consultation des alertes de snort. BASE effectue un tri des alertes et propose de sélectionner les alertes du jour, les alertes uniques, ... Les figures 2 et 3 montrent respectivement la page d’accueil d’un service BASE et un écran de visualisation des alertes uniques.

Fig. 2 – La page d’accueil d’un service BASE

Fig. 3 – Les alertes uniques

1.3.2 snort et les faux positifs

Le problème principal posé par l’exploitation d’une sonde snort est l’analyse des alertes positionnées. Quelles sont les alertes justifiées ? Comment éliminer les alertes intempestives (les faux positifs) ?

L’utilisation d’une interface de consultation des alertes telle que BASE procure un premier élément de confort : les alertes sont triées et consultables indépendamment de leurs occurences. Il reste tout de même à vérifier l’importance des faits signalés, cette opération n’est pas automatisable, elle doit être effectuée avec précision.

L’exemple suivant, issu du fichier contenant des règles ciblant les attaques sur des scripts CGI, illustre la part d’investigation laissée aux administrateurs : une alerte est remontée, elle indique qu’un des serveurs Web surveillés a reçu une requête d’accès à sendmessage.cgi. BASE précise la référence de la vulnérabilité (cve-2001-1100) : sendmessage.cgi in W3Mail 1.0.2, and possibly other CGI programs, allows remote attackers to execute arbitrary commands via shell metacharacters in any field of the ’Compose Message’ page.. Si W3Mail 1.0.2 est en service alors il s’agit peut-être d’une attaque, dans le cas contraire l’alerte est un faux positif. Plus généralement, on notera qu’un appel à un script nommé sendmessage.cgi engendrera une alerte qu’il fasse partie ou pas de W3Mail 1.0.2.

A l’issue d’une alerte, lorsque les investigations sont terminées, l’administrateur peut s’il le juge nécessaire, commenter les règles qui génèrent des alertes non justifiées.

------------------------------------------------------------------------------------------------------

 >>> CHAPITRE VI : Détection post intrusion