OPNsense - Suricata Intrusion Detection und Prevention
Auf einen Blick
| Gilt für | OPNsense 26.1/26.7 (integriert, Services → Intrusion Detection), Suricata 8.0 |
|---|---|
| Bereich | IT-Security |
| Dauer | ca. 30 Minuten (Grundeinrichtung), danach Feinabstimmung über einige Wochen |
| Rechte | Administrator (OPNsense-WebUI) |
| Stand | Oktober 2026 (OPNsense 26.7.5, Suricata 8.0.6) |
Suricata ist ein leistungsfähiges Open-Source-Intrusion-Detection- und -Prevention-System (IDS/IPS) und fest in die OPNsense integriert – ein zusätzliches Plugin ist nicht nötig. Suricata untersucht den Datenverkehr per Deep Packet Inspection auf bekannte Angriffsmuster: Exploits, Malware-Kommunikation, Command-and-Control-Verbindungen, Scans oder Richtlinienverstöße. Im IDS-Modus meldet es Treffer, im IPS-Modus verwirft es verdächtige Pakete direkt. Grundlage sind Regelsätze (Signaturen) von Anbietern wie Proofpoint Emerging Threats oder abuse.ch.
Seit OPNsense 26.1 arbeitet die Firewall mit Suricata 8 und bietet neben dem bekannten Netmap-Modus einen neuen Divert-Modus, bei dem gezielt einzelne Firewall-Regeln Verkehr zur Prüfung an Suricata übergeben.
IDS oder IPS?
- IDS (Intrusion Detection): Suricata liest den Verkehr mit und erzeugt Alarme. Es greift nicht ein – ideal für den Start und die Feinabstimmung.
- IPS (Intrusion Prevention): Suricata sitzt im Datenpfad und verwirft Pakete, deren Regel die Aktion drop hat. Das schützt aktiv, kann bei Fehlalarmen aber auch legitimen Verkehr blockieren.
Empfehlung: Mit IDS beginnen, Alarme einige Tage bis Wochen auswerten, dann ausgewählte Regelgruppen auf drop setzen und in den IPS-Modus wechseln.
Die drei Betriebsmodi
| Capture mode | Funktionsweise | Vorteile | Hinweise |
|---|---|---|---|
| PCAP live mode (IDS) (Standard) | Liest Pakete mit (libpcap) | funktioniert auf nahezu allen Schnittstellen, kein Eingriff in den Datenpfad | nur Alarme, kein Blockieren |
| Netmap (IPS) | Suricata sitzt per netmap direkt im Datenpfad der gewählten Schnittstellen | prüft den gesamten Verkehr der Schnittstelle, hohe Leistung bei unterstützten Netzwerkkarten | Hardware-Offloading muss aus sein; bei VLANs IPS auf der Parent-Schnittstelle aktivieren; nicht zusammen mit Zenarmor auf derselben Schnittstelle |
| Divert (IPS) (seit 26.1) | Firewall-Regeln mit der Option Divert-to übergeben passenden Verkehr an Suricata | gezielte Prüfung nur ausgewählter Verbindungen, unabhängig von netmap-Unterstützung der Karte, auch für VLANs/VPN-Schnittstellen | Läuft Suricata nicht, werden Pakete aus Divert-Regeln verworfen (fail-closed); Anzahl der Listeners ≈ CPU-Kerne |
Welche Schnittstelle?
Wichtig: Ab Werk ist das WAN vorausgewählt. Auf dem WAN sieht Suricata wegen NAT nur die Adresse der Firewall statt des internen Geräts – Alarme lassen sich dann nicht zuordnen, und viele Regeln, die zwischen $HOME_NET und $EXTERNAL_NET unterscheiden, greifen nicht sinnvoll. Zudem verwirft die Firewall eingehenden Verkehr ohnehin. Daher in der Regel die internen Schnittstellen (LAN, VLANs, DMZ) auswählen; das WAN nur, wenn veröffentlichte Dienste gezielt geprüft werden sollen.
Schritt 1: Vorbereitung
- Interfaces → Settings: Für den Netmap-Modus die Hardware-Offloading-Funktionen (CRC, TSO, LRO) deaktivieren und neu starten.
- Ressourcen: Suricata benötigt CPU und RAM abhängig von Durchsatz und Regelumfang; für mehrere Hundert Mbit/s mit IPS sind mehrere Kerne und mindestens 4–8 GB RAM sinnvoll.
- Ist Zenarmor im Einsatz, Suricata im Netmap-Modus nicht auf denselben Schnittstellen betreiben – stattdessen IDS- oder Divert-Modus verwenden.
Schritt 2: Grundeinstellungen
Services → Intrusion Detection → Administration, Reiter Settings:
| Feld | Empfehlung |
|---|---|
| Enabled | aktivieren |
| Capture mode | zunächst PCAP live mode (IDS); später Netmap (IPS) oder Divert (IPS) |
| Interfaces | LAN und weitere interne Netze (nicht nur das vorausgewählte WAN) |
| Listeners | nur im Divert-Modus: Anzahl der CPU-Kerne |
| Promiscuous mode | nur bei Bedarf (z. B. Analyse eines Spiegelports oder VLAN-Verkehr in einer transparenten Filter-Bridge) |
| Pattern matcher | Hyperscan, wenn verfügbar (deutlich schneller), sonst Aho-Corasick „Ken Steele“ variant |
| Home networks (advanced) | Standard: RFC-1918-Netze; anpassen, wenn öffentliche Adressen intern genutzt werden |
| Detect Profile (advanced) | Standard; High bei viel RAM für bessere Leistung bei großen Regelsätzen |
| Enable syslog alerts / Enable eve syslog output | EVE-Ausgabe aktivieren, wenn Alarme an ein SIEM gehen sollen |
| Rotate log / Save logs | wöchentlich bzw. Anzahl nach Speicherplatz |
Apply – Suricata startet, ist aber ohne Regelsätze noch wirkungslos.
Schritt 3: Regelsätze laden
Reiter Download: Regelsätze auswählen, aktivieren und Download & Update Rules ausführen. Über Schedule wird ein Cronjob für die tägliche Aktualisierung angelegt.
| Regelsatz | Anbieter | Hinweis |
|---|---|---|
| ET Open | Proofpoint Emerging Threats | kostenlos, breite Abdeckung; laut Anbieter keine Vollabdeckung für regulierte Umgebungen |
| ET Pro Telemetry | Proofpoint (Plugin os-etpro-telemetry) | kostenlose ET-Pro-Variante im Austausch gegen anonyme Telemetrie; ergänzend os-intrusion-detection-content-et-open |
| ET Pro | Proofpoint (Plugin os-intrusion-detection-content-et-pro) | kommerziell, Oinkcode erforderlich |
| abuse.ch SSL Blacklist, Feodo Tracker, URLhaus | abuse.ch | Malware-/Botnetz-Zertifikate, Banking-Trojaner-C2, Malware-URLs |
| OPNsense App detection | OPNsense-Projekt | Erkennung von Webanwendungen und -diensten (Richtlinien statt Sicherheit) |
| Weitere | Plugins für Snort VRT, Positive Technologies, Anti-Phishing | je nach Lizenz/Registrierung |
Nach dem Download sind die Regeln standardmäßig auf alert gesetzt.
Schritt 4: Richtlinien (Policies)
Unter Services → Intrusion Detection → Policy wird gesteuert, welche Regeln aktiv sind und ob sie nur melden oder blockieren. Eine Richtlinie wählt Regelsätze und Metadaten (z. B. affected_product, attack_target, signature_severity, deployment) aus und setzt die neue Aktion (disable, alert, drop). Bei Überschneidungen gewinnt die Richtlinie mit der niedrigsten Prioritätszahl.
Bewährte Vorgehensweise:
- Alles auf alert und einige Tage beobachten.
- Eine Richtlinie „Kritische Bedrohungen blocken“: Regelsätze ET (Open/Pro) und abuse.ch, Metadaten z. B. signature_severity = Major/Critical bzw. Klassen wie Malware, Trojaner, Command-and-Control, Exploit-Kit → Aktion drop.
- Eine Richtlinie zum Deaktivieren irrelevanter Regeln (z. B. Produkte, die im Netz nicht vorkommen) – spart Leistung und reduziert Fehlalarme.
- Danach in den IPS-Modus wechseln.
Einzelne Regeln lassen sich im Reiter Rules gezielt ändern (sie erscheinen dann mit der Richtlinie __manual__); für viele Änderungen sind Richtlinien übersichtlicher und robuster.
Schritt 5: Alarme auswerten
Reiter Alerts: Zeitpunkt, Schnittstelle, Quelle/Ziel, Regel (SID) und Aktion. Über die Info-Schaltfläche werden Details der Regel angezeigt.
- Treffer von internen Geräten zu Malware- oder C2-Zielen ernst nehmen: Gerät identifizieren (DHCP-Leases/ARP) und untersuchen.
- Fehlalarme (z. B. durch Update-Dienste, Scanner, Fachsoftware): Regel per Richtlinie deaktivieren oder auf alert belassen, statt pauschal Regelsätze abzuschalten.
Divert-Modus einrichten
- Unter Settings den Capture mode auf Divert (IPS) setzen, Listeners auf die Anzahl der CPU-Kerne, anwenden.
- Unter Firewall → Rules die Erlaubnis-Regeln, deren Verkehr geprüft werden soll (z. B. LAN → Internet, Internet → Webserver in der DMZ), öffnen und im advanced mode unter Divert-to den Suricata-Dienst auswählen.
- Regeln anwenden. Nur dieser Verkehr läuft durch Suricata; alles andere wird ohne Inspektion geroutet.
Eigene Regeln, Fingerprints und Bypass
- Reiter User defined: einfache eigene Regeln, z. B. Sperren anhand des TLS-Zertifikats-Fingerprints oder der Quell-/Zieladresse.
- Bypass: Verkehr gezielt von der Inspektion ausnehmen – etwa lokaler Verkehr zwischen internen Netzen, um Routing-Leistung zu sparen (siehe OPNsense-How-to „IPS bypass“).
- Eigene Suricata-Konfiguration: Seit 26.1 nicht mehr über
custom.yaml, sondern über Override-Dateien im Verzeichnis/usr/local/etc/suricata/conf.d.
Alarme an ein SIEM weiterleiten
- Enable eve syslog output aktivieren und unter System → Settings → Logging / Targets ein Ziel für die Anwendung suricata (Level info) anlegen, oder
- den Wazuh-Agent mit der Option Intrusion detection events nutzen – dann kommen die EVE-Events strukturiert im Open-Source-SIEM auf Wazuh-Basis an und können per Active Response weitere Sperren auslösen.
Suricata im Zusammenspiel
| Werkzeug | Ansatz | Zusammenspiel mit Suricata |
|---|---|---|
| CrowdSec | Verhaltenserkennung in Logs, Community-Blocklist | ergänzt: sperrt Angreifer-IPs vorab; Suricata prüft die erlaubten Verbindungen |
| Q-Feeds | Listen bösartiger IPs/Domains | ergänzt: vorbeugende Sperren per Alias und DNS |
| Zenarmor | Anwendungs- und Webkontrolle | nicht beide per netmap auf derselben Schnittstelle; Divert- oder IDS-Modus wählen |
| Maltrail | Erkennung verdächtiger Ziele | ähnliche Zielrichtung, andere Datenquellen |
Grenzen
- Verschlüsselter Verkehr: Suricata sieht bei TLS keine Inhalte, wertet aber Servernamen (SNI), Zertifikate, JA3/JA4-Fingerprints und DNS aus. Viele Malware-Regeln greifen genau dort.
- Leistung: Große Regelsätze und IPS kosten Durchsatz; Regeln für nicht genutzte Produkte deaktivieren und einen schnellen Pattern Matcher wählen.
- Pflege: Regelsätze täglich aktualisieren, Richtlinien gelegentlich überprüfen.
Typische Probleme
| Symptom | Lösung |
|---|---|
| Keine Alarme | Keine Regelsätze geladen oder aktiviert; Schnittstelle falsch (nur WAN); Dienst läuft nicht – Log File prüfen. |
| Netzwerk nach Wechsel auf Netmap (IPS) instabil oder langsam | Hardware-Offloading nicht deaktiviert; Netzwerkkarte ohne native netmap-Unterstützung (Tunable dev.netmap.admode=2 erzwingt den emulierten Modus) oder Divert-Modus verwenden.
|
| VLAN-Verkehr wird nicht geprüft | Bei Netmap IPS auf der Parent-Schnittstelle aktivieren. |
| Legitime Verbindungen werden blockiert | Betroffene SID im Reiter Alerts ermitteln und per Richtlinie auf alert oder disable setzen. |
| Nach Stopp von Suricata funktioniert ein Dienst nicht mehr | Divert-Regel aktiv – Suricata starten oder Divert-to in der Regel entfernen. |
| Hohe CPU-Last | Regelumfang reduzieren, Hyperscan nutzen, Bypass für internen Verkehr, Divert nur für relevante Regeln. |
Fazit
Suricata ist auf der OPNsense ohne Zusatzkosten verfügbar und mit wenigen Schritten einsatzbereit: Regelsätze laden, Richtlinien definieren, interne Schnittstellen schützen. Mit Suricata 8 und dem neuen Divert-Modus lässt sich die Inspektion seit OPNsense 26.1 gezielt auf ausgewählte Verbindungen beschränken – unabhängig von der Netzwerkkarte. Sauber eingeführt (erst beobachten, dann gezielt blockieren) und an ein SIEM angebunden, ist Suricata ein zentraler Baustein der Angriffserkennung im Unternehmensnetz.
Unterstützung von m.a.x. it
Sie möchten Suricata auf Ihrer OPNsense einführen, Richtlinien und Regelsätze abstimmen oder IDS-Alarme zentral im SIEM auswerten? m.a.x. it unterstützt Sie als OPNsense-Gold-Partner mit OPNsense-Firewall-Services von m.a.x. it, einer Managed Firewall und einem Managed SIEM von m.a.x. it.
Siehe auch
- OPNsense - Firewall-Regeln
- OPNsense - Bridge und transparente Firewall
- Suricata
- IDS
- IPS
- OPNsense - CrowdSec
- OPNsense - Q-Feeds Threat Intelligence
- OPNsense - Zenarmor Next-Generation-Firewall
- OPNsense - Wazuh-Agent
- OPNsense - Maltrail Erkennung von Schadverkehr
Links und Quellen
- OPNsense-Doku – Intrusion Prevention System
- OPNsense-Doku – How-to Feodo Tracker
- OPNsense-Doku – How-to IPS Bypass
- OPNsense-Doku – ET Pro Telemetry
- Suricata – Projektseite
- m.a.x. it – OPNsense-Firewall-Services
Über m.a.x. it Die m.a.x. Informationstechnologie AG ist seit über 30 Jahren IT-Partner mittelständischer und großer Unternehmen in München und bietet maßgeschneiderte Lösungen und Services in den Bereichen Cloud, Cybersecurity, Netzwerk, Windows, Linux und Softwareentwicklung. Sie haben eine Frage zu diesem Artikel oder brauchen Unterstützung?
