Configurer une détection open source avec Wazuh

Une petite structure n’a pas besoin d’un centre opérationnel de sécurité avec écrans muraux et analystes de nuit pour détecter les attaques les plus banales. Elle a besoin de journaux centralisés, d’alertes rares mais actionnables, et d’une conservation suffisante pour comprendre un incident après coup.

→ Lire l’explication complète de la marmotte

Le compromis central est brutal : on gagne une visibilité exploitable sur les accès et les changements système, mais on paie en stockage, en maintenance et en temps d’analyse. La recommandation est de démarrer avec Wazuh, un outil de détection open source incluant collecte, règles et interface de recherche. Une pile Elasticsearch, Logstash et Kibana (ELK) ou OpenSearch devient justifiable lorsque la recherche transverse, les tableaux de bord métier ou les flux applicatifs dominent les besoins. Pour moins de cinquante actifs critiques, Wazuh évite de construire un château de Lego à trois heures du matin.

Périmètre de collecte et dimensionnement Wazuh

Ne pas collecter tous les journaux de toutes les machines dès le premier jour. Cette stratégie produit surtout un index coûteux rempli de bruit, puis une désactivation silencieuse du projet. Commencer par les actifs dont la compromission donne un accès durable ou étendu :

contrôleurs de domaine, serveurs d’identité et bastions d’administration ;
serveurs exposés sur Internet, notamment reverse proxies, messageries et applications ;
serveurs contenant des données sensibles ou assurant les sauvegardes ;
postes d’administration, postes des équipes infrastructure et sécurité ;
équipements réseau produisant des événements d’authentification ou de configuration.

La cartographie des identités doit précéder le déploiement. Une alerte sur un compte administrateur n’a aucune valeur si personne ne sait quels comptes sont réellement privilégiés, ni quel usage est autorisé. Les journaux réseau restent également nécessaires : les fondations réseau déterminent quels flux permettent aux agents d’atteindre le collecteur.

Prévoir un serveur Linux dédié avec au minimum 8 processeurs virtuels, 32 gigaoctets de mémoire vive et 1 téraoctet de stockage redondé pour vingt à cinquante sources actives. Ce n’est pas luxueux : le moteur d’indexation consomme mémoire et entrées disque dès qu’il doit agréger, rechercher et conserver. Une machine virtuelle avec 8 gigaoctets de mémoire peut afficher une interface pendant une démonstration, puis échouer dès que les alertes ont l’impolitesse d’arriver en même temps.

Mesurer le volume réel pendant sept jours avant de fixer la rétention. Pour une petite flotte, prévoir entre 200 mégaoctets et 2 gigaoctets par jour et par serveur critique, selon verbosité applicative et audit système. Les postes génèrent moins, sauf si l’audit Windows est configuré sans filtrage. Conserver au minimum 30 jours consultables immédiatement et 90 jours au total, compressés si nécessaire. Sous 30 jours, une investigation lancée après une absence ou un congé devient une enquête archéologique sans ruines.

La rétention doit inclure une marge de 30 % pour les pics, les tentatives de force brute et les erreurs de configuration. Surveiller l’espace libre, la latence disque, la taille des index et la file d’attente des agents. Une collecte qui perd des événements parce que le disque est plein ne produit pas une alerte élégante : elle produit du silence, ce grand classique des architectures optimistes.

Installation du serveur Wazuh et des agents critiques

Wazuh repose sur trois rôles : le manager reçoit et analyse les événements, l’indexeur les conserve et les recherche, le tableau de bord les affiche. L’installation mononœud rassemble ces rôles sur une même machine. Elle convient à une petite structure, pas à un service qui doit rester disponible pendant la perte complète de son unique serveur.

Avant installation, préparer :

une adresse IP fixe et un nom de service résolu par le système de noms de domaine ;
un certificat Transport Layer Security (TLS) valide pour l’interface et les agents ;
les flux réseau limités aux sources connues : port 1514 en Transmission Control Protocol (TCP) pour les agents, port 1515 en TCP pour leur enrôlement, port 443 en TCP pour l’interface ;
une synchronisation horaire par Network Time Protocol (NTP), car une alerte sans heure fiable vaut à peu près un ticket sans numéro ;
une sauvegarde chiffrée de la configuration, des certificats et des index.

Installer une version stable maintenue de Wazuh selon la branche validée par l’éditeur. Le script suivant installe un nœud unique. Le numéro de version doit être remplacé par la branche stable encore supportée, puis figé dans la documentation d’exploitation.

# Installer Wazuh tout-en-un sur Debian ou Ubuntu supporté.
# Vérifier au préalable la somme de contrôle publiée du script.
curl -sO https://packages.wazuh.com/4.14/wazuh-install.sh

# L'option -a déploie manager, indexeur et tableau de bord sur ce nœud.
sudo bash ./wazuh-install.sh -a

# Afficher les mots de passe générés, à transférer dans un coffre de secrets.
sudo tar -O -xvf wazuh-install-files.tar wazuh-install-files/wazuh-passwords.txt

# Activer les services et contrôler leur état.
sudo systemctl enable --now wazuh-manager wazuh-indexer wazuh-dashboard
sudo systemctl --no-pager --full status wazuh-manager

Ne jamais déposer wazuh-passwords.txt dans un partage d’équipe, un ticket ou un dépôt Git. Ce fichier ouvre l’administration de la plate-forme. Stocker les secrets dans un coffre dédié, limiter les administrateurs et renouveler les mots de passe après chaque exposition suspecte. Les secrets de supervision méritent la même discipline que les secrets applicatifs : une collecte compromise peut aussi être utilisée pour faire disparaître les traces.

Sur un hôte Debian ou Ubuntu, installer l’agent puis définir l’adresse du manager avant son démarrage :

# Ajouter le dépôt Wazuh et sa clé de signature.
curl -fsSL https://packages.wazuh.com/key/GPG-KEY-WAZUH \
  | sudo gpg --dearmor -o /usr/share/keyrings/wazuh.gpg

echo "deb [signed-by=/usr/share/keyrings/wazuh.gpg] https://packages.wazuh.com/4.x/apt/ stable main" \
  | sudo tee /etc/apt/sources.list.d/wazuh.list

sudo apt-get update
sudo WAZUH_MANAGER="10.20.30.10" \
  WAZUH_AGENT_NAME="$(hostname -f)" \
  apt-get install -y wazuh-agent

# Démarrer l'agent seulement après validation de l'adresse du manager.
sudo systemctl enable --now wazuh-agent
sudo systemctl status wazuh-agent --no-pager

Pour Windows, déployer le paquet MSI par stratégie de groupe ou outil de gestion de parc, avec l’adresse du manager imposée dans la configuration. Activer au minimum l’audit des connexions, des échecs de connexion, de la création de comptes, des modifications de groupes privilégiés et de l’exécution PowerShell. L’agent ne corrige pas une politique d’audit absente : il ne peut expédier que ce que le système enregistre.

Règles de détection pour authentification et accès administrateur

Une règle de détection doit décrire un comportement dangereux, pas une curiosité technique. Les deux premiers scénarios à couvrir sont les échecs d’authentification répétés et les connexions administratives hors plage autorisée. Ils détectent du bruteforce, de l’usage opportuniste de comptes volés et des erreurs d’exploitation qui doivent être visibles avant de devenir des incidents.

Sur les systèmes Linux, les événements Secure Shell (SSH) proviennent généralement de /var/log/auth.log ou /var/log/secure. Wazuh dispose de règles natives pour les succès et échecs SSH. Ajouter des règles locales dans /var/ossec/etc/rules/local_rules.xml :

<!-- Détecter huit échecs SSH depuis une même adresse en cinq minutes. -->
<group name="local,authentication,">
  <rule id="100100" level="10" frequency="8" timeframe="300">
    <if_matched_sid>5710</if_matched_sid>
    <same_source_ip />
    <description>Échecs SSH répétés depuis une même adresse source</description>
  </rule>

  <!-- Détecter une connexion réussie du compte adminops le soir. -->
  <rule id="100101" level="12">
    <if_sid>5715</if_sid>
    <regex>Accepted.*for adminops</regex>
    <time>18:01-23:59</time>
    <description>Connexion SSH adminops hors horaires autorisés</description>
  </rule>
</group>

Ajouter une seconde règle pour la plage nocturne de 00:00-07:59, puis redémarrer le manager avec sudo systemctl restart wazuh-manager. Tester avec un compte de laboratoire et une adresse connue. Une règle non testée est une opinion XML, ce qui reste moins coûteux qu’une opinion PowerPoint, mais pas beaucoup plus défendable.

Les seuils doivent être calibrés sur les journaux réels. Huit échecs en cinq minutes conviennent souvent à un service SSH exposé, mais un bastion derrière une authentification multifacteur peut exiger un seuil différent. L’authentification multifacteur réduit l’intérêt d’un mot de passe volé, elle ne remplace ni la journalisation ni la détection d’une session déjà ouverte.

Configurer la notification par courrier électronique ou webhook uniquement pour les niveaux élevés, puis créer une procédure de triage : vérifier l’hôte, le compte, l’adresse source, les événements précédents et les changements associés. Envoyer chaque événement vers une messagerie d’alerte transforme vite celle-ci en compost numérique.

Surface d’attaque, limites et exploitation durable

Le collecteur central devient une cible prioritaire. Un attaquant disposant d’un accès administrateur au manager peut modifier des règles, effacer des index ou désactiver les agents. Séparer les comptes d’administration, imposer une authentification multifacteur sur le tableau de bord, filtrer les accès réseau et transmettre les sauvegardes vers un stockage distinct avec rétention verrouillée.

Le chiffrement TLS protège le transport, pas la véracité de l’événement. Un serveur compromis peut mentir, désactiver son agent ou modifier son horloge. Une détection minimale doit donc surveiller l’arrêt d’agent, les trous de télémétrie, les changements de configuration Wazuh et les élévations de privilèges. La centralisation ne garantit pas l’intégrité forensique complète : pour cela, il faut des journaux immuables, des contrôles d’accès stricts et, selon le niveau de risque, une collecte hors bande.

Cette pile ne couvre pas correctement les attaques sans journaux, l’exfiltration chiffrée dans un flux autorisé, les logiciels malveillants inconnus, les abus SaaS ou les actions réalisées avec un compte légitime sans anomalie visible. Elle ne remplace ni la gestion des correctifs, ni les sauvegardes testées, ni le durcissement des protocoles. Le durcissement de NTLM reste par exemple nécessaire même si chaque échec d’authentification remonte parfaitement.

Sauvegarder chaque jour la configuration du manager, les certificats, les règles locales et les index nécessaires à la rétention. Tester trimestriellement la restauration sur un environnement isolé. Documenter la rotation des certificats, les propriétaires des règles et la procédure de révocation d’un agent. Une plate-forme de détection sans reprise testée n’est pas une capacité de sécurité, c’est un journal intime avec alimentation électrique.

🐝 Ce qui arrive si on s’en passe

Sans collecte centralisée, les journaux restent sur les machines qui les produisent : ils tournent selon la rotation locale, disparaissent en quelques jours et s’effacent avec l’hôte reconstruit. Un accès administrateur sur un serveur suffit alors à supprimer la seule copie des traces de son propre passage. La corrélation devient impossible : une campagne d’authentification répartie sur vingt hôtes ne laisse que quelques échecs isolés par machine, sous tout seuil local. Après coup, la reconstitution de la chronologie (première entrée, comptes utilisés, latéralisation) ne repose plus que sur des horloges non synchronisées et des fichiers partiels, ce qui empêche de délimiter le périmètre compromis. Faute de périmètre, la reprise se résume à tout reconstruire, et la démonstration qu’aucune donnée n’a été touchée reste hors de portée.

🦫 Explication de la marmotte 🍫

Le système commence par choisir les ordinateurs et serveurs qui comptent le plus : ceux qui donnent accès aux comptes, aux données, aux sauvegardes ou à Internet. Un programme installé sur chaque machine lit les événements enregistrés par le système, par exemple une connexion réussie, un mot de passe refusé ou un changement de compte. Il envoie ces informations vers un serveur central protégé par chiffrement.

Le serveur central range les événements, les garde pendant une durée définie et applique des règles. Une règle peut dire : « déclencher une alerte si la même adresse essaie huit mots de passe faux en cinq minutes ». Une autre peut signaler une connexion d’administration à une heure où elle ne devrait pas avoir lieu. Les alertes doivent ensuite être vérifiées : une erreur de saisie existe, mais une série d’échecs peut aussi annoncer une tentative d’intrusion.

Le dispositif dépend de plusieurs éléments : l’heure doit être correcte sur toutes les machines, les événements doivent être activés, le réseau doit permettre l’envoi, et le serveur central doit avoir assez d’espace disque. Si un agent s’arrête, si le disque se remplit ou si un pirate contrôle une machine, des informations peuvent manquer ou être fausses. Il faut donc sauvegarder la configuration, surveiller les interruptions de collecte et protéger fortement le serveur central.

Pages voisines

La citent

Configurer une détection open source avec Wazuh

Elle cite

Configurer une détection open source avec Wazuh

Configurer une détection open source avec Wazuh

Périmètre de collecte et dimensionnement Wazuh

Installation du serveur Wazuh et des agents critiques

Règles de détection pour authentification et accès administrateur

Surface d’attaque, limites et exploitation durable

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines