Free-tier logging in most cloud dashboards gives you maybe 7 days of retention and no correlation engine. Wazuh 4.14.9, released in October 2026 and listed by Wazuh’s own documentation as the current build (with a 5.0.0-rc1 preview of the next-generation platform also surfacing that same month, according to Release Alert), gives you an open-source SIEM and XDR stack with file integrity monitoring, vulnerability detection, and MITRE ATT&CK mapping for the cost of the server it runs on. This tutorial walks through a full install, agent enrollment, and rule tuning on a single VPS or lab machine, no license key required.
By the end you will have a working manager, indexer, and dashboard stack collecting logs from at least one endpoint, plus enough troubleshooting knowledge to survive the parts of the install that trip up most first-timers: certificate mismatches, indexer memory limits, and agents that enroll but never send data.
Don't miss new tech stories on Google
Add Tech Insider once in the Google app and our stories appear in your news suggestions.
What Is Wazuh and Why Set It Up in 2026
Wazuh is an open-source security platform that combines SIEM (security information and event management) with XDR (extended detection and response) capabilities. It watches endpoints for suspicious file changes, correlates logs from servers and applications, flags vulnerable software packages, and can trigger automated responses like blocking an IP address the moment a rule fires. The project ships as four cooperating components rather than one monolithic binary, which matters once you get to the architecture section below. It fits into a broader 2026 cybersecurity toolkit alongside vulnerability scanners and endpoint agents rather than replacing all of them.
The reason to set this up now rather than reach for a commercial SIEM: cost. Wazuh’s core platform carries no per-agent or per-event license fee, according to Wazuh’s own documentation. You pay for compute, storage, and your own time tuning rules, but the software itself is free to self-host. That is a different economic model than Splunk, where ingest volume drives a recurring bill that scales with your log growth rather than shrinking as your team gets better at filtering noise.
Wazuh 4.14.9 is the current release as of this writing, published in October 2026 according to the official Wazuh documentation — it follows 4.14.8 (September 23, 2026), 4.14.2 (January 14, 2026), 4.14.1 (November 12, 2025), 4.14.0 (October 23, 2025), 4.13.1 (September 24, 2025), 4.13.0 (September 18, 2025), and 4.12.0 (May 7, 2025). That cadence — a patch release roughly every four to eight weeks — holds even as Wazuh starts previewing 5.0.0-rc1, a next-generation release candidate that surfaced the same month, so expect to revisit this install periodically rather than treating it as a set-and-forget deployment.
Prerequisites and System Requirements
Before you start, confirm your target machine actually meets Wazuh’s resource floor. Undersizing the host is the single most common reason first installs fail partway through, usually with the indexer crashing silently or the dashboard hanging on a blank screen.
| Requirement | Single-node minimum | Small production recommendation |
|---|---|---|
| CPU | 4 cores | 8 dedicated cores or vCPUs |
| RAM | 8 GB | 16–32 GB |
| Disk | 50 GB (installation floor) | 200 GB+ SSD/NVMe for log retention |
| Architecture | 64-bit x86_64 or ARM64 | x86_64 preferred for widest package support |
| Operating system | Ubuntu 22.04/24.04, RHEL 8/9/10, Amazon Linux 2023 | Ubuntu 24.04 LTS or RHEL 9 |
The 50 GB disk figure from Wazuh’s Docker documentation is a starting point, not a retention budget. Index data, vulnerability databases, and archived alerts eat storage fast once you have more than a handful of agents reporting in. Budget extra headroom, because the indexer starts throwing watermark warnings, and eventually refuses writes, well before the disk actually fills.
Software prerequisites for this tutorial:
- A fresh Ubuntu 24.04 LTS server (this guide uses Ubuntu; RHEL-family steps differ only in package manager syntax)
- Root or sudo access
- curl, tar, and systemd already present (default on Ubuntu Server)
- Outbound internet access to packages.wazuh.com
- Open ports 443, 1514, 1515, and 55000 on your firewall/security group
- If using Docker instead of the native installer: Docker Engine 24.0+ and Docker Compose v2 (the
docker composeplugin, not the deprecated standalone binary)
Supported agent operating systems are broader than the server list. The Wazuh 4.14.8 package matrix covers Windows (MSI packages), most current Linux distributions, macOS on both Intel and Apple Silicon, and even AIX 6.1+. For this tutorial, we will enroll one Ubuntu agent and one Windows agent so you see both workflows.
Understanding the Wazuh Architecture
Wazuh is not one program. It is four components that talk to each other over specific ports, and knowing which piece does what will save you hours of confused troubleshooting later.
- Wazuh agent, runs on every monitored endpoint, collects logs, watches files for integrity changes, gathers software inventory, and can execute active-response actions when commanded.
- Wazuh server (manager), receives agent data, applies decoders and rules, generates alerts, handles agent enrollment, and exposes the Wazuh REST API on port 55000.
- Wazuh indexer, built on OpenSearch, stores and indexes every alert and event so you can search and visualize it later. This is the most resource-hungry component.
- Wazuh dashboard, the web interface for investigating alerts, managing agents, and viewing compliance and MITRE ATT&CK views, served over HTTPS on port 443.
Here is the port map you need memorized before you start opening firewall rules:
| Port | Protocol | Component | Purpose |
|---|---|---|---|
| 1514 | TCP/UDP | Wazuh server | Agent event communication |
| 1515 | TCP | Wazuh server | Agent enrollment and authentication |
| 1516 | TCP | Wazuh server | Cluster communication between server nodes |
| 514 | UDP (optional TCP) | Wazuh server | Syslog reception |
| 55000 | TCP/HTTPS | Wazuh server | Wazuh REST API |
| 9200 | TCP/HTTPS | Wazuh indexer | Indexer API |
| 9300–9400 | TCP | Wazuh indexer | Indexer cluster communication |
| 443 | TCP/HTTPS | Wazuh dashboard | Web interface |
Never expose port 9200 or 55000 to the open internet. Both give direct access to raw security data and administrative functions. If you need remote dashboard access, put it behind a VPN or a reverse proxy with its own authentication layer, not a public IP with a firewall rule and a prayer.
Step 1: Provision and Update the Server
Spin up a fresh Ubuntu 24.04 instance meeting the specs above, then update packages before touching Wazuh. Installing on top of a stale package cache is a common source of dependency conflicts.
sudo apt update && sudo apt upgrade -y
sudo apt install -y curl tar gnupg apt-transport-https
sudo timedatectl set-ntp true
timedatectl statusThat last pair of commands matters more than it looks. Clock drift between the server and its own certificates is one of the most common causes of TLS handshake failures during Wazuh setup, because the certificates the installer generates are time-bound. Confirm NTP sync shows “synchronized” before moving on.
Step 2: Run the Wazuh Installation Assistant
Wazuh’s quickstart method uses a single installation assistant script that deploys the indexer, server, and dashboard together on one host. This is the fastest path to a working lab and is what we use for the rest of this tutorial.
curl -sO https://packages.wazuh.com/4.14/wazuh-install.sh
sudo bash ./wazuh-install.sh -aThe -a flag performs the all-in-one deployment: indexer, server, and dashboard on the same machine. The script takes several minutes to run since it is generating self-signed certificates, initializing the indexer, and starting three separate services in sequence. Do not interrupt it partway through, a killed installation assistant run is harder to clean up than a slow one is to wait out.
When it finishes, the script prints an admin username and an auto-generated password for the dashboard. Copy that password somewhere safe immediately; it is not stored in plaintext anywhere and re-displaying it later requires a separate recovery command.
Step 3: Verify the Three Core Services Are Running
Before touching the dashboard, confirm all three services report active status at the systemd level. This catches silent failures early.
sudo systemctl status wazuh-indexer --no-pager
sudo systemctl status wazuh-manager --no-pager
sudo systemctl status wazuh-dashboard --no-pagerAll three should show “active (running)”. If wazuh-indexer fails to start, jump ahead to the troubleshooting section below before proceeding, nothing else in the stack works correctly until the indexer is healthy, since the manager and dashboard both depend on it for storage and queries.
Once all three are confirmed active, check indexer cluster health directly:
curl -k -u admin:YOUR_INDEXER_PASSWORD \
https://127.0.0.1:9200/_cluster/health?prettyYou want "status" : "green" or at minimum "yellow" on a single-node deployment (yellow is expected on one node because replica shards cannot be assigned without a second node, this is normal, not a bug). A "red" status means something is actually broken and needs fixing before you continue.
Step 4: Log Into the Wazuh Dashboard
Open a browser and navigate to https://YOUR_SERVER_IP. You will hit a certificate warning because the installer generates a self-signed certificate by default, accept it for lab use, or replace it with a certificate from your own CA before exposing this to a team.
Log in with the admin username and the password the installer printed in Step 2. On first login you land on the Wazuh overview dashboard, which will look mostly empty since no agents are reporting data yet. That is expected and gets fixed in the next steps.
Step 5: Enroll Your First Linux Agent
On the Ubuntu machine you want to monitor (this can be the Wazuh server itself for a minimal test, or a separate host for a real deployment), add the Wazuh repository and install the agent package.
curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | sudo 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" | \
sudo tee /etc/apt/sources.list.d/wazuh.list
sudo apt update
sudo WAZUH_MANAGER='YOUR_MANAGER_IP' apt install -y wazuh-agentReplace YOUR_MANAGER_IP with the actual IP or hostname of your Wazuh server. This environment variable gets baked into the agent’s config file automatically during install, saving you an extra manual edit.
sudo systemctl daemon-reload
sudo systemctl enable wazuh-agent
sudo systemctl start wazuh-agent
sudo systemctl status wazuh-agent --no-pagerBack in the dashboard, go to Agents management and confirm the new agent shows status “Active” within a minute or two. If it stays stuck on “Never connected,” see the agent troubleshooting entry further down.
Step 6: Enroll a Windows Agent
Most real environments have a mix of Linux and Windows endpoints, so it is worth doing this once even in a lab. On the target Windows machine, open PowerShell as Administrator and run:
Invoke-WebRequest -Uri https://packages.wazuh.com/4.x/windows/wazuh-agent-4.14.8-1.msi -OutFile $env:tmp\wazuh-agent.msi
msiexec.exe /i $env:tmp\wazuh-agent.msi /q WAZUH_MANAGER='YOUR_MANAGER_IP'
NET START WazuhSvcThe MSI installer accepts the manager address as a silent-install parameter, identical in spirit to the environment variable used on Linux. Verify the service is running with Get-Service WazuhSvc, it should report “Running.” Give it a minute, then check the dashboard’s Agents page the same way as the Linux agent.
Step 7: Enable File Integrity Monitoring
File integrity monitoring (FIM) is one of Wazuh’s core detection features: it watches specific directories for unauthorized additions, modifications, or deletions and alerts when they happen. On the agent, edit /var/ossec/etc/ossec.conf and add or confirm a syscheck block:
<syscheck>
<disabled>no</disabled>
<frequency>43200</frequency>
<directories check_all="yes" realtime="yes">/etc,/usr/bin,/usr/sbin</directories>
<directories check_all="yes">/home,/var/www</directories>
</syscheck>The realtime="yes" attribute on system binary directories triggers near-instant alerts on change, using inotify under the hood on Linux. Reserve realtime monitoring for high-value paths only, running it against large, frequently-changing directories like /home generates excessive CPU load and alert noise. Restart the agent to apply:
sudo systemctl restart wazuh-agentTest it by creating a file in a monitored directory, then check the dashboard’s Integrity Monitoring module a few minutes later. You should see the new file logged as an addition event.
Step 8: Turn On Vulnerability Detection
Wazuh cross-references each agent’s installed software inventory against vulnerability feeds to flag outdated or exploitable packages. On the manager, edit /var/ossec/etc/ossec.conf and confirm the vulnerability-detection module is enabled:
<vulnerability-detection>
<enabled>yes</enabled>
<index-status>yes</index-status>
<feed-update-interval>60m</feed-update-interval>
</vulnerability-detection>sudo systemctl restart wazuh-managerThe first feed sync can take a while depending on your connection, since it is pulling a full vulnerability database rather than a delta. Give it 15–30 minutes before checking the Vulnerability Detection dashboard module. Results depend on the quality of each agent’s software inventory data, so this feature tends to be most reliable on well-maintained Linux hosts with a standard package manager. Wazuh’s vulnerability module covers installed packages, not open ports or web application flaws, for that layer, pair it with a dedicated scanner like a Nessus Essentials setup running against the same hosts.
Step 9: Configure Active Response
Active response lets Wazuh automatically react to specific alerts, blocking an IP, killing a process, or disabling an account. This is the feature that turns Wazuh from a passive log shelf into something closer to a lightweight IPS. Configure it cautiously; a misconfigured active response rule can lock you out of your own server.
A common starting example is blocking IPs after repeated failed SSH logins. On the manager, add to ossec.conf:
<active-response>
<disabled>no</disabled>
<command>firewall-drop</command>
<location>local</location>
<rules_id>5712</rules_id>
<timeout>600</timeout>
</active-response>Rule 5712 in the default Wazuh ruleset corresponds to multiple SSH authentication failures from the same source. The timeout value of 600 seconds means the block automatically lifts after 10 minutes rather than becoming permanent, start with a short timeout while testing, then extend it once you trust the rule isn’t catching legitimate traffic.
Before enabling any active response in a shared or production environment, add your own management IP to an allowlist so a false positive cannot cut off your own access.
Step 10: Add YARA-Based Malware Scanning
Wazuh does not ship a built-in malware scanner, but it integrates cleanly with YARA, the pattern-matching tool widely used for malware identification. The typical design triggers a YARA scan whenever FIM detects a new or modified file in a sensitive directory.
sudo apt install -y yara
sudo mkdir -p /var/ossec/ruleset/yara/rules
curl -s https://raw.githubusercontent.com/Yara-Rules/rules/master/malware/MALW_Eicar.yar \
-o /var/ossec/ruleset/yara/rules/malware.yarWire it into an active-response command that runs a YARA scan against any file flagged by syscheck. Keep the ruleset curated and current, an outdated or overly broad YARA rule set generates false positives fast, and each scan consumes CPU cycles on every triggering event, so scope it to directories where untrusted files are likely to land (upload folders, temp directories, download paths). When a scan does flag something, a tool like a CyberChef setup is useful for manually decoding and inspecting the suspicious payload before deciding how to respond.
Step 11: Map Alerts to MITRE ATT&CK and Enable Compliance Modules
One of Wazuh’s more useful dashboard features is automatic mapping of triggered rules to MITRE ATT&CK tactics and techniques, giving analysts a standardized way to see detection coverage gaps rather than a flat alert list. This works out of the box with the default ruleset, no extra configuration needed, just navigate to the MITRE ATT&CK module in the dashboard once you have alerts flowing.
For compliance-driven environments, Wazuh includes dashboards and rule mappings for PCI DSS, HIPAA, GDPR, and NIST-aligned controls, plus CIS benchmark configuration assessment. Enable the security configuration assessment (SCA) module per agent. Note that Wazuh’s alerting only covers what reaches your monitored endpoints and logs, it will not tell you if employee credentials are already circulating on criminal marketplaces, which is a separate problem better handled with a dark web monitoring setup running alongside it:
<sca>
<enabled>yes</enabled>
<scan_on_start>yes</scan_on_start>
<interval>12h</interval>
</sca>Worth stating plainly: these modules support evidence collection and continuous monitoring toward a framework, but enabling them does not make an organization compliant on its own. Actual compliance still depends on governance, documented procedures, scope definition, and independent audit, treat Wazuh’s compliance dashboards as one input to that process, not a checkbox.
Step 12: Tune Alert Noise and Custom Rules
A fresh Wazuh install with the default ruleset and several active agents will generate more low-value alerts than most teams want to triage. Tuning is not optional if you want the dashboard to stay useful past week one.
Create a local rules file so your customizations survive future Wazuh upgrades instead of getting overwritten:
sudo nano /var/ossec/etc/rules/local_rules.xml<group name="local,">
<rule id="100010" level="0">
<if_sid>5501</if_sid>
<match>known-internal-service</match>
<description>Suppress known internal service login noise</description>
</rule>
</group>Custom rule IDs should start at 100000 to avoid colliding with Wazuh’s built-in ruleset. Setting level="0" effectively silences a specific noisy pattern without disabling the parent rule for everything else. Restart the manager after any rules change:
sudo systemctl restart wazuh-managerRevisit your rule tuning weekly for the first month. Alert fatigue kills SIEM adoption faster than almost anything else, a dashboard nobody checks because it cried wolf too many times is worse than no dashboard at all.
Step 13: Set Up Integrations for Alerting
A SIEM that only shows data when someone happens to log into the dashboard is much less useful than one that pages a human when something serious happens. Wazuh supports integrations with Slack, PagerDuty, email, and generic webhooks through its integrator module. A Slack example:
<integration>
<name>slack</name>
<hook_url>https://hooks.slack.com/services/YOUR/WEBHOOK/URL</hook_url>
<level>10</level>
<alert_format>json</alert_format>
</integration>Setting level="10" means only alerts at severity 10 or above trigger a Slack message, keeping the channel from flooding with low-priority noise. Add this block to ossec.conf on the manager and restart the service to apply it. For anything approaching production use, pair this with a ticketing integration like TheHive so high-severity alerts automatically generate a tracked case rather than just a chat message someone might scroll past.
Docker-Based Installation: The Alternative Path
If you prefer containers over a native systemd install, useful for tearing down and rebuilding a lab repeatedly, or running Wazuh alongside other containerized tooling, Wazuh publishes official Docker images for the manager, indexer, dashboard, and agent.
git clone https://github.com/wazuh/wazuh-docker.git -b v4.14.8
cd wazuh-docker/single-node
docker compose up -dCheckout a tag matching your target Wazuh version rather than the default branch — running an arbitrary branch against production data invites version-mismatch bugs between components; as of October 2026 that means pinning to the v4.14.9 tag, the current release per Wazuh’s own documentation, rather than the v4.14.8 example shown above. The Docker deployment’s minimum footprint is the same 4 cores and 8 GB RAM as the native single-node install; a multi-node Docker Compose stack bumps that to 16 GB RAM minimum according to Wazuh’s own Docker documentation.
Before running docker compose up, confirm ports 443, 1514, 1515, 55000, and 9200 are free on the host, and that you have edited the generated .env file with your own passwords rather than shipping with defaults, leaving default Docker deployment credentials in place is a startlingly common finding in exposed-Wazuh security scans.
Wazuh Cloud vs. Self-Hosted: When to Pay for Managed Hosting
Everything covered so far assumes self-hosting, which is the right default for a lab, a small team, or anyone comfortable owning the operational burden. But Wazuh also offers Wazuh Cloud, a managed hosted version of the same platform, and it is worth knowing when that trade makes sense rather than treating self-hosting as the only option.
Self-hosting wins on cost when your team already has Linux operations experience and spare infrastructure capacity, you are trading engineering time for a lower cash outlay, since the core software has no license fee. It also wins on control: you decide exactly where data lives, which matters for teams with strict data-residency or air-gapped requirements that a hosted service cannot satisfy.
Managed hosting through Wazuh Cloud starts making more sense once the operational overhead of running your own indexer cluster, capacity planning, certificate rotation, upgrade testing, backup verification, starts competing for the same engineering hours you’d rather spend on detection engineering and rule tuning. Wazuh Cloud pricing is quote- and plan-dependent based on monitored endpoints, data volume, and retention, as a reference point, The Geeks Club listed Wazuh Cloud’s Small plan at $571/month for up to 100 agents as of September 2026, so get a current quote directly from Wazuh rather than assuming that figure holds for your own plan tier; the trade-off calculus is really about your team’s bandwidth, not a simple price comparison.
A reasonable middle path many teams take: start self-hosted with the setup in this tutorial to learn the platform’s behavior and tune rules against real traffic, then evaluate Wazuh Cloud once agent count and data volume outgrow what a single engineer can comfortably babysit alongside their other responsibilities. Whichever path you take, test your detection pipeline end to end, running a controlled exercise with a GoPhish phishing simulation against your own users is a practical way to confirm Wazuh actually surfaces the resulting alerts before you rely on it during a real incident.
Common Pitfalls to Avoid
These are the mistakes that show up most often in Wazuh forums and support channels, in rough order of how early in the process they hit.
- Undersizing the VPS. Running the all-in-one stack on a 2 GB or 4 GB instance because “it’s just a lab” leads to the indexer getting killed by the Linux OOM killer under normal alert volume, not just under load testing.
- Skipping NTP sync before install. Certificate generation is time-sensitive; clock drift causes TLS failures that look like a networking problem but are actually a time problem.
- Exposing port 9200 or 55000 publicly. Both grant direct access to raw security data or administrative functions, treat them like database ports, not web ports.
- Enabling realtime FIM on huge, volatile directories. Monitoring
/homeor a build directory in realtime mode generates CPU load and alert volume disproportionate to the security value. - Writing custom rules directly into the default ruleset files. They get overwritten on the next Wazuh upgrade. Always use
local_rules.xmland custom rule IDs above 100000. - Deploying active response without an allowlist. A false positive on an SSH brute-force rule can block your own management IP, locking you out of a server you cannot reach any other way.
- Ignoring the first vulnerability-feed sync delay. The vulnerability detection module needs time to pull its full database after enabling; checking the dashboard five minutes later and concluding it is broken is a frequent false alarm.
- Leaving default Docker Compose passwords in place. The
.envfile ships with placeholder credentials meant to be changed before first boot, not after.
Expected Output: What a Healthy Wazuh Deployment Looks Like
Once the install is stable and agents are reporting, here is roughly what you should see. The indexer health check should return:
{
"cluster_name" : "wazuh-cluster",
"status" : "green",
"number_of_nodes" : 1,
"active_primary_shards" : 15,
"active_shards" : 15,
"unassigned_shards" : 0
}In the dashboard’s Agents view, each enrolled endpoint should show a green “Active” status badge with a “Last keep alive” timestamp updating every few minutes. The Security Events module should populate with a mix of low-severity informational events (routine logins, package updates) and, once you have run a test like the EICAR file drop, at least one higher-severity alert demonstrating that detection is actually firing, not just collecting logs.
Troubleshooting Guide
Eight issues that account for most Wazuh support requests, based on the official documentation’s troubleshooting guidance and common deployment patterns.
1. Indexer cluster health shows red
Check sudo systemctl status wazuh-indexer and journalctl -u wazuh-indexer -n 200 first. Red status usually traces back to insufficient memory, a disk watermark being hit, or certificate/hostname mismatches between nodes. Run df -h and free -h to rule out capacity issues before touching configuration. Do not delete indices to force a clean state until you have confirmed whether the affected shard is a primary and whether the underlying data is actually recoverable.
2. Dashboard shows “unable to connect to indexer”
Verify the indexer service is actually running, then test connectivity directly with curl -k https://127.0.0.1:9200 from the dashboard host. Common causes are an incorrect indexer URL in the dashboard config, a firewall blocking port 9200 locally, or clock skew making the TLS certificate appear invalid even though it has not expired.
3. Agent enrolls but never sends data (“Never connected”)
Confirm the manager address in the agent’s config actually matches your server, and that DNS or /etc/hosts resolves it correctly. Test raw connectivity with telnet YOUR_MANAGER_IP 1514 and 1515 from the agent host. On the manager, confirm it is actually listening with sudo ss -lntup | grep -E '1514|1515'. Cloud security groups and NAT rules are a frequent silent blocker here, the agent config can be perfect while the network simply drops the traffic.
4. Dashboard SSL certificate errors in the browser
Beyond the expected self-signed warning, watch for a hostname/IP mismatch, if the certificate’s SAN lists a hostname but you are accessing the dashboard by raw IP, browsers will flag it. Access the dashboard consistently by the same name the certificate was issued for. Verify cert and key actually match with openssl x509 -noout -modulus -in dashboard.pem | openssl sha256 compared against the equivalent command for the key file.
5. Out-of-memory crashes on a small VPS
Symptoms include the indexer’s Java process disappearing from systemctl status output with no clear error, or the dashboard becoming unresponsive under normal load. The fix is rarely a configuration tweak, it is usually that the host genuinely needs more RAM. 8 GB is a documented floor, not a comfortable operating point; 16 GB avoids most of these crashes on a real workload.
6. Vulnerability detection module shows no results
Give the initial feed sync at least 30 minutes before assuming it is broken, it pulls a full vulnerability database on first run, not an incremental update. If results are still empty after that, confirm <vulnerability-detection><enabled>yes</enabled> is actually set on the manager and that the manager has outbound internet access to reach the feed source.
7. Active response blocks legitimate traffic or locks out admins
If you get locked out, you will need console or out-of-band access to the server to manually clear the firewall rule Wazuh’s active response added (check iptables -L or your cloud provider’s equivalent). Prevent recurrence by adding your management IPs to an active-response allowlist and testing new rules with a short timeout before extending it.
8. Docker Compose stack fails to start or ports conflict
Run docker compose ps and docker compose logs --tail=200 wazuh.indexer to identify which container is failing. Frequent causes: another service already bound to 443 or 9200, an outdated Docker Compose v1 binary being invoked instead of the v2 plugin, or insufficient vm.max_map_count on the host, OpenSearch-based components typically need this kernel parameter raised above the Linux default before they will start reliably.
Wazuh vs. Splunk, Elastic Security, and Security Onion
None of these tools solve the exact same problem, so “which is best” depends heavily on what you are actually trying to monitor.
| Platform | Core strength | Cost model | Best fit |
|---|---|---|---|
| Wazuh | Endpoint XDR, FIM, vulnerability detection, compliance dashboards | Free self-hosted core; paid Wazuh Cloud/support available | Teams that want SIEM+EDR functionality without per-event licensing |
| Splunk Enterprise Security | Mature analytics, huge integration ecosystem | Commercial, typically ingest- or workload-based | Large enterprises with budget for a mature commercial SIEM |
| Elastic Security | Flexible search, detection engineering, existing Elastic users | Self-managed or cloud tiers, feature-gated by license | Organizations already running the Elastic Stack |
| Security Onion | Network security monitoring via Zeek and Suricata | Free/open-source; paid support optional | Network-centric monitoring and packet-level threat hunting |
Wazuh’s clearest advantage is cost predictability for endpoint-focused monitoring: no per-event ingest fee means your bill does not spike just because you added more logging. Splunk typically offers the broadest mature ecosystem of prebuilt content and integrations but can get expensive fast as data volume climbs. Elastic Security makes the most sense if your organization already runs the Elastic Stack for other purposes. Security Onion is the stronger choice when network telemetry and packet analysis are the primary requirement rather than endpoint-level detail, its endpoint capability is less unified than Wazuh’s agent-based model. If your organization is standardized on Microsoft tooling instead, it is also worth comparing Wazuh’s agent-based approach against a Microsoft Defender for Endpoint setup, which trades open-source flexibility for tighter native Windows integration.
Advanced Tips for Production Deployments
Once the basic lab install is stable, a few practices separate a toy deployment from something a SOC can actually rely on.
- Move to a distributed architecture before you scale agent count significantly. Splitting the indexer, manager, and dashboard onto separate nodes isolates the most resource-hungry component (the indexer) so a spike in log volume does not starve the dashboard of CPU.
- Replace the self-signed certificate with one from your internal CA. Browser certificate warnings train analysts to click through security prompts without reading them, exactly the habit you do not want in a SOC tool.
- Set index lifecycle policies rather than letting retention grow unbounded. Decide your compliance-driven retention window up front and configure automated rollover and deletion, rather than manually purging indices when disk alerts fire.
- Version-pin your Docker deployment. Track a specific Wazuh release tag in your infrastructure-as-code rather than always pulling latest, so an upstream update cannot silently change behavior in production.
- Monitor CVE-2026-71540 and future advisories directly from Wazuh’s own release channels. Third-party CVE indexes can list an issue before the vendor confirms which specific versions are affected, always cross-check against Wazuh’s official release notes before assuming your version is exposed.
- Back up your Wazuh indexer snapshots and generated certificates regularly. A rebuild from scratch after a disk failure is far more painful than restoring from a snapshot taken the night before.
Complete Working Project: A Minimal SOC Lab
Putting the full tutorial together, here is the complete sequence for a working single-node Wazuh lab monitoring one Linux and one Windows endpoint, with FIM, vulnerability detection, active response, and Slack alerting all enabled.
# On the Wazuh server (Ubuntu 24.04, 8GB+ RAM)
sudo apt update && sudo apt upgrade -y
sudo timedatectl set-ntp true
curl -sO https://packages.wazuh.com/4.14/wazuh-install.sh
sudo bash ./wazuh-install.sh -a
sudo systemctl status wazuh-indexer wazuh-manager wazuh-dashboard --no-pager
# On the Linux agent
curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | sudo 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" | \
sudo tee /etc/apt/sources.list.d/wazuh.list
sudo apt update
sudo WAZUH_MANAGER='YOUR_MANAGER_IP' apt install -y wazuh-agent
sudo systemctl enable --now wazuh-agent
# On the manager: enable FIM, vulnerability detection, and SCA in ossec.conf,
# then create local_rules.xml with custom rule IDs above 100000,
# add the Slack integration block, and restart:
sudo systemctl restart wazuh-managerRun through this sequence end to end and you have a functioning open-source SIEM/XDR lab that costs nothing beyond the server it runs on, a reasonable foundation before deciding whether to scale into a distributed production deployment or move to Wazuh Cloud’s managed hosting.
Frequently Asked Questions
Is Wazuh really free, or are there hidden costs?
The self-hosted Wazuh platform carries no license fee for the software itself, according to Wazuh’s own documentation, there is no per-agent or per-event charge. Your actual costs are infrastructure (compute, storage, bandwidth) and the engineering time to run and tune it. Wazuh Cloud, the managed hosted option, and paid commercial support are separate offerings with their own recurring cost if you choose them.
How much RAM does Wazuh actually need for a small business?
8 GB is the documented minimum for a single-node all-in-one Docker deployment, but that is a floor for testing, not comfortable production use. For a small business monitoring a few dozen endpoints, 16 GB gives meaningfully more headroom before you start seeing memory pressure on the indexer.
Can Wazuh replace Splunk or Elastic Security entirely?
For endpoint-focused SIEM and XDR use cases, often yes, and at a much lower licensing cost. For organizations relying heavily on Splunk’s mature prebuilt content ecosystem or an existing large Elastic Stack investment, a full replacement involves real migration work, not just a swap of the log destination.
Does Wazuh work on Windows Server, or only Linux?
The central components (manager, indexer, dashboard) run on Linux only. Windows is fully supported as an agent platform, however, with an MSI installer package covering current Windows desktop and server releases.
What is the difference between the Wazuh manager and the Wazuh server?
They refer to the same central analysis component. Current Wazuh documentation uses “server” more consistently, but “manager” persists in configuration file names, systemd service names, and older documentation, so you will see both terms used interchangeably throughout the ecosystem.
How often does Wazuh release updates, and do I need to upgrade immediately?
Wazuh ships patch releases roughly every four to eight weeks based on recent release history — 4.14.8 shipped September 23, 2026 and 4.14.9 followed in October 2026 as the current documented release, with a 5.0.0-rc1 preview of the next major version also appearing that month according to Release Alert. Review each release’s notes for security fixes specifically; a patch addressing a CVE should be prioritized over one that only adds features, and if you are mid-upgrade cycle it is worth deciding now whether to track the 4.14.x line or start evaluating the 5.0 release candidate.
Is Wazuh vulnerable to any known CVEs right now?
Third-party vulnerability indexes list CVE-2026-71540, a memory-allocation issue with a reported CVSS score of 7.5, published September 24, 2026. Confirm affected and fixed versions directly against Wazuh’s official release notes before assuming your deployment is exposed, since third-party CVE listings sometimes lag or precede the vendor’s own advisory in scope details.
Do I need Docker, or is the native installer better?
Neither is strictly better. The native installation assistant is simpler for a straightforward Linux server and matches what most official documentation assumes. Docker is a better fit if you already manage other services as containers, need to rebuild the lab frequently, or want the deployment defined declaratively in a Compose file for reproducibility.
