Aus Paketen werden strukturierte Netzwerkereignisse
In Modul 11 hast du Netzwerkverkehr mit Wireshark auf Paketebene untersucht. Jetzt wechselst du die Perspektive: Zeek verarbeitet denselben Netzwerkverkehr und erzeugt daraus strukturierte Verbindungs-, DNS-, HTTP-, TLS- und Datei-Ereignisse. Dadurch lassen sich auch große Datenmengen wesentlich zielgerichteter untersuchen.
Vom einzelnen Paket zum auswertbaren Ereignis
Eine PCAP kann Millionen einzelner Pakete enthalten. Zeek hilft dabei, diese Paketmenge in strukturierte Informationen zu übersetzen, die sich schneller lesen, filtern und miteinander verbinden lassen.
Der Perspektivwechsel
WIRESHARK
Paket → Paket → Paket → Paket
↓
Kommunikation
↓
ZEEK
Verbindung · DNS · HTTP · TLS · Datei · Ereignis
Wireshark bleibt sehr nah am einzelnen Paket. Zeek fasst beobachtete Kommunikation stärker zusammen und erzeugt strukturierte Datensätze. Beide Werkzeuge betrachten dieselbe technische Realität aus unterschiedlichen Perspektiven.
Wo Zeek in der Verarbeitungskette steht
NETZWERKVERKEHR
↓
TAP / SPAN / CAPTURE UNIT
↓
PCAP / LIVE-DATEN
↓
ZEEK
↓
STRUKTURIERTE LOGS
↓
OPENSEARCH / WEITERE AUSWERTUNG
Zeek steht zwischen der erfassten Netzwerkkommunikation und der späteren Suche in großen Datenbeständen. Es ist damit eine wichtige Brücke zwischen Paketebene und datengetriebener Analyse.
Was Zeek nicht ist
Zeek ist keine Wahrheitsmaschine und ersetzt keine analytische Bewertung. Es verarbeitet die Daten, die am Beobachtungspunkt tatsächlich vorliegen, und erzeugt daraus technische Beobachtungen.
Ein Ereignis landet dort, wo es fachlich hingehört
Zeek erzeugt abhängig vom beobachteten Netzwerkverkehr unterschiedliche Logdateien. Du musst nicht jedes Feld auswendig kennen. Entscheidend ist zunächst, welches Log welche Frage beantwortet.
Die wichtigsten Logs für den Einstieg
| Log | Kernfrage |
|---|---|
conn.log | Wer kommunizierte wann mit wem und in welchem Umfang? |
dns.log | Welche Namen wurden aufgelöst und welche Antworten wurden beobachtet? |
http.log | Welche HTTP-Aktivitäten wurden erkannt? |
ssl.log / TLS | Welche TLS-bezogenen Metadaten wurden erkannt? |
files.log | Welche Dateiaktivitäten wurden innerhalb unterstützter Protokolle erkannt? |
weird.log | Welche ungewöhnlichen Protokollereignisse wurden beobachtet? |
notice.log | Welche Ereignisse wurden durch Zeek oder Skripte besonders hervorgehoben? |
Eine PCAP mit Zeek verarbeiten
zeek -r capture.pcap Danach beispielsweise: conn.log dns.log http.log ssl.log files.log
Welche Logs tatsächlich entstehen, hängt vom Inhalt der Aufzeichnung ab. Enthält die PCAP beispielsweise keine erkannte HTTP-Kommunikation, muss auch kein http.log entstehen.
Wer kommunizierte mit wem?
conn.log ist häufig der erste sinnvolle Einstieg in eine Zeek-Auswertung. Es beschreibt beobachtete Kommunikationsbeziehungen in strukturierter Form.
Wichtige Felder
| Feld | Bedeutung |
|---|---|
ts | Zeitpunkt des Beginns |
uid | Eindeutige Kennung des Kommunikationszusammenhangs |
id.orig_h | IP-Adresse des Originators |
id.orig_p | Port des Originators |
id.resp_h | IP-Adresse des Responders |
id.resp_p | Port des Responders |
proto | Transportprotokoll |
service | Von Zeek erkannter Dienst |
duration | Beobachtete Dauer |
orig_bytes / resp_bytes | Datenmengen in beide Richtungen |
conn_state | Beobachteter Zustand der Kommunikation |
Originator und Responder
192.168.10.25:51842 → 203.0.113.20:443 id.orig_h = 192.168.10.25 id.orig_p = 51842 id.resp_h = 203.0.113.20 id.resp_p = 443
Der Originator ist die Seite, von der Zeek den Kommunikationsvorgang als initiiert betrachtet. Der Responder ist die entsprechende Gegenseite.
Technische Aussage statt Vermutung
id.orig_h = 10.10.5.21 id.resp_h = 198.51.100.44 id.resp_p = 443 duration = 317.2
Eine saubere Formulierung wäre: Das System 10.10.5.21 führte eine TCP-Kommunikation zu 198.51.100.44 unter Beteiligung des Zielports 443; der beobachtete Vorgang dauerte rund 317 Sekunden.
Nicht automatisch bewiesen sind Anwendung, Benutzer, Inhalt, Absicht oder Schädlichkeit.
Der Schlüssel zwischen verschiedenen Zeek-Logs
Die UID ist eines der wichtigsten Konzepte für eine strukturierte Zeek-Analyse. Sie erlaubt dir, Informationen desselben Kommunikationszusammenhangs über mehrere Logs hinweg miteinander zu verbinden.
Eine UID – mehrere Perspektiven
conn.log uid = Cx7Ab12Example http.log uid = Cx7Ab12Example files.log uid = Cx7Ab12Example
Die gleiche UID zeigt, dass die Informationen in einem gemeinsamen Kommunikationskontext stehen.
Pivotieren
INTERESSANTE VERBINDUNG IN conn.log
↓
UID MERKEN
↓
UID IN ANDEREN LOGS SUCHEN
↓
HTTP · TLS · FILES · WEITERE EREIGNISSE
↓
GESAMTBILD ERWEITERN
Dieses Wechseln von einem technischen Merkmal zu weiteren zusammengehörigen Informationen wird häufig als Pivotieren bezeichnet. Genau diese Arbeitsweise wird später auch in OpenSearch wichtig.
Von der Namensauflösung zur späteren Verbindung
DNS liefert häufig einen ersten Hinweis darauf, welchen Namen ein System auflösen wollte. Erst durch die Korrelation mit weiteren Ereignissen entsteht ein belastbarer technischer Zusammenhang.
Eine DNS-Beobachtung lesen
Client: 10.10.5.21 Query: update.example.net Answer: 198.51.100.17
Eine belastbare Aussage lautet zunächst: Das System 10.10.5.21 führte eine DNS-Anfrage nach update.example.net durch; als Antwort wurde 198.51.100.17 beobachtet.
DNS allein reicht nicht
dns.log
10.10.5.21 → update.example.net → 198.51.100.17
↓ prüfen
conn.log
10.10.5.21:51877 → 198.51.100.17:443
Die DNS-Anfrage zeigt Interesse an einem Namen. Erst die zusätzliche Verbindung zeigt, dass anschließend tatsächlich Kommunikation mit der aufgelösten IP-Adresse beobachtet wurde.
Inhaltliche Hinweise und Metadaten auseinanderhalten
Je nach Protokoll kann Zeek zusätzliche Informationen aus einer Kommunikation ableiten. Bei verschlüsselter Kommunikation bleiben insbesondere Metadaten wichtig.
http.log
method = GET host = example.org uri = /download/update.bin status = 200
Ein HTTP-Eintrag kann beispielsweise Methode, Host, URI, User-Agent, Statuscode sowie Quelle, Ziel und UID enthalten. Dadurch lässt sich eine Webaktivität direkt mit der zugrunde liegenden Verbindung verknüpfen.
TLS-bezogene Metadaten
| Beobachtbar | Nicht automatisch sichtbar |
|---|---|
| Quelle und Ziel | Vollständiger Anwendungsinhalt |
| Zeitpunkt und Dauer | Verschlüsselte Nutzdaten |
| Ports und Datenmengen | Alle übertragenen Inhalte im Klartext |
| Je nach Kommunikation TLS-Metadaten | Automatische fachliche Bewertung |
Weitere Ereignisse richtig einordnen
Neben Verbindungen, DNS und Webkommunikation können weitere Logs wertvolle Hinweise liefern. Sie müssen jedoch immer im Kontext interpretiert werden.
files.log
Wenn Zeek innerhalb unterstützter Protokolle eine Dateiaktivität erkennt, können dazu strukturierte Informationen entstehen. Interessant sind beispielsweise Zeit, Dateityp, Größe, Quelle und die Verknüpfung zur zugrunde liegenden Kommunikation.
HTTP-Ereignis
↓
Dateiaktivität erkannt
↓
files.log
↓
über UID / weitere Kennungen korrelierenweird.log
weird.log dokumentiert ungewöhnliche oder unerwartete Protokollereignisse. Ein solcher Eintrag ist zunächst ein technischer Hinweis.
notice.log
Ein Notice kann ein besonders hervorgehobenes Ereignis darstellen. Auch hier gilt: Ein Hinweis ist kein Beweis. Prüfe anschließend die zugrunde liegende Kommunikation und weitere Datenquellen.
NOTICE ↓ BETROFFENE KOMMUNIKATION BESTIMMEN ↓ UID · IP · ZEITSTEMPEL PRÜFEN ↓ WEITERE LOGS KORRELIEREN ↓ GESAMTBILD BEWERTEN
Bekannte Linux-Werkzeuge sinnvoll weiterverwenden
Zeek-Logs können schnell groß werden. Die Linux-Grundlagen aus den vorherigen Modulen helfen dir, auch ohne grafische Oberfläche erste gezielte Prüfungen durchzuführen.
Dateien und erste Zeilen ansehen
ls head conn.log less conn.log
Mit ls siehst du vorhandene Logs. head zeigt einen ersten Ausschnitt, less eignet sich zum kontrollierten Durchsehen größerer Dateien.
Nach einer IP-Adresse suchen
grep "10.10.5.21" conn.log
Mit grep kannst du einen bekannten Wert in einer Logdatei suchen. Für kleine Übungen reicht das oft aus, um einen relevanten Ausgangspunkt zu finden.
Felder mit zeek-cut reduzieren
cat conn.log | zeek-cut id.orig_h id.resp_h id.resp_p
zeek-cut kann ausgewählte Felder aus klassischen Zeek-TSV-Logs herauslösen. Dadurch wird aus einer breiten Logzeile eine übersichtliche Darstellung relevanter Werte.
Aus einzelnen Logs wird eine nachvollziehbare Timeline
Der eigentliche analytische Wert entsteht oft erst dann, wenn mehrere technische Ereignisse zeitlich und inhaltlich miteinander verbunden werden.
Eine einfache Ereigniskette
14:32:01 DNS
Client fragt update.example.net ab
14:32:01 DNS
Antwort: 198.51.100.44
14:32:03 CONN
Client → 198.51.100.44:443
14:32:03–14:37:20
Verbindung bleibt aktiv
später
weitere Verbindungen zum selben Ziel
Jede einzelne Zeile ist zunächst eine technische Beobachtung. Zusammen entsteht ein Kommunikationsmuster.
Beobachtung, Interpretation und Bewertung trennen
| Ebene | Beispiel |
|---|---|
| Beobachtung | Ein Client baute wiederholt TCP-Kommunikation zu derselben externen IP auf. |
| Interpretation | Die Regelmäßigkeit könnte auf automatisierte Kommunikation hindeuten. |
| Bewertung | Ob die Kommunikation legitim oder schädlich ist, benötigt zusätzlichen Kontext. |
Ein wiederholbarer Ablauf für Zeek-Daten
Auch bei Zeek gilt: Nicht wahllos Logs durchsuchen. Beginne mit einer klaren Fragestellung und arbeite dich kontrolliert von der Verbindung zum Kontext vor.
Schritt 1 – Ausgangssystem bestimmen
Beginne mit einer bekannten IP-Adresse, einem Zeitraum oder einem anderen belastbaren Merkmal aus der Aufgabenstellung.
Schritt 2 – conn.log prüfen
Bestimme Kommunikationspartner, Ports, Protokolle, Dauer und Datenmengen. Markiere interessante Verbindungen.
Schritt 3 – DNS und Dienste ergänzen
Prüfe, ob Namen aufgelöst wurden und welche Dienste Zeek für die relevanten Verbindungen erkannt hat.
Schritt 4 – UID verwenden
Nutze die UID, um zugehörige HTTP-, TLS-, Datei- oder weitere Ereignisse zu finden.
Schritt 5 – Timeline bilden
Ordne relevante Ereignisse chronologisch und prüfe, welche technischen Zusammenhänge tatsächlich durch die Daten getragen werden.
Schritt 6 – Feststellung formulieren
Dokumentiere beobachtbare Fakten. Trenne klar zwischen sicherer Beobachtung, möglicher Interpretation und abschließender Bewertung.
Vier Aussagen, die bei Zeek schnell zu falschen Schlüssen führen
Öffne alle vier Karten. Der Modulabschluss setzt voraus, dass du jede Aussage geprüft hast.
Von der Verbindung zum korrelierten Ereignisbild
Klicke dich durch den Ablauf. Diese Reihenfolge bildet gleichzeitig die Grundlogik für die spätere Zeek-Herausforderung.
Eine wiederkehrende Verbindung mit Zeek einordnen
Das interne System 10.20.30.45 soll untersucht werden. Du findest folgende vereinfachte Informationen:
dns.log
16:42:11 10.20.30.45
update.example.net
→ 203.0.113.80
conn.log
16:42:12 10.20.30.45:51844
→ 203.0.113.80:443
uid: C8Example01
duration: 4.8 s
16:47:12 10.20.30.45:51902
→ 203.0.113.80:443
uid: C8Example02
duration: 5.1 s
16:52:13 10.20.30.45:51961
→ 203.0.113.80:443
uid: C8Example03
duration: 4.9 s
update.example.net zu 203.0.113.80 auf.Als nächstes würdest du insbesondere die zugehörigen UIDs, weitere Zeek-Logs, Datenmengen und gegebenenfalls die zugrunde liegenden Pakete prüfen.
Logs, Felder und Analyseentscheidungen sicher zuordnen
Ordne alle zehn Situationen korrekt zu. Alle Zuordnungen müssen richtig sein, bevor der Modulabschluss möglich ist.
Das richtige Log wählen
Felder verstehen
Korrelation
Hinweise richtig bewerten
Werkzeuge und Arbeitsweise
Prüfe dein Verständnis von Zeek und Korrelation
Beantworte alle zwölf Fragen. Für den Modulabschluss müssen alle Antworten korrekt sein.
Du kannst Netzwerkverkehr jetzt als Ereignisbild untersuchen
Nach Modul 12 kannst du erklären, wie Zeek aus Netzwerkverkehr strukturierte Logs erzeugt. Du kennst die Rolle von conn.log, dns.log, http.log, TLS-bezogenen Informationen, files.log, weird.log und notice.log. Vor allem kannst du mit der UID zwischen zusammengehörigen Ereignissen pivotieren und aus Einzelbeobachtungen eine nachvollziehbare Timeline bilden.
Im nächsten Modul skalierst du diese Arbeitsweise weiter: Mit OpenSearch lernst du, große Mengen strukturierter Ereignisdaten gezielt zu durchsuchen, zu filtern und miteinander zu korrelieren.