Wazuh, Open-Source XDR and SIEM for When Grep Isn't a Security Strategy Anymore

You’ve got a handful of servers, maybe a VPS or two running something that matters, and when something looks off you SSH in and grep the logs for a suspicious IP or an error message that keeps repeating. That works fine as long as you’re the only one watching and the machine count fits on one hand. Then infrastructure grows: more servers, maybe a client asking for a security audit or a compliance requirement (PCI DSS, GDPR, HIPAA) that wants actual proof you’re monitoring file integrity, detecting intrusions, and keeping centrally analyzed logs, not just scattered text files on each box. At that point, manual grepping stops being a security strategy and becomes luck that hasn’t run out yet.

Wazuh (repo at github.com/wazuh/wazuh , official site wazuh.com ) is built for exactly that jump: an open-source platform, licensed under GPLv2, that combines XDR (Extended Detection and Response) with SIEM (Security Information and Event Management) in a single stack. For organizations that need centralized log analysis and file integrity monitoring across a fleet of servers, Wazuh is one of the strongest open-source options available today, not because it’s the only one, but because it realistically covers the whole cycle: telemetry collection, detection, correlation against known frameworks, alerting, and compliance reporting.

What Wazuh actually is

At its core, Wazuh works with lightweight agents installed on endpoints and servers, which collect telemetry (system and application logs, system calls, file changes, software inventory) and forward it to a central Wazuh server. There, the data gets decoded, matched against a ruleset, and turned into meaningful alerts instead of raw lines of text. Around that core sits an indexer, built on OpenSearch, which stores and indexes the full data volume, and a dashboard, built on OpenSearch Dashboards, where you search, visualize, and configure alerting.

Why centralizing security telemetry beats eyeballing individual server logs

When you have a single server, reading logs by hand is a perfectly reasonable approach. The problem shows up at scale: an attacker moving laterally across a network leaves fragmented traces on multiple machines, traces that look harmless in isolation but make sense only once lined up on a single timeline. Log rotation deletes evidence before you notice it, and an auditor asking for proof that you monitor a configuration file’s integrity won’t settle for “I check every now and then.” Centralizing security telemetry gives you one ruleset applied consistently, one timeline of events, and one place where alerts show up, regardless of which of your 20 or 200 machines something happened on.

From OSSEC to a full XDR/SIEM stack

Wazuh has roots in the OSSEC lineage, an older tool focused almost entirely on log analysis and rule-based intrusion detection, running as a fairly simple binary alongside an agent. Real security needs at an organization don’t stop at “alert me when a suspicious word shows up in a log,” though: you also need correlation against known vulnerabilities, compliance reporting, a searchable dashboard for the security team, and a way to place each detection in the context of a known attack tactic or technique. That’s the need that produced today’s stack: Wazuh grew from a log-based detection engine into a full XDR/SIEM platform, with its own indexer and dashboard.

What you get out of the box

A base Wazuh install isn’t a single feature, it’s a bundle of capabilities that, taken together, cover most of an operational security program’s requirements:

• Agents for endpoints and servers: lightweight processes installed on every monitored machine, collecting logs, system events, and inventory data.
• File Integrity Monitoring (FIM): tracking changes to content, permissions, ownership, and attributes for the files and directories you flag as important.
• Log analysis engine: decoders and rules that turn raw text from logs into classified, prioritized events and alerts.
• Intrusion and rootkit detection: looking for hidden files, cloaked processes, unregistered network listeners, and inconsistencies in system call responses.
• Vulnerability detection: the software inventory collected by agents is checked against continuously updated CVE databases, so you find out which installed packages have known vulnerabilities.
• Configuration assessment and compliance: periodic scans that compare system settings against hardening guides, mapped to standards like PCI DSS, GDPR, and HIPAA.
• MITRE ATT&CK mapping: relevant detections can be tied to a known attack tactic or technique, giving you immediate context instead of just an alert title.
• Indexer and dashboard: OpenSearch for storage and search, plus a web interface for visualization and alerting configuration.

Not every organization needs all of this at once, but Wazuh’s real value comes from these pieces working together, rather than as separate tools you have to glue together yourself.

Installing Wazuh on a VPS

Wazuh isn’t a single binary you start and forget. It’s a multi-component stack (server, indexer, dashboard) plus agents deployed separately on every monitored machine. The most practical way to stand it up on a VPS is a docker compose setup that starts the three central services in an isolated network:

git clone https://github.com/wazuh/wazuh-docker.git -b v4.9.0
cd wazuh-docker/single-node

# generate the internal certificates used between components
docker compose -f generate-indexer-certs.yml run --rm generator

# start the stack: wazuh-manager, wazuh-indexer, wazuh-dashboard
docker compose up -d

# check that every container is healthy
docker compose ps

That brings up the central server, the indexer, and the dashboard on the same VPS. The agent, however, gets installed separately, on every machine you want to monitor (including, if you want, the VPS running the server itself), configured to report to the Wazuh server’s IP address.

Once the stack is up, you still need to open the right ports in the firewall. The dashboard is served over HTTPS, and the server listens on separate ports for agent registration and ongoing communication:

# access to the web dashboard (HTTPS)
sudo ufw allow 443/tcp

# registration of new agents
sudo ufw allow 1515/tcp

# ongoing agent -> server communication
sudo ufw allow 1514/tcp

# Wazuh server API (optional, for automation)
sudo ufw allow 55000/tcp

Because this is a multi-service stack, sizing the VPS matters a lot more than it would for a simple command-line utility: the indexer, being built on OpenSearch, wants real memory, and CPU and disk usage scale directly with the number of agents and the volume of ingested logs. A VPS undersized for a few dozen agents quickly becomes the point where the dashboard starts lagging and indexing falls behind.

Configuration patterns worth knowing

Tuning FIM to watch the right paths, not the whole filesystem

The initial temptation is to point File Integrity Monitoring at everything: /etc, /usr/bin, /var/www, maybe even all of /home. The result is an alert volume where the real signal (an unexpected change to a critical configuration file) gets buried in normal noise (a deploy rewriting dozens of files every day). It’s worth starting narrow: system configuration paths, critical binaries, authentication files, expanding the list gradually as you learn what’s normal in your environment.

Picking and writing decoders and rules for your actual log sources

Wazuh ships with a generous set of decoders and rules for common software (nginx, sshd, base system logs), but any internal application or less common stack needs its own decoders to turn logs into useful events. The time invested here is what separates a SIEM that actually tells you something concrete from one that just archives text nobody reads.

Using compliance mappings as a starting checklist, not a certification

The mappings to PCI DSS, GDPR, or HIPAA are useful as an initial checklist and as evidence for auditors that you have an active monitoring process, but they don’t replace an actual compliance audit performed by someone qualified. Treat them as a solid starting point, not a permanently checked box.

Sizing the indexer for your real log volume and retention needs

OpenSearch, the engine behind the indexer, is the component that feels the growth in agent count and log volume the hardest. The retention period you choose (how many days or months you keep indexed data) multiplied by daily event volume gives you your disk requirement directly, and searches over a poorly sharded, large dataset get slow fast. Think about retention and sharding from day one, not after the indexer starts gasping for air.

Where Wazuh is not the right answer

Honestly, Wazuh is overkill for a single small VPS or a handful of personal projects. A stack with a server, an indexer, and a dashboard, each with its own memory and CPU requirements, is a lot heavier than a single tool quietly running in the background. If all you have is one machine and you just want to know when someone’s trying to brute-force SSH, there are much lighter tools built for exactly that need.

Wazuh’s real value only shows up once you have enough hosts and log volume to justify a centralized platform, and an actual security or compliance need that requires proof, not just “I check the logs sometimes.” On top of that, a SIEM doesn’t run itself: it needs ongoing rule tuning and someone who actually looks at the alerts, or it turns into exactly the kind of noise you install and then ignore. A Wazuh instance set up and forgotten is worse than no Wazuh at all, because it gives a false sense of security.

Alternatives we considered

Wazuh isn’t the only option, and the right choice depends a lot on scale and actual need:

• CrowdSec : a behavior-based IPS, much lighter than Wazuh, well suited to smaller setups where you want automatic detection and blocking of common attacks (brute-force, scanning) without standing up a full analysis and indexing stack.
• Elastic Stack / Elastic Security : a DIY SIEM approach, where you build the pieces yourself (ingestion, indexing, rules, visualization) using Elastic’s components. More flexibility, but also more integration work.
• Graylog : a lighter-weight alternative, focused on log management rather than a full security bundle with FIM, vulnerability detection, and compliance mappings included from the start.

If the real need is automatically blocking common attacks on a few servers, CrowdSec is probably enough. If you already have a compliance requirement and a serious fleet of servers, Wazuh gives you more out of the box.

So, should you run it?

Wazuh is the right tool once you already have real infrastructure to monitor, an actual security or compliance requirement, and the resources (human and server) to keep it tuned and actually watched. It’s not the right tool for a hobby VPS or a two-machine personal project, where the weight of the stack doesn’t pay for itself.

If you’re in the camp where Wazuh genuinely makes sense, the first practical step is a VPS properly sized for the indexer and server, not leftover resources scraped together from other services. And because this is a stack that needs continuous tuning, not just an initial install, professional server administration is often worth investing in from day one, instead of discovering mid-incident that nobody’s looked at the dashboard in three months.