Suricata est le moteur qui tient le rôle d'IDS ou d'IPS dans la plupart des architectures ouvertes. Projet libre porté par l'OISF, il est utilisé aussi bien dans des laboratoires que dans des centres opérationnels de sécurité. Voici ce qu'il fait, et ce qui explique sa place.
Un moteur, plusieurs modes
Le même binaire couvre trois usages, selon la manière dont on lui présente le trafic :
- IDS — capture passive sur une interface, sans intervention sur les flux ;
- IPS — le trafic traverse le moteur, qui peut le rejeter ;
- analyse de captures — relecture d'un fichier de trafic enregistré, pour une investigation après coup.
C'est une propriété précieuse : on apprend en mode passif, on bascule en mode actif sans changer d'outil, de configuration ni de compétences.
Ce qu'il fait du trafic
Un test de configuration avant tout démarrage, puis le fichier d'événements qui se remplit : le moteur est en place.
Suricata ne se contente pas de chercher des motifs dans des paquets. Sa chaîne de traitement enchaîne plusieurs étages :
- capture — lecture des paquets sur l'interface, avec répartition sur plusieurs fils d'exécution ;
- décodage et défragmentation — reconstruction des paquets fragmentés ;
- suivi de flux — regroupement des paquets en conversations, dans les deux sens ;
- identification applicative — reconnaissance du protocole réellement utilisé, indépendamment du port ;
- évaluation des règles — confrontation aux signatures ;
- journalisation — production des événements.
L'identification applicative mérite qu'on s'y arrête : Suricata reconnaît du HTTP sur un port inhabituel, ou du DNS encapsulé ailleurs. Un moteur qui se fierait aux numéros de port passerait à côté — et c'est précisément ce que cherchent les attaquants.
Les règles
Une règle Suricata se lit presque en français : une action, un protocole, une origine, une destination, et des conditions sur le contenu.
alert dns any any -> any any (msg:"Requête vers domaine suspect";
dns.query; content:"exemple-malveillant"; sid:1000001; rev:1;)
Les jeux de règles se récupèrent et se mettent à jour avec suricata-update, qui agrège des sources publiques — le jeu ouvert Emerging Threats étant le plus répandu. On y ajoute ses propres règles pour ce qui est spécifique à son environnement.
L'erreur de débutant consiste à tout activer. Des dizaines de milliers de règles génériques sur un réseau particulier produisent une avalanche d'alertes sans valeur, et une charge processeur inutile. Le travail réel consiste à sélectionner, désactiver et adapter — c'est-à-dire à connaître son propre réseau.
eve.json : le vrai produit du moteur
Suricata écrit ses événements dans un fichier au format JSON par ligne — un objet complet par événement. Ce fichier ne contient pas que des alertes, loin de là :
alert— une règle s'est déclenchée ;dns,http,tls,ssh,smtp… — les transactions applicatives observées ;flow— le résumé de chaque conversation ;fileinfo— les fichiers transférés ;stats— la santé du moteur, dont les paquets perdus.
Deux enseignements pratiques. D'abord, c'est le format qui rend l'intégration simple : n'importe quel collecteur sait lire du JSON par ligne, et c'est ce qui permet d'alimenter un moteur d'indexation sans écrire de convertisseur. Ensuite, surveiller le compteur de paquets perdus est essentiel : un moteur saturé cesse silencieusement d'analyser une partie du trafic, et rien dans les alertes ne le signale.
La configuration qui compte
Deux réglages déterminent tout le reste. L'interface écoutée — souvent l'interface interne d'une passerelle, celle où passe le trafic des utilisateurs. Et la répartition de charge : Suricata distribue les flux sur plusieurs fils d'exécution, en veillant à ce que les deux sens d'une même conversation soient traités ensemble, sans quoi il ne pourrait pas reconstruire les échanges.
Enfin, un réflexe à prendre : tester la configuration avant de démarrer. Suricata dispose d'un mode de vérification qui charge tout — configuration et règles — puis sort. Cinq secondes qui évitent un service qui refuse de démarrer sur un réseau de production.
Ce qui explique sa place
- multi-fils d'exécution dès l'origine — il exploite les processeurs modernes, contrairement à des moteurs plus anciens ;
- format de sortie exploitable — l'intégration à une chaîne d'analyse est immédiate ;
- compatible avec les règles existantes — l'écosystème de signatures est très large ;
- libre, sans limite d'usage — ce qui permet d'en déployer autant que nécessaire.
La suite de cette série montre comment il s'installe, ce qu'il produit, et comment brancher ce qu'il produit sur une chaîne d'analyse.
La série « détection réseau »
Cinq articles pour comprendre, cinq pour construire :
- Qu'est-ce qu'un IDS ?
- Qu'est-ce qu'un IPS ?
- Suricata, le moteur — vous y êtes
- OpenSearch, le socle analytique
- Détection réseau et NIS2 : la logique de sécurité
- Lab (1) : architecture et passerelle
- Lab (2) : OpenSearch et Grafana
- Lab (3) : Suricata en mode IDS
- Lab (4) : la chaîne d'ingestion
- Lab (5) : les tableaux de bord