OPNsense bringt mit Suricata eine vollwertige IDS/IPS-Engine direkt mit – aber der Teufel steckt im Detail. Wer einfach „IPS Mode aktivieren" anklickt und hofft, dass es funktioniert, blockiert im schlimmsten Fall legitimen Traffic oder bemerkt gar nicht, dass Suricata überhaupt nichts verwirft. Diese Anleitung zeigt dir den richtigen Weg: vom Betriebsmodus-Entscheid über Hardware-Offloading-Konfiguration und Ruleset-Auswahl bis zum systematischen Tuning von False Positives – so dass am Ende tatsächlich Angreifer geblockt werden und nicht Windows-Updates oder VPN-Verbindungen.

Voraussetzungen

OPNsense >= 24.7 (für native suricata-update-Integration; >= 26.1 für vollständige Inline/Divert-Trennung in der GUI)
NIC mit Netmap-Unterstützung für Inline-IPS (Intel em/igb/ixgbe empfohlen); bei VMs: Tunable dev.netmap.admode=2
Mindesthardware für 1 Gbit/s IPS-Durchsatz: 4–6-Kern-CPU (Intel bevorzugt für Hyperscan), 16 GB RAM
ET Open Ruleset (kostenlos, direkt integrierbar) oder ET Pro Telemetry Plugin os-etpro-telemetry (kostenlos, anonymisierte Datenweitergabe an Proofpoint)
Optional: Abuse.ch Rulesets (Feodo Tracker, URLHaus, SSL Blacklist) – kostenlos, direkt integrierbar
ET Pro Jahresabonnement (~750 USD/Jahr) ausschließlich über shop.opnsense.com erhältlich, falls keine Datenweitergabe gewünscht

Schritt 1: Inline-Modus vs. Divert-Modus – die richtige Wahl treffen

Bevor du Suricata konfigurierst, musst du entscheiden, welchen Betriebsmodus du nutzt. Die Unterschiede sind fundamental:

Kriterium	Inline-IPS (Netmap)	Divert-IPS (ipfw)
Paketpfad	Suricata sitzt direkt im Datenpfad	Pakete werden per ipfw-Divert-Regel umgeleitet
Performance	Zero-Copy via NIC-Ring-Buffer, geringer CPU-Overhead	Etwas mehr Overhead durch ipfw-Umleitung
NIC-Anforderung	Netmap-kompatibel zwingend erforderlich	Kompatibel mit mehr NIC-Typen und VMs
Hardware-Offloading	Muss zwingend deaktiviert werden	Weniger kritisch, aber empfohlen
Empfehlung	Physische Hardware mit Intel-NIC	VMs, ältere NICs, Proxmox/VMware

Faustregel: Physische Hardware mit Intel em/igb/ixgbe → Inline-IPS. Virtio-NIC in Proxmox oder VMware → Divert-Modus oder Inline mit dev.netmap.admode=2.

Schritt 2: Hardware-Offloading deaktivieren (Inline-IPS)

Das ist der häufigste Fehler beim Einrichten von Inline-IPS: Hardware-Offloading-Funktionen wie LRO, GRO und TSO erzeugen Pakete, die größer als die physische MTU sind (Jumbo-Frames). Netmap kann diese nicht durch den normalen Sendepfad schleusen – Verbindungen brechen stumm ab. OPNsense aktiviert diese Funktionen standardmäßig für maximale Durchsatz-Performance.

Gehe zu Interfaces > Settings und deaktiviere alle folgenden Optionen:

Hardware CRC (RXCSUM, RXCSUM6, TXCSUM, TXCSUM6)
Hardware TSO (TSO4, TSO6)
Hardware LRO
VLAN Hardware Filtering (bei älteren OPNsense-Installationen vor 20.7 manuell prüfen)

Prüfe nach dem Speichern per Shell, ob die Flags wirklich weg sind:

# Offloading-Status prüfen (FreeBSD Shell)
ifconfig em0 | grep -E 'TXCSUM|RXCSUM|TSO|LRO'
# Alle diese Flags dürfen im IPS-Modus NICHT erscheinen

Falls du eine NIC verwendest, die kein natives Netmap unterstützt, erzwinge den emulierten Modus unter System > Settings > Tunables:

# Netmap-Emulation erzwingen (nicht-native NIC, z. B. Virtio)
# System > Settings > Tunables:
dev.netmap.admode = 2

Der emulierte Modus hat eine geringere Performance, ist aber funktionsfähig.

Schritt 3: Suricata einrichten und Interface-Platzierung korrekt wählen

Navigiere zu Services > Intrusion Detection > Administration. Aktiviere die Engine und wähle den Betriebsmodus. Vor der Interface-Auswahl musst du eine wichtige Entscheidung treffen:

WAN allein reicht nicht. Hinter NAT erscheint aller Traffic als von der Firewall-IP stammend. Die Mehrzahl der ET-Regeln arbeitet mit $HOME_NET- und $EXTERNAL_NET-Variablen – diese Logik bricht komplett, wenn Suricata nur das WAN-Interface sieht.

Interface	Sichtbarkeit	Empfehlung
WAN	Eingehender Traffic von außen; Client-IPs durch NAT versteckt	Ergänzend für eingehenden Angriffsschutz
LAN	Echte Client-IPs sichtbar; $HOME_NET-Logik funktioniert korrekt	Primär-Interface – immer aktivieren
Parent-Interface (VLANs)	Sieht Traffic aller VLANs via Promiscuous Mode	Bei VLAN-Setups statt einzelner VLAN-Interfaces

Wähle unter Administration > Interfaces mindestens das LAN-Interface. Für maximalen Schutz auch WAN hinzufügen.

Stelle den Pattern-Matching-Algorithmus passend zu deiner Hardware ein:

Hyperscan: Beste Performance, nur auf Intel-CPUs verfügbar
Aho-Corasick Ken Steele Variant: Empfohlen für Commodity-Hardware ohne Hyperscan
Standard Aho-Corasick: Plattformübergreifend stabil, geringste Performance

Schritt 4: Rulesets auswählen und aktivieren

Gehe zu Services > Intrusion Detection > Administration > Download. Hier findest du alle verfügbaren Rulesets. Wähle mit Bedacht – zu viele aktive Regeln auf schwacher Hardware können die CPU auf 100 % treiben:

Ruleset	Kosten	Abdeckung	Besonderheit
ET Open	Kostenlos	Basis (Malware, Exploits, Bot-C2)	BSD-lizenziert; laut Proofpoint nicht ausreichend für regulierte Umgebungen
ET Pro Telemetry	Kostenlos	Identisch mit ET Pro	Plugin os-etpro-telemetry; anonymisierte Alert-Daten an Proofpoint (letzte IP-Oktette maskiert)
ET Pro	~750 USD/Jahr	Vollständig, täglich aktualisiert	Nur über shop.opnsense.com; keine Datenweitergabe
Abuse.ch (Feodo, URLHaus)	Kostenlos	Botnet-C2, Malware-URLs, TLS-Fingerprints	Direkt integrierbar; empfohlene Ergänzung zu ET Open
pt-open	–	–	Nicht mehr verfügbar (Pflege eingestellt September 2022)

Empfohlener Einstieg: Aktiviere ET Open nur für kritische Kategorien: emerging-malware, emerging-exploit, emerging-trojan. Füge Abuse.ch-Rulesets hinzu. Erweitere schrittweise, nachdem du Performance und False-Positive-Rate eine Woche beobachtet hast.

Schritt 5: IDS-Monitoring-Phase – erst beobachten, dann blocken

Das ist die wichtigste Lektion: Gehe nicht direkt von „kein IDS" auf „IPS mit Drop". Eine False-Positive-Welle kann legitimen Traffic blockieren – Windows-Updates, Cloud-Backups, VPN-Verbindungen.

Lass Suricata mindestens 1–2 Wochen im reinen Alert-Modus laufen. Alle Regeln stehen standardmäßig auf „Alert" – selbst wenn „IPS Mode" aktiviert ist, wird ohne explizite Drop-Aktionen nichts geblockt. Das ist gewollt und richtig zu diesem Zeitpunkt.

Beobachte die Alerts unter Services > Intrusion Detection > Alerts. Notiere wiederkehrende False Positives – SID, Quell-IP, Regelname. Für weitergehende Log-Auswertung empfiehlt sich die Zentralisierung mit Grafana Loki.

Schritt 6: False Positives systematisch bereinigen

Es gibt drei Methoden, die alle persistent bleiben – wähle die passende:

Methode A: Policy-System (empfohlen für strukturiertes Tuning)

Navigiere zu Services > Intrusion Detection > Administration > Policies. Policies bleiben bei Regelupdates erhalten und sind die bevorzugte Methode. Niedrigere Prioritätszahlen gewinnen.

# Policy-Beispiel (GUI: Services > Intrusion Detection > Administration > Policies)
# Policy 1 (Priorität 0): Alle ET-Regeln auf Alert
#   Ruleset: emerging-threats, Aktion: Alert, Aktiviert: ja
# Policy 2 (Priorität 1): Kritische Kategorien auf Drop
#   Classtype: trojan-activity, malware-cnc -> Aktion: Drop
# Policy 3 (Priorität 2): Spezifische SIDs deaktivieren
#   SID: 2019401 -> Aktion: Disable

Methode B: suricata-update Konfigurationsdateien

Seit OPNsense >= 24.7.11_2 ist suricata-update nativ integriert. Die Konfigurationsdateien unter /root/suricata/ überleben Updates:

# disable.conf – SID dauerhaft deaktivieren
# Datei: /root/suricata/disable.conf
disable sid:2019401
disable sid:2027865
# Alternativ: gesamte Regelgruppe deaktivieren
disable re:emerging-games

# modify.conf – Threshold erhöhen statt deaktivieren
# Datei: /root/suricata/modify.conf
2019401 "threshold:1,track by_src,count 1,seconds 60" \
  "threshold:1,track by_src,count 10,seconds 60"

# threshold.config – Suppress für bekannte False-Positive-Quellen
# Datei: /usr/local/etc/suricata/threshold.config
suppress gen_id 1, sig_id 2019401, track by_src, ip 192.168.1.100
# Oder ganze Netz-Range:
suppress gen_id 1, sig_id 2027865, track by_src, ip 10.0.0.0/24

Führe nach Änderungen ein manuelles Update aus:

# suricata-update manuell ausführen (OPNsense >= 24.7.11_2)
/root/suricata-update/bin/suricata-update update \
  --config /root/suricata/update.yaml \
  --suricata-conf /usr/local/etc/suricata/suricata.yaml \
  --suricata /usr/local/bin/suricata \
  --data-dir /usr/local/etc/suricata \
  --threshold-in=/root/suricata/threshold.in \
  --threshold-out=/usr/local/etc/suricata/threshold.config \
  --output /usr/local/etc/suricata/opnsense.rules \
  -v --no-test --no-reload

Methode C: Pass-Regeln für bekannte Hosts

Für Gaming-Server, Monitoring-Systeme oder andere Hosts, die viele False Positives produzieren:

# Pass-Regel für definierte Hosts (custom.rules)
pass ip $GAMING_HOSTS any -> any any \
  (msg:"Bypass Gaming Hosts"; bypass; sid:1000001; rev:1;)

Schritt 7: IPS-Blocking aktivieren

Erst nach der Tuning-Phase: Wechsle im Policy-System die gewünschten Kategorien von „Alert" auf „Drop". Starte mit den gefährlichsten Klassen:

trojan-activity
malware-cnc
exploit-kit

Erweitere auf weitere Kategorien nach weiteren Beobachtungstagen. Denke daran: Ohne mindestens eine Drop-Policy bleibt Suricata auch im „IPS Mode" rein detektierend.

Schritt 8: EVE-JSON Logging für SIEM aktivieren (optional)

Für strukturierte Log-Ausgabe füge folgendes in das Custom-YAML-Template ein:

# Pfad: /usr/local/opnsense/service/templates/OPNsense/IDS/custom.yaml
outputs:
  - eve-log:
      enabled: yes
      filetype: regular
      filename: /var/log/suricata/eve.json
      community-id: true
      types:
        - alert:
            payload: yes
            http: yes
            tls: yes
        - http
        - dns
        - tls

Troubleshooting / Typische Fehler

Verbindungsabbrüche nach IPS-Aktivierung: Fast immer Hardware-Offloading. Prüfe mit ifconfig em0 | grep -E 'TXCSUM|RXCSUM|TSO|LRO' – alle Flags müssen weg sein. Unter Interfaces > Settings alle Offloading-Optionen deaktivieren, dann Suricata neu starten.
IPS-Modus aktiv, aber nichts wird geblockt: Alle Regeln stehen standardmäßig auf „Alert". Ohne explizite Drop-Aktionen per Policy hat der IPS-Modus keine Blocking-Wirkung. Policy mit Drop anlegen.
„zero traffic inspected" oder Absturz bei VM: Virtio-NICs unterstützen kein natives Netmap. Setze dev.netmap.admode=2 unter System > Settings > Tunables.
False-Positive-Tuning nach Update zurückgesetzt: Manuelle Regeländerungen in der GUI-Regelliste werden bei jedem Update-Lauf überschrieben. Ausschließlich Policy-System oder disable.conf/modify.conf verwenden.
CPU 100 %, hohe Latenz, „netmap: ring X is full": Zu viele aktive Regeln. Weniger Kategorien aktivieren, Hyperscan nutzen (Intel-CPU), $HOME_NET korrekt auf interne Netze eingrenzen.
$HOME_NET-Regeln erkennen interne Hosts nicht: Suricata läuft nur auf dem WAN-Interface. LAN-Interface als Primär-Interface hinzufügen.
pt-open Ruleset fehlt: Plugin wurde nach Einstellung der Pflege im September 2022 entfernt. Auf ET Open oder ET Pro Telemetry wechseln.
suricata-update: „command not found": Native Integration erst ab OPNsense >= 24.7.11_2. Auf älteren Versionen manuellen Git-Clone von github.com/OISF/suricata-update und Python-Symlink erforderlich.

Häufige Fragen

Was ist der Unterschied zwischen Inline-IPS und Divert-IPS?

Inline-IPS (Netmap-Modus) platziert Suricata direkt im Paketpfad: Jedes Paket wird vor der Weiterleitung inspiziert, Drop-Aktionen verwerfen Pakete sofort. Dieser Modus erfordert Netmap-kompatible NICs und zwingend deaktiviertes Hardware-Offloading. Divert-IPS leitet Pakete per ipfw-Divert-Regeln um, ist kompatibler mit verschiedenen NIC-Typen und VMs, hat aber etwas mehr Overhead. Empfehlung: Für physische Hardware mit Intel-NIC Inline-IPS; für VMs oder ältere NICs Divert-Modus oder Inline mit dev.netmap.admode=2.

Suricata blockiert legitimen Traffic – wie vorgehen?

1. Alert-Log filtern nach dem blockierten Traffic. 2. SID der auslösenden Regel notieren. 3. Entscheiden: Suppress (Regel bleibt aktiv, aber nicht für diese IP – beste Option für bekannte interne Systeme), Disable (Regel komplett abschalten), oder Modify (Threshold erhöhen). 4. Änderungen als Policy oder via suricata-update disable.conf/modify.conf durchführen, nicht manuell in der Regelliste. 5. 24 Stunden beobachten.

Reicht ET Open aus, oder brauche ich ET Pro?

ET Open reicht für Heimnetze und kleine Büros als Basisschutz (Malware, bekannte Exploits, Bot-C2). Für regulierte Umgebungen ist ET Open laut Proofpoint nicht als alleiniges Ruleset ausreichend. Die ET Pro Telemetry Edition ist eine gute Alternative: identische Regelabdeckung wie ET Pro, kostenlos, aber anonymisierte Alert-Daten gehen an Proofpoint (letzte IP-Oktette maskiert). ET Pro kostet ~750 USD/Jahr ohne Datenweitergabe. Ergänzend empfehlen sich die kostenlosen Abuse.ch-Rulesets.

Auf welchem Interface soll ich Suricata aktivieren – WAN oder LAN?

LAN-Interface bevorzugen: Hier sind echte Client-IPs sichtbar, und $HOME_NET/$EXTERNAL_NET-Regellogik funktioniert korrekt. WAN allein reicht nicht, da hinter NAT alle Pakete scheinbar von der Firewall-IP kommen. Empfehlung: LAN als Primär-Interface, WAN zusätzlich für eingehenden Angriffsschutz. Bei VLAN-Setups Promiscuous Mode auf dem physischen Parent-Interface aktivieren.

Wie erkenne ich Performance-Probleme durch zu viele Regeln?

Symptome: Erhöhte Latenzen, CPU dauerhaft über 80 %, Verbindungsabbrüche unter Last, Einträge wie „netmap: ring X is full, dropping packet" unter System > Log Files > General. Gegenmaßnahmen: Weniger Regelkategorien aktivieren, Hyperscan nutzen (Intel-CPU), $HOME_NET korrekt eingrenzen, FP-starke Regeln per Policy deaktivieren.

Bleiben meine Tuning-Anpassungen nach einem Regelupdate erhalten?

Policy-Einträge (GUI) bleiben erhalten. suricata-update disable.conf/modify.conf bleiben erhalten. Suppress-Einträge in threshold.config bleiben erhalten, sofern korrekt konfiguriert. Manuelle Änderungen direkt in der GUI-Regelliste werden beim nächsten Update zurückgesetzt – diese Methode nie verwenden.

Fazit

Suricata auf OPNsense ist ein mächtiges Werkzeug – aber nur, wenn die Grundlagen stimmen. Die drei häufigsten Fehler sind: Hardware-Offloading nicht deaktiviert (Verbindungsabbrüche), keine Drop-Policies angelegt (Suricata detektiert, blockt aber nichts) und direkter Sprung in den IPS-Modus ohne Tuning-Phase (blockiert legitimen Traffic). Mit dem hier beschriebenen Vorgehen – erst Offloading deaktivieren, dann IDS-Monitoring-Phase, dann schrittweise Drop-Policies per Policy-System – bekommst du ein stabiles IDS/IPS ohne Fehlalarm-Chaos. Ergänze dazu die OPNsense-Grundkonfiguration als Basis und überwache mit Zabbix die Systemlast, sobald IPS aktiv ist.

Weiterführende Anleitungen und Quellen

OPNsense/pfSense Firewall-Erstkonfiguration – Grundlage für diese Anleitung
VLANs verstehen und am Managed Switch einrichten – für korrekte Suricata-Interface-Platzierung bei VLAN-Setups
Logs zentralisieren mit Grafana Loki – EVE-JSON-Logs von Suricata auswerten
Zabbix Server aufsetzen und Hosts überwachen – Systemlast-Monitoring beim IPS-Betrieb

Quellen: OPNsense Dokumentation: Intrusion Prevention System | OPNsense: ET Pro Telemetry Edition | CoreLab Tech: OPNsense Suricata Inline vs Divert Mode | Nova-Labs: Using suricata-update on OPNsense