Erklärung IPS suricata.yml

Aus Xinux Wiki
Zur Navigation springen Zur Suche springen

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. 

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"
  • 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. 

nfq:
  mode: repeat
  repeat-mark: 1
  repeat-mask: 1
  • 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. 

default-log-dir: /var/log/suricata/

stats:
  enabled: yes
  interval: 8
  • 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. 

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

logging:
  default-log-level: notice
  outputs:
  - console:
      enabled: yes
  - file:
      enabled: yes
      level: info
      filename: suricata.log
  • 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

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

defrag:
  memcap: 32mb
  hash-size: 65536
  trackers: 65535
  max-frags: 65535
  prealloc: yes
  timeout: 60
  • 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

default-rule-path: /etc/suricata/rules
rule-files:
  - local.rules
classification-file: /etc/suricata/classification.config
reference-config-file: /etc/suricata/reference.config
  • 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. 

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

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
Abgerufen von „https://xinux.net/index.php?title=Erklärung_IPS_suricata.yml&oldid=72439“