OPNsense Suricata zu Elastic Stack: SIEM für den Mittelstand

Eine OPNsense mit aktivierter Suricata-IDS erzeugt täglich tausende Events — doch ohne strukturierte Auswertung verschwinden diese im Rauschen des eve.json. Für mittelständische Unternehmen, denen ein klassisches SIEM-Produkt wie Splunk oder QRadar zu teuer ist, gibt es eine praktikable Alternative: Filebeat schiebt die JSON-Logs in einen Elasticsearch- oder OpenSearch-Cluster, Kibana visualisiert Alerts, Flows und DNS-Anfragen. Diese Pipeline lässt sich an einem Wochenende aufsetzen und liefert produktiv nutzbare Sicht auf den Perimeter.

Wir bei DATAZONE betreiben diese Architektur seit drei Jahren in eigenen Kundenprojekten und kennen sowohl die Eleganz als auch die Tücken, insbesondere wenn das Logvolumen die 1-TB-Marke knackt. Im Folgenden skizzieren wir die komplette Pipeline — vom Plugin-Install auf der OPNsense bis zu den ersten brauchbaren Dashboards.

Architektur und Komponentenwahl

Die Pipeline besteht aus vier Bausteinen: Suricata 7.0 (auf OPNsense 25.7) schreibt strukturierte Events ins eve.json. Filebeat 8.17 — als OPNsense-Plugin verfügbar — liest diese Datei tail-artig aus und sendet die Events an einen zentralen Logging-Cluster. Dort läuft entweder Elasticsearch 8.17 oder OpenSearch 2.18, beide sind kompatibel zum Filebeat-Protokoll. Kibana oder OpenSearch Dashboards übernehmen die Visualisierung.

Für den Mittelstand empfehlen wir grundsätzlich OpenSearch: die Apache-2.0-Lizenz bleibt langfristig stabil, während Elastic 2021 auf die restriktivere SSPL gewechselt ist. Funktional gibt es im Bereich Suricata-Logs keinen relevanten Unterschied. Wer ohnehin schon eine Elastic-Subscription hält, bleibt natürlich beim Original.

Komponente	Version	Rolle	RAM-Empfehlung
OPNsense	25.7	Firewall mit Suricata-IDS	4 GB
Filebeat	8.17	Log-Shipper auf OPNsense	256 MB
OpenSearch	2.18	Index- und Suchcluster	16-32 GB
OpenSearch Dash.	2.18	Visualisierung und Dashboards	4 GB

Suricata auf OPNsense vorbereiten

Bevor wir an Filebeat denken, muss Suricata sauberes EVE-JSON liefern. In der OPNsense-Weboberfläche aktivieren Sie unter Services -> Intrusion Detection -> Administration die IDS, wählen die WAN-Schnittstelle und stellen den Modus auf IPS oder IDS only, je nach Risikoappetit. Aktivieren Sie unter Advanced die Option EVE syslog output, damit alle Event-Typen (alert, flow, http, dns, tls) in einer Datei landen.

Zusätzlich empfehlen wir die ET-Open-Regelsätze plus die kostenlose Abuse.ch-Liste für Threat-Intel. Vermeiden Sie zu Beginn die kommerziellen ET-Pro-Regeln, sonst ertrinken Sie in False Positives. Nach einem Reload des IDS-Dienstes liegt die Datei unter /var/log/suricata/eve.json und füllt sich — je nach Traffic — mit 50 MB bis 5 GB pro Tag.

Filebeat-Plugin installieren und konfigurieren

Auf der OPNsense installieren Sie das Plugin os-filebeat über System -> Firmware -> Plugins. Nach dem Reboot taucht unter Services der Filebeat-Eintrag auf. Die Konfiguration erfolgt deklarativ über das OPNsense-Webinterface, technisch landet sie unter /usr/local/etc/filebeat.yml. Ein minimaler Output-Block für OpenSearch sieht so aus:

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

Wichtig: Deaktivieren Sie ILM bei OpenSearch, dort heißt das Pendant ISM und muss separat konfiguriert werden. Das Passwort gehört nicht in die YAML, sondern in die Keystore — filebeat keystore add BEAT_PW. Ein Funktionstest mit filebeat test output zeigt sofort, ob TLS und Authentifizierung sitzen.

OpenSearch-Indizes und Lebenszyklus

Der Default eines Index pro Tag (suricata-2026.06.03) ist sinnvoll, weil Sie alte Daten so per DELETE-Call oder ISM-Policy effizient löschen können. Bei 200 GB Roh-EVE pro Tag entstehen nach Kompression rund 60-80 GB im Index. Planen Sie folgende ISM-Policy:

• Hot: 0-7 Tage, schneller NVMe-Storage, schreibend
• Warm: 7-30 Tage, langsamere SSDs, nur lesend, Replicas reduziert
• Cold/Snapshot: ab Tag 30, Snapshot auf S3-kompatiblen Storage (z.B. MinIO oder TrueNAS mit S3-Plugin)
• Delete: ab Tag 90 oder gemäß Aufbewahrungspflicht

Für ein realistisches 1-TB-Logvolumen pro Monat ergeben sich rund 12 TB pro Jahr im warmen Tier. Auf NVMe-Storage kostet das in Eigenbetrieb etwa 1.500 bis 2.500 Euro Hardware einmalig, in einer Cloud (AWS gp3, 1 TB) hingegen rund 1.200 Euro pro Jahr nur für Storage — ohne Compute. Snapshots auf einem TrueNAS-Backup-Pool drücken die Langzeitkosten signifikant.

Kibana-Dashboards für Alerts, Flows und DNS

Nach den ersten Stunden Ingestion legen Sie in Kibana oder OpenSearch Dashboards ein Index-Pattern suricata-* mit @timestamp als Zeitfeld an. Drei Kern-Dashboards haben sich in unseren Projekten bewährt:

Alert-Dashboard: zeigt Top-Signaturen, Quell- und Ziel-IPs, betroffene Regelkategorien als gestapelte Balken sowie eine Tabelle der Top-10-Alerts der letzten 24 Stunden. Filter auf event_type:alert reduziert das Datenvolumen drastisch.

Flow-Dashboard: visualisiert TCP/UDP-Flows nach Bytes und Paketen, sortiert nach Top-Talkern. Hier finden Sie auffällige Datenabflüsse oder Crypto-Mining-Traffic. Ein Lens-Diagramm mit sum(flow.bytes_toserver) über die Zeit, gruppiert nach dest_ip, liefert sofort verwertbare Erkenntnisse.

DNS-Dashboard: listet die am häufigsten abgefragten Domains, hebt NXDOMAIN-Spitzen hervor (klassisches DGA-Indiz für Malware) und zeigt DNS-over-TLS-Anteile. Auf event_type:dns AND dns.type:query filtern, dann nach dns.rrname aggregieren.

Achtung beim Speicher: Wenn Sie alle Event-Typen indexieren, verschlingen flow-Events 70 Prozent des Volumens, liefern aber den größten forensischen Mehrwert. Wer Kosten sparen muss, kann via Filebeat-Processor drop_event die Flows nach 24 Stunden droppen oder gar nicht erst senden.

Operative Praxis und Stolperfallen

In der Realität ist die größte Herausforderung nicht die Installation, sondern der Dauerbetrieb. Drei Punkte sind aus unserer Praxis besonders relevant.

Erstens: Suricata-Regeln müssen regelmäßig aktualisiert werden, sonst veralten die Detection-Capabilities. Ein nächtlicher Cron auf der OPNsense oder das Plugin os-suricata mit Auto-Update löst das.

Zweitens: Kibana-Dashboards driften. Neue Regeln führen zu neuen Feldnamen, ECS-Mappings ändern sich zwischen Filebeat-Major-Versionen. Versionieren Sie Ihre Saved Objects per kibana_export als JSON in Git, idealerweise in derselben Repo-Struktur wie Ihr Ansible- oder Terraform-Code.

Drittens: Wer Suricata ernsthaft fährt, sollte die Detection mit einer EDR-Lösung auf den Endpunkten und sauberer Segmentierung in OPNsense kombinieren. Ein SIEM ist kein Ersatz für defensive Architektur, sondern dessen Sichtbarkeitsebene.

Fazit

Mit Filebeat, OpenSearch und Dashboards bauen Sie für unter 5.000 Euro Hardware ein vollwertiges, leichtgewichtiges SIEM für den Mittelstand — inklusive nachvollziehbarer Detection, forensischer Tiefe und einer realistischen Kostenstruktur. Wichtig ist die saubere Storage-Planung: ohne ISM-Policy und Snapshot-Strategie wuchern die Indizes, und der Cluster bricht nach wenigen Monaten in die Knie.

DATAZONE unterstützt mittelständische Unternehmen aus Neuburg, Ingolstadt und der Region beim Aufbau dieser Pipeline — von der Suricata-Härtung über die OpenSearch-Architektur bis zu maßgeschneiderten Kibana-Dashboards für Ihre Compliance-Anforderungen. Gerne sprechen wir mit Ihnen über Ihren konkreten Use-Case: Kontakt aufnehmen.