IDS/IPS mit Suricata auf OPNsense: Angriffe erkennen und blocken ohne Fehlalarm-Chaos

OPNsense bringt mit Suricata eine vollwertige IDS/IPS-Engine mit. Wer aber nur „IPS Mode“ anklickt, blockiert schlimmstenfalls legitimen Traffic oder merkt nicht, dass Suricata gar nichts verwirft. Diese Anleitung führt von Betriebsmodus, Offloading und Ruleset-Auswahl bis zum Tuning von False Positives, damit am Ende Angreifer geblockt werden und nicht Windows-Updates oder VPN-Verbindungen.

Voraussetzungen

• OPNsense >= 24.7.11_2 (aktuelles suricata-update bereits enthalten; >= 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 (x86, Hyperscan-fähig), 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
• Alternativ ET Pro als kostenpflichtiges Abonnement (OPNsense-Shop) ohne Datenweitergabe

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

Zuerst der Betriebsmodus: Netmap ist ein FreeBSD-Framework, das Pakete direkt aus den NIC-Puffern liest; Divert leitet Pakete über Firewallregeln an Suricata um.

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.

Verifizieren: Prüfen Sie unter Interfaces > Overview, welcher Treiber Ihre Schnittstellen bedient (z. B. igb0 oder vtnet0). Der gewählte Modus muss zu diesem Treiber passen.

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

Häufigster Fehler bei Inline-IPS: LRO, GRO und TSO erzeugen Pakete größer als die physische MTU, die Netmap nicht durch den normalen Sendepfad schleusen kann; Verbindungen brechen stumm ab. OPNsense aktiviert diese Funktionen standardmäßig.

Unter Interfaces > Settings alle Offloading-Funktionen per „Disable“-Häkchen abschalten:

• 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)

Nach dem Speichern per Shell prüfen, ob die Flags 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

Bei NICs ohne natives Netmap den emulierten Modus unter System > Settings > Tunables erzwingen (langsamer, aber funktionsfähig):

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

Verifizieren: ifconfig zeigt in der Zeile options= für jedes IPS-Interface weder TXCSUM/RXCSUM noch TSO4/TSO6 oder LRO.

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

Unter Services > Intrusion Detection > Administration die Engine aktivieren und unter Capture mode wählen: „PCAP live mode (IDS)“ nur für Alarme, „Netmap (IPS)“ für Inline oder „Divert (IPS)“. Divert wirkt erst mit Regeln „Divert-to“ unter Firewall > Rules [new]. Dann die Interfaces:

WAN allein reicht nicht. Hinter NAT stammt aller Traffic scheinbar von der Firewall-IP, und die $HOME_NET/$EXTERNAL_NET-Logik der meisten ET-Regeln bricht.

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

Unter Administration > Interfaces mindestens LAN wählen. WAN bringt im IPS-Modus laut OPNsense-Doku meist wenig, weil die Firewall unerwünschte eingehende Pakete ohnehin verwirft.

Pattern-Matching-Algorithmus nach Hardware:

• Hyperscan: beste Performance, nur auf unterstützten x86-Plattformen
• Aho-Corasick Ken Steele Variant: für Commodity-Hardware ohne Hyperscan
• Standard Aho-Corasick: plattformübergreifend stabil, langsamste Option

Verifizieren: Unter Services > Intrusion Detection > Administration ist die Engine aktiviert, und Services > Intrusion Detection > Log File meldet den Start von Suricata ohne Fehler zum gewählten Interface.

Schritt 4: Rulesets auswählen und aktivieren

Unter Services > Intrusion Detection > Administration > Download stehen die Rulesets. Zu viele aktive Regeln treiben schwache Hardware auf 100 % CPU:

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	Kostenpflichtig	Vollständig, täglich aktualisiert	Über den OPNsense-Shop; 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)

Einstieg: ET Open nur mit emerging-malware, emerging-exploit, emerging-trojan, dazu Abuse.ch. Erst nach einer Woche Beobachtung von Performance und False-Positive-Rate erweitern.

Verifizieren: Nach „Download & Update Rules“ zeigen die gewählten Rulesets ein aktuelles Datum in der Spalte „Last updated“, und der Reiter Rules listet Regeln aus diesen Kategorien.

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

Wichtigste Lektion: nicht direkt von „kein IDS“ auf „IPS mit Drop“ wechseln. Eine False-Positive-Welle kann Windows-Updates, Cloud-Backups oder VPN-Verbindungen blockieren.

Lassen Sie Suricata 1–2 Wochen im reinen Alert-Modus laufen. Alle Regeln stehen standardmäßig auf „Alert“; auch mit „IPS Mode“ wird ohne Drop-Aktionen nichts geblockt. Das ist hier gewollt.

Alerts unter Services > Intrusion Detection > Alerts beobachten und wiederkehrende False Positives mit SID, Quell-IP und Regelname notieren. Für tiefere Auswertung: Zentralisierung mit Grafana Loki.

Verifizieren: Im Reiter Alerts erscheinen Einträge, aber keiner davon mit der Aktion „blocked“. Solange das so bleibt, verwirft Suricata noch nichts.

Schritt 6: False Positives systematisch bereinigen

Drei Methoden, alle persistent:

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

Unter Services > Intrusion Detection > Administration > Policies. Policies überstehen Regelupdates und sind die bevorzugte Methode. Bei Überschneidungen gilt die erste passende mit der niedrigsten Prioritätszahl: spezielle Ausnahmen bekommen die kleinste Zahl, die allgemeine Alert-Policy die größte.

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

Methode B: suricata-update Konfigurationsdateien

Ab OPNsense 24.7.11_2 ist ein aktuelles suricata-update enthalten. Diese Methode ist ein Community-Ansatz (Nova-Labs, siehe Quellen), keine GUI-Funktion: Sie legen die Dateien unter /root/suricata/ selbst an und deaktivieren unter System > Settings > Cron den Eintrag „IDS Rule Updates“, sonst überschreibt der reguläre Update-Lauf Ihre Anpassungen:

# 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

Danach manuell aktualisieren:

# suricata-update manuell ausführen (OPNsense >= 24.7.11_2)
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 mit vielen False Positives legen Sie im Reiter User defined oder einer eigenen Regeldatei eine Pass-Regel an; $GAMING_HOSTS ersetzen Sie durch die IP-Adressen:

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

Verifizieren: Unter Rules zeigt die Spalte „matched_policy“ für die betroffenen SIDs Ihre Policy, und im Reiter Alerts tauchen die bereinigten False Positives nach 24 Stunden nicht mehr auf.

Schritt 7: IPS-Blocking aktivieren

Erst nach der Tuning-Phase die gewünschten Kategorien im Policy-System von „Alert“ auf „Drop“ stellen, beginnend mit:

• trojan-activity
• malware-cnc
• exploit-kit

Weitere Kategorien nach weiteren Beobachtungstagen. Ohne mindestens eine Drop-Policy bleibt Suricata auch im „IPS Mode“ rein detektierend.

Verifizieren: Im Reiter Alerts erscheinen für Regeln der Drop-Kategorien Einträge mit der Aktion „blocked“, und Windows-Updates, Backups und VPN laufen weiter.

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

Am einfachsten laut OPNsense-Doku: unter Administration „Enable eve syslog output“ aktivieren und unter System > Settings > Logging / Targets ein Ziel anlegen (Anwendung „suricata“, Level „info“). Wer die EVE-Datei selbst braucht, ergänzt das Custom-YAML-Template; nach OPNsense-Updates prüfen, da es überschrieben werden kann:

# 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

Verifizieren: Auf dem SIEM kommen Einträge mit "event_type":"alert" an, bzw. tail -f /var/log/suricata/eve.json zeigt neue JSON-Zeilen.

Troubleshooting / Typische Fehler

• Verbindungsabbrüche nach IPS-Aktivierung: Fast immer Offloading. ifconfig em0 | grep -E 'TXCSUM|RXCSUM|TSO|LRO' darf nichts zeigen; sonst Schritt 2, dann Suricata neu starten.
• IPS-Modus aktiv, aber nichts wird geblockt: Ohne Drop-Policy keine Blocking-Wirkung (Schritt 7).
• „zero traffic inspected“ oder Absturz bei VM: Virtio-NICs ohne natives Netmap; dev.netmap.admode=2 unter System > Settings > Tunables.
• False-Positive-Tuning nach Update zurückgesetzt: Änderungen in der GUI-Regelliste werden bei jedem Update überschrieben; nur Policy-System oder disable.conf/modify.conf nutzen.
• CPU 100 %, hohe Latenz, „netmap: ring X is full“: Zu viele Regeln. Weniger Kategorien, Hyperscan (sofern unterstützt), $HOME_NET auf interne Netze eingrenzen.
• $HOME_NET-Regeln erkennen interne Hosts nicht: Suricata läuft nur auf WAN; LAN als Primär-Interface hinzufügen.
• pt-open Ruleset fehlt: Plugin nach Pflege-Ende im September 2022 entfernt; ET Open oder ET Pro Telemetry nutzen.
• suricata-update: „command not found“: Aktuelle Version erst ab OPNsense >= 24.7.11_2; älter nur per Git-Clone von github.com/OISF/suricata-update und Python-Symlink.

Häufige Fragen

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

Inline-IPS (Netmap) inspiziert jedes Paket vor der Weiterleitung und verwirft bei Drop sofort; es braucht Netmap-kompatible NICs und deaktiviertes Offloading. Divert-IPS leitet per ipfw-Divert-Regeln um, ist kompatibler mit NICs und VMs, hat aber etwas mehr Overhead. Empfehlung siehe Faustregel in Schritt 1.

Suricata blockiert legitimen Traffic – wie vorgehen?

1. Alert-Log nach dem blockierten Traffic filtern. 2. SID notieren. 3. Entscheiden: Suppress (Regel bleibt, aber nicht für diese IP; beste Option für bekannte interne Systeme), Disable oder Modify (Threshold erhöhen). 4. Umsetzen als Policy oder via disable.conf/modify.conf, nicht 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), laut Proofpoint aber nicht als alleiniges Ruleset in regulierten Umgebungen. ET Pro Telemetry bietet identische Abdeckung wie ET Pro kostenlos, schickt aber anonymisierte Alert-Daten an Proofpoint (letzte IP-Oktette maskiert). ET Pro ist kostenpflichtig, ohne Datenweitergabe. Ergänzend: Abuse.ch.

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

LAN bevorzugen: Dort sind echte Client-IPs sichtbar und die $HOME_NET/$EXTERNAL_NET-Logik funktioniert (Schritt 3). Bei VLAN-Setups Promiscuous Mode auf dem physischen Parent-Interface aktivieren.

Wie erkenne ich Performance-Probleme durch zu viele Regeln?

Symptome: erhöhte Latenz, CPU dauerhaft über 80 %, Abbrüche unter Last, „netmap: ring X is full, dropping packet“ unter System > Log Files > General. Gegenmaßnahmen wie im Troubleshooting, dazu FP-starke Regeln per Policy deaktivieren.

Bleiben meine Tuning-Anpassungen nach einem Regelupdate erhalten?

Policy-Einträge, disable.conf/modify.conf und korrekt konfigurierte Suppress-Einträge in threshold.config bleiben erhalten. Änderungen direkt in der GUI-Regelliste werden zurückgesetzt; diese Methode nie verwenden.

Fazit

Die drei häufigsten Fehler: Offloading nicht deaktiviert (Verbindungsabbrüche), keine Drop-Policies (Suricata blockt nichts) und IPS ohne Tuning-Phase (blockiert legitimen Traffic). Reihenfolge daher: Offloading aus, IDS-Monitoring, dann schrittweise Drop-Policies. Basis ist die OPNsense-Grundkonfiguration; die Systemlast bei aktivem IPS überwachen Sie mit Zabbix.

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