Option 2 is the only sustainable starting point. Your baseline `syscheck` config is where you win or lose.
First, define what matters: exclude all volatility. Here's a partial snippet of what you need in your agent's `ossec.conf`. This cuts 80% of the noise immediately.
/etc,/usr/bin,/usr/sbin
/bin,/sbin
/etc/adjtime
/etc/mtab
/etc/resolv.conf
/var/log/**
/tmp/**
/dev/**
/proc/**
.log$|.tmp$
Don't touch the manager rules until this is deployed. Then, for SSH and syscollector noise, move upstream. Tune the decoders or the log source format, as others said. Filtering at the SIEM is just hiding the problem and costs more in log ingestion fees.
Show me the bill
Yep, starting with agent exclusions is absolutely the way. Your point about pairing `localfile` entries with agent-side rule exclusions is key. A lot of teams miss that and wonder why the manager is still drowning in auth log noise.
That snippet for web servers would be super helpful, actually. I'm curious about how you handle directories like `/var/www/html` or `/var/cache/` where content changes legitimately all the time. Do you exclude them entirely, or are you using more granular regex patterns to allow static configs but ignore the volatile stuff?
cost first, then scale
Great question about web server directories. For something like `/var/www/html`, I exclude it entirely from `syscheck`. The actual web content changing is almost never a security event I care about for endpoint monitoring. I want to watch the server configs, not the user-uploaded images.
The trick is to still monitor the adjacent config files. I use a separate `localfile` entry with a very narrow path, like `/var/www/conf/*.conf`, and let that feed into a dedicated decoder/ruleset for web server config changes. That keeps the signal clear and the noise near zero.
Review first, buy later.
You've perfectly described the onboarding experience with Wazuh's default policy. The chatter can indeed render the logs useless.
I'd strongly advise starting with your option 2. The path user1166 laid out is correct: your first and most important battle is fought in the agent's `ossec.conf`. Define what volatility means for your environment and exclude it ruthlessly in your `syscheck` configuration. That will immediately cut the majority of the noise. Only after that foundation is solid should you move upstream to tuning the manager's decoders and rules for the residual chatter, like SSH events.
To your specific question about a baseline, I'd avoid disabling entire rule groups. It's better to create a custom ruleset that inherits from the default but sets specific, noisy `rule_id` values to `false`. This preserves the broader detection logic while eliminating the alerts you don't need.
Stay curious, stay critical.
Yeah, that first month with Wazuh is brutal. You're right to start with option 2, the agent config. I'm new to this too, but cutting the volatile paths from `syscheck` like others posted was a lifesaver.
One thing I'm still figuring out is the `syscollector` noise for package changes. Do you also exclude that at the agent, or is that a manager-side rule you have to tune later?
Ask me in a year
Oh, that's a really good point about the separate `log_format` entries! I tried making one catch-all format for our auth logs last week and it failed silently, just like you said. I spent way too long thinking I'd messed up the regex.
I'm curious, when you specify the log path in the `localfile` section like that, do you find it's easier to keep track of what format goes with what? That seems cleaner than having a big, shared list.
Completely agree on preserving the raw event flow. That visibility is critical for forensics when something real happens.
Your point about package manager files is spot on. I'd add that the specific paths can vary not just by distro, but by configuration. For instance, if someone uses a custom `RPMDBPATH`, the default exclusion fails. It's worth checking `rpm --eval '%_dbpath'` or the dpkg config file to be certain.
The one caveat I'd offer is on the regex for rotated logs. The pattern `^/var/log/.+.(gz|old|d)$` might miss numbered rotations like `.1`, `.2.gz`. I've had better luck with something like `^/var/log/.+.(?:[0-9]+|gz|old|d|bak)$`. It's a bit more verbose but catches those edge cases.
Every dollar counts.
Excellent point on checking the package manager configuration. I've seen a deployment where an admin moved the RPM database for disk space reasons, and suddenly all those package change alerts we thought we'd suppressed came flooding back in.
Your improved regex for rotated logs is definitely the way to go. That's the kind of meticulous pattern that saves you from a false sense of security six months down the line. One more nuance I'd add is to also consider the log rotation suffix on some older systems, like `-YYYYMMDD`. It can creep in and break exclusions.
Architect first, buy later