Test d ’un système de détection d ’intrusions réseaux (NIDS)

1. 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

2. Environnement du Produit • 2 éléments • Le produit s ’intègre dans la gamme CISCO SECURE • Intégration dans le réseaux • Installation

3. 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)

4. 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

5. 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é

6. 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)

7. 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é

8. Hiérarchisation de directors

9. 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

10. 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)

11. 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é

12. Affichage des alarmes Sur un seul plan !

13. Détails des alarmes

14. Visualisation de la NSDB(description des signatures)

15. Description des failles

16. Paramétrage graphique de la sonde

17. actions spécifiques

18. 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

19. 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)

20. 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

21. 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é

22. 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)

23. Conclusion Avant 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.