Intrusion Detection Systeme (IDS) und Intrusion Prevention Systeme (IPS) sind zentrale Bausteine moderner Netzwerksicherheit.
Obwohl beide Konzepte eng miteinander verwandt sind, unterscheiden sie sich grundlegend in ihrer Wirkungsweise und ihrem Einsatzzweck.
Ein IDS ist ein passives Überwachungssystem. Es analysiert den Netzwerkverkehr oder Systemereignisse und erzeugt Alarme,
wenn es verdächtige Muster erkennt – greift jedoch selbst nicht ein. Das IDS ist typischerweise als Netzwerk-TAP oder SPAN-Port
angebunden und „sieht" den Traffic, ohne ihn zu beeinflussen. Es eignet sich besonders für die nachgelagerte Analyse,
Forensik und das Erkennen von Vorfällen, ohne den Produktivbetrieb zu gefährden.
Ein IPS hingegen ist inline im Datenpfad platziert. Es kann nicht nur erkennen, sondern aktiv reagieren –
also Pakete verwerfen, Verbindungen zurücksetzen oder Traffic auf Basis von Regeln blockieren. Damit bietet es deutlich
stärkeren Schutz, bringt aber auch ein höheres Risiko mit sich: Fehlerhafte Regeln oder False Positives können legitimen
Traffic blockieren und den Betrieb stören.
1.1 Erkennungsmethoden: Signaturbasiert vs. Anomaliebasiert
Grundsätzlich gibt es zwei Erkennungsansätze:
Signaturbasierte Erkennung arbeitet mit einer Datenbank bekannter Angriffsmuster. Jede Signatur beschreibt
ein spezifisches Merkmal eines Angriffs – z. B. eine bestimmte Byte-Sequenz im Payload, einen auffälligen HTTP-Header
oder einen charakteristischen DNS-Query. Diese Methode ist sehr präzise bei bekannten Angriffen, erkennt aber keine
Zero-Day-Exploits, für die noch keine Signatur existiert. Suricata und Snort arbeiten primär nach diesem Prinzip.
Anomaliebasierte Erkennung baut ein Baseline-Modell des „normalen" Netzwerkverhaltens auf und schlägt
Alarm, wenn Abweichungen festgestellt werden – etwa ungewöhnlich hohe Verbindungsraten, unbekannte Protokollkombinationen
oder Zugriffsmuster außerhalb der Norm. Dieser Ansatz kann theoretisch auch unbekannte Angriffe erkennen, produziert aber
in der Praxis deutlich mehr False Positives und erfordert sorgfältiges Tuning. Viele kommerzielle Lösungen kombinieren
beide Ansätze.
1.2 Einsatzbereiche im Überblick
Im Netzwerkperimeter schützt ein IPS typischerweise den Übergang zwischen Internet und internem Netz. Im internen Netz
können IDS-Sensoren an strategischen Punkten platziert werden – etwa am Switch-SPAN-Port zwischen verschiedenen VLANs –
um laterale Bewegungen von Angreifern zu erkennen, die bereits eine erste Sicherheitsschicht überwunden haben.
Host-basierte IDS-Lösungen (HIDS) wie OSSEC oder Wazuh ergänzen netzwerkbasierte Ansätze durch die Überwachung von
Dateiintegrität, Systemaufrufen und Log-Dateien direkt auf dem Endpunkt.
2. Suricata – Architektur und Funktionsweise
Suricata ist ein modernes, quelloffenes IDS/IPS-Framework, das von der Open Information Security Foundation (OISF)
entwickelt wird. Es ist der De-facto-Standard im Open-Source-Bereich und wird sowohl in Homelabs als auch in
Enterprise-Umgebungen eingesetzt. Suricata ist in C geschrieben, steht unter der GPLv2 und wird aktiv weiterentwickelt.
2.1 Multi-Threading
Im Gegensatz zum älteren Snort, das traditionell single-threaded arbeitet, nutzt Suricata von Grund auf Multi-Threading.
Traffic-Capture, Paketdecodierung, Stream-Reassembly, Protokollerkennung und Regelauswertung laufen in separaten Threads,
die über eine interne Work-Queue koordiniert werden. Das erlaubt es Suricata, auf modernen Mehrkern-Systemen die volle
CPU-Kapazität zu nutzen und auch bei hohem Durchsatz von mehreren Gigabit pro Sekunde effizient zu arbeiten.
Die Anzahl der Worker-Threads ist in suricata.yaml über den Parameter threading.set-cpu-affinity
konfigurierbar.
2.2 Regelformat
Das Regelformat von Suricata orientiert sich stark an Snort-Regeln und ist zu einem großen Teil kompatibel.
Eine Regel setzt sich aus drei Teilen zusammen: Aktion, Header (Protokoll, Quell-/Zieladresse, Ports) und Regeloptionen.
Die Aktion (alert, drop, reject, pass) bestimmt, was passiert,
wenn eine Regel matcht. alert erzeugt nur einen Log-Eintrag; drop verwirft das Paket –
allerdings nur im IPS-Modus. Im IDS-Modus wird drop intern als alert behandelt.
2.3 Protokoll-Dissection und App-Layer-Erkennung
Suricata verfügt über eigene Protokoll-Parser für HTTP, TLS, DNS, SSH, SMTP, SMB und viele weitere Protokolle. Diese
App-Layer-Erkennung erlaubt es, Regeln auf rekonstruierte Protokollfelder zu schreiben – z. B. den HTTP-Host-Header,
den HTTP-URI oder den TLS-SNI-Wert – statt nur auf rohe Bytes im Paket. Das macht Regeln präziser und weniger anfällig
für einfache Evasion-Techniken wie Zeichenkodierung oder Fragmentation. Über das Lua-Scripting-Interface lassen sich
zudem eigene Protokoll-Parser und komplexe Erkennungslogiken implementieren.
2.4 Ausgabeformate
Suricata kann Ereignisse in verschiedenen Formaten ausgeben. Das wichtigste ist EVE-JSON (Extensible Event Format),
ein strukturiertes JSON-Format, das sich hervorragend für die Weiterverarbeitung in Log-Management-Systemen eignet.
Daneben gibt es das klassische Unified2-Format (Snort-kompatibel, für barnyard2) sowie einfache Textlogs.
Für neue Deployments empfiehlt sich ausschließlich EVE-JSON.
3. Regelwerke und Signaturen
Die Qualität eines IDS/IPS steht und fällt mit den verwendeten Regelwerken. Es gibt eine Reihe etablierter Quellen,
die regelmäßig gepflegte Signaturdatenbanken bereitstellen.
3.1 Emerging Threats (ET)
Die Emerging Threats-Regelwerke von Proofpoint sind die am weitesten verbreiteten für Suricata.
ET Open ist kostenlos verfügbar und enthält mehrere tausend Regeln für aktuelle Bedrohungen –
Malware-C2-Kommunikation, Exploit-Kits, Scanning, DDoS-Tools und vieles mehr. Die Regeln werden täglich aktualisiert.
ET Pro ist ein kommerzielles Erweiterungspaket mit schnelleren Updates und mehr Regeln, insbesondere
für aktuelle APT-Kampagnen. Für ein Homelab ist ET Open vollkommen ausreichend.
3.2 Snort Community Rules und PT Research
Die Snort Community Rules sind ebenfalls kostenlos verfügbar und zu Suricata weitgehend kompatibel,
allerdings weniger aktuell als ET Open. Positive Technologies (PT) Research Rules fokussieren sich auf
ICS/SCADA-Protokolle und spezifische APT-Aktivitäten – relevant für Umgebungen mit industriellen Steuerungssystemen.
Daneben existieren spezialisierte Regelwerke wie die ETLABS-ThreatFox-Regeln, die auf aktuellen IoC-Feeds
(Indicators of Compromise) basieren und bekannte C2-Server-IPs sowie Domainnamen abdecken.
3.3 Regeln aktivieren und deaktivieren mit suricata-update
Das offizielle Werkzeug zur Verwaltung von Regelquellen ist suricata-update. Es lädt Regelwerke herunter,
merged sie und kann gezielt Regeln aktivieren oder deaktivieren.
# Verfügbare Regelquellen auflisten
suricata-update list-sources
# ET Open als Quelle aktivieren
suricata-update enable-source et/open
# Alle Regeln aktualisieren und zusammenführen
suricata-update
# Einzelne Regel per SID deaktivieren (disable.conf)
# /etc/suricata/disable.conf:
# 2100498
# Regeln nach Kategorie deaktivieren (z. B. gesamte P2P-Kategorie)
# /etc/suricata/disable.conf:
# re:emerging-p2p
# Suricata-Regeln ohne Neustart neu laden (SIGUSR2)
kill -USR2 $(pidof suricata)
4. Suricata in OPNsense
OPNsense ist eine auf FreeBSD basierende Open-Source-Firewall-Distribution, die Suricata als Plugin
mitbringt. Die Integration ist tief: Suricata kann direkt über die Weboberfläche konfiguriert, überwacht und gesteuert werden,
ohne dass SSH-Zugriff oder manuelle Konfigurationsdatei-Bearbeitung nötig sind.
4.1 Installation
Das Suricata-Plugin wird über den OPNsense Package Manager installiert:
System → Firmware → Plugins → os-suricata suchen und installieren.
Nach der Installation findet sich Suricata unter Services → Intrusion Detection.
Eine zusätzliche Konfiguration des Betriebssystems ist nicht erforderlich; OPNsense verwaltet die Suricata-Konfiguration
vollständig über seine eigene Datenbank.
4.2 Interface-Auswahl und Betriebsmodus
Im Tab Administration wählt man zunächst das zu überwachende Interface – in der Regel das WAN-Interface
(igb0 o. ä.) für eingehenden Traffic, oder das LAN-Interface für ausgehenden Traffic aus dem eigenen Netz.
Sollen mehrere Interfaces überwacht werden, kann Suricata auf jedem separat aktiviert werden.
Der entscheidende Schalter ist IDS/IPS-Modus: Im reinen IDS-Modus analysiert Suricata den Traffic passiv
und erzeugt nur Alerts. Im IPS-Modus wird Suricata inline geschaltet – unter OPNsense wird hierfür intern NetMap oder
ipfw-Divert verwendet, sodass Pakete mit einer drop-Regel tatsächlich verworfen werden. Der Wechsel
in den IPS-Modus ist mit einem einzelnen Mausklick möglich, sollte aber erst nach ausreichendem IDS-Betrieb und
Regeltuning erfolgen.
4.3 Regelsets konfigurieren
Im Tab Download lassen sich die gewünschten Regelwerke aktivieren. ET Open ist in OPNsense voreingestellt
und kann mit einem Klick abonniert werden. Jeder Regelset zeigt seine Kategorien an, die einzeln aktiviert oder
deaktiviert werden können. Nach dem Aktivieren und dem Download startet OPNsense Suricata automatisch neu bzw.
lädt die neuen Regeln. Ein automatischer Download-Zeitplan (täglich, wöchentlich) ist ebenfalls konfigurierbar.
4.4 Alerts anzeigen und auswerten
Ausgelöste Alarme sind unter Services → Intrusion Detection → Alerts sichtbar. Die Tabelle zeigt Zeitstempel,
Quell- und Zieladresse, Protokoll, Regel-SID und die zugehörige Nachricht. Über das Filter-Feld können gezielt SIDs,
IP-Adressen oder Nachrichtentexte gesucht werden. Direkt aus der Alert-Ansicht heraus können Regeln mit einem Klick
deaktiviert oder in die Suppress-Liste aufgenommen werden, was das tägliche Tuning erheblich vereinfacht.
5. Inline-IPS-Modus unter Linux
Auf einem Linux-System ohne OPNsense gibt es zwei verbreitete Wege, Suricata im echten IPS-Modus zu betreiben:
AF_PACKET mit einem realen Netzwerkpfad oder NFQ (Netfilter Queue) über den
Linux-Kernelpaketfilter.
5.1 AF_PACKET IPS-Modus
Im AF_PACKET-IPS-Modus bindet Suricata zwei Netzwerk-Interfaces zu einem Software-Inline-Paar zusammen und leitet
alle Pakete durch seine eigene Verarbeitungspipeline. Pakete, die keine Regel matchen, werden weitergeleitet;
Pakete, auf die eine drop-Regel zutrifft, werden verworfen. Dieser Modus eignet sich für dedizierte
IPS-Appliances, die zwischen zwei Netzsegmenten platziert werden.
Der NFQ-Modus nutzt die Netfilter-Queue des Linux-Kernels. iptables oder nftables leitet Traffic in eine Queue,
Suricata liest ihn aus, bewertet ihn und gibt ihn entweder frei oder lässt ihn fallen.
Dieser Modus eignet sich besonders, wenn Suricata auf dem Gateway-Host selbst läuft, ohne dass ein zweites
Interface benötigt wird.
# iptables: eingehenden und weitergeleiteten Traffic in Queue 0 leiten
iptables -I INPUT -j NFQUEUE --queue-num 0
iptables -I FORWARD -j NFQUEUE --queue-num 0
# Suricata im NFQ-Modus starten
suricata -c /etc/suricata/suricata.yaml -q 0
5.3 False Positives im IPS-Modus und Tuning
Der größte Unterschied zwischen IDS und IPS im Alltag ist das Risiko durch False Positives.
Im IDS-Modus erzeugt eine fehlerhafte Regel nur einen unnötigen Alert; im IPS-Modus wird legitimer Traffic geblockt.
Daher empfiehlt sich folgendes Vorgehen beim Wechsel in den IPS-Modus: Zunächst den IDS-Modus einige Wochen betreiben
und alle ausgelösten Regeln dokumentieren. Regeln, die auf eigenen, legitimen Traffic ansprechen, werden deaktiviert
oder mit einer Suppress-Rule versehen. Erst dann sollte in den IPS-Modus gewechselt werden – und auch dann zunächst
nur mit einem eingeschränkten, sorgfältig kurierten Regelset.
6. EVE-JSON Logs und zentrale Log-Analyse
EVE-JSON ist das strukturierte Logging-Format von Suricata. Alle Ereignistypen – Alerts, DNS-Anfragen,
HTTP-Requests, TLS-Handshakes, Flows, Dateiübertragungen – werden in ein einheitliches JSON-Format geschrieben,
standardmäßig nach /var/log/suricata/eve.json. Jede Zeile in dieser Datei ist ein vollständiges JSON-Objekt,
was die maschinelle Weiterverarbeitung sehr einfach macht.
Das Feld event_type unterscheidet zwischen alert, dns, http,
tls, flow und weiteren Typen. Das erlaubt eine präzise Filterung im Log-Management-System.
Die flow_id verknüpft alle Events desselben TCP/UDP-Flows miteinander, sodass der vollständige Kontext
eines Angriffs rekonstruierbar ist.
6.2 Integration mit ELK, Graylog und Loki
EVE-JSON lässt sich nahtlos in gängige Log-Management-Plattformen integrieren:
ELK Stack (Elasticsearch, Logstash, Kibana): Filebeat auf dem Suricata-Host liest eve.json
und schickt die Ereignisse an Logstash oder direkt an Elasticsearch. Das offizielle Suricata-Modul für Filebeat
liefert fertige Dashboards für Kibana – Alerts nach Kategorie, Top-Quellen, DNS-Anfragen und Flow-Statistiken.
Graylog: Über einen GELF-Output in Suricata oder via Filebeat und Syslog kann EVE-JSON direkt in Graylog
eingespielt werden. Graylog eignet sich besonders für kleinere Umgebungen, da es einfacher zu betreiben ist als ein
vollständiger ELK-Stack, und bietet mit seinen Streams und Alerts eine praktische Echtzeit-Benachrichtigung.
Grafana Loki: Promtail liest eve.json und sendet die Logs an Loki. In Grafana lassen sich
dann Dashboards bauen, die Suricata-Alerts mit Metriken aus anderen Quellen kombinieren. Für Homelab-Setups, die bereits
einen Grafana/Prometheus-Stack betreiben, ist Loki oft der schlankste Einstieg.
Kein Regelwerk ist perfekt. In realen Umgebungen – erst recht im Homelab – werden etablierte Regelwerke wie ET Open
regelmäßig legitimen Traffic als verdächtig einstufen. Ein pragmatischer Umgang mit False Positives ist daher essenziell,
um die Alarmermüdung (Alert Fatigue) zu vermeiden und das IDS/IPS langfristig nutzbar zu halten.
7.1 Suppress-Rules
Suppress-Rules sagen Suricata, dass bestimmte Regeln für bestimmte Quell- oder Zieladressen nicht ausgelöst werden sollen.
Sie werden in der Datei /etc/suricata/threshold.conf gepflegt und über suricata.yaml
eingebunden (threshold-file: /etc/suricata/threshold.conf).
# /etc/suricata/threshold.conf
# SID 2010935 für alle Quell-IPs vollständig unterdrücken
suppress gen_id 1, sig_id 2010935
# SID 2001219 nur für eine bestimmte interne IP unterdrücken
suppress gen_id 1, sig_id 2001219, track by_src, ip 192.168.1.50
# SID 2019284 für ein ganzes Subnetz unterdrücken
suppress gen_id 1, sig_id 2019284, track by_src, ip 192.168.0.0/16
7.2 Threshold – Frequenzbasierte Unterdrückung
Threshold-Einträge erlauben es, Alerts nur dann auszulösen, wenn ein Ereignis eine bestimmte Häufigkeit überschreitet.
Das ist sinnvoll bei Regeln, die einzelne Pakete erkennen, die in normalen Flows vorkommen, aber in großer Menge
auf einen Angriff hinweisen – etwa bei Portscanning-Detektoren.
# Alert für SID 2009358 erst auslösen, wenn dieselbe Quelle
# innerhalb von 60 Sekunden mehr als 5 Mal matched
threshold gen_id 1, sig_id 2009358, type threshold, \
track by_src, count 5, seconds 60
# Alert maximal einmal pro Minute pro Quell-IP ausgeben (both-Modus)
threshold gen_id 1, sig_id 2009358, type both, \
track by_src, count 1, seconds 60
7.3 Eigene Regelausnahmen schreiben
Für komplexere Szenarien kann eine eigene pass-Regel in einer lokalen Regeldatei angelegt werden.
In Suricata haben pass-Regeln eine höhere Priorität als alert- oder drop-Regeln
auf denselben Traffic, sofern die Regelreihenfolge korrekt konfiguriert ist (rule-files in
suricata.yaml; lokale Regeln sollten zuerst geladen werden).
# /etc/suricata/rules/local.rules
# Legitimen NTP-Traffic vom eigenen Zeitserver nicht als UDP-Flood flaggen
pass udp 192.168.1.1 any -> any 123 (
msg:"Lokaler NTP-Server - kein Alert";
sid:9000001;
rev:1;
)
# Eigenen Vulnerability-Scanner nicht als Portscan erkennen
pass tcp 192.168.1.200 any -> $HOME_NET any (
msg:"Interner Scanner - erlaubt";
sid:9000002;
rev:1;
)
7.4 Pragmatisches Vorgehen im Homelab
Im Homelab gilt: Lieber ein gut gepflegtes kleines Regelset als ein riesiges, ungepflegtes mit hunderten täglicher
False Positives. Empfehlenswert ist folgender Ansatz: Mit ET Open starten, aber zunächst nur die Kategorien
emerging-malware, emerging-exploit und emerging-trojan aktivieren. Kategorien wie
emerging-p2p, emerging-games oder emerging-policy erzeugen in vielen Heimnetzwerken
mehr Rauschen als Erkenntnisse.
Wöchentlich einen Blick auf die häufigsten Alert-SIDs werfen und gezielt entscheiden: Ist das ein echter Befund,
ein False Positive oder eine Regel, die für die eigene Umgebung schlicht irrelevant ist? Auf dieser Basis das
threshold.conf und die local.rules schrittweise ausbauen. So entsteht über Zeit ein
Regelset, das zur eigenen Umgebung passt und tatsächlich verwertbare Signale liefert – anstatt jeden Morgen
hunderte bedeutungsloser Alerts zu produzieren, die niemand mehr liest.