I've been rolling out Wazuh to a fleet of mixed Linux servers (mostly Ubuntu 22.04 and RHEL 9) and the noise level is making the logs useless. The default policy seems designed to alert on every single system activity.
The main culprits seem to be:
* **System inventory scans** firing `syscollector` alerts constantly for trivial changes in package lists or network interface status.
* **Integrity monitoring** going wild on `/tmp`, `/var/log`, and other volatile directories, creating thousands of `syscheck` alerts per day.
* **SSH-related events** where every successful login, sudo command, or even connection attempt triggers multiple decoded alerts.
I get that defaults are broad, but this feels like a configuration issue that pushes people to mute everything. What's the standard practice here? Are you:
1. Aggressively tuning the `ossec.conf` ruleset and local decoders, disabling entire rule groups?
2. Relying heavily on agent-level exclusions in the `syscheck` and `localfile` sections?
3. Just accepting it and filtering at the SIEM/alerting layer?
I need a baseline that catches real intrusions and misconfigurations without drowning in `info`-level chatter. My current `syscheck` snippet for a typical web server looks like this, but I'm still getting flooded:
```xml
/etc,/usr/bin,/usr/sbin
/bin,/sbin,/boot
/etc/ssl/private
/var/log
/tmp
/var/run
6am
6pm
```
What are your essential exclusions and rule disablements?
Build once, deploy everywhere
Yeah, you've hit the classic Wazuh onboarding wall. The defaults are insanely noisy because they're built to catch *everything* on a generic Linux box. Most teams end up doing all three things you listed, but in a specific order.
Start with heavy agent-level exclusions in the `ossec.conf`. That's your first filter. For `syscheck`, you need to exclude directories like `/tmp`, `/var/tmp`, `/dev/shm`, and specific log files that churn. Don't just disable integrity on `/var/log`, use regex patterns to ignore log rotations. For `localfile` sections grabbing auth logs, pair them with rule exclusions at the agent to drop expected, noisy events like routine cron jobs or your own admin logins.
Then, on the manager, you tune the rule set. Disable entire rule groups like the 55000-series (policy monitoring) if it's not relevant, and lower the frequency of syscollector scans. You *can* filter at the SIEM layer, but that's a band-aid for poor source tuning and wastes processing cycles. The goal is to make the agent send only useful data upstream.
I can post a snippet of our baseline syscheck config for web servers if you want. It cuts about 90% of the junk.
Automate everything. Twice.
Totally agree with the agent-first approach. If you're up for sharing that syscheck snippet, I'd love to see it. One thing I'd add is to also throttle the *frequency* of syscollector scans in the agent config - bumping it from the default 60 seconds to something like 3600 for more stable servers cuts a ton of inventory noise without losing real value.
Data > opinions
You're right to focus on configuration rather than just filtering at the SIEM layer. Filtering downstream is a band-aid; you lose visibility into the raw event flow needed for real investigation. I see you've started on the `syscheck` config. The key is moving from directory-level exclusions to more granular, pattern-based ones.
For your `syscheck` snippet, beyond excluding `/tmp` and `/var/tmp`, you need to explicitly ignore the checksums of your package manager's database files (`/var/lib/dpkg/status`, `/var/lib/rpm/*`). Otherwise, every package update triggers an alert. Also, for `/var/log`, exclude by regex for rotated logs: `^/var/log/.+.(gz|old|d)$`. This cuts out 90% of the churn.
I strongly recommend against disabling entire rule groups on the manager initially. It's too blunt. Start with agent-level exclusions, then use the manager's rule tuning to suppress what's left, focusing on specific rule IDs that fire repeatedly for benign activity. This preserves the raw data for future correlation. The noise you're seeing is a rite of passage; tuning it correctly creates a usable baseline.
Garbage in, garbage out.
> start with agent-level exclusions, then use the manager's rule tuning to suppress what's left
This is exactly the right sequence. I learned the hard way that doing it backward silences the alerts but leaves the underlying log collection noisy and wasteful. A practical tip for the manager tuning: build a custom `decoder_exclude` list for your agents. It lets you drop entire event categories, like all SSH logins from a specific jump host IP, before they even hit the rules engine. It's a cleaner filter than disabling rules after the fact.
Also, on the regex exclusions, I'd add `\.\d+$` to catch numbered log rotations (like `auth.log.1`, `auth.log.2.gz`). That pattern, combined with yours, catches almost all of it.
Ship fast. Learn faster.