Mise en place de Wazuh | Déploiement SIEM & Monitoring
Installation et configuration d'une solution complète de surveillance de sécurité pour protéger une infrastructure.
Contexte et Architecture
Pour ce projet, j'ai déployé une solution de surveillance de sécurité Wazuh. L'architecture se compose de deux machines connectées sur le même réseau local, assurant une communication fluide pour la remontée d'alertes.
Serveur Wazuh (VM Linux)
IP : 192.168.106.206/24
Machine Physique (Windows)
IP : 192.168.106.146/24
Étapes de Réalisation
Installation de la VM Ubuntu 22.04
Après avoir installé la machine virtuelle Ubuntu (IP : 192.168.106.150), la première étape a consisté à vérifier la connectivité avec le serveur Wazuh pour s'assurer que les flux réseaux étaient ouverts.
Une fois la connexion validée, j'ai procédé à l'installation des paquets
nécessaires, notamment curl, indispensable pour le téléchargement des
agents et clés.
Connexion à l'interface Wazuh
En parallèle de la configuration du client, je me suis connecté à l'interface web de gestion Wazuh pour préparer l'enrôlement de l'agent.
Identifiants par défaut
Résultats obtenus & Conformité
Analyse de sécurité (Hardening) basée sur les benchmarks CIS (Center for Internet Security).
Conformité Ubuntu 22.04 LTS
Le module SCA a validé 63 contrôles, tandis que 98 ont échoué. Ce score de 39% indique une configuration encore "standard". Le scan met en évidence les points de durcissement (hardening) nécessaires pour s'aligner sur les recommandations NIST, ISO 27001 ou PCI-DSS.
Conformité Windows 10 Enterprise
Sur Windows 10, nous obtenons 128 contrôles conformes pour 262 non conformes. Comme pour Ubuntu, ce score (32%) révèle une machine peu durcie. L'audit SCA fournit une feuille de route claire pour sécuriser le poste de travail selon les standards de l'industrie.
Détection d'Intrusions & Analyse d'Événements
Surveillance en temps réel des activités suspectes et classification des alertes via le framework MITRE ATT&CK.
Collecte des Événements
Dans le module Security events, avec un filtre sur l'agent Ubuntu
(agent.id: 001), Wazuh remonte un total de 198
événements.
Cela confirme que la collecte est opérationnelle et que le manager réceptionne bien
les logs système pour analyse.
Analyse des Top Alertes
Le graphique « Top 5 alerts » met en évidence les catégories les plus fréquentes :
- Host-based anomalies : Comportements systèmes inhabituels.
- PAM: Login session : Surveillance des authentifications.
- SCA/CIS : Alertes liées aux défauts de conformité.
Cette visualisation permet d'identifier rapidement les tendances et les points critiques à traiter en priorité sur la VM Ubuntu.
Classification MITRE ATT&CK
Wazuh corrèle les alertes avec le framework MITRE ATT&CK pour qualifier la menace. Sur cette capture, on observe :
- T1078 (Valid Accounts) : Utilisation de comptes légitimes (Tactiques : Initial Access, Persistence, Privilege Escalation, Defense Evasion).
- T1548.003 (Sudo/Sudo Caching) : Tentatives d'élévation de privilèges.
Cette classification contextuelle aide à comprendre le but de l'attaquant et l'étape de la "Kill Chain" dans laquelle il se situe.
Prérequis : Inventaire Logiciel (Syscollector)
Le module Vulnerability Detector s'appuie sur l'inventaire logiciel remonté par Syscollector. Avant d'analyser les vulnérabilités, il est crucial de valider que cet inventaire est bien actif et fonctionnel sur les agents.
Vérification du Service
Je m'assure d'abord que l'agent Wazuh tourne correctement sur la VM Ubuntu.
La commande systemctl status wazuh-agent me confirme que le service est
active (running).
Activation de Syscollector
L'inventaire est géré par le module syscollector. Je vérifie son
activation dans le fichier de configuration de l'agent :
/var/ossec/etc/ossec.conf.
La présence du bloc <wodle name="syscollector"> avec l'option
<disabled>no</disabled> garantit que le module est bien
activé et prêt à scanner le système.
Validation des Logs
Pour être certain que l'inventaire remonte bien, je consulte les logs de l'agent
dans /var/ossec/logs/ossec.log.
Les lignes indiquant syscollector: INFO: Module started suivies de
Evaluation finished prouvent que l'agent a réussi à scanner les paquets
installés et à envoyer ces métadonnées au serveur Wazuh.
Simulation d'Attaque : Brute Force SSH (Hydra)
Pour tester la réactivité du SIEM, j'ai simulé une attaque par force brute sur le service SSH de l'agent Ubuntu depuis une machine attaquante (Kali Linux).
Préparation de l'Attaquant (Kali)
Sur la VM Kali Linux (192.168.106.205), je crée un fichier
dictionnaire
contenant 10 mots de passe aléatoires pour l'attaque.
Exécution de Hydra
Je lance l'outil Hydra pour tenter de casser le mot de passe SSH de la cible Ubuntu.
L'outil teste séquentiellement les combinaisons jusqu'à trouver ou non l'accès. Chaque tentative échouée génère un log d'échec d'authentification sur la cible.
Détection par Wazuh
Dans la section Security Events, Wazuh a immédiatement détecté l'anomalie.
Analyse de l'incident
Wazuh a agrégé les multiples échecs pour déclencher une alerte de sévérité élevée : "SSHD brute force trying to get access to the system". Cela démontre la capacité du SIEM à transformer une série de logs bénins (échecs de connexion) en un incident de sécurité qualifié.
Réponse Active : Blocage Automatique
Pour aller plus loin que la simple détection, j'ai configuré le module Active Response afin de bloquer automatiquement l'adresse IP de l'attaquant dès qu'une tentative de brute force est détectée.
Configuration du Serveur
Dans le fichier /var/ossec/etc/ossec.conf du serveur Wazuh, je vérifie
la présence de la commande firewall-drop.
J'ajoute ensuite le bloc <active-response> pour lier cette
commande à la règle de détection de brute force SSH (ID 5712) avec un timeout de
60 secondes (pour le test).
Test de l'Attaque
Je relance l'attaque Hydra depuis Kali. Cette nouvelle tentative est nécessaire pour vérifier que la règle de réponse active (Active Response) se déclenche correctement en temps réel.
Résultat sur Wazuh
Sur le dashboard, l'événement "Host Blocked by firewall-drop Active Response" apparaît immédiatement. Cela confirme que l'IP de l'attaquant a été repérée et bloquée automatiquement par le système.
On remarque donc que la règle correspond bien à ce que nous avons ajouté dans le fichier de conf sur le serveur.
Preuve de Blocage (Ping)
Pour vérifier l'efficacité du blocage, je tente de pinger la machine cible (Ubuntu) depuis la machine attaquante (Kali) dans les secondes suivant l'attaque.
Résultat : Le ping échoue (100% packet loss), confirmant que l'IP de Kali a été temporairement bannie par le pare-feu (iptables) de la machine Ubuntu.
Journalisation de la Réponse Active
Par défaut, les actions de réponse active sont logguées dans
/var/ossec/logs/active-responses.log.
Pour les visualiser dans le dashboard, j'ai ajouté ce fichier comme source de
logs locale (localfile) dans la configuration du Manager.
Une fois configuré, une nouvelle alerte spécifique apparaît dans Wazuh,
indiquant clairement que l'action firewall-drop a été déclenchée,
avec la source du log précisée.
Conclusion
J’ai ajouté active-responses.log comme source de logs dans la configuration du
manager Wazuh via un bloc <localfile>. Après exécution d’une action
(active response), un événement apparaît dans Wazuh et indique clairement la source
location: /var/ossec/logs/active-responses.log, ce qui confirme que les
réponses automatiques sont bien journalisées et exploitables pour l’analyse.
Network IDS Integration (Suricata)
Intégration du système de détection d'intrusion réseau Suricata pour analyser le trafic et remonter les alertes dans Wazuh.
Installation de Suricata
J'installe Suricata sur l'endpoint Ubuntu (version testée 6.0.8). L'ajout du dépôt PPA assure d'avoir une version stable récente.
root@etud-virtual-machine:/home/etud# sudo add-apt-repository ppa:oisf/suricata-stable
Téléchargement des Règles
Téléchargement et extraction du jeu de règles "Emerging Threats" pour Suricata.
Configuration de Suricata
Modification du fichier /etc/suricata/suricata.yaml pour définir
l'interface réseau à surveiller (ici ens33) et les réseaux locaux.
sudo systemctl restart suricata
Intégration Agent Wazuh
Ajout de la configuration dans /var/ossec/etc/ossec.conf pour permettre à
l'agent Wazuh de lire le fichier de logs de Suricata (eve.json).
sudo systemctl restart wazuh-agent
Simulation d'Attaque
Wazuh parse automatiquement les données de /var/log/suricata/eve.json et
génère les alertes associées sur le dashboard.
Pour tester, je ping l'adresse IP de l'endpoint Ubuntu depuis le serveur Wazuh.
Visualisation des Alertes
Je peux visualiser les alertes dans le dashboard Wazuh. Pour cela, je vais dans le module "Threat Hunting" et j'ajoute les filtres dans la barre de recherche pour requêter les alertes.
Conclusion du projet
Le déploiement de Wazuh m’a permis de mettre en place une supervision de sécurité complète et plus proactive sur une infrastructure avec plusieurs types de machines.
Entre l’installation et la configuration des agents sur Ubuntu et Windows, la détection des vulnérabilités, la mise en place de réponses actives (comme le blocage d’adresses IP) et l’intégration de Suricata pour l’IDS réseau, ce projet m’a montré concrètement l’efficacité d’une solution Open Source de type XDR/SIEM pour améliorer la protection d’un système d’information.