[IDS Snort Windows – Partie 2] Installation et configuration

Par Rédaction, secuobs.com
Le 11/05/2008

---

Résumé : L’installation de Snort, bien que relativement simple, ne permet pas d’utiliser directement l’IDS sans modification préalable de la configuration par défaut. SNORT peut cependant être mis en place de façon rudimentaire en moins d’une heure. - Lire l'article



NDLR : ce document a été rédigé en 2006, certaines versions ainsi que certaines configurations des logiciels utilisés selon ces versions peuvent être différentes de celles qui sont mentionnées ; merci de vous reporter vers les sites officiels des projets en question en cas de problème.


La gestion des captures réseau est basée sur la librairie pcap (WinPcap sous Windows). Snort requiert donc cette dernière pour fonctionner correctement.

La dernière version stable est téléchargeable sur ( lien ) et est distribuée sous une licence de type BSD ; pour de plus amples informations à ce sujet (cf. lien ).

L’installation triviale de cette librairie (Auto-installer) ne sera pas détaillée ici.

Le paquet à télécharger est « Winpcap auto installer ». Le développeur se tournera vers le paquet devel contenant les codes sources de la librairie ainsi qu’une documentation technique plus détaillée. Selon la version et le type de l’OS, l’installation peut nécessiter un redémarrage.

Vient ensuite l’installation de Snort avec l’installateur ( lien ).

Basée sur le même type d’installer que Winpcap, l’une des seules options modifiables est le chemin d’installation de Snort (par défaut c:\snort).

L’arborescence se présente avec les dossiers suivants :

bin/ – contenant l’exécutable

contrib/ – contenant le fichier README classique des projets open source.

doc/ – contenant une documentation détaillée pour l’installation et la configuration. Il contient également une FAQ (Frequently Asked Questions)

etc/ – contenant les fichiers de configuration de l’IDS, ainsi qu’une configuration par défaut très commentée.

log/ – qui contiendra les fichiers de journalisation et les éventuels enregistrements pcap relatifs aux alertes.

rules/ – contenant les règles des différentes alertes. Il est d’ailleurs conseillé de les mettre à jour régulièrement.

schemas/ – contenant les schémas pour différentes bases de données (MySQL, MsSQL, Oracle et PostgreSQL). Il est en effet possible de remonter les alertes dans une base de données distante pour un traitement spécifique.


Configuration

La majeure partie de la configuration est stockée dans le fichier etc/snort.conf qui sera appelée au démarrage de Snort.

Le fichier peut être repris tel quel et modifié linéairement pour l’adapter aux besoins et spécificités du serveur. Attention, les « # » sont des commentaires et ne seront donc pas pris en compte dans la configuration.

Les deux premières variables à définir sont :

HOME_NET qui définit le ou les réseau(x) cible(s) à auditer ;

EXTERNAL_NET qui contient les réseaux considérés comme hostiles. Dans bien des cas, elle sera fixée à « any » pour ne faire confiance à aucun réseau (cas d’une sonde reliée directement à Internet par exemple).

Les alertes provenant de HOME_NET seront également remontées.

Pour ne considérer que les alertes entrantes, il est possible de la définir de la façon suivante :

var EXTERNAL_NET !$HOME_NET


Puis nous précisons les différentes machines du réseau (SMTP, SNMP, HTTP, etc.), et les ports sur lesquels les services sont en écoute.

RULE_PATH permet ensuite de définir le chemin des fichiers rules contenant les règles de déclenchement des différentes alertes.

Viennent les préprocesseurs qui permettent de suivre des connections, réassembler les paquets, décoder certains types de protocoles, etc.

Comme indiqué dans la configuration par défaut, la syntaxe est :

preprocessor <nom du préprocesseur>: <options>


Voici les principaux préprocesseurs de Snort :

- flow pour le suivi des paquets IP (src port, dst port, etc.)

- frag2 pour le réassemblement des paquets IP (défragmentation)

- stream4 pour le réassemblement des trames TCP : stateful

- http_inspect pour le décodeur HTTP (normalisation des champs, etc.)

- rpc_decode pour la normalisation et le réassemblement des paquets RPC

- bo pour le trafic de la porte dérobée Back Orifice

- telnet_decode pour le réassemblement du trafic Telnet et FTP

- flow-portscan sf Portscan pour la détection de scans de ports

- arpspoof pour la détection d’attaques L2 de type ARP cache poisoning


Les options détaillées sont disponibles dans le fichier de configuration par défaut ou sur la documentation en ligne ( lien & lien ).

Les sorties (outputs) permettent de configurer avec précision la journalisation des alertes et les enregistrements pcap (traces réseau).

Plusieurs formats sont disponibles, la syntaxe générique est :

output <nom>: <options>


Journalisation syslog : remontée locale ou distante des alertes vers un serveur de journalisation syslogd.

Locale:

output alert_syslog: LOG_AUTH LOG_ALERT


Distante:

output alert_syslog: host=192.168.0.100:514, LOG_AUTH \ LOG_ALERT


Sauvegarde pcap : traces réseau relatives aux alertes dans le format pcap, lisibles entre autres par les outils tcpdump ou ethereal :

output log_tcpdump: tcpdump.log


Journalisation SQL/Oracle : remontée des alertes vers un serveur SQL/Oracle :

output database: log, mysql, user=utilisateur password=mdp dbname=db host=localhost


Où le type de serveur peut être adapté : mysql, mssql, postgresql, oracle ou obdc, ainsi que l’utilisateur et le mot de passe.

Journalisation “Snort” / unified : format binaire spécifique à Snort et permettant d’augmenter les performances globales des enregistrements et de limiter la taille du fichier de sortie :

output alert_unified: filename snort.alert, limit 128


Journalisation spécifique : en fonction de certaines alertes. Par exemple pour une porte dérobée de type connect back sur le port TCP/31337 :

ruletype backdoor { type alert output log_tcpdump: trojan31337.log }


Avec la règle associée :

backdoor tcp $HOME_NET any -> $EXTERNAL_NET 31337 \ (msg:"Backdoor 31337 detected"; flags:A+;)


Le dernier point à prendre en compte dans cette configuration est l’activation des différentes classes de règles : les noms des règles sont très explicites.

Il est également possible de créer son propre jeu de règles : la syntaxe est très simple et de nombreuses règles supplémentaires sont disponibles, par exemple sur des mailing-lists de type bugtraq ou directement sur le site de Snort.

Exemple d’alerte détectant l’exploitation d’un bug sur un progiciel Web/CGI :

alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"WEB-CGI progiciel_compta exploitation attempt"; flow:to_server,established; uricontent:"/prog_compta"; content:"../" ; content:"%00" ; classtype:web-application-attack;)


La configuration terminée, Snort se lance simplement avec :

snort -d -l ../log -c ../etc/snort.conf \ -i [interface]


Pour déterminer l’identifiant de l’interface, il est possible :

- d’utiliser Ethereal pour récupérer l’identifiant de l’interface,

- de récupérer directement l’identifiant dans la base de registre Windows avec la clef HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces.


Exemple de lancement :

snort -d -l ../log -c ../etc/snort.conf \ -i \Device\NPF_{2D7E7BAE-3442-4FA1-A154-5172CAC0F038}


Autres ressources dans ce dossier :

[IDS Snort Windows – Partie 1] Introduction aux IDS et à SNORT – lien

[IDS Snort Windows – Partie 3] Exemple de fichier de configuration – lien

[IDS Snort Windows – Partie 4] Conclusion et webographie – lien