A breach now costs U.S. organizations an average of $10.22 million – an all-time high – while the global average actually fell to $4.44 million, according to IBM’s 2025 Cost of a Data Breach Report. The single biggest lever on that number is time: companies still take a mean of 241 days to identify and contain an incident, and the teams that shaved 80 days off that lifecycle did it with security monitoring, AI, and automation. The problem is that the tooling that buys you that time – a Security Information and Event Management (SIEM) platform – has traditionally been priced per gigabyte ingested or per host, which pushes real deployments into five and six figures a year.
This Wazuh tutorial fixes the cost problem without giving up capability. Wazuh is a free, open-source SIEM and XDR platform that bundles log analysis, file integrity monitoring, intrusion and vulnerability detection, configuration auditing, MITRE ATT&CK mapping, and automated response into one stack you fully own. In the next 14 steps you will stand up a working single-node Wazuh 4.14.7 server, log into the dashboard, enroll Linux and Windows agents, switch on the detection engines, wire up active response, and build the compliance dashboards that auditors actually ask for. Budget about 40 minutes for the base install and first agent, and another hour to light up every capability.
One timing note before you start: as of September 29, 2026, Wazuh 4.14.8 (released September 23, 2026) is the current stable release – Wazuh’s own documentation lists it as current, and GitHub’s “Latest” tag on the wazuh/wazuh repository moved to 4.14.8 that same week, succeeding 4.14.7, which Patchletter had independently verified as the stable version on July 30, 2026 – while Wazuh 5.0 is still in beta – beta1 shipped in April 2026 with a rewritten agent communication protocol and a new indexer, and beta2 followed in May 2026. The 4.14.x line has shipped fast all year – 4.14.6 landed July 1, 2026 with updated eBPF libraries (libbpf 1.7.0, bpftool 7.7.0), and 4.14.5 arrived April 23, 2026 with the embedded Python runtime bumped to 3.10.20 – a pace that traces back to 4.13.0 launching in September 2025 and 4.14.0 following in October 2025, after 4.13.1 was still the “Latest” tag on GitHub as of that same October. Even older branches are still getting attention: Wazuh’s documentation shows the legacy 4.10.x line – which debuted in January 2025 with Microsoft Intune integration – received its own maintenance update, 4.10.5, on September 15, 2026. This guide deploys the stable 4.14 branch, now at 4.14.8, and the final section covers what changes when 5.0 reaches general availability so your build is future-proof.
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 Build Your Own SIEM in 2026?
Wazuh is a unified security platform that collects telemetry from your endpoints and cloud workloads, normalizes it, runs it through a correlation engine, and surfaces alerts and compliance evidence in a web dashboard. It began life as a fork of the venerable OSSEC host-based intrusion detection system back in 2015 and has since grown into a full SIEM/XDR offering maintained by Wazuh Inc., founded by Santiago Bassett. The core engine is licensed under the GPLv2 and the search and visualization layers are built on the Apache-2.0 OpenSearch project, so the entire stack is genuinely free to run – you pay only for the infrastructure underneath it.
The project is one of the most widely deployed open-source security tools in the world. The wazuh/wazuh GitHub repository carried roughly 16,100 stars as of July 2026 and the project reports more than 30 million downloads a year. Release velocity backs that up: GitHub still had 4.13.1 tagged “Latest” as of October 2025, and by September 23, 2026 that “Latest” tag had moved all the way to 4.14.8, the endpoint of a cadence that ran through 4.12.0 in May 2025, 4.13.0 in September 2025, 4.14.0 in October 2025, and 4.14.7 in July 2026 – the monthly 4.14.x rhythm that produced the versions in this guide. That scale matters: the ruleset, decoders, vulnerability feeds, and integrations are battle-tested across a huge installed base, which is exactly what you want from the system that decides whether an event is noise or an intrusion.
So why build your own SIEM instead of buying one? Three reasons dominate. First, cost predictability: commercial SIEMs bill on data volume or endpoints, so a noisy week of logs can blow your budget; a self-hosted Wazuh deployment costs the same whether you ingest one gigabyte or one terabyte. Second, data sovereignty: every log stays on hardware you control, which simplifies HIPAA, GDPR, and contractual residency obligations. Third, capability: the same Wazuh agent that ships your logs also performs file integrity monitoring, vulnerability scanning, configuration assessment, and active response – features that are often separate paid add-ons elsewhere.
Wazuh Architecture: The Four Components Explained
Before you install anything, it helps to understand the four pieces you are about to deploy. In a single-node (“all-in-one”) build, the first three run on one server and the fourth lives on every machine you monitor. The official components documentation describes each in depth, but here is the working mental model.
The Wazuh Server, Indexer, and Dashboard
The Wazuh server (also called the manager) is the brain. It receives data from agents over an encrypted channel, runs it through decoders that parse the raw events and rules that decide what is suspicious, and triggers alerts and active responses. The Wazuh indexer is an OpenSearch-based engine that stores and indexes those alerts so they can be searched at speed. The Wazuh dashboard is an OpenSearch Dashboards fork that gives you the web UI for hunting, reporting, and compliance views. Agent-to-server traffic is encrypted with AES, and each component speaks on its own dedicated port.
The Wazuh Agent
The Wazuh agent is a lightweight piece of software you install on each endpoint. It collects logs, monitors file changes, inventories software, checks system configuration against benchmarks, and executes active-response scripts. It runs on Linux (every major distribution), Windows 7 through 11 and Windows Server, macOS 10.14 and newer, plus Solaris, AIX, and HP-UX – and since version 4.12.0, which launched in May 2025, the central components themselves also run on ARM64. The software-inventory side keeps expanding too: Wazuh first introduced an IT Hygiene dashboard in 4.13.0 (September 2025), and Wazuh 4.14.0 (released October 2025) then widened that visibility from a single view to four full inventory areas – browser extensions, running services, users, and groups – so the agent now flags far more than just installed packages. The table below summarizes the components and the ports you must keep open between agents and the server.
| Component | Built on | Default port(s) | Role |
|---|---|---|---|
| Wazuh server / manager | C++ analysis engine (GPLv2) | 1514/tcp (events), 1515/tcp (enrollment), 1516/tcp (cluster) | Decoders, rules, correlation, active response |
| Wazuh server API | Python / REST | 55000/tcp | Programmatic management and automation |
| Wazuh indexer | OpenSearch (Apache 2.0) | 9200/tcp | Stores and indexes alerts and events |
| Wazuh dashboard | OpenSearch Dashboards | 443/tcp | Web UI, hunting, compliance reporting |
| Wazuh agent | Multi-platform daemon | Outbound to 1514/1515 | Log collection, FIM, SCA, vuln data, response |
| Syslog ingestion (optional) | Remote daemon | 514/udp or 514/tcp | Agentless devices, firewalls, switches |
Prerequisites and System Requirements
This Wazuh tutorial assumes a fresh 64-bit Linux server with sudo access and internet connectivity. The all-in-one installer is supported on recent Ubuntu, Debian, RHEL, AlmaLinux, Rocky, Amazon Linux, and openSUSE releases. You also need a second machine (Linux or Windows) to act as your first monitored endpoint. The absolute minimum for a lab is 2 vCPU and 4 GB RAM, but the indexer is memory-hungry, so plan for 8 GB the moment you go past a handful of agents.
| Requirement | Version / spec | Notes |
|---|---|---|
| Wazuh (stable) | 4.14.5 (Apr 23, 2026) | Branch installed by this guide; 5.0 still in beta |
| Server OS | Ubuntu 22.04/24.04, Debian 12, RHEL 9, AlmaLinux 9 | 64-bit; ARM64 supported since 4.12 |
| CPU | 2 vCPU (lab) / 4–8 vCPU (prod) | Correlation scales with event rate |
| RAM | 4 GB (lab) / 8 GB+ (prod) | Indexer needs a JVM heap; 8 GB is the practical floor |
| Disk | 50 GB+ | Scales with log retention; SSD strongly recommended |
| Browser | Recent Chrome, Edge, or Firefox | Dashboard is served over HTTPS on 443 |
Sizing the host correctly is the difference between a snappy SOC and a dashboard that times out. Wazuh’s official guidance ties hardware to agent count and log volume. Use the table below as a starting point, and remember that storage is the variable that grows with retention – a year of logs for a busy estate can dwarf the operating-system footprint.
| Deployment size | Agents | vCPU | RAM | Storage (90-day baseline) |
|---|---|---|---|---|
| Lab / proof of concept | 1–10 | 2 | 4 GB | 50 GB |
| Small production | 10–25 | 4 | 8 GB | 50–100 GB |
| Medium | 25–50 | 8 | 8 GB | 100–200 GB |
| Larger single node | 50–100 | 8 | 16 GB | 200 GB+ |
Beyond about 100 agents or heavy log volume, split the indexer, server, and dashboard onto separate nodes and consider a multi-node indexer cluster. Everything in this guide still applies – you simply run the components on dedicated hosts instead of one box.
Step 1 – Prepare and Harden the Host
Start clean. Update the system, set a fully qualified hostname, and confirm the clock is synchronized – a SIEM with a skewed clock produces alerts you cannot correlate. Accurate timestamps are non-negotiable for forensic value, so install and enable a time daemon if one is not already running.
# Update packages and set a clear hostname
sudo apt update && sudo apt upgrade -y
sudo hostnamectl set-hostname wazuh-soc-01
# Verify time sync (critical for log correlation)
timedatectl status
sudo systemctl enable --now systemd-timesyncd
# Confirm you have at least 4 GB RAM and free disk
free -h
df -h /If this host is internet-facing, lock the firewall down to only the ports you actually need. The dashboard (443) and agent ports (1514/1515) must be reachable by the right networks; the indexer (9200) and API (55000) should never be exposed to the public internet. We will open them deliberately in Step 4.
Step 2 – Run the Wazuh All-in-One Installer
Wazuh ships an assistant script that installs the server, indexer, and dashboard, generates certificates, and wires the three components together. The -a flag means “all-in-one.” Download it and run it with sudo. On a correctly sized host this takes 8–15 minutes and is the heart of any Wazuh install.
# Download and launch the all-in-one installer
curl -sO https://packages.wazuh.com/4.14/wazuh-install.sh
sudo bash ./wazuh-install.sh -aWhen the script finishes you will see a success banner. Note the admin password it prints – you will need it in the next step.
INFO: --- Summary ---
INFO: You can access the web interface https://<wazuh-server-ip>
User: admin
Password: <your-generated-password>
INFO: Installation finished.Verify all three services are active before moving on. If any of them is not active (running), jump to the troubleshooting section before continuing – chasing agent problems on a half-installed server wastes hours.
sudo systemctl status wazuh-indexer --no-pager
sudo systemctl status wazuh-manager --no-pager
sudo systemctl status wazuh-dashboard --no-pagerStep 3 – Retrieve Credentials and Log Into the Dashboard
If you missed the password in the installer output, every generated credential is stored in the wazuh-install-files.tar archive the script left in your working directory. Extract just the password file to standard output so nothing lingers on disk.
# Print all generated passwords (admin, kibanaserver, wazuh-wui, etc.)
sudo tar -O -xvf wazuh-install-files.tar wazuh-install-files/wazuh-passwords.txtOpen https://<wazuh-server-ip> in your browser. Because the installer issues self-signed certificates, your browser will warn you the first time – that is expected on a fresh lab build, and Step 4 covers replacing those certs for production. Log in as admin with the password you just retrieved. You should land on the Wazuh overview with zero agents reporting – that is your blank canvas.
Step 4 – Secure the Deployment
A SIEM is a high-value target – it holds the logs an attacker most wants to erase. Harden it immediately. First, change the default admin password using the bundled password tool, then restrict network exposure with the firewall. Never expose the indexer (9200) or API (55000) to the public internet; a 2025 advisory (CVE-2025-24016, patched in 4.9.1) showed that an exposed, credentialed API is the realistic attack path against Wazuh itself.
# Rotate the admin password (interactive)
sudo /usr/share/wazuh-indexer/plugins/opensearch-security/tools/wazuh-passwords-tool.sh
--change-all --admin-user admin
# Allow only what agents and analysts need; keep 9200/55000 internal
sudo ufw allow 443/tcp # dashboard
sudo ufw allow 1514/tcp # agent events
sudo ufw allow 1515/tcp # agent enrollment
sudo ufw enable
sudo ufw status numberedFor production, replace the self-signed certificates with ones from your internal CA or a public authority, restrict dashboard access to your management network or VPN, and enable disk encryption on the indexer volume. These three changes turn a lab build into something you can defend during an audit.
Step 5 – Deploy Your First Wazuh Agent (Linux)
With the server live, enroll an endpoint. The cleanest method is to add the Wazuh APT/YUM repository and install the agent with the manager’s IP baked in as a deployment variable, which auto-registers the agent on first start. Run the following on a second Ubuntu or Debian machine, replacing the IP with your server’s address.
# Add the Wazuh repository key and source
curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | sudo gpg --no-default-keyring
--keyring gnupg-ring:/usr/share/keyrings/wazuh.gpg --import
sudo chmod 644 /usr/share/keyrings/wazuh.gpg
echo "deb [signed-by=/usr/share/keyrings/wazuh.gpg] https://packages.wazuh.com/4.x/apt/ stable main"
| sudo tee /etc/apt/sources.list.d/wazuh.list
sudo apt update
# Install the agent pointed at your manager, then start it
sudo WAZUH_MANAGER="10.0.0.5" WAZUH_AGENT_NAME="web-prod-01" apt install -y wazuh-agent
sudo systemctl daemon-reload
sudo systemctl enable --now wazuh-agentBack on the server, confirm the agent is connected. The agent_control binary lists every enrolled endpoint and its status.
sudo /var/ossec/bin/agent_control -lWazuh agent_control. List of available agents:
ID: 000, Name: wazuh-soc-01 (server), IP: 127.0.0.1, Active/Local
ID: 001, Name: web-prod-01, IP: 10.0.0.21, ActiveAn Active status means events are flowing. Refresh the dashboard and your first agent now appears under Agents with a live event count. The agent enrollment documentation covers password-protected and certificate-based registration if you need stronger onboarding controls.
Step 6 – Enroll a Windows Agent
Windows endpoints are where most real-world detections happen, so add one. Open an elevated PowerShell on a Windows 10/11 or Windows Server machine and run the MSI installer with the manager IP and a friendly agent name. The same deployment variables work on Windows.
# Run in an elevated PowerShell session
Invoke-WebRequest -Uri https://packages.wazuh.com/4.x/windows/wazuh-agent-4.14.5-1.msi `
-OutFile $env:tmpwazuh-agent.msi
msiexec.exe /i $env:tmpwazuh-agent.msi /q `
WAZUH_MANAGER="10.0.0.5" WAZUH_AGENT_NAME="win-ep-01"
# Start the service
NET START WazuhSvcThe Windows agent immediately begins forwarding Windows Event Log channels – Security, System, Application, Sysmon if present, and PowerShell operational logs. Within a minute you will see Windows authentication events, service installs, and account changes flowing into the dashboard. This single agent gives you visibility that costs extra in most commercial endpoint products.
Step 7 – Enable File Integrity Monitoring (FIM)
File Integrity Monitoring watches critical directories and alerts when files are created, modified, or deleted – the core of detecting tampering, web shells, and unauthorized changes. It is also an explicit requirement of several compliance regimes. Configure it in the agent’s ossec.conf (or push it centrally from the server) by adding directories to the syscheck block. The realtime="yes" attribute uses inotify on Linux, and since 4.12 Wazuh can use eBPF for lower-overhead who-data monitoring – a path that got faster with 4.14.6 (released July 1, 2026), which updated the underlying eBPF libraries to libbpf 1.7.0 and bpftool 7.7.0.
<!-- /var/ossec/etc/ossec.conf on the monitored endpoint -->
<syscheck>
<disabled>no</disabled>
<frequency>43200</frequency>
<directories check_all="yes" realtime="yes">/etc,/usr/bin,/usr/sbin</directories>
<directories check_all="yes" realtime="yes">/bin,/sbin,/boot</directories>
<directories check_all="yes" realtime="yes" report_changes="yes">/var/www</directories>
<alert_new_files>yes</alert_new_files>
<nodiff>/etc/ssl/private.key</nodiff>
</syscheck>Restart the agent, then test the rule by touching a watched file. Within seconds you should see a FIM alert in the dashboard with the file path, the change type, and a before/after hash. The FIM documentation details tuning options like ignoring noisy paths and capturing the actual content diff with report_changes.
# Generate a test FIM event on the endpoint
echo "test-change-$(date +%s)" | sudo tee -a /etc/hosts
# Watch it arrive on the server
sudo tail -f /var/ossec/logs/alerts/alerts.json | grep -m1 syscheckStep 8 – Turn On Vulnerability Detection
Wazuh’s Vulnerability Detection module inventories the software on every agent and cross-references it against CVE feeds, then writes the results to the indexer so you get a live, searchable list of exposures across your estate – no separate scanner license required. The module was rebuilt in the 4.8 line to use Wazuh’s Cyber Threat Intelligence feed, and 4.12 added direct CTI reference links inside each CVE detail. Enable it on the server in ossec.conf.
<!-- /var/ossec/etc/ossec.conf on the Wazuh server -->
<vulnerability-detection>
<enabled>yes</enabled>
<index-status>yes</index-status>
<feed-update-interval>60m</feed-update-interval>
</vulnerability-detection>Restart the manager. The first feed download and full scan can take several minutes; afterward, open the Vulnerability Detection module in the dashboard and you will see CVEs grouped by severity, with affected package versions and remediation guidance. Sorting by Critical gives you an instant patch priority list. See the vulnerability detection documentation for feed and offline-update options.
sudo systemctl restart wazuh-manager
# Confirm the module loaded without errors
sudo grep -i vulnerability /var/ossec/logs/ossec.log | tail -5Step 9 – Run Security Configuration Assessment (SCA)
Security Configuration Assessment audits each endpoint against hardening benchmarks – Wazuh ships policies aligned to the CIS Benchmarks for common operating systems. SCA is enabled by default; you can tune the scan interval in ossec.conf. The 4.14 line keeps extending benchmark coverage: 4.14.3 (released February 11, 2026) added a CIS SCA policy for macOS 26 Tahoe, and 4.14.2 (released January 14, 2026) added a dedicated SCA policy for Windows Server 2025, on top of the reworked Windows 10 Enterprise policy and the refreshed Linux policy introduced in 4.12.
<sca>
<enabled>yes</enabled>
<scan_on_start>yes</scan_on_start>
<interval>12h</interval>
<skip_nfs>yes</skip_nfs>
</sca>Open the Configuration Assessment module in the dashboard and select an agent to see a pass/fail scorecard: which checks passed, which failed, the exact remediation command for each, and an overall hardening percentage you can track over time. This is the single fastest way to prove and improve your baseline. The SCA documentation explains how to write custom policies for in-house applications.
Step 10 – Collect Logs From Agentless Devices
Not everything can run an agent – firewalls, switches, routers, and many appliances only speak syslog. Wazuh ingests these natively. Add a remote block to the server’s ossec.conf that listens for syslog and restrict it to the source networks you trust, so the SIEM does not become an open log relay.
<remote>
<connection>syslog</connection>
<port>514</port>
<protocol>udp</protocol>
<allowed-ips>10.0.0.0/24</allowed-ips>
</remote>Point your network gear at the Wazuh server on UDP 514, restart the manager, and the events flow through the same decoders and rules as agent data. This is how you bring perimeter and network telemetry into the same correlation engine as your endpoints – a unified view that is the whole point of a SIEM. The log data collection documentation covers parsing custom log formats.
Step 11 – Map Alerts to MITRE ATT&CK
Wazuh’s ruleset is pre-tagged with MITRE ATT&CK technique IDs, so detections automatically map to adversary tactics and techniques. That gives analysts a shared vocabulary and shows coverage gaps at a glance. When you write custom rules, add a <mitre> block so your own detections appear on the ATT&CK matrix too. Custom rules live in /var/ossec/etc/rules/local_rules.xml.
<!-- /var/ossec/etc/rules/local_rules.xml -->
<group name="local,syslog,authentication,">
<rule id="100100" level="10" frequency="6" timeframe="120">
<if_matched_sid>5716</if_matched_sid>
<description>Possible SSH brute-force: 6+ failures in 120s.</description>
<mitre>
<id>T1110</id>
</mitre>
<group>authentication_failures,pci_dss_10.2.4,</group>
</rule>
</group>This rule fires when the built-in SSH-failure rule (5716) matches six times in two minutes, tags it as ATT&CK technique T1110 (Brute Force), and links it to a PCI DSS control. Validate any custom rule with the log tester first; since Wazuh 4.13.0 (September 2025) added hot reload for decoders, rules, and CDB lists, you can usually push it live without a full manager restart, though restarting is still the safest fallback if the change does not take. The MITRE ruleset documentation explains the mapping in detail.
# Test a rule against a sample log line before going live
sudo /var/ossec/bin/wazuh-logtest
# Paste a log line, confirm rule 100100 fires, then:
sudo systemctl restart wazuh-managerStep 12 – Configure Active Response to Auto-Block Attackers
Detection is only half a SOC; response is the other half. Wazuh active response runs a script on the agent or server when a rule of a given level or ID fires. The built-in firewall-drop command blocks the offending IP at the host firewall for a set timeout – turning your brute-force detection from Step 11 into an automatic countermeasure. Add this to the server’s ossec.conf.
<active-response>
<command>firewall-drop</command>
<location>local</location>
<rules_id>100100,5710,5712,5720</rules_id>
<timeout>600</timeout>
</active-response>Now, when an IP trips the brute-force rule, the agent drops it for 600 seconds and Wazuh logs the action – with an automatic rollback when the timeout expires so you do not permanently lock out a fat-fingered admin. Tune the rule IDs and timeout to your risk tolerance, and review the active-response log regularly. Read the active response documentation before enabling automatic blocking in production; an over-eager response can become a self-inflicted denial of service.
# Watch active-response actions as they happen
sudo tail -f /var/ossec/logs/active-responses.logStep 13 – Build Compliance Dashboards (PCI DSS, NIST, HIPAA)
Wazuh ships built-in compliance modules that re-slice your existing alerts against regulatory controls – no extra configuration beyond the capabilities you already enabled. In the dashboard you will find ready-made views for PCI DSS, HIPAA, NIST SP 800-53, GDPR, and the SOC 2 Trust Services Criteria. The mapping below shows how the steps you just completed line up with the controls auditors check.
| Wazuh capability | PCI DSS 4.0.1 | NIST 800-53 / CSF 2.0 | HIPAA Security Rule |
|---|---|---|---|
| Log collection & retention | Req 10.2, 10.5 | AU-2, AU-6 / Detect | §164.312(b) |
| File Integrity Monitoring | Req 10.3.4, 11.5.2 | SI-7 / Protect | §164.312(c)(1) |
| Vulnerability detection | Req 6.3.3, 11.3 | RA-5 / Identify | §164.308(a)(1) |
| Config assessment (SCA/CIS) | Req 2.2 | CM-6 / Protect | §164.308(a)(8) |
| Active response | Req 12.10 | IR-4 / Respond | §164.308(a)(6) |
| MITRE ATT&CK detection | Req 10.4.1 | SI-4 / Detect | §164.308(a)(1)(ii)(D) |
The practical win is evidence on demand. When an assessor asks “show me that you monitor changes to system files,” you open the PCI DSS view, filter to requirement 11.5.2, and export the report. Building that evidence trail manually is what makes commercial compliance tooling expensive; here it is a tab. The NIST Cybersecurity Framework 2.0 functions – Identify, Protect, Detect, Respond, Recover – map almost one-to-one onto the Wazuh capability set.
Step 14 – Set Up Email Alerting and Tune Rules
Finally, make the SOC reach out to you. Configure email notifications in the server’s global block so high-severity alerts hit your inbox, and set a sensible threshold so you are not paged for every low-level event. Level 10 and above is a common starting line for “a human should look at this.”
<global>
<email_notification>yes</email_notification>
<smtp_server>smtp.example.com</smtp_server>
<email_from>[email protected]</email_from>
<email_to>[email protected]</email_to>
<email_maxperhour>12</email_maxperhour>
</global>
<alerts>
<email_alert_level>10</email_alert_level>
</alerts>Restart the manager one last time. From here, tuning is continuous: silence false positives by adjusting rule levels, raise the level of alerts that matter to you, and add custom decoders for in-house apps. A well-tuned Wazuh deployment surfaces a handful of high-signal alerts a day instead of thousands of meaningless ones – and that signal-to-noise ratio is what actually shortens the 241-day detection window.
Complete Working Project: A 50-Endpoint SOC Blueprint
Put the 14 steps together and you have a complete, repeatable project: a self-hosted security operations center for a mid-sized environment. Here is the blueprint many teams settle on after the first month.
- One Wazuh 4.14.5 server (8 vCPU, 8–16 GB RAM, 200 GB SSD) running manager, indexer, and dashboard, firewalled so only 443/1514/1515 are externally reachable.
- Agents on every server, workstation, and cloud instance – roughly 50 endpoints – each running FIM, SCA, and vulnerability inventory.
- Syslog ingestion from the firewall, switches, and any appliance that cannot host an agent.
- Custom rules in
local_rules.xmlfor your crown-jewel applications, each tagged with MITRE technique IDs. - Active response auto-blocking brute-force and known-bad IPs with short, self-reverting timeouts.
- Compliance dashboards for the one or two frameworks that apply to you, exported on a schedule for auditors.
- Email alerting at level 10+ feeding a shared inbox or chat webhook, plus a daily review of the vulnerability and SCA scorecards.
That stack replaces what would otherwise be three or four separate paid products – log management, FIM, a vulnerability scanner, and a compliance reporter – with one open-source platform. The recurring cost is the server and the analyst time to tune it, not a per-gigabyte invoice that grows every time your logs do.
6 Common Pitfalls When Deploying Wazuh
These are the mistakes that send first-time Wazuh installs sideways. Avoiding them saves the most painful debugging.
- Undersizing RAM. The OpenSearch-based indexer wants a JVM heap; on a 2 GB host it will OOM-kill mid-scan. Treat 8 GB as the floor for anything beyond a tiny lab, and never let the heap exceed half of system RAM.
- Clock drift. If the server and agents disagree on the time, correlation breaks and alerts land in the wrong window. Enforce NTP/timesyncd everywhere before you onboard agents.
- Exposing the indexer or API to the internet. Ports 9200 and 55000 belong on an internal segment only. The one notable Wazuh CVE (CVE-2025-24016) required an exposed, credentialed API – keep it private and you sidestep that entire class of risk.
- Forgetting to open agent ports. A firewall that blocks 1514/1515 leaves agents stuck in “Never connected.” Open them deliberately and verify with
agent_control -l. - Over-aggressive active response. Auto-blocking on a noisy rule can lock out legitimate users or even your own monitoring. Start with a narrow rule list and a short timeout, then widen.
- Never tuning the ruleset. Out of the box Wazuh is chatty. If you do not silence false positives and raise the levels that matter, alert fatigue sets in and real detections get missed.
Troubleshooting: 8 Wazuh Errors and Fixes
When something breaks, the logs at /var/ossec/logs/ossec.log (server and agent) tell you almost everything. The table below maps the eight problems you are most likely to hit to their cause and fix.
| Symptom | Likely cause | Fix |
|---|---|---|
| Installer aborts mid-run | Unsupported OS or leftover packages | Re-run with sudo bash ./wazuh-install.sh -a -o to overwrite, on a supported, clean OS |
| Dashboard shows 502 / won’t load | Indexer not fully started | systemctl status wazuh-indexer; wait for green, then restart the dashboard |
| Agent stuck “Never connected” | Firewall blocking 1514/1515 | Open the ports on the server; confirm with agent_control -l |
| Agent “Disconnected” after a while | Manager IP wrong or NAT/keepalive issue | Check WAZUH_MANAGER in agent ossec.conf; verify reachability |
| No FIM alerts on file change | syscheck disabled or wrong path | Confirm the <directories> path and realtime="yes"; restart the agent |
| Vulnerability module empty | Feed not downloaded / indexer link down | Restart manager; grep ossec.log for feed errors; check indexer connectivity |
| “agent already exists” on enroll | Duplicate name from a reinstall | Remove the stale entry with manage_agents, then re-enroll |
| Out-of-memory / indexer crash | Heap too large or host too small | Cap the JVM heap at ~50% of RAM; add memory or split nodes |
One universal first move: check service health with sudo /var/ossec/bin/wazuh-control status on the server and tail the relevant log. Most “Wazuh is broken” tickets resolve to a stopped service or a blocked port.
Advanced Tips: Scaling, the API, and Wazuh 5.0
Once the basics are solid, three moves take a Wazuh deployment from “running” to “production-grade.” First, automate with the API on port 55000. Everything in the dashboard is also a REST call, so you can script agent onboarding, pull agent inventories into a CMDB, or build custom reports. Authenticate, then query.
# Get a JWT, then list all agents via the API
TOKEN=$(curl -s -u wazuh-wui:<password> -k -X POST
"https://localhost:55000/security/user/authenticate?raw=true")
curl -s -k -X GET "https://localhost:55000/agents?pretty=true&select=name,ip,status"
-H "Authorization: Bearer $TOKEN"Second, plan for scale. A single node comfortably handles up to roughly 100 agents; past that, separate the indexer, server, and dashboard onto their own hosts and run a multi-node indexer cluster for resilience and search performance. Third, watch the Wazuh 5.0 release. Wazuh 5.0.0-beta1 landed in April 2026 with a rewritten agent communication protocol and a new indexer, and 5.0.0-beta2 followed in May 2026; independent release tracker MacSouverain had penciled in general availability for late June to July 2026, but as of this writing in mid-August 2026 that window has come and gone and 5.0 remains in public beta. The big architectural changes: clustering becomes the default, the Filebeat dependency is removed in favor of a native indexer connector, role-based access control is overhauled, and threat-intel coverage expands to indicators of compromise. The upgrade path from 4.14 will be supported – but because indexer upgrades are one-way, stay on stable 4.14.7 in production until 5.0 reaches GA, then test the migration in a lab first.
Wazuh vs Commercial SIEMs: Cost and Capability
The reason this tutorial matters is the economics. Commercial SIEMs are powerful but priced on the very thing a SIEM produces – data. The table below compares licensing models, not specific quotes (which vary wildly by contract), so you can see where Wazuh’s flat, infrastructure-only cost structure fits.
| Platform | Licensing model | License cost | FIM / SCA / vuln built in? | Self-hosted |
|---|---|---|---|---|
| Wazuh 4.14.5 | Open source (GPLv2 core) | $0 (pay only for infra) | Yes – all included | Yes |
| Splunk Enterprise Security | Per-GB ingest or workload-based | Subscription, scales with data | Mostly via add-ons | Yes / cloud |
| Microsoft Sentinel | Per-GB ingested (Azure) | Usage-based | Via connectors | Cloud only |
| IBM QRadar | Events/sec or per-GB | Subscription | Partly | Yes / cloud |
| Elastic Security | Resource-based subscription | Tiered subscription | Via integrations | Yes / cloud |
Wazuh is not a drop-in replacement for a managed, vendor-supported SIEM with a 24/7 SOC behind it – that trade-off is real, and large enterprises often run both. But for the vast majority of teams that need credible detection, FIM, vulnerability visibility, and compliance evidence without an unpredictable per-gigabyte bill, a self-hosted Wazuh deployment delivers the capability at the cost of hardware and attention. Given that the average U.S. breach now runs $10.22 million, the return on a weekend of setup is hard to argue with.
Frequently Asked Questions
Is Wazuh really free, or is there a paid tier?
The Wazuh platform is genuinely free and open source – the core engine is GPLv2 and the indexer and dashboard are built on Apache-2.0 OpenSearch. There is no paid “enterprise edition” gating features; every capability in this guide is included. Wazuh Inc. monetizes through an optional Wazuh Cloud managed service and professional support, but self-hosting is fully featured at zero license cost.
What is the difference between Wazuh and OSSEC?
Wazuh began as a fork of OSSEC in 2015 and has since become a far broader platform. OSSEC is a host-based intrusion detection system; Wazuh keeps that foundation but adds a scalable OpenSearch indexer, a modern web dashboard, vulnerability detection, security configuration assessment, MITRE ATT&CK mapping, cloud integrations, and ready-made compliance modules. If you are starting fresh in 2026, Wazuh is the actively developed successor.
How many resources does a Wazuh server need?
For a lab, 2 vCPU and 4 GB RAM is the bare minimum. For production, plan on 4–8 vCPU and at least 8 GB RAM, because the indexer needs a healthy JVM heap. Storage scales with how many agents you run and how long you retain logs – budget 50 GB for a small estate and 200 GB or more for 50–100 agents with a 90-day window. SSD storage makes a large difference to dashboard responsiveness.
Should I install Wazuh 5.0 or stay on 4.14?
As of September 29, 2026, Wazuh 5.0 is still in beta – beta1 arrived in April 2026 and beta2 followed in May 2026, with tracker MacSouverain’s projected stable release window of late June to July 2026 having already slipped – so production deployments should use the current stable release, 4.14.8, which launched September 23, 2026 and is the newest release listed in Wazuh’s own documentation, succeeding 4.14.7 (confirmed current by Wazuh’s documentation, Patchletter, and GitHub’s “Latest” tag on July 29–30, 2026). It caps a fast-moving 4.14.x line that has shipped a new point release roughly every month, from 4.14.0 in October 2025 (not long after 4.13.1 held the “Latest” GitHub tag) through 4.14.7 in July 2026 and now 4.14.8 in September 2026. Wazuh 5.0 brings clustering by default, a rewritten agent communication protocol, a new indexer, removal of the Filebeat dependency, an overhauled RBAC system, and expanded threat intelligence. When it reaches general availability, test the upgrade in a lab first, since indexer upgrades cannot be rolled back.
Can Wazuh monitor Windows, macOS, and cloud workloads?
Yes. The Wazuh agent runs on Linux, Windows 7 through 11 and Windows Server, macOS 10.14+, plus Solaris, AIX, and HP-UX. For cloud, Wazuh integrates with AWS, Azure, Google Cloud, and Microsoft 365 to pull service and audit logs – Wazuh 4.14.0 (October 2025) added a dedicated Microsoft Graph API dashboard for that Microsoft 365 telemetry, and the Azure integration itself was refreshed in 4.14.4 (released March 17, 2026), which updated the underlying azure-core library to 1.38.0 – and the central components themselves run on ARM64. A single Wazuh server can monitor a mixed fleet of all of these at once.
Does Wazuh help with PCI DSS, HIPAA, and SOC 2 compliance?
It does, and that is one of its strongest selling points. Wazuh ships built-in dashboards mapped to PCI DSS, HIPAA, NIST SP 800-53, GDPR, and the SOC 2 Trust Services Criteria. The log collection, file integrity monitoring, vulnerability detection, and configuration assessment you enable in this guide directly satisfy specific controls – for example, PCI DSS 4.0.1 requirements 10.3.4 and 11.5.2 for change detection. You still need policies and process, but Wazuh produces the technical evidence on demand.
How long does a full Wazuh deployment take?
The all-in-one installer brings up a working server in 8–15 minutes on a correctly sized host. Enrolling your first agent and logging in adds another 15–20 minutes, so you can have a live SIEM in well under an hour. Switching on every capability – FIM, vulnerability detection, SCA, syslog, active response, and compliance dashboards – and tuning the ruleset typically adds another one to two hours for a first deployment.
What happens if an attacker tries to delete the logs?
This is exactly why a SIEM ships logs off the endpoint in near real time. Once an event reaches the Wazuh indexer it is stored centrally, so even if an attacker wipes a compromised host’s local logs, the evidence already lives on the server. Combine that with file integrity monitoring on log directories and restricted access to the indexer, and you have a tamper-evident record – one of the core reasons compliance frameworks mandate centralized logging in the first place.
Related Coverage
- Fail2ban: Stop SSH Brute-Force in 12 Steps, 30 Min [2026] – host-level intrusion prevention that pairs perfectly with a Wazuh SIEM.
- ShinyHunters Hit 100+ Orgs via Oracle Zero-Day [2026] – the kind of intrusion centralized monitoring is built to catch early.
- Canvas LMS Breach: 275M Records, 9K Schools Hit [2026] – a breach where faster detection would have changed the outcome.
- Bitdefender vs Norton vs McAfee 2026: 2 Win Gold, 1 Bronze – endpoint protection that complements Wazuh’s agent telemetry.
- ECS vs EKS vs Fargate: $0 vs $73/mo Control Plane [2026] – the cloud workloads your Wazuh agents will monitor.
- More cybersecurity guides and threat coverage – the full Tech Insider security hub.
Last updated August 16, 2026. Versions and figures reflect Wazuh 4.14.7 (stable, released July 29, 2026) and the Wazuh 5.0 beta as of publication – consistent with Tech Insider’s own platform comparison published in August 2026, which likewise lists 4.14.7 as the current release; verify the current release on the official Wazuh documentation before deploying.
