OPNsense Suricata to Elastic Stack: SIEM for SMBs

An OPNsense firewall with Suricata IDS enabled produces thousands of events per day — yet without structured analysis these vanish into the noise of eve.json. For mid-sized companies who find a classic SIEM product like Splunk or QRadar too expensive, there is a practical alternative: Filebeat ships the JSON logs into an Elasticsearch or OpenSearch cluster, and Kibana visualises alerts, flows and DNS queries. The pipeline can be set up over a weekend and delivers production-grade visibility into the perimeter.

At DATAZONE we have been running this architecture in customer projects for three years and know both its elegance and its pitfalls — especially once log volume crosses the 1 TB mark. The following walks through the complete pipeline, from installing the plugin on OPNsense to your first usable dashboards.

Architecture and Component Choice

The pipeline consists of four building blocks: Suricata 7.0 (on OPNsense 25.7) writes structured events to eve.json. Filebeat 8.17 — available as an OPNsense plugin — tails the file and sends events to a central logging cluster. There, either Elasticsearch 8.17 or OpenSearch 2.18 runs, both speaking the Filebeat protocol. Kibana or OpenSearch Dashboards handles visualisation.

For SMBs we generally recommend OpenSearch: the Apache 2.0 license remains stable long-term, whereas Elastic moved to the more restrictive SSPL in 2021. Functionally there is no meaningful difference for Suricata logs. If you already hold an Elastic subscription, sticking with the original is fine too.

Component	Version	Role	RAM recommendation
OPNsense	25.7	Firewall with Suricata IDS	4 GB
Filebeat	8.17	Log shipper on OPNsense	256 MB
OpenSearch	2.18	Index and search cluster	16-32 GB
OpenSearch Dash.	2.18	Visualisation and dashboards	4 GB

Preparing Suricata on OPNsense

Before touching Filebeat, Suricata needs to emit clean EVE JSON. In the OPNsense web UI go to Services -> Intrusion Detection -> Administration, enable the IDS, select the WAN interface and choose IPS or IDS only mode depending on your risk appetite. Under Advanced enable EVE syslog output so that all event types (alert, flow, http, dns, tls) land in a single file.

We also recommend the ET Open rulesets plus the free Abuse.ch threat-intel feed. Avoid commercial ET Pro rules initially or you will drown in false positives. After reloading the IDS service the file lives at /var/log/suricata/eve.json and — depending on traffic — grows by 50 MB to 5 GB per day.

Installing and Configuring the Filebeat Plugin

On OPNsense install the plugin os-filebeat via System -> Firmware -> Plugins. After a reboot the Filebeat entry appears under Services. Configuration is declarative through the OPNsense web UI; technically it ends up in /usr/local/etc/filebeat.yml. A minimal output block for OpenSearch looks like this:

filebeat.inputs:
  - type: filestream
    id: suricata-eve
    paths:
      - /var/log/suricata/eve.json
    parsers:
      - ndjson:
          target: ""
          overwrite_keys: true
    fields:
      log_source: opnsense-fw01
    fields_under_root: true

output.elasticsearch:
  hosts: ["https://logs.intern.example.de:9200"]
  username: "filebeat_writer"
  password: "${BEAT_PW}"
  ssl.certificate_authorities: ["/usr/local/etc/ca.crt"]
  index: "suricata-%{+yyyy.MM.dd}"

setup.template.name: "suricata"
setup.template.pattern: "suricata-*"
setup.ilm.enabled: false

Important: disable ILM for OpenSearch, where the equivalent is called ISM and must be configured separately. Do not store the password in the YAML, use the keystore instead — filebeat keystore add BEAT_PW. A quick filebeat test output immediately shows whether TLS and authentication are correct.

OpenSearch Indices and Lifecycle

The default of one index per day (suricata-2026.06.03) is sensible because old data can be deleted efficiently via a DELETE call or an ISM policy. At 200 GB of raw EVE per day you end up with around 60-80 GB in the index after compression. Plan the following ISM policy:

• Hot: 0-7 days, fast NVMe storage, writeable
• Warm: 7-30 days, slower SSDs, read-only, fewer replicas
• Cold/Snapshot: from day 30, snapshots to S3-compatible storage (e.g. MinIO or TrueNAS with the S3 plugin)
• Delete: from day 90 or per your retention requirements

For a realistic 1 TB monthly log volume that adds up to about 12 TB per year in the warm tier. On in-house NVMe storage this costs roughly 1,500 to 2,500 Euro of hardware once; in the cloud (AWS gp3, 1 TB) around 1,200 Euro per year just for storage — excluding compute. Snapshots on a TrueNAS backup pool drastically cut long-term costs.

Kibana Dashboards for Alerts, Flows and DNS

After the first hours of ingestion create an index pattern suricata-* with @timestamp as the time field in Kibana or OpenSearch Dashboards. Three core dashboards have proven their worth in our projects:

Alert dashboard: shows top signatures, source and destination IPs, affected rule categories as stacked bars and a table of the top 10 alerts in the last 24 hours. Filtering on event_type:alert drastically reduces the data set.

Flow dashboard: visualises TCP/UDP flows by bytes and packets, sorted by top talkers. This is where you spot suspicious data exfiltration or crypto mining traffic. A Lens chart with sum(flow.bytes_toserver) over time, grouped by dest_ip, delivers immediately actionable insight.

DNS dashboard: lists the most queried domains, highlights NXDOMAIN spikes (a classic DGA indicator for malware) and shows DNS-over-TLS ratios. Filter on event_type:dns AND dns.type:query and aggregate by dns.rrname.

A storage caveat: if you index every event type, flow events will consume 70 percent of the volume — but they deliver the highest forensic value. If you have to cut costs, use the Filebeat drop_event processor to drop flows after 24 hours, or never send them at all.

Operational Practice and Pitfalls

In reality the biggest challenge is not installation but day-2 operations. Three points from our practice stand out.

First: Suricata rules must be updated regularly or detection capability degrades. A nightly cron on the OPNsense or the plugin os-suricata with auto-update solves this.

Second: Kibana dashboards drift. New rules introduce new field names and ECS mappings change between Filebeat major releases. Version your saved objects via kibana_export as JSON in Git, ideally in the same repository structure as your Ansible or Terraform code.

Third: anyone running Suricata seriously should combine detection with an EDR solution on endpoints and clean segmentation in OPNsense. A SIEM is no substitute for defensive architecture, only its visibility layer.

Conclusion

With Filebeat, OpenSearch and dashboards you can build a fully functional, lightweight SIEM for SMBs for under 5,000 Euro of hardware — including traceable detection, forensic depth and a realistic cost structure. Sound storage planning is essential: without an ISM policy and snapshot strategy the indices will grow unchecked and the cluster will buckle within months.

DATAZONE supports mid-sized companies in Neuburg, Ingolstadt and the wider region in building this pipeline — from Suricata hardening and OpenSearch architecture to tailored Kibana dashboards aligned with your compliance requirements. We are happy to discuss your specific use case with you: Get in touch.