Le capteur écrit dans un fichier, le moteur d'indexation attend des documents. Entre les deux, il faut une chaîne — et le choix de cette chaîne dit beaucoup sur la robustesse qu'on attend d'une plateforme de sécurité.
Pourquoi ne pas envoyer directement
Quatre étages, quatre responsabilités — et surtout un fichier comme tampon : c'est ce qui rend l'ensemble tolérant aux pannes.
Suricata sait envoyer ses événements directement sur le réseau. Le lab choisit pourtant d'écrire dans un fichier, puis de faire lire ce fichier par un agent. Ce détour a une justification précise : le fichier sert de tampon.
Si le collecteur est arrêté, redémarré ou saturé, le capteur continue d'écrire sans se soucier de rien. L'agent, lui, garde sa position de lecture et reprend exactement où il s'était arrêté. Aucun événement n'est perdu, et une panne du collecteur ne devient jamais une panne du capteur.
Les quatre étages
- Suricata écrit un événement JSON par ligne ;
- Filebeat, sur la passerelle, suit le fichier et expédie les lignes ;
- Logstash, sur le collecteur, normalise, enrichit et route ;
- OpenSearch indexe.
Filebeat : suivre un fichier, sans rien perdre
L'agent décode le JSON à la source et enrichit les événements ; le pipeline ajoute le nom du capteur et route vers l'index du jour.
filebeat.inputs:
- type: filestream
paths: [ /var/log/suricata/eve.json ]
parsers:
- ndjson: { target: "" }
Deux choses à noter. Le décodage du JSON est fait dès la lecture : les événements arrivent structurés dans la suite de la chaîne, plutôt que sous forme de texte à ré-analyser. Et l'on ajoute au passage des champs d'identification — nom du capteur, nom du lab — qui deviendront indispensables le jour où un second capteur enverra ses propres événements.
Un point technique qui fait perdre du temps : cet agent est conçu pour Elasticsearch et tente par défaut d'y installer des modèles d'index et des politiques de rétention. OpenSearch n'est pas Elasticsearch — ces opérations échouent. Il faut donc désactiver explicitement ces automatismes et passer par le pipeline intermédiaire, ce qui est de toute façon la pratique recommandée.
Logstash : le point de normalisation
input { beats { port => 5044 } }
filter { mutate { add_field => { "sensor" => "suricata-01" } } }
output {
opensearch {
hosts => ["http://127.0.0.1:9200"]
index => "suricata-eve-%{+YYYY.MM.dd}"
}
}
Trois choix visibles dans ces quelques lignes :
- l'index est daté — un index par jour. C'est ce qui rendra la rétention gérable : supprimer trente jours de données consiste à supprimer trente index, et non à effacer des millions de documents un par un ;
- l'enrichissement est centralisé — c'est ici qu'on ajoutera demain la géolocalisation, la résolution d'un nom d'actif, ou l'étiquetage d'un segment réseau ;
- la sortie passe par un greffon dédié, à installer explicitement : le connecteur OpenSearch n'est pas fourni d'origine.
À conserver le temps de la mise au point : une sortie de débogage vers la console. Voir passer les événements bruts est le moyen le plus rapide de comprendre pourquoi un champ n'arrive pas.
Vérifier que ça coule
curl -s http://127.0.0.1:9200/_cat/indices?v | grep suricata green open suricata-eve-2025.12.30 ... 12843 docs
Un index du jour, avec un nombre de documents qui augmente : la chaîne fonctionne. En cas de silence, le diagnostic se fait étage par étage — le fichier grossit-il ? l'agent tourne-t-il ? le pipeline reçoit-il ? l'index existe-t-il ? Cette progression identifie la panne en quelques minutes, là où un envoi direct laisserait face à un seul symptôme : « je ne vois rien ».
Le sujet qui arrive juste après
Une fois la chaîne en place, une question se pose immédiatement : combien de temps conserve-t-on ? Un seul capteur sur un petit réseau produit déjà plusieurs centaines de mégaoctets par jour. Sans politique de rétention, le disque du collecteur se remplit — et un moteur d'indexation plein passe en lecture seule, donc cesse d'ingérer.
C'est un arbitrage à poser dès le début : trop court, l'investigation devient impossible ; trop long, le coût explose et la question de la protection des données personnelles se pose. Le découpage quotidien des index est ce qui rend cet arbitrage applicable.
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
- 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 — vous y êtes
- Lab (5) : les tableaux de bord