Databases, Systems & Networks

• le scan simple : aussi appelé le scan connect(), il consiste à établir une connexion TCP complète sur une suite de ports. S’il arrive à se connecter, le port est ouvert ; sinon, il est fermé. Cette méthode de scan est très facilement détectable ;
• le scan furtif : aussi appelé scan SYN, il s’agit d’une amélioration du scan simple. Ce scan essaie également de se connecter sur des ports donnés, mais il n’établit pas complètement la connexion : pas de commande ACK (acquittement) après avoir reçu l’accord de se connecter. Grâce à ceci, la méthode est bien plus furtive que le scan normal ;
• les scans XMAS, NULL et FIN : se basent sur des détails de la RFC du protocole TCP pour déterminer si un port est fermé ou non en fonction de la réaction à certaines requêtes. Ces scans sont moins fiables que le scan SYN, mais ils sont un peu plus furtifs. La différence entre ces trois types de scan se situe au niveau des flags TCP utilisés lors de la requête ;
• le scan à l’aveugle : s’effectue via une machine intermédiaire et avec du spoofing (voir plus bas). Le système attaqué pense que le scan est réalisé par la machine intermédiaire et non par le pirate ;
• le scans passif : est la méthode la plus furtive. Consiste à analyser les champs d’en-tête des paquets (TTL, ToS, MSS…) et à les comparer avec une base de signatures qui pourra déterminer les applications qui ont envoyé ces paquets.

Remarque : l’utilitaire incontournable pour réaliser des scans de ports se nomme Nmap.

• Source routing : technique consistant à placer le chemin de routage directement dans le paquet IP. Cette technique ne fonctionne plus de nos jours, les routeurs rejetant cette option.
• Reroutage : cette technique consiste à envoyer des paquets RIP aux routeurs afin de modifier les tables de routage. Les paquets avec l’adresse spoofée seront ainsi envoyés aux routeurs contrôlés par le pirate et les réponses pourront être également reçues par celui-ci.

• DNS Cache Poisoning : les serveurs DNS possèdent un cache permettant de garder pendant un certain temps la correspondance entre un nom de machine et son adresse IP. Le DNS Cache Poisoning consiste à corrompre ce cache avec de fausses informations. Ces fausses informations sont envoyées lors d’une réponse d’un serveur DNS contrôlé par le pirate à un autre serveur DNS, lors de la demande de l’adresse IP d’un domaine (ex. : www.ledomaine.com). Le cache du serveur ayant demandé les informations est alors corrompu ;
• DNS ID Spoofing : pour communiquer avec une machine, il faut son adresse IP. On peut toutefois avoir son nom, et grâce au protocole DNS, nous pouvons obtenir son adresse IP. Lors d’une requête pour obtenir l’adresse IP à partir d’un nom, un numéro d’identification est placé dans la trame afin que le client et le serveur puissent identifier la requête. L’attaque consiste ici à récupérer ce numéro d’identification (en sniffant le réseau) lors de la communication entre un client et un serveur DNS, puis envoyer des réponses falsifiées au client avant que le serveur DNS lui réponde.

Remarque : une attaque que nous allons voir ci-après, le Déni de Service, peut aider à ralentir le trafic du serveur DNS et ainsi permettre de répondre avant lui.

• Fragments overlapping : quand un message est émis sur un réseau, il est fragmenté en plusieurs paquets IP. Afin de pouvoir reconstruire le message, chaque paquet possède un offset. Le but de l’attaque est de réaliser une demande de connexion et de faire chevaucher des paquets en spécifiant des offsets incorrects. La plupart des filtres analysant les paquets indépendamment, ils ne détectent pas l’attaque. Cependant, lors de la défragmentation, la demande de connexion est bien valide et l’attaque a lieu ;
• Tiny fragments : le but de l’attaque est de fragmenter une demande de connexion sur deux paquets IP : le premier paquet de taille minimum (68 octets selon la RFC du protocole IP) ne contient que l’adresse et le port de destination. Le deuxième paquet contient la demande effective de connexion TCP. Le premier paquet est accepté par les filtres puisqu’il ne contient rien de suspect. Quand le deuxième paquet arrive, certains filtres ne le vérifient pas, pensant que si le premier paquet est inoffensif, le deuxième l’est aussi. Mais lors de la défragmentation sur le système d’exploitation, la connexion s’établit !

De nos jours, une grande majorité des firewalls(2) sont capables de détecter et stopper ce type d’attaques.

• Faux positif : une alerte provenant d’un IDS, mais qui ne correspond pas à une attaque réelle.
• Faux négatif : une intrusion réelle qui n’a pas été détectée par l’IDS

• host-based memory and process protection :surveille l’exécution des processus et les tue s’ils ont l’air dangereux (buffer overflow). Cette technologie est utilisée dans les KIPS (Kernel Intrusion Prevention System) que nous décrivons un peu plus loin ;
• session interception / session sniping : termine une session TCP avec la commande TCP Reset : « RST ». Ceci est utilisé dans les NIPS (Network Intrusion Prevention System) ;
• gateway intrusion detection : si un système NIPS est placé en tant que routeur, il bloque le trafic ; sinon il envoie des messages à d’autres routeurs pour modifier leur liste d’accès.

Un IPS possède de nombreux inconvénients. Le premier est qu’il bloque toute activité qui lui semble suspecte. Or, il est impossible d’assurer une fiabilité à 100 % dans l’identification des attaques. Un IPS peut donc malencontreusement bloquer du trafic inoffensif ! Par exemple, un IPS peut détecter une tentative de déni de service alors qu’il s’agit simplement d’une période chargée en trafic. Les faux positifs sont donc très dangereux pour les IPS. Le deuxième inconvénient est qu’un pirate peut utiliser sa fonctionnalité de blocage pour mettre hors service un système. Prenons l’exemple d’un individu mal intentionné qui attaque un système protégé par un IPS, tout en spoofant son adresse IP. Si l’adresse IP spoofée est celle d’un nœud important du réseau (routeur, service Web…), les conséquences seront catastrophiques. Pour pallier ce problème, de nombreux IPS disposent des « white lists », c’est-à-dire des listes d’adresses réseau qu’il ne faut en aucun cas bloquer. Et enfin, le troisième inconvénient et non le moindre : un IPS est peu discret. En effet, à chaque blocage d’attaque, il montre sa présence. Cela peut paraître anodin, mais si un pirate remarque la présence d’un IPS, il tentera de trouver une faille dans celui-ci afin de réitérer son attaque… mais cette fois en passant inaperçu. Voilà pourquoi les IDS passifs sont souvent préférés aux IPS. Cependant, il est intéressant de noter que plusieurs IDS (ex. : Snort, RealSecure, Dragon…) ont été dotés d’une fonctionnalité de réaction automatique à certains types d’attaques.

• les systèmes à filtrage de paquets sans état : analysent les paquets les uns après les autres, de manière totalement indépendante ;
• les systèmes à maintien d’état (stateful) : vérifient que les paquets appartiennent à une session régulière. Ce type de firewall possède une table d’états où est stocké un suivi de chaque connexion établie, ce qui permet au firewall de prendre des décisions adaptées à la situation.

Ces firewalls peuvent cependant être outrepassés en faisant croire que les paquets appartiennent à une session déjà établie ;

• les firewalls de type proxy : le firewall s’intercale dans la session et analyse l’information afin de vérifier que les échanges protocolaires sont conformes aux normes.

• peu fiable : tout changement dans les habitudes de l’utilisateur provoque une alerte ;
• nécessite une période de non-fonctionnement pour mettre en œuvre les mécanismes d’autoapprentissage : si un pirate attaque pendant ce moment, ses actions seront assimilées à un profil utilisateur, et donc passeront inaperçues lorsque le système de détection sera complètement mis en place ;
• l’établissement du profil doit être souple afin qu’il n’y ait pas trop de fausses alertes : le pirate peut discrètement intervenir pour modifier le profil de l’utilisateur afin d’obtenir après plusieurs jours ou semaines, un profil qui lui permettra de mettre en place son attaque sans qu’elle ne soit détectée.

Plusieurs approches peuvent être utilisées pour la méthode de détection comportementale : Approche probabiliste Des probabilités sont établies permettant de représenter une utilisation courante d’une application ou d’un protocole. Toute activité ne respectant pas le modèle probabiliste provoquera la génération d’une alerte. Exemple : Avec le protocole HTTP, il y a une probabilité de 0.9 qu’une commande GET soit faite après une connexion sur le port 80. Il y a ensuite une probabilité de 0.8 que la réponse à cette commande GET soit « HTTP/1.1 200 OK ». Approche statistique Le but est de quantifier les paramètres liés à l’utilisateur : taux d’occupation de la mémoire, utilisation des processeurs, valeur de la charge réseau, nombre d’accès à l’Intranet par jour, vitesse de frappe au clavier, sites les plus visités… Cette méthode est très difficile à mettre en place. Elle n’est actuellement présente que dans le domaine de la recherche, où les chercheurs utilisent des réseaux neuronaux et le data mining pour tenter d’avoir des résultats convaincants. Autres méthodes D’autres méthodes existent, mais ne sont pas encore répandues. Parmi celles-ci, nous pouvons noter :

• l’utilisation de l’immunologie, c’est-à-dire construire un modèle de comportement normal des services ;
• la présentation d’une activité habituelle sous forme de graphe.

• Pattern Matching algorithmes de recherche de motifs (ex. : Boyer-Moore), algorithmes de comptage, algorithmes génétiques ;
• Analyse Protocolaire conformité aux RFC ;
• Détection d’anomalies méthodes heuristiques ;
• Analyse statistique modèles statistiques ;
• Analyse probabiliste réseaux bayésiens ;
• Autres analyses comportementales réseaux de neurones, systèmes experts + data mining, immunologie, graphes…

Il est bien sûr impossible de détailler chacun des algorithmes mis en œuvre dans les IDS. Nous avons cependant dédié le chapitre 6 aux algorithmes de pattern matching.

• les systèmes et les applications doivent être mises à jour régulièrement (patches de sécurité) ;
• les systèmes utilisant Internet doivent être dans un réseau isolé (DMZ(5)) ;
• chaque utilisateur doit être averti de l’importance de la sécurité de ses mots de passe ;
• les fonctionnalités des services qui ne sont pas utilisées doivent être désactivées.

Lors du déploiement d’un IDS, il faut le configurer correctement : par exemple, si le réseau est sous Windows, les règles destinées à Unix ne sont pas nécessaires. Il faut donc faire une configuration en fonction de l’OS, des applications et du matériel utilisés. L’emplacement du senseur(6) est très important :

• À l’emplacement B, seul le trafic entre les systèmes de la DMZ et Internet est analysé. Le trafic entre le réseau interne et Internet n’est pas analysé. Pour cela, il faudra également placer un senseur au point A.
• À l’emplacement C, le trafic entre Internet et le réseau interne ou la DMZ est analysé. Par contre, le trafic entre le réseau interne et la DMZ est invisible.

Il est impensable de vouloir analyser tout le trafic d’un réseau. Il faut donc donner la priorité aux systèmes à risque : ceux qui offrent des services accessibles par Internet (HTTP, FTP…). De plus, il est souvent préférable de placer le senseur après le firewall du côté interne. Ainsi, seuls les flux acceptés par le firewall sont analysés, ce qui réduit fortement la charge de la sonde IDS. Lors de l’installation d’un NIDS, le choix matériel a également une grande importance. Puisqu’une sonde NIDS doit être capable d’analyser le trafic réseau quel que soit le destinataire, elle devra recevoir elle-même tous les paquets. Pour cela, le NIDS devra jouer le rôle d’un sniffer(7), mais le matériel réseau pose parfois problème :

• un switch simple (commutateur) : en utilisant un tel équipement, la conversation avec l’IDS est impossible du fait de la nature d’un switch : il commute les paquets directement au destinataire. Il est dès lors impossible d’installer une sonde qui analysera le trafic global ;
• un hub (concentrateur) => la conversation avec l’IDS est possible, car les hubs répètent les paquets en les émettant à toutes les machines connectées. Cependant, les hubs sont peu fiables et sont donc à éviter ;
• il existe des switches professionnels qui copient le trafic et l’envoie sur un port spécifié (où sera placé le NIDS) : SPAN port (Switch Port Analyzer). Attention : pour ce port, il faudra utiliser une connexion rapide (ex. : Gigabits) capable d’analyser entièrement le trafic provenant ou à destination des différents sous réseaux.

Un autre problème doit être pris en considération : lorsque les flux sont cryptés (ex. : par SSL, c’est le cas pour les VPN(8)), il est impossible pour l’IDS de décrypter ces flux. Il faut dans ce cas utiliser un proxy SSL comme illustré ci-dessous.

Nous savons donc maintenant que l’emplacement des sondes et le matériel réseau utilisés sont très importants. Cependant, un autre point ne doit pas être oublié : la sécurisation du senseur et des logs d’alerte. En effet, si la sonde elle-même ou si les alertes qu’elles génèrent ne sont pas sécurisées, un pirate pourrait très bien rendre l’IDS complètement inefficace. Pour sécuriser les sondes et les fichiers d’alertes, il est par exemple possible de mettre en place un réseau de management très contrôlé, avec son propre firewall. Ce système sera primordial pour la sécurité du réseau et plusieurs mesures devront être prises pour assurer son fonctionnement :

• le système d’exploitation du senseur devra tenu à jour ;
• un système d’authentification robuste (ex. : PKI) pourra être mis en place pour renforcer la sécurité ;
• tous les mots de passe devront être changés régulièrement ;
• il est également possible d’utiliser deux interfaces réseaux pour le senseur : la première pour générer les alertes et contrôler le trafic, et la deuxième, complètement invisible, en tant que point de monitoring. Ce genre d’interface est communément appelée stealth interface.

• capture de la trame par l’interface en mode promiscuité (promiscous mode) ;
• analyse de la trame et filtrage éventuel en bas niveau ;
• détection de la présence de fragments ou non et passage éventuel à un moteur de reconstruction ;
• transfert de la trame vers le système d’exploitation ;
• filtrage éventuel ;
• applications de divers préprocesseurs en fonction du type de requête afin de contrer des techniques d’évasion d’attaques (voir plus loin) ;
• passage vers le moteur d’analyse (protocole, pattern matching, statistique…).

Pour améliorer les performances de l’IDS, il peut donc être judicieux de répartir les charges. Par exemple, il est envisageable de séparer les flux à analyser en fonction du protocole de niveau 4 : une sonde pour l’analyse des flux Web, une autre pour l’analyse des flux FTP et une analyse des requêtes SQL. Un autre problème est la corrélation des informations provenant de plusieurs types de sondes. Voici les actions à réaliser pour regrouper ces informations :

• agrégation : rassembler les informations des différentes sondes ;
• fusion : fusionner en supprimant les doublons (même attaque détectée par plusieurs sondes) ;
• corrélation : définir un motif commun, c’est-à-dire interpréter une suite d’événements et les résumer.

Une corrélation intéressante serait de ne garder que les alertes qui concernent une faille probable du système. Pour cela il faut utiliser un scanner de vulnérabilités par exemple, ou ne pas afficher les alertes concernant IIS si on possède Apache, ce qui entraînera moins de faux positifs. Néanmoins, l’utilisation d’un scanner de vulnérabilités n’est pas parfaite, car il est difficile d’échanger des informations entre un scanner de vulnérabilités et un IDS. Cependant, depuis peu, des consoles de corrélation entre IDS et scanners de vulnérabilités sont proposées (ex. : Nevo de Tenable Network Security). Enfin, un dernier problème est qu’il n’y a aucune interopérabilité entre les différents IDS du marché, mis à part la possibilité d’exporter les informations dans des formats standard. Pourtant, des normes ont été établies, comme nous allons le voir.

• le pirate génère une série de pings vers l’adresse à tester, puis il mesure et note les temps de réponse ;
• le pirate sature ensuite le réseau en broadcast(9) dans le but de ralentir l’IDS, qui recevra tous les paquets. Enfin, le pirate réémet la même série de pings en mesurant les nouveaux temps de réponse. S’ils sont bien plus élevés que les premiers temps obtenus, il est fort possible que la machine soit en mode promiscous ;

exploiter les mécanismes de réponses actives : les IPS réagissent à certaines attaques (fermer session, bloquer port…), mais en faisant cela, ils laissent souvent des empreintes (header des paquets) permettant d’identifier le type d’IPS ; observation des requêtes DNS : Les IDS génèrent souvent des requêtes DNS lors des alertes. En observant le DNS primaire lors de fausses attaques, on peut détecter qu’il y a un IDS.

• l’IDS les estime inoffensives ;
• la cible ne les décode pas ;

Voici quelques méthodes permettant d’utiliser des techniques d’insertion : – en utilisant la fragmentation IP qui est gérée de manière différente selon l’OS lors de cas anormaux (ex. : recouvrement de paquets) : soit les fragments anciens sont favorisés, soit les nouveaux le sont. Par exemple, il est donc possible que les IDS favorisent les anciens paquets alors que le système d’exploitation utilisé favorise les nouveaux. Pour utiliser le recouvrement de fragments (fragmentation overlap), il faut modifier artificiellement les champs « longueur » et « décalage » (offset) des fragments IP ; – en utilisant l’écrasement de fragments (fragmentation overwrite) : même principe que précédemment, mais des fragments entiers sont remplacés, et non seulement des parties de paquets ; – en utilisant le timeout de fragmentation : les systèmes conservent en général les fragments pendant 60 secondes pour le réassemblage ; mais les IDS les gardent souvent moins longtemps. On peut donc espacer les fragments dans le temps pour ne pas se faire repérer par l’IDS tout en réalisant une attaque complète sur le système d’exploitation ; – découpage de sessions TCP (session splicing) : la requête TCP est divisée en paquets, tout en modifiant le numéro de séquence pour créer des recouvrements : même principe qu’avec la fragmentation IP + possibilité de timeout (Apache Linux : 5 min dans tampon, IIS : 10 min). L’un des outils pour réaliser ce genre d’attaques se nomme fragroute ; – insérer un faux paquet avec checksum erroné : certains IDS ne verront pas l’attaque, car peu d’IDS vérifient le checksum. Le système, par contre, rejettera le paquet erroné. Attention : de nos jours, les routeurs rejettent souvent les paquets erronés ; il faut donc utiliser un autre champ que le checksum, par exemple le TTL.

• libpcap (http://www.tcpdump.org) : offre des fonctions de sniffer
• PCRE (http://www.pcre.org) : permet d’utiliser des expressions régulières de type Perl

La compilation de ces bibliothèques se fait très aisément : ./configure, make, make install. 3. Ouvrir un terminal, décompresser ensuite l’archive de Snort et se placer dans le répertoire des sources décompressées. 4. Configurer la compilation de Snort afin d’activer plusieurs fonctionnalités : ./configure [options]. Deux options nous ont semblé intéressantes :

• –with-mysql=DIR : activer le support de MySQL. Ainsi Snort enregistrera les alertes dans une base de données accessible par d’autres applications (ex. : BASE, décrite plus loin). MySQL n’est bien sûr pas l’unique SGBD supporté.

PostgreSQL ou Oracle peuvent également être utilisés avec les options -withpostgresql et –with-oracle.

• –enable-flexresp : activer les réponses flexibles en cas de tentatives de connexion hostile. Pour activer cette option, la bibliothèque libnet (http://www.packetfactory.net/libnet) est nécessaire.

5. Compiler les sources : make. 6. Installer Snort : make install en mode root. 7. Pour que Snort puisse fonctionner en mode détection/prévention d’intrusions, il est nécessaire de lui fournir des fichiers de règles. Le site de Snort propose deux types de règles : les règles officielles et les règles créées par la communauté. Certaines règles officielles ne sont disponibles que pour les utilisateurs enregistrés, tandis que les règles communautaires sont disponibles à tous et mises à jour régulièrement. Il est cependant important de noter que les règles proposées par la communauté n’ont pas été forcément testées par l’équipe officielle de Snort. Après téléchargement, l’archive des règles doit être décompressée. Il est conseillé de placer le répertoire rules dans le dossier de Snort. Nous pouvons remarquer que les règles consistent en de simples fichiers textes, et qu’un fichier un peu spécial est présent : snort.conf. Ce dernier va nous permettre de configurer Snort.

• la variable HOME_NET permet de spécifier quels réseaux ou quelles interfaces seront surveillés par Snort. La valeur any signale à Snort de surveiller tout le trafic ;
• si le réseau à surveiller possède des serveurs DNS, SMTP, FTP, etc., il est possible de spécifier les adresses IP de ces serveurs via les variables DNS_SERVERS, SMTP_SERVERS… Si le réseau ne possède pas un type spécifique de serveur, il est conseillé de commenter (avec le caractère #) la ligne concernée, afin d’optimiser le traitement de Snort. En effet, il est inutile d’analyser du trafic HTTP si aucun serveur Web n’est disponible ;
• certains ports de services peuvent être configurés via des variables telles que HTTP_PORTS ou ORACLE_PORTS.
• la variable RULE_PATH est très importante. Elle permet de spécifier le répertoire où sont stockés les fichiers de règles de Snort.
• les directives include permettent d’inclure des fichiers de règles. Ici encore, il est conseillé de n’inclure que les règles nécessaires en fonction des services disponibles sur le réseau.

• -A : générer des alertes. Activé par défaut avec l’option -c
• -c <emplacement de snort.conf> : lancer Snort avec des fichiers de règles.
• -l <répertoire de log> : spécifier le répertoire où les logs d’alertes seront stockés (défaut : /var/log/snort)
• -v : mode verbose. Permet d’afficher les paquets capturés
• -T : mode test. Permet de tester la configuration de Snort

Avant de lancer Snort en mode NIDS, il est préférable de tester si le programme arrive à récupérer les paquets qui circulent sur le réseau. Pour cela, nous pouvons par exemple lancer Snort en simple mode Sniffer : snort -v. Si aucun paquet n’est capturé et affiché, il est probable que Snort n’écoute pas sur la bonne interface. L’option -i permet de spécifier une autre interface. Lançons maintenant Snort en mode NIDS. Pour cela, nous lui précisons l’emplacement du fichier de configuration avec l’option -c : snort -c /opt/snort/rules/snort.conf Toutes les alertes détectées sont ainsi stockées dans le fichier /var/log/snort/alert. Pour chaque alerte, Snort donne une priorité, une description, les flags des paquets et éventuellement des adresses sur Internet où se trouvent de plus amples informations sur la tentative d’intrusion. Exemple :

[**] [1:1384:8] MISC UPnP malformed advertisement [**]
[Classification: Misc Attack] [Priority: 2]
03/25-17:34:49.251861 192.168.0.1:1900 ->
239.255.255.250:1900
UDP TTL:1 TOS:0x0 ID:37277 IpLen:20 DgmLen:437
Len: 409
[Xref =>

059.mspx][Xref => http://cve.mitre.org/cgibin/
cvename.cgi?name=2001-0877][Xref =>

0876][Xref => http://www.securityfocus.com/bid/3723]

Le champ action peut prendre les valeurs suivantes :

• alert : générer une alerte + logger le paquet
• log : logger le paquet
• pass : ignorer le paquet
• activate : activer une règle dynamique
• dynamic : définir une règle dynamique, qui est passive tant qu’elle n’est pas activée par une autre règle
• drop : demander à iptables(10) de bloquer le paquet, puis le logger
• reject : demander à iptables de bloquer le paquet, puis le logger, et envoyer une commande TCP RST (reset) ou une réponse ICMP Host unreachable
• sdrop : demander à iptables de bloquer le paquet. Ce dernier n’est pas loggé.

Le champ protocole spécifie le protocole pour lequel la règle s’applique. Les valeurs possibles sont : tcp, udp, icmp ou ip. Les champs adresse1 et adresse2 indiquent l’adresse IP source et destination du paquet. Le mot-clé any permet de spécifier une adresse quelconque. Les adresses doivent être numériques, les adresses symboliques ne sont pas acceptées. Les champs port1 / port2 spécifient les numéros de port utilisés par la source et la destination. Le mot-clé any permet de spécifier un port quelconque. Des noms de services peuvent être utilisés : tcp, telnet… De même des plages de ports peuvent être spécifiées avec le caractère « : ». Le champ direction spécifie l’orientation du paquet. Cet opérateur peut prendre deux valeurs : -> : adresse1 vers adresse2 <> : de adresse1 vers adresse2, ou de adresse2 à adresse1 Notons qu’il n’y a pas d’opérateur <- . La partie Options des règles contient différentes options, séparées par un point-virgule, qui vont permettre de préciser des critères de détection. Pour chaque option, le format est nomOption : valeur1[, valeur2…] Voici les options importantes :

• msg : spécifier le message qui sera affiché dans le log et dans l’alerte
• reference : faire référence à un site expliquant l’attaque détectée
• classtype : définir la classe de l’attaque (troyen, shellcode…)
• priority : définir la sévérité de l’attaque
• content : spécifier une chaîne de caractères qui doit être présente dans le paquet pour déclencher l’action de la règle
• rawbytes : spécifier une suite d’octets qui doit être présente dans le paquet pour déclencher l’action de la règle
• uricontent : identique à content, mais est adapté au format normalisé des URI (ex. : hexadécimal accepté)
• pcre : utiliser une expression régulière compatible Perl pour spécifier le contenu du paquet
• ttl : spécifier la valeur du TTL du paquet
• flags : spécifier la présence d’un flag TCP dans le paquet (ex. : SYN, FIN…)
• fragbits : vérifier la présence de certains bits IP (more fragments, don’t fragment ou bit réservé)
• session : extraire toutes les informations de la session TCP à laquelle le paquet suspect appartient
• resp : activer une réponse flexible (flexresp) afin de bloquer l’attaque. Il est ainsi possible d’envoyer une commande TCP ou ICMP précise. Cette option nécessite l’activation du mode flexresp lors de la compilation de Snort.
• limit : limiter le nombre d’actions pendant un intervalle de temps pour le même événement.

Exemple de règle :

alert tcp any any -> $HTTP_SERVERS $HTTP_PORTS (msg:"WEBATTACKS
/bin/ls command attempt"; uricontent:"/bin/ls";
nocase; classtype:web-application-attack;)

Cette règle permet de générer une alerte quand un paquet provient d’un couple (adresse:port) quelconque, est à destination des serveurs HTTP définis dans snort.conf, et contient la chaîne « /bin/ls » dans l’URI. Le message de l’alerte sera « WEB-ATTACKS /bin/ls command attempt ». Cette attaque sera classée dans la classe web-application-attack (priorité medium par défaut). Il est bien sûr impossible d’être exhaustif ici pour décrire le format des règles Snort. Le manuel utilisateur disponible sur le site officiel indique comment utiliser aux mieux le langage des signatures de Snort.

• un SGBD installé, par exemple MySQL
• Snort compilé avec le support de ce SGBD
• un serveur HTTP, par exemple Apache
• l’interpréteur PHP avec les supports pour le SGBD choisi, la bibliothèque GD et les sockets.
• La bibliothèque ADODB : http://adodb.sourceforge.net

Nous ne détaillerons pas ici l’installation de chaque dépendance. La documentation livrée avec les sources de BASE (disponibles sur http://secureideas.sourceforge.net) fournit les informations nécessaires. Notons cependant que l’archive des sources de Snort dispose également d’un dossier schemas contenant le code SQL pour créer la structure de la base de données pour différents SGBD. Le fichier doc/README.database donne toutes les indications pour créer le schéma de la base de données. Afin que Snort enregistre les alertes dans la base de données, il ne faut pas oublier de modifier le fichier snort.conf et rajouter une ligne output database avec les informations pour se connecter à la base de données. Exemple :

output database: log, mysql, user=snortusr password=pwd
dbname=snort host=localhost

Après configuration et installation de BASE ainsi que de toutes ses dépendances, nous pouvons y accéder avec un navigateur internet. Si tout se passe bien, un écran similaire à l’illustration suivante est obtenu :

• un langage de script propre à Bro permettant d’écrire les règles de détection et d’action ;
• l’utilisation des expressions régulières pour exprimer les motifs des signatures ;
• la possibilité d’exécuter des programmes tiers après détection d’intrusion permet de réaliser de nombreux types d’actions ;
• une compatibilité avec les règles de Snort, grâce à un convertisseur nommé snort2bro ;
• la possibilité d’utiliser GnuPG (Gnu Privacy Gard) pour crypter et signer les rapports d’alertes. Cela permet d’empêcher l’espionnage ou la falsification des logs par un pirate ;
• l’envoi d’un rapport périodique des alertes par mail.

L’architecture de Bro est définie en trois couches principales :

• le module Packet Capture : chargé d’écouter le trafic en mode sniffer et de transmettre tous les paquets à la couche supérieure ;
• le module Event Engine : classe les flux par protocole, crée une table d’états pour les connexions, contrôle l’intégrité (checksum), réassemble les fragments et analyse les flux. Ce module génère des événements qu’il transmet à la troisième couche ;
• le module Policy Layer : utilise les scripts écrits dans le langage de Bro pour traiter les événements.

• alarm.XXX : les attaques détectées
• conn.XXX : un résumé des connexions établies
• ftp.XXX : des informations concernant le trafic FTP suspect
• HTTP.XXX : des informations concernant le trafic HTTP suspect
• info.XXX : des informations générales
• notice.XXX : un suivi des événements lancés

• conditions d’en-tête : elles permettent de spécifier le protocole, les ports et les adresses source et de destination ;
• conditions de contenu : elles sont exprimées sous forme d’expressions régulières pour reconnaître le contenu de certains types de requêtes ;
• conditions de dépendance : elles permettent d’exprimer des dépendances entre les signatures. Par exemple, une signature ne doit être détectée que si une autre signature l’a été ;
• conditions de contexte : elles permettent de rajouter l’exécution de certaines fonctions, écrites avec le langage de script de Bro, qui complémenteront les autres conditions.

Comme nous pouvons le voir, les conditions de détection de signatures sont très évoluées. Cependant, ce n’est pas le cas des actions, c’est-à-dire les opérations à réaliser quand une signature est détectée. Il n’existe pour l’instant qu’une seule action possible : event. Celle-ci va permettre de décrire l’éventuelle attaque qui a été détectée. Enfin, rappelons l’existence de snort2bro qui permet de convertir des règles écrites pour Snort dans le format de Bro. Ainsi, un utilisateur préférant la syntaxe de Snort ou utilisant ces deux NIDS, pourra très facilement réutiliser ses règles Snort avec Bro.

• Global : contient les paramètres d’alertes par email ;
• Rules : indique les différents fichiers contenant les règles de détection ;
• Syscheck : spécifie les répertoires à scanner et les fichiers à ignorer ;
• Rootcheck : contient les paramètres de détection des rootkits. Les fichiers contenant les signatures doivent être spécifiés ;
• Active-response : active/désactive la réponse active ;
• Alerts : spécifie le niveau d’alerte pour avertir par email l’administrateur ;
• Localfiles : contient tous les fichiers de logs à vérifier (une entrée par fichier).

<group name="syslog,attacks">
...
<rule id="1608" level="14" timeframe="120">
<if_matched_regex>^sshd[\d+]: \.+Corrupted check by bytes
on</if_matched_regex>
<regex>^sshd[\d+]: fatal: Local: crc32 compensation
attack</regex>
<description>SSH CRC-32 Compensation attack</description>
<cve>2001-0144</cve>
<info>http://www.securityfocus.com/bid/2347/info/</info>
</rule>
...
</group>

Cette règle est caractérisée par un identifiant unique (chaque règle possède un identifiant propre), un niveau de sécurité allant de 0 à 16 (ici 14) et une fréquence d’apparition (timeframe). Cette fréquence d’apparition permet de déclencher une règle uniquement si une règle précédente a déjà été levée. La règle précédente est spécifiée à l’aide de la baliseif_matched_regex. Cette dernière option de répétition est bien sur optionnelle. Plusieurs options de concordance sont possibles. Ici regex spécifie qu’il s’agit d’une expression régulière à trouver dans la chaîne. Toutefois, il existe l’option match qui spécifie une sous-chaîne à trouver dans la chaîne. La balise description permet de donner une courte description de la règle ; cve la date de découverte de la faille et enfin info permet de spécifier une information supplémentaire sur la règle, par exemple l’URL qui référence l’exploit connu. Plus d’informations sont disponibles dans la documentation sur le site officiel d’OSSEC.

./configure --enable-network=server --enable-xml-log --
with-database=mysql --prefix=/usr/local/yule
make
make install

Le serveur (se nommant yule) va ici être installé dans /usr/local/yule. Effectuons à présent l’installation du client :

./configure --prefix=/usr/local/samhain --enable-xml-log -
-enable-network=client \
--with-datafile=
REQ_FROM_SERVER/var/lib/samhain/samhain_file \
--with-config-file=REQ_FROM_SERVER/etc/samhainrc \
--with-logserver=server.yourdomain.com
make

La variable REQ_FROM_SERVER indique que ce fichier doit être récupéré du serveur. Logserver spécifie l’adresse où se trouve le serveur regroupant toutes les alertes, c’est-à-dire l’adresse à laquelle le client samhain enverra les alertes. Cette installation n’est toutefois pas terminée, puisqu’avant d’effectuer la dernière phase, il faut configurer le client pour qu’il puisse s’authentifier au niveau du serveur. Générons une clé aléatoire sur le serveur :

yule -P $SHPW | sed s%HOSTNAME%client.yourdomain.com% >>
/etc/yulerc

Indiquons cette clé à notre client :

./samhain_setpwd samhain new $SHPW

Cette opération a pour but de créer un nouveau binaire se nommant samhain_new, qui nous permettra de nous connecter avec le serveur. Terminons l’installation avec ces lignes :

mv samhain.new samhain
make install && make install-boot
samhain -t init

/usr/local/bin/rkhunter -c -sk

Voici un exemple de résultat :

Networking
* Check: frequently used backdoors
Port 2001: Scalper Rootkit [ OK ]
Port 2006: CB Rootkit [ OK ]
Port 2128: MRK [ OK ]
Port 14856: Optic Kit (Tux) [ OK ]
Port 47107: T0rn Rootkit [ OK ]
Port 60922: zaRwT.KiT [ OK ]
* Interfaces
Scanning for promiscuous interfaces [ OK ]
Security advisories
* Check: Groups and Accounts
Searching for /etc/passwd... [ Found ]
Checking users with UID '0' (root)... [ OK ]
* Check: SSH
Searching for sshd_config...
* Check: Events and Logging
Search for syslog configuration... [ OK ]
Checking for running syslog slave... [ OK ]
Checking for logging to remote system... [ OK (no remote
logging) ]
------------------ Scan results --------------------
MD5
MD5 compared: 0
Incorrect MD5 checksums: 0
File scan
Scanned files: 342
Possible infected files: 0
Application scan
Vulnerable applications: 0
Scanning took 62 seconds