Installer Wazuh sur un VPS Linux : un SIEM et une détection d'intrusion open source pour vos serveurs

Wazuh est une plateforme de sécurité open source qui réunit un SIEM (collecte et corrélation des journaux de sécurité) et une détection d'intrusion sur l'hôte. Un agent léger, installé sur chaque serveur, envoie ses événements à un serveur central : connexions SSH, modifications de fichiers, paquets vulnérables, événements Docker. Le serveur Wazuh les décode, applique ses règles de détection, classe les alertes par niveau de gravité et les rend consultables dans un tableau de bord web. Pour un administrateur qui gère plusieurs VPS, un serveur dédié et quelques serveurs de jeu, c'est la différence entre lire les logs machine par machine en SSH et voir au même endroit qu'une même IP attaque trois serveurs à la fois.

Ce guide montre comment installer Wazuh 4.14 sur un VPS Linux, avec l'assistant officiel ou avec Docker, comment déployer l'agent Wazuh sur vos autres serveurs (Linux et Windows), quelles règles activer en priorité (brute force SSH, intégrité des fichiers, conteneurs Docker) et comment recevoir les alertes par e-mail ou déclencher un blocage automatique.

Sources : démarrage rapide de Wazuh, architecture et ports, déploiement Docker et notes de version.

Wazuh en bref : SIEM, HIDS et XDR open source

Trois sigles reviennent dans tous les comparatifs de sécurité, et Wazuh coche les trois :

• SIEM (Security Information and Event Management) : la collecte centralisée des journaux de sécurité de toutes vos machines, leur stockage, la recherche dans l'historique et la corrélation d'événements pour produire des alertes ;
• HIDS (Host-based Intrusion Detection System) : un système de détection d'intrusion qui travaille sur l'hôte lui-même, à partir de ses journaux, de l'intégrité de ses fichiers et de sa configuration, et non en écoutant le trafic réseau ;
• XDR (Extended Detection and Response) : la détection étendue à plusieurs sources (serveurs, postes, conteneurs, cloud) avec une capacité de réponse. Le projet se présente lui-même comme une protection « XDR et SIEM unifiée » pour les endpoints et les charges de travail cloud.

Dans les comparatifs de SIEM, Wazuh côtoie Microsoft Sentinel (un service cloud), Splunk ou Elastic Security. Sa particularité pour un administrateur de VPS : il est open source, sous licence GPL v2 pour l'essentiel de son code, et s'auto-héberge entièrement sur une seule machine, sans licence à payer par agent. La version courante est la 4.14.10, publiée le 5 novembre 2026.

Une installation Wazuh se compose de quatre éléments, plus un agent par machine surveillée :

Les échanges entre agent et serveur sont chiffrés en AES (clés de 256 bits par défaut). Au-delà de l'analyse des journaux, la documentation liste comme capacités : évaluation de configuration (SCA), détection de malwares, surveillance d'intégrité des fichiers (FIM), détection de vulnérabilités, inventaire des systèmes, threat hunting, réponse aux incidents, conformité réglementaire (PCI DSS, RGPD, HIPAA, NIST 800-53 : les règles portent leurs références) et sécurité des conteneurs.

Wazuh, CrowdSec, auditd, Fail2ban : qui fait quoi

Nous avons déjà publié des guides sur CrowdSec, auditd et Fail2ban. Ces outils parlent tous de détection d'intrusion, mais ils ne font pas le même travail :

En résumé : CrowdSec et Fail2ban bloquent, auditd journalise, Wazuh centralise et corrèle. Huit échecs d'authentification SSH depuis la même IP en deux minutes sur un serveur, ce sont des entrées de journal pour auditd, un bannissement pour Fail2ban, et pour Wazuh une alerte de niveau 10 (règle 5763) visible à côté de tout ce qui s'est passé sur vos autres machines. Ces outils se combinent : sous Linux, le mode whodata de Wazuh s'appuie justement sur auditd pour savoir quel utilisateur et quel processus ont modifié un fichier. Si CrowdSec bloque déjà les attaques sur un serveur, laissez Wazuh observer plutôt que d'activer deux mécanismes de blocage sur la même règle.

Prérequis : quel VPS pour le serveur Wazuh

Le serveur central fait tourner trois composants sur la même machine (installation dite tout-en-un). La documentation de démarrage rapide donne ce dimensionnement, pour 90 jours d'alertes indexées :

Au-delà, la documentation recommande un déploiement distribué, avec l'indexeur sur ses propres nœuds. Quelques repères pour bien choisir :

• 4 Go de RAM, c'est le minimum documenté pour l'indexeur seul (16 Go recommandés, avec 2 cœurs au minimum et 8 recommandés). En tout-en-un, l'indexeur partage cette mémoire avec le serveur et le dashboard : 4 Go permettent un test, 8 Go sont la base documentée pour surveiller jusqu'à 25 serveurs.
• Le stockage dépend du volume d'alertes : la documentation de l'indexeur compte environ 3,7 Go par serveur surveillé pour 90 jours (1,5 Go pour un poste de travail). Dix serveurs, c'est donc environ 37 Go de données, plus le système.
• Système d'exploitation : la documentation 4.14 liste Ubuntu 16.04 à 24.04, Red Hat Enterprise Linux 7 à 10, CentOS Stream 10 et Amazon Linux 2 et 2023, en x86_64 ou ARM64. Debian ne figure pas dans cette liste pour les composants centraux : prenez Ubuntu 24.04 LTS pour le VPS Wazuh. Les agents, eux, s'installent sur Debian comme sur Ubuntu.
• Une machine dédiée à ce rôle : n'installez pas le serveur Wazuh sur le VPS qui fait tourner votre serveur de jeu. L'indexeur consomme la mémoire dont le jeu a besoin, et si ce serveur est compromis, l'attaquant a la main sur les journaux qui devaient le trahir.
• Un accès root, une adresse IP fixe ou un nom de domaine pour le serveur, et les ports listés plus bas.

Chez ElypseCloud, le VPS Linux Classic (4 vCPU, 8 Go de RAM, 70 Go SSD) correspond au profil documenté pour 1 à 25 agents. Le VPS Linux Pro (6 vCPU, 16 Go de RAM, 100 Go SSD) atteint les 16 Go recommandés pour l'indexeur et laisse de la marge pour allonger la rétention. Au-delà d'une centaine de machines, un serveur dédié accueille un déploiement distribué dans des machines virtuelles.

Installer Wazuh avec l'assistant officiel (tout-en-un)

L'assistant d'installation wazuh-install.sh installe et configure le serveur, l'indexeur et le dashboard sur la même machine, avec des certificats auto-signés. Sur un VPS Ubuntu 24.04 fraîchement installé et à jour :

sudo apt update && sudo apt upgrade -y
curl -sO https://packages.wazuh.com/4.14/wazuh-install.sh && sudo bash ./wazuh-install.sh -a

L'option -a (all-in-one) déploie les trois composants. À la fin, l'assistant affiche un résumé avec l'adresse du dashboard, l'utilisateur admin et son mot de passe généré. Si vous l'avez perdu, il se trouve dans le fichier wazuh-passwords.txt de l'archive wazuh-install-files.tar, créée dans le dossier où vous avez lancé l'assistant :

sudo tar -O -xvf wazuh-install-files.tar wazuh-install-files/wazuh-passwords.txt

Cette archive contient tous les mots de passe et les certificats de l'installation : ne la laissez pas dans un dossier lisible par d'autres utilisateurs. Connectez-vous ensuite à https://adresse-du-vps (port 443) avec le compte admin. Le navigateur signale un certificat non reconnu : c'est normal avec les certificats auto-signés, vous pouvez accepter l'exception ou installer un certificat de confiance.

Bloquer les mises à jour accidentelles

La documentation recommande de désactiver le dépôt Wazuh après l'installation : un apt upgrade de routine pourrait mettre à jour un composant sans les autres et casser l'ensemble.

sudo sed -i "s/^deb /#deb /" /etc/apt/sources.list.d/wazuh.list
sudo apt update

Vous réactiverez le dépôt le jour où vous déciderez de passer à une nouvelle version, en suivant le guide de mise à jour de Wazuh, composant par composant. Gardez cette mise à jour à l'esprit dans votre routine de mises à jour de sécurité : un SIEM non maintenu devient lui-même une cible.

Changer le mot de passe admin

L'outil wazuh-passwords-tool.sh, livré avec l'indexeur, change le mot de passe d'un utilisateur et met à jour les composants qui l'utilisent :

sudo bash /usr/share/wazuh-indexer/plugins/opensearch-security/tools/wazuh-passwords-tool.sh -u admin -p 'N0uveau*MotDePasse'

Le mot de passe doit faire de 8 à 64 caractères, avec au moins une majuscule, une minuscule, un chiffre et un des symboles . * + ? -. Sans l'option -p, l'outil en génère un aléatoire.

Variante : installer Wazuh avec Docker (single-node)

Si votre VPS fait déjà tourner Docker et Docker Compose, le dépôt wazuh-docker fournit une pile single-node prête à l'emploi. La documentation demande au moins 4 cœurs, 8 Go de RAM et 50 Go de disque pour l'hôte Docker. L'indexeur exige d'abord un réglage du noyau, vm.max_map_count à 262144 au minimum :

sudo sysctl -w vm.max_map_count=262144
echo "vm.max_map_count=262144" | sudo tee /etc/sysctl.d/99-wazuh-max-map-count.conf
sudo sysctl --system

Clonez ensuite la version voulue, générez les certificats, puis démarrez la pile :

git clone https://github.com/wazuh/wazuh-docker.git -b v4.14.10
cd wazuh-docker/single-node/
docker compose -f generate-indexer-certs.yml run --rm generator
docker compose up -d

L'indexeur met environ une minute à démarrer : les erreurs de connexion affichées pendant ce délai sont normales. Le dashboard répond ensuite sur https://adresse-du-vps, avec l'utilisateur admin et le mot de passe par défaut SecretPassword, à changer immédiatement. La procédure documentée, depuis le dossier single-node :

1. déconnectez-vous du dashboard, puis arrêtez la pile avec docker compose down ;
2. générez le hash du nouveau mot de passe : docker run --rm -ti wazuh/wazuh-indexer:4.14.10 bash /usr/share/wazuh-indexer/plugins/opensearch-security/tools/hash.sh ;
3. remplacez le hash du bloc admin dans config/wazuh_indexer/internal_users.yml ;
4. remplacez SecretPassword dans les variables INDEXER_PASSWORD des services wazuh.manager et wazuh.dashboard du fichier docker-compose.yml (doublez tout caractère $) ;
5. relancez avec docker compose up -d, entrez dans le conteneur de l'indexeur (docker exec -it single-node-wazuh.indexer-1 bash) et appliquez la configuration de sécurité avec securityadmin.sh, comme le détaille la page « Changing the default password » de la documentation.

Attention au pare-feu : la pile publie les ports 443, 1514, 1515, 514/UDP, 55000 et 9200 sur toutes les interfaces, et les ports publiés par Docker contournent les règles UFW. Pour garder l'API (55000) et l'indexeur (9200) hors d'atteinte, liez-les à l'adresse locale dans docker-compose.yml (par exemple "127.0.0.1:9200:9200") ou filtrez-les dans la chaîne DOCKER-USER.

Ouvrir uniquement les ports nécessaires

Un SIEM exposé à tout Internet est une mauvaise idée : il contient l'historique de sécurité de toutes vos machines. Voici les ports du serveur Wazuh selon la documentation d'architecture, et à qui les ouvrir :

Avec UFW, sur une installation par l'assistant (adaptez les adresses : 203.0.113.10 et 203.0.113.11 sont deux serveurs surveillés, 198.51.100.50 votre IP d'administration) :

sudo ufw allow OpenSSH
sudo ufw allow proto tcp from 203.0.113.10 to any port 1514,1515
sudo ufw allow proto tcp from 203.0.113.11 to any port 1514,1515
sudo ufw allow proto tcp from 198.51.100.50 to any port 443
sudo ufw enable

Notre guide ouvrir des ports avec UFW détaille la syntaxe. Plus simple encore pour le dashboard : ne l'ouvrez qu'à un réseau privé comme Tailscale, et faites aussi passer les agents par ce réseau. Vérifiez enfin ce qui écoute réellement avec ss -tlnp (voir lister les ports en écoute avec ss).

Déployer l'agent Wazuh sur vos VPS et serveurs de jeu

L'agent Wazuh s'installe sur chaque machine à surveiller : vos autres VPS, votre serveur dédié, et les machines qui font tourner vos serveurs de jeu (Minecraft, FiveM, Rust). La documentation annonce une consommation de 35 Mo de RAM en moyenne, ce qui reste négligeable à côté d'un serveur de jeu. L'agent a besoin d'un accès root : il concerne les serveurs de jeu que vous administrez vous-même sur un VPS ou un dédié, pas une offre gérée depuis un panel, où vous n'avez pas la main sur le système.

Créer un groupe d'agents

Les groupes permettent d'appliquer une configuration commune à plusieurs agents (par exemple, les dossiers à surveiller sur tous vos serveurs de jeu). Le groupe doit exister avant l'enrôlement. Sur le serveur Wazuh :

sudo /var/ossec/bin/agent_groups -a -g serveurs-jeu -q

Agent Linux (Debian, Ubuntu)

Sur chaque serveur à surveiller, en root (sudo -i), ajoutez le dépôt Wazuh puis installez l'agent en lui indiquant l'adresse du serveur, son nom et son groupe :

apt-get install gnupg apt-transport-https curl
curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | gpg --no-default-keyring --keyring gnupg-ring:/usr/share/keyrings/wazuh.gpg --import && 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" | tee -a /etc/apt/sources.list.d/wazuh.list
apt-get update
WAZUH_MANAGER="203.0.113.5" WAZUH_AGENT_NAME="mc-survie-01" WAZUH_AGENT_GROUP="serveurs-jeu" apt-get install wazuh-agent
systemctl daemon-reload
systemctl enable wazuh-agent
systemctl start wazuh-agent

WAZUH_MANAGER est l'IP ou le nom du serveur Wazuh (ici 203.0.113.5), WAZUH_AGENT_NAME le nom affiché dans le dashboard (par défaut, le nom de la machine), WAZUH_AGENT_GROUP un ou plusieurs groupes existants séparés par des virgules. Sans WAZUH_MANAGER, l'agent s'installe sans s'enrôler. Bloquez ensuite le paquet : la compatibilité n'est garantie que si la version du serveur est supérieure ou égale à celle de l'agent, et un agent mis à jour avant le serveur peut décrocher.

echo "wazuh-agent hold" | dpkg --set-selections

Agent Windows (VPS Windows, serveur de jeu sous Windows)

Sur un VPS Windows, dans un PowerShell administrateur :

Invoke-WebRequest -Uri https://packages.wazuh.com/4.x/windows/wazuh-agent-4.14.10-1.msi -OutFile wazuh-agent-4.14.10-1.msi
msiexec.exe /i wazuh-agent-4.14.10-1.msi /q WAZUH_MANAGER="203.0.113.5"
Start-Service wazuhsvc

La documentation couvre les versions de Windows jusqu'à Windows 11 et Windows Server 2025. Les tentatives RDP échouées y remontent aussi : la preuve de concept officielle les détecte avec les règles 60122 et 60204.

Vérifier que les agents sont connectés

sudo /var/ossec/bin/agent_control -lc

-lc liste les agents connectés, -l tous les agents enregistrés, actifs ou non. Dans le dashboard, chaque agent apparaît avec son système, son groupe et son état.

Règles utiles : brute force SSH, intégrité des fichiers, Docker

Wazuh arrive avec un jeu de règles prêt à l'emploi. Les règles personnalisées se placent sur le serveur dans /var/ossec/etc/rules/local_rules.xml, avec des identifiants entre 100000 et 120000 pour ne pas entrer en conflit avec les règles fournies. Trois familles méritent votre attention dès le premier jour.

Brute force SSH

Les règles sshd sont actives sans configuration. Celles qui comptent, d'après le ruleset 4.14.10 :

Pour vérifier la chaîne de bout en bout, tentez depuis une autre machine une connexion SSH avec un utilisateur qui n'existe pas, puis cherchez rule.id:5710 dans le module Threat Hunting du dashboard. Pour retrouver les attaques par force brute : rule.id:(5712 OR 5763). Si rien ne remonte, vérifiez dans le bloc <localfile> de /var/ossec/etc/ossec.conf que l'agent lit bien le journal où sshd écrit. La règle 5715 a aussi son intérêt : une connexion réussie depuis une IP inconnue, juste après une série d'échecs, est exactement ce qu'un SIEM aide à voir. Pour réduire le bruit à la source, appliquez notre guide sécuriser SSH, et pour lire ces échecs à la main, analyser les échecs de connexion SSH.

Modifications de fichiers (FIM)

Le module de surveillance d'intégrité des fichiers (FIM, ou syscheck) calcule les empreintes des fichiers surveillés et signale tout ajout, modification ou suppression. Par défaut, il repasse toutes les 12 heures (frequency de 43200 secondes). Pour le dossier des plugins ou des ressources d'un serveur de jeu, un des chemins classiques d'une porte dérobée, passez en temps réel. Sur l'agent, ajoutez dans le bloc <syscheck> de /var/ossec/etc/ossec.conf :

<directories realtime="yes" check_all="yes" report_changes="yes">/home/minecraft/serveur/plugins</directories>
<directories check_all="yes" whodata="yes">/etc</directories>

Adaptez le chemin : plugins/ d'un serveur Paper, resources/ d'un serveur FiveM, oxide/plugins/ d'un serveur Rust sous Oxide. Trois précisions de la documentation :

• realtime ne s'applique qu'aux dossiers, et le dossier doit exister avant le redémarrage de l'agent ;
• report_changes conserve une copie des fichiers texte surveillés dans /var/ossec/queue/diff/ pour afficher le contenu modifié : à réserver à des dossiers de petite taille ;
• whodata ajoute l'utilisateur et le processus à l'origine du changement. Sous Linux, il s'appuie sur auditd : installez auditd (et audispd-plugins avec Audit 3.1.1 ou plus récent), puis vérifiez la règle posée par l'agent avec auditctl -l | grep wazuh_fim.

Redémarrez l'agent (systemctl restart wazuh-agent). Les alertes FIM utilisent les règles 550 (fichier modifié, niveau 7), 553 (fichier supprimé, niveau 7) et 554 (fichier ajouté, niveau 5). Pour qu'une modification des plugins de jeu sorte du lot et déclenche un e-mail, relevez son niveau à 12 avec deux règles personnalisées sur le serveur, dans /var/ossec/etc/rules/local_rules.xml :

<group name="syscheck,">
  <rule id="100210" level="12">
    <if_sid>550</if_sid>
    <field name="file">/home/minecraft/serveur/plugins</field>
    <description>Plugin du serveur de jeu modifié : $(file)</description>
  </rule>
  <rule id="100211" level="12">
    <if_sid>554</if_sid>
    <field name="file">/home/minecraft/serveur/plugins</field>
    <description>Fichier ajouté dans les plugins du serveur de jeu : $(file)</description>
  </rule>
</group>

Puis sudo systemctl restart wazuh-manager. Ce n'est plus une simple modification de fichier noyée dans la masse, c'est une alerte de haute importance.

Événements Docker

Sur un hôte qui fait tourner des conteneurs, le module docker-listener de l'agent remonte les événements Docker. Il demande Python 3.8 à 3.13 et la bibliothèque Python Docker 7.1.0, à installer sur l'agent (le serveur l'embarque déjà) :

pip3 install docker==7.1.0 urllib3==1.26.20 requests==2.32.2

Avec Python 3.11 ou 3.12 (Debian 12, Ubuntu 24.04), la documentation ajoute l'option --break-system-packages, qui modifie l'environnement Python du système. Ajoutez ensuite dans /var/ossec/etc/ossec.conf de l'agent, puis redémarrez-le :

<wodle name="docker-listener">
  <interval>10m</interval>
  <attempts>5</attempts>
  <run_on_start>no</run_on_start>
  <disabled>no</disabled>
</wodle>

La règle 87908 est la plus parlante : un shell ouvert dans le conteneur de votre serveur de jeu ou de votre base de données, à une heure où personne de l'équipe ne travaille, mérite une explication.

Recevoir les alertes : niveaux, e-mail et réponse active

Les niveaux d'alerte

Chaque règle a un niveau de 0 à 16 ; le niveau 16 n'est utilisé par aucune règle fournie et reste disponible pour vos règles personnalisées. Repères tirés de la classification officielle : 0 = ignoré, 3 = événement réussi ou autorisé, 5 = erreur générée par un utilisateur, 7 = correspondance avec un « mot interdit », 10 = erreurs multiples d'un utilisateur, 12 = événement de haute importance, 15 = attaque sévère. Deux seuils pilotent la suite : log_alert_level (3 par défaut), en dessous duquel un événement n'est pas enregistré comme alerte, et email_alert_level (12 par défaut), à partir duquel une alerte part par e-mail.

Les alertes par e-mail

Sur le serveur, dans /var/ossec/etc/ossec.conf :

<global>
  <email_notification>yes</email_notification>
  <smtp_server>localhost</smtp_server>
  <email_from>wazuh@votre-domaine.fr</email_from>
  <email_to>admin@votre-domaine.fr</email_to>
</global>
<alerts>
  <email_alert_level>12</email_alert_level>
</alerts>

Wazuh ne gère pas l'authentification SMTP. Si votre fournisseur de messagerie l'exige, installez Postfix sur le serveur Wazuh comme relais local authentifié, et laissez smtp_server sur localhost, comme le décrit la documentation. Redémarrez ensuite le serveur avec sudo systemctl restart wazuh-manager. Avec les règles personnalisées de niveau 12 vues plus haut, vous recevez un e-mail à chaque modification des plugins de jeu. Pour les alertes de disponibilité (serveur éteint, disque plein), complétez avec notre guide alertes et monitoring d'un VPS Linux : Wazuh surveille la sécurité, pas l'état de santé de vos services.

La réponse active : bloquer automatiquement

Wazuh peut aussi agir. La réponse active firewall-drop bloque avec iptables, sur la machine attaquée, l'IP qui a déclenché une règle. Sur le serveur, dans /var/ossec/etc/ossec.conf :

<active-response>
  <disabled>no</disabled>
  <command>firewall-drop</command>
  <location>local</location>
  <rules_id>5763</rules_id>
  <timeout>180</timeout>
</active-response>

Après sudo systemctl restart wazuh-manager, chaque déclenchement de la règle 5763 bloque l'IP source pendant 180 secondes sur l'agent concerné (location à local). L'action est consignée dans /var/ossec/logs/active-responses.log sur l'agent, et une alerte « Host Blocked by firewall-drop Active Response » (règle 651) apparaît dans le dashboard. La commande firewall-drop doit être définie dans un bloc <command> du même fichier. Testez depuis une IP qui n'est pas la vôtre, et si CrowdSec ou Fail2ban bloquent déjà sur ce serveur, gardez un seul mécanisme de blocage.

Erreurs fréquentes avec Wazuh

• Sous-dimensionner la RAM : 4 Go est le plancher de l'indexeur seul. En tout-en-un avec des agents en production, partez sur 8 Go.
• Laisser le dépôt actif : une mise à jour partielle casse la pile, et un agent plus récent que le serveur n'est plus garanti compatible.
• Exposer 9200 et 55000 : l'indexeur et l'API n'ont rien à faire sur Internet. Avec Docker, souvenez-vous que les ports publiés contournent UFW.
• Garder SecretPassword sur une installation Docker : c'est le mot de passe par défaut documenté publiquement.
• Oublier le disque : à 3,7 Go par serveur pour 90 jours, un VPS trop juste se remplit et l'indexeur ne peut plus enregistrer les alertes. Surveillez l'espace libre.
• Activer report_changes sur de gros dossiers : chaque fichier texte surveillé est copié dans /var/ossec/queue/diff/.
• Installer le serveur Wazuh sur la machine qu'il surveille : un attaquant qui prend la main sur le serveur de jeu ne doit pas pouvoir effacer les traces centralisées.

En résumé

Wazuh 4.14 transforme un VPS Linux en SIEM et en console de détection d'intrusion pour tous vos serveurs. Installez le serveur, l'indexeur et le dashboard avec wazuh-install.sh -a sur Ubuntu 24.04 (ou avec la pile Docker single-node), sur une machine d'au moins 4 vCPU et 8 Go de RAM pour 25 agents. N'ouvrez que 1514 et 1515 à vos serveurs et 443 à vos IP d'administration, déployez l'agent avec WAZUH_MANAGER sur vos VPS, votre dédié et vos serveurs de jeu, puis activez les trois familles de règles utiles : brute force SSH (5712, 5763), intégrité des fichiers en temps réel sur les dossiers sensibles, événements Docker. Réglez enfin les alertes par e-mail à partir du niveau 12 et, si aucun autre outil ne bloque déjà, la réponse active firewall-drop. CrowdSec et Fail2ban continuent de bloquer, auditd de journaliser : Wazuh centralise et corrèle.