I've been conducting a longitudinal analysis of our SonicWall NSA 2700's system log behavior, and the rate of log generation poses a significant operational data management challenge. The volume necessitates daily administrative intervention to prevent capacity exhaustion, which seems antithetical to a "set-and-forget" network security appliance in a mid-sized enterprise context. This isn't a simple storage issue; it's a signal-to-noise ratio problem within the telemetry data itself.
My investigation, correlating log entry timestamps with configured policies, points to several high-frequency event generators:
* **Security Processor & Deep Packet Inspection (DPI) Logging:** Every packet processed through the DPI-SSL or Security Services (Gateway Anti-Virus, Anti-Spyware, IPS) generates a metadata event. With high throughput, this creates a torrent of `info` level entries that often drown out critical `alert` or `critical` events.
* **Implicit Deny Rules & Probe Traffic:** The default implicit deny at the end of every policy table logs every unauthorized connection attempt. On an internet-facing device, this includes constant internet background radiation (port scans, worm probes), each creating a log entry.
* **Connection Monitoring Events:** Enabling logging for "connection established" and "connection closed" on even a few key policies (e.g., outbound web traffic) can be profoundly multiplicative.
The core issue is that the logging subsystem often operates at a verbosity level more suited for debugging than for continuous security monitoring. To illustrate, I've refined our log settings to suppress noise while retaining forensic capability. The critical adjustments were made in **Log > Categories > Log Settings**:
```
## Example of tuned settings for a balance of audit and volume:
Category: System - Success - Set to "Alert" (from "Info")
Category: System - Error - Remain at "Notice"
Category: Firewall - Connection Opened - Disable (if not required for compliance)
Category: Firewall - Connection Closed - Disable
Category: Network - Monitor - Disable (unless specifically troubleshooting)
Category: Security Services - Scan - Set to "Alert" (only log infected/blocked)
```
Furthermore, leveraging **Log > Automation** is non-negotiable. A scheduled weekly archive and purge policy, offloading logs to a syslog server (like a Graylog instance), is essential for preserving historical data without consuming local ring buffer space. The built-in database has inherent limitations.
From a statistical perspective, the log generation follows a Poisson process where the rate parameter λ is inflated by numerous low-information events. The practical result is that the mean time between significant security events is masked by high-frequency operational noise. I'm interested in the community's analysis: have others performed a quantitative event-type frequency distribution on their SonicWall logs? What categories did you find to be the most prolific generators of low-priority entries?
- Dr. C
Nullius in verba
You've perfectly identified the core generators. The implicit deny rule logging is a major contributor that often gets overlooked during initial setup. It's effectively logging every single packet that doesn't have an explicit allow rule, which on an internet edge is a staggering amount of noise.
I'd add a third category to your list: scheduled system jobs and health checks. Things like firmware update checks, signature update polls, and hardware diagnostic pings can each generate their own series of routine log entries every few minutes. When combined, they create a constant, predictable baseline of events that further dilute the actionable alerts.
Have you considered creating a log filtering profile to suppress info-level events from the DPI engine? You can often retain the alert and critical events while stopping the flood of packet-processing metadata. It requires careful tuning to avoid missing a true anomaly.
Method over hype