Thomas.will: Die Seite wurde neu angelegt: „== Suricata-Konfiguration: suricata.yaml == Diese Konfiguration richtet Suricata als '''IPS/IDS im NFQ-Modus''' ein, das Pakete von iptables/nftables via NFQU…“

2026-08-04T11:46:05Z

Die Seite wurde neu angelegt: „== Suricata-Konfiguration: suricata.yaml == Diese Konfiguration richtet Suricata als '''IPS/IDS im NFQ-Modus''' ein, das Pakete von iptables/nftables via NFQU…“

Neue Seite

== Suricata-Konfiguration: suricata.yaml ==

Diese Konfiguration richtet Suricata als '''IPS/IDS im NFQ-Modus''' ein, das Pakete von iptables/nftables via NFQUEUE übernimmt, analysiert und das Verdikt zurückgibt.

=== Adressgruppen (vars) ===

;Beschreibung
Definiert Variablen für Netzsegmente, die in Regeln (local.rules) als $HOME_NET, $DMZ usw. referenziert werden können, statt IP-Bereiche hart zu codieren.

<syntaxhighlight lang="yaml">
vars:
address-groups:
LAN: "[172.26.2XX.0/24]"
DMZ: "[10.88.2XX.0/24]"
SERVER: "[10.2XX.1.0/24]"
INT: "[$LAN,$DMZ,$SERVER]"
HOME_NET: "$INT"
EXTERNAL_NET: "!$INT"
</syntaxhighlight>

* '''LAN / DMZ / SERVER''' – die drei internen Segmente des Labors
* '''INT''' – Sammelvariable aus allen drei Segmenten
* '''HOME_NET''' – wird auf $INT gesetzt → alles "Eigene" gilt als vertrauenswürdig referenzierbar
* '''EXTERNAL_NET''' – Negation von $INT (!$INT) → alles außerhalb der eigenen Netze gilt als extern

Diese Trennung ist entscheidend für Regeln wie alert tcp $EXTERNAL_NET any -> $HOME_NET any, die nur eingehenden Traffic von außen betrachten.

=== NFQ-Modus ===

;Beschreibung
Legt fest, wie Suricata mit der Linux-Netfilter-Queue interagiert.

<syntaxhighlight lang="yaml">
nfq:
mode: repeat
repeat-mark: 1
repeat-mask: 1
</syntaxhighlight>

* mode: repeat – das Paket wird nach der Analyse erneut durch die Firewall-Regelkette geschickt (statt es direkt zu akzeptieren/verwerfen)
* repeat-mark / repeat-mask – das Paket wird mit einer Markierung (mark 1) versehen, damit iptables/nftables es beim zweiten Durchlauf erkennt und nicht erneut an die Queue schickt (Endlosschleife vermeiden)

Das ist der klassische Suricata-Inline-IPS-Aufbau: iptables -I FORWARD -j NFQUEUE --queue-num 0 (oder äquivalent in nftables) → Suricata prüft → Paket erneut durch die Kette mit gesetztem Mark → Firewall lässt es durch oder verwirft es je nach Verdikt.

=== Logging & Statistiken ===

;Beschreibung
Grundlegende Log-Pfade und Intervall für interne Statistiken.

<pre>
default-log-dir: /var/log/suricata/

stats:
enabled: yes
interval: 8
</pre>

* default-log-dir – Standardverzeichnis für alle Logdateien
* stats.enabled – aktiviert interne Performance-/Durchsatzstatistiken
* stats.interval – Statistik wird alle 8 Sekunden aktualisiert (Standard wäre meist 30s; kurzes Intervall eignet sich gut für Labor/Debugging, ist aber im Dauerbetrieb unnötig I/O-lastig)

=== Outputs ===

;Beschreibung
Definiert, welche Log-Formate Suricata schreibt und was darin enthalten ist.

<syntaxhighlight lang="yaml">
outputs:
- fast:
enabled: yes
filename: fast.log
append: yes
- alert-debug:
enabled: yes
filename: alert-debug.log
append: yes
- stats:
enabled: yes
filename: stats.log
append: yes
totals: yes
threads: no
- eve-log:
enabled: yes
filetype: regular
filename: eve.json
types:
- alert
- drop
- http
- dns
- tls
- flow
- ssh
- stats
</syntaxhighlight>

* '''fast.log''' – kompaktes, menschenlesbares Ein-Zeilen-Alert-Format, gut zum schnellen Überfliegen
* '''alert-debug.log''' – sehr ausführliches Alert-Log mit internen Details (Paketinhalt, Signatur-Metadaten), primär für Regel-Debugging gedacht, im Produktivbetrieb meist deaktiviert wegen Größe
* '''stats.log''' – periodische Textstatistik (Durchsatz, Drops, Speichernutzung); totals: yes aggregiert über alle Threads, threads: no unterdrückt Pro-Thread-Aufschlüsselung
* '''eve.json''' – das wichtigste Output-Format: strukturiertes JSON, das von SIEM-Systemen (hier: Wazuh) eingelesen wird
** types – legt fest, welche Event-Typen ins eve.json geschrieben werden: alert (IDS/IPS-Treffer), drop (im Inline-Modus verworfene Pakete), sowie Protokoll-Metadaten zu http, dns, tls, flow, ssh und stats

;Hinweis für den SOC-Kurs
pcap-log fehlt hier bewusst (noch) – für POCs, bei denen zu einem Alert das zugehörige Rohpaket z. B. für eine spätere NetworkMiner-Analyse extrahiert werden soll, müsste dieser Output ergänzt werden.

=== Logging-Einstellungen (Suricata selbst) ===

;Beschreibung
Nicht zu verwechseln mit outputs (Netzwerk-Events) – dieser Block steuert, wie Suricata über sich selbst (Start, Fehler, Warnungen) protokolliert.

<pre>
logging:
default-log-level: notice
outputs:
- console:
enabled: yes
- file:
enabled: yes
level: info
filename: suricata.log
</pre>

* default-log-level: notice – Standard-Schwellwert für Log-Meldungen
* console – Ausgabe zusätzlich auf die Konsole/systemd-journal (nützlich bei systemctl status suricata oder journalctl -u suricata)
* file – separates Betriebslog (suricata.log) mit Level info, unabhängig von den eve.json-Netzwerk-Events

=== Prozess- und Systemeinstellungen ===

<pre>
pid-file: /var/run/suricata.pid

coredump:
max-dump: unlimited

host-mode: auto

unix-command:
enabled: yes
filename: /var/run/suricata-command.socket

engine-analysis:
rules-fast-pattern: yes
rules: yes
</pre>

* pid-file – Prozess-ID-Datei für Init-System/Monitoring
* coredump.max-dump: unlimited – bei einem Absturz wird ein vollständiger Core-Dump geschrieben (hilfreich zum Debuggen, sollte in Produktivumgebungen ggf. eingeschränkt werden)
* host-mode: auto – Suricata erkennt selbst, ob es als Router (Traffic für viele Hosts) oder als Sniffer für einen einzelnen Host arbeitet; beeinflusst u. a. Stream-Reassembly-Verhalten
* unix-command – öffnet ein Unix-Socket für die Laufzeitsteuerung via suricatasc (z. B. Regeln neu laden ohne Neustart: reload-rules)
* engine-analysis – erzeugt beim Start Analyse-Reports (rules-fast-pattern.txt, rules.txt) im Log-Verzeichnis, die zeigen, wie Suricata die Regeln intern optimiert hat (nützlich für Regel-Tuning)

=== Defragmentierung ===

;Beschreibung
Steuert, wie fragmentierte IP-Pakete vor der Analyse wieder zusammengesetzt werden.

<pre>
defrag:
memcap: 32mb
hash-size: 65536
trackers: 65535
max-frags: 65535
prealloc: yes
timeout: 60
</pre>

* memcap – maximaler Speicher für den Defragmentierungs-Puffer
* hash-size / trackers / max-frags – Größe der internen Tracking-Strukturen für gleichzeitig offene Fragment-Ketten
* prealloc: yes – Speicher wird beim Start reserviert statt dynamisch (bessere Performance, etwas höherer Grundverbrauch)
* timeout: 60 – nach 60 Sekunden ohne vollständige Reassemblierung wird die Fragmentkette verworfen

=== Regeln ===

<pre>
default-rule-path: /etc/suricata/rules
rule-files:
- local.rules
classification-file: /etc/suricata/classification.config
reference-config-file: /etc/suricata/reference.config
</pre>

* default-rule-path – Basisverzeichnis für Regeldateien
* rule-files – hier wird ausschließlich local.rules geladen; es sind (noch) keine Community-Regelsätze (z. B. ET Open, über suricata-update) eingebunden – im Kurs vermutlich bewusst so gehalten, um mit eigenen, nachvollziehbaren Regeln zu arbeiten
* classification-file – ordnet Alert-Klassen (z. B. attempted-recon) Schweregrade zu, wird u. a. für die Priorisierung in eve.json/Wazuh genutzt
* reference-config-file – definiert, wie externe Referenzen in Regeln (z. B. reference:cve,...) aufgelöst/verlinkt werden

=== App-Layer-Protokolle ===

;Beschreibung
Aktiviert Protokoll-Parser, die Suricata befähigen, den jeweiligen Anwendungsschicht-Traffic inhaltlich zu verstehen (nicht nur als rohe TCP/UDP-Bytes), was Voraussetzung für protokollspezifische Alerts (z. B. http.uri, tls.sni) und die entsprechenden Metadaten-Logs in eve.json ist.

<syntaxhighlight lang="yaml">
app-layer:
protocols:
http:
enabled: yes
tls:
enabled: yes
dcerpc:
enabled: yes
smb:
enabled: yes
ftp:
enabled: yes
ssh:
enabled: yes
smtp:
enabled: yes
dns:
enabled: yes
modbus:
enabled: yes
enip:
enabled: yes
dnp3:
enabled: yes
nfs:
enabled: yes
ntp:
enabled: yes
tftp:
enabled: yes
ikev2:
enabled: yes
krb5:
enabled: yes
dhcp:
enabled: yes
snmp:
enabled: yes
sip:
enabled: yes
rfb:
enabled: yes
mqtt:
enabled: yes
rdp:
enabled: yes
http2:
enabled: yes
imap:
enabled: yes
</syntaxhighlight>

Bemerkenswert ist, dass hier praktisch ''alle'' verfügbaren Parser aktiviert sind – inklusive Industrie-/OT-Protokolle wie modbus, enip und dnp3, die in einem klassischen DMZ/SOC-Lab eher unüblich sind. Das erhöht den CPU-Overhead geringfügig, hat aber für ein Übungs-/Kurssystem keine praktische Relevanz und deckt bewusst ein möglichst breites Analyse-Spektrum ab.

;Kurzübersicht der Protokollgruppen
* '''Web/Mail''': http, http2, tls, smtp, imap
* '''Windows/Fileservices''': dcerpc, smb, rdp
* '''Klassische Dienste''': ftp, ssh, dns, ntp, tftp, dhcp, snmp, nfs
* '''VPN/Auth''': ikev2, krb5
* '''IoT/Sonstiges''': mqtt, rfb (VNC), sip
* '''OT/Industrie (ICS/SCADA)''': modbus, enip, dnp3

Erklärung IPS suricata.yml - Versionsgeschichte

Thomas.will: Die Seite wurde neu angelegt: „== Suricata-Konfiguration: suricata.yaml == Diese Konfiguration richtet Suricata als '''IPS/IDS im NFQ-Modus''' ein, das Pakete von iptables/nftables via NFQU…“