📍 Article principal de la série : Wazuh 2026 : guide pratique.

Wazuh installé, agents déployés. Étape suivante : activer FIM (File Integrity Monitoring) et scan vulnérabilités CVE pour transformer monitoring passif en détection proactive. Ce tutoriel détaille les configurations validées en production.

Prérequis

Wazuh Manager + agents en production.
Niveau attendu : intermédiaire/avancé.
Temps estimé : 1 heure.

FIM : surveillance fichiers critiques

Étape 1 — Comprendre la stratégie

FIM surveille modifications (create, modify, delete) sur fichiers/dossiers définis. Alerte en temps réel ou quotidienne. Critique pour :

Fichiers système : /etc/passwd, /etc/shadow, /etc/sudoers.
Configurations : /etc/ssh/sshd_config, /etc/nginx/, /etc/caddy/.
Code applicatif : /var/www/, /srv/apps/.
Logs sensibles : /var/log/auth.log.

Étape 2 — Configuration FIM dans ossec.conf

Sur chaque agent (ou via central config Manager) :

nano /var/ossec/etc/ossec.conf

<syscheck>
  <disabled>no</disabled>
  <frequency>43200</frequency>  <!-- 12h scan complet -->
  
  <!-- Real-time monitoring -->
  <directories realtime="yes" check_all="yes" report_changes="yes">/etc</directories>
  <directories realtime="yes" check_all="yes" report_changes="yes">/var/www</directories>
  <directories realtime="yes" check_all="yes">/srv/apps</directories>
  
  <!-- Scan régulier -->
  <directories check_all="yes">/usr/bin</directories>
  <directories check_all="yes">/usr/sbin</directories>
  
  <!-- Exclusions -->
  <ignore>/etc/mtab</ignore>
  <ignore>/etc/hosts.deny</ignore>
  <ignore type="sregex">.log$|.swp$|.tmp$</ignore>
  
  <!-- Audit Linux : qui a modifié -->
  <whodata>yes</whodata>
</syscheck>

systemctl restart wazuh-agent

Étape 3 — Test FIM

echo "test" >> /etc/test-fim.txt
# Attendre 30 secondes

Dashboard → Modules → Integrity Monitoring → voir alerte.

Étape 4 — Alerte critique sur fichiers sensibles

Custom rule pour alerter level 12 sur /etc/sudoers :

# /var/ossec/etc/rules/local_rules.xml
<group name="syscheck,">
  <rule id="100100" level="12">
    <if_sid>550,553,554</if_sid>
    <match>/etc/sudoers</match>
    <description>Critical: sudoers file modified</description>
    <mitre>
      <id>T1548.003</id>
    </mitre>
  </rule>
</group>

Vulnerability scanning

Étape 5 — Activer Vulnerability Detector

nano /var/ossec/etc/ossec.conf

<vulnerability-detector>
  <enabled>yes</enabled>
  <interval>5m</interval>
  <run_on_start>yes</run_on_start>
  
  <provider name="canonical">
    <enabled>yes</enabled>
    <os>jammy</os>
    <os>noble</os>
    <update_interval>1h</update_interval>
  </provider>
  
  <provider name="debian">
    <enabled>yes</enabled>
    <os>bookworm</os>
  </provider>
  
  <provider name="redhat">
    <enabled>yes</enabled>
  </provider>
  
  <provider name="nvd">
    <enabled>yes</enabled>
    <update_from_year>2018</update_from_year>
  </provider>
</vulnerability-detector>

systemctl restart wazuh-manager

Étape 6 — Premier scan

Attendre 30-60 minutes pour téléchargement des feeds NVD + Canonical + Debian.

Dashboard → Modules → Vulnerabilities → voir tous CVE détectés par endpoint.

Étape 7 — Filtrer par sévérité

Dashboard offre filtres : Critical, High, Medium, Low. Pour PME, prioriser Critical et High avec score CVSS > 7.

Étape 8 — Action sur CVE détecté

Pour chaque CVE Critical :

Lire le report : package affecté, version actuelle, version corrigée.
Vérifier patch disponible : apt list --upgradable.
Planifier patch dans fenêtre maintenance.
Appliquer et vérifier nouveau scan.

Erreurs fréquentes

Erreur	Cause	Solution
FIM CPU élevé	Trop de fichiers scannés realtime	Whitelist /var/log et /tmp
Whodata ne marche pas	auditd absent	apt install auditd
Vulnerability feed manquant	Internet bloqué Manager	UFW allow outbound 443
NVD scan slow	Première fois	Patientez 1-2 heures
Faux positifs CVE	Package backporté distro	Whitelist par CVE ID
FIM alertes inondées	Logs apps en /var/log/apps	Exclure pattern

À l’épreuve du contexte sénégalais

Trois précisions. Patch management : pour PME africaine sans équipe dédiée, programme patch tuesday + alerte Wazuh = workflow simple. Conformité ARTCI : rapport CVE mensuel + actions patch documentées = preuve diligence pour audit. Code custom monitoring : FIM sur /srv/apps détecte si attaquant injecte webshell après compromission.

Tutoriels frères

FAQ

Differential FIM coût RAM ? 50-100 Mo par 100 000 fichiers monitorés.

Scan vulnerability fréquence ? Toutes les 5 minutes interval. Mais nouveau CVE = re-scan endpoint.

Whitelist CVE faux positif ? Yes via custom rule level 0 sur CVE ID.

NIST CVSS v4 ? Wazuh 4.10+ supporte CVSS v3.1, v4 en bêta.

Active Directory FIM Windows ? Oui, monitoring registry + fichiers GPO.

Pour creuser ce sujet

🔝 Retour au guide général : guide pratique Wazuh 2026
Documentation FIM : documentation.wazuh.com/fim

Un hébergeur abordable pour vos projets

Hostinger combine prix raisonnable et stabilité. Lien partenaire — pas de surcoût pour vous.

Choisir une offre →

Lien d affiliation. Si vous achetez via ce lien, le blog reçoit une petite commission sans surcoût pour vous.

Étape 1 : Préparer un serveur Wazuh dimensionné pour 50 endpoints

Wazuh 4.10 manager exige au minimum 4 vCPU et 8 Go de RAM pour 50 endpoints surveillés en temps réel. Provisionnez un VPS Hetzner CX32 à 7,55 EUR mensuel, soit environ 4 953 FCFA, ou une machine on-premise équivalente dans un datacenter Sénélec stable de Diamniadio.

Allouez un disque de 200 Go : Wazuh archive les événements pendant 90 jours par défaut et un endpoint actif génère environ 3 Mo de logs par jour. Au-delà, basculez vers un stockage Wasabi à 6,99 USD le To et par mois pour les archives froides.

Étape 2 : Installer Wazuh manager via le script all-in-one

Le script officiel installe en une commande le manager, l’indexer OpenSearch et le dashboard. Comptez 18 minutes sur un VPS standard et environ 6,5 Go d’espace disque consommé après installation complète.

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

Le script affiche à la fin les identifiants admin du dashboard accessible sur https://votre-ip. Stockez-les immédiatement dans un gestionnaire de mots de passe Vaultwarden : ils n’apparaîtront plus jamais.

Étape 3 : Déployer l’agent Wazuh sur les postes Windows et Linux

Téléchargez le MSI Windows ou le DEB Ubuntu depuis le dashboard, section Agents puis Deploy new agent. Le wizard génère la commande d’enrôlement avec la clé pré-partagée correcte pour votre manager.

# Linux Ubuntu
curl -so wazuh-agent.deb https://packages.wazuh.com/4.x/apt/pool/main/w/wazuh-agent/wazuh-agent_4.10.0-1_amd64.deb
sudo WAZUH_MANAGER='10.0.0.1' WAZUH_AGENT_GROUP='default' dpkg -i ./wazuh-agent.deb
sudo systemctl enable --now wazuh-agent

L’agent apparaît dans le dashboard sous deux minutes. S’il reste en statut Disconnected au-delà de cinq minutes, vérifiez le pare-feu UDP 1514 et 1515 entre l’endpoint et le manager.

Étape 4 : Activer le module File Integrity Monitoring (FIM)

FIM surveille en temps réel les modifications de fichiers sensibles via inotify sur Linux et la Windows Audit API. Éditez /var/ossec/etc/ossec.conf pour ajouter les répertoires critiques de votre stack applicative.

<syscheck>
  <directories check_all="yes" realtime="yes">/etc,/usr/bin,/usr/sbin</directories>
  <directories check_all="yes" realtime="yes" report_changes="yes">/var/www</directories>
  <ignore>/etc/mtab</ignore>
</syscheck>

L’option report_changes capture le diff complet des fichiers texte modifiés, idéal pour les sites WordPress. Sur Windows, ajoutez C:\Windows\System32\drivers et le dossier d’installation de votre logiciel comptable.

Étape 5 : Tester FIM avec une modification volontaire

Pour valider que FIM remonte bien les alertes, modifiez un fichier sous /etc puis surveillez le dashboard. L’alerte doit apparaître dans les huit secondes en mode realtime.

sudo touch /etc/test-fim.txt
sudo echo "test" > /etc/test-fim.txt

Dans le dashboard Wazuh, naviguez vers Modules puis Integrity monitoring. Vous voyez l’événement avec le nom du fichier, l’utilisateur ayant modifié, et le hash SHA-256 avant et après. Si rien n’apparaît, vérifiez ossec-syscheckd dans /var/ossec/logs/ossec.log.

Étape 6 : Activer le scan de vulnérabilités CVE

Le module Vulnerability Detector compare l’inventaire des paquets installés avec les bases CVE Canonical, Red Hat, Debian et NVD. Activez-le dans la configuration manager pour bénéficier d’un rapport quotidien.

<vulnerability-detection>
  <enabled>yes</enabled>
  <index-status>yes</index-status>
  <feed-update-interval>60m</feed-update-interval>
</vulnerability-detection>

Le premier scan prend deux à trois heures car Wazuh télécharge environ 800 Mo de feeds CVE. Ensuite, les scans incrémentaux durent moins de cinq minutes par endpoint et tournent automatiquement chaque nuit à 3h.

Étape 7 : Prioriser les CVE critiques avec les filtres CVSS

Une instance Wazuh standard remonte facilement 200 à 400 CVE sur un parc de 50 machines. Filtrez par score CVSS supérieur à 7,0 et statut Active pour ne traiter que les vulnérabilités exploitées dans la nature.

Créez un dashboard custom qui affiche le top 10 des CVE par nombre d’endpoints touchés. Vous concentrez vos patchs sur les vulnérabilités à fort impact plutôt que de courir après chaque alerte mineure, méthode qui épuise les équipes IT en six mois.

Étape 8 : Automatiser les alertes vers Slack ou Telegram

Configurez l’intégration native Wazuh vers Slack pour recevoir en temps réel les alertes critiques. Créez un webhook entrant Slack puis ajoutez-le dans /var/ossec/etc/ossec.conf section integration.

<integration>
  <name>slack</name>
  <hook_url>https://hooks.slack.com/services/T0000/B0000/XXXX</hook_url>
  <level>10</level>
  <alert_format>json</alert_format>
</integration>

Le niveau 10 ne déclenche que pour les événements de gravité élevée comme les modifications de /etc/passwd ou les CVE critiques. Évitez le niveau 5 qui inonderait votre canal de notifications de bas niveau et provoquerait l’effet inverse, à savoir l’inattention progressive.

Étape 9 : Sauvegarder la base d’événements vers Wasabi

Les indices OpenSearch grossissent vite : comptez 30 Go par mois pour 50 endpoints. Programmez un snapshot hebdomadaire chiffré vers un bucket Wasabi pour garder une archive long terme à coût maîtrisé.

0 4 * * 0 /usr/share/wazuh-indexer/bin/opensearch-snapshot create wasabi-repo --indices wazuh-alerts-* --include-global-state false

Vous pouvez restaurer un snapshot vieux de deux ans en moins de quinze minutes pour répondre à une investigation forensique. Conservez douze snapshots glissants soit environ trois mois en chaud puis purgez les plus anciens vers Glacier.

Étape 10 : Documenter le runbook d’incident sécurité

Rédigez un runbook d’une page qui décrit la procédure quand une alerte FIM critique se déclenche : qui appeler, quel endpoint isoler du réseau, comment collecter la mémoire vive avec avml ou WinPMEM avant redémarrage.

Dans la continuité, parcourez les guides ITSkillsCenter ou contactez-nous via la page contact pour un audit personnalisé.

Étape 11 : Corréler FIM et antivirus avec les règles MITRE ATT&CK

Wazuh ships avec un mapping natif vers la matrice MITRE ATT&CK. Une modification suspecte dans /etc/cron.d combinée à un téléchargement curl déclenche la technique T1053.003 Scheduled Task. Cette corrélation transforme une alerte isolée en signal d’attaque contextualisé.

Activez le module MITRE dans le dashboard pour visualiser les techniques détectées sur les 30 derniers jours. Vous obtenez une heatmap qui révèle les techniques privilégiées par les attaquants ciblant votre infrastructure, généralement T1078 (comptes valides) et T1190 (exploit application web) en Afrique de l’Ouest.

Étape 12 : Tester le scénario ransomware avec Atomic Red Team

Atomic Red Team fournit des scripts qui simulent des techniques d’attaque sans causer de dommages réels. Exécutez le test T1486 sur un poste de test pour vérifier que Wazuh détecte bien la création massive de fichiers chiffrés caractéristique d’un ransomware.

Invoke-AtomicTest T1486 -TestNumbers 1 -PathToAtomicsFolder C:\AtomicRedTeam\atomics

Wazuh doit déclencher une alerte FIM de niveau 12 ou supérieur dans les vingt secondes. Si rien ne remonte, ajustez les règles syscheck pour augmenter la sensibilité aux modifications massives, seuil typique au-delà de 100 fichiers modifiés en moins d’une minute.

Étape 13 : Former les administrateurs à lire le dashboard

Bloquez deux séances de deux heures pour former chaque administrateur à naviguer dans le dashboard, distinguer les vrais positifs des faux positifs, et accuser réception d’une alerte avec un commentaire d’enquête. Sans cette formation, le SIEM le mieux configuré devient un mur d’alertes ignorées en trois mois.

Documentez les dix règles les plus bruyantes de votre environnement et la manière de les whitelister proprement via custom_rules.xml. Cette discipline maintient le ratio signal sur bruit au niveau acceptable pour une vigilance durable des équipes.

Étape 14 : Mettre à jour Wazuh sans casser les agents

Wazuh publie une version mineure tous les deux mois et une majeure annuelle. Mettez à jour le manager en premier puis les agents dans la foulée pour éviter les incompatibilités de protocole. Le sens inverse provoque des déconnexions massives.

sudo apt update && sudo apt install --only-upgrade wazuh-manager wazuh-indexer wazuh-dashboard
# Puis sur chaque agent
sudo apt install --only-upgrade wazuh-agent

Lisez systématiquement le changelog officiel avant la mise à jour. Wazuh 4.10 par exemple a modifié le format de stockage des CVE, ce qui imposait un re-scan complet du parc après upgrade. Anticipez la fenêtre de quatre heures correspondante.

Étape 15 : Auditer trimestriellement la couverture FIM

Listez chaque trimestre les répertoires critiques de votre infrastructure et vérifiez que chacun est bien sous surveillance Wazuh FIM. Une nouvelle application installée par un développeur sans informer la sécurité crée souvent un angle mort qui devient le point d’entrée d’une attaque six mois plus tard.

Conservez la trace de cet audit dans un Wiki BookStack avec la date, le périmètre couvert et les ajouts de configuration apportés. Cette discipline transforme votre SIEM en outil vivant qui suit les évolutions de votre système d’information.

Étape 16 : Préparer un retour d’expérience post-incident

Après chaque alerte critique gérée, rédigez un post-mortem de 30 lignes : chronologie des événements, action de l’attaquant, point d’entrée probable, indicateurs de compromission collectés et durcissement appliqué. Partagez ce post-mortem en interne sans nommer les personnes mais en décrivant clairement les processus à améliorer pour éviter la récidive.

Étape 17 : Intégrer les flux de threat intelligence régionaux

Au-delà des feeds CVE génériques, intégrez les indicateurs de compromission spécifiques à l’Afrique de l’Ouest publiés par AfricaCERT et CERT-Sénégal. Ces flux STIX/TAXII alimentent automatiquement les règles Wazuh et améliorent la détection des campagnes ciblant la sous-région.

<integration>
  <name>custom-misp</name>
  <hook_url>https://misp.africacert.org/events/restSearch</hook_url>
  <api_key>VOTRE_CLE</api_key>
</integration>

Les domaines, hashs et IP malveillants sont ingérés toutes les six heures et utilisés par les règles de détection. Une connexion sortante vers un C2 connu déclenche immédiatement une alerte de niveau 14, suffisamment grave pour réveiller l’astreinte de nuit.