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?