Snort:Preambule
Préambule
Objet du document
Ce document présente Snort, un IDS (Intrusion Detection System) opensource, sa mise en place et son interfaçage avec des outils de contre-mesure et d'analyse.
Différence entre IDS et IPS
Alors que l'IDS est généralement considéré comme passif (sniffing, analyse du traffic dans le but d'une reconnaissance d'un comportement douteux sur base de signatures connues), l'IPS est plus réactif, dans la mesure où il est en coupure directe, comme le montre le schéma suivant :
Afin de palier aux lacunes induites par l'IDS, nous couplerons Snort avec Guardian qui permettra de bloquer les adresses IP détectées comme étant à l'origine des alertes.
Snort et les autres solutions
Définition de Snort
Snort est capable d'effectuer aussi en temps réel des analyses de trafic et de logger les paquets sur un réseau IP. Il peut effectuer des analyses de protocole, recherche/correspondance de contenu et peut être utilisé pour détecter une grande variété d'attaques et de sondes comme des dépassements de buffers, scans, attaques sur des CGI, sondes SMB, essai d'OS fingerprintings et bien plus. Cependant, comme tout logiciel, Snort n'est pas infaillible et demande une mise à jour régulière.
Snort peut également être utilisé avec d'autres projets open sources tels que SnortSnarf, ACID, sguil et BASE (Basic Analysis and Security Engine) afin de fournir une représentation visuelle des données concernant les éventuelles intrusions.
Fonctionnement de Snort
Snort est composé de 4 blocs :
|
Champ d'actions de Snort
Snort n'est pas considéré comme IPS mais comme IDS dans la mesure où il n'intègre pas, de manière native, d'action de contre-mesure en cas de détection d'attaque.
Snort permet notamment la détection des attaques suivantes :
- Dépassement de tampon
- Fingerprinting d'OS
- SMB probe
- Scan de port
- Attaques CGI
- …
Acteurs IDS/IPS
Solutions open source | Solutions commerciales | |
---|---|---|
IDS |
Snort, Prelude |
Hogwash, Snort-Inline |
IPS |
TomaHawk |
McAfee (IntruShield, Entercept), ISS (Proventia), Juniper (IDP) et 3COM/TippingPoint (Unity One) |
Architecture applicative
Lorsqu’un comportement suspect est intercepté par Snort en fonction des signatures, Snort inscrit les événements. Il est possible d’inscrire les logs en base de données directement. Néanmoins, dans un souci d’optimisation (libération de ressources), nous utiliserons Barnyard, une couche d’abstraction de Snort. Ainsi, Snort inscrira les événements dans des logs au format unifié (Fast Unified Logging) et ces derniers seront exploités par Barnyard pour une inscription en base de données. |
Guardian assurera le blocage des adresses IP détectées comme suspectes. Par ailleurs, BASE et/ou SGUIL permettront d’analyser ces attaques.
Pré-requis
Le document suppose que Debian est déjà installé a minima sur la machine.
Par ailleurs, les dépendances suivantes doivent être installées :
# apt-get install apache2 apache2.2-common php5 libapache2-mod-php5 \ mysql-server mysql-common mysql-client php5-mysql libnet1 \ libnet1-dev libpcre3 libpcre3-dev autoconf automake1.9 libpcap0.8 \ libpcap0.8-dev libmysqlclient15-dev php5-gd php-pear libphp-adodb \ vim gcc make php5-cli libtool libssl-dev gcc-4.1 g++
Par ailleurs, BASE exploite les packages PEAR Mail et Mail_Mime. Pour les installer, entrez les commandes suivantes :
# pear upgrade PEAR # pear install Mail # pear install Mail_Mime
Versions et limitations
Versions
Elément | Version | Description |
---|---|---|
Linux | Linux debian 2.6.18-6-686 | OS utilisé |
Apache | Apache/2.2.11 | Moteur Web |
PHP | 5.2.0-9 | Langage de script PHP |
MySQL | Ver 14.12 Distrib 5.0.32 | Base de données MySQL |
Snort | 2.8.6 | IDS |
Barnyard | 0.2.0 (Build 32) | Couche d’abstraction de Snort pour une exploitation des logs unifiés (insertion dans MySQL) |
BASE | 1.3.9 (anne) | Couche applicative Web pour l’analyse des événements inscrits dans MySQL |
Guardian | 1.7 | Blocage d’IP |
Oinkmaster | 2.0 | Automatisation de l’importation des règles de Snort |
Limitations
Les tests ont été effectués à partir d'une version d'émulation Cygwin sous Windows pour le client et d’un environnement virtualisé par VMWARE Debian pour le serveur, le client et le serveur étant physiquement sur la même machine.
Par ailleurs, une seule interface réseau (eth0) a été utilisée. En mode production, il est probable que le serveur soit en coupure entre la connexion extérieure et le réseau local. Dans ce cas, deux interfaces (eth0 et eth1) seront utilisées.
[Sommaire] |
[Suivant]
Détection et analyse
|