[{"data":1,"prerenderedAt":148},["ShallowReactive",2],{"seo-verification":3,"blog-wazuh-siem-vps-self-hosting-en":6},{"google":4,"bing":5},"EycwPY2XMyTkVzas3n1ygeNJFGAH513qrMjfDljzsMQ","",{"key":7,"data":8},"blog-wazuh-siem-vps-self-hosting-en",{"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-vps-self-hosting",{"fr":12,"en":10,"ar":13,"es":14},"wazuh-siem-self-hosted-vps","wazuh-siem-استضافة-ذاتية-vps","wazuh-siem-autoalojado-vps","Wazuh Open Source SIEM on a VPS: Monitoring and Compliance","Deploy Wazuh open source SIEM on your Linux VPS to centralize logs, detect intrusions and automate PCI-DSS, HIPAA and GDPR compliance.",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,"Security & 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","You run multiple self-hosted servers — n8n, Nextcloud, databases — and you have no unified view of what happens on them. Wazuh is an open source SIEM\u002FXDR that correlates your security events in real time, without sending your logs to a third party and without a cloud subscription. Here is how to deploy it on a Linux VPS in single-node mode with Docker Compose.",[35,39,50,53,78,81,85,88],{"type":36,"title":37,"body":38},"h2","Why deploy Wazuh on your VPS","A Linux server constantly emits security signals: SSH login attempts, system file changes, privilege escalations, unusual processes. These events live in scattered logs — `\u002Fvar\u002Flog\u002Fauth.log`, your container journals, application logs — that nobody correlates. A SIEM (Security Information and Event Management) is precisely the tool that centralises these streams, analyses them and surfaces incidents.\n\nWazuh is today the open source reference in this space. Its architecture relies on a **manager** (the detection brain) that receives data from lightweight **agents** installed on each of your servers. The manager embeds a rule correlation engine, a File Integrity Monitoring (FIM) module, a vulnerability detection module and out-of-the-box regulatory compliance dashboards.\n\nUnlike Datadog SIEM or cloud-hosted Elastic SIEM, Wazuh does not charge per ingestion and your data stays within your infrastructure. This is the approach to adopt once you manage several servers and need to justify your security posture — for an audit, for a client, or simply to know what is actually happening.",{"type":40,"title":41,"items":42},"ul","What Wazuh brings to your infrastructure",[43,44,45,46,47,48,49],"Centralised logs from all your Linux servers in a single dashboard: no more SSH machine-hopping to read `auth.log`.","Rule-based intrusion detection: brute-force attempts, privilege escalations, critical file modifications — with multi-source correlation.","Real-time File Integrity Monitoring (FIM): any modification to `\u002Fetc\u002Fpasswd`, `\u002Fetc\u002Fsudoers` or your system binaries triggers an immediate alert.","PCI-DSS, HIPAA, GDPR and NIST SP 800-53 compliance rules built into the default ruleset — every alert is automatically tagged with the regulatory controls it touches.","Active vulnerability detection: Wazuh queries CVE databases and identifies installed packages exposed to known CVEs.","Complementary to CrowdSec and Fail2ban: Wazuh correlates and archives for compliance, CrowdSec acts at the perimeter — the two tools reinforce each other without duplicating.","No ingestion cost: you keep history as long as your disk allows.",{"type":36,"title":51,"body":52},"Minimum requirements before you start","The Wazuh single-node deployment (manager + indexer + dashboard in three Docker containers) is more resource-intensive than a simple monitoring agent. Here are the realistic minimums for a production use case.\n\n**For the manager (central node):**\n- **4 vCPU** minimum, 8 vCPU recommended for a fleet of 10 servers or more.\n- **8 GB of RAM** minimum for the single-node (manager + indexer + dashboard). Plan for 16 GB if you index a high volume of events or manage more than 50 agents.\n- **50 GB SSD disk** minimum; 100 GB or more if you retain 90 days of history across multiple servers.\n- Ubuntu 22.04 LTS or Debian 12, kept up to date.\n- Docker Engine 24.0+ and Docker Compose v2 installed.\n- A domain name to expose the Wazuh dashboard over HTTPS via a reverse proxy.\n\n**For each agent (on your other servers):**\n- The Wazuh agent is very lightweight: under 64 MB of RAM and under 1% CPU under normal load.\n- Compatible with Linux (Debian, Ubuntu, AlmaLinux, Rocky), Windows and macOS.\n\n**Network ports to open on the manager:**\n- `1514\u002FUDP` and `1514\u002FTCP`: agent → manager communication.\n- `1515\u002FTCP`: agent registration.\n- `55000\u002FTCP`: Wazuh REST API (local access only, do not expose publicly).\n- `9200\u002FTCP` and `9300\u002FTCP`: Wazuh Indexer (internal use between containers).\n- `443\u002FTCP`: Wazuh Dashboard via your reverse proxy.",{"type":54,"title":55,"steps":56},"steps","Deploy Wazuh with Docker Compose: full procedure",[57,60,63,66,69,72,75],{"title":58,"body":59},"Prepare the server and install Docker","Update the system, then install Docker Engine and Docker Compose v2 from the official Docker repository:\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\nVerify that Docker Compose v2 responds correctly (command `docker compose`, without a hyphen). Enable Docker at boot: `systemctl enable --now docker`.",{"title":61,"body":62},"Clone the official Wazuh Docker repository","Wazuh publishes its official Docker Compose files in the `wazuh\u002Fwazuh-docker` repository. Clone the branch matching the current stable version (v4.14.x at the time of this 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\nThe `single-node` folder contains the pre-wired `docker-compose.yml` with three services: `wazuh.manager`, `wazuh.indexer` and `wazuh.dashboard`.",{"title":64,"body":65},"Generate inter-component TLS certificates","Wazuh requires TLS certificates for communication between the manager, indexer and dashboard. The repository provides a dedicated Compose file for their generation:\n\n```bash\ndocker compose -f generate-indexer-certs.yml run --rm generator\n```\n\nCertificates are written to `config\u002Fwazuh_indexer_ssl_certs\u002F`. This step is required only once; to renew, re-run the command and then restart the stack.",{"title":67,"body":68},"Start the Wazuh stack","Launch the three containers in the background:\n\n```bash\ndocker compose up -d\n```\n\nThe first start downloads the official images (approximately 2 GB total) and initialises the indexer. Wait 60 to 90 seconds, then check that all three services are `healthy`:\n\n```bash\ndocker compose ps\n```\n\nIf `wazuh.indexer` stays in `starting` after 3 minutes, inspect its logs: `docker compose logs wazuh.indexer | tail -50`.",{"title":70,"body":71},"Change the default dashboard password","The default Wazuh dashboard credentials are `admin` \u002F `SecretPassword`. Change them immediately via the OpenSearch indexer API:\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\": \"YourNewPassword\", \"current_password\": \"SecretPassword\"}'\n```\n\nThen update the `DASHBOARD_PASSWORD` variable in `docker-compose.yml` and re-run `docker compose up -d` so the dashboard uses the new password.",{"title":73,"body":74},"Expose the dashboard via an HTTPS reverse proxy","Do not expose the dashboard directly on port 443 without a reverse proxy. With nginx, create a vhost that proxies to `https:\u002F\u002F127.0.0.1:5601` (the internal dashboard port) while disabling upstream self-signed certificate verification:\n\n```nginx\nserver {\n  listen 443 ssl;\n  server_name wazuh.your-domain.com;\n  location \u002F {\n    proxy_pass https:\u002F\u002F127.0.0.1:5601;\n    proxy_ssl_verify off;\n  }\n}\n```\n\nRenew your Let's Encrypt certificate with Certbot (`certbot --nginx -d wazuh.your-domain.com`). Do **not** expose ports 9200, 55000 or 1514\u002F1515 publicly — ports 1514-1515 should only be open to your own servers.",{"title":76,"body":77},"Install and register an agent on a remote server","On each Linux server you want to monitor, install the Wazuh agent pointing to your manager's IP or DNS name. On 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\nSet the manager address in `\u002Fvar\u002Fossec\u002Fetc\u002Fossec.conf` (tag `\u003Caddress>`), then start and enable the agent:\n\n```bash\nsystemctl daemon-reload\nsystemctl enable wazuh-agent\nsystemctl start wazuh-agent\n```\n\nThe agent appears in the dashboard under **Agents** within 30 seconds.",{"type":36,"title":79,"body":80},"Post-installation configuration: agents, rules and compliance dashboards","Once the stack is running and your first agents are connected, three adjustments significantly improve alert relevance.\n\n**Enable File Integrity Monitoring (FIM).** In the agent configuration (`\u002Fvar\u002Fossec\u002Fetc\u002Fossec.conf`), add sensitive directories to the `\u003Csyscheck>` section:\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\nEvery modification in these directories triggers an alert of level 7 or higher.\n\n**Explore the compliance dashboards.** In the Wazuh dashboard, the **Modules** section exposes pre-built views for PCI-DSS, HIPAA, GDPR and NIST SP 800-53. Each alert automatically inherits the regulatory tags defined in the manager's XML rules — for example, a privilege escalation attempt simultaneously tags PCI-DSS 10.2.5 and HIPAA 164.312(b).\n\n**Adjust the alert level threshold.** The default threshold is 3. To receive only significant alerts, edit `\u002Fvar\u002Fossec\u002Fetc\u002Fossec.conf` on the manager and raise the threshold to 7 in the `\u003Calerts>` section:\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\nRestart the manager after any configuration change: `docker compose restart wazuh.manager`.",{"type":82,"title":83,"body":84},"tip","Hardening your deployment","A few settings reduce the attack surface of the manager itself.\n\n**Isolate the manager on its own VPS** or, at minimum, behind a firewall that only opens ports 1514-1515 to your agents' IPs — never to `0.0.0.0`. On a ServOrbit VPS, the **VPS administration** option gives you access to pre-configured `ufw`: `ufw allow from \u003CAGENT_IP> to any port 1514 proto tcp`.\n\n**Enable mutual TLS authentication** between agents and manager by generating agent certificates signed by your internal CA rather than using automatic registration (`ossec-authd`). The official Wazuh documentation details the procedure under \"Agent enrollment via the Wazuh manager API\".\n\n**Encrypt the Docker volumes** that contain the OpenSearch index and configurations — especially if you host the manager on a shared VPS. A dump of the indexer contains your entire security log history.\n\n**Monitor the manager itself**: install a Wazuh agent on the VPS running the manager to detect any modification of Docker images or configuration files.",{"type":36,"title":86,"body":87},"Troubleshooting: common errors","Here are the five most common issues when deploying Wazuh with Docker, with exact messages and fixes.\n\n**1. `max virtual memory areas vm.max_map_count [65530] is too low`**\nThe OpenSearch indexer requires at least 262144. Add this line to `\u002Fetc\u002Fsysctl.conf` on the **host** (not inside the container): `vm.max_map_count=262144`, then apply with `sysctl -p`. This is the most common error on a fresh VPS.\n\n**2. `wazuh.indexer` stays in `starting` state indefinitely**\nCheck the logs first (`docker compose logs wazuh.indexer`). If you see `bootstrap checks failed`, it is almost always `vm.max_map_count` (see above) or insufficient RAM. If you see `certificate not found`, the certificates were not generated correctly — re-run `docker compose -f generate-indexer-certs.yml run --rm generator`.\n\n**3. Agent shows `Disconnected` in the dashboard**\nVerify that port 1514 is open inbound on the manager and that the manager address is correctly set in `\u002Fvar\u002Fossec\u002Fetc\u002Fossec.conf` on the agent. Test connectivity from the agent: `nc -zv \u003CMANAGER_IP> 1514`. If the connection fails, check your firewall (`ufw status`, CSF rules).\n\n**4. `ERROR: [agent_auth] Unable to create ssl context`**\nThe agent cannot validate the manager's TLS certificate. Check that `ossec.cfg` on the agent points to the DNS name rather than the bare IP if you are using a named certificate. Alternatively, disable certificate verification on the agent side during testing: use the tag `\u003Cverify_host>no\u003C\u002Fverify_host>` in the registration configuration (do **not** leave this in production).\n\n**5. `Too many open files` in manager logs**\nIncrease `nofile` limits on the host. In `\u002Fetc\u002Fsecurity\u002Flimits.conf`: `* soft nofile 65536` and `* hard nofile 65536`. In `docker-compose.yml`, add `ulimits: nofile: soft: 65536 hard: 65536` to the `wazuh.manager` service, then restart.",{"type":36,"title":89,"body":90},"Wazuh in your security stack","Wazuh is most effective when integrated with what you already have. Combined with **CrowdSec** (which blocks IPs at the network level), it covers both the perimeter and deep system-level monitoring. Combined with **Fail2ban**, it adds correlation and regulatory archiving that Fail2ban cannot produce on its own. And if you already run a **Grafana + Prometheus** stack, Wazuh complements system observability with a security layer: Prometheus tells you CPU is at 90%, Wazuh tells you why — and whether it is a cryptomining attempt.\n\nHardening your server (\u003Ca href=\"\u002Fblog\u002Flinux-hardening-vps-checklist\">Linux VPS hardening checklist\u003C\u002Fa>) defines a static security posture. Wazuh is the continuous monitoring that verifies that posture holds over time — that nobody has modified `\u002Fetc\u002Fsudoers`, that your system binaries have not been replaced, that authentication events remain within normal ranges.\n\nTo host your Wazuh manager on infrastructure whose security level you control, see \u003Ca href=\"\u002Fpourquoi\u002Fsecurite\">how ServOrbit structures its infrastructure security\u003C\u002Fa> and choose the VPS that matches your agent fleet.","Your infrastructure under surveillance","A VPS with root access, OS choice and dedicated IPv4 — what you need to run your Wazuh manager without constraints.","Secure my 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,"securing-your-vps-with-crowdsec",{"fr":100,"en":98,"ar":101,"es":102},"securiser-vps-crowdsec","تأمين-خادمك-الافتراضي-vps-باستخدام-crowdsec","proteger-vps-con-crowdsec","Securing your VPS with CrowdSec","Deploy CrowdSec on your VPS to block attacks thanks to behavioral detection and a shared community blocklist.",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-bastion","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-vps-hardening-checklist-for-agencies",{"fr":120,"en":118,"ar":121,"es":122},"linux-hardening-vps-checklist","قائمة-تصليب-خادم-لينكس-للوكالات-بعد-التسليم","hardening-linux-vps-checklist-para-agencias-tras-la-entrega","Linux VPS Hardening Checklist for Agencies","Reproducible Linux hardening checklist for agencies: auditd, sudo user, SSH key auth, UFW, fail2ban and root lockout — with per-client traceability.",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,"vps-monitoring-with-grafana-and-prometheus",{"fr":135,"en":133,"ar":136,"es":137},"monitoring-vps-grafana-prometheus","مراقبة-الخادم-الافتراضي-vps-باستخدام-grafana-و-prometheus","monitorizacion-vps-grafana-prometheus","VPS Monitoring with Grafana and Prometheus","Set up a Grafana + Prometheus stack on your VPS to collect, store and visualize your system and application metrics.","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-observability","grafana",1790987795169]