Test d ’un système de détection d ’intrusions réseaux (NIDS) La solution NETRANGER CISCO SECURE IDS Par l ’Université de Tours Thierry Henocque Patrice Garnier

Environnement du Produit 2 éléments Le produit s ’intègre dans la gamme CISCO SECURE Intégration dans le réseaux Installation La sonde est une boite noire (sur architecture PC/Solaris) à 2 interfaces

2 éléments La sonde (SENSOR) PC propriétaire 20 Kg La console d ’administration (Le Director) Un station SUN/HP Sun de préférence avec HP-OpenView Plug-In Elle peut gérer plusieurs Sensors et plusieurs Directors (hierarchiques)

Le produit s ’intègre dans la gamme CISCO SECURE Gestion dynamique d ’acl sur routeurs CISCO Une version allégée (59 signatures) Peut être installé dans l ’IOS CISCO 12.5(T) et dans ce cas peut être autonome (syslog) La version 2.0 de CSPM (mi avril) pourra recevoir les alarme et la version 2.1 (septembre) remplacera le director CSPM= CISCO SECURE POLICIES MANAGER N.b.: Nous envisageons de tester la solution IDS intégrée à l ’IOS CISCO

Intégration dans le réseau Le sonde possède 2 interfaces une sur le réseau à écouter une sur le réseau du director utiliser de préférence un réseau dédié Problématique de notre test 3 buts - se protéger des attaques extérieures et éviter de trop "polluer" Internet - augmenter la connaissance de l ’usage de notre réseau (Nous ne maîtrisons pas les serveurs situés dans les UFR) - mettre en place une politique de sécurité

Installation du Sensor installation physique PC à intégrer dans une armoire 19 pouces paramétrage réseau @ip nom @director(s) seules les machines citées peuvent communiquer avec lui configuration de la communication (Host ID,Host Name, Organisation ID, Organisation Name)

Installation du Director Nous avons utilisé une station SUN sous Solaris 2.7 avec HpOv 6.1 et Netscape. Il faut prévoir 1,2 Go d ’espace disque dont 1Go pour les logs Une fois que ces pré requis sont mis en place : un script (./install) rajoute à HpOv un plugin en Java et demande des info (Host ID,Host Name, Org. ID, Org. Name) Sous HpOv, AddHost lance un assistant dans lequel on indique le sensor concerné

Hiérarchisation de directors

Principe de Fonctionnement Rôles de chacun des éléments (Sensor et Director) Le SENSOR Sniffe les paquets reconstitue les sessions et compare avec une base de signatures sert via POP les alarmes au(x) Directors selon la politique de sécurité logue les sessions envoie des TCP Reset La sonde compare les paquets avec une base de signature à partir de l ’entête ou dans le contenu des données sur des paquets isolés ou sur des sessions La mise à jour des signature se fait via le Director tous les 15 jours La sonde envoie les alarmes au Director par POP Le director affiche une icône pour chaque nouvelle alarme

Principe de Fonctionnement Rôle du DIRECTOR Paramétrage de la politique de sécurité (alarmes,logs,actions) Affichage les alarmes "en temp réel" sous forme d'icones Paramétrage des signatures Mise à jour du fichier de signatures (tous les 15jours). Personnalisation de signatures basées sur des chaînes de caractères. Et suivant la politique de sécurité configurée Retransmet des alarmes (syslog, mail, snmp, script, oracle) Modifie les droits d'accès au réseau (acl spécifique CISCO)

Fonctionnalités Affichage des alarmes Tri sur critère des alarmes Visualisation de la NSDB Description des signatures Description des failles Paramétrage graphique de la sonde Paramétrage graphique de la politique de sécurité

Affichage des alarmes Sur un seul plan !

Détails des alarmes

Visualisation de la NSDB (description des signatures)

Description des failles

Paramétrage graphique de la sonde

actions spécifiques Danger relatif à la configuration de tels mécanismes

Exploitation premières impressions Problématique de l'analyse des logs quantités qualification SQL une solution efficace mais insuffisante Une attaque peut-être représentée par des alarmes dont les paramètres ne sont pas fixes signature @source et @destination port temporisation 1ères impressions : un nombre affolant d'alarmes :15000 / jour constatation : il y a plus d'alertes en provenances de nos réseaux vers l'extérieur Problématique des logs : Comment lire 15000 lignes par jour? Comment distinguer les types d'alarmes - Phases de reconnaissances (scans, sweep,...) - Phases d'intrusion ( FTP retry password, Windows password...) - Machines déjà piratées - Trafic du à des réseaux défectueux - du trafic normal (faux positif) L'analyse ne peut pas se faire uniquement sur le numéro d'alarme!!! d'autres paramètres entrent en ligne de compte quantité et types de services existant sur les machines (suppose de bien connaitre son réseau la densité des alertes dans le temps et l'espace (espace de nommage) Le fait d'avoir un mélange d'alertes : souvent un outil de pirate génère non pas une alerte mais un ensemble d'alertes caractéristiques du type d'attaque (scan) effectué Comment prendre du recul dans cette abondance de log Où cela nous a mené : Examen des logs dans une base de donnée (on a utilisé access, mais c'est un peu juste pour gérer plusieurs dizaine voir centaines de milliers d'enregistrements une semaine = 100000 alertes) Mise en places de requêtes permettant d'éliminer des faux positifs Mécanisme d'acquittement des alarmes

Résultats beaucoup de scans transparents Certains faux positifs sont identifiables Proxy => Syn Host Sweep (80) Traceroute => ICMP Time exeded alarmes anodines révélatrices d'anomalies Danger d'ignorer une alarme (Time exeded)

Résultats Découverte d'un serveur piraté Oubli dans les configurations de routage règle anti-smurf sur une interface problèmes de routage des classes privées Hot spots salles d'étudiants machines habitées lokid trafic suspect

Points positifs améliore la connaissance de l'usage du réseau NSDB (Network Sécurity Data Base) scans bien détectés reconstitue les session dans le cas d ’ attaques fragmentées avec ‘ nmap -f ’ semble tenir la charge (nmap -f) Logs denses (1 ligne par alarme) Paramétrage fin de la politique de sécurité Points positifs : Les scans sont assez bien détectés, mieux que dans les logs standards unix (même avec des méthodes dites discrètes : nmap -sS -T) Améliore la connaissance de son (ses) réseaux : nous avons déterminés plusieurs points chauds Outil qui permet de réagir en temps réel Points négatifs : bugs (tri, affichage,...) pb dans l'interface java de configuration souvent on ne peut pas sauvegarder les modification de config ls sonde peut subir des dénits de services (nmap -f : plusieurs milliers d'alarmes par minutes) qui permettent de faire des attaques non loggées par la sonde !!! ni la sonde ni la console d'administration ne sont capable de synthétiser les informations recueillies

Points négatifs Interface graphique déplorable Contraintes sur le matériel nécessaire. Coté boîte noire algorithme de détection des attaques inconnu fichier de signatures binaire monolithique sonde peu transportable (21 kg) Pas de synthèse des logs Problèmes de remontée des alarmes dans HpOv Bugs (tri, java)

Conclusion Avant ce test : Après ce test : On s'en passait très bien Après ce test : Il nous paraît difficile de ne pas utiliser du tout d'IDS Il reste à choisir 1 (ou plusieurs) IDS et à trouver une solution humaine pour l'analyse des logs.