Skip to content
Notifications
Clear all

How-to: Integrating OPNsense logs into a self-hosted SIEM (Graylog)

1 Posts
1 Users
0 Reactions
2 Views
(@cloud_infra_vet)
Reputable Member
Joined: 2 months ago
Posts: 134
Topic starter   [#10962]

Having recently completed a multi-cloud consolidation project, a critical requirement was establishing a unified security event pipeline. The on-premises edge was secured by an OPNsense appliance, and while its web GUI is sufficient for day-to-day administration, for enterprise-scale threat visibility, integration into a centralized SIEM is non-negotiable. This post details a production-tested method to stream OPNsense logs into a self-hosted Graylog instance, moving beyond simple syslog forwarding to leverage structured logging via the Syslog-NG `network()` source and Graylog's extractors for proper parsing.

The default approach of using OPNsense's built-in syslog forwarding (System > Settings > Logging) to a Graylog `syslog` UDP input works, but it leaves you with a monolithic `message` field, requiring complex pipeline rules for parsing. A more elegant solution is to deploy a Syslog-NG relay (or agent) that can receive the RFC3164 syslog and forward it as structured JSON to Graylog's GELF input. However, for a leaner architecture, we can configure OPNsense to send directly to a Graylog `syslog` TCP input with a custom format, and then use Graylog's capabilities to dissect the logs.

First, ensure your Graylog side is prepared. Create a `Syslog TCP` input (not UDP for reliability). Note the IP and port. The key is in the OPNsense configuration. Navigate to **System > Settings > Logging**. Set "IP addresses" to your Graylog server's IP and the port you configured. For "Transport", select **TCP** for reliable delivery. The critical step is enabling **RFC 5424** and setting a proper "Hostname" that identifies this firewall (e.g., `fw01-dmz`). This provides structured metadata from the onset.

The raw log will still arrive as a string, but now with predictable fields. In Graylog, you then create extractors for the `message` field. For OPNsense's filterlog (firewall entries), a Grok pattern is essential. Based on the default `filterlog` format, a pattern like this can be a starting point:

```
rule "%{SYSLOGTIMESTAMP:timestamp} %{SYSLOGHOST:device} filterlog[%{POSINT:process_id}]: %{WORD:action},%{WORD:ip_version},%{WORD:interface},%{DATA:rule_details},%{INT:rule_id},%{DATA:reason},%{DATA:action},%{INT:direction},%{DATA:ipv4_details},%{DATA:tcp_details}"
```

You will need to create separate extractors or a pipeline rule for each OPNsense log facility (`filterlog`, `dhcpd`, `unbound`, `openvpn`). The most valuable, from a security perspective, are `filterlog` and `openvpn`. For sustained high-volume logging, consider the following optimizations:

* **Rate Limiting:** In OPNsense, under the logging settings, enable "Rate limit" to prevent log flooding from overwhelming your SIEM during incidents.
* **Local Buffer:** Always keep a local log on the OPNsense appliance (`/var/log/filter.log`) as a fail-safe. Set log rotation to manage disk space.
* **TLS Encryption:** For cross-DC or untrusted network traversal, configure the syslog forwarder to use TLS. This requires importing Graylog's certificate into OPNsense's trust store (**System > Trust > Authorities**).
* **Field Extraction Strategy:** Perform initial parsing with a Graylog pipeline rule that uses the `grok` function, then write the individual fields to new message fields. This is more maintainable than a single, monstrous Grok pattern.

The outcome is a searchable, alert-ready stream of firewall events within your Graylog dashboard. You can now correlate OPNsense deny events with internal host alerts, build dashboards for top blocked countries, and monitor VPN user authentication failures. The integration shifts OPNsense from a perimeter device into a first-class citizen in your security observability stack.



   
Quote