Network-Hunting mit Zeek und Suricata: Deployment, Rule-Tuning, TLS-Parsing und Alert-to-Case-Prozesse

Network-Hunting mit Zeek und Suricata ist dann besonders wirksam, wenn es nicht als „noch ein Sensor“ verstanden wird, sondern als Betriebsdisziplin: saubere Capture-Architektur, kontrolliertes Rule-Tuning, belastbare TLS-Metadaten und ein Prozess, der Alerts in nachvollziehbare Cases überführt. Zeek (Network Security Monitor, erzeugt strukturierte Protokoll- und Flow-Metadaten) und Suricata (IDS/IPS-Engine, prüft Traffic gegen Signaturen und Protokollregeln) ergänzen sich sehr gut – aber nur, wenn Deployment und Datenpfad stimmen.

Dieser Beitrag richtet sich an Administratoren und Operatoren, die pragmatisch starten wollen: Welche Sensor-Topologie funktioniert in der Praxis? Wie vermeiden Sie, dass 10.000 Alerts am Tag die Teams lähmen? Was ist beim TLS-Parsing noch möglich, obwohl Inhalte verschlüsselt sind? Und wie bauen Sie einen Alert-to-Case-Prozess, der in Audit, Incident Response und Alltag standhält?

Network-Hunting mit Zeek und Suricata in der Praxis

Zeek ist stark, wenn Sie aus Rohpaketen schnell verwertbare Metadaten machen wollen: Verbindungsdaten (5-Tuple, Dauer, Bytes), Protokoll-Ereignisse (z. B. DNS-Queries, HTTP-Header, TLS-Handshake-Daten) und Dateimetadaten. Suricata ist stark, wenn Sie bekannte Muster erkennen möchten: Signaturen (klassisch „Rules“), Protokoll-Decoder, Anomalie-Erkennung und – je nach Betriebsmodus – auch Inline-Blockieren als IPS.

In Hunting-Setups ist Suricata meist als IDS (passiv) sinnvoll, weil Inline-IPS schnell zu Verfügbarkeitsrisiken führt: falsch-positive Drops, asymmetrisches Routing, Session-Reassembly-Probleme. Zeek bleibt passiv und ist dafür oft „ehrlicher“ in der Datenqualität – sofern Capture und Zeitstempel sauber sind.

Wichtig ist die Erwartungshaltung: Bei TLS sehen Sie in der Regel keine Inhalte, aber sehr viele Signale aus dem Handshake und aus dem Verbindungsverhalten. Das reicht für viele Fragestellungen (C2-Indikatoren, ungewöhnliche Zielketten, verdächtige SNI, Zertifikatsauffälligkeiten), ersetzt aber keine Host-Telemetrie.

Deployment-Architektur: TAP vs. SPAN, Sensorplatzierung und Rückfallstrategie

Die größte Fehlerquelle beim Sensor-Deployment ist nicht die Software, sondern der Netzwerkzugang. Für Zeek/Suricata brauchen Sie Packet Capture (PCAP) oder AF_PACKET/DPDK-basierte Erfassung. Entscheidend sind: vollständige Sichtbarkeit, keine Paketverluste und korrekte Zeitsynchronisation.

TAP oder SPAN?

Ein TAP (Test Access Point) ist eine physische Abzweigung, die typischerweise stabiler ist: Er spiegelt Bits ohne Switch-„Interpretation“. Ein SPAN/Mirror-Port auf Switches ist oft schneller verfügbar, bringt aber typische Stolperfallen mit: Oversubscription (mehr Traffic als der Mirror-Port tragen kann), unvollständige VLAN-Sicht, Paket-Bursting und – je nach Plattform – subtile Filtereffekte.

• TAP: besser für verlässliche Forensik, höhere Materialkosten, aber reproduzierbarer Betrieb.
• SPAN: schnell, günstig, aber Sie müssen Drop-Risiko und Vollständigkeit aktiv überprüfen.

Wo platzieren?

Für den Einstieg sind drei Plätze praxisnah:

• Internet Edge / Perimeter: ein guter Überblick über Ein- und Ausgänge (Egress ist für Hunting oft wichtiger als Ingress).
• Rechenzentrums-Aggregation: East-West-Traffic zwischen Servernetzen – relevant für Lateralmovement.
• Segment mit „Kronjuwelen“: Datenbanken, ERP-/CRM-Backends, zentrale Fileservices – ideal für Fokus-Hunting.

Typischer Kompromiss: Starten Sie mit einem Perimeter-Sensor (maximale Abdeckung) und ergänzen Sie später gezielt Segment-Sensoren, wenn Sie wissen, wo die wichtigsten Hypothesen liegen.

Rückfallstrategie (Rollback) schon im Design

Auch bei passiven Sensoren können Sie Produktion stören: Mirror-Konfigurationen können falsch gesetzt werden, Sensor-NICs können Switch-Ports fluten (z. B. bei Loops), Storage kann volllaufen und Monitoring-Systeme können durch Log-Stürme kippen. Planen Sie daher:

• Mirror/TAP schnell abschaltbar (Change-Plan, eindeutig beschriftete Ports).
• Sensoren als „Fail-open“ (passiv) betreiben; IPS nur mit gesonderter Freigabe.
• Rate-Limits und Backpressure in der Log-Pipeline (Queue, Batch, Drop-Policy).
• Kapazitätsgrenzen: PCAP-Ringbuffer, Log-Rotation, Storage-Warnschwellen.

Hardware- und Performance-Basis: Drops vermeiden, bevor Sie Regeln tunen

Rule-Tuning ist wertlos, wenn Ihre Sensoren Pakete verlieren. Paketverlust erzeugt Artefakte: zerhackte TLS-Handshakes, fehlende HTTP-Transaktionen, falsche Stream-Reassembly – daraus folgen Ghost-Alerts und blinde Flecken.

Minimal-Checkliste für Sensor-Hosts

• NIC: Server-NIC mit stabilem Treiber; RSS (Receive Side Scaling) aktiv, passende Ringbuffer-Größe.
• CPU: ausreichend Kerne, Pinning/Worker-Modell passend; Avoid „alles auf Core 0“.
• Storage: getrennte Volumes für Logs/PCAP; IOPS-Reserve für Peaks; Logrotate getestet.
• Zeit: NTP/Chrony stabil; Zeitdrift zerstört Korrelation und Case-Timeline.

Prüfschritte: Dropped Packets, Queue-Überlauf, Capture-Health

Prüfen Sie nicht nur „läuft der Dienst“, sondern „verarbeiten wir Traffic vollständig“. Je nach Capture-Backend unterscheiden sich die Kennzahlen. Zwei praktische Basistests sind: Interface-Statistiken (Kernel) und Sensor-Statistiken (Anwendung).

# Interface-Statistiken (Drops, Errors) – Ausgangspunkt
ip -s link show dev eth1

# Kernel- und Treiberzähler (je nach Treiber aussagekräftig)
ethtool -S eth1 | egrep -i 'drop|dropped|miss|error|fifo'

# Ringbuffer/RX-Tuning prüfen
ethtool -g eth1

# CPU/Softirq-Last im Blick: wenn ksoftirqd hoch geht, drohen Drops
top -H

Wenn Sie hier bereits Drops sehen, sind typische Gegenmaßnahmen: Mirror-Last reduzieren (selektiver SPAN), Capture-Backend wechseln (AF_PACKET vs. DPDK), RX-Ring anheben, IRQ-Balancing sauber einstellen oder dedizierte Sensor-Hardware nutzen.

Suricata Deployment: EVE JSON, Rule-Sets und sichere Update-Disziplin

Suricata liefert seine Ergebnisse typischerweise als EVE JSON (strukturierte Ereignisse im JSON-Format). Für Betrieb und Integrationen ist das ideal: SIEM, Log-Management, Message-Bus oder Case-Systeme können Events robust parsen.

Konfigurationsprinzipien, die im Alltag helfen

• Trennen Sie Betriebs- und Analysepfad: Suricata schreibt lokal, ein Forwarder (z. B. Filebeat/Fluent Bit/Vector) liefert weiter.
• Rules versionieren: Git-Repo oder Artefakt-Registry; Updates nicht „auf dem Sensor“ zusammenklicken.
• Update-Fenster: Rule-Updates sind faktisch Code-Änderungen – mit Change-Record und Rollback.

Rule-Update kontrolliert durchführen (Beispielablauf)

# Beispiel: Regeln aktualisieren (Distribution/Tooling variiert je nach Setup)
# 1) Vorher: aktuelle Regeln sichern
sudo tar -C /etc/suricata -czf /var/backups/suricata-rules_$(date +%F).tar.gz rules

# 2) Update aus kontrollierter Quelle (z. B. internes Repo / signiertes Paket)
# (Hier als Platzhalter – in der Praxis per Paketmanager oder suricata-update)
# sudo suricata-update --no-test --reload-command 'systemctl reload suricata'

# 3) Syntax-/Ladeprüfung und anschließend Reload
sudo suricata -T -c /etc/suricata/suricata.yaml
sudo systemctl reload suricata

# 4) Rückfall: falls Alarmflut oder Fehler
# sudo tar -C /etc/suricata -xzf /var/backups/suricata-rules_YYYY-MM-DD.tar.gz
# sudo systemctl reload suricata

Warum dieser Ablauf funktioniert: Sie trennen Test (Konfig-/Rule-Check) von Aktivierung. Und Sie haben eine schnelle Rückfalloption, bevor die Pipeline mit falschen Signaturen überläuft.

Zeek Deployment: Metadaten als Hunting-Basis und sinnvoller Log-Zuschnitt

Zeek erzeugt viele Log-Typen (z. B. conn, dns, http, ssl/tls). Für den Betrieb ist weniger oft mehr: Wenn Sie „alles“ aktivieren, steigt Storage- und Parsinglast, und die Teams verlieren den Überblick. Starten Sie mit einem Kernset, das typische Hypothesen abdeckt:

• conn: Basisverbindungen (wer spricht mit wem, wann, wie viel).
• dns: Namensauflösung (C2-Domains, DGA-Verdacht, exfil via DNS).
• tls/ssl: Handshake-Metadaten (SNI, Zertifikat, Versionen, ALPN).
• files (optional): Dateimetadaten (Hashes) – nur wenn Sie die I/O-Last tragen.

Ein häufiger Stolperstein ist die Korrelation über Sensoren hinweg: Wenn Sie mehrere Sensoren betreiben, brauchen Sie eindeutige Sensor-IDs und konsistente Zeitquellen. Sonst werden aus zwei Ereignissen „zwei Wahrheiten“.

Prüfschritte: Zeek-Health und Log-Rotation

# Läuft Zeek und schreibt Logs?
sudo systemctl status zeek
ls -lh /opt/zeek/logs/current/

# Rotation/Archive prüfen (Pfad je nach Installation)
find /opt/zeek/logs -maxdepth 2 -type d -name "20*" | tail

# Grober Plausibilitätscheck: wächst conn.log, dns.log, tls/ssl.log?
for f in conn.log dns.log ssl.log tls.log; do
  test -f "/opt/zeek/logs/current/$f" && echo "OK: $f" || echo "MISS: $f";
done

Wenn Logs nicht rotieren oder Archive nicht weggeräumt werden, ist das kein Schönheitsfehler: Volllaufende Filesystems führen zu Datenverlust und im schlimmsten Fall zu instabilen Sensoren.

Rule-Tuning in Suricata: Von Alarmflut zu belastbaren Signalen

Rule-Tuning heißt nicht „alles deaktivieren, bis Ruhe ist“, sondern: Erwartungen definieren, Baselines bilden, Kontext hinzufügen und dann iterativ schärfen. Ziel ist ein Signal-Rausch-Verhältnis, das ein Team tatsächlich bearbeiten kann.

Typische Ursachen für False Positives

• Inkompatible Netze: Regeln feuern auf internes Monitoring, Backups, Vulnerability-Scanner oder Proxy-Traffic.
• TLS überall: Viele Signaturen auf Klartext-Protokolle werden durch TLS „halb“ getroffen (SNI/Handshake), ohne echte Evidenz.
• Protokoll-Normalisierung: Reverse-Proxies, NAT, Load-Balancer verändern Sicht und führen zu „komischen“ Flows.
• Unvollständige Reassembly: Paketverlust oder asymmetrisches Routing erzeugen irreführende Decoder-Events.

Praktischer Tuning-Workflow (3 Stufen)

1. Stufe 1: Noise abklemmen – klare Ausnahmen für bekannte Scanner, interne Update-Server, Management-Netze. Das ist kein „Wegfiltern von Angriffen“, sondern Entfernen von Dauerfeuer, das niemand bearbeitet.
2. Stufe 2: Kontext erzwingen – nur alerten, wenn mehrere Bedingungen stimmen (z. B. Zielzone + Protokoll + seltenes Ziel + ungewöhnlicher Port).
3. Stufe 3: Prozess anbinden – jede verbleibende Regel bekommt Ownership (wer pflegt?) und einen Review-Rhythmus.

Wichtig: Tuning sollte immer datenbasiert sein. Wenn Sie Regeln deaktivieren, dokumentieren Sie den Grund und setzen Sie ein Wiedervorlage-Datum. Sonst sammeln sich „Altlasten“ an, die später blinde Flecken erzeugen.

TLS-Parsing: Was Sie ohne Entschlüsselung zuverlässig nutzen können

TLS-Parsing bedeutet, den unverschlüsselten Teil des TLS-Handshakes auszuwerten. Dazu gehören unter anderem SNI (Server Name Indication – der angefragte Hostname), Zertifikatskette, Version/Cipher-Auswahl und Extensions. Zeek und Suricata können hier wertvolle Metadaten liefern, auch wenn Payload verschlüsselt ist.

Welche TLS-Signale sind in der Praxis nützlich?

• SNI: Häufig der stärkste Indikator für Zielbeziehungen. Scheitert bei IP-only, ESNI/ECH (verschleierte SNI) oder TLS-Tunneln.
• Zertifikat: Aussteller, Subject, Gültigkeit, Self-signed, ungewöhnliche SAN-Muster. Vorsicht: Let’s-Encrypt ist nicht „böse“, aber eine gute Baseline ist nötig.
• JA3/JA3S: Fingerprints aus Client-/Server-Handshake-Parametern. Nützlich für Clusterbildung, aber nicht als alleiniger „Malware-Beweis“, weil Fingerprints kollidieren und sich verändern können.
• ALPN: Aushandlung von HTTP/2, HTTP/1.1 etc. Hilft bei Protokollprofilen.

Wann TLS-Parsing scheitert: Bei ECH (Encrypted ClientHello) wird der klassische SNI-Mehrwert reduziert. Außerdem können Middleboxes (Proxies) das sichtbare TLS-Verhalten „vereinheitlichen“, wodurch Sie eher den Proxy als den Client fingerprinten.

Stolperfallen: Proxy-Welten und Zertifikats-Interception

In vielen Unternehmen terminiert ein Proxy TLS und baut zum Ziel neu auf. Dann sehen Sie am Perimeter nicht den echten Client-Fingerprint, sondern den Proxy. Das ist nicht „schlecht“, aber Sie müssen Ihre Hypothesen anpassen: Hunting auf „Endgerät spricht direkt mit X“ funktioniert dann nicht; Hunting auf „Proxy baut ungewöhnliche Verbindungen“ kann dagegen sehr gut funktionieren.

Alert-to-Case: Von Events zu bearbeitbaren Vorgängen

Ein Alert ist ein technisches Ereignis. Ein Case ist ein Vorgang mit Kontext, Zuständigkeit, Zeitleiste und Entscheidung. Ohne diesen Übergang endet Network-Hunting oft als Alarm-Müllhalde oder als Einmal-Projekt.

Minimaler Case-Datensatz, der sich bewährt

• Identität: Case-ID, Sensor, Zeitfenster, betroffene Assets (IP, Hostname, Benutzer falls vorhanden).
• Begründung: Welche Regel/Heuristik hat ausgelöst, welche Evidenz ist angehängt (Zeek-Logzeilen, Suricata-Alert, PCAP-Referenz).
• Kontext: Asset-Kritikalität, bekannte Change-Tickets, Wartungsfenster, Scanner-IP-Liste.
• Entscheidung: True/False Positive, Schweregrad, nächste Aktion (contain, observe, close).
• Nacharbeit: Tuning-Task ja/nein, Regel-Owner, Wiedervorlage.

Pragmatisches Correlation-Design

In der Praxis korrelieren Sie nicht „alles mit allem“, sondern bauen wenige robuste Brücken:

• Suricata Alert → Zeek Kontext: gleicher 5-Tuple (Quelle/Ziel/Ports/Proto) + Zeitfenster.
• Zeek TLS/DNS → Asset-DB: IP/Hostname zu CMDB/Inventar (welcher Server ist das?).
• PCAP on demand: nur für eskalierte Cases; ansonsten Metadaten reichen.

Das reduziert Kosten: Dauer-PCAP ist teuer (Storage, Datenschutz, Betrieb). Ein „PCAP-Ringbuffer für 2–6 Stunden“ ist häufig ein guter Kompromiss, um im Incident-Fall noch rückwärts schauen zu können, ohne ständig alles aufzubewahren.

Log-Pipeline und Datenhaltung: Robustheit vor „schönem Dashboard“

Die meisten Ausfälle passieren zwischen Sensor und Auswertung: Log-Forwarder blockiert, Queue läuft voll, Indexer ist überlastet, Zeitstempel sind falsch, Felder ändern sich nach Updates. Behandeln Sie die Pipeline wie ein produktives System.

Best Practices für Forwarding und Backpressure

• Lokales Spooling: Forwarder muss puffern können (Disk-Queue), sonst verlieren Sie bei kurzen Störungen Events.
• Schema-Kontrolle: EVE JSON/Zeek-Logs versionieren; Parser-Änderungen testen, bevor sie in Produktion gehen.
• Trennung von „hot“ und „cold“: Aktive Suche im schnellen Index, Langzeit-Aufbewahrung als komprimierte Archive.

Prüfschritte: Zeitkorrelation und Feldstabilität

Wenn Sie Hunting betreiben, ist „Zeit“ eine Kernfunktion. Prüfen Sie regelmäßig:

• Drift zwischen Sensor, Log-Collector, SIEM-Indexer (NTP-Status).
• Zeitzonen (UTC vs. Lokalzeit) in allen Stufen.
• Feldnamen/Typen nach Updates (z. B. Suricata EVE-Felder, Zeek-Log-Formate).

Troubleshooting: Wenn Ergebnisse nicht zu Ihrer Realität passen

Es ist normal, dass die ersten Wochen „komisch“ aussehen. Entscheidend ist, systematisch zu prüfen, ob das Problem im Netz, im Capture, im Parsing oder im Prozess liegt.

Symptom: Viele TLS-Alerts, aber keine passenden DNS-Spuren

• Ursache: DNS wird intern gecacht/aufgelöst (Resolver), Clients nutzen DoH/DoT (DNS over HTTPS/TLS) oder Proxy übernimmt Auflösung.
• Prüfung: Sehen Sie Port 53/853? Gibt es DoH-Verbindungen zu bekannten Resolvern? Läuft alles über einen Proxy?
• Gegenmaßnahme: Sensor näher an Clients/Resolver platzieren oder Hypothesen auf Proxy-Ebene formulieren.

Symptom: Regeln feuern auf „alles“, besonders bei Backups/Scans

• Ursache: Scanner und Backup-Tools erzeugen Muster wie Exploit-Scans (viele Ziele/Ports/Requests).
• Prüfung: Quell-IP identifizieren, Wartungsfenster und Tool-Liste abgleichen.
• Gegenmaßnahme: Ausnahmen mit klarer Dokumentation; separate „Noise“-Policy für Management-Netze.

Symptom: Fehlende oder instabile Protokoll-Logs

• Ursache: Paketdrops, asymmetrisches Routing, VLAN-Fehlspiegelung, MTU/Fragmentierung.
• Prüfung: Drops/Errors wie oben, SPAN-Config, Vergleich mit NetFlow/Firewall-Logs.
• Gegenmaßnahme: TAP nutzen, SPAN selektieren, Sensor-NIC/CPU/Backend anpassen.

Umsetzungsvorschlag: In 14 Tagen zu einem brauchbaren Hunting-Betrieb

Ein praktikabler Plan ist besser als „wir installieren mal und schauen“. Folgender Ablauf hat sich als realistisch erwiesen, ohne Teams zu überfahren:

Phase 1 (Tag 1–3): Sichtbarkeit und Stabilität

• Sensor am Perimeter oder Aggregation aufsetzen (passiv).
• NTP/Chrony sauber, Storage- und Rotation-Policies festlegen.
• Drop-freie Verarbeitung verifizieren (Peak-Zeiten testen).

Phase 2 (Tag 4–7): Daten nutzbar machen

• Suricata EVE JSON und Zeek-Kernlogs ins zentrale Logging.
• Erste Dashboards/Queries: Top-Destinations, neue Domains, seltene SNI, ungewöhnliche Ports.
• Alert-Flut messen: Top-10 Rules, Top-10 Quellen, Top-10 Ziele.

Phase 3 (Tag 8–14): Tuning und Case-Prozess

• Noise-Reduktion mit dokumentierten Ausnahmen.
• Case-Template definieren (Felder, Zuständigkeit, SLAs im Kleinen).
• Wöchentlicher Review: welche Rules liefern Wert, welche nicht, welche Hypothesen fehlen.

Fazit: Hunting ist Betrieb – und Zeek/Suricata sind Ihre Sensorik

Zeek und Suricata liefern zusammen eine sehr belastbare Basis für Network-Hunting, wenn Sie zuerst die Capture-Qualität absichern, dann Regeln iterativ tunen und TLS-Metadaten korrekt einordnen. Der größte Hebel liegt am Ende nicht in „mehr Regeln“, sondern im Alert-to-Case-Prozess: klare Zuständigkeiten, reproduzierbare Evidenz, und ein Feedback-Loop, der Tuning und Datenqualität kontinuierlich verbessert.

Wenn Sie das Thema im Umfeld von API-Sicherheit, zentraler Secrets-Verwaltung oder Remote-Access-Logging weiter vertiefen wollen, sollte der nächste Schritt immer derselbe sein: Sichtbarkeit gezielt erhöhen, aber nur dort, wo Sie die Findings auch operationalisieren können.

Für dieses Thema sind auch Ids/Nsm Architektur und Rule-Tuning Suricata wichtig. Der Beitrag ordnet diese Aspekte verständlich ein und zeigt, worauf es im Alltag ankommt.