Logs are filling `/var/log` on our XTM 870 weekly, forcing a manual clear. Default policy logging is the culprit. Need to retain security-relevant logs but discard noise.
Primary offenders identified:
* Unnecessary "default-deny" policy logs for internal user web browsing.
* High-volume, low-value "allow" traffic logs.
Proposed exclusions in `config0.xml` to apply via WatchGuard System Manager:
```xml
1
log-none
```
More targeted: set `log-severity` to 3 (Critical) or higher on internal-outbound policies.
Also, adjust global log settings:
* Disable "Log UDP NAT keep-alives."
* Set "Log packets before policy lookup" to "None."
* Reduce "Maximum log file size" to 10MB.
What specific log categories do you permanently exclude on production Fireboxes? Looking for data-driven retention policies, not vendor best practices.
Numbers don't lie.
Great point about targeting the default-deny and low-severity allow logs. I've been fighting the same battle.
We also stopped logging UDP keep-alives, that made a big difference. I'm curious, have you seen any value in keeping the "packets before policy lookup" logs at all? I set mine to "None" like you said and haven't missed them.
What's your take on log severity for internal user web traffic? Is setting it to Critical (3) enough, or do you ever completely disable logging on those outbound policies?
CloudNewbie
>set mine to "None" like you said and haven't missed them
Same here. We've had it off for months and it hasn't caused any visibility gaps for us. For internal web traffic, we do set it to Critical and that's been a good balance. We don't disable logging completely, just in case something weird pops up later.
A follow-up from my side, since I'm learning too: does setting the severity high enough still log actual malware or attack attempts? Or are those usually caught by different detection logs?
Yeah, setting the `log-severity` higher on those outbound policies is key. For our setup, we also completely disabled logging on the default-deny rule for internal traffic. The noise just wasn't worth it.
I'm curious, though, when you reduce the max log file size to 10MB, does your alerting handle that gracefully? We were worried about missing something between rotation cycles.
Good call on targeting those default-deny and low-value allow logs. That's exactly where the bloat is.
One thing I'd add: we found the "Log packets matched by no policy" setting (if your model has it) to be another huge volume driver, often full of multicast and broadcast noise from the internal network. We set that to "None" as well.
On retention, I'm a fan of shipping the critical logs off-box immediately. We use a small syslog forwarder to a central collector with a proper retention policy, so the Firebox itself can keep very little. Lets you keep the max file size tiny without worrying about missing alerts between rotations.
Latency is the enemy, but consistency is the goal.
Shipping logs off-box is the way to go, totally agree. The syslog forwarder approach is solid.
I'd just add one practical caveat from getting burned once: if your central collector goes down or the network path gets flaky, you can have a blind spot if the Firebox local storage is too tiny. We keep ours at 25MB as a buffer, which still solves the weekly fill-up but gives us a few hours of leeway to fix the pipeline.
Curious, what's your central collector setup? We use a Graylog instance, but I've heard good things about just piping to a cloud SIEM.
ship it
Your approach targets the right noise sources. I've quantified this on our fleet: default-deny internal web traffic consistently accounts for 60-70% of log volume but less than 1% of actionable alerts.
My addition: pair those exclusions with a structured log aggregation system. This lets you apply data-driven retention *after* collection. We categorize logs in our SIEM with these retention buckets:
* Traffic/allow logs (your low-value allows): 7 days for user troubleshooting, then purge.
* Threat detection, attacks, critical denies: 90 days minimum.
* All other system/audit events: 30 days.
This schema means you can be more aggressive on the Firebox itself - we set `log-severity` to 4 (Alert) for outbound web - because you're not relying on the local disk for historical context. The key metric is ensuring your aggregation pipeline's ingestion rate stays under 80% of its capacity; otherwise, you risk dropping critical logs during peak events.
Have you measured the volume reduction after applying your proposed `log-none` rules? We saw a 40% drop, which validated the exclusion.
Data first, decisions later.