Central logging on a budget: Wazuh for a small network
A 200-device network has the same question a bank has — "what happened on this host last Tuesday?" — and a budget that does not include a SIEM. Wazuh is the honest answer for most of them, provided you accept what it is and what it is not.
What problem you are actually solving
Three things, in this order:
- Retention. Logs on a firewall or switch rotate away in days. If nobody centralised them, an incident that is discovered a week late has no evidence.
- Authentication visibility. Who logged in, from where, and who failed. This is the highest-value signal per unit of effort in almost every small network.
- Configuration drift. The host that quietly had its audit policy switched off, or a service account added to the local administrators group.
What you are not buying is a 24/7 SOC. Wazuh can detect and alert; it does not watch the alerts for you. Be honest about that before you deploy it, because a system that alerts into a void is how people conclude "logging doesn't work".
Sizing, without the guesswork
For a 50–500 device estate, one manager node with 4 vCPU, 8 GB RAM and 200 GB of disk handles a surprising amount — typically hundreds of agents and a few thousand events per second. The bottlenecks, in order, are disk I/O for the indexer, RAM for the manager, and retention policy.
- Do not put the manager and the indexer on a single 2 vCPU VM and expect it to be pleasant.
- Do decide retention before you ingest anything. Thirty days of everything is rarely the right answer; ninety days of authentication and thirty days of the rest usually is.
- Do exclude the noise at the source — debug-level logs from an application will cost you more than every switch combined.
The log sources that earn their place
- Domain controllers and Linux auth logs. Success and failure, with source address. This is the core.
- Firewall traffic and VPN logs. Especially VPN — remote access is where the interesting failures are.
- Windows event logs on servers: service changes, account changes, PowerShell if you have it enabled.
- Network device syslog for configuration changes and admin logins, not for every interface flap.
Everything else is optional until you have a question it answers.
Why "just enable all the rules" fails
A default ruleset will produce thousands of alerts a day in a Windows environment, most of them unactionable. The teams that succeed start narrow — authentication, privilege changes, new services — and add rules only when they can state what they would do about a match. Wazuh's rule levels help: alert at 10+, log below that, and revisit monthly.
This is the same failure mode as monitoring. The tool is not the outcome; the tuning is.
The insurance question
Cyber-insurance questionnaires increasingly ask whether you centralise logs, how long you retain them, and whether you can show authentication failures across systems. You do not need a SIEM to answer yes — you need a system that ingests those sources, retains them for a defined window, and can produce a report. A documented Wazuh deployment with a stated retention policy answers the question with evidence rather than assertion.
What it costs
The software is free. The real costs are a VM with disk, the time to deploy and tune it, and the discipline to keep it running. A fixed-scope deployment for a 50–500 device network is typically a two- to three-week engagement — manager and indexer built, agents rolled out, log sources onboarded, retention set, authentication alerting tuned, and a runbook so the next person can operate it.
I do exactly that as a fixed-scope engagement, usually paired with Zabbix so visibility and evidence come from one handover. Scope and pricing are here. If you are deploying it yourself, the starter kit covers the automation side, and the Zabbix comparison covers the other half of the stack.