WAZUH

Site officiel : https://wazuh.com

Github : https://github.com/wazuh/wazuh

Documentations :

Outil open source de cybersécurité :

Modules Core :

Agents :

SIEM

XDR

Ubuntu 22.04

Au moment de l’écriture de ces lignes, la version 24.04 d’Ubuntu ne supporte pas Wazuh. Il faut rester en version 22.04 LTS pour que le service Wazuh puisse fonctionner convenablement.

Si le parefeu est activé sur votre serveur Ubuntu, autoriser les ports 443 et 80

sudo ufw allow 443

sudo ufw allow 80

Installation de WAZUH

WAZUH met à disposition un cloud, payant, pour gérer les Indexeurs, packageurs, …

La documentation signale que pour utiliser 100 endpoints et disposer d’environ 90 jours d’alertes, il faut disposer d’une machine avec 8 vCPU, 8 Go de RAM et 200 Go de stockage. Pour les tests nous resterons sur la version basse à savoir celle fonctionnant jusqu’à 25 endpoints soit 4 vCPU, 8 Go de RAM et 50 Go de stockage.

Agents CPU RAM Storage (90 days)
1-25 4 vCPU 8 Go 50 Go
25-50 8 vCPU 8 Go 100 Go
50-100 8 vCPU 8 Go 200 Go

Sinon il faut partir par la suite sur une installation distribuée, du multi-node en cluster.

Depuis la documentation Quickstart nous allons suivre les étapes suivantes :

  1. Télécharger et exécuter l’assistant d’installation de Wazuh

    curl -sO https://packages.wazuh.com/4.7/wazuh-install.sh && sudo bash ./wazuh-install.sh -a

A la fin de l’installation si tout s’est bien passé, le mot de passe de l’administrateur de Wazuh va être affiché. Copiez et conservez ce mot de passe car il ne sera pas disponible ailleurs.

  1. Accédez à l’interface de Wazuh par https://<wazuh-dashboard-ip> et renseignez vos credentials tels que donnés dans l’étape précédente.

Déployer un agent

Afin de remonter des informations dans le SIEM WAZUH il faut installer des agents sur les environnements d’exploitation. Wazuh prend en charge Windows, Mac et Linux.

Un exemple de déploiement sur Windows est donné depuis la page de déploiement et requiert l’usage de Powershell en tant qu’administrateur. Une version téléchargeable est également disponible sur le site de wazuh.

Invoke-WebRequest -Uri https://packages.wazuh.com/4.x/windows/wazuh-agent-4.7.3-1.msi -OutFile ${env.tmp}\wazuh-agent; msiexec.exe /i ${env.tmp}\wazuh-agent /q WAZUH_MANAGER='192.168.1.223' WAZUH_AGENT_NAME='MSSQL01' WAZUH_REGISTRATION_SERVER='192.168.1.223'

Dans les lignes précédentes nous installons un agent sur un serveur Windows nommé MSSQL01 et qui va s’enregistrer auprès du serveur Wazuh installé on-premise sur l’IP 192.168.1.223. Il serait envisageable de disposer d’un serveur sous Linux disponible sur Internet directement ou derrière un reverse proxy + certificat.

Sous Windows il n’est même pas nécessaire de spécifier le nom de l’agent étant donné que le nom de la machine devrait potentiellement être unique.

Une fois l’agent installé il reste à démarrer le service wazuhSvc

net start WazuhSvc

Activation de la détection de vulnérabilités

Par défaut la détection de vulnérabilités n’est pas activée. Celle-ci repose sur une activation dans le fichier de configuration de Wazuh Manager ainsi que sur le fait que l’agent doit être redémarré pour que cela soit pris en compte. Sur l’agent, la détection de vulnérabilités est configurée à yes par défaut.

Sur le manager de Wazuh, les configurations se trouvent dans le dossier /var/ossec. Celle qui nous intéresse est /etc/ossec.conf. Le fichier contient le comportement du logiciel : alertes, mail, ports…

Un élément n’est pas activé par défaut : vulnerability-detector. Cherchez-le dans le fichier et passez la valeur à yes.

Redémarrez le service par :

systemctl restart wazuh-manager

Pour les agents il faut relancer le service par

systemctl restart wazuh-agent (linux) service-restart wazuh (windows) ou bien net stop wazuhsvc net start wazuhsvc

Activation de l’intégrité du Système de fichiers

Wazuh est capable de recevoir en quasi temps réel les modifications apportées aux différents systèmes de fichiers, tant Windows que Linux.

Pour Windows, c’est dans le fichier c:Files (x86)-agent.conf

On cherche la section syscheck et on peut ajouter un répertoire personnalisé comme suit

<directories realtime="yes" report_changes="yes" check_all="yes">c:\Users\<your_username>\Desktop</directories>

Il faut ensuite relancer le service Wazuh

PS> Restart-Service Wazuh

De la même façon il est possible de surveiller des clés de la base de registre, toujours en les ajoutant dans ce fichier ossec.conf

Activer les réponses aux attaques

Si, par exemple, vous remarquez un brute force sur un service du genre ssh, comme cela pourrait être fait depuis une machine Kali Linux et la commande

sudo hydra -t 4 -l monlogin -P /usr/share/wordlists/wifile.txt -I @remote_ip_machine ssh

Dans les logs du serveur Wazuh, sur Security events > Events, nous devrions voir apparaître les tentatives de connexion dans la liste. En dépliant cette liste cela nous permet de visualiser les différents paramètres de l’attaque, notamment l’id utilisé pour la connexion ssh.

Pour bloquer directement cette tentative depuis Wazuh, comme le ferait un firewall, se rendre sur le serveur Wazuh > Management > Configuration

Editer la configuration à la recherche du tag . Un template existe en fin de block pour pouvoir écrire de nouvelles réponses aux attaques.

Par exemple :

<active-response>
    <command>firewall-drop</command>
    <location>local</location>
    <rules_id>5710</rules_id>
    <timeout>180</timeout>
</active-response>

On spécifie local dans la réponse car c’est une action qui est gérée localement car nous n’avons qu’un seul master.

Pour récupérer le Rule_id, se rendre sur les agents > Security Events > Events et déplier les informations concernant la tentative de connexion au service ssh. Par défaut cela devrait être 5710.

La valeur timeout précise la durée de blocage en secondes. Dans notre exemple cela rendrait indisponible l’accès ssh de l’attaquant pendant 3 minutes.

Etre alerté en cas d’attaque

Par défaut Wazuh sait envoyer par email une série d’alertes. Mais il est également capable d’être interfacé avec Slack. Il faut lui fournir un WebHook (créé sur Slack) et le rule_id à réceptionner.

Pour cela, se connecter à Slack, dans les apps avec https://api.slack.com/apps

Créer une nouvelle App from Scratch en l’appelant wazuh-alerts et en sélectionnant votre Workspace.

Ce que nous souhaitons réaliser est un Incoming WebHook. Cliquez sur le lien et Activez les incoming webhooks (en haut à droite).

Cliquez ensuite sur le bouton Add new Webhook to Workspace. Sélectionnez le canal wazuh-alerts (créé au départ de l’exemple dans le workspace). Cela nous donne alors le Webhook URL que nous allons transmettre à la configuration de Wazuh Manager.

Editez la configuration de Wazuh et ajoutez les éléments suivants (si aucune section nommée integration n’existe) :

<integration>
    <name>slack</name>
    <hook_url></hook_url> <!-- Mettre la Slack hook URL -->
    <alert_format>json</alert_format>
    <rule_id>5710</rule_id>
</integration>

Tester avec Linux / Windows

Se rendre sur Atomic Red Team

Les tests s’exécutent depuis Powershell, donc compatibles avec Windows ET Linux (en installant le Powershell Core par sudo snap install powershell –classic ou sudo apt install powershell).

PS> Invoke-atomictest

Le test va demander un numéro de technique MITRE, numéro disponible en regardant sur Wazuh > Modules > MITRE & ATT&CK > Framework

L’exécution va se produire en effectuant la technique de hacking spécifiée et cela devrait générer une série d’événements dans Wazuh. Celui-ci étant capable de réagir à des événements par la mise en place de règles de comportement…

Ces règles sont à inscrire dans les fichiers de configuration des différents agents.