Trois outils, trois angles morts
ce qu’on apprend en les croisant

Trois sources, trois angles morts

Un parc se surveille rarement avec un seul outil. Chez nous, trois systèmes regardent des choses différentes, et chacun est aveugle à ce que voit l'autre :

Outil	Ce qu'il voit	Ce qu'il ne voit pas
SIEM (Wazuh)	Journaux système, intégrité des fichiers, comptes, vulnérabilités des machines	Ce qui se passe sur le réseau entre les machines
Supervision réseau (Observium)	Disponibilité SNMP, interfaces, erreurs, débits	Ce qui se passe dans les machines
Journaux pare-feu	Chaque connexion autorisée ou refusée, avec source, destination et règle	Un processus compromis qui parle en HTTPS sortant

Aucun des trois ne suffit. Mais réunis, ils répondent à la question qui compte : est-ce que quelque chose d'anormal s'est produit aujourd'hui ?

Ce que les journaux de pare-feu disent vraiment

Sur vingt-quatre heures, deux appliances Stormshield ont produit un peu plus de 7,9 millions d'événements autorisés et 5 436 refus. Le rapport de un à mille cinq cents est l'ordre de grandeur normal d'un réseau d'entreprise : l'immense majorité du trafic est légitime, et le bruit de fond des scans est absorbé par les règles.

Ce qui rend ces journaux exploitables n'est pas leur volume mais leur structure : chaque ligne porte l'identifiant de l'appliance, la règle qui a décidé, l'interface d'entrée et de sortie, la source, la destination, le port et l'action. Sans ces champs, on a un fichier texte ; avec eux, on peut répondre en une requête à « qui essaie d'entrer, et sur quoi ».

Un détail relevé au passage : les alarmes les plus fréquentes ne sont pas des attaques mais des tentatives d'usurpation d'adresse IP un poste qui prétend être une passerelle. C'est souvent un signe de configuration réseau (deux DHCP, un pont mal cloisonné) autant que de malveillance. Un journal de sécurité qui ne se lit pas par type d'alarme laisse passer ce genre de signal.

Réparer un agent muet : le cas d'école

Un agent Wazuh peut être active et ne rien livrer. Le nôtre pointait vers une adresse de manager qui n'existait plus, l'ancienne, changée lors d'une migration. Le service tournait, se reconnectait toutes les deux minutes, et échouait en silence. Quatre cent quatre-vingt-six jours sans un seul événement.

La correction tient en une ligne dans ossec.conf et un redémarrage. La leçon est ailleurs : personne ne surveillait ce silence. Un agent hors ligne ne produit pas d'alerte, il produit de l'absence, et l'absence ressemble à « rien à signaler ».

Quand l'indexeur sature, le SIEM devient sourd

Panne plus discrète encore : le manager générait bien ses alertes, mais l'indexeur refusait de les stocker.

validation_exception: this action would add [1] total shards,
but this cluster currently has [1000]/[1000] maximum shards open

Le tableau de bord continuait d'afficher des courbes, celles du passé. Le présent n'était plus enregistré. C'est le piège des systèmes qui vieillissent : ils ne tombent pas, ils se figent.

La règle qu'on applique maintenant

Trois contrôles, indépendants des outils, et envoyés hors de la plateforme surveillée :

• Le silence daté. Tout agent sans contact depuis plus de 24 heures devient un incident nommé, pas une ligne grise.
• Le bout-en-bout. « Le service tourne » ne veut rien dire. On vérifie que la donnée arrive chez le consommateur : présence de l'hôte dans les index, ligne du jour dans le journal, compteur non gelé.
• Le rapport hors plateforme. Un message quotidien sur un téléphone, produit par un système qui n'est pas celui qu'il surveille. Si le SIEM meurt, le rapport continue de dire qu'il est mort.

Ce qu'on ne peut pas automatiser

Aucun de ces contrôles ne remplace une décision. Un score CIS à 23 % ne dit pas s'il faut patcher ce soir ; une alarme d'usurpation ne dit pas si c'est un DHCP en trop ou une intrusion. L'automatisation sert à poser la question au bon endroit, pas à y répondre.

Et la question la plus utile reste la plus simple : depuis combien de temps ma machine la plus critique n'a-t-elle pas parlé ?

Sources

• Wazuh, réglages du manager et OpenSearch, réglages de cluster : limite de shards et conséquences sur l'indexation.
• VictoriaLogs, langage LogsQL : extraction de champs et agrégations sur de gros volumes.
• Stormshield, documentation : format des journaux de connexion et d'alarme.
• Observium : supervision SNMP, alertes et inventaire réseau.

Relevés du 31 octobre 2026 sur notre infrastructure : deux appliances Stormshield, 7,9 M d'événements autorisés et 5 436 refus sur 24 h. Aucune adresse, aucune machine et aucun identifiant interne n'est cité.