SIEM/IDS : l'union fait-elle la force ?

Prérequis

La meilleure démonstration étant la pratique, nous allons mettre plusieurs IDS face à une attaque simple constituant encore malheureusement une menace dans bon nombre d'applications Web : le Path Traversal, accompagné d'une LFI (ou Local File Inclusion). Cette attaque consiste à accéder à des fichiers situés en dehors du répertoire de l'application Web (typiquement, le fichier /etc/passwd sur des systèmes UNIX), et à les renvoyer au client (dans la page Web de réponse).

Pour cela, nous allons mettre en place deux niveaux de détection : au niveau réseau avec Snort, puis au niveau du système au moyen d'OSSEC. Enfin, nous tenterons de corréler les alertes de ces outils avec le SIEM open source OSSIM.

La solution présentée ici utilise uniquement des logiciels libres. Afin d'alléger l'article et d'éviter les redites par rapport à d'autres écrits, nous ne détaillerons pas les étapes d'installation et de configuration de chacun de ces outils, mais simplement les parties de configuration indispensables à l'article.

Pour se familiariser avec le fonctionnement d'OSSIM, deux articles ont déjà été publiés dans les [MISC 62] et [MISC 63]. Afin d'avoir un environnement de test complet, nous avons donc installé la dernière version d'OSSIM [OSSIM]. Il s'agit d'une distribution GNU/Linux basée sur Debian Squeeze qui intègre par défaut le SIEM OSSIM et une grande collection de [H/N]IDS. Par souci de simplicité, l'agent et le serveur OSSIM seront ici présents sur la même machine. Les autres services (Snort, OSSEC) seront également installés sur ce serveur. Le serveur Web Apache, quant à lui, sera mis en fonction sur une deuxième machine.

Nous voulons détecter des attaques de type Path Traversal sur des applications Web. Ici, nous avons choisi l'application Webgrind, qui permet de faire du profilage de code PHP [1]. Afin de disposer d'une version vulnérable à des failles de type Path Traversal, nous utiliserons la version 1.0 disponible sur Internet [WEBGRIND]. Cet outil tourne sur le serveur Web Apache.

1. Détection d'attaque ciblée : analyse d'empreinte réseau

1.1 NIDS : la surveillance du réseau

Le premier niveau de détection possible est la détection de motifs sur le réseau, effectuée par des Network-Based IDS. Ces NIDS écoutent le trafic réseau et lèvent des alertes dès qu'un ou plusieurs paquets réseaux correspondent à des règles définies dans la configuration de l'IDS. Plusieurs systèmes de détection d'intrusions basés sur le réseau existent, comme Snort, Suricata, ou encore Bro. Nous avons choisi ici de nous pencher sur Snort, un NIDS distribué sous licence GNU/GPL [SNORT].

Les règles des IDS sont généralement simples et contiennent soit un motif complet et précis qu'il faudra trouver dans le paquet (typiquement, un payload applicatif détectable), soit un motif plus générique, que l'on écrira souvent sous la forme d'une expression régulière. La deuxième possibilité a un inconvénient majeur : le temps d’exécution et les ressources consommées par l'IDS qui peuvent être très élevées pour détecter des motifs complexes. Nous allons donc ici utiliser la détection d'un motif bien défini : la charge applicative liée à l'exploitation d'une faille connue sur une application Web.

Comme indiqué dans la première partie de cet article, nous allons ici exploiter une vulnérabilité de type Path Traversal/LFI dans l'outil Webgrind (en version 1.0), référencée par la CVE-2012-1790 [CVE-2012-1790]. Cette CVE a été choisie pour sa simplicité d'exploitation. Il suffit d'insérer dans l’URI le nom du fichier que l'on souhaite lire pour qu'il soit affiché en réponse. Aucune authentification ni autre modification n'est nécessaire. L'URI complète d'exploitation de la faille est la suivante : /index.php?file=/etc/passwd&op=fileviewer.

1.2 La détection avec Snort

Comme expliqué plus haut, Snort se base sur une liste de règles pour déterminer si un paquet transitant sur le réseau est légitime ou non. En fonction de la règle, il pourra alors dropper le paquet, lever une alerte ou par exemple envoyer un paquet TCP RESET (plus d'informations sur les règles Snort sont disponibles dans la documentation officielle (page 173 et suivantes [DOC SNORT]).

Basiquement, une règle Snort va simplement contenir un motif qui devra être contenu dans le paquet analysé. On pourra ensuite affiner les règles en ajoutant des filtres supplémentaires, par exemple sur le sens de la communication (client vers serveur, ou serveur vers client), sur l'endroit où le contenu est situé dans le paquet (par exemple dans l’URI HTTP, dans le contenu HTTP, etc.), et même sur des valeurs de l'entête des datagrammes IP (champ ID, TTL) ou sur les flags TCP.

Dans le cas de la détection de l'exploit sur la faille étudiée ici, on va créer une règle Snort qui va filtrer les paquets :

- émis en TCP ;

- depuis n'importe quelle machine, vers la machine identifiée par l'adresse IP $SERV_IP_TEST vers un des ports $HTTP_PORTS ;

- à destination du serveur ;

- qui possèdent l’URI HTTP donnée plus haut.

La règle Snort pourra donc être la suivante :

Dans les principaux cas d'utilisation, Snort est lancé en tant que daemon sur le serveur et stocke dans un fichier Pcap les paquets qui lèvent des alertes. Pour tester ses règles, on peut lancer Snort directement en ligne de commandes en lui demandant d'afficher les alertes dans la console. Ainsi, en accédant à l’URI d'exploitation de la vulnérabilité, on obtiendra ce qui suit  :

1.3 Et si les flux sont chiffrés ?!

Aujourd'hui, beaucoup de sites web sont accessibles via le protocole HTTPS, permettant le chiffrement des flux entre le client et le serveur. Dans cette situation, la sonde Snort qui recevra le trafic ne pourra pas déchiffrer les données envoyées, et il sera impossible de les analyser. Est-ce vraiment le cas ?

Dans la pratique, il est envisageable de procéder à l'analyse des flux chiffrés transitant sur notre réseau. Nous allons ici proposer deux solutions simples à mettre en place.

La première solution est la mise en place d'un Reverse Proxy en entrée du réseau. C'est ce proxy qui effectue toutes les étapes de chiffrement avec le client, puis l'intégralité du trafic entre ce proxy et le serveur Web est envoyée en clair. La sonde Snort peut alors être placée n'importe où entre ces deux machines pour analyser le trafic.

Dans beaucoup d'architectures, la sonde Snort n'est pas placée en coupure du réseau (configuration de type Man-in-the-Middle), mais plutôt en parallèle du réseau, recevant tout le trafic à destination des systèmes ou environnements que l'on souhaite surveiller (cette mise en place est généralement effectuée au moyen de Port Mirroring ou de TAP réseau [TAP]). Dans cette situation, la sonde reçoit la totalité du trafic, mais toujours chiffré (du fait de la réplication). Il est possible de permettre au serveur Snort de déchiffrer lui-même les données reçues en utilisant la clé privée du serveur Web. Ce genre de configuration est possible et sans dégradation du niveau de sécurité puisque les deux hôtes font partie du même domaine de confiance (la sonde Snort devient alors un asset critique au même titre que le(s) serveur(s) Web pour lesquels elle dispose des clés de chiffrement SSL).

1.4 Avantages et inconvénients des solutions NIDS

Les solutions de détection d'intrusions basées sur le réseau ont un avantage majeur : les informations reçues sont extrêmement précises et obtenues en temps réel. Elles présentent cependant un certain nombre d'inconvénients.

Tout d'abord, les règles doivent être maintenues à jour au fil des publications des vulnérabilités et exploits pour assurer un bon niveau de détection. À l'inverse, faire le choix de règles trop génériques pourra conduire à une quantité de faux positifs beaucoup trop importante. Un autre inconvénient est la quantité d'événements remontés par Snort, qui rend le traitement et l'exploitation de ceux-ci très lourds et complexes (par exemple lors d'attaques par force brute ou bien lors de la supervision de flux importants à fort trafic). Enfin, il faudra garder à l'esprit lors de la mise en place d'une telle solution que la surveillance des flux chiffrés ne sera pas triviale et nécessitera quelques étapes de configuration supplémentaires.

Enfin, bien que cette technique de détection permette de connaître l'origine de l'attaque (adresse IP et port sources) ainsi que la charge envoyée au serveur, elle n'apporte aucune information sur la réussite ou non de l'attaque. La quantité d'informations reçues ainsi que leur format de stockage rendent de fait encore plus difficile leur exploitation par des équipes opérationnelles.

2. Un PRISM dans votre système GNU/Linux

2.1 HIDS : le monitoring au niveau système

Les IDS ne sont pas cantonnés à la surveillance du réseau. Ils peuvent aussi très bien être utilisés pour monitorer des actions au niveau de l'OS. Ici, nous allons utiliser l'HIDS (Host-Based IDS) OSSEC, qui a l'avantage d'être porté sur la plupart des systèmes UNIX et Microsoft Windows, ce qui permet une meilleure intégration en entreprise. OSSEC se base sur des fichiers de logs tiers à partir desquels il va extraire des informations et, le cas échéant, notifier des alertes.

Le second outil que nous utiliserons est Audit, un daemon GNU/Linux permettant de surveiller les accès à des fichiers ou répertoires du système. OSSEC va remonter des alarmes à partir de ces logs.

L'utilisation d'un HIDS va nous permettre de généraliser la détection des attaques. Au lieu de détecter un payload applicatif spécifique à une vulnérabilité, nous cherchons ici à être alertés dès que l'utilisateur www-data (qui lance les services Web par défaut sur les OS GNU/Linux) tente d'accéder à des fichiers sensibles (typiquement tous les fichiers en dehors de la racine des sites web ; dans notre cas, nous nous concentrerons sur /etc/passwd).

2.2 Audit et www-data

Comme indiqué plus haut, Audit permet de surveiller les accès à des fichiers ou répertoires présents sur le serveur. La configuration est très simple, et dans notre cas, il suffit de préciser pour quels fichiers et quels types d'accès nous voulons obtenir des logs. On rajoute donc ici une ligne de configuration et on redémarre le serveur. Des détails sur l'installation et la configuration d'Audit sont disponibles dans la documentation d'openSUSE [AUDIT].

On se retrouve de cette manière avec des logs dès que l'utilisateur www-data accède en lecture ou écriture au fichier /etc/passwd.

2.3 OSSEC et parsing de logs

OSSEC, tout comme Audit, est un HIDS, bien que leurs fonctionnements diffèrent. OSSEC est basé sur une architecture client-serveur. Le client surveille des journaux d'événements ou des résultats de commandes système, puis envoie toute nouvelle activité au serveur qui va les analyser et lever (ou non) des alertes. La procédure d'installation est détaillée sur le site d'OSSEC [OSSEC]. La configuration se déroule ensuite en deux étapes : la configuration de l'agent, puis celle du serveur.

2.3.1 Agent OSSEC

La configuration de l'agent OSSEC est très simple. Il suffit simplement de préciser l'emplacement du fichier de logs à surveiller, et d'indiquer qu'il faut les envoyer au serveur par paquets de 3 lignes (les logs Audit sont sur 3 lignes).

2.3.2 Serveur OSSEC

La configuration du serveur est légèrement plus complexe puisqu'elle nécessite de créer dans OSSEC un décodeur pour parser les logs, puis des règles pour les filtrer et choisir quand lever des alertes.

2.3.2.1 Décodeur

Les décodeurs OSSEC sont stockés dans des fichiers XML, et chaque entrée de ce fichier est un nouveau décodeur. Chaque décodeur se compose d'un champ prematch (qui indique une valeur que le log doit contenir avant d'être traité plus en détail), puis une expression régulière qui permet d'extraire des valeurs du log, pour les placer ensuite dans des variables internes à OSSEC. Lorsqu'OSSEC reçoit des logs au format multiline, il les regroupe sur une seule ligne pour faciliter le traitement dans les regex.

Dans le log reçu, on cherche à extraire l'UID de l'utilisateur, la commande lancée, le fichier sur lequel on lance la commande et le succès (ou non) de la commande. Cela correspond aux champs suivants dans le journal d’événements :

Le décodeur du serveur OSSEC est donc le suivant :

Après l'écriture des règles OSSEC adéquates, on observe dans les journaux d'événements d'OSSEC que les alertes sont bien levées :

2.4 Avantages et inconvénients d'un HIDS

Nous n'avons dans cet article présenté que les HIDS Audit et OSSEC sur des points très précis. On peut cependant en tirer quelques conclusions sur les points positifs et négatifs de ces Host-Based IDS. Ils ont l'avantage d'être présents directement sur le système d'exploitation et sont généralement très modulaires en s'appuyant sur d'autres outils, comme Audit. On peut donc obtenir des informations précises sur les actions lancées, et ainsi détecter si une attaque est réussie ou non. Toutefois, ces techniques ne donnent aucun renseignement sur l'origine de l'attaque. En effet, la seule donnée contenue dans les logs d'Audit est le hostname de la machine hôte de l'agent OSSEC et l'utilisateur lançant la commande.

Les alertes levées par les HIDS sont donc elles aussi très importantes dans le processus de détection, mais sont difficilement exploitables seules en production.

3. « One SIEM to bind them all »

3.1 OSSIM

Comme nous l'avons vu dans les deux exemples précédents, on a principalement accès à deux types d'IDS : des IDS réseaux et des IDS systèmes. Chacun d'entre eux a des points positifs comme des points négatifs. Les IDS réseaux permettent d'obtenir des informations précises quant à la source des attaques, alors qu'un IDS installé sur le système attaqué permettra d'avoir connaissance des actions lancées sur le système et de déterminer si l'attaque a réussi ou non. C'est dans cette optique que l'on souhaite mettre en place un SIEM, afin de pouvoir corréler les événements des deux systèmes de détection d'intrusions et ainsi remonter des alertes plus précises et diminuer le nombre de faux positifs.

Un SIEM (ou Security Information and Event Management) permet de « gérer les événements du Système d'Information » [WIKIPEDIA], en particulier les événements de sécurité. Le SIEM collecte des événements de plusieurs sources réparties sur le SI, puis va normaliser ces données, avant de pouvoir les confronter et les corréler. En règle générale, un SIEM peut aussi inclure des fonctionnalités de reporting, intégrer des dashboards, ainsi que stocker les logs de façon centralisée à des fins juridiques ou inforensiques.

Nous utilisons ici la solution SIEM Open Source OSSIM, en version 4.2, qui a l'avantage d'être livrée par défaut avec toute la configuration requise nécessaire de Snort et OSSEC.

Parmi toutes les fonctionnalités proposées par OSSIM, nous n'allons en utiliser qu'une : la corrélation d'alertes. Cette technique permet de créer de nouvelles alertes, de plus haut niveau, mais aussi de meilleures qualité et précision, en se basant sur des alertes de plus bas niveau levées par des IDS ou, plus généralement, par des agents du SIEM. Nous vous proposons en figure 2 le schéma d'une architecture OSSIM basée sur des événements OSSEC, Snort et ssh. Chaque agent OSSIM normalise les logs reçus de différentes sources dans un format commun, puis les transmet au serveur, qui les analyse puis effectue les étapes de corrélation et d'alarming. Deux articles présentant de façon plus précise et complète OSSIM sont disponibles dans les numéros 62 et 63 de MISC ([MISC 62] et [MISC 63]).

3.2 Corrélation des alertes

Le SIEM reçoit désormais les deux alertes dès que l'attaque est lancée sur l'application Webgrind.

Afin de les corréler, nous allons utiliser une directive de corrélation. La directive permet de modifier la criticité des alertes remontées par OSSIM suivant les événements remontés (ou non) par les différents IDS. Dans notre exemple, on augmentera la criticité de l'alerte si suite à l'exploitation de la LFI, l'utilisateur www-data tente sans succès d'accéder au fichier /etc/passwd. Si cet accès réussit, la criticité est élevée à un niveau plus important.

L'écriture d'une directive de corrélation ayant déjà été détaillée dans l'article publié dans MISC 63, nous ne détaillerons pas cette partie ici [MISC 63]. Notre directive de corrélation est donnée en figure 5.

4. Peut-on aller plus loin ? Quelques scénarios plus évolués...

Nous avons choisi dans cet article d'utiliser un scénario d'attaque simple dans son exploitation et sa détection : une attaque par Path Traversal/LFI. Celle-ci se compose simplement d'une requête HTTP, et bien qu'illustrant l'utilité de la corrélation, ne fait qu’effleurer les possibilités de détection offertes par un SIEM. On peut envisager des schémas de supervision plus avancés ; prenons donc quelques exemples de scénarios rencontrés « in the wild ».

4.1 Détection généralisée d'attaques

Il est possible de détecter des attaques plus complexes au moyen d'IDS et de SIEM, notamment les phases de reconnaissance du serveur (que l’attaquant réalisera au moyen d'outils du type nmap afin d'obtenir la liste des services ouverts), puis les tentatives d’intrusion sur le service ssh (bruteforce et exploitation d’une ancienne vulnérabilité)(ou sur tout autre service, comme présenté précédemment pour un serveur Web) au moyen de Snort (on partira du postulat que l'adresse IP source est toujours la même au cours des différentes phases de l’attaque et que celle-ci se déroule durant une plage de temps restreinte). On vérifie ensuite la réussite de l'attaque au moyen des logs ssh gérés par OSSIM en vérifiant les authentifications réussies au moment de l’attaque depuis l'adresse IP utilisée lors de l'attaque.

Il est également possible de détecter les étapes suivantes de l'attaque ou des points plus avancés, comme le lancement de certaines commandes sur le serveur, l'ouverture ou non de flux réseau vers l'Internet, etc.

4.1 Surveillance avancée de l'authentification

Un des challenges de la sécurité est de s'assurer que personne ne se connecte aux postes de travail sans être physiquement présent sur la machine (présence potentielle de malware), en particulier sur des périmètres sensibles. On peut utiliser pour cela OSSEC, afin de lever des alertes à chaque connexion d'un utilisateur sur chaque poste. Un accès aux bureaux par badge permettra de vérifier si l'utilisateur est présent ou non, et donc de lever une alerte s'il se connecte sans avoir « badgé » préalablement à l'entrée du bureau.

Conclusion

On a donc montré dans cet article qu'il existe un très grand nombre d'outils permettant de monitorer en temps réel la sécurité d'un SI. Ces IDS sont généralement dédiés à un usage particulier (Snort pour le réseau, Audit pour les accès aux fichiers sur GNU/Linux, etc.), et remontent des alertes très précises sur les activités en cours. Cependant, ces informations peuvent être générées en trop grand nombre (cas de Snort lors d'une attaque par force brute, qui remontera une alerte pour chaque tentative) et peu facilement exploitables pour réaliser un monitoring efficient.

On remarque que, malgré cet inconvénient, dans leur ensemble toutes ces informations sont particulièrement intéressantes, puisqu'elles apportent une vision globale de la situation. C'est dans cette optique que l'utilisation d'un SIEM est précieuse, puisque ses capacités de corrélation des alertes permettent de n'extraire que les informations essentielles issues des différentes sources de données et de les sublimer pour obtenir une information concentrée beaucoup plus pertinente.

Il devient donc important, pour que le SIEM émette des alertes pertinentes, de définir en amont des scénarios d'attaques précis, de disposer d'une grande variété d'outils de monitoring au sein du SIEM afin d'obtenir des informations précises, ciblées et pertinentes. Il sera alors possible, de cette façon d'utiliser au maximum toutes les fonctionnalités des différents outils et de disposer d'une vision plus haut niveau sur l'état de la sécurité du SI, facilitant ainsi de fait la détection des attaques et leur résolution par les équipes opérationnelles.

Références

[MISC 62] Misc 62 - « Open Source Security Information Management (OSSIM) - Partie 1 » - Lionel Prat

[MISC 63] Misc 63 - « Open Source Security Information Management (OSSIM) - Partie 2 » - Lionel Prat

[OSSIM] http://communities.alienvault.com/

[1] Le choix de l'outil est sans intérêt dans le cadre de cet article, et utiliser WordPress ou SPIP au lieu de Webgrind ne changerait pas le comportement des outils présentés.

[WEBGRIND] http://code.google.com/p/webgrind/downloads/list

[SNORT] http://www.snort.org

[CVE-2012-1790] http://www.cvedetails.com/cve/CVE-2012-1790/

[DOC SNORT] http://s3.amazonaws.com/snort-org/www/assets/166/snort_manual.pdf

[TAP] http://fr.wikipedia.org/wiki/TAP_r%C3%A9seau

[AUDIT] http://doc.opensuse.org/products/draft/SLES/SLES-security_sd_draft/cha.audit.comp.html

[OSSEC] http://www.ossec.net/doc/manual/installation/index.html

[WIKIPEDIA] http://fr.wikipedia.org/wiki/SIEM