Interfacer Suricata avec son écosystème sécurité

Suricata a déjà été présenté dans les numéros 66 et 69 de MISC. Il s’agit d’un moteur de détection des menaces qui analysele trafic réseau, reconstruit les échanges protocolaires et, de manière optionnelle, les journalise puis applique une détection d’intrusion par signatures sur le trafic reconstruit.

1. IDS & NSM sont dans un bateau

1.1 Une approche hybride

Suricata est plus qu’un système de détection d’intrusion (IDS) basé sur des signatures, car il intègre également des fonctions de surveillance réseau orientées sécurité (NSM). Le concept est simple, les signatures doivent pouvoir exprimer simplement et efficacement des menaces. Simplement, car si le développeur de la signature doit coder dans la signature la logique protocolaire, le coût et le temps de développement peuvent être rédhibitoires. De plus, des erreurs sont probables et cela conduirait à des faux positifs, c’est-à-dire des alertes sur du trafic valide ou des faux négatifs, i.e. des attaques non détectées. Si l’outil comprend le protocole, il est à même de proposer des champs facilement utilisables à l’auteur de signatures et limite les risques d’erreurs. Suricata réalise cette analyse pour les protocoles courants et, ayant extraitces informations, il est à même de journaliser les transactions protocolaires au format JSON ; c’est la fonction NSM de Suricata.

1.2 Rappel par l’exemple

Le point clef de l’intégration de Suricata est l’utilisation de JSON comme format principal pour les événements. Ce format est en effet facile à ingérer par les autres logiciels et le transfert d’événements s’effectue sans perte d’information, car il s’agit du format natif de Suricata. Au niveau des alertes, un travail conséquent a été effectué pour apporter le maximum de contexte. Avec juste les informations de base, IP et paramètres de la signature, il est en effet difficile d’analyser la pertinence ou la sévérité d’une alerte. L’approche « On sait jamais, sur un malentendu ça peut marcher » peut donner des résultats, mais une analyse construite et argumentée est bien sûr préférable. C’est pour cette raison que les métadonnées applicatives ont été ajoutées dans les alertes afin de faciliter leur compréhension. Prenons par exemple, la signature de la figure 1 qui détecte l’agent pycurl.

Cette signature a été déclenchée sur un système. Si l’on observe les paramètres IP de la figure 2, on se demande ce que vient faire pyCurl sur le port 22 de notre machine.

Tout devient plus clair en observant les éléments applicatifs remontés par Suricata. Comme le montre la figure 3, nous avons des données HTTP et elles indiquent qu’une tentative de détection de serveur mandataire ouvert a été faite.

En effet, nous avons une requête HTTP avec méthode CONNECT à destination de cn.bing.com. Il s’agit donc d’une alerte déclenchée par un scanner exotique basé sur pyCurl qui recherche des serveurs mandataires sur le port 22.

Si la technologie est exotique, l’adresse IP de l’attaquant l’est aussi puisque chinoise. Ces informations ne sont pas fournies par Suricata et il est nécessaire d’enrichir les événements après la création et donc sur la chaîne de transfert des événements.

1.3 Architecture globale

Suricata est un moteur et ne prend donc en charge que l’analyse des flux et la génération des événements. Il faut donc transférer les éléments vers une solution de stockage et d’analyse des logs. Deux logiciels se partagent ce marché : Elastic et Splunk. Dans le cas de Splunk, la solution la plus facile consiste à installer et configurer Splunk forwarder sur les sondes pour envoyer les événements stockés sur disque vers le système Splunk. Dans le cas d’Elastic, les possibilités pour le transfert sont plus ouvertes. On peut par exemple utiliser Filebeat de la suite Elastic pour envoyer vers un Logstash qui sera en charge de l’ingestion dans Elasticsearch ainsi que de l’enrichissement des données. Le transfert par Filebeat répond aux contraintes classiques : chiffrement et non perte de données en cas de rupture de lien. La figure 4 illustre l’architecture obtenue.

Suricata bénéficie également d’une sortie Prelude [PRELUDE]et les utilisateurs de ce SIEM peuvent donc profiter d’événements au format natif. Les dernières versions de la sortie Prelude intègrent les métadonnées applicatives (au format JSON) facilitant ainsi l’analyse. On notera que la sortie Prelude ne supporte que les alertes, donc pour gérer les métadonnées protocolaires, il faut un autre bac à événements. D’où l’expression à la musicalité certaine, « Prelude, deux bacs ».

1.4 IDS et signatures

La détection d’intrusions dans Suricata étant basée sur des signatures, l’obtention de règles adaptées aux réseaux surveillés est un point clef. La fondation OISF [OISF] qui gère le projet Suricata a donc récemment créé une liste de sources de signatures [SURIRULES] disponibles publiquement (voir figure 5).

Cette liste contient des sources gratuites et des sources payantes. Les plus fréquemment utilisées sont « Emerging Threat Open » et « Emerging Threat Pro », toutes les deux distribuées par Proofpoint. Il s’agit de jeux de règles généralistes avec un fort focus sur les logiciels malveillants. La couverture de ET Pro est bien supérieure à celle de ET Open avec plus de deux fois plus de signatures. L’utilisation d’ET Pro est donc conseillée malgré son coût.

Le jeu de signatures pour Snort distribué par Talos peut également être utilisé, mais étant développé pour Snort, il n’y a pas de réelle garantie quant à l’impact sur les performances. Il convient donc de le mettre en œuvre avec précaution. Il n’est d’ailleurs même pas référencé par l’OISF, car outre le problème de performance, la compatibilité des règles n’est pas complète.

La plupart des autres jeux de signatures référencés par l’OISF sont plus restreints (Attack research, abuse.ch), mais ils sont intéressants dans la mesure où les problèmes de sécurités couverts sont souvent récents et différents de ceux traités par EmergingThreats.

En dehors de ces sources de signatures publiques, il existe également des sources plus spécifiques qui sont distribuées au sein de communautés d’entités. Dans de nombreux cas, le logiciel MISP [MISP] (présenté dans MISC n°94) est utilisé pour cette distribution. MISP est une une plateforme open source pour le partage d’informations sur les logiciels malveillants et les menaces. Elle fournit les moyens techniques pour échanger indicateurs et informations au sein d’une communauté. Le transfert des informations peut se faire dans une hiérarchie d’instances autorisant ainsi des chaînes de transfert de l’information non triviale et d’une taille augmentant la quantité des informations. Une entité peut être connectée à plusieurs MISP et recevoir/diffuser les informations avec des règles précises.

Au niveau de Suricata, MISP présente des capacités d’exportation de signatures. Ces règles sont soit auto-générées à partir d’éléments de type IOC, soit développées lors d’une réponse sur incident par un des acteurs. L’intégration est assez simple, car les règles sont récupérables sur des URLs publiées par l’instance de MISP. Il convient néanmoins de rester prudent lors de la mise en place. De mauvaises signatures peuvent être publiées causant potentiellement des tempêtes d’alertes. De plus, le nombre total de signatures peut entraîner des problèmes de performance. L’exportation de signatures de certaines instances de MISP compte en effet plus de 80000 signatures.

Une solution pour diminuer l’impact de l’importation de règles MISP consiste trivialement à n’exporter qu’une sous-partie des règles. Pour cela, l’utilisation de limitation temporelle (derniers 15 jours) est fréquemment mise en œuvre. Ceci correspond assez bien à la nature des informations exportées par MISP puisque les indicateurs échangés portent très souvent sur des menaces qui évoluent très rapidement.

1.5 Gestion des signatures

Ne serait-ce que par l’existence des signatures de type Policy, il est nécessaire de paramétrer le jeu de signatures poussé sur les sondes. En effet, une signature avertissant d’une mise à jour de système Debian avec APT a un intérêt dans un parc bureautique sous Windows (pensez VM Kali), mais est simplement inutile pour un réseau de postes sous GNU/Linux. Il faut bien sûr ajouter à cela les faux positifs avec par exemple des signatures qui se déclenchent de manière erronée sur des applications spécifiques. Il est donc obligatoire d’adapter le jeu de signatures par défaut pour éviter un effet sapin de Noël : des alertes par milliers, un SIEM qui clignote et un IDS qu’on oublie dans un coin. Et comme « on laisse pas bébé dans un coin », il faut utiliser un outil de gestion des signatures. Un logiciel dédié est nécessaire, car les fichiers contenant les signatures étant mis à jour régulièrement, des modifications locales effectuées sur les fichiers seraient écrasées à chaque mise à jour.

Il existe deux classes d’outils pour cette tâche, les outils en ligne de commandes : oinkmaster, pulledpork et suricata-update et des outils graphiques : Scirius pour ne mentionner que les logiciels open source. Dans les deux cas, la philosophie est la même, l’utilisateur définit les sources à utiliser par leur point de téléchargement et l’outil s’occupe de les récupérer, d’appliquer les transformations locales et de générer un fichier de règles utilisable par Suricata. Suricata-update et Scirius utilisent la liste des sources de signatures référencées et l’ajout de ces sources est donc particulièrement simple.

Concernant la gestion quotidienne, les deux types de logiciels s’opposent. Pour les logiciels en ligne de commandes, il faut éditer la configuration ou lancer une commande pour modifier le jeu de signatures. Il est donc nécessaire de pivoter de l’interface d’analyse des événements à l’édition de la configuration, ce qui peut devenir rapidement pénible. Avec une interface comme Scirius qui présente les infos des alertes, quelques clics suffisent, « ce n’est pas la peine d’en rajouter ».

Parmi les utilitaires en ligne de commandes, suricata-update est sans doute celui qu’il faut considérer. Il est développé par l’OISF et sera maintenu dans le temps. Il s’agit de plus d’un développement récent intégrant les dernières fonctionnalités de Suricata. De son côté, Oinkmaster est quasiment mort et ne supporte pas certaines des fonctionnalités de Suricata. Pulledpork lui évolue depuis peu, après une longue période sans mainteneur.

2. Intégrations

2.1 Indicateurs de Compromissions

2.1.1 Sommes de contrôle

Suricata dispose avec filemd5, filesha1 et filesha256 d’une série de mots clefs cherchant une correspondance sur les sommes de contrôle des fichiers. Vérifier des indicateurs de compromissions (IOCs) sur ces dernières est donc faisable en ajoutant une ou plusieurs règles qui vont évaluer les sommes de contrôle contre des listes  :

Même s’il ne s’agit pas d’IOCs, il est également possible d’utiliser les mots clefs de type filemd5 pour chercher des documents qui ne sont pas dans une liste connue :

Les mots clefs de cette famille utilisent des structures de données adaptées lors de la recherche de correspondance. Il est ainsi possible vérifier de manière efficace la présence d’empreinte sur une liste de plusieurs millions d’entrées.

Dans de nombreux cas, la réponse sur incident conduit à l’identification de fichiers dont on peut relever l’empreinte. Il est alors intéressant de la chercher a posteriori sur les échanges réseau pour estimer qu’elle est l’étendue d’une compromission. Pour cela, il est possible de journaliser les événements d’échanges de fichiers en leur associant les métadonnées applicatives et les sommes de contrôle. Une recherche peut ensuite être faite sur les événements stockés pour déterminer si certains des fichiers identifiés ont été vus et si oui dans quel contexte.

Il est à noter que le calcul des empreintes demande un Suricata bien nourri et en parfaite condition physique. Il faut en effet analyser la totalité des échanges pour pouvoir calculer les empreintes. La moindre perte de paquets au niveau de la capture ou à tout autre niveau (surcharge CPU par exemple) va en effet se traduire par des événements de type fileinfo dont le champ state sera TRUNCATED. La valeur de la somme de contrôle sera alors soit absente, soit invalide.

2.1.2 Adresses IP

Pour les IOCs contentant des adresses IP, la fonctionnalité appelée « IP Reputation » est particulièrement adaptée puisqu’elle offre une structure dédiée à la recherche d’adresse IP dans des flux pour un nombre important d’adresses sans un impact considérable sur les performances. Ce format est un peu plus qu’une liste d’adresses IP comme il contient une catégorie et un score pour cette catégorie. Il convient donc de transformer les données pour passer d’une liste d‘adresses (telles que souvent fournies dans les IOCs) au format requis par le module IPreputation.

2.1.3 Noms de domaines et URLs

Suricata ne supporte pas directement les indicateurs de compromission sur des domaines. S’il est possible de charger un nombre de règles important utilisant un mot clef comme dns_query or http_hostname, ce n’est pas une solution optimale. En attendant l’arrivée d’un mot clef dédié, il est possible d’utiliser un outil comme Surimisp [SURIMISP] pour vérifier des IOC de type domaines ou URLs dans Suricata.

Ce logiciel se connecte à une instance de MISP et récupère les entrées de type nom de hôte et url. Il lit ensuite en continu les événements générés par Suricata à la recherche de ces éléments dans les entrées DNS, TLS et HTTP. En cas de correspondance, il génère un événement dérivé de l’événement d’origine qu’il écrit sur disque dans un fichier dédié. Comme le format est semblable à celui de Suricata, le procédé de centralisation des journaux déjà en place (filebeat, syslog) est réutilisable.

2.2 Extraction de fichiers

Suricata est capable d’extraire les fichiers passant sur les protocoles HTTP, FTP, NFS, SMB, SMTP. Il est possible d’activer une extraction systématique, mais c’est sans doute l’extraction sélective en utilisant le mot clef filestore qui est la plus intéressante. Le langage de signature peut être utilisé pour sélectionner les conditions d’extraction de fichiers. Ceci se fait assez souvent grâce au mot clef filemagic qui réalise une identification du type de fichier en regardant le contenu du binaire. La règle suivante va ainsi extraire les fichiers PDF échangés sur le protocole HTTP :

Une approche alternative consiste à mettre à jour des signatures intéressantes en ajoutant le mot clef filestore. Les fichiers causant les alertes sont alors enregistrés et constituent autant de preuves qui peuvent être analysées soit par des moyens automatisés (sandboxing) soit par rétro-ingénierie. Les logiciels de gestion de signatures comme Scirius ou suricata-update peuvent être utilisés pour gérer ces transformations de signatures.

Depuis la version 4.1, Suricata supporte un mode de stockage où les fichiers ayant la même empreinte sont écrits une seule fois sur disque. Lorsqu’une extraction est effectuée, l’entrée fileinfo correspondante a une clef stored positionnée sur true et l’utilisateur peut donc savoir qu’effectivement, le fichier a été écrit sur le disque.

Au moment de l’émission de l’alerte, Suricata ne connaît pas l’empreinte du fichier (qui est sans doute encore en cours de tranfert) et la correspondance entre le fichier extrait et l’alerte ne peut donc être faite. Cela est réalisable a posteriori en utilisant deux informations disponibles dans les événements : les clefs flow_id et tx. La première clef est, comme son nom l’indique, un identifiant de flux. Ce dernier est calculé à partir du tuple IP et du temps au moment de l’événement. Il n’est pas formellement unique, mais dans la pratique les collisions sont très rares. Cette clef est donc un filtre idéal pour identifier tous les événements ayant eu lieu sur un même flux (typiquement, alerte, http, fileinfo, entrée de type netflow). Comme un flux peut avoir été le support de plusieurs échanges de fichiers, il est nécessaire d’utiliser une deuxième clef de recherche. Si une donnée protocolaire comme le nom de fichier (disponible dans le sous object fileinfo de l’alerte) est une solution possible, il est plus pertinent d’utiliser la clef tx qui est l’identifiant de la transaction protocolaire. En combinant ces deux informations, l’identification du fichier stocké est stricte.

2.3 Réactions et pots de miels

Les événements protocolaires générés par Suricata sont une source d’information intéressante sur les comportements observés sur le réseau. Leur format étant JSON, il est facile de construire des briques utilisant ces informations. DOM [DOM] présenté dans MISC n°76 est une preuve de concept implémentant une alternative à fail2ban. Le logiciel lit le fichier eve.json et déclenche un traitement lorsqu’un client SSH annonce une valeur attendue. Le traitement par défaut est l’ajout de l’IP source dans une liste Netfilter qui peut être utilisée soit dans une règle de filtrage bloquante, soit pour effectuer une redirection. Dans ce deuxième cas, il s’agit d’une technique pour mettre en place un pot de miel.

Le code actif de DOM (écrit en Python) est très simple :

Il s’agit d’une boucle infinie qui lit le fichier ligne par ligne, décode l’événement (appel à json.loads) et déclenche une action (appel à call_add) si la version du client SSH correspond à ce qui est recherché (via une expression régulière). La fonction call_add réalise un appel à nftables ou iptables pour ajouter l’adresse IP dans une liste prédéfinie. Cette liste est utilisée dans les règles pour bloquer ou rediriger les flux à venir provenant de cette IP vers un service qui agit comme pot de miel.

Comme, pour citer G. Poupard, « Il faut rendre la sécurité numérique sexy » et que l’érotisme consiste à ne pas tout dévoiler, les réalisations possibles sur la base de cette méthode sont laissées à l’imagination du lecteur.

Conclusion

Le moteur Suricata est par son ouverture et ses fonctionnalités un outil de choix pour implémenter une analyse réseau orientée sécurité dans une organisation. Le format JSON des événements est facilement injectable dans les collecteurs de données et est interprétable pour réaliser des développements ad-hoc. La détection d’intrusion offre des fonctions de base intéressantes, mais c’est en la couplant avec l’extraction de métadonnées et de fichiers que le potentiel se révèle tant pour une analyse en temps réel que pour répondre à des besoins d’analyse post-mortem.

Remerciements

Un énorme remerciement à l’OISF et à la communauté formée autour de Suricata ainsi qu’à Christophe Brocas pour sa relecture.

Références

[OISF] Open Information Security Foundation : https://oisf.net/

[SURI] Open Information Security Foundation, Suricata : https://suricata-ids.org/

[SURIRULES] OISF, Sources de signatures référencées : https://www.openinfosecfoundation.org/rules/index.yaml

[MISP] Malware Information Sharing Platform : https://www.misp-project.org/

[PRELUDE] CS Communication & Systèmes, Prelude : https://www.prelude-siem.org/

[SURIMISP] Stamus Networks, surimisp : https://github.com/StamusNetworks/surimisp

[DOM] Eric Leblond, Deny On Monitoring : https://github.com/regit/DOM