A SIEM that only sees endpoints is watching half the story. The firewall knows which hosts talk to the internet, which internal hosts talk to each other, and which connections were blocked and then retried.
Getting SonicWall logs into Wazuh is not difficult. Getting them to arrive reliably is where people lose an afternoon.
The shape of the integration
SonicWall sends syslog to the Wazuh manager. The manager receives it, decodes it, and applies rules. From there it is like any other log source: events in the archive, alerts where the rules match.
What to check, in order
- Is the firewall actually sending? Watch traffic on the manager while you trigger something on the firewall. If nothing arrives, the problem is before Wazuh.
- Right port, right protocol. Syslog defaults to UDP 514, and UDP does not tell you when it drops. If you can use TCP, use it.
- Right source. A firewall with multiple interfaces may send from an address you did not expect, especially behind NAT.
- Time zone. Nothing is more confusing than events that arrive with timestamps two hours off. Set the firewall and the manager to the same idea of time.
- Decoding. Once events arrive in the archives, check that fields are extracted. A wall of raw text is not monitoring.
What you get
Once the firewall is a first class source, a few things become possible that were not before:
- Correlating a blocked inbound connection with the endpoint that answered it
- Spotting internal scanning by looking at connection patterns between hosts
- Following an outbound connection from an endpoint to the destination that received it
- Detecting policy changes on the firewall itself
Read it
The step by step guide: SonicWall and Wazuh syslog integration
Start with one rule you actually care about, prove the pipeline end to end, then expand.