OPNsense Suricata: Regel-Tuning ohne False-Positive-Flood

Suricata in OPNsense ist mit zwei Klicks aktiviert — und genau das ist das Problem. Wer die Emerging-Threats-Open-Rules ungefiltert scharf schaltet, erzeugt in einem typischen SMB-Netz binnen Stunden fünfstellige Alert-Zahlen. Nach einer Woche schaut niemand mehr in die Log-Konsole, und der teuer bezahlte IDS-Sensor ist praktisch blind.

Rule-Tuning ist die entscheidende Disziplin, die aus Suricata ein produktives Detection-Werkzeug macht. In diesem Artikel zeigen wir, wie Sie in OPNsense 25.7 mit Suricata 7.x systematisch Rauschen unterdrücken, echte Erkennungslücken schließen und die relevanten Events sauber an ein SIEM übergeben. Der Fokus liegt bewusst auf handwerklichem Vorgehen statt auf Wunder-Konfigurationen.

Ruleset-Auswahl: ET/Open vs. kommerzielle Quellen

OPNsense bringt in der Suricata-Integration eine Auswahl vordefinierter Regelquellen mit. In der Praxis relevant:

Ruleset	Regeln (ca.)	Lizenz	Typische Rauschklasse
ET Open	60.000+	frei, GPLv2	hoch, viele generische Signaturen
ET Pro (Proofpoint)	90.000+	kommerziell	mittel, kuratiert, IOC-Feed inkl.
Abuse.ch (SSLBL, Feodo)	wenige tausend	frei	niedrig, sehr präzise
OPNsense-eigene	wenige hundert	frei	niedrig

Unsere Empfehlung für SMB-Umgebungen: ET Open als Basis, ergänzt um die Abuse.ch-Feeds für hochwertige C2-Erkennung. ET Pro rechnet sich erst, wenn Sie ein dediziertes SOC oder einen MSSP haben, der die Alerts auch bearbeitet. Wer ohne Personalressourcen ET Pro einkauft, hat mehr Regeln, aber nicht mehr Sicherheit.

Wichtig ist die Ruleset-Update-Strategie: Suricata sollte nicht täglich alle Kategorien nachladen, sondern in Klassen. Kategorien wie emerging-info oder emerging-policy sind für die meisten Netze irrelevant und sollten komplett deaktiviert werden — nicht per Suppression, sondern durch Abwählen der Kategorie im Downloader. Das spart Rule-Compile-Zeit und RAM.

Kategorien deaktivieren statt Regeln suppressen

Der erste Tuning-Schritt findet in Services > Intrusion Detection > Administration > Download statt. Hier deaktivieren Sie ganze Regelkategorien, die für Ihr Netz keine Relevanz haben. In einem typischen SMB-Netz ohne Gaming, ohne Chat-Server und ohne P2P sind das:

• emerging-chat (IRC, ICQ, XMPP-alt)
• emerging-games
• emerging-p2p
• emerging-info (reine Informations-Events, keine Bedrohung)
• emerging-policy (interne Policy-Verletzungen ohne Sicherheitsbezug)
• emerging-icmp_info

Aktiv bleiben sollten emerging-malware, emerging-exploit, emerging-trojan, emerging-current_events, emerging-mobile_malware sowie die Abuse.ch-Feeds. Für Webserver-DMZs zusätzlich emerging-web_server und emerging-web_specific_apps.

Nach der Kategorie-Auswahl bleiben in der Regel 8.000 bis 15.000 aktive Signaturen — eine Größenordnung, die auf modernen Firewall-Appliances mit vier Kernen und 8 GB RAM sauber im IPS-Modus läuft.

Threshold und Suppression: das Herzstück

Auch nach der Kategorie-Bereinigung bleiben Signaturen übrig, die im eigenen Netz false-positiv feuern. Klassische Kandidaten:

• SNMP-Polling durch das eigene Monitoring
• Legitime Update-Verbindungen zu ungewöhnlichen CDN-Ranges
• VoIP-Traffic, den SIP-Signaturen als Scan interpretieren
• Interne Backup-Jobs, die als Datenexfiltration erkannt werden

Für diese Fälle gibt es zwei Mechanismen: Threshold (Häufigkeit begrenzen) und Suppression (Regel für definierte IPs komplett stumm schalten).

Ein Blick in die generierte suricata.yaml bzw. die OPNsense-Konfiguration unter /usr/local/etc/suricata/ zeigt die Syntax. In OPNsense pflegen Sie diese Einträge komfortabel über Services > Intrusion Detection > Administration > Schedule > User defined. Ein typisches Beispiel für eine Threshold-Konfiguration:

# Threshold für SIP-Scan-Signatur, nur bei mehr als 20 Events / 60s alarmieren
threshold gen_id 1, sig_id 2019876, type threshold, \
  track by_src, count 20, seconds 60

# Suppression: Backup-Server darf uneingeschränkt große Datenmengen exportieren
suppress gen_id 1, sig_id 2013504, track by_src, ip 10.10.20.15

# Suppression pro Netz: Monitoring-Segment ist von SNMP-Signaturen ausgenommen
suppress gen_id 1, sig_id 2101411, track by_src, ip 10.10.99.0/24

Wichtig: Suppression ist kein “Regel löschen”. Die Signatur bleibt aktiv, aber für die genannten Quell- oder Ziel-IPs wird kein Event erzeugt. So bleibt die Erkennung für den Rest des Netzes intakt.

Als Faustregel für die Erst-Inbetriebnahme: Starten Sie im reinen IDS-Modus (Alert Only), sammeln Sie sieben Tage lang Events, klassifizieren Sie die Top-30-Regeln nach Häufigkeit und entscheiden Sie pro Regel: legitime Erkennung, Threshold, oder Suppression. Erst dann in den IPS-Modus schalten.

Custom Rules: gezielte IOC-Erkennung

Der eigentliche Mehrwert von Suricata entsteht bei kundenspezifischen Regeln. Wenn Sie aus einem CERT-Bulletin, einem Threat-Intel-Feed oder einem eigenen Incident wissen, dass bestimmte IP-Adressen, Domains oder JA3-Fingerprints kompromittiert sind, gehört diese Information in eine lokale Signaturdatei.

In OPNsense legen Sie unter Services > Intrusion Detection > Administration > User defined eigene Regeln an. Ein Beispiel für eine IOC-Regel, die ausgehende Verbindungen zu einer bekannten C2-Infrastruktur meldet:

alert tcp $HOME_NET any -> [185.220.101.0/24,45.132.192.15] any \
  (msg:"DATAZONE-IOC C2 Outbound Connection"; \
   flow:established,to_server; \
   classtype:trojan-activity; \
   priority:1; \
   sid:9000101; rev:1;)

alert dns $HOME_NET any -> any any \
  (msg:"DATAZONE-IOC Suspicious Domain Lookup"; \
   dns.query; content:"malicious-c2.example"; nocase; \
   sid:9000102; rev:1;)

alert tls $HOME_NET any -> $EXTERNAL_NET any \
  (msg:"DATAZONE-IOC Known Bad JA3 Fingerprint"; \
   ja3.hash; content:"a0e9f5d64349fb13191bc781f81f42e1"; \
   sid:9000103; rev:1;)

Die SID-Range 9000000-9999999 ist per Konvention für lokale Regeln reserviert — so kollidiert sie nicht mit ET-Signaturen. Verwenden Sie einen konsistenten Präfix im msg-Feld (im Beispiel “DATAZONE-IOC”), damit Ihr SIEM die eigenen Regeln automatisiert filtern kann.

Für dynamische IOC-Listen empfiehlt sich ein Cron-Job, der aus MISP, Abuse.ch oder einem eigenen Feed regelmäßig eine .rules-Datei generiert und via configctl ids reload in Suricata nachlädt. So bleibt die Erkennung tagesaktuell, ohne dass die Firewall vollständig neu startet.

SIEM-Integration: Syslog und EVE-JSON

Alerts, die nur in der OPNsense-GUI stehen, werden nicht bearbeitet. Für produktive Detection muss Suricata seine Events an ein zentrales System übergeben. OPNsense bietet dafür zwei Pfade:

Syslog-Export über System > Settings > Logging > Remote. Reicht für kleine Umgebungen, aber die Alerts kommen als unstrukturierter Text an — Parsing im SIEM ist aufwendig.

EVE-JSON-Log ist der bessere Weg. Suricata schreibt bereits nach /var/log/suricata/eve.json strukturierte JSON-Events mit vollem Kontext (Flow, HTTP, DNS, TLS, Files). Ein Filebeat- oder Vector-Agent auf der OPNsense (oder ein Log-Shipper auf einem separaten Collector, der die Datei per NFS/Syslog abholt) transportiert das direkt in Elastic, Wazuh, Graylog oder Splunk.

Ein Beispiel-Event aus eve.json:

{
  "timestamp":"2026-08-05T10:23:41.123456+0200",
  "event_type":"alert",
  "src_ip":"10.10.20.15","src_port":52341,
  "dest_ip":"185.220.101.44","dest_port":443,
  "proto":"TCP",
  "alert":{
    "signature_id":9000101,
    "signature":"DATAZONE-IOC C2 Outbound Connection",
    "category":"A Network Trojan was detected",
    "severity":1
  },
  "flow":{"pkts_toserver":8,"bytes_toserver":1204}
}

Ein solches Event lässt sich im SIEM sofort mit Asset-Datenbank und User-Kontext anreichern. In unseren Kundenprojekten sehen wir typischerweise: nach sauberem Tuning liegt das relevante Event-Volumen bei 20 bis 200 Alerts pro Tag für ein 100-Client-Netz — eine Menge, die ein IT-Team im Rahmen der normalen Betriebsroutine tatsächlich sichten kann.

Performance und IPS-Aktivierung

Suricata kann in OPNsense reines IDS (nur Alert) oder aktives IPS (Verwerfen von Paketen via Netmap) sein. Der Wechsel in den IPS-Modus verdient ein eigenes Wartungsfenster — eine falsch getunte Regel im Blocking-Mode kann legitimen Traffic komplett unterbrechen.

Empfohlener Ablauf: mindestens zwei Wochen IDS mit sauberem Tuning, danach IPS-Aktivierung schrittweise pro Kategorie. emerging-malware und die Abuse.ch-Feeds sind in aller Regel unproblematisch als Blocker. Regeln aus emerging-scan oder emerging-web_specific_apps sollten Sie erst nach längerer Beobachtung scharf schalten.

Für die Hardware-Dimensionierung gilt: pro Gigabit inspizierter Bandbreite kalkulieren wir konservativ einen CPU-Kern (moderne x86, ab Xeon-D oder AMD EPYC Embedded). Bei kleineren Umgebungen bis 250 MBit/s WAN läuft Suricata problemlos auf jeder aktuellen SMB-Appliance mit vier Kernen. Wer 10-GbE-Inspektion braucht, muss über die Netzwerk-Architektur und ggf. dedizierte Sensoren nachdenken.

Fazit

Suricata in OPNsense ist ein hervorragendes Werkzeug — aber nur, wenn das Ruleset diszipliniert kuratiert und die Ausgabe an ein SIEM angebunden ist. Wer die Ruleset-Katalog-Klicks überspringt und direkt in den IPS-Modus geht, produziert entweder Ausfälle oder Alert-Fatigue. Beides ist teurer als eine Woche sauberes Tuning zu Projektbeginn.

DATAZONE unterstützt bei OPNsense- und Suricata-Deployments von der Ruleset-Auswahl über Custom-IOC-Integration bis zur SIEM-Anbindung (Wazuh, Graylog, Elastic). Wenn Sie Ihre Firewall vom reinen Paketfilter zum echten Detection-Sensor ausbauen möchten, sprechen Sie uns an: Kontakt zu DATAZONE — Ihrem IT-Systemhaus in Neuburg an der Donau.