Wazuh: A SIEM You Can Actually Run at Home

Here is an uncomfortable question to ask yourself about your own homelab: if someone got a shell on one of your boxes six weeks ago, how would you know today? Most honest answers are some variant of “I’d notice the CPU fan”. Which is to say: you would not know, unless the intruder was clumsy enough to start mining crypto badly.

That gap is the reason SIEM exists as a product category. Security Information and Event Management is a mouthful that means one modest idea — pull the logs and system state from every machine into one place, run rules against them, and raise something a human can read when the rules trip. The commercial versions of that idea cost more per year than my entire rack cost to build, and they are priced per gigabyte ingested, which is a pricing model apparently designed to punish you for having good logging.

Wazuh is the open-source answer. It is a fork of OSSEC that grew a real correlation engine, an OpenSearch-based indexer, and a dashboard, and it is free in the way that matters: no node limits, no ingest tiers, no feature gates on the security-relevant parts. I looked at whether it is worth the RAM back in January and came away cautiously positive. Six months of running it in earnest have sharpened that into something more specific, including one loud reservation.

What Wazuh actually does, before you install anything

Wazuh’s marketing lists about fifteen capabilities. Four of them justify the install, and the rest are bonus.

File integrity monitoring. An agent hashes the files you tell it to watch and raises an alert when one changes. Point it at /etc, /usr/bin, /usr/sbin and the web roots, and you have a tripwire on every persistence mechanism a lazy attacker uses. This is the single highest-value thing in the product, and it is the thing nothing else in a normal homelab stack does at all.

Log analysis with decoders and rules. The agent ships log lines, the manager decodes them into fields, and rules match against fields. Rules have levels from 0 to 16 and can reference other rules, which is how correlation happens: “rule 5710 (failed SSH) firing eight times in 120 seconds from one source” becomes rule 5712 at level 10.

Rootcheck and SCA. Policy scans against CIS benchmarks that tell you your SSH config allows password auth and your kernel has net.ipv4.ip_forward on. Genuinely useful the first time you run it, mostly noise afterwards. It overlaps heavily with what Lynis gives you for free in one binary, and Lynis needs no infrastructure.

Vulnerability detection. The agent inventories installed packages, the manager cross-references them against CVE feeds, and you get a list of what on your boxes is known-broken. This works well and is a legitimate reason to run the thing.

Everything else — the MITRE ATT&CK mapping, the compliance dashboards for PCI DSS and GDPR, the cloud connectors — is enterprise furniture. It does no harm sitting there, and it is decoration in a house with three machines in it.

Installing without hating yourself

The all-in-one installer works, and it is the right call for a homelab. Do not build a distributed cluster on three nodes to feel professional about it.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

$ curl -sO https://packages.wazuh.com/4.12/wazuh-install.sh
$ bash ./wazuh-install.sh -a -i

19/07/2025 10:14:02 INFO: Starting Wazuh installation assistant.
19/07/2025 10:14:02 INFO: Verifying that your system meets the recommended requirements.
19/07/2025 10:18:44 INFO: Wazuh indexer cluster initialized.
19/07/2025 10:21:03 INFO: Starting service wazuh-dashboard.
19/07/2025 10:21:39 INFO: You can access the web interface https://<wazuh-dashboard-ip>
    User: admin
    Password: <generated>
19/07/2025 10:21:39 INFO: Installation finished.

That is three processes on one box: wazuh-manager (the brain), wazuh-indexer (OpenSearch, the storage), and wazuh-dashboard (OpenSearch Dashboards, the face). The indexer is where all your RAM went. Give the whole thing 8 GB and a dedicated VM; 4 GB technically boots and then the JVM spends its life in garbage collection while you wonder why the dashboard times out.

Agents install per machine and register against the manager:

1
2
3
4
5
6
7
8
9

$ WAZUH_MANAGER='192.168.1.20' apt install wazuh-agent
$ systemctl enable --now wazuh-agent

$ /var/ossec/bin/agent_control -l
Wazuh agent_control. List of available agents:
   ID: 000, Name: siem.mylab.local (server), IP: 127.0.0.1, Active/Local
   ID: 001, Name: docker01, IP: any, Active
   ID: 002, Name: nas01, IP: any, Active
   ID: 003, Name: edge01, IP: any, Active

The agent is a C program in about 40 MB of RAM. It is genuinely lightweight, and it is the one part of Wazuh I have no complaints about at all.

The configuration that actually matters

Default Wazuh is loud. Out of the box you will get thousands of level-3 events a day telling you cron ran and a user logged in. The first week is spent making it quiet enough to be worth reading, and the file where that happens is /var/ossec/etc/ossec.conf on the manager, plus local_rules.xml for your overrides.

File integrity monitoring wants real-time on the directories that matter and scheduled scans on the ones that do not:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

<syscheck>
  <disabled>no</disabled>
  <frequency>43200</frequency>
  <scan_on_start>yes</scan_on_start>

  <!-- Real-time on the persistence targets. Costs inotify watches. -->
  <directories check_all="yes" realtime="yes">/etc,/usr/bin,/usr/sbin</directories>
  <directories check_all="yes" realtime="yes">/root/.ssh,/home/*/.ssh</directories>

  <!-- Twice a day is plenty for bulk binaries -->
  <directories check_all="yes">/bin,/sbin,/boot</directories>

  <!-- The noise generators. Ignore aggressively or drown. -->
  <ignore>/etc/mtab</ignore>
  <ignore>/etc/resolv.conf</ignore>
  <ignore>/etc/adjtime</ignore>
  <ignore type="sregex">.log$|.tmp$|.swp$</ignore>
</syscheck>

Silencing rules you have judged irrelevant goes in local_rules.xml, and the crucial habit is writing why in a comment, because in four months you will not remember:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

<group name="local,syslog,">
  <!-- Backup job runs as root via cron at 0300 and trips 5402 nightly.
       Expected. Silenced 2025-07-08 after verifying the crontab. -->
  <rule id="100010" level="0">
    <if_sid>5402</if_sid>
    <match>backup-runner</match>
    <description>Backup job sudo - expected, silenced</description>
  </rule>

  <!-- Escalate: FIM change under /etc on the edge box is never routine -->
  <rule id="100020" level="12">
    <if_sid>550,554</if_sid>
    <field name="agent.name">edge01</field>
    <description>File change on edge firewall host - investigate</description>
  </rule>
</group>

Level 0 means “decode it, store it, never alert”. Level 12 means “wake me”. That second rule is the entire point of a SIEM: the same event means different things on different machines, and a correlation engine is where you encode that judgement.

Alerting outward needs <command> and <active-response> blocks, or an integration. I push level-10-and-above to a self-hosted push endpoint rather than email, because email alerts get filtered into a folder and die there.

What a real alert looks like

Abstract talk about correlation engines is easy to nod along to and hard to evaluate. Here is an actual chain from my own logs, lightly genericised, because it shows what the machinery buys you over grepping.

A scan hit the edge box. Wazuh’s decoder turned each failed SSH line into fields, rule 5710 fired per attempt at level 5, and eight of those inside two minutes rolled up into rule 5712 at level 10:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

$ tail -f /var/ossec/logs/alerts/alerts.log

** Alert 1752398841.2291043: - syslog,sshd,authentication_failures,
2025 Jul 13 09:07:21 edge01->/var/log/auth.log
Rule: 5712 (level 10) -> 'SSHD brute force trying to get access to the system.'
Src IP: 203.0.113.77
2025 Jul 13 09:07:19 edge01 sshd[4412]: Failed password for invalid user
    admin from 203.0.113.77 port 51422 ssh2

** Alert 1752398903.2291810: - ossec,syscheck,
2025 Jul 13 09:08:23 edge01->syscheck
Rule: 550 (level 7) -> 'Integrity checksum changed.'
File '/etc/ssh/sshd_config' checksum changed.
Old md5sum was: '4f8a2c1e9b3d7a5f2e1c8b4d6a9f3e7c'
New md5sum is : 'a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6'
Old modification time was: 'Sat Mar 15 11:02:14 2025',
    now it is 'Sun Jul 13 09:08:19 2025'

The first alert is noise. Something on the internet tried eight passwords against a box with password authentication disabled and achieved nothing. Rule 5712 fires on my edge host several times a week and I ignore it completely.

The second alert is the one that matters, and it landed sixty-two seconds later. sshd_config changed on a host where I had made no change. In that instance it was an unattended-upgrades run rewriting the file after a package update, which I confirmed inside a minute by reading the apt history — dull, and exactly the dullness you want. But notice the shape of what happened: the tool told me, unprompted, that a security-critical file on an internet-facing machine had been modified, and it told me a minute after it happened rather than during an incident review in November.

That is the capability. No amount of grep on auth.log produces the second alert, because the second alert has nothing to do with logs. It comes from an agent hashing files on a schedule and noticing arithmetic that changed.

The RAM problem, stated honestly

This is where I stop being nice about it. On my box, steady state with four agents:

Five gigabytes to watch four machines. The indexer is OpenSearch, and OpenSearch was designed for clusters ingesting terabytes; running it to hold 3 GB of alerts is using a shipping crane to move a bicycle. There is no supported way to swap it for something smaller, and the dashboard is welded to it.

Compare that to Loki holding logs for the same four machines in about 300 MB. Loki does less — no FIM, no CVE feed, no correlation engine — and it does that less for one-seventeenth of the memory. If your machine has 16 GB and hosts other things, Wazuh will take a third of it and you will feel that every time something else needs to grow.

Retention is the other tax. Alerts land in daily indices and stay forever unless you tell them otherwise. Set an ISM policy on day one:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

$ curl -k -u admin:$PW -X PUT "https://localhost:9200/_plugins/_ism/policies/wazuh-retention" \
  -H 'Content-Type: application/json' -d '{
  "policy": {
    "description": "Delete Wazuh alert indices after 90 days",
    "default_state": "hot",
    "states": [
      {"name": "hot", "transitions": [{"state_name": "delete",
        "conditions": {"min_index_age": "90d"}}]},
      {"name": "delete", "actions": [{"delete": {}}], "transitions": []}
    ],
    "ism_template": [{"index_patterns": ["wazuh-alerts-*"], "priority": 100}]
  }}'

Skip that and the disk fills, the indexer goes read-only at the 95% flood-stage watermark, and every agent silently stops reporting. Which brings us neatly to the failure modes.

The habit that decides whether it was worth it

Every piece of security tooling has a hidden requirement that the documentation never lists, and for a SIEM it is this: someone has to look at it. Wazuh generates a dashboard. The control is a human forming a judgement, and the software’s only job is making that judgement possible.

The homelab failure pattern is completely predictable. You install it in a burst of enthusiasm, you tune the noise for a fortnight, you check the dashboard daily for a month, and then you stop. Six months later it is a VM eating 5 GB that nobody has opened since spring. It is worse than nothing at that point, because you believe you have monitoring and you have a decoration.

What has worked for me is refusing to rely on the dashboard at all. The dashboard is for investigating something after I already know it happened. The thing that makes Wazuh survive is a small number of alerts that arrive somewhere I cannot ignore — a push notification on my phone, from a rule I wrote deliberately, for an event I have decided in advance is worth interrupting my evening.

That list is short and it should be short. File integrity change on an internet-facing host. A new user account created anywhere. A successful SSH login from an address outside my own networks. Sudo by an account that should never use sudo. Four rules. Everything else lands in the index, waits, and gets queried when I have a reason.

The discipline is that every one of those four must be genuinely rare. An alert that fires weekly becomes wallpaper within a month and you will start swiping it away without reading. If a rule fires and the answer is “oh, that is just the backup job”, the rule is wrong and you fix it that day. An alert you have learned to dismiss is worse than no alert, because it costs attention and returns nothing.

Get that right and the RAM argument mostly evaporates.

Troubleshooting

“Agents show Never connected.” The manager listens on 1514/TCP for agent traffic and 1515/TCP for enrolment. Enrolment happens once and people forget to open it. Check /var/ossec/logs/ossec.log on the agent — Unable to connect to enrollment service means 1515 is blocked; Unable to connect to '192.168.1.20:1514' means the agent enrolled fine and the data port is shut.

“The dashboard is empty but agents are Active.” Almost always the indexer refusing writes. Check it directly:

1
2
3
4
5
6

$ curl -k -u admin:$PW https://localhost:9200/_cluster/health?pretty
{
  "status" : "red",
  "number_of_nodes" : 1,
  "active_shards_percent_as_number" : 62.5
}

Red with a single node usually means the disk watermark tripped. Free space, then clear the read-only block that OpenSearch set: PUT /_all/_settings {"index.blocks.read_only_allow_delete": null}.

“FIM is eating the CPU.” You pointed realtime="yes" at a directory with a hundred thousand files, and inotify watches are per-file. Check sysctl fs.inotify.max_user_watches — the agent silently degrades to scheduled scanning when it runs out, so you get the CPU cost without the real-time benefit. Watch /etc in real time and scan /var/www on a schedule.

“Everything worked until an upgrade.” Wazuh’s minor versions expect manager and agents to match. A manager on 4.12 with agents on 4.9 mostly works until a decoder changes and a rule stops firing, with no error anywhere. Upgrade the manager first, then the agents, and check agent_control -l reports the version you expect.

Is it worth it?

Wazuh is worth it if you have five or more machines, at least one exposed to the internet, and 8 GB you can genuinely spare. File integrity monitoring plus vulnerability detection plus rule-based correlation is a real capability, it is the capability your homelab is otherwise completely missing, and nobody else gives it to you for free. The first time it tells you /etc/ssh/sshd_config changed on a box where you changed nothing, the RAM stops being a debate.

Wazuh is a mistake if you have three machines and 16 GB total. You will spend the RAM, spend the first fortnight tuning noise, and end up with a dashboard you check twice a month. For that shape of lab, CrowdSec on the edge plus AIDE for file integrity plus a weekly Lynis run covers 70% of the value at 5% of the cost. That is a good trade and you should take it without embarrassment.

The reservation I promised: Wazuh is enterprise software wearing a homelab hat. Every design decision assumes a security team, a compliance requirement and a hardware budget, and you have none of those. It will work, it will work well, and it will always feel one size too big for the room. I keep running it because file integrity monitoring on the edge box is worth 5 GB to me specifically. Do the same arithmetic with your own numbers before you install anything, because the answer genuinely changes with the size of the lab.