the free SIEM bills you in hours

Monday morning, 9:04, and the alert counter on my third monitor reads 11,400. Nine agents had reported into my homelab Wazuh install for one full week, and that was the tally. The cold brew next to the keyboard had gone warm, the way it does on Mondays, because I'd started reading alerts at six and hadn't stopped. Somewhere in that pile were three things that mattered. One of them, it turned out, was my own cron job. A backup script I wrote in March, running on schedule, flagged as suspicious activity, sitting in a stack of eleven thousand four hundred others.

The software cost nothing. The week cost a lot, and the week is the product.

the part everyone gets wrong

People install a SIEM and expect detections. They get alerts, which are not the same thing, and the difference is the entire job. Wazuh's manager matches events against its ruleset and fires a warning whenever an event crosses severity level 3, which is the default threshold, and out of the box the ruleset knows nothing about your house. So it flags every SSH attempt from anywhere, because brute-force protection is on by default and the internet is a permasea of bots trying passwords. It flags every package on every box through the vulnerability detector, because old packages exist on every box. Eleven thousand warnings is what "working correctly" looks like on week one. Newcomers read that number as either proof the tool is broken or proof they're under attack. It's neither. It's a microphone turned all the way up in an empty room.

The actual detection engineering is making the microphone discriminate: suppression rules for the backup script, decoders for the log formats that matter, local rules for the things that would be wrong in this building specifically. That work doesn't scale down to hobby scale, either. It's the same work, just smaller.

twenty minutes and then everything else

The install genuinely is fast. Wazuh is GPLv2 and free to self-host, currently at 4.14.8, released late September 2026, with 5.0 still in beta. The all-in-one quickstart asks for 4 vCPUs, 8 GiB of RAM, and 50 GB of disk for up to 25 agents with 90 days of retention, which fits on a surplus mini PC, and the scripted install had agents reporting in about twenty minutes. Here's the thing: the tool is free, Wazuh Cloud starts at $571 a month for 100 agents, and my honest ledger says the free one billed me around forty hours before it said something true. That's local rules, custom decoders, suppression tuning, and a first real pass at deciding which severity levels actually page me. Forty hours is two work weeks at a leisurely pace, spent once, and then a few hours a month forever, because networks drift and rules rot.

Indexer tuning needs its own paragraph, because it's where the free tool's complexity lives. It's OpenSearch under the hood, and on a single node the default index templates create replica shards that can never allocate anywhere, so the dashboard glows yellow and you learn about shard budgets the hard way. Set one primary shard and zero replicas in a template, put an index lifecycle policy on the alerts so 90 days of retention doesn't become 900 GB of disk, and give the JVM half the RAM with the heap min and max set equal. Skip all three and alerts stop indexing at some point, quietly, while the agents keep sending and the dashboard keeps lying by omission. Ask me how I know, and I'll tell you it was a Thursday.

the SIEM joined the botnet

Where it breaks is the part I find funniest and least reassuring. In February 2025 a vulnerability was disclosed in Wazuh itself: CVE-2025-24016, unsafe deserialization in the DistributedAPI, affecting versions 4.4.0 through 4.9.0, fixed in 4.9.1. Exploiting it required valid API credentials, which matters, and the CVSS score prints as 9.9 on one feed and 9.0 on GitHub's advisory. I checked both and never found why they disagree. Both readings mean critical, so the disagreement is academic.

Then Akamai's researchers watched Mirai botnet variants exploiting exactly this bug in the wild, starting March 2025, against Wazuh managers left unpatched and reachable. CISA added the CVE to the KEV catalog in June. The irony writes itself: a tool that watches your network for intrusions became the beachhead, because someone exposed its admin API to the internet and never updated it. Wazuh's own response says none of their customers were affected, and I believe them, because the victims here are the self-hosters. The mechanism is worth stating plainly: the manager's API is a network service with credentials, credentials can be weak or leaked, and internet exposure plus unpatched code is the same recipe on a SIEM as on anything else. My manager sits behind the homelab VPN, listens on the management interface only, and its API credentials are long, rotated, and stored like they matter, because they do.

A security tool is part of your attack surface. Write that sentence somewhere you'll see it.

what I'd build first

• Install it on hardware that meets the quickstart sizing and nothing less. An underpowered indexer doesn't fail loudly, it fails quietly, and quiet failure in a SIEM is the worst kind.
• Before you invite alerts, decide which of your machines generate logs worth keeping and for how long, then put the lifecycle policy on day one.
• Spend the first tuning week on suppression for your own infrastructure, then watch what's left. My pile of 11,400 dropped to a few hundred, and those were readable.
• Keep the manager off the internet, behind the VPN, patched like a server, because the botnets found the ones that weren't.
• Track what the alerts became: mine are two pages, a weekly digest, and a folder of rules with comments in them explaining why, because future me won't remember.

And one thing for the people starting out, since a mentor once spent an hour on the phone saving me from alert fatigue: this is the portfolio. Nine agents, forty hours of tuning, three rules you can defend in an interview, is worth more than another certificate on a wall. A hiring manager who runs a SOC will recognize the work in about four seconds, because they've done it.

The cron job alert got its own suppression rule with a comment attached: added June, backup script, mine, verified. Reading it still makes me laugh, and I check it every time I touch the schedule, because the last person to trust a script is the person who wrote it.

Free means the invoice comes in hours.