Déployer un SIEM Wazuh sur mon lab : détection cross-platform et brute-force SSH

Étape 1 : Préparer la VM du Wazuh manager

Le composant indexer (OpenSearch) est gourmand en mémoire : une VM sous-dimensionnée refuse de démarrer ou tourne mal. Nous provisionnons une VM correctement dimensionnée avant de lancer l'installation.

1. Dans Proxmox, nous créons une VM nommée SER25-WAZUH avec :
   • Ubuntu Server 24.04 LTS comme système
   • 4 vCPU
   • 8 Go de RAM (l'indexer réserve la moitié de la RAM disponible pour sa JVM)
   • 50 Go de disque
2. Nous attribuons l'adresse IP fixe 192.168.10.151, DNS préféré 192.168.10.150 (notre contrôleur de domaine), DNS auxiliaire 8.8.8.8.
3. Nous mettons à jour le système avant de commencer :

   
   sudo apt update && sudo apt upgrade -y
   sudo hostnamectl set-hostname SER25-WAZUH
   

Étape 2 : Installer Wazuh en mode all-in-one

Wazuh fournit un script d'installation assisté qui déploie le manager, l'indexer et le dashboard en une seule commande, avec génération automatique des certificats et des mots de passe. C'est la méthode recommandée pour un lab.

1. Nous téléchargeons et lançons l'assistant d'installation (version 4.14, la dernière stable au moment de la rédaction) :

   
   curl -sO https://packages.wazuh.com/4.14/wazuh-install.sh
   sudo bash ./wazuh-install.sh -a   // -a = installation all-in-one (manager + indexer + dashboard)
   

2. L'installation prend entre 5 et 10 minutes. À la fin, le script affiche un résumé avec l'URL du dashboard et le mot de passe généré pour le compte admin :

   

3. Nous copions ce mot de passe immédiatement : il n'est affiché qu'une seule fois. Il reste également consultable dans le fichier wazuh-install-files.tar généré dans le répertoire courant.

Piège connu : si la VM dispose de moins de 4 Go de RAM, l'indexer (OpenSearch) peut ne pas démarrer ou planter après quelques minutes. Dans ce cas, réduire manuellement le heap JVM dans /etc/wazuh-indexer/jvm.options peut suffire, mais mieux vaut redimensionner la VM en amont.

Étape 3 : Premier accès au dashboard

1. Depuis un navigateur, nous ouvrons https://192.168.10.151.
2. Le certificat est auto-signé : c'est attendu pour un lab, nous acceptons l'exception de sécurité.
3. Nous nous connectons avec l'utilisateur admin et le mot de passe récupéré à l'étape précédente.
4. Nous arrivons sur la page d'accueil du dashboard, qui indique « 0 agents » tant qu'aucune machine n'est enregistrée :

   

Étape 4 : Déployer l'agent sur le contrôleur de domaine Windows

Nous installons l'agent Wazuh sur SER25-ADDS-GPO, notre contrôleur de domaine komjordan.fr, pour surveiller les événements de sécurité Windows (connexions, modifications de GPO, création de comptes).

1. Dans le dashboard, nous allons dans Agents > Deploy new agent.
2. Nous sélectionnons le système d'exploitation Windows, renseignons le nom d'agent SER25-ADDS-GPO et l'adresse du manager 192.168.10.151. Le dashboard génère la commande PowerShell correspondante :

   

3. Sur SER25-ADDS-GPO, dans une console PowerShell en administrateur, nous exécutons la commande générée (adaptée ici avec nos valeurs) :

   
   Invoke-WebRequest -Uri https://packages.wazuh.com/4.x/windows/wazuh-agent-4.14.7-1.msi -OutFile wazuh-agent.msi
   msiexec.exe /i wazuh-agent.msi /q WAZUH_MANAGER="192.168.10.151" WAZUH_AGENT_NAME="SER25-ADDS-GPO"
   

4. Nous démarrons le service de l'agent :

   
   NET START WazuhSvc
   

5. Vérification : dans le dashboard, l'agent SER25-ADDS-GPO apparaît avec le statut Active après quelques secondes :

   

Piège connu : si l'agent reste Never connected, vérifier que le pare-feu Windows autorise le trafic sortant vers le port 1514/tcp (communication) et 1515/tcp (enregistrement) vers 192.168.10.151.

Étape 5 : Déployer l'agent sur une VM Linux

Nous ajoutons une seconde VM (Ubuntu Server ou Debian), que nous appelons LAB-LINUX01, adresse 192.168.10.152. C'est elle qui servira de cible pour la simulation de brute-force à l'étape suivante.

1. Sur LAB-LINUX01, nous ajoutons le dépôt Wazuh et sa clé GPG :

   
   sudo apt-get install gnupg apt-transport-https -y
   curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | sudo gpg --no-default-keyring --keyring gnupg-ring:/usr/share/keyrings/wazuh.gpg --import
   sudo chmod 644 /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 -a /etc/apt/sources.list.d/wazuh.list
   sudo apt-get update
   

2. Nous installons l'agent en pointant directement vers notre manager via la variable WAZUH_MANAGER :

   
   sudo WAZUH_MANAGER="192.168.10.151" WAZUH_AGENT_NAME="LAB-LINUX01" apt-get install wazuh-agent -y
   

3. Nous activons et démarrons le service :

   
   sudo systemctl daemon-reload
   sudo systemctl enable wazuh-agent
   sudo systemctl start wazuh-agent
   

4. Vérification : le statut du service doit être active (running), et le journal doit confirmer la connexion :

   
   sudo systemctl status wazuh-agent
   sudo tail -f /var/ossec/logs/ossec.log   // on y attend la ligne "Connected to the server"
   

5. Dans le dashboard, les deux agents apparaissent maintenant côte à côte, l'un Windows, l'autre Linux :

   

Étape 6 : Simuler une attaque brute-force SSH

Wazuh embarque des règles prêtes à l'emploi pour détecter les tentatives de connexion SSH répétées et échouées (règles 5710 à 5712 du décodeur sshd). Nous les déclenchons volontairement pour observer une alerte de bout en bout.

1. Depuis une autre machine du réseau (par exemple notre poste de travail), nous tentons plusieurs connexions SSH vers LAB-LINUX01 avec un mot de passe volontairement incorrect :

   
   for i in $(seq 1 6); do
     ssh -o StrictHostKeyChecking=no -o PreferredAuthentications=password baduser@192.168.10.152
   done
   

   Nous saisissons un mot de passe quelconque à chaque invite : l'échec est attendu et volontaire.
2. Sur LAB-LINUX01, nous pouvons confirmer que les échecs sont bien journalisés par sshd :

   
   sudo tail -n 20 /var/log/auth.log
   

3. Dans le dashboard, nous allons dans Threat intelligence > Security events et filtrons sur l'agent LAB-LINUX01. Une alerte de niveau élevé apparaît, correspondant à la règle de brute-force SSH :

   

4. En ouvrant le détail de l'alerte, nous retrouvons l'identifiant de règle, le nombre de tentatives comptabilisées et l'adresse IP source :

   

Piège connu : si aucune alerte ne remonte, vérifier que le fichier /var/log/auth.log est bien surveillé par l'agent (c'est le cas par défaut sur Ubuntu/Debian) et que l'heure système de LAB-LINUX01 et de SER25-WAZUH sont synchronisées : un décalage important peut retarder l'indexation des événements.