Par Ayoub Figuigui – le 17/07/10

Préconisations, Installation, configuration.

1. Introduction sur les IDS

Aujourd’hui les systèmes d’information des entreprises sont de plus en plus ouverts sur le réseau des réseaux (Intenet). Ainsi la mise en place des mesures sécuritaires devient une condition nécessaire, mais pas suffisante pour se protéger des risques présents sur la toile internet.

Ainsi les entreprises commencent à prendre conscience de l’importance de la sécurité informatique et intègrent des mécanismes de sécurité dans leurs architectures réseaux. De plus la mise en place d’une politique de sécurité informatique autour de ces systèmes d’information et détecter d’éventuelles intrusions devient une nécessité pour estimer la complétude de cette politique de sécurité.

Dans cette perspective, outre la mise en place de pare-feux et des systèmes d’authentification sécurisés, les systèmes de détection d’intrusions (IDS) et les systèmes de protection d’intrusions (IPS) interviennent pour assurer une protection efficace face aux tentatives intrusives des systèmes d’information. Cependant cette protection révèle certaines limites dues à la multitude des techniques et des possibilités de contournement mais aussi la complexité des choix au niveau de la politique de sécurité à adopter et des obligations vis-à-vis des dispositions légales (Sarbane Oxley, BALE II …).

Le but de cet article est, tout d’abord, de vous donner un ordre d’idée sur les techniques utilisées par les systèmes de détection/protection d’intrusions pour assurer la protection face aux intrusions. Ensuite, vous montrer comment réussir la mise en place d’un IDS, notamment « Snort » et étendre sa fonctionnalité en IPS grâce à Snortsam. Enfin vous présenter les limites de cette solution.

(up)

2. Présentation générale des IDS et IPS

Nous appellons un IDS (Intrusion Detection System) un mécanisme permettant d’écouter le trafic réseau et de contrôler les activités réseau afin de repérer toutes activités anormales ou suspectes et ainsi remonter des alertes sur les tentatives d’intrusion à un système informatique. Quant à l’IPS (Intrusion Prevention System), il gère les mêmes tâches qu’un IDS, sauf qu’il mène des actions pour la protection du système informatique contre les risques intrusifs.

Un IDS est constitué essentiellement d’un sniffer couplé avec un moteur qui analyse du trafic selon des règles. Ces règles donnent une description des caractéristiques des trafics réseau à signaler. Ainsi un IDS remplit des fonctionnalités de contrôle réseau et réagit selon la nature du trafic.

Notons qu’un IDS ne remplace, en aucun cas, un pare-feu ou tout autre mécanisme de sécurisation des systèmes d’information. Cependant il renforce la sécurité en ajoutant une couche de sécurité et permettant ainsi la mise en place d’une défense en profondeur sur l’architecture réseau.

1. Les types des IDS/IPS

La diversité des attaques utilisées par les pirates et des failles exploitées par ces attaques sur les différents niveaux des systèmes d’informations justifie l’existence de plusieurs types des IDS/IPS. En effet, pour assurer le bon fonctionnement de ces mécanismes, il faut savoir évaluer les risques encourus par votre système d’information et classifier ces risques afin de déterminer le type de système de détection/Prévention d’intrusion à mettre en place.

Ainsi plusieurs types d’IDS/IPS existent pour répondre à des problématiques précises selon le contexte d’utilisation de ces derniers et les fonctions qu’ils doivent remplir. Ci-dessous nous citons les différents types des IDS et nous détaillons leurs caractéristiques principales.

  • Les systèmes de détection d’intrusions réseau (NIDS) :

Ce type d’IDS écoute tout le trafic réseau, analyse de manière passive les flux et détecte les intrusions en temps réel afin de générer des alertes. Ce type d’IDS est le plus utilisé des IDS, ainsi nous allons nous concentrer essentiellement sur ce type dans notre document, notamment l’implémentation du NIDS Snort.

  • Les systèmes de détection d’intrusions de type hôte (HIDS) :

Un HIDS est plus lié à une machine qu’à son réseau. Il permet d’analyser, non seulement, le trafic réseau, mais aussi l’activité se passant sur la machine. Le but de ce type d’IDS est d’assurer l’intégrité des données d’un système et analyser le flux relatif à une machine ainsi que ces journaux. Il existe plusieurs solutions qui proposent cette fonctionnalité, par exemple les HIDS Samhain ou Tripwire. Toutefois, ce type d’IDS présente une limitation qui se traduit par la nécessité d’avoir un système sain pour vérifier l’intégrité des données et donc un HIDS devient inefficace dans le cas ou il est implémenté sur un système déjà infecté.

  • Les systèmes de détection d’intrusions hybrides :

Ce type d’IDS est utilisé dans un environnement décentralisé. Il centralise les informations en provenance de plusieurs emplacements (senseurs) sur le réseau. Le but de ce type d’IDS est d’avoir une vision globale sur les composants constituants un système d’information en permettant une supervision centralisée en matières d’alertes d’intrusions remontées par les NIDS et les HIDS présents sur l’architecture du réseau supervisé.

  • Les systèmes de prévention d’intrusions (IPS) :

Les systèmes de prévention d’intrusions sont des systèmes de détection d’intrusions particuliers qui permettent, en plus de repérer les tentatives d’intrusion à un système, d’agir pour contrer ces tentatives. En effet, les IPS constituent des IDS actifs qui tentent de bloquer les intrusions. Cependant, les IPS ne sont pas une solution parfaite comme nous pourrions le penser, ces derniers présentent certaines limitations, notamment le blocage de toute activité qui leurs semblent suspecte. Or il est impossible d’identifier de manière fiable toutes les attaques informatiques.

De plus les pirates peuvent utiliser cette fonctionnalité de blocage assurée par les IPS pour mettre hors service un système. Ainsi les IPS se transforment en vecteurs d’attaques qui peuvent nuire au bon fonctionnement d’un système d’information. Par ailleurs, un IPS est peu discret puisqu’il montre sa présence à chaque blocage d’attaques. Ainsi, un pirate peut détecter sa présence sur le réseau et tente de trouver une faille ou des techniques pour contourner les restrictions imposer par l’IPS en question.

  • Les systèmes de prévention d’intrusions Kernel (KIDS /KIPS) :

Ce type d’IDS fait partie de la famille des HIDS. Cependant, sa fonctionnalité principale est de détecter les intrusions au niveau noyau. L’utilisation d’un KIPS s’avère parfois nécessaire selon le niveau de sécurité à apporter pour une machine et permet de reconnaître, non seulement les caractéristiques des failles présentes sur un système, mais aussi d’interdire l’OS d’exécuter des appels systèmes qui peuvent s’avérer dangereux ou qui visent la compromission du système.

Toutefois un ralentissement dans le fonctionnement peut être observé sur un système protégé par un KIPS. En effet, ce dernier analyse les appels systèmes et bloque tout accès suspect au système. Ainsi les KIPS sont des solutions rarement utilisés sur des serveurs souvent sollicités. Un exemple de KIPS est SecureIIS qui constitue une surcouche des serveurs web IIS de Microsoft.

(up)

2. Les méthodes de détection

Pour bien manipuler un système de détection d’intrusion. Il est important de comprendre son fonctionnement interne et les méthodes que ce dernier utilise pour détecter les tentatives d’intrusions dans le cas d’un IDS et pour les bloquer dans le cas d’un IPS.

C’est dans cette perspective que nous allons vous présenter, sans rentrer dans les détails, les deux approches principales utilisées pour la détection des intrusions aux systèmes d’information. En effet, plusieurs techniques sont utilisées pour assurer cette fonctionnalité selon l’approche utilisée pour assurer la détection d’intrusions.

  • Approche par scénario:

Cette technique nécessite une connaissance préalable des techniques d’attaques utilisées par les pirates pour pouvoir en déduire des scénarios typiques. Elle est dite sans état « stateless » puisqu’elle ne tient pas compte des activités passées sur le système et s’appuie, comme pour les antivirus, sur une base de signatures d’attaques pour pouvoir repérer des tentatives d’intrusions et remonter des alertes, notamment en se basant sur un ensemble de caractères permettant d’identifier une activité intrusive ou en analysant la conformité protocolaire des paquets.

Ainsi cette technique présente un inconvénient principal qui se traduit par le niveau de précision des signatures d’attaques. De plus le niveau de détection des attaques dépend impérativement de la manière dont elles sont gérées, les mises à jour de la base des signatures et du nombre des règles présentes pour gérer les alertes.

En général, cette approche se base principalement sur des techniques de recherche de motifs statiques ou dynamiques, ainsi que sur une analyse protocolaire pour vérifier la conformité (par rapport aux RFC) des flux qui circulent sur le réseau.

  • Approche comportementale:

Cette approche s’appuie principalement sur l’analyse du comportement passé des utilisateurs, des services ou des applications. Elle permet d’établir une certaine corrélation entre les différents événements sur un système et ainsi détecter des anomalies qui mènent à la détection de tentatives intrusives sur ce dernier. En effet, cette approche définie un comportement normal du système et considère toute déviation par rapport à ce comportement comme étant suspecte.

De plus il est nécessaire de modéliser des comportements normaux pour le système à protéger en définissant un profil système qualifié comme profil normal. Par ailleurs, cette approche permet de détecter des attaques non connues, contrairement à l’approche par scénario présenté ci-dessus, puisqu’elle utilise des techniques heuristiques, probabilistes ou statistiques pour la détection des tentatives intrusives. Cependant les IDS, qui adoptent cette approche, sont dotés de fonctionnalités d’adaptation et d’apprentissage afin de définir un comportement normal du système. Du coup la mise en place de cette approche nécessite plus de temps pour arriver à couvrir la totalité des systèmes à protéger.

En général, les IDS mélangent les différentes techniques de détection par scénario ou par anomalie en proposant des combinaisons entre la recherche des motifs, l’analyse protocolaire et la détection d’anomalies.

(up)

3. Déploiement d’un NIDS

Le déploiement d’un IDS n’est pas suffisant pour assurer la sécurité. Ainsi il faut toujours penser aux actions habituelles, notamment l’isolement des systèmes utilisant internet (DMZ), la robustesse de la politique des mots de passe et la gestion des mises à jour applicatives.

Un autre point important à prendre en compte est la veille sur la bonne configuration de l’IDS. Par exemple si le réseau est sous Windows, la configuration destinée aux systèmes Unix s’avèrent inutiles pour la détection des tentatives d’intrusion d’un parc informatique Windows. Du coup il est nécessaire de faire une configuration en fonction de l’OS, des applications et du matériel utilisé.

De plus l’emplacement des senseurs lors du déploiement d’un IDS est très important et permet de répondre à certaines problématiques selon la position du senseur. Le schéma ci-dessous vous montre les positions possibles pour placer un IDS.

 

    • Position 1:

 

Tout le trafic entre internet et le réseau interne ou la DMZ est analysé. Par contre le trafic entre le réseau interne et la DMZ est invisible pour l’IDS. De plus mettre un senseur à cette position génère des fichiers de log complets, mais trop complexe à analyser.

 

    • Position 2:

 

Seul le trafic entre la DMZ et internet ou le réseau interne est analysé. De plus, placer un senseur à cet emplacement nous permet de détecter les attaques non filtré par le pare-feu et donc minimise le trafic réseau à analyser. Cependant le trafic entre le réseau interne et internet n’est pas visible pour l’IDS.

 

    • Position 3:

 

Placer le senseur à cette position nous assure une analyse du trafic sur le réseau interne et la détection des attaques au niveau du réseau interne. Dans notre cas nous allons vous présenter l’installation de Snort sur un réseau local. Ce choix nous est apparu judicieux car la majorité des attaques proviennent de l’intérieur (Troyen, Virus, …etc.).

En général, il est souvent préférable de placer le senseur après le firewall du côté interne. Ainsi seuls les flux acceptés par le firewall sont analysés et donc nous obtenons une forte réduction en matière de charge des sondes de l’IDS.

De plus le choix matériel a également une grande importance puisque le trafic réseau doit être reçu par les sondes IDS pour l’analyser quelque soit le destinataire. Du coup le choix d’un switch ou d’un hub doit être fait pour assurer cette fonctionnalité. Cependant, sans rentrer dans les détails, d’autres problématiques peuvent surgir selon la nature du réseau à surveiller, notamment lorsque les flux sont cryptés ainsi que la sécurisation des sondes et des alertes qu’elles génèrent qui constitue elle-même une problématique, à part, à gérer.

(up)

3. Mise en oeuvre d’un NIDS

Maintenant que nous avons vu le but, le fonctionnement mais aussi certaines faiblesses des IDS, Nous allons mettre en place une solution NIDS basé sur le logiciel Snort et la console BASE (Basic Analysis and Security Engine) pour analyser et superviser les alertes remontées par notre NIDS. Le choix de Snort, en particulier, est justifié par le fait que nous trouvons que cette solution peut être adaptée pour une entreprise quelque soit sa taille (TPE, PME …), mais aussi la disponibilité de nombreuses règles dans la communauté de Snort et des projets comme Oinkmaster qui gèrent la mise à jour des signatures et fournissent un nombre important de règles optimisées et efficaces pour la détection des intrusions.

De plus Snort dispose d’un ensemble de plugins qui aident à étendre ses fonctionnalités, notamment Snortsam qui ajoute des fonctionnalités permettant à Snort de jouer le rôle d’un IPS. Nous allons aborder cette facette plus loin dans cet article mais nous préférons attirer votre attention sur les différentes possibilités qu’offre ce logiciel afin de pouvoir adapter votre configuration aux besoins de votre système d’information.

Les étapes suivantes montrent étape par étape la démarche à suivre pour réussir l’installation de notre NIDS.

1. Installation de Mysql

L’installation de Snort nécessite la mise en place d’un serveur Mysql afin de permettre au NIDS de stocker les alertes qu’il génère mais aussi à la console BASE de se connecter et récupérer ces alertes.

Cette installation a été faite sur une distribution Ubuntu 9.10. Vous pouvez procéder à une installation manuelle ou par package pour installer les différents logiciels nécessaires pour la mise en place de Snort.

La première étape consiste à installer le serveur et le client Mysql. Et d’y apporter la configuration nécessaire pour assurer le fonctionnement de Snort.

$ sudo apt-get install mysql-server mysql-client

Ensuite il faut créer deux bases de données « snort » et « archive ». Ces bases de données vont vous servir pour stocker/archiver les alertes remontées par Snort.

$ mysql –u root –p
mysql> CREATE DATABASE snort;
mysql> grant INSERT,SELECT,UPDATE,CREATE,DELETE on snort.* to snort;
mysql> grant INSERT,SELECT,UPDATE,CREATE,DELETE on snort.* to snort@localhost;
mysql> set password for snort=PASSWORD(‘password’);
mysql> set password for snort@localhost=PASSWORD(‘password’);
mysql> flush privileges;
mysql> exit

Vous devez faire la même chose pour la base de données archive.

$ mysql –u root –p
mysql> CREATE DATABASE archive;
mysql> grant INSERT,SELECT,UPDATE,CREATE,DELETE on archive.* to snort;
mysql> grant INSERT,SELECT,UPDATE,CREATE,DELETE on archive.* to snort@localhost;
mysql> set password for archive=PASSWORD(‘password’);
mysql> set password for archive@localhost=PASSWORD(‘password’);
mysql> flush privileges;
mysql> exit

Une fois que vous avez créé les bases de données, vous allez procéder à la création du schéma des données pour ces bases. Pour se faire deux méthodes existent :

  • En important le schéma des données à partir du répertoire d’installation de Snort.
cat create_mysql | mysql –u snort –D snort –p
  • Si Snort (snort-mysql) a été téléchargé à partir du dépôt Ubuntu.
$ zcat /usr/share/doc/snort-mysql/create_mysql.gz | mysql –u snort –D snort –p

Après vous pouvez vérifier si les bases sont bien créées et que le schéma a bien été importé.

$ mysql –u root –p
mysql> show databases ;
mysql> use snort ;
mysql> show tables ;

Si tout s’est bien passé vous devez avoir comme résultat :

+——————+
| Tables_in_snort |
+——————+
| data
| detail
| encoding
| event
| icmphdr
| iphdr
| opt
| reference
| reference_system
| schema
| sensor
| sig_class
| sig_reference
| signature
| tcphdr
| udphdr
+——————+
16 rows in set (0.00 sec)

Ensuite, il faut vérifier si l’utilisateur snort a un mot de passe et toutes les permissions nécessaires pour accéder à la base de données.

Si tout s’est bien passé vous devez avoir comme résultat :

mysql> show grants for ‘snort’;
+—————————————+
| Grants for snort@% |
+—————————————+
GRANT USAGE ON *.* TO ‘snort’@’%’ IDENTIFIED BY PASSWORD ‘hash du mot de passe’
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE ON `snort`.* TO ‘snort’@’%’
+—————————————+
2 rows in set (0.00 sec)

Enfin, il ne faut pas oublier de redémarrer le serveur Mysql pour qu’il prenne en compte les modifications apportées aux bases de données.

$ /etc/init.d/mysql restart

Si vous êtes arrivés à ce stade là, vous êtes sur de la bonne configuration de votre serveur Mysql. Du coup vous pouvez passer à l’étape suivante qui consiste à installer apache pour la console BASE.

(up)

2. Mise en place d’Apache-PHP

La console BASE est une interface écrite en PHP, donc qui nécessite un serveur web supportant PHP. Pour cette installation nous avons choisi d’installer un serveur apache2 ainsi que tous les modules et les extensions nécessaires pour assurer le fonctionnement de BASE.

$ sudo apt-get install apache2 php5-mysql libphp-adodb php-mail- mime php-mail
  • Apache2 : serveur web.
  • Php5 : module PHP.
  • Php5-mysql : interface PHP/MYSQL
  • Libphp-adodb : librairie d’abstraction de base de données pour PHP.
  • Php-mail : extension PHP

Tout d’abord, configurez le serveur pour écouter sur l’adresse de la boucle local (127.0.0.1). Ainsi le serveur web n’est visible que sur la machine locale. Pensez également à changer la configuration pour supporter HTTPS dans le cas où vous activez SSL, BASE continuera à fonctionner.

$ sudo nano /etc/apache2/ports.conf
listen 127.0.0.1 :80
Listen 127.0.0.1 :443

Ensuite assurez-vous que le module PHP est activé.

$ a2enmod php5
Module php5 already enabled

Si vous avez le résultat ci-dessus, vous êtes sur que tout est bien installé, pensez donc à redémarrer Apache pour la prise en compte de la nouvelle configuration.

$ /etc/init.d/apache restart

Enfin, allez sur votre navigateur préféré et vérifiez que vous pouvez vous connecter à l’adresse 127.0.0.1.

(up)

3. Mise en place de Base

BASE est une interface graphique écrite en PHP utilisée pour afficher les alertes générées par l’IDS Snort et stockées dans la base de données. Elle signifie Basic Analysis and Security Engine.Vous pouvez la télécharger sur le site : http://sourceforge.net/projects/secureideas/files

Une fois vous avez téléchargé BASE, décompressez les fichiers dans le dossier du serveur web.

$ tar xzvf base-x.y.z.tar .gz
$ mv /home/user/Desktop/base-x.y.z /var/www/base

Ensuite vous pouvez passer à la configuration de BASE. Vous aurez besoin de ADOdb (Active Data Objects Data Base) pour BASE, vous pouvez la télécharger sur : http://adodb.sourceforge.net/#download. Comme précédemment vous devez décompresser les fichiers dans le dossier base.

$ unzip adodb5.zip
$ mv /home/user/Desktop/adodb5 /var/www/base

Une fois, vous avez réussi ces étapes, vous pouvez lancer l’assistant et procéder à l’installation de BASE. Mais avant de lancer l’assistant n’oubliez pas de faire le changement ci-dessous pour permettre à l’utilisateur web (www-data) d’écrire dans le dossier BASE.

$ chown –R www-data /var/www/base

Après vous pouvez lancer l’assistant en ouvrant le navigateur web et sélectionner le dossier BASE sur l’adresse : http://localhost/base/setup.php.

Vous obtiendrez la première page de l’assistant qui vérifie que les paramètres nécessaires à la configuration sont mis en place.

Ensuite l’assistant vous demande de choisir la langue et le chemin pour accéder adodb5.

Après l’assistant vous invite à introduire les paramètres du serveur Mysql dans la configuration.

Ensuite vous paramétrer les champs d’authentification pour accéder à la console BASE.

Une fois que les paramètres d’authentification sont mis en place, l’assistant vous demande de créer les tables de la base de données de BASE.

Enfin vous serez redirigés vers la page d’authentification qui vous propose de vous authentifier afin d’accéder à la console pour superviser les alertes remontées par Snort.

Avant d’en finir avec la configuration de BASE, nous souhaitons attirer votre attention sur certains paramètres qui rendent l’utilisation de BASE une expérience agréable et justifient le choix d’utiliser cette console plutôt que d’autres.

En effet, BASE offre la possibilité de générer des graphiques permettant de voir l’évolution de nombres des alertes remonter par Snort. Pour se faire il faut installer quelques packages.

$ sudo apt-get install php-pear
$ sudo apt-get install php-gd
$ sudo pear install –force Image_Color
$ sudo pear install –force Images_Canvas
$ sudo pear install –force Images_Graph

Les commandes ci-dessus installent les librairies et les dépendances nécessaires pour BASE pour la génération des graphes.

BASE propose aussi de visualiser les alertes colorées afin de classifier les alertes selon leurs degrés de criticité. Vous pouvez activer cette fonctionnalité en paramétrant la variable $colored_alerts dans le fichier base_conf.php

$ nano /var/www/base/base_conf.php

$colored_alerts=1 ;

(up)

4. Mise en place de Snort

Vous pouvez installer Snort à l’aide d’un package ou manuellement. Dans notre cas nous allons installer Snort à l’aide d’un package snort-mysql. Cela vous garantie, d’une manière simple, d’installer Snort pour interagir avec le serveur Mysql afin de stocker les alertes.

$ sudo apt-get install snort-mysql

Ensuite assurez-vous que l’installation s’est bien déroulée et vérifier que vous avez la dernière version du logiciel avant de passer à la configuration de ce dernier.

La configuration de snort devient une tâche facile une fois que vous avez réussis toutes les étapes précédentes. En effet cette étape consiste à éditer le ficher /etc/snort/snort.conf pour y mettre les bons paramètres afin de permettre à Snort de commencer son analyse sur votre réseau.

$ sudo cp /etc/snort/snort.conf /etc/snort/snort.conf.old
$ sudo nano /etc/snort/snort.conf

#configuration du réseau à surveiller
var HOME_NET [192 .168.0.0/24] votre réseau/netmask
var HTTP_SEVERS X.X.X.X #adresses ip des serveurs http]
var DNS_SEVERS X.X.X.X #adresses ip des serveurs DNS]
var SMTP_SEVERS X.X.X.X #adresses ip des serveurs SMTP]
var SQL_SEVERS X.X.X.X #[adresses ip des serveurs SQL]
var SNMP_SERVERS X.X.X.X # [adresses ip des serveurs SNMP]

#Chemins vers les régles
var RULE_PATH /etc/snort/rules
var PREPROC_RULE_PATH /etc/snort/preproc_rules

#paramètre pour MYSQL
output database: log, mysql, user=snort password=password dbname=snort host=127.0.0.1
ruletype redalert
{
type alert
output alert_syslog: LOG_AUTH LOG ALERT
output database: log, mysql, user=snortuser password=snortpassword dbname=snort host=localhost
}

Une fois vous avez paramétré Snort. Vous pouvez le lancer et visualiser les alertes qu’il remonte en utilisant la console BASE.

$ sudo snort –u snort -c /etc/snort/snort.conf

Si tout s’est bien passé vous pouvez vous connecter à la console BASE afin de vérifier si elle prend en compte les alertes remontées par Snort. Ainsi vous pouvez voir un résultat similaire à celui présenté ci-dessous.

Comme pour tout système informatique, ou presque, il existe des failles ou des techniques exploitables pour outrepasser ces systèmes sans se faire détecter. Ainsi il faut penser à la gestion des mises à jour au niveau logiciel mais aussi au niveau des règles utilisées pour la détection des attaques.

En effet, vous pouvez utiliser plusieurs méthodes pour mettre à jour votre IDS. Ceci en faisant la veille sur l’évolution des développements de votre IDS et installer les mises à jour nécessaires pour le faire passer à la dernière version disponible. Veiller à mettre à jour les règles en les téléchargeant sur le site de votre IDS ou en installant des outils automatisant cette tâche comme Oinkmaster pour Snort. Nous n’allons pas vous présenter comment faire usage de Oinkmaster puisque vous pouvez trouver une documentation complète sur le site du projet : http://oinkmaster.sourceforge.net/docs.shtml.

Notons qu’en plus des règles prêtes proposées par Snort, vous pouvez écrire vos propres règles afin d’adapter cette solution à votre architecture réseau. Ainsi nous allons vous présenter comment créer des règles afin de bénéficier de cette fonctionnalité.

(up)

5. Création de nouvelles règles

Il peut être intéressant d’adapter au mieux Snort au réseau qu’il doit surveiller. Du coup Snort vous offre la possibilité de créer des règles capables de répondre à cette fonctionnalité. Ainsi, par convention, nous proposons de placer les règles dans le fichier local rules. Notons que ces règles doivent être complètement écrites sur une seule ligne puisque l’analyseur de règles de Snort ne sait pas comment traiter des règles sur plusieurs lignes.

Une règle Snort est composée de deux parties présentées sous le format suivant : Header (options).

action protocole adress1 port1 direction adresse2 port2 Options (msg,content ….etc)

La partie header décrit l’action, la direction et les adresses sources et destinations des échanges réseau.

Le champ « action » peut prendre plusieurs valeurs selon l’action à mener par Snort en détectant des paquets réseau répondant au critère définie dans la règle. Ces valeurs sont les suivantes :

  • alert : génère une alerte et log le paquet
  • log : log le paquet
  • pass : ignore le paquet
  • activate : active une règle dynamique
  • dynamic : définie une règle dynamique
  • ..etc

Le champ « protocole » décrit le protocole utilisé pour la communication. Snort supporte les protocoles TCP, UDP, ICMP et IP.

Les champs « direction » renseignent Snort sur la direction des échanges réseau ( ->, <->, <- ).

Les champs « adress/port » décrivent les adresses IP et les ports des machines qui échangent des données sur le réseau.

Quant à la partie options, elle renseigne Snort sur les caractéristiques des paquets à signaler et garantissent une meilleure granularité pour définir et appliquer les règles mais aussi déclencher les actions qu’elles décrivent.

La partie options est constituée de plusieurs champs qui assurent l’analyse du contenu des paquets réseau avec plus de finesse. Notons que la manipulation de ces champs nécessite une grande maîtrise des protocoles réseau pour pouvoir décrire les signatures des attaques à détecter.

Pour chaque option le format est nom option : valeur1 [, valeur2,…] ci-dessous quelques options utilisées dans la création des règles.

  • msg : spécifie le message qui sera affiché dans le log et dans l’alerte
  • reference : fait référence aux sites expliquant l’attaque détectée (bugtraq , CVE, …etc.)
  • classtype : définit la classe de l’attaque (troyen, shellcode …etc)
  • ttl : spécifie la valeur du TTL du paquet
  • flags : spécifie la présence d’un flag TCP dans le paquet (SYN, Fin, …etc)
  • ..etc

Notons que ces options sont intéressantes pour décrire avec précision les attaques. Donc plus vous maîtriser le formalisme de description des attaques par le biais de ces règles plus vous aurez des alertes précises et vous évitez les faux positifs.

  • Exemple de règles :
alert tcp $EXTERNAL_NET any -> HTTP_SERVERS 80 (msg : ‘’web attack code execution ‘’ ; uricontent :’’/bin/sh’’ ; nocase ; classtype : ‘’ web-application-attacks ‘’ ; sid :1518 ; rev :1 ; )
alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg: »WEB-MISC /etc/passwd »;flags: A+; content: »/etc/passwd »; nocase; classtype:attempted-recon; sid:1122; rev:1;)

Ces deux règles permettent de détecter des attaques du réseau externe. La première détecte une attaque qui consiste à exécuter une commande sur le serveur web. Quant à la deuxième, elle détecte des tentatives de récupération des fichiers sensibles afin de les exploiter pour gagner des privilèges sur les machines du réseau interne.

(up)

4. Snortsam

Comme nous l’avons déjà évoqué le déploiement d’un IDS constitue une couche de sécurité de plus pour protéger votre réseau. Cependant cette solution permet juste de détecter des éventuelles tentatives d’intrusions sur votre système d’information. Ainsi Snortsam intervient pour étendre les fonctionnalités de Snort en IPS et interagir avec votre pare-feu et bloquer les tentatives d’intrusions.

Snortsam est un plugin Snort qui fonctionne avec deux parties: le plugin pour Snort et un agent intelligent qui tourne comme un service sur le(s) firewall(s). Il permet de bloquer des adresses IP sur pare-feu en analysant les alertes relevé par Snort et indiquant aux agents Snortsam les adresses que ces derniers fournissent au pare-feu afin de les bloquer. Ce plugin supporte plusieurs types de pare-feu, dans notre cas nous allons utiliser iptables

L’avantage de SnortSam, c’est que l’agent avec lequel il fonctionne fourni plusieurs fonctionnalités que d’autres mécanismes de blocage automatisés ne proposent pas, comme:

  • Une liste blanche d’adresse IP qui ne seront jamais bloquées.
  • Un système de plage horaire pour bloquer les utilisateurs.
  • Des règles de blocage spécifiques, comme les règles de blocage dépendant de l’heure.
  • Une liste de filtrage de SID autorisés ou non, basée sur l’entité.
  • Un moteur de détection d’attaque qui essaye d’atténuer le risque d’un Deni de service interne à l’architecture IDS.
  • Un système de blocage préventif des répétitions (mêmes adresses IP) avec une fenêtre modifiable pour améliorer les performances.
  • Une communication chiffrée en TwoFish entre Snort et l’agent SnortSam.
  • Un vrai support d’OPSEC en utilisant le SDK de Checkpoint (plugin OPSEC)
  • Le « Multi-Thread » pour traiter plus vite et simultanément les blocages sur plusieurs appareils
  • L’enregistrement des fichiers et la notification d’événements par email.
  • Et la possibilité d’utiliser l’architecture client/serveur (snortsam/snort) pour les grands réseaux de manière à optimiser les remontées d’information du réseau.

De plus, SnortSam est un programme complètement gratuit et open-source. Il peut être compilé sur plusieurs plateformes et l’interaction devrait fonctionner à travers ces différentes plateformes (selon l’auteur).

(up)

1. Installation de Snortsam

Vous pouvez trouver tous les fichiers nécessaires à la configuration de SnortSam sur le site http://www.snortsam.net/files . Ainsi la première étape consiste à récupérer la dernière version stable du plugin. Ainsi vous pouvez compiler et installer les agents comme indiquer ci-dessous.

$ tar xzvf snortsam-src-2.69.tar.gz
$ cd snortsam-src-2.69
$ chmod +x makesnortsam.sh
$ ./makesnortsam.sh

Done.
$ cp snortsam /bin

Ensuite récupérer le patch nécessaire pour la version de l’IDS Snort dont vous disposer, appliquer le patch et recompiler Snort.

$ wget http://www.snortsam.net/files/snort-plugin/snortsam-2.8.6.diff.gz
$ gunzip snortsam-2.8.6.diff.gz
$ patch –p1 /usr/local/src/snort < snortsam-2.8.6.diff
$ cd /usr/local/src/snort
$ ./autojunk
$ ./configure –with-mysql
$ make
$ make install

Si tout se passe bien vous auvez votre Snort compiler avec le plugin snortsam et un agent snortsam prêt à être déployé.

2. Configuration de Snortsam

La configuration de Snortsam nécessite la configuration de Snort pour prendre en compte la nouvelle fonctionnalité assurée par le plugin et la configuration des agents pour pouvoir communiquer avec le plugin et assurer le blocage des adresses IP.

Ainsi vous pouvez configurer Snort en éditant le fichier snort.conf comme indiqué si-dessous :

$ vi /etc/snort/snort.conf

output alert_fwsam: localhost/myhostpass remotehost:remoteport/remotehostpass

La ligne si dessous indique à snort les agents Snortsam avec qui il doit communiquer afin de leur fournir les adresses IP à bloquer.

  • Localhost : premier agent local communiquant avec le port par défaut et le mot de passe « myhostpass »
  • Remotehost : le deuxième agent distant communiquant avec le port « remoteport » et le mot de pass « remotehostpass ».

Vous pouvez ajouter plus d’agents selon le nombre des agents déployé sur votre réseau.

Ensuite il faut configurer les agents afin de garantir la communication entre l’IDS et ces derniers. Pour se faire éditez le fichier snortsam.conf sur les machines des agents comme indiqué ci-dessous :

$ vi /etc/snortsam.conf
….
#accepter les connexion en provenance de l’IDS
accept 192.168.X.X, mypass #adresse IP IDS / mot de passe indiquer dans snort.conf
# adresse IP à ne pas bloquer
dontblock

#fichier de log
Logfile /var/log/snortsam.log
# niveau de log vous pouvez choisir entre 3 niveaux
loglevel 3
# snortsam en mode démon
deamon
# notification par email
email
# choix du firewall
#iptables
Iptables eth0 /var/log/iptables-snortsam.log

Une fois vous avez édité les fichiers de configuration, la dernière étape consiste à éditer les règles snort qui entraîneront le blocage côté pare-feu. Cette configuration nécessite l’ajout du champ « fwsam » dans les lignes des règles en question.

Exemple :

alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg: ″WEB-ATTACKS /bin/ps command attempt ″; flow:to_server,established; uricontent: ″ps%20″; nocase; sid:1329; classtype:web-application-attack; rev:4; fwsam: src[in], 5 minutes; )

En effet en peut résumer la syntaxe du champ en : fwsam : qui[comment], durée

  • Qui : ce paramètre peut prendre une des valeurs src, source, dst, dest ou destination selon la machine à bloquer.
  • Comment : peut être initialisé à In, out, src, dest, either, both, this ou conn pour définir le type des paquets à rejeter.
  • Durée : définit la durée du blocage des adresses IP en question.

Une fois toutes les configurations citées ci-dessus ont été mises en place, vous pouvez lancer les agents snortsam ainsi que l’IDS Snort et vérifier que tout est bien déployé et que la communication est assurée entre les différentes parties de notre IPS. Pour se faire suivez les étapes ci-dessous.

$ snortsam /etc/snortsam.conf
$ snort –u snort –c /etc/snort/snort.conf&

Ensuite vérifier le fichier de log de snortsam pour vérifier que votre configuration est bien prise en charge par les différents éléments de l’IPS.

$ cat /var/log/snortsam.conf
2010/07/13, 11:54:05, -, 1, snortsam, Starting to listen for Snort alerts.
2010/07/13, 11:55:18, 192.168.X.X, 3, snortsam, Accepted connection from 192.168.X.X.
2010/07/13, 11:55:18, 192.168.X.X, 3, snortsam, Adding sensor 192.168.X.X to list.

Si tout s’est bien passé vous devez avoir un message comme ci-dessus, sinon allez revérifier votre configuration.

(up)

3. Cas d’utilisation

Cette partie consiste à vous donner un cas d’utilisation de Snortsam. Vous pouvez vous en inspirer pour adapter la configuration au besoin de votre réseau. Dans notre cas nous allons essayer de bloquer une attaque remontée par Snort.

Pour ceci nous observons les alertes remontées sur l’interface web de BASE. Pour détecter les attaques sur notre réseau et configurer Snort afin de communiquer avec l’agent snortsam et bloquer l’adresse IP source de cette attaque.

Dans ce cas de figure nous remarquons que l’interface base nous a remontée une alerte sur une attaque détecter par Snort.

Ainsi nous allons voir si la règle de détection de ce type d’attaque est configurée pour bloquer l’adresse source de cette attaque. Sinon nous allons ajouter le champ fwsam pour permettre à snort de communiquer avec l’agent snortsam au niveau du pare-feu et bloquer l’accès à l’adresse en question.

$ cat /etc/snort/rules/icmp.rules | grep ICMP\ L3retriever alert icmp $EXTERNAL_NET any -> $HOME_NET any (msg: »ICMP L3retriever Ping »; icode:0; itype:8; content: »ABCDEFGHIJKLMNOPQRSTUVWABCDEFGHI »; depth:32; reference:arachnids,311; classtype:attempted-recon; sid:466; rev:5;fwsam:src, 30; )

Du coup nous avons vérifié que la règle et bien configurer pour bloquer les accès aux adresses IP sources de ce type d’attaques pendant une durée de 30 secondes. Cependant il faut vérifier que l’agent s’est chargé de bloquer l’accès à cette adresse IP en question. Pour se faire nous allons consulter le fichier de log de l’agent.

$ tail /var/log/snortsam.log
2010/07/13, 17:41:02, -, 3, iptables, Info: Command /sbin/iptables -I FORWARD -i eth1 -s 192.168.1.241 -j DROP Executed Successfully
2010/07/13, 17:41:02, -, 3, iptables, Info: Command2 /sbin/iptables -I INPUT -i eth1 -s 192.168.1.241 -j DROP Executed Successfully
2010/07/13, 17:41:02, -, 3, iptables, Info: Command /sbin/iptables -I FORWARD -i eth1 -d 192.168.1.241 -j DROP Executed Successfully
2010/07/13, 17:41:02, -, 3, iptables, Info: Command2 /sbin/iptables -I INPUT -i eth1 -d 192.168.1.241 -j DROP Executed Successfully
2010/07/13, 17:41:32, -, 2, snortsam, Removing 30 sec complete block for host 192.168.1.241.
2010/07/13, 17:41:32, -, 1, iptables, Info: UnBlocking ip 192.168.1.241
2010/07/13, 17:41:32, -, 3, iptables, Info: Command /sbin/iptables -D FORWARD -i eth1 -s 192.168.1.241 -j DROP Executed Successfully
2010/07/13, 17:41:32, -, 3, iptables, Info: Command2 /sbin/iptables -D INPUT -i eth1 -s 192.168.1.241 -j DROP Executed Successfully
2010/07/13, 17:41:32, -, 3, iptables, Info: Command /sbin/iptables -D FORWARD -i eth1 -d 192.168.1.241 -j DROP Executed Successfully
2010/07/13, 17:41:32, -, 3, iptables, Info: Command2 /sbin/iptables -D INPUT -i eth1 -d 192.168.1.241 -j DROP Executed Successfully

Une fois de plus nous avons vérifié que notre IPS marche et que l’agent interagis avec notre pare-feu pour bloquer les accès.

De plus si vous pouvez être notifié par email des actions menées par votre IPS en configurant l’agent pour l’envoi de mail de notification.

(up)

5. Techniques anti-IDS

Les IDS constituent une mesure sécuritaire qui rend la vie difficile aux pirates. Ainsi ces derniers ont compris la nécessité de trouver des moyens pour outrepasser les mécanismes de sécurité assurés par les IDS afin d’attaquer sans se faire remarquer. En effet, il existe des techniques anti-IDS qui rendent possible le contournement des IDS. Ces techniques se présentent sous trois catégories :

  • Attaque par déni de service : permet de rendre l’IDS inopérant en le saturant.
  • Attaque par insertion : Insertion de trafic afin de déjouer l’IDS en lui faisant croire à un trafic légitime. Le principe de ces techniques est d’injecter une attaque parmi beaucoup d’informations sans incidences. Les signes de l’attaque n’apparaissent donc pas à l’IDS mais quand les données atteignent la cible, seule l’information malintentionnée est acceptée par le système. Cela est très proche du principe des canaux cachés.
  • Attaque par évasion : cette technique est l’inverse de l’attaque par insertion. Ici le principe est de faire passer des données superflues qui sont ignorées par l’IDS mais prises en compte par les systèmes ciblés.

Bien évidement, avant de commencer à lancer des attaques anti-IDS, il faut détecter au préalable l’existence d’un IDS sur le réseau ciblé. Pour ceci les pirates utilisent certaines techniques qui révèlent l’existence d’un IDS en observant certains comportements sur le réseau ciblé, notamment l’existence d’une interface en mode promiscuité, la mesure du temps de latence et l’exploitation des réponses actives des IPS.

(up)

1. Attaque par déni de service

Le but de ce type d’attaque est de saturer les ressources utilisées par l’IDS afin de le désactiver. Ainsi l’IDS ne peut plus remplir sa fonctionnalité et le pirate peut lancer ces attaques contre le réseau ciblé sans se faire remarquer.

Pour se faire les pirate utilise des technique d’attaque par flood qui consiste à surcharger le NIDS pour qu’il ne puisse pas fonctionner correctement et qu’il ne détecte pas l’attaque principale ou par la noyade sous les faux-positifs dont le principe est de provoquer de nombreuses remontées d’alertes. En parallèle, une attaque réelle contre le réseau est lancée, et l’administrateur occupé à analyser les alertes, ne s’en rendra pas compte sur le moment. Nous pouvons utiliser l’option decoy de nmap pour générer des scans nmap multiples pour lancer ce type d’attaque.

2. Attaques par insertion

Il existe plusieurs techniques d’insertion ou d’injection qui permettent d’outrepasser les IDS. Comme nous l’avons déjà évoqué, ces techniques consistent à injecter des données supplémentaires de telle sorte que l’IDS les ignores et que la machine cible ne les décodent pas. Ci-dessous nous vous présentons certaines attaques de ce type :

 

    • Fragmentation IP:

 

Le principe est de fragmenter les paquets IP pour empêcher les NIDS de détecter les attaques sachant que les paquets seront réassemblés au niveau du destinataire. Il est possible aussi d’envoyer des paquets IP mal fragmentés qui vont utiliser la faiblesse de certaines pile IP (peut-être aussi celle de la sonde IDS qui capte tout le trafic) pour perturber le système.

En effet, cette technique exploite certaines faiblesses dans la technique de fragmentation utilisée par la pile IP mais aussi la différence en matière de gestion des fragments selon l’OS, notamment dans les mécanismes de recouvrement, d’écrasement et du temps de garde des fragments IP (timeout de fragmentation).

 

    • Segmentation TCP:

 

Cette technique repose sur le même principe que la fragmentation IP, mais cette fois ci au niveau de la couche transport TCP. En effet, les requêtes TCP sont divisées en segments identifiées par des numéros de séquence. Ainsi, tout en modifiant le numéro de séquence pour créer des recouvrements nous nous retrouvons dans la même situation qu’avec la fragmentation IP.

 

    • Insertion de faux paquets:

 

Le principe de cette technique et d’insérer des paquets avec des champs erronés, par exemple checksum ou TTL, de manière à ce que l’IDS ne les détecte pas et que le système les rejettent.

3. Attaques par évasion

Pour rappel, ces techniques ont pour but d’insérer des données qui seront ignorées par l’IDS, mais interprétées par les systèmes ciblés. En effet, le but de ces techniques est de réussir des attaques sans être gêné par les IDS.

De plus, ces techniques exploitent des faiblesses dans les mécanismes utilisés par les IDS, par exemple le mécanisme de recherche des motifs que nous avons évoqué dans la première partie de cet article, pour réussir à outrepasser l’IDS. Ainsi nous vous présentons certaines attaques d’évasion.

Technique d’évasion HTTP :

 

    • l’encodage :

 

Il permet de coder les caractères sous forme hexadécimale. L’URL sera comprise par le protocole HTTP.

 

    • les doubles slashs :

 

Par exemple, une requête de type ‘//cgi-bin//script’ ne sera pas détectée car les IDS vérifient les requêtes de la forme ‘/cgi-bin/script’.

 

    • les self-reference directories :

 

Il consiste à remplacer tous les ‘/’ par des ‘/./’. Ainsi La requête n’est pas détectée par l’IDS.

 

    • La simulation de fin de requête :

 

L’IDS analyse la première partie de l’URL et s’arrête au premier HTTP/1.0 rn. Le reste de la requête qui représente l’attaque passe sans être analysée. Par exemple: HEAD /HTTP/1.0rnHeader : /../../cgi-bin/bidule.cgi HTTP/1.0rnrn

 

    • Le formatage :

 

Il consiste à remplacer les espaces par des tabulations dans les requêtes HTTP.

 

    • Case sensitive :

 

Il consiste à remplacer les minuscules par des majuscules. La requête reste valide.

 

    • URL coupée :

 

Il consiste à couper la requête HTTP en plusieurs paquets TCP. Par exemple : l’URL « GET /cgi/bin/phf » devient « GET », »/cgi/b », »in/ph », »f HTTP/1.0″.

 

    • Le caractère NULL :

 

En analysant la chaine de caractères HEAD%00 /cgi-bin/some.cgi HTTP/1.0, l’IDS s’arrête dès qu’il atteint le caractère NULL, la suite de l’URL n’étant pas analysée.

 

    • Utiliser la syntaxe MS DOS :

 

Cette technique consiste à remplacer les caractères / par \.

Shellcode polymorphique :

Cette technique consiste à rendre difficile la détection des shellcodes pour les IDS utilisant les signatures. En effet, elle permet de camoufler les tentatives de buffer overflow en mettant une autre instruction NOP pour remplir le buffer, en utilisant des instructions par équivalence ou mieux encore en cryptant le shellcode et le rendre polymorphique en utilisant un cryptage (XOR) tout en s’assurant que le décodeur et la clé sont présents dans le shellcode pour pouvoir le décrypter lors de son exécution sur les machine des victimes.

Nous pouvons remarquer qu’il devient très difficile pour un IDS de détecter le shellcode en utilisant des signatures. Ainsi, il faut mettre en place d’autres mécanismes, par exemple des KIPS, en complément des IDS pour pouvoir mener des analyses au niveau des appels systèmes et détecter ce type d’attaques. De cette façon nous constatons une fois de plus l’importance de la notion de complémentarité des types des IDS, la nécessité de bien définir le périmètre à défendre sur notre réseau et la nature des mécanismes utilisés pour accomplir cette tâche.

(up)

6. Conclusion

Bien que répandus dans les organisations aujourd’hui, les systèmes de détection d’intrusions ne représentent qu’un maillon d’une politique de sécurité. En effet, même s’ils permettent la détection, parfois l’arrêt, des intrusions, ils restent néanmoins vulnérables eux aussi face aux attaques externes.

C’est pourquoi, pour une sécurité optimale, ces outils doivent être couplés à d’autres, comme l’indispensable pare-feu. Mais ils doivent aussi être mis à jour, aussi bien au niveau du cœur du logiciel comme la base de signatures, qui constitue la base d’une détection efficace. Il faut également coupler les systèmes de détection entre eux en prenant en compte la notion de complémentarité des solutions offertes pour assurer cette fonctionnalité : c’est-à-dire, ne pas hésiter à placer des NIDS, HIDS et KIDS dans le même réseau. Leurs rôles sont différents, mais chacun apporte ses fonctionnalités.

L’efficacité des détections passe aussi par une bonne implémentation des nouvelles règles de détection d’intrusion. L’étude que nous avons menée sur l’écriture de ces dernières nous a permis d’observer ô combien il est indispensable de maîtriser le formalisme de description des attaques et d’adapter ces règles à l’architecture du réseau à défendre. Mais ce n’est pas tout, au-delà de ce formalisme, doit résider un savoir faire important de la part du (des) concepteur(s) de ces règles.

Toutefois, et nous terminerons par ceci, même si une certaine maturité dans ce domaine commence à se sentir, le plus important reste de savoir de quoi il faut se protéger. Les failles les plus répandues proviennent généralement de l’intérieur de l’entreprise, et non de l’extérieur. Des mots de passe simples, des droits d’accès trop élevés, des services mal configurés, ou encore des failles dans les logiciels restent la bête noire en matière de sécurité.

(up)

Philippe Humeau
Philippe Humeau
Philippe a co-fondé NBS System en 1999. Après s’être concentré sur la sécurité, qu’il n’a jamais abandonnée, il se découvre une passion pour le ecommerce à partir de 2008. Tour à tour pentester, CTO, CCO puis CEO, son profil touche-à-tout l’a conduit à devenir directeur marketing et stratégie d’OT Group après notre intégration dans celui-ci.