Du SIEM au SOC : plusieurs couches de détection autour de Wazuh

Contexte

L'entreprise, une PME de distribution d'une vingtaine de personnes, repose sur Windows Server, Active Directory, un pare-feu en frontière et Microsoft 365. Chaque machine gardait ses journaux pour elle : rien ne les centralisait ni ne les croisait.

Une attaque combine souvent fichiers modifiés, trafic inhabituel et déplacement vers d'autres machines ; vue isolément, chaque étape semble anodine. D'où plusieurs couches de détection, avec trois contraintes : aucun coût logiciel, détecter sans bloquer, valider chaque module sur l'infrastructure réelle.

Ce que j'ai fait

1. Créer un serveur SIEM dédiéUne VM Ubuntu Server 22.04 LTS sur Hyper-V (8 vCPU, 32 Go de RAM), à l'adresse figée dès la conception : tous les agents et flux Syslog pointent vers elle.
2. Surveiller les machinesIntégrité des fichiers sensibles en temps réel, configuration des postes comparée aux guides CIS, et Auditd sur le SIEM lui-même, la cible la plus sensible.
3. Écouter le réseauSuricata en IDS passif, avec 50 682 règles Emerging Threats Open actives : il observe sans bloquer, le temps de connaître le trafic normal.
4. Poser un leurreOpenCanary simule des services tentants pour un attaquant, sur sa propre VM isolée. Personne n'a de raison de s'y connecter : ses événements lèvent une alerte de niveau 13 sur 15.
5. Réparer l'annotation MITRE ATT&CKElle n'avait jamais fonctionné : deux pannes se cumulaient. Après réinstallation du manager, elle est active, sans perte de règles ni d'intégrations.

Voir les détails techniques

Serveur. 400 Go de disque. Ubuntu Server 22.04 LTS est la plateforme que l'éditeur de Wazuh teste en priorité, avec cinq ans de support. Manager, indexer (OpenSearch) et tableau de bord sont installés ensemble par le script officiel ; le mot de passe administrateur, affiché une fois, est rangé dans un coffre dédié.

Machines. Intégrité des fichiers (FIM) en temps réel plutôt qu'en scan périodique, avec report_changes : l'alerte contient le détail du changement. Le contrôle de configuration (SCA) tourne toutes les douze heures ; faute de vue consolidée, j'ai lu le score de chaque agent par l'API REST, avec un jeton JWT. Auditd surveille sur le SIEM les commandes des comptes à privilèges, les accès à la configuration de Wazuh et les règles du pare-feu local. Les autres protections de ce serveur font l'objet d'un projet à part.

Bash · API REST Wazuh

# 1. Obtenir un jeton JWT (mot de passe masqué)
TOKEN=$(curl -sk -u wazuh:'********' -X POST \
  'https://localhost:55000/security/user/authenticate' \
  | python3 -c 'import sys,json; print(json.load(sys.stdin)["data"]["token"])')

# 2. Score SCA d'un agent (ici le 001), puis la même requête pour chaque agent actif
curl -sk -H "Authorization: Bearer $TOKEN" 'https://localhost:55000/sca/001?pretty=true'

Réseau. Suricata en mode af-packet multi-threads. Parmi les règles désactivées : celles des protocoles industriels (Modbus, DNP3), sans objet ici. Un IPS mal calibré peut couper un flux légitime ; un passage en blocage, sur quelques règles maîtrisées, ne viendrait qu'ensuite. Pour valider la chaîne de bout en bout, une alerte simulée de scan SSH a déclenché la règle Wazuh 86601 (« ET SCAN Potential SSH Scan », niveau 3, signature ET 2001219).

Wazuh · ossec.conf

<ossec_config>
  <localfile>
    <log_format>json</log_format>
    <location>/var/log/suricata/eve.json</location>
  </localfile>
</ossec_config>

Leurre. Sa propre VM, pour qu'un attaquant qui chercherait à en sortir n'atterrisse pas sur l'outil qui surveille tout le reste ; une machine dédiée est aussi plus crédible. La règle se déclenche dès qu'un événement contient « opencanary ».

Wazuh · local_rules.xml

<group name="local,">
  <!-- Règle racine : parent local, ne produit aucune alerte -->
  <rule id="100001" level="0">
    <match>.</match>
    <description>Regle racine locale.</description>
  </rule>

  <!-- Toute trace du leurre : alerte de niveau 13 -->
  <rule id="100002" level="13">
    <if_sid>100001</if_sid>
    <match>opencanary</match>
    <description>OpenCanary: Intrusion detectee sur le honeypot</description>
  </rule>
</group>

MITRE, panne 1 : l'interface de Wazuh ne répond plus

Problème

Interface web bloquée, tableaux de bord inaccessibles. Lancé au premier plan, le moteur d'analyse montrait que le fichier d'archive du jour appartenait à root au lieu de wazuh : il refusait de démarrer.

Résolution

Correction récursive des propriétaires des journaux de Wazuh : API, interface et moteur sont repartis aussitôt.

MITRE, panne 2 : la base de référence ne se régénère pas

Problème

La détection fonctionnait, mais aucune alerte n'était annotée. La base MITRE interne était corrompue ; la supprimer ne la régénérait pas, et l'extraire du paquet ne donnait qu'une coquille vide, non compilée.

Résolution

Réinstallation du manager, dont les scripts officiels de post-installation compilent cette base ; la version de Wazuh a été mise à jour au passage. Un test de force brute SSH, remonté par un agent Windows, a confirmé l'annotation.

L'incident

Résultats

Une requête HTTP vers le leurre fait apparaître l'alerte en moins de 30 secondes. Il détecte une connexion à lui-même, pas tout mouvement latéral, et un outil d'inventaire légitime peut le toucher : chaque alerte se qualifie avant réaction.

La première mesure CIS des postes Windows a donné 28 à 29 %, le score attendu sans GPO de durcissement. Chaque contrôle en échec indique la GPO qui le corrige : une liste de travail. Les tableaux PCI-DSS et RGPD de Wazuh classent les alertes par exigence : utile pour préparer un audit, sans prouver la conformité.

Ce SOC est le premier volet d'un même projet, mené en juin 2026 ; le second protège le serveur SIEM lui-même et fait expliquer ses alertes par une IA locale. Ensuite, l'audit de l'Active Directory a ajouté au SIEM l'audit avancé des contrôleurs de domaine, et un cyber range en homelab a montré ce qu'une chaîne pare-feu → SIEM laisse passer.

Ce que j'améliorerais

• Prévoir dès la conception un port miroir (SPAN) sur le switch cœur : un IDS ne détecte que le trafic qu'on lui montre.
• Suivre dès le départ la couverture du parc, « agents actifs / machines inventoriées », pour savoir ce que le SIEM ne voit pas.
• Ajouter une réponse active pas à pas, en commençant par le leurre : observer quels outils légitimes le touchent, puis bloquer temporairement l'adresse source.

Compétences

• Architecture de détection en couches
• Administration d'un SIEM Wazuh
• Détection réseau avec Suricata
• Leurre et qualification d'alertes
• Dépannage en production
• MITRE ATT&CK et CIS Benchmarks