WAZUH SIEM/XDR - Guide de Déploiement Complet en PME
Guide complet de déploiement Wazuh 4.9 en PME sur Proxmox VE 8.x avec réseau, firewall, VM, Kubernetes et checklist opérationnelle.
AP
Admin Pocax
24 février 2026
9 min
1. Introduction et Architecture Générale
Wazuh est une plateforme SIEM/XDR (Security Information & Event Management / Extended Detection and Response) open-source qui centralise la collecte, l'analyse et la corrélation des événements de sécurité de toute votre infrastructure.
1.1 Pourquoi Wazuh pour une PME ?
- Solution open-source avec support commercial disponible
- Gestion centralisée des alertes et logs de toute l'infrastructure
- Détection des intrusions (IDS/HIDS), analyse de vulnérabilités, conformité (PCI-DSS, HIPAA, GDPR)
- Intégration native avec Kubernetes, hyperviseurs, firewalls
- Interface web moderne (Wazuh Dashboard basé sur OpenSearch)
1.2 Architecture cible PME
L'architecture déployée dans ce guide couvre les couches suivantes :
| Composant | Technologie | Rôle |
|---|---|---|
| Hyperviseur | Proxmox VE 8.x | Hébergement des VM et conteneurs |
| Réseau | Switch manageable (VLAN) | Segmentation réseau par zones |
| Firewall | pfSense / OPNsense | Filtrage, IDS Suricata, collecte logs |
| Serveurs | VM Linux/Windows | Agents Wazuh installés |
| Orchestration | Kubernetes (K3s) | Surveillance des pods et nœuds |
| SIEM | Wazuh Manager + Dashboard | Analyse centrale et visualisation |
1.3 Schéma réseau recommandé
La segmentation en VLANs est essentielle pour isoler les zones et limiter la propagation d'incidents : Internet
| [Firewall pfSense/OPNsense] ← Collecte logs vers Wazuh | [Switch manageable — VLANs] | ┌───────────────────────────────────────────────────┐ │ VLAN 10 — Management (192.168.10.0/24) │ │ ├── Proxmox VE (192.168.10.1) │ │ └── Wazuh Server (192.168.10.20) │ │ VLAN 20 — Serveurs (192.168.20.0/24) │ │ ├── VM Linux Server (agent Wazuh) │ │ └── VM Windows Server (agent Wazuh) │ │ VLAN 30 — Kubernetes (192.168.30.0/24) │ │ ├── K3s Master (192.168.30.10) │ │ └── K3s Workers (192.168.30.11-13) │ │ VLAN 40 — Utilisateurs (192.168.40.0/24) │ └───────────────────────────────────────────────────┘
2. Prérequis et Dimensionnement
2.1 Dimensionnement matériel recommandé
| VM/Nœud | CPU | RAM | Stockage | Note |
|---|---|---|---|---|
| Wazuh Manager | 4 vCPU | 8 Go RAM | 100 Go SSD | Nœud central |
| Wazuh Indexer | 4 vCPU | 8 Go RAM | 500 Go SSD | Stockage logs (OpenSearch) |
| Wazuh Dashboard | 2 vCPU | 4 Go RAM | 20 Go SSD | Interface web |
| Proxmox VE | 8+ cœurs physiques | 32 Go+ RAM | SSD NVMe | Hôte hyperviseur |
| K3s Master | 2 vCPU | 4 Go RAM | 40 Go | Orchestrateur K8s |
| K3s Workers (x2+) | 4 vCPU | 8 Go RAM | 80 Go | Exécution workloads |
ℹ Pour moins de 50 endpoints, vous pouvez combiner Manager + Indexer + Dashboard sur une seule VM avec 16 Go RAM et 8 vCPU.
2.2 Ports réseau à ouvrir
| Port | Direction | Usage |
|---|---|---|
| 1514 TCP/UDP | Agents → Manager | Communication agents Wazuh |
| 1515 TCP | Agents → Manager | Enregistrement agents |
| 443 HTTPS | Admin → Dashboard | Interface web Wazuh |
| 9200 TCP | Manager → Indexer | API OpenSearch |
| 9300 TCP | Indexer cluster | Communication cluster |
| 514 UDP/TCP | Firewall → Manager | Syslog distant |
3. Préparation de Proxmox VE
3.1 Configuration initiale Proxmox
Après installation de Proxmox VE 8.x, effectuez les opérations suivantes :
3.1.1 Mise à jour du système
# Désactiver le dépôt enterprise si pas d'abonnement sed -i 's/^deb/# deb/' /etc/apt/sources.list.d/pve-enterprise.list # Ajouter le dépôt no-subscription echo 'deb http://download.proxmox.com/debian/pve bookworm pve-no-subscription' \ >> /etc/apt/sources.list apt update && apt full-upgrade -y
3.1.2 Configuration des VLANs sur Proxmox
Dans l'interface Proxmox (Datacenter > Nœud > Network), créez les interfaces réseau :
# Dans /etc/network/interfaces — exemple avec VLAN aware bridge auto lo iface lo inet loopback # Interface physique iface eno1 inet manual # Bridge principal avec VLAN aware auto vmbr0 iface vmbr0 inet static address 192.168.10.1/24 gateway 192.168.10.254 bridge-ports eno1 bridge-stp off bridge-fd 0 bridge-vlan-aware yes bridge-vids 10 20 30 40
3.2 Création de la VM Wazuh Server
- Dans Proxmox, cliquer sur
Create VM. - Configurer :
OS=Ubuntu 22.04 LTS,CPU=4 vCPU,RAM=8192 Mo,Disk=100 Go SSD. - Réseau :
Bridge vmbr0,Tag VLAN=10. - Démarrer la VM et noter l'adresse IP (ex:
192.168.10.20).
✔ Activez l'option QEMU Guest Agent dans les options de VM et installez qemu-guest-agent dans Ubuntu pour bénéficier des snapshots cohérents.
4. Installation de Wazuh
4.1 Installation all-in-one (Manager + Indexer + Dashboard)
Cette méthode déploie les 3 composants sur une seule VM. Recommandée pour PME < 100 endpoints.
4.1.1 Téléchargement et lancement du script d'installation
# Sur la VM Wazuh (Ubuntu 22.04) apt update && apt install -y curl # Télécharger l'assistant d'installation Wazuh curl -sO https://packages.wazuh.com/4.9/wazuh-install.sh curl -sO https://packages.wazuh.com/4.9/config.yml
4.1.2 Configuration de config.yml
# Éditer config.yml nodes: # Wazuh indexer nodes indexer: - name: node-1 ip: 192.168.10.20 # Wazuh server nodes server: - name: wazuh-1 ip: 192.168.10.20 # Wazuh dashboard node dashboard: - name: dashboard ip: 192.168.10.20
4.1.3 Génération des certificats et installation
# Générer les certificats bash wazuh-install.sh --generate-config-files # Installer le nœud indexer bash wazuh-install.sh --wazuh-indexer node-1 # Initialiser le cluster bash wazuh-install.sh --start-cluster # Installer le serveur Wazuh bash wazuh-install.sh --wazuh-server wazuh-1 # Installer le dashboard bash wazuh-install.sh --wazuh-dashboard dashboard ⚠ À la fin de l'installation, notez les identifiants affichés : User: admin, Password: <généré automatiquement>. Stockez-les dans un gestionnaire de mots de passe.
4.2 Installation distribuée (production)
Pour les environnements plus importants (>100 endpoints), déployez chaque composant sur une VM dédiée. La procédure est identique mais avec les IPs distinctes de chaque VM dans config.yml.
4.3 Accès au Dashboard
URL : https://192.168.10.20 (ou FQDN configuré) Identifiants : admin / <mot de passe généré> Changez le mot de passe admin à la première connexion
5. Déploiement des Agents Wazuh
5.1 Agent Linux (Debian/Ubuntu)
# Ajouter le dépôt Wazuh curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | gpg --dearmor \ -o /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 # Installer l'agent avec l'adresse du manager WAZUH_MANAGER='192.168.10.20' \ WAZUH_AGENT_GROUP='linux-servers' \ apt install -y wazuh-agent # Démarrer et activer l'agent systemctl daemon-reload systemctl enable wazuh-agent systemctl start wazuh-agent
5.2 Agent Linux (RHEL/CentOS/Rocky)
# Ajouter le dépôt RPM rpm --import https://packages.wazuh.com/key/GPG-KEY-WAZUH cat > /etc/yum.repos.d/wazuh.repo << EOF [wazuh] gpgcheck=1 gpgkey=https://packages.wazuh.com/key/GPG-KEY-WAZUH enabled=1 name=EL-\$releasever - Wazuh baseurl=https://packages.wazuh.com/4.x/yum/ protect=1 EOF WAZUH_MANAGER='192.168.10.20' yum install -y wazuh-agent systemctl enable --now wazuh-agent
5.3 Agent Windows
Téléchargez l'installeur MSI depuis le Dashboard Wazuh ou via PowerShell :
# PowerShell (exécuter en tant qu'administrateur) Invoke-WebRequest -Uri 'https://packages.wazuh.com/4.x/windows/wazuh-agent-4.9.0-1.msi' \ -OutFile 'wazuh-agent.msi' # Installation silencieuse msiexec.exe /i wazuh-agent.msi /q ` WAZUH_MANAGER='192.168.10.20' ` WAZUH_AGENT_GROUP='windows-servers' ` /l*v 'wazuh-install.log' # Démarrer le service NET START WazuhSvc
5.4 Déploiement en masse avec Ansible
Pour déployer des agents sur de nombreuses machines, utilisez Ansible :
# Installer le rôle Wazuh pour Ansible ansible-galaxy install wazuh.wazuh_agents # playbook-wazuh-agents.yml --- - hosts: all roles: - role: wazuh.wazuh_agents vars: wazuh_managers: - address: 192.168.10.20 port: 1514 protocol: tcp wazuh_agent_authd: enable: true server_hostname: 192.168.10.20 # Exécution ansible-playbook -i inventory.yml playbook-wazuh-agents.yml
6. Surveillance de Proxmox
6.1 Collecte des logs Proxmox
Installez l'agent Wazuh directement sur l'hôte Proxmox (Debian 12) :
# Sur le nœud Proxmox curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | gpg --dearmor \ -o /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 WAZUH_MANAGER='192.168.10.20' \ WAZUH_AGENT_GROUP='hypervisors' \ apt install -y wazuh-agent systemctl enable --now wazuh-agent
6.2 Configuration des logs Proxmox dans ossec.conf
Ajoutez ces sections dans /var/ossec/etc/ossec.conf sur l'agent Proxmox :
<ossec_config> <!-- Logs authentification Proxmox --> <localfile> <log_format>syslog</log_format> <location>/var/log/pve/tasks/index</location> </localfile> <!-- Logs système --> <localfile> <log_format>syslog</log_format> <location>/var/log/syslog</location> </localfile> <!-- Audit des VMs --> <localfile> <log_format>syslog</log_format> <location>/var/log/pve-firewall.log</location> </localfile> </ossec_config>
6.3 Surveillance via API Proxmox
Créez un script de collecte via l'API REST Proxmox pour surveiller les VMs, conteneurs et ressources : #!/usr/bin/env python3
# /usr/local/bin/proxmox-wazuh-monitor.py import requests, json, urllib3 urllib3.disable_warnings() PROXMOX_URL = 'https://192.168.10.1:8006' USER = 'monitoring@pve' PASSWORD = 'votre_mot_de_passe' def get_token(): r = requests.post(f'{PROXMOX_URL}/api2/json/access/ticket', data={'username': USER, 'password': PASSWORD}, verify=False) return r.json()['data'] def check_vms(token): cookies = {'PVEAuthCookie': token['ticket']} headers = {'CSRFPreventionToken': token['CSRFPreventionToken']} r = requests.get(f'{PROXMOX_URL}/api2/json/cluster/resources?type=vm', cookies=cookies, headers=headers, verify=False) for vm in r.json()['data']: if vm.get('status') != 'running': print(json.dumps({'wazuh_alert': 'vm_stopped', 'vm_name': vm['name'], 'vmid': vm['vmid']})) token = get_token() check_vms(token) # Ajouter la collecte dans ossec.conf <localfile> <log_format>json</log_format> <command>python3 /usr/local/bin/proxmox-wazuh-monitor.py</command> <frequency>300</frequency> </localfile>
7. Surveillance Réseau — Switch et Flux
7.1 Collecte des logs SNMP du switch
Configurez votre switch manageable pour envoyer les logs via Syslog vers Wazuh :
7.1.1 Sur le switch (exemple Cisco/HP ProCurve)
! Configuration Cisco IOS logging host 192.168.10.20 logging trap informational logging source-interface Vlan10 ! Activer les logs d'authentification aaa accounting exec default start-stop group tacacs+ aaa accounting commands 15 default start-stop group tacacs+
7.1.2 Réception Syslog sur Wazuh Manager
Configurez Wazuh pour écouter les logs Syslog sur le port 514 :
# Dans /var/ossec/etc/ossec.conf (Manager) <ossec_config> <remote> <connection>syslog</connection> <port>514</port> <protocol>udp</protocol> <allowed-ips>192.168.0.0/16</allowed-ips> <local_ip>192.168.10.20</local_ip> </remote> </ossec_config> # Ouvrir le port firewall sur le Manager ufw allow 514/udp ufw allow 514/tcp
7.2 Surveillance du trafic réseau avec Suricata
Installez Suricata sur un nœud dédié ou le firewall pour l'analyse des flux réseau :
# Installation Suricata sur Ubuntu add-apt-repository ppa:oisf/suricata-stable apt update && apt install -y suricata # Télécharger les règles Emerging Threats suricata-update # Configurer l'interface dans /etc/suricata/suricata.yaml af-packet: - interface: eth0 cluster-id: 99 cluster-type: cluster_flow defrag: yes # Intégration Suricata → Wazuh (ossec.conf sur l'agent) <localfile> <log_format>json</log_format> <location>/var/log/suricata/eve.json</location> </localfile>
8. Intégration Firewall (pfSense/OPNsense)
8.1 Configuration de pfSense
8.1.1 Envoi des logs vers Wazuh
Dans pfSense : System > General Setup > Logging > Remote log servers
- IP Server :
192.168.10.20 - Port :
514 - Protocol :
UDP - Cocher :
Firewall Events,DHCP Events,Authentication Events,General Events
8.1.2 Intégration Suricata/Snort de pfSense
pfSense peut faire tourner Suricata nativement. Activez la remontée des alertes :
# Dans les options Suricata de pfSense # Services > Suricata > Global Settings # Cocher : Send Alerts to System Log # Log Level : Notice
8.2 Configuration d'OPNsense
# System > Settings > Logging > Remote # Ajouter un serveur Syslog distant : # Hostname: 192.168.10.20 # Port: 514 # Transport: UDP # Level: Notice # Facilities: All
8.3 Règles de décodage pfSense dans Wazuh
Wazuh inclut des décoders natifs pour pfSense/OPNsense. Vérifiez qu'ils sont actifs :
# Sur le Manager ls /var/ossec/ruleset/rules/ | grep -i pf # Vous devriez voir : 0100-pfsense_rules.xml # Tester le décodage d'un log pfSense /var/ossec/bin/wazuh-logtest # Collez un exemple de log pfSense pour vérifier le parsing
9. Surveillance Kubernetes (K3s)
9.1 Installation de K3s
# Sur le nœud master (192.168.30.10) curl -sfL https://get.k3s.io | sh - # Récupérer le token pour les workers cat /var/lib/rancher/k3s/server/node-token # Sur chaque nœud worker curl -sfL https://get.k3s.io | K3S_URL=https://192.168.30.10:6443 \ K3S_TOKEN=<TOKEN> sh - # Vérifier le cluster kubectl get nodes
9.2 Déploiement de l'agent Wazuh sur Kubernetes
Déployez l'agent Wazuh en tant que DaemonSet pour surveiller chaque nœud :
# wazuh-daemonset.yaml apiVersion: apps/v1 kind: DaemonSet metadata: name: wazuh-agent namespace: wazuh spec: selector: matchLabels: app: wazuh-agent template: metadata: labels: app: wazuh-agent spec: hostPID: true hostNetwork: true dnsPolicy: ClusterFirstWithHostNet containers: - name: wazuh-agent image: wazuh/wazuh-agent:4.9.0 env: - name: WAZUH_MANAGER value: '192.168.10.20' - name: WAZUH_AGENT_GROUP value: 'kubernetes' securityContext: privileged: true volumeMounts: - name: host-proc mountPath: /host/proc readOnly: true - name: host-sys mountPath: /host/sys readOnly: true - name: host-logs mountPath: /host/var/log readOnly: true volumes: - name: host-proc hostPath: path: /proc - name: host-sys hostPath: path: /sys - name: host-logs hostPath: path: /var/log # Créer le namespace et déployer kubectl create namespace wazuh kubectl apply -f wazuh-daemonset.yaml # Vérifier le déploiement kubectl get pods -n wazuh -o wide
9.3 Surveillance de l'API Kubernetes
Activez l'audit logging de Kubernetes pour capturer toutes les actions API :
# audit-policy.yaml apiVersion: audit.k8s.io/v1 kind: Policy rules: - level: RequestResponse resources: - group: '' resources: ['pods', 'secrets', 'configmaps'] - level: Metadata resources: - group: 'rbac.authorization.k8s.io' resources: ['*'] - level: None users: ['system:kube-proxy'] # Sur K3s : éditer /etc/systemd/system/k3s.service # Ajouter dans ExecStart : --kube-apiserver-arg=audit-log-path=/var/log/k3s-audit.log --kube-apiserver-arg=audit-policy-file=/etc/k3s/audit-policy.yaml --kube-apiserver-arg=audit-log-maxage=30 --kube-apiserver-arg=audit-log-maxbackup=3 # Intégrer les logs audit dans Wazuh (ossec.conf de l'agent K3s master) <localfile> <log_format>json</log_format> <location>/var/log/k3s-audit.log</location> </localfile>
9.4 Surveillance des images et vulnérabilités
ℹ Wazuh intègre un module de détection de vulnérabilités qui analyse les packages des agents. Pour Kubernetes, utilisez Trivy en complément pour scanner les images.
# Installer Trivy apt install -y trivy # Scanner une image trivy image nginx:latest --format json > /var/log/trivy-scan.json # Intégrer dans Wazuh <localfile> <log_format>json</log_format> <location>/var/log/trivy-scan.json</location> </localfile>
10. Configuration Avancée de Wazuh
10.1 Groupes d'agents et politiques différenciées
Organisez vos agents en groupes pour appliquer des configurations spécifiques :
# Sur le Manager — créer les groupes /var/ossec/bin/agent_groups -a -g linux-servers /var/ossec/bin/agent_groups -a -g windows-servers /var/ossec/bin/agent_groups -a -g hypervisors /var/ossec/bin/agent_groups -a -g kubernetes /var/ossec/bin/agent_groups -a -g firewalls # Affecter un agent à un groupe /var/ossec/bin/agent_groups -a -i <AGENT_ID> -g linux-servers # Configuration spécifique par groupe # Créer : /var/ossec/etc/shared/<groupe>/agent.conf
10.2 Détection de vulnérabilités
# Activer dans ossec.conf (Manager) <vulnerability-detection> <enabled>yes</enabled> <index-status>yes</index-status> <feed-update-interval>60m</feed-update-interval> </vulnerability-detection>
10.3 Intégration avec Active Directory (Windows)
# ossec.conf sur agents Windows (groupe windows-servers) <localfile> <log_format>eventchannel</log_format> <location>Security</location> </localfile> <localfile> <log_format>eventchannel</log_format> <location>System</location> </localfile> <localfile> <log_format>eventchannel</log_format> <location>Microsoft-Windows-Sysmon/Operational</location> </localfile>
10.4 Règles personnalisées
Créez des règles Wazuh adaptées à votre environnement :
# /var/ossec/etc/rules/local_rules.xml <group name='pme-custom,'> <!-- Alerte si une VM Proxmox est arrêtée --> <rule id='100001' level='10'> <field name='wazuh_alert'>vm_stopped</field> <description>VM Proxmox arrêtée : $(vm_name)</description> <group>proxmox,vm,availability,</group> </rule> <!-- Alerte connexion admin hors horaires --> <rule id='100002' level='12'> <if_sid>5501,5502</if_sid> <time>8 pm - 7 am</time> <description>Connexion admin hors horaires bureau</description> <group>after-hours,authentication,</group> </rule> <!-- Pod Kubernetes en crashloop --> <rule id='100010' level='9'> <match>CrashLoopBackOff</match> <description>Pod Kubernetes en CrashLoopBackOff</description> <group>kubernetes,availability,</group> </rule> </group>
11. Configuration des Alertes
11.1 Alertes par email
# Dans /var/ossec/etc/ossec.conf (Manager) <global> <email_notification>yes</email_notification> <email_from>wazuh@votre-domaine.fr</email_from> <email_to>soc@votre-domaine.fr</email_to> <smtp_server>smtp.votre-domaine.fr</smtp_server> <email_maxperhour>12</email_maxperhour> <email_alert_level>10</email_alert_level> </global>
11.2 Intégration Slack
# Dans ossec.conf — integration Slack <integration> <name>slack</name> <hook_url>https://hooks.slack.com/services/XXXXX/YYYYY/ZZZZZ</hook_url> <alert_level>10</alert_level> <group>authentication_failure,intrusion_detection,</group> </integration>
11.3 Réponse active
Configurez des réponses automatiques aux menaces détectées :
# Bloquer une IP après échecs d'authentification répétés <active-response> <command>firewall-drop</command> <location>local</location> <rules_id>5710,5711,5712</rules_id> <timeout>600</timeout> </active-response>
12. Conformité et Tableaux de Bord
12.1 Modules de conformité intégrés
Wazuh inclut des modules prêts à l'emploi pour les principales normes :
| Norme | Description | Statut |
|---|---|---|
| PCI-DSS | Sécurité des données de paiement | Activé par défaut |
| HIPAA | Données de santé (USA) | Activé par défaut |
| GDPR | Données personnelles (UE) | Activé par défaut |
| NIST 800-53 | Framework NIST | Activé par défaut |
| TSC SOC2 | Contrôles SOC 2 | Activé par défaut |
| CIS | CIS Benchmarks | Via module SCA |
12.2 Security Configuration Assessment (SCA)
Le SCA audite la configuration de sécurité de vos systèmes selon les CIS Benchmarks :
# Lister les politiques SCA disponibles ls /var/ossec/ruleset/sca/ # Politiques disponibles : # cis_debian10.yml, cis_ubuntu22-04.yml # cis_win2019.yml, cis_rhel8.yml, etc. # Activer dans ossec.conf des agents <sca> <enabled>yes</enabled> <scan_on_start>yes</scan_on_start> <interval>12h</interval> </sca>
13. Maintenance et Opérations
13.1 Gestion de la rétention des données
# Configurer la rétention OpenSearch # Dans le Dashboard : Stack Management > Index Management # Ou via API : curl -X PUT 'https://192.168.10.20:9200/_ilm/policy/wazuh-policy' \ -H 'Content-Type: application/json' \ -u admin:password \ --insecure \ -d '{ "policy": { "phases": { "hot": { "min_age": "0ms", "actions": { "rollover": { "max_size": "50gb" } } }, "delete": { "min_age": "90d", "actions": { "delete": {} } } } } }'
13.2 Sauvegarde de la configuration Wazuh
#!/bin/bash # /usr/local/bin/wazuh-backup.sh BACKUP_DIR='/opt/wazuh-backups' DATE=$(date +%Y%m%d-%H%M) mkdir -p $BACKUP_DIR # Sauvegarder la configuration tar -czf $BACKUP_DIR/wazuh-config-$DATE.tar.gz \ /var/ossec/etc/ \ /var/ossec/ruleset/rules/local_rules.xml \ /var/ossec/logs/ # Garder 30 jours find $BACKUP_DIR -name '*.tar.gz' -mtime +30 -delete echo 'Sauvegarde terminée : wazuh-config-$DATE.tar.gz' # Planifier en crontab 0 2 * * * /usr/local/bin/wazuh-backup.sh >> /var/log/wazuh-backup.log 2>&1
13.3 Mise à jour de Wazuh
# Mise à jour du Manager apt update && apt install -y wazuh-manager wazuh-indexer wazuh-dashboard # Mise à jour des agents Linux apt update && apt install -y wazuh-agent # Vérifier les versions /var/ossec/bin/wazuh-control info
13.4 Commandes de diagnostic
# Statut des services Wazuh systemctl status wazuh-manager wazuh-indexer wazuh-dashboard # Lister les agents connectés /var/ossec/bin/agent_control -l # Voir les alertes en temps réel tail -f /var/ossec/logs/alerts/alerts.json | python3 -m json.tool # Tester les règles et décoders /var/ossec/bin/wazuh-logtest # Vérifier la connectivité agent /var/ossec/bin/agent_control -i <AGENT_ID> # Santé du cluster OpenSearch curl -k -u admin:password https://localhost:9200/_cluster/health?pretty
14. Checklist de Déploiement
Infrastructure
- Proxmox VE installé et mis à jour
- VLANs configurés sur le switch (VLAN 10, 20, 30, 40)
- Règles firewall ouvertes pour les ports Wazuh (1514, 1515, 514)
- VM Wazuh créée avec les ressources recommandées
Installation Wazuh
- Wazuh Manager installé et démarré
- Wazuh Indexer (OpenSearch) opérationnel
- Wazuh Dashboard accessible via HTTPS
- Mot de passe admin changé
- Certificats SSL valides configurés
Agents
- Agent installé sur l'hôte Proxmox
- Agent installé sur chaque VM Linux
- Agent installé sur chaque VM Windows
- Agent déployé en DaemonSet sur Kubernetes
- Tous les agents visibles dans le Dashboard
Intégrations réseau
- Syslog reçu depuis pfSense/OPNsense
- Syslog reçu depuis le switch manageable
- Suricata intégré (si déployé)
- Logs d'audit Kubernetes collectés
Configuration sécurité
- SCA activé sur tous les groupes d'agents
- Détection de vulnérabilités activée
- Alertes email/Slack configurées
- Réponse active configurée
- Rétention des données configurée (90 jours minimum)
- Sauvegarde automatique planifiée
15. Troubleshooting
| Problème | Solution |
|---|---|
| Agent non connecté | Vérifier port 1514/1515 ouvert, cert valide, hostname manager correct dans ossec.conf |
| Logs non reçus | Vérifier ossec.conf localfile, chemin du log, permissions de lecture |
| Dashboard inaccessible | Vérifier service wazuh-dashboard, port 443, certificat SSL |
| OpenSearch surchargé | Augmenter heap JVM, vérifier disk space, optimiser rétention |
| Alertes manquantes | Vérifier niveau d'alerte (alert_level), tester avec wazuh-logtest |
| Faux positifs | Ajouter règle d'exclusion dans local_rules.xml avec <if_sid> et <same_source_ip> |
| K8s DaemonSet crashe | Vérifier privilèges (privileged: true), accès au socket Docker/containerd |
| Syslog firewall non parsé | Utiliser wazuh-logtest pour identifier le decoder manquant |
16. Ressources et Documentation
Liens utiles
- Documentation officielle : https://documentation.wazuh.com
- Dépôt GitHub Wazuh : https://github.com/wazuh/wazuh
- Règles communautaires : https://github.com/socfortress/Wazuh-Rules
- Proxmox documentation : https://pve.proxmox.com/pve-docs/
- K3s documentation : https://docs.k3s.io
Niveaux d'alerte Wazuh
| Niveau | Sévérité | Description |
|---|---|---|
| 0-3 | Faible | Informations système normales |
| 4-7 | Moyen | Événements de sécurité à surveiller |
| 8-11 | Élevé | Attaques potentielles, nécessite attention |
| 12-15 | Critique | Compromission confirmée, action immédiate |
⚠ Ce guide a été rédigé pour Wazuh 4.9 et Proxmox VE 8.x. Vérifiez la compatibilité avec les versions futures et adaptez les configurations à votre environnement spécifique.