If your threat detection strategy is "wait for the SOC vendor to email us," you don't have one. You have a hope. I've watched a mid-size SaaS company pay six figures a year for a commercial SIEM and still miss a compromised WordPress plugin for eleven days — because the detection rules that would have caught it were behind a premium content pack nobody bought. Meanwhile, a two-node Wazuh cluster on hardware they already owned flagged the same class of behavior in under four minutes. That's the entire pitch: detection coverage is a function of rules and telemetry, not licensing.
This guide is for engineers who already know what a SIEM is and are tired of the "just use the Docker compose, it's easy" blog posts that fall apart the moment you point 200 production agents at them. By the end you'll be able to size a distributed Wazuh deployment, install it without painting yourself into a corner, write and tune detection rules that don't drown your on-call, scope FIM so it doesn't melt your manager, set retention on day one, and route alerts to humans who will actually act on them.
:::note[TL;DR]
- Wazuh is a detection platform — HIDS, FIM, SCA, log analysis, and vulnerability detection in one stack. It is not a detection strategy; you still have to tune it.
- Skip the all-in-one VM for anything real. Distributed Manager/Indexer/Dashboard is the only topology that survives contact with production.
- The OpenSearch fork dependency is the biggest operational liability — plan your index lifecycle and upgrade path before you install.
- Tune rules or die. Out-of-the-box Wazuh will happily generate 10k alerts a day and teach your team to ignore all of them. :::
Prerequisites
- Two or more Linux hosts (Ubuntu 22.04 LTS or RHEL/Rocky 9 recommended) with static addresses and a management VLAN.
- Root or sudo on all nodes. Wazuh's manager runs privileged daemons that read system logs — treat it accordingly.
- A DNS name for the dashboard and API, plus a decision on TLS (self-signed certs from the installer are fine to start, not fine forever).
- Working knowledge of
systemd,firewalld/nftables, and OpenSearch basics. If you've never tuned a JVM heap, read the sizing section twice. - Roughly 8 GB RAM minimum for a lab; 32 GB+ per indexer node for production. More on that below.
What Wazuh Actually Is (And Isn't)
Wazuh is four things bolted together: a manager (the rule engine and agent coordinator), an indexer (an OpenSearch fork that stores alerts), a dashboard (a Kibana fork), and agents (the shippers on your hosts). The data flow is strictly one direction — agents talk to the manager on 1514/tcp, the manager forwards alerts to the indexer via Filebeat, and the dashboard reads from the indexer. If you understand that pipeline, you understand 80% of Wazuh's operational behavior.
[Agent] --1514/tcp--> [Manager] --Filebeat--> [Indexer] <-- [Dashboard]
| | (1515 enrollment) | (443)
| | |
syscheck, rules/decoders, wazuh-alerts-*
logcollector, vulnerability feed, wazuh-archives-*
SCA, rootcheck integratord
⚠️ TRUNCATED VERSION
This is an abbreviated cross-post. Full article (all config files, architecture diagrams, images): valtersit.com
🛠️ Partner Tools for Developers
ValtersIT curates partner deals for developers and sysadmins — VPS hosting, security tools, monitoring platforms and dev productivity gear. No filler, no affiliate spam.
Top comments (0)