Netzwerkforensik mit NetworkMiner: Von Suricata-Alert zur PCAP-Analyse

Aus Xinux Wiki
Version vom 23. Juli 2026, 07:42 Uhr von Thomas.will (Diskussion | Beiträge) (Die Seite wurde neu angelegt: „= Netzwerkforensik mit NetworkMiner: Von Suricata-Alert zur PCAP-Analyse = Dieser Artikel beschreibt den kompletten Workflow von der Konfiguration des PCAP-Lo…“)
(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)
Zur Navigation springen Zur Suche springen

Netzwerkforensik mit NetworkMiner: Von Suricata-Alert zur PCAP-Analyse

Dieser Artikel beschreibt den kompletten Workflow von der Konfiguration des PCAP-Loggings in Suricata über das Auslösen und Erkennen eines Beispielangriffs bis zur forensischen Analyse des zugehörigen Netzwerkverkehrs mit NetworkMiner.

Voraussetzungen

Benötigte Komponenten
  • Suricata-Sensor (IDS- oder inline-IPS-Modus) mit Zugriff auf das zu überwachende Netzsegment
  • Schreibrechte auf das Suricata-Log-Verzeichnis
  • NetworkMiner (Free oder Professional Edition) auf dem Analyse-Arbeitsplatz
  • Optional: Wazuh-Integration zur Alert-Sichtung

Im Folgenden wird `it2XX` als Platzhalter für den jeweiligen Suricata-Sensor verwendet.

Schritt 1: PCAP-Logging in Suricata aktivieren

Standardmäßig protokolliert Suricata nur Alerts nach eve.json, nicht den zugehörigen Rohtraffic. Damit später ein Alert mit dem passenden Netzwerkausschnitt verknüpft werden kann, muss das Output-Modul pcap-log im sguil-Modus aktiviert werden. In diesem Modus schreibt Suricata die PCAP-Dateien mit einem Zähler (pcap_cnt), der im jeweiligen Alert-Eintrag referenziert wird.

Konfigurationsdatei öffnen
  • vim /etc/suricata/suricata.yaml
Output-Sektion ergänzen
outputs:
  - pcap-log:
      enabled: yes
      filename: log.pcap
      limit: 1000mb
      max-files: 2000
      compression: none
      mode: sguil
      dir: /var/log/suricata/pcaps/
      use-stream-depth: no
      honor-pass-rules: no
Zielverzeichnis anlegen
  • mkdir -p /var/log/suricata/pcaps/
  • chown suricata:suricata /var/log/suricata/pcaps/
Suricata neu starten
  • systemctl restart suricata
Funktionskontrolle
  • systemctl status suricata
  • ls -la /var/log/suricata/pcaps/

Im sguil-Modus legt Suricata die Dateien nach Datum sortiert in Unterverzeichnissen ab, z. B. /var/log/suricata/pcaps/2026-07-23/.

Hinweis für OPNsense-basierte Sensoren: Die GUI unter Services → Intrusion Detection → Administration bietet meist kein direktes Feld für pcap-log. Die Direktive muss über das dafür vorgesehene Feld für zusätzliche Suricata-Konfiguration eingetragen werden, nicht durch direktes Editieren von /usr/local/etc/suricata/<interface>/suricata.yaml, da die GUI diese Datei bei jeder Änderung neu generiert.

Schritt 2: Beispielangriff auslösen

Als reproduzierbares und gefahrloses Beispiel eignet sich der Download der EICAR-Testdatei über einfaches HTTP. Die EICAR-Datei ist eine von der Antiviren-Industrie standardisierte, harmlose Testdatei, die von jeder Signatur-Engine als "Malware" erkannt wird, ohne selbst schädlich zu sein.

Angriff simulieren (vom Client aus)
curl -o eicar.com http://www.eicar.org/download/eicar.com

Da die Übertragung unverschlüsselt per HTTP erfolgt, greift sowohl die Suricata-Signatur für die EICAR-Testdatei als auch die Möglichkeit, die übertragene Datei später aus dem PCAP zu rekonstruieren.

Alternativ – für eine Demonstration mit Zugangsdaten im Klartext – bietet sich ein FTP-Login gegen einen Test-Server im Kursnetz an: 

ftp it2XX.int
# Benutzername/Passwort im Klartext eingeben

Schritt 3: Alert identifizieren

Rohen Alert direkt in eve.json prüfen
  • tail -f /var/log/suricata/eve.json | jq 'select(.event_type=="alert")'

Ein Alert-Eintrag zur EICAR-Signatur sieht auszugsweise so aus: 

{
  "timestamp": "2026-07-23T10:14:32.118421+0200",
  "flow_id": 1748239501774213,
  "pcap_cnt": 4821,
  "event_type": "alert",
  "src_ip": "172.26.52.50",
  "dest_ip": "172.26.52.10",
  "alert": {
    "signature": "ET POLICY EICAR Test File Download",
    "category": "Potentially Bad Traffic",
    "severity": 2
  }
}

Die relevanten Felder für die spätere PCAP-Zuordnung sind:

  • flow_id – eindeutige Kennung der gesamten Verbindung
  • pcap_cnt – Paketzähler innerhalb der PCAP-Rotation, über den sich die passende Datei bestimmen lässt
  • timestamp – zur groben zeitlichen Eingrenzung, falls mehrere PCAP-Dateien in Frage kommen
Alternative
Sichtung über Wazuh

Ist die OPNsense-Suricata-Integration in Wazuh eingebunden, erscheint derselbe Alert im Wazuh-Dashboard unter den Suricata-Eve-Regeln. Von dort lässt sich flow_id und pcap_cnt ebenfalls direkt aus dem Rohereignis (Raw Event) ablesen.

Schritt 4: Passende PCAP-Datei ermitteln und übertragen

Verzeichnis nach Zeitstempel filtern
  • ls -la /var/log/suricata/pcaps/2026-07-23/

Die Dateien sind fortlaufend nummeriert, z. B. log.pcap.1753258000, wobei die Zahl ein Unix-Timestamp ist. Anhand des Alert-Timestamps lässt sich die relevante Datei eingrenzen.

Datei auf den Analyse-Arbeitsplatz kopieren
scp root@it2XX.int:/var/log/suricata/pcaps/2026-07-23/log.pcap.1753258000 .
Optional
Ausschnitt vorab mit tcpdump eingrenzen

Bei großen Dateien empfiehlt es sich, vorab nach der betroffenen IP zu filtern, um die Datei für NetworkMiner zu verkleinern: 

tcpdump -r log.pcap.1753258000 -w eicar_incident.pcap host 172.26.52.50

Schritt 5: Analyse in NetworkMiner

PCAP laden
  • NetworkMiner öffnen → File → Open → eicar_incident.pcap auswählen
Übertragene Dateien prüfen
  • Reiter Files öffnen
  • Die übertragene eicar.com erscheint dort mit Quell-/Ziel-IP, Zeitstempel und Dateigröße
  • Rechtsklick → Open File bzw. Open Folder zeigt die vollständig rekonstruierte Datei
Sitzungsdetails nachvollziehen
  • Reiter Sessions zeigt die zugehörige TCP-Verbindung inklusive Ports und Protokoll (hier: HTTP)
  • Reiter Hosts zeigt OS-Fingerprint und weitere Metadaten des Quellhosts
Beim FTP-Beispiel
Zugangsdaten extrahieren
  • Reiter Credentials listet bei Klartext-Protokollen (FTP, HTTP Basic Auth, Telnet) automatisch erkannte Benutzername/Passwort-Paare inklusive der Verbindung, in der sie aufgetreten sind

Schritt 6: Einordnung des Befunds

Der Abgleich zwischen Alert und rekonstruierter Datei bestätigt: Der Suricata-Alert ET POLICY EICAR Test File Download bezog sich auf die tatsächlich übertragene Datei eicar.com, deren Inhalt in NetworkMiner vollständig einsehbar ist. Für reale Vorfälle liefert dieser Workflow denselben Mehrwert – statt einer reinen Signatur-Meldung liegt der tatsächlich übertragene Inhalt (Payload, Datei, Zugangsdaten) zur Bewertung vor, etwa um zwischen False Positive und echtem Datenabfluss zu unterscheiden.

Zusammenfassung des Workflows

  1. pcap-log im sguil-Modus in Suricata aktivieren
  2. Angriff/Testereignis auslösen
  3. Alert in eve.json oder Wazuh identifizieren, flow_id/pcap_cnt/timestamp notieren
  4. Passende PCAP-Datei anhand Zeitstempel im Log-Verzeichnis finden
  5. Optional mit tcpdump auf relevante IP eingrenzen
  6. PCAP in NetworkMiner laden und über Files/Sessions/Credentials auswerten

Siehe auch

Abgerufen von „http://xinux.net/index.php?title=Netzwerkforensik_mit_NetworkMiner:_Von_Suricata-Alert_zur_PCAP-Analyse&oldid=72122“