Détection d'Intrusion 18 min de lecture

Déployer Wazuh 4.14 sur Linux : détection d'intrusion et réponse automatisée

Déployez Wazuh 4.14 sur vos serveurs Linux : installation pas à pas, surveillance d'intégrité FIM, détection de brute-force SSH, réponse automatisée, règles personnalisées et intégration Suricata.

Editorial TeamRelu par Yuki Tanaka, May 2026
Wazuh 4.14 Linux 2026 : Guide IDS & FIM

Pourquoi la détection d'intrusion est devenue indispensable en 2026

Les pare-feu et le durcissement système ne suffisent plus. Honnêtement, si vous administrez des serveurs Linux exposés à Internet en 2026, vous le savez déjà : le nombre de CVE affectant le noyau Linux dépasse les 5 500 par an, et les campagnes de brute-force SSH automatisées frappent la quasi-totalité des serveurs en moins de 24 heures après leur mise en ligne. Oui, 24 heures.

Face à cette réalité, un système de détection d'intrusion n'est plus un luxe réservé aux grands groupes — c'est une brique fondamentale de toute posture de sécurité digne de ce nom.

C'est là qu'intervient Wazuh. Ce SIEM/XDR open source, fork d'OSSEC maintenu par une communauté très active, réunit dans une seule plateforme la détection d'intrusion basée sur l'hôte (HIDS), la surveillance d'intégrité des fichiers (FIM), l'analyse de vulnérabilités, l'évaluation de conformité et la réponse automatisée aux incidents. Sa dernière version stable, la 4.14.4 (mars 2026), apporte des correctifs de sécurité importants et le support d'AlmaLinux 10, Rocky Linux 10 et Debian 13.

Ce guide vous accompagne du déploiement initial jusqu'à la mise en place de règles de détection personnalisées et de réponses automatiques. Chaque étape inclut des commandes prêtes à copier-coller — adaptez-les à votre infrastructure et vous serez opérationnel rapidement.

Architecture de Wazuh : comprendre les composants

Avant de foncer tête baissée dans l'installation, prenons un moment pour comprendre comment les composants de Wazuh s'articulent entre eux. L'architecture repose sur quatre éléments distincts :

  • Wazuh Manager (serveur) : le cerveau du système. Il reçoit les événements envoyés par les agents, les corrèle avec son moteur de règles, génère les alertes et orchestre les réponses actives. Il écoute sur le port 1514 (TCP/UDP) pour la communication agent et sur le port 55000 pour l'API REST.
  • Wazuh Indexer : basé sur OpenSearch, il stocke et indexe les alertes et les événements. Il fournit les capacités de recherche plein texte et d'analyse en temps quasi réel. Par défaut, il écoute sur le port 9200.
  • Wazuh Dashboard : l'interface web (basée sur OpenSearch Dashboards) pour visualiser les alertes, les vulnérabilités, la conformité CIS/PCI-DSS/RGPD, et gérer les agents. Accessible sur le port 443.
  • Agents Wazuh : des processus légers (~35 Mo de RAM, ce qui est vraiment très peu) installés sur chaque endpoint à surveiller. Ils collectent les logs système, surveillent l'intégrité des fichiers, exécutent les audits de configuration et transmettent le tout au Manager via un canal chiffré.

Pour un déploiement de petite à moyenne taille (jusqu'à environ 100 agents), tous les composants serveur peuvent cohabiter sur une seule machine. Au-delà, il faudra penser à une architecture distribuée avec des nœuds indexeur séparés.

Prérequis matériels et logiciels

Serveur Wazuh (tout-en-un)

Pour un déploiement tout-en-un regroupant le Manager, l'Indexer et le Dashboard :

  • CPU : 4 vCPU minimum (8 recommandé si vous dépassez 50 agents)
  • RAM : 8 Go minimum (16 Go recommandé)
  • Stockage : 50 Go SSD minimum (prévoyez davantage selon la rétention de logs souhaitée)
  • OS : Ubuntu 22.04/24.04 LTS, Debian 12/13, RHEL 8/9, Rocky Linux 9/10, AlmaLinux 9/10
  • Réseau : ports 1514, 1515, 9200, 55000 et 443 accessibles

Agents (endpoints à surveiller)

  • CPU : 1 vCPU suffit largement
  • RAM : 35 Mo en moyenne
  • OS : la plupart des distributions Linux, macOS, Windows, AIX, Solaris

Installation du serveur Wazuh 4.14

Déploiement tout-en-un avec l'assistant d'installation

Bon, passons aux choses sérieuses. L'installation la plus rapide passe par l'assistant officiel qui déploie automatiquement le Manager, l'Indexer et le Dashboard :

# Télécharger et exécuter l'assistant d'installation
curl -sO https://packages.wazuh.com/4.14/wazuh-install.sh
sudo bash wazuh-install.sh -a

L'assistant effectue les étapes suivantes automatiquement :

  1. Vérifie les prérequis système (RAM, espace disque, OS)
  2. Installe et configure le Wazuh Indexer (OpenSearch)
  3. Installe et configure le Wazuh Manager
  4. Installe et configure le Wazuh Dashboard
  5. Génère les certificats TLS pour sécuriser les communications
  6. Affiche les identifiants d'accès au Dashboard

À la fin de l'installation, l'assistant affiche les identifiants de connexion au Dashboard. Notez-les immédiatement — le mot de passe administrateur ne sera pas réaffiché. J'ai déjà vu des collègues devoir relancer toute la procédure pour ça. Vous accéderez ensuite au Dashboard via https://<IP_SERVEUR>:443.

Déploiement avec Docker Compose (alternative)

Si vous préférez les conteneurs (et franchement, c'est souvent plus pratique pour tester), Wazuh fournit une configuration Docker Compose prête à l'emploi :

# Cloner le dépôt officiel Docker
git clone https://github.com/wazuh/wazuh-docker.git -b v4.14.4
cd wazuh-docker/single-node

# Générer les certificats
docker compose -f generate-indexer-certs.yml run --rm generator

# Démarrer la stack complète
docker compose up -d

# Vérifier que tous les conteneurs fonctionnent
docker compose ps

Les trois conteneurs (wazuh.manager, wazuh.indexer, wazuh.dashboard) doivent être à l'état Up. Le Dashboard nécessite généralement une à deux minutes pour s'initialiser complètement — soyez patient.

Vérification post-installation

# Vérifier l'état du Manager
sudo systemctl status wazuh-manager

# Vérifier l'état de l'Indexer
sudo systemctl status wazuh-indexer

# Vérifier l'état du Dashboard
sudo systemctl status wazuh-dashboard

# Tester l'API REST du Manager
curl -k -u admin:<MOT_DE_PASSE> https://localhost:55000/?pretty

Déployer les agents Wazuh sur vos serveurs Linux

Installation d'un agent sur Debian/Ubuntu

# Ajouter le dépôt Wazuh
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 /etc/apt/sources.list.d/wazuh.list

# Installer l'agent en spécifiant l'adresse du Manager
apt update
WAZUH_MANAGER="192.168.1.100" WAZUH_AGENT_NAME="srv-web-01" apt install wazuh-agent

# Activer et démarrer l'agent
systemctl daemon-reload
systemctl enable wazuh-agent
systemctl start wazuh-agent

Installation d'un agent sur RHEL/Rocky/AlmaLinux

# Ajouter le dépôt Wazuh
rpm --import https://packages.wazuh.com/key/GPG-KEY-WAZUH
cat > /etc/yum.repos.d/wazuh.repo << EOF
[wazuh]
gpgcheck=1
gpgkey=https://packages.wazuh.com/key/GPG-KEY-WAZUH
enabled=1
name=EL-\$releasever - Wazuh
baseurl=https://packages.wazuh.com/4.x/yum/
protect=1
EOF

# Installer l'agent
WAZUH_MANAGER="192.168.1.100" WAZUH_AGENT_NAME="srv-db-01" yum install wazuh-agent

# Activer et démarrer
systemctl daemon-reload
systemctl enable wazuh-agent
systemctl start wazuh-agent

Vérifier la connexion de l'agent

# Sur le serveur Wazuh Manager
sudo /var/ossec/bin/agent_control -l

# Ou via l'API REST
curl -k -u admin:<MOT_DE_PASSE> "https://localhost:55000/agents?pretty&sort=-dateAdd"

Chaque agent doit apparaître avec le statut Active. Si un agent reste en Disconnected, vérifiez que le port 1514 est bien ouvert entre l'agent et le Manager, et que l'adresse du Manager est correcte dans /var/ossec/etc/ossec.conf de l'agent. C'est presque toujours un problème de pare-feu, d'expérience.

Configurer la surveillance d'intégrité des fichiers (FIM)

Le module FIM de Wazuh surveille en permanence les fichiers et répertoires critiques de vos serveurs. Toute modification — création, suppression, changement de contenu, de permissions ou de propriétaire — déclenche une alerte.

C'est une capacité essentielle pour détecter les compromissions : un attaquant qui modifie /etc/passwd, /etc/shadow ou un binaire système sera immédiatement repéré. Et croyez-moi, quand ça arrive, on est content d'avoir configuré ça.

Configuration côté agent

Éditez le fichier /var/ossec/etc/ossec.conf de l'agent pour personnaliser les répertoires surveillés :

<syscheck>
  <!-- Fréquence de scan en secondes (ici toutes les 6 heures) -->
  <frequency>21600</frequency>

  <!-- Surveillance en temps réel des répertoires critiques -->
  <directories realtime="yes" check_all="yes">/etc,/usr/bin,/usr/sbin</directories>
  <directories realtime="yes" check_all="yes">/bin,/sbin,/boot</directories>

  <!-- Surveillance des fichiers de configuration web -->
  <directories realtime="yes" check_all="yes">/etc/nginx,/etc/apache2</directories>

  <!-- Surveiller qui effectue les modifications (whodata) -->
  <directories whodata="yes">/etc/ssh</directories>
  <directories whodata="yes">/var/www</directories>

  <!-- Exclure les fichiers temporaires et les logs -->
  <ignore>/etc/mtab</ignore>
  <ignore>/etc/resolv.conf</ignore>
  <ignore type="sregex">^/var/log/</ignore>

  <!-- Alerter sur les nouveaux fichiers -->
  <alert_new_files>yes</alert_new_files>

  <!-- Activer le rapport de modifications -->
  <scan_on_start>yes</scan_on_start>
</syscheck>

Le mode whodata est particulièrement puissant : il utilise le sous-système d'audit Linux (auditd) pour identifier non seulement quelle modification a été faite, mais aussi qui l'a effectuée et quel processus est impliqué. Pour l'investigation post-incident, c'est tout simplement indispensable.

Règles FIM importantes

Wazuh inclut des règles prédéfinies pour le FIM. Voici celles qu'il faut connaître :

  • Règle 550 : intégrité des fichiers vérifiée avec succès (baseline)
  • Règle 553 : fichier supprimé d'un répertoire surveillé
  • Règle 554 : modification non autorisée d'un fichier surveillé
  • Règle 555 : nouveau fichier ajouté dans un répertoire surveillé

Détecter les attaques par brute-force SSH

Les tentatives de brute-force SSH constituent, et de loin, l'attaque la plus fréquente contre les serveurs Linux. Wazuh détecte automatiquement ces attaques grâce à un jeu de règles prédéfinies qui corrèlent les échecs d'authentification successifs.

Comment fonctionne la détection

L'agent Wazuh surveille en continu le fichier /var/log/auth.log (Debian/Ubuntu) ou /var/log/secure (RHEL/Rocky). Quand plusieurs échecs d'authentification se produisent depuis la même adresse IP dans un court intervalle, les règles de corrélation se déclenchent progressivement :

  • Règle 5710 (niveau 5) : tentative de connexion SSH avec un mot de passe invalide
  • Règle 5551 (niveau 10) : multiples échecs d'authentification
  • Règle 5712 (niveau 10) : attaque brute-force SSHD détectée
  • Règle 5763 (niveau 10) : brute-force SSHD — tentative d'accès au système

Par défaut, il faut huit tentatives échouées pour déclencher la règle de brute-force. Ce seuil est configurable, et selon votre environnement, vous voudrez peut-être le baisser à cinq ou six.

Tester la détection

Depuis une machine tierce, simulez une attaque brute-force pour vérifier que tout fonctionne correctement :

# Depuis une machine de test (PAS votre serveur de production !)
for i in $(seq 1 10); do
  ssh -o ConnectTimeout=2 utilisateur_inexistant@IP_SERVEUR_CIBLE 2>/dev/null
done

Vérifiez ensuite les alertes dans le Dashboard Wazuh sous l'onglet Security Events. Vous devriez voir des alertes de niveau 10 correspondant aux règles 5712 ou 5763. Si rien n'apparaît, vérifiez que l'agent lit bien le bon fichier de log d'authentification.

Configurer la réponse automatisée (Active Response)

La détection, c'est bien. La réponse rapide, c'est mieux. Le module Active Response de Wazuh permet d'exécuter automatiquement des scripts de remédiation quand une règle spécifique se déclenche. C'est la différence entre voir une attaque se produire et l'arrêter en temps réel.

Bloquer automatiquement les IP malveillantes

Configurez le Manager (/var/ossec/etc/ossec.conf) pour bloquer automatiquement les adresses IP qui déclenchent une alerte de brute-force :

<!-- Définir la commande de blocage -->
<command>
  <name>firewall-drop</name>
  <executable>firewall-drop</executable>
  <timeout_allowed>yes</timeout_allowed>
</command>

<!-- Configurer la réponse active -->
<active-response>
  <command>firewall-drop</command>
  <location>local</location>
  <rules_id>5763</rules_id>
  <timeout>600</timeout>
</active-response>

Avec cette configuration, dès que la règle 5763 se déclenche, le script firewall-drop (situé dans /var/ossec/active-response/bin/) ajoute automatiquement une règle iptables pour bloquer l'IP de l'attaquant pendant 600 secondes (10 minutes). Après expiration du délai, la règle est automatiquement retirée. Simple et efficace.

Désactiver un compte utilisateur compromis

Wazuh peut aussi désactiver automatiquement un compte local après trop de tentatives échouées sur le terminal :

<command>
  <name>disable-account</name>
  <executable>disable-account</executable>
  <timeout_allowed>yes</timeout_allowed>
</command>

<active-response>
  <command>disable-account</command>
  <location>local</location>
  <rules_id>5551</rules_id>
  <timeout>3600</timeout>
</active-response>

Le compte sera automatiquement réactivé après le délai spécifié. C'est un filet de sécurité particulièrement utile pour les comptes de service — ces comptes qu'on oublie souvent de protéger correctement.

Créer un script de réponse active personnalisé

Pour des besoins spécifiques, vous pouvez écrire vos propres scripts de réponse. Voici un exemple qui envoie une notification Slack lorsqu'un fichier critique est modifié :

#!/bin/bash
# /var/ossec/active-response/bin/slack-notify.sh

LOCAL=$(dirname $0)
cd $LOCAL
cd ../
PWD=$(pwd)

# Lire les paramètres fournis par le Manager
read INPUT_JSON
ALERT_MSG=$(echo $INPUT_JSON | jq -r '.parameters.alert.rule.description')
AGENT_NAME=$(echo $INPUT_JSON | jq -r '.parameters.alert.agent.name')
RULE_ID=$(echo $INPUT_JSON | jq -r '.parameters.alert.rule.id')
TIMESTAMP=$(echo $INPUT_JSON | jq -r '.parameters.alert.timestamp')

SLACK_WEBHOOK="https://hooks.slack.com/services/VOTRE/WEBHOOK/URL"

# Envoyer la notification
curl -s -X POST -H 'Content-type: application/json' \
  --data "{\"text\":\"Alerte Wazuh (règle ${RULE_ID}) sur ${AGENT_NAME} : ${ALERT_MSG} — ${TIMESTAMP}\"}" \
  $SLACK_WEBHOOK

exit 0;
# Rendre le script exécutable
chmod 750 /var/ossec/active-response/bin/slack-notify.sh
chown root:wazuh /var/ossec/active-response/bin/slack-notify.sh

Puis déclarez-le dans la configuration du Manager :

<command>
  <name>slack-notify</name>
  <executable>slack-notify.sh</executable>
  <timeout_allowed>no</timeout_allowed>
</command>

<active-response>
  <command>slack-notify</command>
  <location>server</location>
  <rules_id>554</rules_id>
  <level>10</level>
</active-response>

Écrire des règles de détection personnalisées

Les règles par défaut de Wazuh couvrent la majorité des scénarios courants, mais chaque infrastructure a ses particularités. Les règles personnalisées se placent dans /var/ossec/etc/rules/local_rules.xml sur le Manager.

Voici quelques exemples concrets que j'utilise régulièrement.

Détecter les connexions root directes

<group name="custom_ssh,">

  <!-- Alerte critique si connexion SSH en tant que root -->
  <rule id="100010" level="14">
    <if_sid>5715</if_sid>
    <user>root</user>
    <description>Connexion SSH réussie en tant que root — violation de politique de sécurité.</description>
    <mitre>
      <id>T1078</id>
    </mitre>
    <group>authentication_success,pci_dss_10.2.4,gdpr_IV_32.2,</group>
  </rule>

</group>

Détecter les modifications de crontab

Les attaquants adorent les tâches planifiées pour maintenir leur accès. Cette règle vous prévient immédiatement :

<group name="custom_persistence,">

  <!-- Alerte sur modification de fichiers cron -->
  <rule id="100020" level="12">
    <if_sid>554</if_sid>
    <match>/etc/cron|/var/spool/cron</match>
    <description>Modification détectée dans les fichiers de tâches planifiées (cron). Possible tentative de persistance.</description>
    <mitre>
      <id>T1053.003</id>
    </mitre>
    <group>syscheck,pci_dss_11.5,gdpr_II_5.1.f,</group>
  </rule>

</group>

Détecter l'installation de paquets non autorisée

<group name="custom_software,">

  <!-- Alerte sur installation de paquets via apt -->
  <rule id="100030" level="8">
    <if_sid>2902</if_sid>
    <match>install |apt-get install|dnf install|yum install</match>
    <description>Installation de logiciel détectée. Vérifiez que cette action est autorisée.</description>
    <group>software_change,pci_dss_6.2,</group>
  </rule>

</group>

Valider et appliquer les règles

# Vérifier la syntaxe des règles
sudo /var/ossec/bin/wazuh-logtest

# Redémarrer le Manager pour appliquer
sudo systemctl restart wazuh-manager

# Tester une règle spécifique avec wazuh-logtest
# Collez un extrait de log pour voir quelle règle se déclenche

L'outil wazuh-logtest est indispensable quand vous rédigez des règles personnalisées. Il permet de coller un extrait de log et de voir en temps réel quelle règle se déclencherait — sans avoir à redémarrer le Manager ni attendre un événement réel. Utilisez-le systématiquement avant de déployer une nouvelle règle.

Audit de conformité automatisé avec SCA

Le module Security Configuration Assessment (SCA) de Wazuh audite automatiquement vos systèmes par rapport aux benchmarks CIS et à d'autres standards de sécurité. C'est un complément naturel à la détection d'intrusion : le durcissement réduit la surface d'attaque, l'IDS détecte ce qui passe au travers.

Activer les politiques SCA

Les politiques SCA sont activées par défaut sur les agents. Vérifiez et ajustez la configuration dans /var/ossec/etc/ossec.conf de l'agent :

<sca>
  <enabled>yes</enabled>
  <scan_on_start>yes</scan_on_start>
  <interval>12h</interval>
  <skip_nfs>yes</skip_nfs>

  <!-- Politiques activées -->
  <policies>
    <policy>cis_ubuntu22-04.yml</policy>
    <policy>cis_debian12.yml</policy>
  </policies>
</sca>

Les résultats d'audit SCA apparaissent directement dans le Dashboard Wazuh sous l'onglet Configuration Assessment, avec un score de conformité global et le détail de chaque contrôle (Pass, Fail, Not applicable). C'est un bon point de départ pour planifier le durcissement de vos serveurs.

Intégrer Suricata pour la détection d'intrusion réseau

Wazuh excelle dans la détection basée sur l'hôte (HIDS), mais pour une couverture complète, il faut aussi couvrir le réseau. Suricata est le choix naturel pour ça : ses alertes réseau s'intègrent directement à Wazuh pour une corrélation centralisée.

Installer Suricata

# Sur Debian/Ubuntu
sudo apt install suricata

# Mettre à jour les règles de détection
sudo suricata-update

# Configurer l'interface réseau à surveiller
sudo nano /etc/suricata/suricata.yaml
# Modifier : af-packet > interface: eth0 (adaptez à votre interface)

Configurer l'agent Wazuh pour lire les logs Suricata

Ajoutez la configuration suivante dans le fichier /var/ossec/etc/ossec.conf de l'agent où Suricata est installé :

<ossec_config>
  <localfile>
    <log_format>json</log_format>
    <location>/var/log/suricata/eve.json</location>
  </localfile>
</ossec_config>
# Redémarrer l'agent pour appliquer
sudo systemctl restart wazuh-agent

Wazuh dispose de règles prédéfinies pour les alertes Suricata (groupe de règles suricata). Les alertes réseau apparaîtront dans le Dashboard avec les métadonnées enrichies par le moteur de corrélation. L'ensemble HIDS + NIDS donne une visibilité bien plus complète sur votre infrastructure.

Bonnes pratiques pour un déploiement en production

Sécuriser le serveur Wazuh

  • Changez les mots de passe par défaut immédiatement après l'installation (Dashboard, API, Indexer) — ça paraît évident, mais c'est trop souvent négligé
  • Restreignez l'accès réseau au Dashboard et à l'API via un pare-feu — seuls les administrateurs doivent y accéder
  • Activez l'authentification forte pour l'accès au Dashboard (LDAP, SAML si disponible dans votre environnement)
  • Appliquez le durcissement CIS au serveur Wazuh lui-même — surveiller le surveillant, c'est fondamental

Optimiser la rétention des logs

# Configurer la rétention dans l'Indexer (index state management)
# Par défaut : garder les index 90 jours puis les supprimer
# Adapter selon vos obligations réglementaires (RGPD, PCI-DSS, etc.)

# Vérifier l'espace disque utilisé par les index
curl -k -u admin:<MOT_DE_PASSE> "https://localhost:9200/_cat/indices?v&s=store.size:desc"

Surveiller les performances

  • Surveillez la file d'attente du Manager : si /var/ossec/var/run/wazuh-analysisd.state montre une file d'attente qui se remplit, il est temps d'augmenter les ressources CPU
  • Configurez la rotation des logs du Manager : les fichiers dans /var/ossec/logs/ peuvent grossir vite, surtout avec beaucoup d'agents
  • Au-delà de 200 agents, envisagez sérieusement de séparer l'Indexer sur un nœud dédié

Maintenir Wazuh à jour

# Vérifier la version actuelle
sudo /var/ossec/bin/wazuh-control info | grep WAZUH_VERSION

# Processus de mise à jour (toujours sauvegarder avant !)
sudo cp -r /var/ossec/etc /var/ossec/etc.backup

# Suivre le guide officiel de mise à jour pour votre méthode de déploiement
# https://documentation.wazuh.com/current/upgrade-guide/index.html

FAQ — Questions fréquentes

Wazuh est-il vraiment gratuit pour une utilisation en production ?

Oui, Wazuh est entièrement open source sous licence GPLv2. Il n'y a aucune limitation fonctionnelle ni restriction sur le nombre d'agents. L'entreprise Wazuh, Inc. propose des services de support commercial optionnels et un service cloud hébergé, mais la plateforme autonome est complète et gratuite. Des milliers d'entreprises l'utilisent en production à grande échelle sans débourser un centime en licences.

Combien de serveurs Linux Wazuh peut-il surveiller simultanément ?

Un déploiement monoserveur gère environ 100 à 200 agents avec les prérequis matériels recommandés (8 Go RAM, 4 vCPU). Pour aller plus loin, Wazuh supporte une architecture en cluster avec plusieurs nœuds Manager et Indexer, permettant de surveiller des milliers d'agents. Certaines organisations dépassent les 10 000 endpoints avec Wazuh en mode distribué.

Quelle est la différence entre Wazuh et OSSEC en 2026 ?

Wazuh est un fork d'OSSEC créé en 2015 qui a depuis considérablement évolué. En 2026, OSSEC est essentiellement en mode maintenance (dernière version 3.8.0 de janvier 2021), tandis que Wazuh est activement développé avec la version 4.14.4 de mars 2026. Wazuh ajoute un Dashboard web complet, une API REST, la détection de vulnérabilités, l'intégration native avec le framework MITRE ATT&CK, la conformité réglementaire (RGPD, PCI-DSS, HIPAA), et une architecture en cluster. Pour tout nouveau déploiement, le choix est vite fait.

Wazuh peut-il remplacer un SIEM commercial comme Splunk ou QRadar ?

Pour la plupart des PME et des organisations de taille moyenne, la réponse est oui. Les fonctionnalités de corrélation d'événements, de détection de menaces et de reporting réglementaire de Wazuh rivalisent avec les solutions payantes. Cependant, pour des besoins très avancés en analyse de données massives ou en intégration avec des centaines de sources hétérogènes, un SIEM commercial peut rester pertinent. L'approche hybride — Wazuh pour l'IDS/HIDS et un SIEM commercial pour l'agrégation centralisée — est aussi une option tout à fait viable.

Comment intégrer Wazuh dans un pipeline DevSecOps ?

Wazuh s'intègre naturellement dans une approche DevSecOps : déployez les agents automatiquement via Ansible, Puppet ou Chef lors du provisionnement des serveurs ; utilisez l'API REST pour interroger l'état de sécurité dans vos pipelines CI/CD ; configurez des réponses actives pour bloquer les comportements suspects ; et exportez les alertes vers des outils comme TheHive, Shuffle ou n8n pour l'orchestration de la réponse aux incidents. Le module de détection de vulnérabilités peut aussi servir de porte de qualité dans votre pipeline de déploiement.

À propos de l'auteur Editorial Team

Our team of expert writers and editors.

Articles Connexes