Résumé : 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.

Poster un commentaire

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 ( lien http externe url:[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.


Autres ressources dans ce dossier :

[IDS Snort Windows – Partie 2] Installation et configuration – lien http interne url:[click]

[IDS Snort Windows – Partie 3] Exemple de fichier de configuration – lien http interne url:[click]

[IDS Snort Windows – Partie 4] Conclusion et webographie – lien http interne url:[click]

Poster un commentaire