[{"data":1,"prerenderedAt":148},["ShallowReactive",2],{"seo-verification":3,"blog-wazuh-siem-self-hosted-vps-fr":6},{"google":4,"bing":5},"EycwPY2XMyTkVzas3n1ygeNJFGAH513qrMjfDljzsMQ","",{"key":7,"data":8},"blog-wazuh-siem-self-hosted-vps-fr",{"id":9,"slug":10,"slugs":11,"title":15,"excerpt":16,"readTime":17,"views":18,"isPinned":19,"publishedAt":20,"updatedAt":21,"category":22,"categories":28,"featuredImage":30,"bgImage":31,"posterImage":32,"relatedSolution":30,"intro":33,"sections":34,"ctaTitle":91,"ctaBody":92,"ctaButton":93,"ctaUrl":94,"relatedPosts":95},404,"wazuh-siem-self-hosted-vps",{"fr":10,"en":12,"ar":13,"es":14},"wazuh-siem-vps-self-hosting","wazuh-siem-استضافة-ذاتية-vps","wazuh-siem-autoalojado-vps","Wazuh SIEM open source sur VPS : surveillance et conformité","Déployez Wazuh SIEM open source sur VPS Linux pour centraliser vos logs, détecter les intrusions et automatiser la conformité PCI-DSS, HIPAA et GDPR.",10,0,false,"2026-10-02T00:00:00+00:00","2026-10-02T14:03:20+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},8,"Sécurité & Monitoring","securite-monitoring","bg-rose-500\u002F10 text-rose-400","security",[29],{"id":23,"name":24,"slug":25,"color":26,"icon":27},null,"\u002Fblog\u002Fcovers\u002Fbg.svg","\u002Fblog\u002Fcovers\u002Fwazuh-siem-self-hosted-vps-poster.svg","Vous multipliez les serveurs auto-hébergés — n8n, Nextcloud, bases de données — et vous n'avez aucune vue unifiée sur ce qui s'y passe. Wazuh est un SIEM\u002FXDR open source qui corrèle vos événements de sécurité en temps réel, sans envoyer vos logs à un tiers et sans abonnement cloud. Voici comment le déployer sur un VPS Linux en mode single-node, avec Docker Compose.",[35,39,50,53,78,81,85,88],{"type":36,"title":37,"body":38},"h2","Pourquoi déployer Wazuh sur votre VPS","Un serveur Linux expose continuellement des signaux de sécurité : tentatives de connexion SSH, modifications de fichiers système, escalades de privilèges, processus inhabituels. Ces événements vivent dans des logs épars — `\u002Fvar\u002Flog\u002Fauth.log`, les journaux de vos conteneurs, les logs applicatifs — que personne ne corrèle. Un SIEM (Security Information and Event Management) est précisément l'outil qui centralise ces flux, les analyse et fait remonter les incidents.\n\nWazuh est aujourd'hui la référence open source dans ce domaine. Son architecture repose sur un **manager** (cerveau de la détection) qui reçoit les données d'**agents** légers installés sur chacun de vos serveurs. Le manager embarque un moteur de corrélation de règles, un module d'intégrité de fichiers (FIM), un module de détection de vulnérabilités et des tableaux de bord de conformité réglementaire prêts à l'emploi.\n\nContrairement à Datadog SIEM ou Elastic SIEM en mode cloud, Wazuh ne vous facture pas à l'ingestion et vos données restent dans votre infrastructure. C'est l'approche à privilégier dès que vous gérez plusieurs serveurs et que vous devez justifier votre posture de sécurité — pour un audit, pour un client, ou simplement pour savoir ce qui se passe réellement.",{"type":40,"title":41,"items":42},"ul","Ce que Wazuh apporte concrètement sur votre infrastructure",[43,44,45,46,47,48,49],"Centralisation des logs de tous vos serveurs Linux sur un seul tableau de bord : plus de connexion SSH de machine en machine pour lire `auth.log`.","Détection d'intrusion basée sur les règles : tentatives de brute-force, escalades de privilèges, modifications de fichiers critiques — avec corrélation multi-sources.","File Integrity Monitoring (FIM) en temps réel : toute modification de `\u002Fetc\u002Fpasswd`, `\u002Fetc\u002Fsudoers` ou de vos binaires système déclenche une alerte immédiate.","Règles de conformité PCI-DSS, HIPAA, GDPR et NIST SP 800-53 intégrées dans le jeu de règles par défaut — chaque alerte est automatiquement taggée avec les contrôles réglementaires qu'elle touche.","Détection de vulnérabilités active : Wazuh interroge les bases CVE et identifie les paquets installés exposés à des CVE connues.","Complémentarité avec CrowdSec et Fail2ban : Wazuh corrèle et archive pour la conformité, CrowdSec agit au périmètre — les deux outils se renforcent sans se dupliquer.","Aucun coût d'ingestion : vous gardez l'historique aussi longtemps que votre disque le permet.",{"type":36,"title":51,"body":52},"Prérequis chiffrés avant de commencer","Le déploiement single-node Wazuh (manager + indexer + dashboard dans trois conteneurs Docker) est plus gourmand qu'un simple agent de monitoring. Voici les minima réalistes pour un usage de production.\n\n**Pour le manager (nœud central) :**\n- **4 vCPU** minimum, 8 vCPU recommandés pour un parc de 10 serveurs ou plus.\n- **8 Go de RAM** minimum pour le nœud single-node (manager + indexer + dashboard). Comptez 16 Go si vous indexez un volume élevé d'événements ou si vous gérez plus de 50 agents.\n- **50 Go de disque SSD** minimum ; 100 Go ou plus si vous conservez un historique de 90 jours sur plusieurs serveurs.\n- Ubuntu 22.04 LTS ou Debian 12, à jour.\n- Docker Engine 24.0+ et Docker Compose v2 installés.\n- Un nom de domaine pour exposer le dashboard Wazuh en HTTPS via un reverse proxy.\n\n**Pour chaque agent (sur vos autres serveurs) :**\n- L'agent Wazuh est très léger : moins de 64 Mo de RAM et moins de 1 % de CPU en régime normal.\n- Compatible Linux (Debian, Ubuntu, AlmaLinux, Rocky), Windows et macOS.\n\n**Ports réseau à ouvrir sur le manager :**\n- `1514\u002FUDP` et `1514\u002FTCP` : communication agent → manager.\n- `1515\u002FTCP` : enregistrement des agents.\n- `55000\u002FTCP` : API REST Wazuh (accès local uniquement, ne pas exposer publiquement).\n- `9200\u002FTCP` et `9300\u002FTCP` : Wazuh Indexer (usage interne entre conteneurs).\n- `443\u002FTCP` : Wazuh Dashboard via votre reverse proxy.",{"type":54,"title":55,"steps":56},"steps","Déployer Wazuh avec Docker Compose : procédure complète",[57,60,63,66,69,72,75],{"title":58,"body":59},"Préparer le serveur et installer Docker","Mettez à jour le système, puis installez Docker Engine et Docker Compose v2 via le dépôt officiel Docker :\n\n```bash\napt-get update && apt-get upgrade -y\ncurl -fsSL https:\u002F\u002Fget.docker.com | sh\ndocker --version && docker compose version\n```\n\nVérifiez que Docker Compose v2 répond bien (commande `docker compose`, sans tiret). Activez Docker au démarrage : `systemctl enable --now docker`.",{"title":61,"body":62},"Cloner le dépôt officiel Wazuh Docker","Wazuh publie ses fichiers Docker Compose officiels dans le dépôt `wazuh\u002Fwazuh-docker`. Clonez la branche correspondant à la version stable courante (v4.14.x au moment de cet article) :\n\n```bash\ngit clone https:\u002F\u002Fgithub.com\u002Fwazuh\u002Fwazuh-docker.git -b v4.14.8 --depth 1\ncd wazuh-docker\u002Fsingle-node\n```\n\nLe dossier `single-node` contient le `docker-compose.yml` précâblé avec les trois services : `wazuh.manager`, `wazuh.indexer` et `wazuh.dashboard`.",{"title":64,"body":65},"Générer les certificats TLS inter-composants","Wazuh exige des certificats TLS pour la communication entre le manager, l'indexer et le dashboard. Le dépôt fournit un fichier Compose dédié à leur génération :\n\n```bash\ndocker compose -f generate-indexer-certs.yml run --rm generator\n```\n\nLes certificats sont écrits dans `config\u002Fwazuh_indexer_ssl_certs\u002F`. Cette étape est requise une seule fois ; en cas de renouvellement, relancez la commande puis redémarrez le stack.",{"title":67,"body":68},"Démarrer le stack Wazuh","Lancez les trois conteneurs en arrière-plan :\n\n```bash\ndocker compose up -d\n```\n\nLe premier démarrage télécharge les images officielles (environ 2 Go au total) et initialise l'indexer. Attendez 60 à 90 secondes, puis vérifiez que les trois services sont `healthy` :\n\n```bash\ndocker compose ps\n```\n\nSi `wazuh.indexer` reste en `starting` au-delà de 3 minutes, consultez ses logs : `docker compose logs wazuh.indexer | tail -50`.",{"title":70,"body":71},"Changer le mot de passe par défaut du dashboard","L'identifiant par défaut du dashboard Wazuh est `admin` \u002F `SecretPassword`. Changez-le immédiatement via l'API de l'indexer OpenSearch :\n\n```bash\ndocker compose exec wazuh.indexer curl -sk -X PUT \\\n  https:\u002F\u002Flocalhost:9200\u002F_plugins\u002F_security\u002Fapi\u002Faccount \\\n  -u admin:SecretPassword \\\n  -H 'Content-Type: application\u002Fjson' \\\n  -d '{\"password\": \"VotreNouveauMotDePasse\", \"current_password\": \"SecretPassword\"}'\n```\n\nPuis mettez à jour la variable `DASHBOARD_PASSWORD` dans `docker-compose.yml` et relancez `docker compose up -d` pour que le dashboard utilise le nouveau mot de passe.",{"title":73,"body":74},"Exposer le dashboard via un reverse proxy HTTPS","Ne pas exposer le dashboard directement sur le port 443 sans reverse proxy. Avec nginx, créez un vhost qui proxifie vers `https:\u002F\u002F127.0.0.1:5601` (le port interne du dashboard) en désactivant la vérification du certificat auto-signé côté upstream :\n\n```nginx\nserver {\n  listen 443 ssl;\n  server_name wazuh.votre-domaine.com;\n  location \u002F {\n    proxy_pass https:\u002F\u002F127.0.0.1:5601;\n    proxy_ssl_verify off;\n  }\n}\n```\n\nRenouvelez votre certificat Let's Encrypt avec Certbot (`certbot --nginx -d wazuh.votre-domaine.com`). N'exposez **pas** les ports 9200, 55000 ou 1514\u002F1515 publiquement — seul le port 1514-1515 doit être ouvert pour les agents, et uniquement en provenance de vos propres serveurs.",{"title":76,"body":77},"Installer et enregistrer un agent sur un serveur distant","Sur chaque serveur Linux que vous souhaitez surveiller, installez l'agent Wazuh en pointant vers l'IP ou le nom DNS de votre manager. Sur Ubuntu\u002FDebian :\n\n```bash\ncurl -s https:\u002F\u002Fpackages.wazuh.com\u002Fkey\u002FGPG-KEY-WAZUH | gpg --no-default-keyring \\\n  --keyring gnupg-ring:\u002Fusr\u002Fshare\u002Fkeyrings\u002Fwazuh.gpg --import && \\\n  chmod 644 \u002Fusr\u002Fshare\u002Fkeyrings\u002Fwazuh.gpg\necho \"deb [signed-by=\u002Fusr\u002Fshare\u002Fkeyrings\u002Fwazuh.gpg] https:\u002F\u002Fpackages.wazuh.com\u002F4.x\u002Fapt\u002F stable main\" | \\\n  tee \u002Fetc\u002Fapt\u002Fsources.list.d\u002Fwazuh.list\napt-get update && apt-get install -y wazuh-agent\n```\n\nConfigurez l'adresse du manager dans `\u002Fvar\u002Fossec\u002Fetc\u002Fossec.conf` (balise `\u003Caddress>`), puis démarrez et activez l'agent :\n\n```bash\nsystemctl daemon-reload\nsystemctl enable wazuh-agent\nsystemctl start wazuh-agent\n```\n\nL'agent apparaît dans le dashboard sous **Agents** dans les 30 secondes qui suivent.",{"type":36,"title":79,"body":80},"Configuration post-installation : agents, règles et dashboards de conformité","Une fois le stack opérationnel et vos premiers agents connectés, trois ajustements améliorent significativement la pertinence des alertes.\n\n**Activer la surveillance de l'intégrité des fichiers (FIM).** Dans la configuration de l'agent (`\u002Fvar\u002Fossec\u002Fetc\u002Fossec.conf`), ajoutez les répertoires sensibles dans la section `\u003Csyscheck>` :\n\n```xml\n\u003Csyscheck>\n  \u003Cfrequency>43200\u003C\u002Ffrequency>\n  \u003Cdirectories check_all=\"yes\">\u002Fetc,\u002Fusr\u002Fbin,\u002Fusr\u002Fsbin\u003C\u002Fdirectories>\n  \u003Cdirectories check_all=\"yes\">\u002Fvar\u002Fwww\u003C\u002Fdirectories>\n\u003C\u002Fsyscheck>\n```\n\nChaque modification dans ces répertoires déclenche une alerte de niveau 7 ou plus.\n\n**Explorer les dashboards de conformité.** Dans le dashboard Wazuh, la section **Modules** expose des vues précâblées pour PCI-DSS, HIPAA, GDPR et NIST SP 800-53. Chaque alerte hérite automatiquement des tags réglementaires définis dans les règles XML du manager — par exemple, une tentative d'élévation de privilèges tague simultanément PCI-DSS 10.2.5 et HIPAA 164.312(b).\n\n**Personnaliser le niveau d'alerte.** Le seuil d'alerte par défaut est 3. Pour ne recevoir que les alertes significatives, éditez `\u002Fvar\u002Fossec\u002Fetc\u002Fossec.conf` sur le manager et remontez le seuil à 7 dans la section `\u003Calerts>` :\n\n```xml\n\u003Calerts>\n  \u003Clog_alert_level>7\u003C\u002Flog_alert_level>\n  \u003Cemail_alert_level>9\u003C\u002Femail_alert_level>\n\u003C\u002Falerts>\n```\n\nRelancez le manager après toute modification : `docker compose restart wazuh.manager`.",{"type":82,"title":83,"body":84},"tip","Durcissement du déploiement","Quelques réglages réduisent la surface d'attaque du manager lui-même.\n\n**Isolez le manager sur son propre VPS** ou, au minimum, derrière un pare-feu qui n'ouvre les ports 1514-1515 qu'aux IP de vos agents — jamais à `0.0.0.0`. Sur un VPS ServOrbit, l'option **administration VPS** vous donne accès à `ufw` préconfigurée : `ufw allow from \u003CIP_AGENT> to any port 1514 proto tcp`.\n\n**Activez l'authentification mutuelle TLS** entre agents et manager en générant des certificats d'agent signés par votre CA interne plutôt qu'en utilisant l'enregistrement automatique (`ossec-authd`). La documentation officielle Wazuh détaille la procédure sous « Agent enrollment via the Wazuh manager API ».\n\n**Chiffrez les volumes Docker** qui contiennent l'index OpenSearch et les configurations — en particulier si vous hébergez le manager sur un VPS partagé. Un dump de l'indexer contient l'intégralité de vos logs de sécurité.\n\n**Surveillez le manager lui-même** : installez un agent Wazuh sur le VPS qui fait tourner le manager pour détecter toute modification des images Docker ou des fichiers de configuration.",{"type":36,"title":86,"body":87},"Dépannage : les erreurs courantes","Voici les cinq problèmes les plus fréquents lors d'un déploiement Wazuh Docker, avec les messages exacts et les corrections.\n\n**1. `max virtual memory areas vm.max_map_count [65530] is too low`**\nL'indexer OpenSearch exige au moins 262144. Ajoutez cette ligne dans `\u002Fetc\u002Fsysctl.conf` sur le **hôte** (pas dans le conteneur) : `vm.max_map_count=262144`, puis appliquez avec `sysctl -p`. C'est l'erreur la plus fréquente sur un VPS vierge.\n\n**2. `wazuh.indexer` reste en état `starting` indéfiniment**\nVérifiez d'abord les logs (`docker compose logs wazuh.indexer`). Si vous voyez `bootstrap checks failed`, c'est presque toujours `vm.max_map_count` (voir ci-dessus) ou un manque de RAM. Si vous voyez `certificate not found`, les certificats n'ont pas été générés correctement — relancez `docker compose -f generate-indexer-certs.yml run --rm generator`.\n\n**3. L'agent apparaît `Disconnected` dans le dashboard**\nVérifiez que le port 1514 est ouvert en entrée sur le manager et que l'adresse du manager est correctement renseignée dans `\u002Fvar\u002Fossec\u002Fetc\u002Fossec.conf` de l'agent. Testez la connectivité depuis l'agent : `nc -zv \u003CIP_MANAGER> 1514`. Si la connexion échoue, vérifiez votre pare-feu (`ufw status`, règles CSF).\n\n**4. `ERROR: [agent_auth] Unable to create ssl context`**\nL'agent ne peut pas valider le certificat TLS du manager. Vérifiez que le fichier `ossec.cfg` de l'agent pointe bien sur l'adresse DNS et non l'IP brute si vous utilisez un certificat nommé. Alternativement, désactivez la vérification de certificat côté agent en phase de test : balise `\u003Cverify_host>no\u003C\u002Fverify_host>` dans la configuration d'enregistrement (à **ne pas laisser en production**).\n\n**5. `Too many open files` dans les logs du manager**\nAugmentez les limites `nofile` sur l'hôte. Dans `\u002Fetc\u002Fsecurity\u002Flimits.conf` : `* soft nofile 65536` et `* hard nofile 65536`. Dans le `docker-compose.yml`, ajoutez `ulimits: nofile: soft: 65536 hard: 65536` au service `wazuh.manager`, puis relancez.",{"type":36,"title":89,"body":90},"Wazuh dans votre stack de sécurité","Wazuh n'est pas un outil isolé : il est le plus efficace quand il s'intègre à ce que vous avez déjà déployé. Associé à **CrowdSec** (qui bannit les IPs au niveau réseau), il couvre à la fois le périmètre et la profondeur système. Associé à **Fail2ban**, il lui apporte la corrélation et l'archivage réglementaire que Fail2ban ne peut pas produire seul. Et si vous avez déjà une stack **Grafana + Prometheus**, Wazuh complète l'observabilité système par une couche de sécurité : Prometheus vous dit que le CPU est à 90 %, Wazuh vous dit pourquoi — et si c'est une tentative de cryptominage.\n\nLe hardening de votre serveur (\u003Ca href=\"\u002Fblog\u002Flinux-hardening-vps-checklist\">checklist de durcissement Linux sur VPS\u003C\u002Fa>) définit une posture statique. Wazuh est la surveillance continue qui vérifie que cette posture tient dans le temps — que personne n'a modifié `\u002Fetc\u002Fsudoers`, que vos binaires système n'ont pas été remplacés, que les événements d'authentification restent dans les plages normales.\n\nPour héberger votre manager Wazuh sur une infrastructure dont vous contrôlez le niveau de sécurité, consultez \u003Ca href=\"\u002Fpourquoi\u002Fsecurite\">comment ServOrbit structure la sécurité de son infrastructure\u003C\u002Fa> et choisissez le VPS adapté à votre parc d'agents.","Votre infrastructure sous surveillance","Un VPS avec accès root, choix d'OS et IPv4 dédiée — ce qu'il faut pour faire tourner votre manager Wazuh sans contrainte.","Sécuriser mon infrastructure","\u002Fpourquoi\u002Fsecurite",[96,116,131],{"id":97,"slug":98,"slugs":99,"title":103,"excerpt":104,"readTime":105,"views":106,"isPinned":19,"publishedAt":107,"updatedAt":108,"category":109,"categories":110,"featuredImage":30,"bgImage":31,"posterImage":112,"relatedSolution":113},108,"securiser-vps-crowdsec",{"fr":98,"en":100,"ar":101,"es":102},"securing-your-vps-with-crowdsec","تأمين-خادمك-الافتراضي-vps-باستخدام-crowdsec","proteger-vps-con-crowdsec","Sécuriser votre VPS avec CrowdSec","Déployez CrowdSec sur votre VPS pour bloquer les attaques grâce à une détection comportementale et une blocklist communautaire mutualisée.",4,1,"2026-03-04T00:00:00+00:00","2026-09-07T11:26:10+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[111],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fsecuriser-vps-crowdsec-poster.svg",{"categorySlug":114,"appSlug":115},"cybersecurity","crowdsec",{"id":117,"slug":118,"slugs":119,"title":123,"excerpt":124,"readTime":125,"views":106,"isPinned":19,"publishedAt":126,"updatedAt":108,"category":127,"categories":128,"featuredImage":30,"bgImage":31,"posterImage":130,"relatedSolution":30},317,"linux-hardening-vps-checklist",{"fr":118,"en":120,"ar":121,"es":122},"linux-vps-hardening-checklist-for-agencies","قائمة-تصليب-خادم-لينكس-للوكالات-بعد-التسليم","hardening-linux-vps-checklist-para-agencias-tras-la-entrega","Durcissement Linux VPS : checklist agence après livraison","Checklist de durcissement Linux pour agences : auditd, sudo, SSH par clé, UFW, fail2ban et désactivation root — traçabilité et runbook par client.",11,"2026-08-30T00:00:00+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[129],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Flinux-hardening-vps-checklist-poster.svg",{"id":132,"slug":133,"slugs":134,"title":138,"excerpt":139,"readTime":105,"views":18,"isPinned":19,"publishedAt":140,"updatedAt":108,"category":141,"categories":142,"featuredImage":30,"bgImage":31,"posterImage":144,"relatedSolution":145},106,"monitoring-vps-grafana-prometheus",{"fr":133,"en":135,"ar":136,"es":137},"vps-monitoring-with-grafana-and-prometheus","مراقبة-الخادم-الافتراضي-vps-باستخدام-grafana-و-prometheus","monitorizacion-vps-grafana-prometheus","Monitoring de VPS avec Grafana et Prometheus","Montez une stack Grafana + Prometheus sur votre VPS pour collecter, stocker et visualiser vos métriques système et applicatives.","2026-03-06T00:00:00+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[143],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fmonitoring-vps-grafana-prometheus-poster.svg",{"categorySlug":146,"appSlug":147},"monitoring","grafana",1790987739402]