Running one Wazuh manager for all our clients without drowning in alerts

Most of our small clients will never pay for an expensive SIEM, but they still deserve someone watching their logs. Wazuh is how we cover that. It's free and open source, and it gives a small MSP a lot of what the big products offer, across Windows, Linux and macOS. We run a single Wazuh manager for every client. This post covers how we deploy agents from the RMM, keep clients separated, cut down the noise, and keep the manager itself from turning into a liability.

What you get out of it

• Log collection and analysis. Agents ship Windows event logs, syslog and application logs to the manager, which decodes them and matches them against thousands of rules.
• File integrity monitoring (FIM), which alerts when watched files, directories or registry keys change
• Vulnerability detection. Agents inventory installed packages and the manager compares them against CVE feeds.
• Security configuration assessment (SCA), which scores endpoints against CIS-style benchmark checks
• Active response, which is optional automated action such as blocking an IP after repeated failures. I'd be careful with this one.

Lock down enrollment first

Out of the box, anything that can reach port 1515 can enroll as an agent. Turn on password enrollment on the manager. In /var/ossec/etc/ossec.conf, inside the <auth> section, set <use_password>yes</use_password>, then write the password to the auth file:

echo 'REPLACE-WITH-LONG-RANDOM-STRING' > /var/ossec/etc/authd.pass
chmod 640 /var/ossec/etc/authd.pass
chown root:wazuh /var/ossec/etc/authd.pass
systemctl restart wazuh-manager

One group per client

Groups let you push different configuration to different agents, and they let whoever is looking at the dashboard filter down to one client. Create them on the manager before you deploy anything:

/var/ossec/bin/agent_groups -a -g client-contoso -q
/var/ossec/bin/agent_groups -a -g client-fabrikam -q
/var/ossec/bin/agent_groups -l

Each group gets a shared config file at /var/ossec/etc/shared/GROUP/agent.conf, and agents in that group pull it automatically. That's where client-specific FIM paths or extra log sources go.

Pushing agents from the RMM

The agent packages accept deployment variables, so one command installs the agent, enrolls it and assigns the group. Match the agent version to your manager version or older, because an agent newer than the manager won't connect. On Windows:

$msi = "$env:TEMP\wazuh-agent.msi"
Invoke-WebRequest -Uri 'https://packages.wazuh.com/4.x/windows/wazuh-agent-4.x.x-1.msi' -OutFile $msi
Start-Process msiexec.exe -Wait -ArgumentList "/i `"$msi`" /q WAZUH_MANAGER=`"wazuh.contoso.com`" WAZUH_REGISTRATION_PASSWORD=`"REPLACE-ME`" WAZUH_AGENT_GROUP=`"client-contoso`""
Start-Service -Name WazuhSvc

Replace 4.x.x with the exact version you run. On Debian or Ubuntu, with the Wazuh repository already added:

WAZUH_MANAGER='wazuh.contoso.com' WAZUH_REGISTRATION_PASSWORD='REPLACE-ME' \
  WAZUH_AGENT_GROUP='client-contoso' apt-get install -y wazuh-agent
systemctl daemon-reload
systemctl enable --now wazuh-agent

Keep the registration password in an RMM secret or script variable instead of hard-coding it in a script every technician can see.

The first week is loud

Expect a flood at first. Don't disable whole rule groups. Write targeted overrides in /var/ossec/etc/rules/local_rules.xml instead, where a child rule with level 0 suppresses a specific match. For example, this silences successful logons from a known service account:

<group name="local,windows,">
  <rule id="100100" level="0">
    <if_sid>60106</if_sid>
    <field name="win.eventdata.targetUserName">^svc-backup$</field>
    <description>Ignore routine logons by the backup service account</description>
  </rule>
</group>

Use custom rule IDs from 100000 upward. Test by pasting a sample event into /var/ossec/bin/wazuh-logtest, then restart the manager.

Treat the manager like a domain controller

Your SIEM holds logs from every client and can push configuration to every agent. If someone gets into it, they get into everyone.

• Don't expose the dashboard to the internet without SSO and MFA in front of it, or keep it reachable only over VPN.
• Change the default admin passwords for the dashboard, indexer and API right after install.
• If agents connect over the internet, expose only 1514 and 1515, and consider restricting them to client office IPs.
• Keep the API port (55000) internal.
• Back up /var/ossec/etc (keys, rules, groups), and plan indexer retention so the disk doesn't fill.

/var/ossec/bin/agent_control -l
/var/ossec/bin/agent_groups -l -g client-contoso

Each week I look at the top rules by count in the dashboard and tune whichever one is worst. It only takes a few minutes, and it's what keeps our techs reading the alerts instead of muting them.