IDS et LAN
L’utilisation d’un NIDS sur un réseau local est peu répandue, en effet, on peut estimer que la zone est de confiance moyenne, mais surtout que peu de valeur réside sur le LAN. Néanmoins, on retrouvera sur le LAN des serveurs méritant une attention particulière (DNS, DHCP, serveurs de fichiers, contrôleurs de domaines) ainsi que des machines d’administration, intéressantes pour un rebond ciblé. Un environnement qui respecte les principes de cloisonnement des activités et l’utilisation de VLANs dédiés sera plus facilement utilisable pour déployer des NIDS.
En poussant plus loin l’analyse, il est possible de faire une différenciation entre un LAN de production et un LAN bureautique. Un LAN de production est une zone avec une valeur forte et une configuration correcte. A contrario, un LAN bureautique
représente peu de valeur et une confiance moyenne. Dans les deux cas, la configuration NIDS est difficile car on ne maîtrise pas souvent les flux qui transitent sur le réseau interne et les ressources sont souvent éparpillées. Pour le LAN, nous pouvons parler des cœurs de réseau, qui concentrent les flux venant de VLANs différents. L’avantage des cœurs de réseau pour y placer une sonde est une visibilité accrue sur tous les VLANs, mais le principal désavantage réside dans la quantité de trafic. Les nouveaux cœurs de réseau sont maintenant prévus en dizaine de gigabits dans les grandes entreprises et même si des produits se déclarent « Gigabit compliant », leur débit utile est souvent de l’ordre de quelques centaines de mégabits.
De plus, si les paquets sont de petite taille, la capacité de traitement s’effondre.
Une sonde aurait donc plus d’intérêt à être située sur un équipement d’accès au cœur de réseau (routeur, Firewall…) ou sur la partie distribution
IDS et MAN
Un MAN permet d’interconnecter des sites géographiquement proches. Les sites peuvent hébergés la production de l’entreprise, les serveurs bureautiques, être des sites bureautiques ou mélanger ces possibilités. Sur le MAN, nous pouvons donc voir tout type de flux (bureautique/ production). Si la séparation des activités est faite, il est facile d’identifier le trafic passant sur les liens du MAN. Dans ce cas, les flux non identifiés seront suspects. Dans les deux cas, l’utilisation d’un NIDS est intéressante puisqu’elle permettra d’analyser les flux à l’interconnexion des sites. Comme énoncé dans le paragraphe précédent, mettre une sonde à l’entrée d’un site permet d’analyser tout ce qui rentre et sort de ce site. Qu’il y ait une politique de filtrage entre les sites et LAN de chaque site ou non, le NIDS permettra une analyse plus profonde des flux (Rappelons qu’un flux autorisé par un firewall/ACL n’est pas forcément valide). Rappelons aussi que les liens réseaux du MAN étant dans la plupart des cas des liaisons louées, ils peuvent être partagés entre plusieurs clients. Nous pourrions affecter une note de valeur de faible à moyenne, et une note de confiance qui sera correcte si le lien ne supporte qu’un client (fibre entre deux bâtiments) ou plus forte si la liaison est partagée. Cela peut amener à se poser la question du chiffrement des flux.
Ceci implique le placement de la sonde aux endroits où le trafic n’est pas chiffré.
IDS et WAN
Les problématiques du WAN ressemblent à celles du MAN. La charge réseau qui transite par le WAN est généralement plus restreinte et plus précise que celle qui passe par le LAN car les lignes sont souvent louées. Ainsi, un WAN obtiendra une note de confiance correcte car les flux réseaux sont maîtrisés, mais à l’inverse la zone de valeur sera probablement plus faible que pour un MAN.
Suivi des attaques
Les IDS sont rarement les seules solutions de sécurité informatiques mises en place sur un réseau. Il y a donc tout un ensemble de “barrières” déjà mises en place. Mais sontelles efficaces ? Et si une attaque est perpétrée contre une machine du réseau, quelle protection a permis de la stopper, et laquelle n’a au contraire rien changer ? Un réseau peut aussi avoir des vulnérabilités de conception, comme par exemple, la possibilité de se connecter à des Access Point Wireless, accédant de la sorte au LAN sans passer par le firewall qui ne surveille que les accès à Internet.
Surveillance globale
La mise en place de sondes sur tout le réseau va permettre de suivre une attaque. Il est important de pouvoir avoir une sonde surveillant le traffic avant et après chaqueprotection (avant et après un firewall…). Ainsi, cela permet d’avoir un aperçu des attaques que la protection bloque et celles qu’elle laisse passer. Pour une attaque donnée, on pourra en déduire son taux de pénétration dans le réseau, et ainsi désigner les parties du réseau sûres et celles non sûres face à une attaque donnée.
Dans les réseaux complexes et vastes, nous nous trouvons parfois face à des niveaux de sécurité hétérogènes. Le cas le plus répandu est de rencontrer une sécurité maximale sur l’accès à Internet, mais une fois dans le LAN, tout est ouvert (faible protection entre la DMZ et le LAN, des Access Point Wireless poussant comme deschampignons, accès illicites à Internet directement d’un poste de travail, …). Alors qu’une attaque donnée serait bloquée en passant par la grande porte, elle ne rencontrera aucune résistance en passant par un autre chemin. Le positionnement des sondes sur tout le réseau va alors permettre de détecter par où elle est rentrée, ou le chemin qu’elle a emprunté pour contourner les protections qui auraient pu la bloquer. Avantages/Inconvénients : Le problème de cette solution est le coût matériel et humain. Le nombre de sondes étant très important, il est évident que le nombre de machines à dédier à cette tâche est plus important. De plus, l’exploitation correcte de toutes les alertes remontées (alertesremontées par plusieurs sondes, savoir retrouver le parcours d’une attaque dans tout cela, …) nécessite beaucoup de temps.
Problème de positionnement des sondes
La mise en place est importante. Il faut bien définir là où placer les sondes. Il ne s’agit pas de mettre une sonde partout où l’on veut surveiller. Il faut étudier les champs de vision des sondes suivant leur placement, si on veut recouper ces champs de vision (pour par exemple faire des doublons de surveillance ou faire un suivi d’attaque), quel détail d’analyse (à l’entrée d’un réseau, ou dans chaque domaine de collision). On découpe souvent le réseau global en un LAN, une DMZ, puis Internet. Mais il faut aussi envisager les domaines de collisions, les sous réseaux, … Étant donné que la sonde travaille en mode promiscuité, elle utilise la librairie libpacap ou winpcap qui fait qu’une sonde ne pourra pas être installée sur les firewalls. Et la mise en place sur la sonde même d’un filtrage pour la protéger contre certaines attaques directes aura une efficacité très réduite.
L’utilisation de tunnel est aussi à envisager lors du positionnement des sondes : inutile de placer une sonde où tout le trafic est crypté.
Les connaissances réseaux sont importantes. Il faut aussi faire attention à comment sont remontées les alertes (si on passe par une ligne RNIS, éviter de la monter et la fermer à chaque alerte). Même si la plupart des schémas montrent un manager et N sondes, nous pouvons très bien utiliser M manager et N sondes.
Vulnérabilités des sondes NIDS
De part leur fonctionnement en mode promiscuité (carte réseau sans adresse IP), lessondes sont vulnérables. Elles captent tout le trafic, et même si un ping flood est réalisé sur une autre machine, les sondes NIDS le captureront aussi et donc en subiront les conséquences, comme si l’attaque leur était directement envoyée.
Un DoS explose les fichiers de logs
Le point fort de certains IDS qui est d’archiver aussi le payload des trames ayant levées une alerte, peut aussi s’avérer un point faible. Un ping flood avec un payload chargé de 64000 octets, ou encore des trames de 1500 octets pour les SYN flood vont faire exploser la taille des fichiers de logs des sondes en quelques minutes. C’est une attaque qui porte le nom coke qui consiste à saturer le disque dur (http://www.securiteinfo.com/attaques/hacking/coke.shtml). La seule façon de parer cette attaque est de prévoir d’importants espaces de stockages, et gérer le stockage des fichiers de logs.
Par les méthodes classiques de scan
Nous pouvons prendre comme exemple le scan furtif SYN implémenté par NMAP permettant de ne pas être détecté par les NIDS. Le but du scan SYN est de ne pas ouvrir une connexion complètement. A la réception d’un SYN/ACK qui signifie que le port est ouvert, il envoie un RST pour interrompre la connexion. Aucune connexion n’est donc faite tout en sachant quels ports sont ouverts.
Par le flood
Il consiste à surcharger le NIDS pour qu’il ne puisse pas fonctionner correctement, et qu’il ne détecte pas l’attaque principale. Par la noyade sous les faux positifs : Le principe est de provoquer de nombreuses remontées d’alertes. En parallèle, une attaque réelle contre le réseau est lancée, et l’administrateur occupé à analyser les alertes, ne s’en rendra pas compte sur le moment. Nous pouvons utiliser l’option decoy de nmap pour générer des scans nmap multiples.
Par fragmentation
Le principe est de fragmenter les paquets IP pour empêcher les NIDS de détecter les attaques sachant que les paquets seront réassemblés au niveau du destinataire. Il est possible aussi d’envoyer des paquets IP mal fragmentés qui vont utiliser la faiblesse de certaines pile IP (peut-être aussi celle de la sonde IDS qui capte tout le trafic) pour perturber le système.
Par des scans lents
Les NIDS ne détectent souvent pas ce type de scan (un scan toutes les heures par exemple). Sachant qu’un NIDS maintient un état de l’information (TCP, IP fragments, TCP scan, …) pendant une période de temps bien définie (capacité mémoire, configuration), ils ne détectent rien si deux scans consécutifs sont trop espacés.
Conclusion
Les IDS continuent d’évoluer pour répondre aux exigences technologiques du momentet offrentd’ores et déjà un éventail de fonctionnalités capables de satisfaire les besoinsde tous les types d’utilisateurs. Cependant comme tous les outils techniques ils ont des limites que seule une analyse humaine peut compenser. Les détecteurs d’intrusions deviennent chaque jour meilleur grâce à l’expérience acquise avec le temps. Mais ils deviennent aussi de plus en plus sensibles aux erreurs de configuration et de paramétrage. Par conséquent, il est plus que fondamental de former correctement les personnes chargées de la mise en oeuvre et de l’exploitation des IDS.
Snort et Prelude-NIDS
Snort
Snort est un système de détection d’intrusion réseau capable d’effectuer l’analyse dutrafic en temps réel et de la journalisation de paquets sur des réseaux IP. Il peut effectuer de l’analyse de protocoles, de la recherche / correspondance de contenu et peut être utilisé pour détecter une variété d’attaques et de scans, tels que des débordements de tampons, des scans de ports furtifs, des attaques CGI, des scansSMB, des tentatives d’identification d’OS… Snort utilise un langage de règles flexibles pour décrire le trafic qu’il devrait collecter ou laisser passer, ainsi qu’un moteur de détection qui utilise une architecture modulaire de plugin. Snort possède aussi des capacités modulaires d’alertes en temps réel, incorporant des plugins d’alerte et de journalisation pour syslog, des fichiers textes en ASCII, de sockets UNIX, de messages WinPopup à des clients Windows en utilisant smbclient de Samba, de base de données (Mysql/PostgreSQL/Oracle/ODBC) ou XML. Snort a trois utilisations principales.
Il peut être utilisé comme un simple renifleur de paquets comme tcpdump (1), un enregistreur de paquets (utile pour déboguer le trafic réseau, etc), ou comme un système complet de détection d’intrusion réseau. Snort journalise les paquets dans le format binaire tcpdump, vers une base de données ou dans le format ASCII
Caractéristiques
Descriptions
L’architecture de SNORT est organisée en modules, elle est composée de quatre grands modules : Le décodeur de paquets, les préprocesseurs, le moteur de détection et le système d’alerte et d’enregistrement de log.
Le décodeur de paquets
Un système de détection d’intrusion active un ou plusieurs interfaces réseau de la machine en mode espion (promiscuous mode), ceci va lui permet de lire et analyser tous les paquets qui passent par le lien de communication. SNORT utilise la bibliothèque libpcap pour faire la capture des trames. Un décodeur de paquets est composé de plusieurs sous décodeurs qui sont organisés par protocole (Ethernet, IP, TCP..), ces décodeurs transforme les éléments des protocoles en une structure de données interne.
Les présprocesseurs
Les préprocesseurs s’occupent de la détection d’intrusion en cherchant les anomalies, un pré processeur envoie une alerte si les paquets ne respectent pas les normes des protocoles utilisées. Un pré processeur est différent d’une règle de détection, il est un programme qui vise à aller plus en détail dans l’analyse de trafic.
Moteur de détection
Décodage des protocoles
« Liaison de données »
Décodage des protocoles
« Réseaux»
Décodage des protocoles
« Transport »
Préprocesseur
C’est la partie la plus importante dans un SDI. Le moteur de détection utilise les règles pour faire la détection des activités d’intrusion. Si un paquet correspond à une règle une alerte est générée.
Les règles sont groupées en plusieurs catégories sous forme de fichiers. SNORT vient avec un ensemble de règles prédéfini.
Ces règles ne sont pas activées automatiquement, il faut les activer dans le fichier de configuration snort.conf. Chaque fichier contient des règles décrivant un type de trafic à signaler.
Système d’alerte et d’enregistrement des logs
Le système d’alerte et d’enregistrement des logs s’occupe de la génération des logs et des alertes. Les alertes sont stockées par défaut dans le répertoire /var/log/snort/. Dés que le système devient opérationnel, on pourra consulter les alertes générées directement dans les fichiers textes ou bien utilisé une console de gestion. ACID (Analysis Console for Intrusion Detection), est une application qui fournie une console de gestion et qui permet la visualisation des alertes en mode graphique. Les alertes dans ce cas sont stockées dans une base de données mysql.
Les codes source des scripts
SNORT est une application écrite en C. les programmes sources sont dans le répertoire snort-2.1.0/src/. Le programme snort.c représente la routine principale de SNORT, le décodeur des paquets est implémenté dans le programme decode.c. rules.c est la routine qui s’occupe des règles.
Le moteur de détection est implémenté dans le programme detect.c et Le moteur d’enregistrement est dans log.c.
Il est très utile de consulter le contenu de ces programmes et voir comment SNORT capture les paquets et détecte les attaques.
Prelude NIDS
Le projet de Prelude a commencé en 1998 et avait pour but de créer un outil modulaire de détection d’intrusion réseau composé d’une sonde et d’un Report Server. Lors du Libre Software Meeting 2001, les équipes de Prelude et du projet Trithème (projet indépendant lancé en février 2000) ont décidé de joindre leurs efforts dans le but d’évoluer progressivement vers le développement d’un IDS hybride basé sur la prise en compte de la quasi-totalité des évènements sécurité au niveau réseau (Networkbased IDS) et local (Host-based IDS) grâce à des sondes dédiées.