Un capteur réseau produit des dizaines de milliers d'événements par jour. Les stocker dans des fichiers ne mène nulle part : sans moteur de recherche, personne ne répondra à « quelles machines ont contacté ce domaine la semaine dernière ? ». C'est le rôle d'OpenSearch.
Ce que c'est
OpenSearch est un moteur de recherche et d'analyse distribué, né en 2021 d'une bifurcation d'Elasticsearch — lorsque ce dernier a quitté sa licence libre. Le projet est aujourd'hui piloté par une fondation, sous licence Apache 2.0, avec un engagement d'ouverture qui explique son adoption rapide dans le domaine de la sécurité.
Son principe : on lui envoie des documents JSON, il les indexe, et l'on peut ensuite interroger des millions d'entrées en quelques millisecondes — en texte libre, par filtres, ou par agrégations.
Les quatre notions à connaître
- Document — un objet JSON. Ici, un événement Suricata : une requête DNS, une alerte, un flux.
- Index — un ensemble de documents. En sécurité, on découpe par jour :
suricata-eve-2025.12.30. Ce découpage est ce qui rend possible la suppression des vieilles données par simple effacement d'index — bien plus efficace que de supprimer ligne à ligne. - Mapping — la description des champs et de leur type. C'est là que se joue la qualité des recherches : une adresse IP typée comme telle se filtre par plage, un champ texte se cherche par mot.
- Agrégation — le calcul qui transforme des millions d'événements en réponse : « les dix domaines les plus résolus », « le volume d'alertes par heure ».
Cette dernière notion est le cœur de l'usage sécurité : on ne lit pas les événements un par un, on les agrège pour faire apparaître ce qui sort de l'ordinaire.
Pourquoi il convient à la sécurité
- Volume et rétention — il absorbe des flux continus et conserve l'historique, ce qui permet de revenir en arrière lors d'un incident.
- Recherche libre — on cherche une adresse IP, un nom de domaine, une empreinte de fichier à travers toutes les données, sans avoir prévu la question à l'avance.
- Corrélation — croiser plusieurs types d'événements sur une fenêtre de temps, ce qui est la base de toute reconstitution d'attaque.
- Écosystème — collecteurs, tableaux de bord, alerting : les briques existent et se branchent.
Les pièges d'exploitation
La mémoire. OpenSearch tourne sur une machine virtuelle Java et réclame des réglages système spécifiques — notamment une limite de zones mémoire relevée, faute de quoi il refuse purement et simplement de démarrer. C'est le premier écueil de toute installation, et l'erreur affichée n'est pas toujours limpide.
L'espace disque. Un capteur réseau produit beaucoup, et l'indexation ajoute son propre coût. Sans politique de rétention, le disque se remplit — et un moteur d'indexation plein passe en lecture seule, donc cesse d'ingérer. Décider dès le départ combien de jours conserver n'est pas une optimisation, c'est une condition de fonctionnement.
La sécurité, justement. OpenSearch embarque un module de sécurité — authentification, chiffrement, contrôle d'accès. Beaucoup de tutoriels, dont celui du lab de cette série, le désactivent volontairement pour simplifier. C'est acceptable sur un réseau isolé, à condition de l'assumer : un moteur d'indexation ouvert, c'est l'ensemble des journaux de sécurité accessible à qui sait taper une URL.
Un nœud ou plusieurs ?
OpenSearch est conçu pour fonctionner en grappe : les données sont réparties et répliquées. En lab, un nœud unique suffit et se déclare explicitement — sans quoi le moteur attend indéfiniment des pairs qui n'existent pas.
En production, la question se pose autrement : la réplication protège des pannes, et la répartition permet d'absorber le volume. Mais un cluster mal dimensionné coûte cher et se répare mal. La règle habituelle consiste à commencer petit, mesurer le volume réel, puis dimensionner sur des chiffres.
Et les tableaux de bord ?
OpenSearch fournit sa propre interface — OpenSearch Dashboards — qui excelle pour l'investigation : explorer les champs, filtrer, remonter une chronologie. Beaucoup d'architectures lui adjoignent Grafana pour la supervision : des tableaux de bord synthétiques, aux côtés d'autres sources de données.
Les deux ne s'opposent pas et répondent à deux questions différentes : « que s'est-il passé exactement ? » pour l'un, « comment se porte le réseau ce matin ? » pour l'autre.
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 — vous y êtes
- 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