Wazuh SIEM/XDR : Guide Déploiement et Détection 2026

Guide complet Wazuh SIEM/XDR : architecture, déploiement Docker/K8s, agents, règles détection, FIM, Active Response, intégration TheHive/MISP/Shuffle.

Le déploiement d'un SIEM open source performant et évolutif est un enjeu stratégique pour les organisations de toutes tailles cherchant à renforcer leur posture de sécurité sans les coûts prohibitifs des solutions commerciales. Wazuh, plateforme unifiée de sécurité combinant les capacités de SIEM (Security Information and Event Management), XDR (Extended Detection and Response) et de conformité, s'est imposée comme la référence incontestée de la détection des menaces open source avec plus de 20 millions d'agents déployés dans le monde en 2026. Héritier d'OSSEC enrichi par une architecture moderne composée du Wazuh Manager (moteur d'analyse et de corrélation), des agents (collecte endpoint), de l'Indexer (stockage et recherche basé sur OpenSearch) et du Dashboard (visualisation et investigation), Wazuh offre un écosystème complet couvrant la détection d'intrusions, le File Integrity Monitoring (FIM), le Security Configuration Assessment (SCA), la détection de vulnérabilités, l'Active Response automatisée et l'intégration avec les plateformes SOAR (Shuffle, TheHive, MISP). Ce guide expert détaille le déploiement en production d'une infrastructure Wazuh complète — du single node aux architectures cluster multi-nœuds — les stratégies de création de règles personnalisées pour les environnements Active Directory, Microsoft 365 et AWS, le tuning de performance pour les environnements à haut volume, et les intégrations avancées qui transforment Wazuh en plateforme SOC intégrée, en complément des use cases SIEM essentiels et des méthodologies de threat hunting proactif.

Points clés de cet article :

Wazuh est une plateforme unifiée SIEM + XDR + Compliance open source avec plus de 20 millions d'agents déployés mondialement
L'architecture se compose de 4 éléments : Manager (analyse), Agents (collecte), Indexer (OpenSearch), Dashboard (UI)
Le déploiement supporte le single node, le cluster multi-nœuds, Docker et Kubernetes (Helm charts)
Les capacités natives incluent : FIM, SCA, détection de vulnérabilités, rootkit check, log analysis, Active Response
Le système de rules/decoders permet une personnalisation complète de la détection via XML
Les CDB lists enrichissent les règles avec des IOC, allowlists et contexte externe
Les intégrations TheHive, MISP et Shuffle SOAR transforment Wazuh en plateforme SOC complète
Le tuning de performance (indexer shards, worker threads, queue sizes) est critique pour les environnements 10K+ agents

Architecture Wazuh : composants et flux de données

L'architecture Wazuh est conçue selon un modèle distribué modulaire où chaque composant remplit une fonction spécifique dans la chaîne de collecte, analyse, stockage et visualisation des événements de sécurité. Cette modularité permet un dimensionnement indépendant de chaque couche en fonction de la volumétrie et des exigences de performance de l'environnement cible.

Wazuh Manager (serveur d'analyse)

Le Wazuh Manager est le cœur du système, responsable de la réception des événements depuis les agents, de l'application des decoders (parsing et normalisation), de l'évaluation des rules (détection), et de la génération des alertes. Il gère également la configuration centralisée des agents, la distribution des politiques de sécurité (SCA baselines, rootcheck signatures), et l'exécution des actions de réponse automatique (Active Response). Le manager maintient une base de données locale (SQLite) pour le suivi de l'état des agents, l'inventaire des fichiers (FIM), et les résultats de conformité. En mode cluster, plusieurs managers fonctionnent ensemble avec un nœud master et des nœuds workers, partageant l'état via un protocole de synchronisation propriétaire.

Wazuh Agents (collecte endpoint)

Les agents Wazuh sont des processus légers déployés sur les endpoints (serveurs, postes de travail, containers) qui collectent les données de sécurité locales et les transmettent de manière chiffrée (AES-256) au manager via le protocole Wazuh natif (port TCP/UDP 1514). Les agents sont disponibles pour Linux (tous les distributions majeures), Windows (Server et Desktop), macOS, Solaris, AIX, et HP-UX. Chaque agent exécute localement les modules de collecte : lecture des logs système (syslog, Event Log Windows, journald), surveillance d'intégrité de fichiers (FIM), évaluation de configuration (SCA), détection de rootkits, inventaire de vulnérabilités, et exécution de commandes personnalisées (wodles). Les agents fonctionnent également en mode agentless pour les équipements réseau (switches, firewalls, routeurs) via la collecte syslog directe sur le manager.

Wazuh Indexer (OpenSearch)

Le Wazuh Indexer est une instance OpenSearch (fork d'Elasticsearch) optimisée et préconfigurée pour le stockage et l'indexation des alertes Wazuh. Il reçoit les alertes du manager via Filebeat, les indexe dans des indices journaliers (wazuh-alerts-4.x-YYYY.MM.DD), et fournit les capacités de recherche full-text, agrégation et visualisation utilisées par le Dashboard. L'indexer supporte le clustering natif OpenSearch pour la haute disponibilité et la distribution des données, avec des réplicas configurables par index. Pour les déploiements à grande échelle, l'indexer peut être dimensionné indépendamment avec des nœuds dédiés aux rôles data, master, ingest et coordinating, selon les patterns d'architecture OpenSearch/Elasticsearch standard.

Wazuh Dashboard

Le Wazuh Dashboard est l'interface web basée sur OpenSearch Dashboards (fork de Kibana) avec le plugin Wazuh qui fournit les vues spécialisées de sécurité : tableau de bord des menaces, investigation d'alertes, visualisation MITRE ATT&CK, gestion des agents, règles et décoders, rapports de conformité (PCI DSS, GDPR, HIPAA, NIST 800-53), et administration du cluster. Le Dashboard communique avec l'API REST du manager (port 55000) pour la gestion opérationnelle et avec l'indexer pour la consultation et la visualisation des données historiques.

Déploiement Wazuh : du single node au cluster

Le choix de l'architecture de déploiement Wazuh dépend de la volumétrie d'événements (EPS - Events Per Second), du nombre d'agents, des exigences de haute disponibilité, et des contraintes d'infrastructure. Wazuh supporte quatre modes de déploiement principaux : single node (tout-en-un), distributed (composants séparés), cluster (haute disponibilité), et containerisé (Docker/Kubernetes).

Déploiement single node (all-in-one)

Le déploiement single node installe le Manager, l'Indexer et le Dashboard sur une seule machine. Adapté aux environnements de 1 à 500 agents ou aux POC, cette architecture simplifie la maintenance mais ne fournit pas de haute disponibilité. Le script d'installation officiel Wazuh automatise ce déploiement en quelques minutes.

# Déploiement single node Wazuh 4.9 - Installation automatisée
# Prérequis : Ubuntu 22.04/24.04 LTS, 8+ GB RAM, 50+ GB disk

# Téléchargement de l'assistant d'installation
curl -sO https://packages.wazuh.com/4.9/wazuh-install.sh
curl -sO https://packages.wazuh.com/4.9/config.yml

# Configuration minimale (config.yml)
cat > config.yml <<'EOF'
nodes:
  indexer:
    - name: wazuh-indexer
      ip: "127.0.0.1"
  server:
    - name: wazuh-manager
      ip: "127.0.0.1"
  dashboard:
    - name: wazuh-dashboard
      ip: "127.0.0.1"
EOF

# Installation all-in-one (une seule commande)
bash wazuh-install.sh -a

# Vérification du déploiement
systemctl status wazuh-manager
systemctl status wazuh-indexer
systemctl status wazuh-dashboard

# Accès Dashboard : https://<ip>:443
# Credentials par défaut : admin / <password affiché lors de l'installation>

# Vérification de l'API Manager
curl -k -u admin:password https://localhost:55000/security/user/authenticate
TOKEN=$(curl -k -u admin:password https://localhost:55000/security/user/authenticate 2>/dev/null | jq -r '.data.token')
curl -k -H "Authorization: Bearer $TOKEN" https://localhost:55000/?pretty

# Vérification de l'Indexer
curl -k -u admin:password https://localhost:9200/_cat/indices?v

Déploiement cluster multi-nœuds

Pour les environnements de production avec plus de 500 agents ou des exigences de haute disponibilité, un déploiement distribué avec cluster est recommandé. L'architecture typique comprend un cluster de managers (1 master + N workers), un cluster OpenSearch (3+ nœuds pour le quorum), et un ou plusieurs nœuds Dashboard derrière un load balancer. Le cluster de managers distribue la charge de traitement des événements entre les workers, tandis que le master gère la configuration centralisée et la synchronisation.

# Déploiement cluster Wazuh - Architecture distribuée
# Infrastructure type :
# - 3x Wazuh Indexer nodes (cluster OpenSearch)
# - 1x Wazuh Manager Master + 2x Workers
# - 1x Wazuh Dashboard (+ LB si nécessaire)

# Configuration cluster (config.yml)
cat > config.yml <<'EOF'
nodes:
  indexer:
    - name: wazuh-indexer-1
      ip: "10.0.1.10"
    - name: wazuh-indexer-2
      ip: "10.0.1.11"
    - name: wazuh-indexer-3
      ip: "10.0.1.12"
  server:
    - name: wazuh-manager-master
      ip: "10.0.1.20"
      node_type: master
    - name: wazuh-manager-worker1
      ip: "10.0.1.21"
      node_type: worker
    - name: wazuh-manager-worker2
      ip: "10.0.1.22"
      node_type: worker
  dashboard:
    - name: wazuh-dashboard
      ip: "10.0.1.30"
EOF

# Génération des certificats (sur n'importe quel nœud)
bash wazuh-install.sh --generate-config-files

# Installation de chaque composant sur son nœud respectif
# Sur les nœuds Indexer :
bash wazuh-install.sh --wazuh-indexer wazuh-indexer-1
bash wazuh-install.sh --wazuh-indexer wazuh-indexer-2
bash wazuh-install.sh --wazuh-indexer wazuh-indexer-3

# Initialisation du cluster indexer (sur le premier nœud)
bash wazuh-install.sh --start-cluster

# Sur les nœuds Manager :
bash wazuh-install.sh --wazuh-server wazuh-manager-master
bash wazuh-install.sh --wazuh-server wazuh-manager-worker1
bash wazuh-install.sh --wazuh-server wazuh-manager-worker2

# Sur le nœud Dashboard :
bash wazuh-install.sh --wazuh-dashboard wazuh-dashboard

# Configuration cluster du manager (/var/ossec/etc/ossec.conf sur le master)
# <cluster>
#   <name>wazuh-cluster</name>
#   <node_name>wazuh-manager-master</node_name>
#   <node_type>master</node_type>
#   <key>CLUSTER_KEY_HERE</key>
#   <port>1516</port>
#   <bind_addr>0.0.0.0</bind_addr>
#   <nodes>
#     <node>10.0.1.20</node>
#   </nodes>
#   <hidden>no</hidden>
#   <disabled>no</disabled>
# </cluster>

# Vérification du cluster
/var/ossec/bin/cluster_control -l
# NAME                  TYPE    VERSION  ADDRESS
# wazuh-manager-master  master  4.9.0    10.0.1.20
# wazuh-manager-worker1 worker  4.9.0    10.0.1.21
# wazuh-manager-worker2 worker  4.9.0    10.0.1.22

Déploiement Docker et Kubernetes

Wazuh fournit des images Docker officielles et des Helm charts pour les déploiements containerisés. L'approche Docker est idéale pour les environnements de développement, les POC et les petits déploiements, tandis que Kubernetes est recommandé pour les déploiements cloud-native à grande échelle nécessitant auto-scaling, self-healing et orchestration avancée.

# Déploiement Docker Compose (development/small production)
git clone https://github.com/wazuh/wazuh-docker.git -b v4.9.0
cd wazuh-docker/single-node

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

# Démarrage de l'environnement complet
docker compose up -d

# Vérification
docker compose ps
docker compose logs -f wazuh.manager

# --- Déploiement Kubernetes (Helm) ---
# Ajout du repository Helm Wazuh
helm repo add wazuh https://packages.wazuh.com/4.x/helm/
helm repo update

# Installation avec valeurs personnalisées
cat > wazuh-values.yaml <<'EOF'
wazuh:
  manager:
    replicas: 3
    resources:
      requests:
        memory: "4Gi"
        cpu: "2000m"
      limits:
        memory: "8Gi"
        cpu: "4000m"
  indexer:
    replicas: 3
    storageSize: 100Gi
    resources:
      requests:
        memory: "4Gi"
        cpu: "2000m"
  dashboard:
    replicas: 2
    ingress:
      enabled: true
      hostname: wazuh.company.com
      tls: true
EOF

# Déploiement
kubectl create namespace wazuh
helm install wazuh wazuh/wazuh -n wazuh -f wazuh-values.yaml

# Vérification
kubectl get pods -n wazuh
kubectl get svc -n wazuh

Enrollment et gestion des agents

L'enrollment des agents est le processus par lequel un agent Wazuh s'enregistre auprès du manager et établit une communication sécurisée. Wazuh supporte plusieurs méthodes d'enrollment : enrollment automatique (le plus simple, basé sur un mot de passe partagé), enrollment par clé pré-générée (pour les environnements air-gapped), et enrollment via l'API (pour l'intégration avec les outils de provisioning comme Ansible, Terraform, SCCM).

# --- Enrollment agent Linux ---
# Installation de l'agent (Ubuntu/Debian)
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
apt update && apt install wazuh-agent

# Configuration de l'agent
WAZUH_MANAGER="10.0.1.20" WAZUH_REGISTRATION_SERVER="10.0.1.20" \
  WAZUH_REGISTRATION_PASSWORD="EnrollmentPassword123" \
  apt install wazuh-agent

# Ou configuration post-installation
sed -i 's/MANAGER_IP/10.0.1.20/' /var/ossec/etc/ossec.conf
/var/ossec/bin/agent-auth -m 10.0.1.20 -P "EnrollmentPassword123"
systemctl start wazuh-agent
systemctl enable wazuh-agent

# --- Enrollment agent Windows ---
# Téléchargement MSI
# https://packages.wazuh.com/4.x/windows/wazuh-agent-4.9.0-1.msi

# Installation silencieuse avec configuration
msiexec.exe /i wazuh-agent-4.9.0-1.msi /q WAZUH_MANAGER="10.0.1.20" WAZUH_REGISTRATION_SERVER="10.0.1.20" WAZUH_REGISTRATION_PASSWORD="EnrollmentPassword123" WAZUH_AGENT_GROUP="windows-servers"

# --- Enrollment via API (automation) ---
TOKEN=$(curl -k -u admin:password -X POST https://10.0.1.20:55000/security/user/authenticate 2>/dev/null | jq -r '.data.token')

# Lister les agents
curl -k -H "Authorization: Bearer $TOKEN" "https://10.0.1.20:55000/agents?pretty"

# Groupes d'agents
curl -k -H "Authorization: Bearer $TOKEN" -X POST "https://10.0.1.20:55000/groups" \
  -H "Content-Type: application/json" \
  -d '{"group_id": "linux-servers"}'

# Assigner un agent à un groupe
curl -k -H "Authorization: Bearer $TOKEN" -X PUT "https://10.0.1.20:55000/agents/001/group/linux-servers"

# --- Déploiement massif avec Ansible ---
# playbook: deploy-wazuh-agent.yml
# - hosts: all_servers
#   roles:
#     - role: wazuh-agent
#       vars:
#         wazuh_manager_ip: "10.0.1.20"
#         wazuh_agent_group: "{{ group_names[0] }}"
#         wazuh_registration_password: "{{ vault_wazuh_password }}"

Rules et Decoders : personnalisation de la détection

Le moteur de détection Wazuh repose sur deux composants fondamentaux : les decoders (qui parsent et normalisent les logs bruts en champs structurés) et les rules (qui évaluent les événements normalisés pour générer des alertes). Wazuh fournit plus de 4000 règles prédéfinies couvrant les événements système Linux/Windows, les applications courantes (Apache, Nginx, SSH, etc.), et les standards de sécurité. La personnalisation des règles est essentielle pour adapter la détection aux spécificités de chaque environnement.

Anatomie d'un decoder

Un decoder extrait les champs pertinents d'un log brut et les assigne à des variables standardisées utilisables par les règles. Les decoders fonctionnent en hiérarchie (parent → child) pour un parsing progressif des logs complexes.

<!-- Decoder personnalisé pour une application interne -->
<!-- Fichier : /var/ossec/etc/decoders/local_decoder.xml -->

<!-- Decoder parent : identifie le type de log -->
<decoder name="custom-app">
  <program_name>myapp</program_name>
</decoder>

<!-- Decoder enfant : extrait les champs d'un log d'authentification -->
<decoder name="custom-app-auth">
  <parent>custom-app</parent>
  <regex>AUTH (\w+) from (\S+) user=(\S+) status=(\w+)</regex>
  <order>action, srcip, user, status</order>
</decoder>

<!-- Decoder pour les logs JSON (natif depuis Wazuh 4.4) -->
<decoder name="custom-json-app">
  <program_name>json-service</program_name>
  <plugin_decoder>JSON_Decoder</plugin_decoder>
</decoder>

<!-- Test du decoder -->
<!-- /var/ossec/bin/wazuh-logtest
Type one log per line:
Jan 15 10:30:45 server1 myapp[1234]: AUTH LOGIN from 192.168.1.100 user=admin status=success
**Phase 2: Completed decoding.
    name: 'custom-app-auth'
    action: 'LOGIN'
    srcip: '192.168.1.100'
    user: 'admin'
    status: 'success'
-->

Anatomie d'une rule

Les rules évaluent les événements décodés et génèrent des alertes lorsque les conditions sont remplies. Chaque règle possède un ID unique, un niveau de sévérité (0-15), et un ensemble de conditions de matching. Les règles peuvent être enchaînées (fréquence, corrélation) pour détecter des patterns complexes.

<!-- Rules personnalisées -->
<!-- Fichier : /var/ossec/etc/rules/local_rules.xml -->

<group name="custom-app,">

  <!-- Règle simple : échec d'authentification -->
  <rule id="100001" level="5">
    <decoded_as>custom-app-auth</decoded_as>
    <field name="status">failure</field>
    <description>Custom App: Authentication failure from $(srcip)</description>
    <mitre>
      <id>T1078</id>
    </mitre>
    <group>authentication_failed,</group>
  </rule>

  <!-- Règle de fréquence : brute force (5 échecs en 2 minutes) -->
  <rule id="100002" level="10" frequency="5" timeframe="120">
    <if_matched_sid>100001</if_matched_sid>
    <same_source_ip/>
    <description>Custom App: Brute force attempt from $(srcip) - $(user)</description>
    <mitre>
      <id>T1110</id>
    </mitre>
    <group>authentication_failures,brute_force,</group>
  </rule>

  <!-- Règle composite : login après brute force -->
  <rule id="100003" level="12">
    <if_sid>100002</if_sid>
    <field name="status">success</field>
    <description>Custom App: Successful login after brute force from $(srcip)</description>
    <mitre>
      <id>T1078</id>
      <id>T1110</id>
    </mitre>
    <group>authentication_success,brute_force,</group>
  </rule>

  <!-- Règle avec CDB list (IOC matching) -->
  <rule id="100004" level="14">
    <decoded_as>custom-app-auth</decoded_as>
    <list field="srcip" lookup="address_match_key">etc/lists/malicious-ips</list>
    <description>Custom App: Connection from known malicious IP $(srcip)</description>
    <mitre>
      <id>T1071</id>
    </mitre>
    <group>threat_intelligence,</group>
  </rule>

</group>

Règles pour Active Directory

La détection des menaces Active Directory est l'un des cas d'usage les plus critiques de Wazuh en environnement entreprise. Les événements Windows Security (EventID 4624, 4625, 4672, 4720, 4732, 4768, 4769, 4771, etc.) et les logs de Domain Controllers fournissent la visibilité nécessaire pour détecter les attaques Kerberoasting, AS-REP Roasting, Golden/Silver Ticket, DCSync, et les mouvements latéraux, conformément aux méthodes de détection décrites dans notre guide Sigma Rules.

<!-- Règles Active Directory personnalisées -->
<group name="active_directory,windows,">

  <!-- Détection Kerberoasting (TGS request pour service accounts) -->
  <rule id="100100" level="10">
    <if_sid>60103</if_sid> <!-- Windows Security Event -->
    <field name="win.system.eventID">4769</field>
    <field name="win.eventdata.ticketEncryptionType">0x17</field> <!-- RC4 -->
    <field name="win.eventdata.serviceName">\.+(?!krbtgt)</field>
    <description>AD: Possible Kerberoasting - TGS request with RC4 encryption for $(win.eventdata.serviceName)</description>
    <mitre>
      <id>T1558.003</id>
    </mitre>
    <group>kerberoasting,credential_access,</group>
  </rule>

  <!-- Détection DCSync (Replication de l'annuaire) -->
  <rule id="100101" level="14">
    <if_sid>60103</if_sid>
    <field name="win.system.eventID">4662</field>
    <field name="win.eventdata.properties">1131f6ad-9c07-11d1-f79f-00c04fc2dcd2</field>
    <description>AD: DCSync attack detected - Directory replication by $(win.eventdata.subjectUserName)</description>
    <mitre>
      <id>T1003.006</id>
    </mitre>
    <group>dcsync,credential_access,critical,</group>
  </rule>

  <!-- Ajout d'utilisateur au groupe Domain Admins -->
  <rule id="100102" level="12">
    <if_sid>60103</if_sid>
    <field name="win.system.eventID">4732</field>
    <field name="win.eventdata.targetUserName">Domain Admins</field>
    <description>AD: User added to Domain Admins group by $(win.eventdata.subjectUserName)</description>
    <mitre>
      <id>T1098</id>
    </mitre>
    <group>privilege_escalation,persistence,</group>
  </rule>

  <!-- Login anormal (hors heures de bureau) -->
  <rule id="100103" level="8">
    <if_sid>60103</if_sid>
    <field name="win.system.eventID">4624</field>
    <field name="win.eventdata.logonType">10</field> <!-- Remote Interactive (RDP) -->
    <time>22:00-06:00</time>
    <description>AD: After-hours RDP login by $(win.eventdata.targetUserName) from $(win.eventdata.ipAddress)</description>
    <mitre>
      <id>T1078</id>
    </mitre>
    <group>after_hours,lateral_movement,</group>
  </rule>

</group>

File Integrity Monitoring (FIM) et Security Configuration Assessment (SCA)

Le FIM (File Integrity Monitoring) surveille en temps réel les modifications de fichiers et répertoires critiques (configurations, binaires système, fichiers web), détectant les altérations non autorisées qui peuvent indiquer une compromission. Le SCA (Security Configuration Assessment) évalue la conformité des configurations système par rapport à des baselines de sécurité (CIS Benchmarks, PCI DSS, HIPAA, NIST 800-53), identifiant les écarts de configuration qui augmentent la surface d'attaque.

<!-- Configuration FIM dans ossec.conf -->
<syscheck>
  <!-- Fréquence de scan (secondes) -->
  <frequency>300</frequency>

  <!-- Surveillance en temps réel (inotify sur Linux, ReadDirectoryChanges sur Windows) -->
  <directories realtime="yes" check_all="yes" report_changes="yes">/etc,/usr/bin,/usr/sbin</directories>
  <directories realtime="yes" check_all="yes" report_changes="yes">/var/www/html</directories>

  <!-- Windows - fichiers critiques -->
  <directories realtime="yes" check_all="yes">C:\Windows\System32\drivers\etc</directories>
  <directories realtime="yes" check_all="yes">C:\Windows\System32\config</directories>

  <!-- Surveillance de fichiers spécifiques -->
  <directories check_all="yes">/etc/passwd,/etc/shadow,/etc/sudoers</directories>

  <!-- Exclusions -->
  <ignore>/etc/mtab</ignore>
  <ignore type="sregex">\.log$|\.tmp$</ignore>

  <!-- Surveillance du registre Windows -->
  <windows_registry arch="both">HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run</windows_registry>
  <windows_registry arch="both">HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services</windows_registry>

  <!-- Who-data (audit de qui a modifié) - Linux nécessite auditd -->
  <directories whodata="yes">/etc/crontab,/etc/cron.d</directories>
</syscheck>

<!-- Configuration SCA -->
<sca>
  <enabled>yes</enabled>
  <scan_on_start>yes</scan_on_start>
  <interval>12h</interval>
  <skip_nfs>yes</skip_nfs>

  <!-- Politiques CIS à évaluer -->
  <policies>
    <policy>cis_ubuntu22-04.yml</policy>
    <policy>cis_win2022.yml</policy>
    <policy>cis_apache_24.yml</policy>
    <policy>cis_mysql8.yml</policy>
  </policies>
</sca>

Détection de vulnérabilités et Active Response

Le module de détection de vulnérabilités Wazuh inventorie les packages installés sur chaque agent et les corrèle avec les bases de vulnérabilités (NVD, Red Hat, Debian, Ubuntu, Microsoft, Amazon) pour identifier les CVE affectant l'environnement. L'Active Response permet l'exécution automatique d'actions de remédiation sur les agents en réponse aux alertes détectées — blocage d'IP, terminaison de processus, isolation réseau, ou scripts personnalisés.

<!-- Configuration de la détection de vulnérabilités -->
<vulnerability-detection>
  <enabled>yes</enabled>
  <index-status>yes</index-status>
  <feed-update-interval>60m</feed-update-interval>
</vulnerability-detection>

<!-- Configuration Active Response -->
<!-- Fichier: /var/ossec/etc/ossec.conf (Manager) -->

<!-- Définition des commandes de réponse -->
<command>
  <name>firewall-drop</name>
  <executable>firewall-drop</executable>
  <timeout_allowed>yes</timeout_allowed>
</command>

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

<command>
  <name>custom-isolation</name>
  <executable>custom-isolation.sh</executable>
  <timeout_allowed>yes</timeout_allowed>
</command>

<!-- Active Response : bloquer IP après brute force SSH -->
<active-response>
  <command>firewall-drop</command>
  <location>local</location>
  <rules_id>5712</rules_id> <!-- SSH brute force -->
  <timeout>3600</timeout> <!-- Block pendant 1h -->
</active-response>

<!-- Active Response : désactiver compte après tentatives excessives -->
<active-response>
  <command>disable-account</command>
  <location>server</location>
  <rules_id>100002</rules_id> <!-- Notre règle brute force custom -->
  <timeout>7200</timeout>
</active-response>

<!-- Active Response : isolation réseau sur détection critique -->
<active-response>
  <command>custom-isolation</command>
  <location>local</location>
  <level>14</level> <!-- Toute alerte niveau 14+ -->
  <timeout>0</timeout> <!-- Pas de timeout - action manuelle pour restaurer -->
</active-response>

Script Active Response personnalisé

#!/bin/bash
# /var/ossec/active-response/bin/custom-isolation.sh
# Script d'isolation réseau pour Active Response

LOCAL=`dirname $0`;
cd $LOCAL
cd ../

PWD=`pwd`
ACTION=$1
USER=$2
IP=$3
ALERTID=$4
RULEID=$5
AGENT=$6

LOG_FILE="${PWD}/../logs/active-responses.log"

if [ "$ACTION" = "add" ]; then
    # Isolation : bloquer tout sauf la communication avec le manager Wazuh
    iptables -I INPUT -s 10.0.1.20 -j ACCEPT  # Permettre le manager
    iptables -I OUTPUT -d 10.0.1.20 -j ACCEPT  # Permettre le manager
    iptables -A INPUT -j DROP   # Bloquer le reste
    iptables -A OUTPUT -j DROP  # Bloquer le reste

    echo "$(date) $0 $ACTION $IP $RULEID - Host isolated" >> ${LOG_FILE}

elif [ "$ACTION" = "delete" ]; then
    # Restauration : supprimer les règles d'isolation
    iptables -D INPUT -j DROP
    iptables -D OUTPUT -j DROP
    iptables -D INPUT -s 10.0.1.20 -j ACCEPT
    iptables -D OUTPUT -d 10.0.1.20 -j ACCEPT

    echo "$(date) $0 $ACTION $IP $RULEID - Host un-isolated" >> ${LOG_FILE}
fi

exit 0;

Intégrations : TheHive, MISP, Shuffle SOAR

L'intégration de Wazuh avec des plateformes de Threat Intelligence (MISP), de gestion d'incidents (TheHive) et d'orchestration/automatisation (Shuffle SOAR) transforme le déploiement d'un simple SIEM en une plateforme SOC intégrée capable de détection, enrichissement, investigation et réponse automatisée, conformément aux principes d'automatisation décrits dans notre guide SOAR.

Intégration TheHive

TheHive est la plateforme open source de gestion d'incidents de sécurité de référence. L'intégration avec Wazuh permet la création automatique de cas (cases) et d'alertes dans TheHive lorsque des alertes Wazuh de niveau élevé sont générées, facilitant le workflow d'investigation des analystes SOC.

<!-- Configuration intégration TheHive dans ossec.conf -->
<integration>
  <name>custom-thehive</name>
  <hook_url>http://thehive.internal:9000/api/alert</hook_url>
  <api_key>YOUR_THEHIVE_API_KEY</api_key>
  <level>10</level> <!-- Créer un case pour les alertes niveau 10+ -->
  <alert_format>json</alert_format>
</integration>

#!/usr/bin/env python3
# /var/ossec/integrations/custom-thehive
# Script d'intégration Wazuh -> TheHive

import json
import sys
import requests
from datetime import datetime

THEHIVE_URL = "http://thehive.internal:9000"
THEHIVE_API_KEY = "YOUR_API_KEY"

def create_alert(alert_data):
    """Crée une alerte dans TheHive à partir d'une alerte Wazuh"""

    # Extraction des champs Wazuh
    rule = alert_data.get("rule", {})
    agent = alert_data.get("agent", {})
    data = alert_data.get("data", {})

    # Construction de l'alerte TheHive
    thehive_alert = {
        "title": f"[Wazuh] {rule.get('description', 'Unknown alert')}",
        "description": json.dumps(alert_data, indent=2),
        "severity": map_severity(rule.get("level", 0)),
        "type": "wazuh",
        "source": "wazuh",
        "sourceRef": alert_data.get("id", "unknown"),
        "tags": rule.get("groups", []) + [f"agent:{agent.get('name', 'unknown')}"],
        "artifacts": build_observables(alert_data),
        "tlp": 2,  # TLP:AMBER
        "pap": 2
    }

    # Ajout MITRE ATT&CK si disponible
    mitre = rule.get("mitre", {})
    if mitre.get("id"):
        thehive_alert["tags"].extend([f"mitre:{tid}" for tid in mitre["id"]])

    # Envoi à TheHive
    headers = {
        "Authorization": f"Bearer {THEHIVE_API_KEY}",
        "Content-Type": "application/json"
    }

    response = requests.post(
        f"{THEHIVE_URL}/api/alert",
        headers=headers,
        json=thehive_alert,
        verify=False
    )

    return response.status_code == 201

def map_severity(wazuh_level):
    """Mappe les niveaux Wazuh vers les sévérités TheHive"""
    if wazuh_level >= 14: return 4  # Critical
    if wazuh_level >= 12: return 3  # High
    if wazuh_level >= 8: return 2   # Medium
    return 1  # Low

def build_observables(alert_data):
    """Extrait les observables (IOC) de l'alerte"""
    observables = []
    data = alert_data.get("data", {})

    if data.get("srcip"):
        observables.append({
            "dataType": "ip",
            "data": data["srcip"],
            "message": "Source IP"
        })
    if data.get("dstip"):
        observables.append({
            "dataType": "ip",
            "data": data["dstip"],
            "message": "Destination IP"
        })
    if data.get("url"):
        observables.append({
            "dataType": "url",
            "data": data["url"],
            "message": "URL"
        })

    return observables

# Point d'entrée
if __name__ == "__main__":
    alert_file = sys.argv[1]
    with open(alert_file) as f:
        alert_data = json.load(f)
    create_alert(alert_data)

Intégration MISP (Threat Intelligence)

L'intégration avec MISP (Malware Information Sharing Platform) permet d'enrichir les règles Wazuh avec des IOC (Indicators of Compromise) issus de feeds de threat intelligence. Les indicateurs MISP (IPs malveillantes, hashes de malware, domaines C2, URLs de phishing) sont synchronisés dans les CDB lists Wazuh pour la corrélation en temps réel avec les événements des agents.

#!/usr/bin/env python3
# Synchronisation MISP -> Wazuh CDB Lists
# Exécution via cron toutes les heures

import requests
import json

MISP_URL = "https://misp.internal"
MISP_API_KEY = "YOUR_MISP_API_KEY"
WAZUH_CDB_PATH = "/var/ossec/etc/lists"

def sync_misp_to_cdb():
    """Synchronise les IOC MISP vers les CDB lists Wazuh"""

    headers = {
        "Authorization": MISP_API_KEY,
        "Accept": "application/json",
        "Content-Type": "application/json"
    }

    # Récupérer les IPs malveillantes (dernières 24h)
    response = requests.post(
        f"{MISP_URL}/attributes/restSearch",
        headers=headers,
        json={
            "type": ["ip-src", "ip-dst"],
            "last": "1d",
            "published": True,
            "to_ids": True
        },
        verify=False
    )

    ips = response.json().get("response", {}).get("Attribute", [])

    # Écriture de la CDB list (format: key:value)
    with open(f"{WAZUH_CDB_PATH}/malicious-ips", "w") as f:
        for attr in ips:
            f.write(f"{attr['value']}:MISP-{attr.get('Event', {}).get('info', 'unknown')}\n")

    # Récupérer les hashes de malware
    response = requests.post(
        f"{MISP_URL}/attributes/restSearch",
        headers=headers,
        json={
            "type": ["md5", "sha256"],
            "last": "7d",
            "published": True,
            "to_ids": True
        },
        verify=False
    )

    hashes = response.json().get("response", {}).get("Attribute", [])

    with open(f"{WAZUH_CDB_PATH}/malicious-hashes", "w") as f:
        for attr in hashes:
            f.write(f"{attr['value']}:{attr['type']}-{attr.get('comment', 'malware')}\n")

    # Recharger les CDB lists (sans redémarrer le manager)
    import subprocess
    subprocess.run(["/var/ossec/bin/wazuh-control", "reload"], check=True)

    print(f"Synchronized {len(ips)} IPs and {len(hashes)} hashes from MISP")

if __name__ == "__main__":
    sync_misp_to_cdb()

Intégration Shuffle SOAR

Shuffle est une plateforme SOAR (Security Orchestration, Automation and Response) open source qui orchestre les workflows de réponse à incident en connectant Wazuh avec des dizaines d'outils de sécurité. L'intégration permet de créer des playbooks automatisés : enrichissement des alertes avec VirusTotal/AbuseIPDB, création de tickets Jira/ServiceNow, notification Slack/Teams, et actions de remédiation orchestrées multi-outils.

<!-- Configuration webhook vers Shuffle dans ossec.conf -->
<integration>
  <name>shuffle</name>
  <hook_url>http://shuffle.internal:3001/api/v1/hooks/wazuh_webhook_id</hook_url>
  <level>8</level>
  <alert_format>json</alert_format>
  <options>{"data": "full_alert"}</options>
</integration>

CDB Lists et enrichissement contextuel

Les CDB lists (Constant DataBase lists) sont des fichiers clé-valeur optimisés utilisés par le moteur de règles Wazuh pour enrichir les événements avec du contexte externe. Elles permettent de corréler les adresses IP avec des listes de réputation, les hashes de fichiers avec des bases de malware, les noms d'utilisateurs avec des listes d'allowlist/blocklist, et tout autre enrichissement basé sur un lookup clé-valeur. Les CDB lists sont chargées en mémoire pour des performances de lookup O(1), ce qui les rend adaptées aux environnements à haut volume d'événements.

# Création de CDB lists

# Liste d'IPs malveillantes (format: ip:description)
cat > /var/ossec/etc/lists/malicious-ips <<'EOF'
10.0.0.100:known-c2-server
192.168.1.50:compromised-host
203.0.113.45:scanner
198.51.100.23:tor-exit-node
EOF

# Liste d'utilisateurs critiques (à surveiller plus)
cat > /var/ossec/etc/lists/critical-users <<'EOF'
admin:domain-admin
svc-backup:service-account
krbtgt:kerberos-critical
DOMAIN\Administrator:builtin-admin
EOF

# Liste de hashes de malware
cat > /var/ossec/etc/lists/malware-hashes <<'EOF'
e3b0c44298fc1c149afbf4c8996fb924:emotet-loader
a1b2c3d4e5f6789012345678abcdef:cobalt-strike-beacon
EOF

# Liste de programmes autorisés (allowlist)
cat > /var/ossec/etc/lists/approved-software <<'EOF'
notepad.exe:approved
chrome.exe:approved
code.exe:approved
EOF

# Déclaration des listes dans ossec.conf
# <ruleset>
#   <list>etc/lists/malicious-ips</list>
#   <list>etc/lists/critical-users</list>
#   <list>etc/lists/malware-hashes</list>
#   <list>etc/lists/approved-software</list>
# </ruleset>

# Utilisation dans les règles
# <rule id="100200" level="14">
#   <list field="srcip" lookup="address_match_key">etc/lists/malicious-ips</list>
#   <description>Connection from threat intelligence IOC: $(srcip)</description>
# </rule>

Règles personnalisées pour Microsoft 365 et AWS

La surveillance des environnements cloud (Microsoft 365, AWS, Azure, GCP) via Wazuh nécessite des modules de collecte spécifiques et des règles adaptées aux logs cloud natifs. Wazuh supporte la collecte des logs AWS (CloudTrail, GuardDuty, VPC Flow Logs, WAF) via le module aws-s3, et les logs Microsoft 365 (Azure AD, Exchange Online, SharePoint, Teams) via le module office365.

<!-- Configuration collecte AWS CloudTrail -->
<wodle name="aws-s3">
  <disabled>no</disabled>
  <interval>5m</interval>
  <run_on_start>yes</run_on_start>

  <bucket type="cloudtrail">
    <name>my-cloudtrail-bucket</name>
    <access_key>AKIAIOSFODNN7EXAMPLE</access_key>
    <secret_key>wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY</secret_key>
    <region>eu-west-1</region>
  </bucket>

  <bucket type="guardduty">
    <name>my-guardduty-bucket</name>
    <access_key>AKIAIOSFODNN7EXAMPLE</access_key>
    <secret_key>wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY</secret_key>
    <region>eu-west-1</region>
  </bucket>
</wodle>

<!-- Configuration collecte Microsoft 365 -->
<wodle name="office365">
  <disabled>no</disabled>
  <interval>5m</interval>
  <run_on_start>yes</run_on_start>
  <api_auth>
    <tenant_id>YOUR_TENANT_ID</tenant_id>
    <client_id>YOUR_CLIENT_ID</client_id>
    <client_secret>YOUR_CLIENT_SECRET</client_secret>
  </api_auth>
  <subscriptions>
    <subscription>Audit.AzureActiveDirectory</subscription>
    <subscription>Audit.Exchange</subscription>
    <subscription>Audit.SharePoint</subscription>
    <subscription>Audit.General</subscription>
    <subscription>DLP.All</subscription>
  </subscriptions>
</wodle>

<!-- Règles personnalisées AWS -->
<group name="aws,cloudtrail,">

  <!-- Création de clé d'accès IAM (potentiel persistence) -->
  <rule id="100300" level="10">
    <if_sid>80302</if_sid> <!-- AWS CloudTrail event -->
    <field name="aws.eventName">CreateAccessKey</field>
    <description>AWS: IAM Access Key created by $(aws.userIdentity.arn)</description>
    <mitre>
      <id>T1098.001</id>
    </mitre>
  </rule>

  <!-- Désactivation de CloudTrail (anti-forensics) -->
  <rule id="100301" level="14">
    <if_sid>80302</if_sid>
    <field name="aws.eventName">StopLogging|DeleteTrail</field>
    <description>AWS: CloudTrail logging disabled/deleted by $(aws.userIdentity.arn)</description>
    <mitre>
      <id>T1562.008</id>
    </mitre>
    <group>defense_evasion,critical,</group>
  </rule>

  <!-- Connexion console depuis un pays inhabituel -->
  <rule id="100302" level="10">
    <if_sid>80302</if_sid>
    <field name="aws.eventName">ConsoleLogin</field>
    <field name="aws.sourceIPAddress" negate="yes">^(10\.|172\.(1[6-9]|2|3[01])\.|192\.168\.)</field>
    <description>AWS: Console login from external IP $(aws.sourceIPAddress) by $(aws.userIdentity.arn)</description>
    <mitre>
      <id>T1078.004</id>
    </mitre>
  </rule>

</group>

<!-- Règles Microsoft 365 -->
<group name="office365,">

  <!-- Impossible travel (login depuis deux pays différents rapidement) -->
  <rule id="100400" level="12">
    <if_sid>99100</if_sid> <!-- Office 365 base rule -->
    <field name="office365.Operation">UserLoggedIn</field>
    <description>M365: Login by $(office365.UserId) from $(office365.ClientIP) - verify for impossible travel</description>
    <mitre>
      <id>T1078.004</id>
    </mitre>
  </rule>

  <!-- Création de règle de transfert email (exfiltration) -->
  <rule id="100401" level="10">
    <if_sid>99100</if_sid>
    <field name="office365.Operation">New-InboxRule|Set-InboxRule</field>
    <field name="office365.Parameters">ForwardTo|RedirectTo</field>
    <description>M365: Email forwarding rule created by $(office365.UserId)</description>
    <mitre>
      <id>T1114.003</id>
    </mitre>
    <group>email_exfiltration,</group>
  </rule>

  <!-- Désactivation MFA (account takeover preparation) -->
  <rule id="100402" level="12">
    <if_sid>99100</if_sid>
    <field name="office365.Operation">Disable Strong Authentication</field>
    <description>M365: MFA disabled for $(office365.ObjectId) by $(office365.UserId)</description>
    <mitre>
      <id>T1556</id>
    </mitre>
    <group>persistence,credential_access,</group>
  </rule>

</group>

Performance tuning pour les environnements à haut volume

Les déploiements Wazuh à grande échelle (10 000+ agents, 50 000+ EPS) nécessitent un tuning fin des composants pour maintenir des performances acceptables sans perte d'événements. Les trois axes d'optimisation sont : le manager (worker threads, buffer sizes, rule optimization), l'indexer (shards, replicas, JVM heap, refresh interval), et le réseau (agent buffer, reconnection time, UDP vs TCP).

# --- Tuning Manager ---
# /var/ossec/etc/internal_options.conf

# Augmenter les threads d'analyse (défaut: 2, max selon CPU)
analysisd.event_threads=8
analysisd.syscheck_threads=4
analysisd.syscollector_threads=4

# Buffer de réception des événements
analysisd.default_timeframe=360
analysisd.stats_maxdiff=999999
analysisd.stats_mindiff=999999
analysisd.stats_percent_diff=999999

# Taille des queues internes
remoted.queue_size=131072
analysisd.queue_size=131072

# /var/ossec/etc/ossec.conf
# <global>
#   <max_output_size>20M</max_output_size>
#   <alerts_log>no</alerts_log> <!-- Désactiver si seul l'indexer est utilisé -->
# </global>

# --- Tuning Indexer (OpenSearch) ---
# /etc/wazuh-indexer/opensearch.yml

# Nombre de shards primaires (adapter au volume)
# Pour les indices wazuh-alerts : 3-5 shards pour gros volumes
# Index template :
curl -k -u admin:password -X PUT "https://localhost:9200/_index_template/wazuh-alerts-template" \
  -H 'Content-Type: application/json' -d'{
    "index_patterns": ["wazuh-alerts-4.x-*"],
    "template": {
      "settings": {
        "index.number_of_shards": 3,
        "index.number_of_replicas": 1,
        "index.refresh_interval": "30s",
        "index.translog.durability": "async",
        "index.translog.sync_interval": "30s"
      }
    }
}'

# JVM Heap (50% de la RAM disponible, max 32GB)
# /etc/wazuh-indexer/jvm.options
# -Xms16g
# -Xmx16g

# --- Tuning Agent ---
# /var/ossec/etc/ossec.conf (côté agent)
# <client_buffer>
#   <disabled>no</disabled>
#   <queue_size>5000</queue_size>
#   <events_per_second>500</events_per_second>
# </client_buffer>

# --- Gestion de la rétention ---
# Index State Management (ISM) pour la rotation et suppression automatique
curl -k -u admin:password -X PUT "https://localhost:9200/_plugins/_ism/policies/wazuh-retention" \
  -H 'Content-Type: application/json' -d'{
    "policy": {
      "description": "Wazuh alerts retention policy",
      "default_state": "hot",
      "states": [
        {
          "name": "hot",
          "actions": [],
          "transitions": [
            {"state_name": "warm", "conditions": {"min_index_age": "7d"}}
          ]
        },
        {
          "name": "warm",
          "actions": [
            {"replica_count": {"number_of_replicas": 0}},
            {"force_merge": {"max_num_segments": 1}}
          ],
          "transitions": [
            {"state_name": "delete", "conditions": {"min_index_age": "90d"}}
          ]
        },
        {
          "name": "delete",
          "actions": [{"delete": {}}]
        }
      ]
    }
}'

Recommandations de dimensionnement Wazuh :

1-100 agents : Single node, 4 vCPU, 8 GB RAM, 50 GB SSD — adapté aux PME et POC
100-500 agents : Single node, 8 vCPU, 16 GB RAM, 200 GB SSD — manager + indexer sur même machine
500-5000 agents : Distributed, Manager (8 vCPU, 16 GB) + Indexer 3 nœuds (8 vCPU, 32 GB chacun)
5000-50000 agents : Cluster, 3 Manager workers (16 vCPU, 32 GB) + 5+ Indexer nœuds (16 vCPU, 64 GB)
50000+ agents : Multi-cluster avec load balancing, indexer dédié avec hot-warm-cold architecture
Le ratio typique est 1000 agents par worker manager avec une config standard
L'indexer nécessite environ 1 GB RAM par 1000 EPS pour des performances de recherche optimales

FAQ

Quelle est la différence entre Wazuh SIEM et Wazuh XDR ?

Wazuh est une plateforme unifiée qui combine les capacités SIEM et XDR dans une même solution. En tant que SIEM, Wazuh collecte, normalise, corrèle et stocke les logs de sécurité provenant de multiples sources (agents, syslog, API cloud) pour la détection de menaces et la conformité. En tant que XDR (Extended Detection and Response), Wazuh va au-delà de la corrélation de logs en intégrant la détection endpoint (FIM, rootcheck, process monitoring), la réponse automatisée (Active Response), la détection de vulnérabilités, et l'évaluation de configuration — le tout avec des agents déployés sur les endpoints. La différence avec un SIEM pur (comme Graylog ou ELK) est la présence d'agents intelligents qui collectent et pré-analysent localement, et la capacité de réponse active. La différence avec un EDR pur (comme Velociraptor) est la corrélation centralisée multi-sources et les capacités de conformité réglementaire.

Comment migrer depuis OSSEC vers Wazuh ?

Wazuh étant un fork d'OSSEC, la migration est relativement directe. Les étapes clés : (1) Installer le Wazuh Manager sur un nouveau serveur (les formats de règles et decoders sont compatibles). (2) Copier les règles personnalisées (local_rules.xml, local_decoder.xml) depuis OSSEC vers le répertoire Wazuh correspondant. (3) Exporter la liste des agents OSSEC et leurs clés (/var/ossec/etc/client.keys). (4) Déployer les agents Wazuh sur les endpoints (l'agent Wazuh remplace l'agent OSSEC). (5) Importer les clés dans le nouveau manager si migration sans ré-enrollment. (6) Adapter les configurations d'agent (le format ossec.conf est largement compatible mais Wazuh ajoute de nombreuses options). Les principales différences : Wazuh ajoute l'indexer (OpenSearch) pour le stockage et la recherche, le dashboard web, les modules cloud (AWS, Office365, GCP), la détection de vulnérabilités, le SCA, et les intégrations SOAR — fonctionnalités absentes d'OSSEC.

Wazuh peut-il remplacer un EDR commercial comme CrowdStrike ou SentinelOne ?

Wazuh couvre une partie significative des fonctionnalités EDR mais ne remplace pas intégralement un EDR commercial haut de gamme pour les environnements à haute exigence de sécurité. Ce que Wazuh fait bien : monitoring d'intégrité de fichiers (FIM), détection basée sur les logs (Event Log, Sysmon), évaluation de configuration, détection de vulnérabilités, réponse active (blocage IP, kill process). Ce que les EDR commerciaux font mieux : protection en temps réel des processus (hooking kernel-level), détection comportementale avancée basée sur le ML (arbres de décision sur les séquences d'API calls), isolation réseau instantanée sans agent additionnel, rollback automatique des modifications malveillantes (ransomware), et couverture des techniques d'évasion (unhooking, ETW bypass). Pour un SOC mature, la combinaison Wazuh (SIEM/corrélation) + EDR commercial (protection endpoint temps réel) offre la meilleure couverture. Pour les organisations avec des budgets limités, Wazuh + Sysmon offre une détection très compétitive.

Comment configurer Wazuh pour détecter les mouvements latéraux dans Active Directory ?

La détection des mouvements latéraux AD avec Wazuh nécessite : (1) Sysmon déployé sur tous les endpoints Windows avec une configuration capturant les Event IDs 1 (Process Create), 3 (Network Connect), 7 (Image Load), 10 (Process Access). (2) Windows Security Events collectés depuis les Domain Controllers (4624 type 3/10, 4625, 4648, 4672, 4768, 4769, 4776). (3) Règles de corrélation personnalisées détectant : les connexions RDP/SMB inhabituelles (4624 type 3 vers des serveurs non habituels), les Pass-the-Hash (4624 type 3 avec NtlmV1 et logins multiples rapides), le Kerberoasting (4769 avec encryption RC4), les accès distants via PsExec/WMI (Sysmon Event 1 avec des process parents suspects), et les mouvements via WinRM. (4) CDB lists de serveurs critiques et comptes privilégiés pour le scoring contextuel. La combinaison de ces sources avec des règles de fréquence et de corrélation temporelle permet une détection efficace des patterns de mouvement latéral.

Comment intégrer Wazuh avec Elastic Stack (ELK) au lieu de l'Indexer natif ?

Bien que Wazuh recommande son Indexer natif (OpenSearch), l'intégration avec Elasticsearch/Kibana reste supportée pour les organisations ayant un investissement existant dans ELK. La configuration nécessite : (1) Installer uniquement le Wazuh Manager et les agents (sans l'Indexer ni le Dashboard). (2) Configurer Filebeat sur le manager pour envoyer les alertes vers Elasticsearch (output.elasticsearch dans filebeat.yml). (3) Importer les templates d'index Wazuh dans Elasticsearch. (4) Installer le plugin Wazuh pour Kibana (disponible pour les versions compatibles). (5) Configurer l'API Wazuh dans le plugin Kibana. Attention aux limitations : certaines fonctionnalités du Dashboard Wazuh natif peuvent ne pas être disponibles dans le plugin Kibana, et les mises à jour nécessitent une compatibilité entre les versions Wazuh/ELK/plugin. Pour les nouveaux déploiements, l'Indexer natif est recommandé pour la simplicité de maintenance et la compatibilité garantie.

Quelles sont les meilleures pratiques pour la gestion des faux positifs dans Wazuh ?

La gestion des faux positifs est cruciale pour maintenir la confiance des analystes SOC dans les alertes Wazuh. Les meilleures pratiques : (1) Déploiement en mode observation d'abord — configurer les nouvelles règles avec un niveau bas (2-5) pendant 2-4 semaines pour observer le volume avant de passer en alerte. (2) Exclusions ciblées via des overrides dans local_rules.xml — utiliser <if_sid> combiné avec des conditions d'exclusion (<match negate="yes">) plutôt que de désactiver la règle entière. (3) CDB lists d'exclusion — maintenir des allowlists de serveurs de backup, comptes de service, scanners de vulnérabilités qui génèrent des alertes légitimes. (4) Groupes d'agents avec des configurations différenciées — les serveurs de développement peuvent avoir des seuils différents de la production. (5) Revue hebdomadaire des Top 10 alertes par volume pour identifier les faux positifs systématiques. (6) Documentation de chaque exclusion avec justification et date de revue. L'objectif est de maintenir un ratio signal/bruit permettant aux analystes de traiter efficacement les alertes sans fatigue.

Comment surveiller les conteneurs Docker et Kubernetes avec Wazuh ?

La surveillance des environnements containerisés avec Wazuh s'effectue à plusieurs niveaux : (1) Agent sur les nœuds hôtes — un agent Wazuh par nœud Docker/Kubernetes collecte les logs du daemon Docker (/var/log/docker.log), les événements Kubernetes (audit log), et surveille l'intégrité des fichiers de configuration des containers. (2) Module Docker Listener — le wodle docker-listener de Wazuh surveille les événements Docker (start, stop, create, destroy, exec) en temps réel. (3) Collecte des logs containers — configuration du logging driver Docker pour envoyer les logs des containers vers syslog, puis collectés par l'agent Wazuh. (4) Kubernetes audit logs — collecte via webhook ou fichier des audit logs du kube-apiserver pour détecter les opérations suspectes (privilege escalation, pod creation avec hostPath, exec into pod). (5) Règles personnalisées pour détecter : containers privilégiés, montages de volumes sensibles, création de pods dans des namespaces non autorisés, et modifications des RBAC.

Quel est le coût total de possession (TCO) de Wazuh comparé aux SIEM commerciaux ?

Le TCO de Wazuh est significativement inférieur aux SIEM commerciaux, mais les coûts ne se limitent pas à la licence (gratuite). Les coûts réels incluent : Infrastructure — serveurs/VMs/cloud pour le Manager, l'Indexer et le Dashboard (typiquement 3-10 serveurs pour un déploiement entreprise). Stockage — les logs indexés consomment un espace significatif (estimez 1-5 GB/jour par millier d'agents selon la verbosité). Personnel — ingénieurs pour le déploiement initial (1-4 semaines), la maintenance (20-40% d'un FTE), et la création de règles personnalisées. Formation — montée en compétences des analystes SOC sur la plateforme. En comparaison, un SIEM comme Splunk coûte 2000-5000 USD/GB/jour ingéré, Microsoft Sentinel facture par GB ingéré (~2.5 EUR/GB), et QRadar nécessite des licences par EPS. Pour un environnement de 1000 agents avec 10 GB/jour de logs, Wazuh coûte environ 30-50K EUR/an (infrastructure + 0.5 FTE) contre 100-500K EUR/an pour un SIEM commercial équivalent. L'économie est encore plus significative à grande échelle.

Wazuh pour la conformite reglementaire

Mapping PCI DSS 4.0

Wazuh offre un support natif pour la conformite PCI DSS 4.0 avec des politiques SCA pre-configurees, des regles de detection mappees aux exigences PCI, et des tableaux de bord de conformite dans le Dashboard. Les exigences PCI DSS couvertes par Wazuh incluent : Requirement 5 (protection contre les malwares) via la detection de rootkits et le monitoring d'integrite, Requirement 6 (developpement et maintenance de systemes securises) via la detection de vulnerabilites, Requirement 10 (journalisation et monitoring) via la collecte centralisee des logs et la detection d'activites suspectes, Requirement 11 (tests de securite reguliers) via le SCA et le FIM, et Requirement 12 (politique de securite) via le reporting de conformite. Le Dashboard Wazuh genere des rapports PCI DSS pre-formates montrant le statut de conformite pour chaque exigence, les alertes associees, et les lacunes identifiees — directement utilisables lors des audits QSA (Qualified Security Assessor).

Mapping RGPD et NIS2

Pour la conformite RGPD, Wazuh contribue au respect des articles relatifs a la securite du traitement (Article 32) via le monitoring des acces aux systemes traitant des donnees personnelles, la detection des transferts de donnees non autorises, et l'alerting sur les tentatives d'acces suspectes. Le FIM surveille l'integrite des fichiers contenant des donnees personnelles, tandis que les regles de detection identifient les exfiltrations potentielles (transferts volumineux, acces hors heures, connexions depuis des geolocalisations inhabituelles). Pour la directive NIS2, Wazuh couvre les exigences de gestion des incidents (Article 21) via la detection automatisee et la generation de rapports d'incidents, les mesures techniques de securite via le SCA et la detection de vulnerabilites, et les obligations de reporting via les dashboards et les integrations SOAR qui automatisent la notification aux autorites competentes dans les delais requis (24 heures pour l'alerte initiale, 72 heures pour le rapport d'incident).

Rapports de conformite automatises

# Generation de rapports de conformite via l'API Wazuh
TOKEN=$(curl -k -u admin:password https://localhost:55000/security/user/authenticate 2>/dev/null | jq -r '.data.token')

# Rapport PCI DSS - regles declenchees par requirement
curl -k -H "Authorization: Bearer $TOKEN"   "https://localhost:55000/rules?pci_dss=10.2.4,10.2.5&pretty"

# Rapport GDPR - alertes liees aux donnees personnelles
curl -k -H "Authorization: Bearer $TOKEN"   "https://localhost:55000/rules?gdpr=IV_35.7.d&pretty"

# Export des resultats SCA (baselines CIS)
curl -k -H "Authorization: Bearer $TOKEN"   "https://localhost:55000/sca/001/checks/results?pretty"

# Rapport de vulnerabilites par severite
curl -k -H "Authorization: Bearer $TOKEN"   "https://localhost:55000/vulnerability/001?pretty"

# Automatisation via cron (rapport hebdomadaire)
# 0 8 * * 1 /opt/wazuh-scripts/generate-compliance-report.sh | mail -s "Wazuh Weekly Compliance" security@company.com

Architecture de haute disponibilite et disaster recovery

Les deployments Wazuh de production necessitent une strategie de haute disponibilite (HA) et de reprise apres sinistre (DR) pour garantir la continuite de la surveillance de securite. L'architecture HA Wazuh repose sur trois piliers : le cluster de managers (un master et des workers redondants, avec failover automatique des agents vers les workers disponibles), le cluster OpenSearch (3+ noeuds avec replicas pour la redondance des donnees indexees), et le load balancing des composants exposes (Dashboard derriere un reverse proxy/LB, communication agents via un LB TCP distribue).

Strategies de backup et restauration

La strategie de backup Wazuh doit couvrir trois categories de donnees : la configuration (fichiers ossec.conf, regles personnalisees, decoders, CDB lists, cles d'agents), les alertes indexees (snapshots OpenSearch vers S3 ou NFS), et l'etat operationnel (base de donnees SQLite des agents, resultats FIM/SCA). La configuration est la plus critique car elle contient la logique de detection personnalisee accumulee au fil du temps — sa perte necessiterait une reconstruction manuelle longue et sujette a erreurs. Les alertes indexees representent le volume le plus important et sont sauvegardees via le mecanisme natif de snapshots OpenSearch, configurable pour des backups incrementaux vers un stockage objet (S3, MinIO, Azure Blob). La restauration doit etre testee regulierement via des exercices DR incluant le redeploiement complet de la stack Wazuh sur une infrastructure de secours et la verification de la reprise de la surveillance.

# Backup de la configuration Wazuh Manager
tar czf /backup/wazuh-config-$(date +%Y%m%d).tar.gz   /var/ossec/etc/ossec.conf   /var/ossec/etc/rules/local_rules.xml   /var/ossec/etc/decoders/local_decoder.xml   /var/ossec/etc/lists/   /var/ossec/etc/shared/   /var/ossec/etc/client.keys   /var/ossec/queue/db/

# Snapshot OpenSearch vers un repository
curl -k -u admin:password -X PUT "https://localhost:9200/_snapshot/backup_repo"   -H 'Content-Type: application/json' -d'{
    "type": "fs",
    "settings": {
      "location": "/backup/opensearch-snapshots",
      "compress": true
    }
}'

# Creation du snapshot
curl -k -u admin:password -X PUT "https://localhost:9200/_snapshot/backup_repo/snap_$(date +%Y%m%d)"   -H 'Content-Type: application/json' -d'{
    "indices": "wazuh-alerts-*",
    "include_global_state": false
}'

# Restauration depuis un snapshot
curl -k -u admin:password -X POST "https://localhost:9200/_snapshot/backup_repo/snap_20260429/_restore"   -H 'Content-Type: application/json' -d'{
    "indices": "wazuh-alerts-*",
    "rename_pattern": "wazuh-alerts-(.*)",
    "rename_replacement": "restored-wazuh-alerts-$1"
}'

# Verification de l'integrite du backup
/var/ossec/bin/wazuh-control info
curl -k -u admin:password "https://localhost:9200/_snapshot/backup_repo/_all?pretty"

Cas d'usage avances : threat hunting avec Wazuh

Le threat hunting avec Wazuh exploite les donnees collectees par les agents et indexees dans OpenSearch pour rechercher proactivement des indicateurs de compromission et des comportements suspects qui n'ont pas declenche d'alertes automatiques. Les analystes SOC utilisent le Dashboard Wazuh et les requetes OpenSearch DSL pour investiguer des hypotheses de menaces basees sur la threat intelligence, les rapports d'incidents dans le secteur, et les nouveaux TTP documentes par MITRE ATT&CK. Les cas d'usage de threat hunting les plus courants avec Wazuh incluent la recherche de persistence mecanisms non detectes (taches planifiees suspectes, services inhabituels, cles de registre Run), la detection de mouvement lateral via l'analyse des connexions inter-machines (patterns de login type 3 anormaux entre serveurs), l'identification de beaconning C2 via l'analyse de periodicite des connexions sortantes, et la detection de data staging (accumulation de fichiers dans des repertoires temporaires avant exfiltration).

# Threat Hunting queries - OpenSearch DSL via l'API

# Recherche de processus suspects lances par des services
curl -k -u admin:password "https://localhost:9200/wazuh-alerts-*/_search?pretty"   -H 'Content-Type: application/json' -d'{
    "query": {
      "bool": {
        "must": [
          {"match": {"rule.groups": "sysmon_event1"}},
          {"match": {"data.win.eventdata.parentImage": "services.exe"}},
          {"bool": {
            "must_not": [
              {"match": {"data.win.eventdata.image": "svchost.exe"}},
              {"match": {"data.win.eventdata.image": "spoolsv.exe"}},
              {"match": {"data.win.eventdata.image": "wuauclt.exe"}}
            ]
          }}
        ]
      }
    },
    "sort": [{"@timestamp": "desc"}],
    "size": 50
}'

# Recherche de connexions reseau inhabituelles depuis des LOLBins
curl -k -u admin:password "https://localhost:9200/wazuh-alerts-*/_search?pretty"   -H 'Content-Type: application/json' -d'{
    "query": {
      "bool": {
        "must": [
          {"match": {"rule.groups": "sysmon_event3"}},
          {"bool": {
            "should": [
              {"wildcard": {"data.win.eventdata.image": "*certutil*"}},
              {"wildcard": {"data.win.eventdata.image": "*mshta*"}},
              {"wildcard": {"data.win.eventdata.image": "*regsvr32*"}},
              {"wildcard": {"data.win.eventdata.image": "*rundll32*"}}
            ]
          }}
        ],
        "must_not": [
          {"match": {"data.win.eventdata.destinationIp": "127.0.0.1"}}
        ]
      }
    }
}'

# Detection de beaconning (connexions periodiques)
# Analyse des intervalles entre les connexions d'un meme processus
curl -k -u admin:password "https://localhost:9200/wazuh-alerts-*/_search?pretty"   -H 'Content-Type: application/json' -d'{
    "size": 0,
    "query": {
      "bool": {
        "must": [
          {"match": {"rule.groups": "sysmon_event3"}},
          {"range": {"@timestamp": {"gte": "now-24h"}}}
        ]
      }
    },
    "aggs": {
      "by_process": {
        "terms": {"field": "data.win.eventdata.image", "size": 50},
        "aggs": {
          "by_destination": {
            "terms": {"field": "data.win.eventdata.destinationIp", "size": 10},
            "aggs": {
              "connection_times": {
                "date_histogram": {"field": "@timestamp", "fixed_interval": "5m"}
              }
            }
          }
        }
      }
    }
}'

Migration et evolution de l'infrastructure Wazuh

La migration vers Wazuh depuis d'autres SIEM ou la mise a niveau d'une installation Wazuh existante sont des operations critiques qui necessitent une planification rigoureuse. La migration depuis Splunk implique la conversion des recherches SPL en regles Wazuh (XML) ou en requetes OpenSearch, la reconfiguration des sources de logs (Splunk Universal Forwarders remplaces par les agents Wazuh), et la migration des dashboards et des alertes. La migration depuis ELK Stack (sans Wazuh) est plus directe car l'Indexer Wazuh utilise OpenSearch (compatible Elasticsearch), mais les regles de detection doivent etre recreees dans le format XML Wazuh plutot qu'en detection rules ElasticSearch. La mise a niveau majeure de Wazuh (par exemple 4.7 vers 4.9) suit un processus ordonne : mise a jour de l'Indexer en premier (compatible avec l'ancienne version du manager), puis du Manager, puis du Dashboard, et enfin des agents (qui supportent la retrocompatibilite avec les managers plus recents). L'utilisation de configuration management (Ansible, Puppet, Chef) pour le deploiement et la configuration de Wazuh facilite les mises a jour a grande echelle et garantit la coherence de la configuration entre les environnements.

Wazuh et la securite cloud-native

La securite des environnements cloud-native avec Wazuh s'etend au-dela de la surveillance des conteneurs pour couvrir l'ensemble de l'infrastructure cloud. Le module AWS collecte les logs CloudTrail (activite API), GuardDuty (menaces detectees), VPC Flow Logs (trafic reseau), WAF (requetes web), et CloudWatch Logs (logs applicatifs). Le module Azure (en complement d'Office 365) collecte les logs Azure Activity, Azure AD Sign-ins, et Azure Security Center. Le module GCP collecte les Cloud Audit Logs et les findings de Security Command Center. Pour chaque provider cloud, Wazuh fournit des regles de detection pre-configurees couvrant les menaces specifiques au cloud : creation de ressources non autorisees, modification des politiques IAM, desactivation du logging (defense evasion), exposition publique de ressources privees (S3 buckets, storage accounts), et detection des lateral movements entre services cloud. L'integration des logs cloud avec les logs on-premise dans le meme Wazuh Manager permet une correlation cross-environment impossible avec des outils cloisonnes.

Checklist de deploiement Wazuh en production :

Dimensionner l'infrastructure selon le nombre d'agents et le volume d'EPS (voir les recommandations de sizing)
Deployer en mode distribue pour les environnements 500+ agents (manager + indexer + dashboard separes)
Configurer le clustering pour la haute disponibilite (3+ noeuds indexer, master + workers manager)
Personnaliser les regles de detection pour l'environnement specifique (AD, cloud, applications metier)
Configurer le FIM sur les fichiers et repertoires critiques avec le mode realtime/whodata
Activer les politiques SCA (CIS Benchmarks) adaptees aux OS et applications deployes
Integrer TheHive/MISP/Shuffle pour l'automatisation du workflow SOC
Configurer les CDB lists avec les IOC de threat intelligence (MISP sync automatique)
Implementer l'Active Response pour les scenarios de reponse automatique (brute force, IOC matching)
Configurer la retention et les snapshots OpenSearch pour le backup et la conformite
Mettre en place le monitoring de la sante de Wazuh lui-meme (alertes si un agent se deconnecte)
Documenter les regles personnalisees et les exclusions de faux positifs avec justification

Wazuh et la detection des menaces avancees (APT)

Detection des techniques de persistence avancee

Wazuh, combine avec Sysmon sur les endpoints Windows, permet la detection des mecanismes de persistance avances utilises par les groupes APT. Les techniques ciblees incluent les WMI Event Subscriptions (detectees via les evenements Sysmon EID 19/20/21 captant la creation de filtres, consommateurs et bindings WMI), les DLL Search Order Hijacking (detection via Sysmon EID 7 montrant le chargement de DLL depuis des emplacements non standards par des processus legitimes), les AppInit_DLLs et AppCertDLLs (surveillance du registre via Sysmon EID 13 pour les cles HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLs), les COM Object Hijacking (modifications des cles CLSID dans le registre), et les Scheduled Tasks cachees (taches planifiees avec le flag Hidden ou stockees dans des emplacements non standards du registre). Pour chaque technique de persistance, Wazuh peut etre configure avec des regles de detection specifiques correlant les evenements Sysmon avec des CDB lists de binaires et chemins legitimes, reduisant significativement les faux positifs.

<!-- Regles Wazuh pour la detection de persistance avancee -->
<group name="persistence,apt,">

  <!-- Detection WMI Event Subscription (Sysmon EID 19) -->
  <rule id="100500" level="12">
    <if_sid>61600</if_sid>
    <field name="win.system.eventID">19</field>
    <description>WMI EventFilter created: $(win.eventdata.name) - possible persistence</description>
    <mitre>
      <id>T1546.003</id>
    </mitre>
    <group>wmi_persistence,high_priority,</group>
  </rule>

  <!-- Detection COM Object Hijacking -->
  <rule id="100501" level="10">
    <if_sid>61603</if_sid>
    <field name="win.system.eventID">13</field>
    <field name="win.eventdata.targetObject">HKCR\\CLSID</field>
    <field name="win.eventdata.targetObject">InprocServer32</field>
    <description>COM Object modification detected: $(win.eventdata.targetObject) - possible hijacking</description>
    <mitre>
      <id>T1546.015</id>
    </mitre>
    <group>com_hijack,persistence,</group>
  </rule>

  <!-- Detection DLL Side-Loading (DLL chargee depuis un emplacement non standard) -->
  <rule id="100502" level="8">
    <if_sid>61603</if_sid>
    <field name="win.system.eventID">7</field>
    <field name="win.eventdata.signed">false</field>
    <field name="win.eventdata.imageLoaded" negate="yes">C:\\Windows</field>
    <description>Unsigned DLL loaded from non-system path: $(win.eventdata.imageLoaded) by $(win.eventdata.image)</description>
    <mitre>
      <id>T1574.001</id>
    </mitre>
    <group>dll_sideloading,defense_evasion,</group>
  </rule>

  <!-- Detection de modification des AppInit_DLLs -->
  <rule id="100503" level="14">
    <if_sid>61603</if_sid>
    <field name="win.system.eventID">13</field>
    <field name="win.eventdata.targetObject">AppInit_DLLs</field>
    <description>AppInit_DLLs registry key modified - possible DLL injection persistence</description>
    <mitre>
      <id>T1546.010</id>
    </mitre>
    <group>persistence,critical,</group>
  </rule>

</group>

Detection du mouvement lateral avec Wazuh

La detection du mouvement lateral est l'un des cas d'usage les plus critiques pour un SIEM dans les environnements Active Directory. Wazuh peut detecter les techniques de mouvement lateral les plus courantes grace a la correlation des logs Windows Security et Sysmon provenant de multiples agents. Les patterns de detection incluent : les Pass-the-Hash (EventID 4624 avec LogonType 3 et NtlmV1/NtlmV2 depuis des workstations non habituelles), le PsExec et variantes (EventID 7045 creation de service + EventID 1 processus cmd.exe avec parent services.exe sur la machine cible), le WinRM/PowerShell Remoting (EventID 4624 LogonType 3 + EventID 1 avec processus wsmprovhost.exe), le RDP lateral (EventID 4624 LogonType 10 depuis des machines internes non habituelles), et le WMI lateral (EventID 4624 LogonType 3 + processus wmiprvse.exe executant des commandes). La correlation entre les evenements de connexion sur la machine source et la machine destination, avec la verification des CDB lists d'acces autorises, permet de distinguer les connexions administratives legitimes des mouvements lateraux malveillants. La visualisation des flux de connexion entre machines dans le Dashboard Wazuh aide les analystes SOC a identifier les patterns de mouvement lateral lors des investigations.

Integration avec Velociraptor pour l'investigation forensique

L'integration de Wazuh avec Velociraptor (outil de forensique et de response open source) cree une synergie puissante : Wazuh detecte les menaces via la correlation de logs, et Velociraptor fournit les capacites d'investigation approfondie (collecte d'artefacts, analyse de memoire, hunting a grande echelle) necessaires pour comprendre l'etendue d'une compromission identifiee. L'integration s'effectue via les webhooks Wazuh : lorsqu'une alerte de haute severite est declenchee, un workflow automatise (via Shuffle SOAR ou un script Python) lance une collection d'artefacts Velociraptor sur l'agent concerne — collecte des processus en cours, connections reseau, modules charges, fichiers recemment modifies, et evenements de registre — fournissant aux analystes les donnees forensiques necessaires pour l'investigation sans attendre qu'un intervenant humain initie manuellement la collecte. Cette automatisation est critique car les artefacts volatils (processus, connexions, memoire) disparaissent rapidement apres la detection initiale, et le delai entre la detection et la collecte forensique est souvent trop long dans les workflows manuels traditionnels.

Automatisation avancee et scripting Wazuh

Wodles personnalises : extension des capacites de collecte

Les wodles (Wazuh modules) sont des composants extensibles qui ajoutent des capacites de collecte et d'analyse au-dela des logs systeme standards. Les wodles natifs incluent vulnerability-detector, osquery, docker-listener, aws-s3, office365, et command. Le wodle command permet d'executer des commandes personnalisees a intervalles reguliers et de traiter leur sortie comme des logs analysables par les decoders et regles Wazuh — offrant une extensibilite quasi-illimitee. Les cas d'usage courants des wodles command incluent la collecte de metriques de securite personnalisees (nombre de connexions actives, processus en ecoute, modules kernel charges), l'interrogation d'APIs tierces (VirusTotal, Shodan, GreyNoise) pour l'enrichissement d'alertes, le monitoring de certificats TLS (expiration, algorithmes faibles), et la verification periodique de l'integrite des baselines de securite au-dela de ce que le SCA standard couvre.

<!-- Wodle command personnalise : monitoring des connexions suspectes -->
<wodle name="command">
  <disabled>no</disabled>
  <tag>network-monitor</tag>
  <command>/var/ossec/wodles/scripts/check_connections.sh</command>
  <interval>5m</interval>
  <ignore_output>no</ignore_output>
  <run_on_start>yes</run_on_start>
  <timeout>30</timeout>
</wodle>

<!-- Wodle pour la verification des certificats TLS -->
<wodle name="command">
  <disabled>no</disabled>
  <tag>cert-monitor</tag>
  <command>/var/ossec/wodles/scripts/check_certificates.sh</command>
  <interval>24h</interval>
  <ignore_output>no</ignore_output>
  <run_on_start>yes</run_on_start>
  <timeout>120</timeout>
</wodle>

<!-- Wodle pour interrogation VirusTotal -->
<wodle name="command">
  <disabled>no</disabled>
  <tag>virustotal-check</tag>
  <command>/var/ossec/wodles/scripts/vt_hash_check.py</command>
  <interval>15m</interval>
  <ignore_output>no</ignore_output>
  <run_on_start>no</run_on_start>
  <timeout>60</timeout>
</wodle>

#!/bin/bash
# /var/ossec/wodles/scripts/check_connections.sh
# Detecte les connexions sortantes vers des ports suspects

SUSPICIOUS_PORTS="4444 5555 6666 8888 1234 31337 12345"

for port in $SUSPICIOUS_PORTS; do
    connections=$(ss -tnp state established "( dport = :$port )" 2>/dev/null)
    if [ -n "$connections" ]; then
        echo "$connections" | while read line; do
            echo "SUSPICIOUS_CONNECTION: port=$port details=$line"
        done
    fi
done

# Detecter les processus avec des connexions vers des IP externes non-RFC1918
ss -tnp state established | grep -v -E '(127\.|10\.|172\.(1[6-9]|2[0-9]|3[01])\.|192\.168\.)' | while read line; do
    process=$(echo "$line" | grep -oP 'users:\(\("\K[^"]+')
    dst=$(echo "$line" | awk '{print $5}')
    if [ -n "$process" ] && [ -n "$dst" ]; then
        echo "EXTERNAL_CONNECTION: process=$process destination=$dst"
    fi
done

API Wazuh : automatisation des operations SOC

L'API REST Wazuh (port 55000) fournit un acces programmatique complet a toutes les fonctionnalites du manager, permettant l'automatisation des operations SOC quotidiennes. Les cas d'usage d'automatisation via l'API incluent : le provisionning automatique d'agents (creation de groupes, assignation de politiques), l'extraction de metriques de securite pour les dashboards executifs (nombre d'alertes par severite, couverture d'agents, compliance score), la generation de rapports periodiques personnalises (top alertes de la semaine, nouveaux agents, agents deconnectes), l'integration avec les systemes de ticketing (creation automatique de tickets pour les alertes critiques), et la gestion du cycle de vie des agents (detection et nettoyage des agents inactifs, mise a jour des configurations de groupe).

#!/usr/bin/env python3
# Exemple d'automatisation SOC via l'API Wazuh
import requests
import json
from datetime import datetime, timedelta

WAZUH_URL = "https://wazuh-manager:55000"
WAZUH_USER = "admin"
WAZUH_PASS = "password"

class WazuhAutomation:
    def __init__(self):
        self.token = self._authenticate()

    def _authenticate(self):
        response = requests.post(
            f"{WAZUH_URL}/security/user/authenticate",
            auth=(WAZUH_USER, WAZUH_PASS),
            verify=False
        )
        return response.json()["data"]["token"]

    def _get(self, endpoint, params=None):
        headers = {"Authorization": f"Bearer {self.token}"}
        response = requests.get(
            f"{WAZUH_URL}{endpoint}",
            headers=headers,
            params=params,
            verify=False
        )
        return response.json()

    def get_critical_alerts_summary(self, hours=24):
        """Resume des alertes critiques des dernieres heures"""
        # Via OpenSearch directement pour les requetes complexes
        agents = self._get("/agents", {"status": "active"})
        summary = self._get("/overview/agents")
        return {
            "total_active_agents": summary["data"]["nodes"]["active"],
            "disconnected_agents": summary["data"]["nodes"]["disconnected"],
            "timestamp": datetime.utcnow().isoformat()
        }

    def find_disconnected_agents(self, hours=4):
        """Trouve les agents deconnectes depuis plus de X heures"""
        agents = self._get("/agents", {
            "status": "disconnected",
            "limit": 500
        })
        disconnected = []
        cutoff = datetime.utcnow() - timedelta(hours=hours)
        for agent in agents.get("data", {}).get("affected_items", []):
            last_seen = datetime.strptime(
                agent.get("lastKeepAlive", ""),
                "%Y-%m-%dT%H:%M:%S+00:00"
            )
            if last_seen < cutoff:
                disconnected.append({
                    "id": agent["id"],
                    "name": agent["name"],
                    "ip": agent.get("ip"),
                    "last_seen": agent.get("lastKeepAlive")
                })
        return disconnected

    def generate_weekly_report(self):
        """Genere un rapport hebdomadaire de securite"""
        report = {
            "generated_at": datetime.utcnow().isoformat(),
            "agent_status": self.get_critical_alerts_summary(),
            "disconnected_agents": self.find_disconnected_agents(hours=48),
            "sca_compliance": self._get("/sca/001")
        }
        return json.dumps(report, indent=2)

# Execution
automation = WazuhAutomation()
disconnected = automation.find_disconnected_agents()
if disconnected:
    print(f"ALERTE: {len(disconnected)} agents deconnectes depuis plus de 4h")
    for agent in disconnected:
        print(f"  - {agent['name']} ({agent['ip']}) - dernier contact: {agent['last_seen']}")

Labels et enrichissement des alertes

L'enrichissement des alertes Wazuh transforme les evenements bruts en informations actionnables pour les analystes SOC. Au-dela des CDB lists pour le matching d'IOC, Wazuh supporte plusieurs mecanismes d'enrichissement. Les labels ajoutent des metadonnees statiques aux alertes basees sur le groupe d'agents ou la regle declenchee (par exemple, labelliser les alertes des agents du groupe pci-scope avec un tag compliance:pci). Les decoders avec enrichissement extraient des champs additionnels des logs et les rendent disponibles dans les alertes pour filtrage et correlation. L'enrichissement dynamique via integrations utilise les webhooks Wazuh pour envoyer les alertes a des services d'enrichissement externes (VirusTotal pour les hashes de fichiers, AbuseIPDB pour les adresses IP, MaxMind GeoIP pour la geolocalisation) et enrichir les alertes avec le contexte retourne. L'outil Shuffle SOAR est particulierement efficace pour l'enrichissement automatise car il permet de creer des workflows visuels qui recoivent une alerte Wazuh, l'enrichissent via plusieurs APIs en parallele, et mettent a jour l'alerte ou creent un ticket enrichi dans TheHive avec toutes les informations contextuelles necessaires a l'investigation.

Wazuh et le framework MITRE ATT&CK

Wazuh integre nativement le framework MITRE ATT&CK dans ses regles de detection et son dashboard. Chaque regle peut etre taguee avec un ou plusieurs identifiants de technique ATT&CK via l'element XML <mitre><id>Txxxx</id></mitre>, et le Dashboard Wazuh fournit une vue matricielle ATT&CK montrant les techniques detectees dans l'environnement. Cette integration permet aux equipes SOC de visualiser leur couverture de detection par rapport au framework ATT&CK, d'identifier les lacunes (tactiques ou techniques non couvertes par les regles actuelles), et de prioriser le developpement de nouvelles regles pour combler ces gaps. L'approche recommandee est de mapper systematiquement toutes les regles personnalisees aux techniques ATT&CK correspondantes, de generer regulierement une heat map de couverture, et de comparer cette couverture avec les TTP des groupes de menaces pertinents pour le secteur d'activite de l'organisation (disponibles dans les rapports de threat intelligence et dans MITRE ATT&CK Navigator). Les exercices de purple team utilisant Atomic Red Team generent des alertes qui apparaissent dans la vue ATT&CK du Dashboard, permettant de valider visuellement que les tests ont ete detectes pour chaque technique testee. La combinaison de cette vue ATT&CK native avec les rapports de conformite (PCI DSS, RGPD, NIS2) fournit une image complete de la posture de securite de l'organisation, couvrant a la fois la detection des menaces et la conformite reglementaire dans un seul dashboard unifie.

Gestion avancee des agents et configuration centralisee

Configuration centralisee via les groupes d'agents

Les groupes d'agents Wazuh permettent de gerer la configuration de maniere centralisee en regroupant les agents par role, localisation ou niveau de criticite. Chaque groupe possede un fichier de configuration partage (/var/ossec/etc/shared/GROUP_NAME/agent.conf) qui est automatiquement distribue a tous les agents du groupe. Cette fonctionnalite est essentielle pour les deployments a grande echelle ou la configuration individuelle de chaque agent serait impraticable. Les cas d'usage typiques incluent : un groupe linux-servers avec des politiques SCA CIS Linux et un FIM sur /etc et /var/www, un groupe windows-servers avec des politiques SCA CIS Windows et la collecte des logs Security et Sysmon, un groupe domain-controllers avec des regles de detection AD renforcees et un FIM sur les fichiers SYSVOL et NTDS, un groupe pci-scope avec des politiques de conformite PCI DSS specifiques et un monitoring renforce, et un groupe dmz-servers avec des regles de detection web et une Active Response aggressive pour le blocage automatique d'IP. Les agents peuvent appartenir a plusieurs groupes simultanement, heritant de la configuration combinee de tous leurs groupes.

<!-- Configuration de groupe : /var/ossec/etc/shared/linux-servers/agent.conf -->
<agent_config>
  <!-- FIM specifique aux serveurs Linux -->
  <syscheck>
    <frequency>300</frequency>
    <directories realtime="yes" check_all="yes" report_changes="yes">/etc,/usr/bin,/usr/sbin</directories>
    <directories realtime="yes" check_all="yes">/var/www</directories>
    <ignore>/etc/mtab</ignore>
    <ignore type="sregex">\.swp$|\.tmp$</ignore>
  </syscheck>

  <!-- Collecte des logs applicatifs -->
  <localfile>
    <log_format>syslog</log_format>
    <location>/var/log/auth.log</location>
  </localfile>

  <localfile>
    <log_format>apache</log_format>
    <location>/var/log/apache2/access.log</location>
  </localfile>

  <!-- SCA baselines -->
  <sca>
    <enabled>yes</enabled>
    <policies>
      <policy>cis_ubuntu22-04.yml</policy>
    </policies>
  </sca>
</agent_config>

Monitoring de la sante de l'infrastructure Wazuh

Le monitoring de la sante de l'infrastructure Wazuh elle-meme est critique pour garantir la continuite de la surveillance de securite. Un SIEM non fonctionnel est pire qu'un SIEM absent car il cree un faux sentiment de securite. Les elements a surveiller incluent : la connectivite des agents (alerter lorsqu'un agent passe en status disconnected pendant plus de X minutes, particulierement pour les agents sur des systemes critiques), les performances du manager (queue d'evenements, latence de traitement, utilisation CPU/memoire), la sante de l'indexer (espace disque disponible, status des shards, latence d'indexation, age du plus ancien document non indexe), et la disponibilite du dashboard (verification HTTP/HTTPS). Wazuh peut se surveiller lui-meme via des regles internes (les alertes sur la deconnexion d'agents sont natives avec la rule 502), mais un monitoring externe via Prometheus/Grafana ou Nagios/Zabbix est recommande pour eviter le probleme du chien de garde qui ne surveille pas lui-meme. Les metriques exportees par l'API Wazuh (/manager/stats, /agents/summary) et les metriques OpenSearch (_cat/health, _cluster/stats) fournissent les donnees necessaires pour ces dashboards de monitoring operationnel.

Gestion du cycle de vie des regles de detection

La gestion du cycle de vie des regles de detection est un processus structurel qui garantit la pertinence et l'efficacite des detections dans le temps. Le cycle comprend : (1) la creation de nouvelles regles en reponse a de nouvelles menaces identifiees (CTI feeds, incidents internes, nouvelles techniques MITRE ATT&CK), (2) le test en mode audit pendant 2-4 semaines pour evaluer le volume d'alertes et le taux de faux positifs dans l'environnement specifique, (3) la mise en production avec le niveau de severite et les actions de reponse appropriees, (4) la revue periodique (trimestrielle) pour evaluer la pertinence des regles existantes (les regles sans declenchement depuis 6 mois sont candidates a la desactivation ou a la revision), (5) la mise a jour des regles en fonction des evolutions de l'environnement (nouvelles applications, changements d'infrastructure, evolution des TTP adversaires), et (6) la desactivation des regles obsoletes avec documentation de la justification. La gestion des regles sous controle de version (Git) permet le suivi des modifications, la revue par les pairs (pull requests pour les nouvelles regles), et le rollback en cas de regression. Les tests automatises (injection de logs de test et verification que les regles attendues se declenchent) dans un pipeline CI/CD assurent que les modifications de regles ne cassent pas les detections existantes.

Wazuh pour la securite des applications web

Integration avec les logs de serveurs web

Wazuh fournit des decoders et regles natifs pour l'analyse des logs de serveurs web (Apache, Nginx, IIS), permettant la detection des attaques web courantes directement depuis les logs d'acces et d'erreur. Les detections incluent les tentatives d'injection SQL (patterns UNION SELECT, OR 1=1 dans les URI et parametres), les attaques XSS (detection de balises script et event handlers dans les parametres), les scans de vulnerabilites (volume anormal de requetes 404, patterns de scanners connus comme Nikto, SQLMap, Acunetix), les attaques par force brute sur les formulaires d'authentification (codes 401/403 repetitifs depuis la meme IP), et les tentatives de traversee de chemin (patterns ../ dans les URI). La configuration requiert que les logs du serveur web soient accessibles a l'agent Wazuh, soit via la lecture directe du fichier de log, soit via syslog forwarding.

<!-- Configuration de la collecte des logs web -->
<localfile>
  <log_format>apache</log_format>
  <location>/var/log/apache2/access.log</location>
</localfile>

<localfile>
  <log_format>apache</log_format>
  <location>/var/log/nginx/access.log</location>
</localfile>

<!-- Regles personnalisees pour les attaques web -->
<group name="web,attack,">
  <rule id="100600" level="10" frequency="20" timeframe="60">
    <if_matched_sid>31101</if_matched_sid>
    <same_source_ip/>
    <description>Web: Vulnerability scan detected from $(srcip)</description>
    <mitre><id>T1595.002</id></mitre>
  </rule>

  <rule id="100601" level="12">
    <if_sid>31100</if_sid>
    <url>union.*select|or.*1.*=.*1|drop.*table</url>
    <description>Web: SQL injection attempt from $(srcip)</description>
    <mitre><id>T1190</id></mitre>
  </rule>

  <rule id="100602" level="10" frequency="10" timeframe="60">
    <if_matched_sid>31103</if_matched_sid>
    <same_source_ip/>
    <description>Web: HTTP authentication brute force from $(srcip)</description>
    <mitre><id>T1110</id></mitre>
  </rule>
</group>

Monitoring de la securite des applications personnalisees

Pour les applications web personnalisees (developpees en interne), Wazuh peut etre configure pour analyser les logs applicatifs et detecter les evenements de securite specifiques a l'application. La methodologie implique : (1) l'identification des evenements de securite generes par l'application (echecs d'authentification, tentatives d'escalade de privileges, acces a des ressources non autorisees, erreurs de validation d'entree), (2) la creation de decoders personnalises parsant le format de log specifique de l'application, (3) la creation de regles associees avec les niveaux de severite appropries et les tags MITRE ATT&CK, et (4) la configuration de l'Active Response pour les scenarios necessitant une reaction automatique (blocage IP apres brute force applicatif, desactivation de compte apres tentatives d'escalade). Cette approche transforme chaque application en source de telemetrie de securite integree dans le SIEM, augmentant significativement la visibilite sur les attaques applicatives specifiques qui ne seraient pas detectees par les regles generiques de monitoring web.

Wazuh et les WAF : complementarite

L'integration de Wazuh avec les WAF (Web Application Firewalls) comme ModSecurity, AWS WAF, Cloudflare WAF ou Azure Front Door cree une strategie de defense en profondeur pour les applications web. Les logs du WAF sont collectes par Wazuh via syslog (ModSecurity), via les modules cloud natifs (AWS WAF logs vers S3, collectes par le module aws-s3), ou via des webhooks. Wazuh peut alors correler les alertes WAF avec les evenements systeme de l'agent sur le serveur web : une alerte WAF de type SQL injection suivie d'un log d'erreur MySQL sur le serveur confirme une tentative d'exploitation reussie ayant contourne le WAF. De meme, un volume eleve d'alertes WAF depuis une IP suivi d'un silence peut indiquer que l'attaquant a adapte ses payloads pour evader les regles du WAF. Cette correlation multi-source est un avantage significatif du SIEM par rapport aux alertes isolees du WAF, et constitue une composante essentielle de la detection des compromissions web en production. Les organisations doivent configurer des regles de correlation specifiques dans Wazuh qui combinent les alertes WAF avec les evenements systeme, les logs applicatifs et les alertes FIM pour construire une image complete de chaque tentative d'attaque web, de la requete initiale a l'impact potentiel sur le systeme.

Integration avec les outils de securite reseau

Wazuh s'integre avec les outils de securite reseau pour enrichir la detection au-dela des logs endpoint. L'integration avec Suricata (IDS/IPS reseau) est native : les alertes Suricata au format EVE JSON sont collectees par l'agent Wazuh, decodees et correlees avec les evenements endpoint. Cette correlation reseau-endpoint est particulierement puissante : une alerte Suricata detectant un pattern de communication C2 combinee avec un evenement Sysmon montrant un processus suspect sur l'endpoint identifie confirme la compromission avec haute confiance et fournit le contexte complet (processus responsable, utilisateur, fichier executable, destination C2). L'integration avec Zeek (analyse de trafic reseau) enrichit la visibilite avec les connexions DNS inhabituelles (possible DNS tunneling), les certificats TLS suspects (C2 avec certificats auto-signes), et les transferts de fichiers anormaux. Pour les environnements cloud, l'integration des VPC Flow Logs (AWS) ou NSG Flow Logs (Azure) dans Wazuh permet la detection de communications laterales entre instances cloud, de connexions sortantes vers des IP malveillantes, et d'anomalies de trafic indiquant une exfiltration de donnees. La combinaison de la telemetrie endpoint (agents Wazuh), reseau (Suricata/Zeek), et cloud (Flow Logs) dans un SIEM unifie offre une visibilite a 360 degres sur les menaces, essentielle pour les operations SOC modernes.

Comparaison avec les alternatives open source

Le choix d'un SIEM open source implique de comparer Wazuh avec les alternatives disponibles, chacune ayant des forces et des limitations specifiques. Elastic Security (anciennement SIEM module d'ELK) offre des capacites de detection basees sur des regles (compatible Sigma via la conversion), une interface Kibana riche, et des fonctionnalites de timeline pour l'investigation. Cependant, depuis le changement de licence Elasticsearch (SSPL), la version gratuite est limitee et les fonctionnalites avancees (ML anomaly detection, rules de detection pre-buildees) necessitent une licence payante. Security Onion est une distribution Linux integrant Suricata (IDS reseau), Zeek (analyse de trafic), Elasticsearch et Kibana, optimisee pour la detection reseau mais moins forte sur la detection endpoint. Graylog est un SIEM focalise sur la centralisation et l'analyse de logs avec un moteur de recherche performant, mais manque des capacites natives de detection endpoint (FIM, SCA, agent) offertes par Wazuh. OSSIM (AlienVault Open Source) combine OSSEC, Suricata, Nagios et OpenVAS dans une appliance integree, mais son developpement open source a significativement ralenti depuis l'acquisition par AT&T (maintenant LevelBlue).

Critere	Wazuh	Elastic Security	Security Onion	Graylog
Detection endpoint (agent)	Excellente	Bonne (Elastic Agent)	Limitee	Non native
Detection reseau (IDS)	Via Suricata integ.	Via integration	Excellente	Non native
FIM natif	Oui (temps reel)	Oui (Elastic Agent)	Non	Non
SCA/Compliance	Oui (CIS, PCI, etc.)	Limitee	Non	Non
Detection vulnerabilites	Oui (natif)	Non	Via OpenVAS	Non
Active Response	Oui (natif)	Non native	Non	Non
Cloud monitoring (AWS/Azure)	Oui (modules natifs)	Oui (Elastic Agent)	Limitee	Via plugins
Facilite de deploiement	Elevee	Moderee	Elevee (ISO)	Elevee
Communaute	Tres active (20M+ agents)	Tres active	Active	Moderee
Support commercial	Wazuh Inc. (optionnel)	Elastic (license)	SO Solutions	Graylog Inc.
Licence	GPLv2	SSPL / Elastic License	GPLv2	Server Side PL

Le choix entre ces solutions depend des priorites de l'organisation : Wazuh excelle pour les organisations qui privilegient la detection endpoint avec FIM, SCA et conformite integres, le tout dans une solution genuinement open source avec un deployment unifie. Elastic Security est prefere lorsque l'organisation a deja un investissement ELK significatif et souhaite des capacites de recherche et visualisation avancees. Security Onion est ideal pour les organisations focalisees sur la detection reseau (NSM/IDS) avec Suricata et Zeek comme composants primaires. La tendance observee dans les SOC matures est la combinaison de Wazuh (detection endpoint et conformite) avec des outils de detection reseau (Suricata standalone ou Security Onion) et un SOAR (Shuffle, TheHive+Cortex) pour l'orchestration — creant une architecture SOC multi-couches ou chaque composant excelle dans sa specialite.

Conclusion

Wazuh s'est impose comme la plateforme de securite open source la plus complete et la plus deployee au monde, offrant des capacites de SIEM, XDR et conformite dans une solution unifiee gratuite. Son architecture modulaire (Manager, Agents, Indexer, Dashboard) permet des deployments allant du single node pour les PME aux clusters multi-noeuds pour les entreprises gerant des dizaines de milliers d'endpoints. La richesse de son systeme de regles et decoders, combinee aux CDB lists et aux integrations SOAR (TheHive, MISP, Shuffle), transforme Wazuh en une plateforme SOC complete capable de detection, enrichissement, investigation et reponse automatisee. Les capacites natives de FIM, SCA, detection de vulnerabilites et Active Response couvrent les besoins de securite endpoint sans necessiter d'outils additionnels pour les cas d'usage standards. Pour les organisations cherchant a renforcer leur posture de securite sans les couts prohibitifs des SIEM commerciaux, Wazuh offre un rapport fonctionnalites/cout imbattable, a condition d'investir dans les competences internes necessaires pour la personnalisation des regles, le tuning des performances, et la maintenance operationnelle de la plateforme.

Besoin d'accompagnement pour déployer ou optimiser Wazuh ?

Ayi NEDJIMI, consultant expert en cybersécurité et SOC, propose des missions d'architecture, déploiement et optimisation de plateformes Wazuh, incluant la création de règles personnalisées, l'intégration SOAR, et la formation des équipes SOC. Construisez un SIEM performant adapté à vos besoins.

Demander un devis

Partager cet article

Twitter LinkedIn

Télécharger cet article en PDF

Format A4 optimisé pour l'impression et la lecture hors ligne

Télécharger le PDF

À propos de l'auteur

Ayi NEDJIMI

Auditeur Senior Cybersécurité & Consultant IA

Expert Judiciaire — Cour d'Appel de Paris
Habilitation Confidentiel Défense

ayi@ayinedjimi-consultants.fr

25+

ans d'expérience

700+

articles publiés

100+

missions réalisées

Ayi NEDJIMI est un vétéran de la cybersécurité avec plus de 25 ans d'expérience sur des missions critiques. Ancien développeur Microsoft à Redmond sur le module GINA (Windows NT4) et co-auteur de la version française du guide de sécurité Windows NT4 pour la NSA.

À la tête d'Ayi NEDJIMI Consultants, il réalise des audits Lead Auditor ISO 42001 et ISO 27001, des pentests d'infrastructures critiques, du forensics et des missions de conformité NIS2 / AI Act.

Conférencier international (Europe & US), il a formé plus de 10 000 professionnels.

Domaines d'expertise

ISO 42001 Lead Auditor ISO 27001 · NIS2 Pentest & Forensics IA / LLM / RAG Cloud & Active Directory

Voir le profil complet Demander un devis

Ressources & Outils de l'auteur

GitHub

Code & projets open source

Hugging Face

Modèles IA & datasets

CertifExpress

Préparez vos certifications IT

WindowsBooster

Optimisation Windows 11

Commentaires

Aucun commentaire pour le moment. Soyez le premier à commenter !

Laisser un commentaire