Introduction aux IDS et à SNORT
Contents
1 Introduction aux IDS et à SNORT
Les systèmes de détection d'intrusions (ou IDS pour Intrusion Detection System) sont de plus en plus répandus et prennent une part importante et croissante dans la sécurité des systèmes d'informations actuels. SNORT est un de ces systèmes de détection d'intrusions avec la particularité d'être un logiciel libre sous licence GPL.
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.
De nombreuses solutions commerciales ont vu le jour avec l'apparition de ce marché jusqu'alors peu développé. Il existe cependant différentes alternatives open source, qui sont souvent à l'origine de produits commerciaux et dont les performances et la fiabilité n'ont rien à envier à leurs concurrents.
Si les aspects techniques sont parfois complexes, les aspects organisationnels n'en sont pas moins importants dans la mise en place de ces systèmes.
En effet, le déploiement d'IDS nécessite une équipe qualifiée, qui peut être sous-traitée par une SSII spécialisée par exemple pour l'installation et la configuration, mais également une équipe qui se chargera de suivre les alertes remontée, d'affiner la configuration pour réduire au maximum les faux positifs, et de mettre en place les contre-mesures éventuelles aux attaques détectées.
Cet aspect souvent sous-estimé conduit certaines entreprises à déployer des IDS dans leurs infrastructures puis de les laisser en place sans monitoring ce qui les rend alors inutiles, voire dangereuses pour le système d’informations.
Il existe principalement 2 types d'IDS :
- Les HIDS (Host IDS), ou encore IDS système, qui analysent localement l'intégrité des machines via un contrôle des appels système, des différents journaux d'événements, de l'intégrité du système de fichiers, etc.
- Les NIDS (Network IDS) qui se basent uniquement sur le trafic réseau capturé et qui fonctionnent la plupart du temps sur des règles de pattern matching pouvant être déclenchées grâce à des signatures connues.
Les NIDS analysent les flux en temps réel (aux temps de latence près) et peuvent réassembler les trames (fragmentation IP), reconstituer les flux (stream4) et gérer les états (stateful).
Les sondes constituent les agents actifs de l'IDS : elles isolent les informations pertinentes qu'elles capturent, les événements - a priori - suspects, puis les remontent à un système centralisé : le concentrateur d'alertes.
Le format des alertes doit être connu du concentrateur. Cette problématique a donné naissance au format IDMEF (Intrusion Detection Message Exchange Format), fondé sur XML, et qui permet de normaliser les différentes alertes remontées.
Dans une large infrastructure, plusieurs sondes sont nécessaires. Il faut alors veiller à choisir judicieusement les emplacements de celles-ci sur le réseau afin de ne pas surcharger inutilement les alertes remontées.
Présentation de Snort
Snort ( [click] ), qui fait partie de la catégorie des NIDS, est un produit open source puissant, configurable, et qui répond aux principales contraintes de la détection d'intrusions.
Il analyse le trafic en temps réel et permet de décoder de nombreux protocoles, d'effectuer du pattern matching sur les paquets capturés, et permet également de repérer les scans de ports.
Il permet de remonter les alertes via syslog, vers un fichier spécial (socket ou pipe par exemple), vers une base de données distante (MySQL, MsSQL ou autre), ou encore via des alertes directes (WinPopup).
Comme tous les projets open source, il dispose d'une large communauté, permettant ainsi de répondre très rapidement aux problèmes rencontrés ou aux demandes d'informations. La documentation fournie est abondante et détaillée, permettant d'exploiter au maximum les possibilités offertes par ce puissant outil.
Placement dans l’architecture
Les sondes doivent être placées avec attention sur les segments du réseau à auditer : elles seraient par exemple inutiles sur un segment d'administration où les accès seraient considérés comme sûrs et où les informations remontées « brouilleraient » l’analyse.
Les débits sont à prendre en compte car le nombre d'alertes est souvent proportionnel au trafic du segment.
Une étude des risques (que dois-je protéger ? contre qui ? Quel est le degré de sensibilité des informations transitant sur ce segment réseau ? Etc.) doit précéder le déploiement afin de déterminer au mieux les emplacements des futures sondes.
Les sondes ne nécessitent pas de configuration IP, hormis si elles nécessitent une administration à distance ou une communication avec le concentrateur d'alertes.
Le cas classique d'une architecture comportant une zone démilitarisée (DMZ) et un Intranet : La sonde en aval du pare-feu, récoltera un grand nombre d'alertes et n'est pas toujours nécessaire. Elle pourrait s'avérer néfaste lors de l'analyse des alertes.
La sonde située dans la DMZ est la plus sensible et devra faire l'objet d'une attention particulière. En effet, en cas de compromission d'une machine depuis l'extérieur, c'est elle qui remontera les premières alertes générées en cas de détection.
Quant à la sonde placée dans l'intranet, son utilité est proportionnelle au nombre d'utilisateurs et au degré de confiance accordé. Elle peut être particulièrement utile pour la détection de vers, de virus, ou de portes dérobées mais également en cas de compromission de postes utilisateurs.
Aspects physiques
Les sondes doivent pouvoir analyser l'intégralité du trafic du segment sur lequel elles agissent.
Connectées à un hub où les paquets sont transmis sur tous les ports de celui-ci, elles peuvent être directement reliées sur un port quelconque.
Dans le cas d'une utilisation sur un switch, elles devront être placées sur des ports de réplication (mirroring port).
Il est possible d'augmenter la furtivité des sondes en rendant unidirectionnelle la connexion physique au réseau et ne permettant ainsi qu'une écoute passive du trafic.
Elles seront alors "transparentes" mais nécessiteront un accès physique pour les besoins de maintenance ou pour l'analyse locale des alertes.
2 Installation et configuration
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.
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 ( [click] ) et est distribuée sous une licence de type BSD ; pour de plus amples informations à ce sujet (cf. [click] ).
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 ( [click] ).
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 ( [click] & [click] ).
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}
3 Exemple de fichier de configuration
L’intégralité du fichier utilisé dans ce dossier pour la configuration du système de détection d'intrusions Open-Source SNORT.
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.
#--------------------------------------------------
# etc/snort.conf
#--------------------------------------------------
# Réseaux C 192.168.0.0 et 192.168.1.0
var HOME_NET [192.168.0.0/24,192.168.1.0/24]
# Tout le trafic sauf les réseaux considérés comme "sûrs"
var EXTERNAL_NET !$HOME_NET
# Serveurs DNS
var DNS_SERVERS $HOME_NET
# Serveurs SMTP
var SMTP_SERVERS $HOME_NET
# Serveurs HTTP
var HTTP_SERVERS $HOME_NET
# Serveurs SQL
var SQL_SERVERS $HOME_NET
# Serveurs Telnet
var TELNET_SERVERS $HOME_NET
# Serveurs SNMP
var SNMP_SERVERS $HOME_NET
# Ports en écoute sur les serveurs HTTP
var HTTP_PORTS 80
# Ports sur lesquels les shellcodes seront surveillés
# Le port 80 (HTTP) entraîne trop souvent de faux-positifs
var SHELLCODE_PORTS !80
# Port Oracle
var ORACLE_PORTS 1521
# Serveurs AIM (IM)
var AIM_SERVERS [64.12.24.0/23,64.12.28.0/23,64.12.161.0/24]
# Chemin contenant les règles de pattern matching
var RULE_PATH ../rules
# Préprocesseurs
preprocessor flow: stats_interval 0 hash 2
preprocessor frag2
preprocessor stream4: disable_evasion_alerts
preprocessor stream4_reassemble
preprocessor http_inspect: global iis_unicode_map unicode.map 1252
preprocessor http_inspect_server: server default profile apache ports { 80 }
preprocessor rpc_decode: 111 32771
preprocessor bo
preprocessor telnet_decode
preprocessor sfportscan: proto { all } memcap { 10000000 }
sense_level { low } \
ignore_scanners { 192.168.1.1 192.168.1.10 }
# Sorties / outputs
output log_tcpdump: tcpdump.log
output database: log, mysql, user=utilisateur password=mdp dbname=snort host=localhost
output alert_unified: filename snort.alert, limit 128
output log_unified: filename snort.log, limit 128
# Règles activées
include $RULE_PATH/local.rules
include $RULE_PATH/bad-traffic.rules
include $RULE_PATH/exploit.rules
include $RULE_PATH/scan.rules
include $RULE_PATH/ftp.rules
include $RULE_PATH/telnet.rules
include $RULE_PATH/dos.rules
include $RULE_PATH/ddos.rules
include $RULE_PATH/web-cgi.rules
include $RULE_PATH/web-misc.rules
include $RULE_PATH/web-client.rules
include $RULE_PATH/web-php.rules
include $RULE_PATH/sql.rules
include $RULE_PATH/smtp.rules
include $RULE_PATH/imap.rules
include $RULE_PATH/other-ids.rules
include $RULE_PATH/web-attacks.rules
include $RULE_PATH/backdoor.rules
include $RULE_PATH/shellcode.rules
include $RULE_PATH/policy.rules
include $RULE_PATH/virus.rules
4 Conclusion et webographie
Cette dernière partie du dossier l'IDS Open-Source SNORT aborde succinctement des sujets comme la sécurité des sondes ainsi que le monitoring. Retrouvez également l'ensemble des liens relatifs à ce dossier.
4.1 Sécurité de la sonde
Une sonde est un élément sensible de par sa fonction sur le réseau: un attaquant cherchera à dissimuler les traces de son attaque en la compromettant.
Elle doit donc faire l’objet d’une attention particulière quant aux mises à jour, notamment Winpcap et Snort, et à une sécurisation élémentaire de celle-ci.
4.2 Monitoring
Plusieurs interfaces permettent d’analyser les alertes remontées par les sondes. ACID (Analysis Console for Intrusion Databases) est l’une des plus performantes et permet également de corréler des alertes de différentes sondes sur le réseau.
Elle est accessible via un simple navigateur Web et dispose de nombreuses options de configuration.
La détection d’intrusions sous Windows n’est pas en reste grâce aux applications portées telles que Snort et Winpcap.
Si l’installation et la configuration sont relativement accessibles, le travail préalable au déploiement de ces systèmes ne doit pas être négligé : une étude précise (budget/personnel, analyse des risques, etc.) est nécessaire.
Les IDS, bien que de plus en plus performants, peuvent être contournés, notamment via des canaux cachés ou encore des encodages de shellcodes, et ne constituent qu'un moyen de sécurité complémentaire !
Il serait illusoire de penser qu’un IDS puisse prévenir une attaque.
Il permet, s’il est correctement configuré et utilisé, de réduire considérablement les dégâts engendrés par la compromission de machines sur le réseau en diminuant le temps de réaction des équipes compétentes.
La principale difficulté reste l’analyse des journaux d’événements car une attaque peut rapidement être noyée dans un flux de faux positifs. ==
