Zeek ist das Werkzeug, mit dem ein Blue Team sieht, was im Netz wirklich passiert: nicht als Alarm einer Signatur, sondern als vollständiges, strukturiertes Protokoll jeder Verbindung, jeder DNS-Anfrage, jedes Zertifikats und jeder übertragenen Datei. Seit fast drei Jahrzehnten quelloffen, läuft es heute im Kern vieler kommerzieller NDR-Produkte und in jedem ernstzunehmenden Sensor-Setup. In diesem Beitrag erfährst du, wie Zeek arbeitet, welche Logs den Unterschied machen, welche Angriffe sich damit erkennen lassen, was beim Betrieb zu beachten ist und wo die Grenzen liegen.
Was Zeek ist und was nicht
Zeek ist ein Network Security Monitor. Vern Paxson begann 1995 am Lawrence Berkeley National Laboratory mit der Entwicklung, bis 2018 hieß das Projekt Bro. Es steht unter BSD-Lizenz, wird von einem Kernteam mit großer Community gepflegt und erscheint in einem festen Takt: Bei Erscheinen dieses Beitrags ist 8.2 die aktuelle Feature-Version, 8.0 die Version mit Langzeitpflege, Zeek 9 steht kurz bevor.
Der Unterschied zu einem klassischen Intrusion Detection System wie Suricata liegt im Ansatz. Ein signaturbasiertes IDS prüft Pakete gegen bekannte Muster und meldet Treffer. Zeek versteht Protokolle, verfolgt Verbindungen über ihre gesamte Dauer und schreibt auf, was passiert ist, unabhängig davon, ob jemand vorher eine Signatur dafür geschrieben hat. Das Ergebnis sind Logs, keine Alarme. Alarme entstehen erst, wenn Regeln im SIEM oder Zeek-Skripte auf diese Logs angesetzt werden. Beide Werkzeuge ergänzen sich, und in Plattformen wie Security Onion laufen sie nebeneinander am selben Sensor.
Wie Zeek arbeitet
Zeek ist passiv. Ein Sensor hängt an einem Mirror-Port des Switches oder an einem TAP und liest den Verkehr mit, ohne ihn zu beeinflussen. Im Inneren zerlegen Protokollanalysatoren die Pakete, eine Ereignismaschine erzeugt daraus Ereignisse wie „neue Verbindung“, „DNS-Antwort“ oder „Datei übertragen“, und Skripte in Zeeks eigener Sprache entscheiden, was damit geschieht. Die mitgelieferten Skripte schreiben die Standard-Logs; eigene Skripte können Erkennungslogik direkt im Sensor abbilden. Für neue Protokolle gibt es mit Spicy einen Parser-Generator, mit dem sich Analysatoren ohne C++ schreiben lassen.
Auf größeren Strecken läuft Zeek als Cluster: Ein Manager koordiniert, mehrere Worker verteilen die Last über die CPU-Kerne, ein Logger schreibt die Ausgabe. Mit Version 8.1 hat das Projekt die Cluster-Kommunikation auf ZeroMQ umgestellt, mit spürbar geringerer CPU-Last bei gleichem Verkehr. Bei verschlüsseltem Verkehr sieht Zeek den Inhalt nicht, aber alles darum herum: Ziel, Zeitpunkt, Dauer, Datenmenge, Server Name Indication, Zertifikat, Fingerabdruck des TLS-Clients. Für die meisten Erkennungen reicht das.
Die Logs, die den Unterschied machen
Jedes Log ist eine Tabelle mit festen Feldern, und alle Einträge zu einer Verbindung teilen sich eine eindeutige ID, die uid. Damit lässt sich von der DNS-Anfrage über die Verbindung bis zur übertragenen Datei alles zusammenführen. Die wichtigsten Logs:
| Log | Inhalt | Wofür ein Blue Team es braucht |
|---|---|---|
| conn.log | Jede Verbindung: Quelle, Ziel, Protokoll, Dauer, Bytes in beide Richtungen, Verbindungszustand, Verlauf | Die Basis für alles: Beaconing, Datenabfluss, Scans, Bewegungen im Netz |
| dns.log | Anfragen und Antworten mit Typ, Antwortcode und aufgelösten Adressen | Command-and-Control über DNS, Tunneling, neu registrierte Domains, fehlgeschlagene Auflösungen in Serie |
| http.log | Methode, Host, URI, User-Agent, Statuscode, übertragene Dateien | Downloads von Werkzeugen, seltsame User-Agents, Web-Shells |
| ssl.log und x509.log | TLS-Handshake: SNI, Version, Cipher, Zertifikatskette, Aussteller, Gültigkeit | Selbstsignierte Zertifikate, TLS zu nackten IP-Adressen, verdächtige Client-Fingerabdrücke (JA3, JA4 als Paket) |
| files.log | Jede übertragene Datei mit MIME-Typ, Größe und Hash, unabhängig vom Protokoll | Abgleich mit Threat Intelligence, ausführbare Dateien aus dem Netz, Extraktion für die Analyse |
| smb_files.log, smb_mapping.log | Zugriffe auf Freigaben, kopierte Dateien, verbundene Laufwerke | Zugriff auf ADMIN$ und C$ von Arbeitsplatzrechnern, Vorbereitung einer Verschlüsselung |
| dce_rpc.log | RPC-Aufrufe mit Endpunkt und Operation | PsExec, WMI-Ausführung auf entfernten Systemen, Dienstinstallation aus der Ferne |
| kerberos.log, ntlm.log | Ticketanforderungen mit Client, Dienst, Cipher und Fehlern; NTLM-Anmeldungen | Kerberoasting (RC4 für Dienstkonten), Fehlschläge in Serie, NTLM dort, wo es nichts zu suchen hat |
| rdp.log, ssh.log | Sitzungen mit Client-Informationen und Ergebnis | RDP-Ketten zwischen Clients, SSH von Systemen, die sonst nie SSH sprechen |
| software.log, known_services.log | Erkannte Software-Versionen und neu gesehene Dienste pro Host | Inventar aus dem Verkehr heraus, neue Dienste als Persistenz-Hinweis |
| notice.log, weird.log | Von Skripten erzeugte Hinweise; Protokollverletzungen und Unerwartetes | Die Stelle, an der Zeek selbst auf etwas zeigt |
Die vollständige Referenz aller Logs und Felder steht in der Zeek-Dokumentation. Wer die Logs im JSON-Format ausgibt, kann sie ohne Parser in jedes SIEM oder in Elastic laden.
Was du mit Zeek erkennst
- Beaconing. Schadsoftware meldet sich in festen Abständen bei ihrem Server. Im conn.log erscheint das als Serie kurzer Verbindungen zur selben Adresse mit fast identischem Intervall und fast identischer Größe. Werkzeuge wie RITA werten conn.log genau darauf aus.
- DNS-Tunneling. Tausende Anfragen an eine Domain, jede mit einer langen, zufällig wirkenden Subdomain. Im dns.log an Anfragenlänge, Volumen pro Domain und Antworttyp erkennbar.
- Seitliche Bewegung. smb_mapping, dce_rpc und rdp zeigen, welcher Client mit welchem anderen Client spricht. Arbeitsplatzrechner haben untereinander normalerweise nichts zu besprechen.
- Command-and-Control über TLS. Verbindungen zu IP-Adressen ohne SNI, selbstsignierte oder frisch ausgestellte Zertifikate, ungewöhnliche Client-Fingerabdrücke. Der Inhalt bleibt verschlüsselt, das Muster nicht.
- Datenabfluss. Ein Client, der nachts mehrere Gigabyte an einen Cloud-Speicher oder eine unbekannte Adresse schickt, steht im conn.log mit orig_bytes, die zu keinem Arbeitsplatz passen.
- Kerberoasting. Im kerberos.log viele Diensticket-Anforderungen mit RC4 von einem Client in Sekunden, das Netzwerk-Gegenstück zu Event 4769 auf dem Domain Controller. Wer beides hat, erkennt es doppelt.
Der gemeinsame Nenner: Zeek erkennt Verhalten, nicht Signaturen. Ein Angreifer, der sein Werkzeug umbenennt oder neu kompiliert, ändert damit nichts an seinem Beaconing-Intervall. In der Cyber Kill Chain sitzt Zeek genau dort, wo Angreifer am schwersten leise sein können: bei Command and Control, seitlicher Bewegung und Exfiltration.
Zeek betreiben: Homelab bis Produktion
Für den Einstieg reicht eine Linux-VM mit zwei Netzwerkkarten, eine für die Verwaltung, eine für den Mirror-Port, und die Binary-Pakete des Projekts für die gängigen Distributionen; wie der Sensor in ein komplettes Blue-Team-Homelab passt, steht dort Schritt für Schritt. Alternativ analysiert Zeek auch aufgezeichnete PCAP-Dateien offline, was für das Lernen und für die Forensik nach einem Vorfall der schnellste Weg ist: Mitschnitt hinein, zwanzig Logs heraus.
In der Produktion entscheidet die Platzierung. Ein Sensor am Internet-übergang sieht alles, was hinaus- und hereinläuft, aber nichts zwischen den Clients. Für seitliche Bewegungen braucht es Sicht auf den Verkehr zwischen Segmenten, also am Core-Switch oder zwischen Client- und Servernetz. Ein TAP ist einem Mirror-Port vorzuziehen, weil er unter Last keine Pakete verwirft. Für die Dimensionierung gilt als grobe Orientierung ein Worker-Prozess pro CPU-Kern und pro paar hundert Megabit anhaltenden Verkehrs; die genaue Zahl hängt von der Protokollmischung ab und wird am besten am eigenen Verkehr gemessen. Logs im JSON-Format, per Filebeat oder vergleichbarem Agenten ins SIEM, mit einer Aufbewahrung von mindestens 90 Tagen, damit ein spät entdeckter Vorfall noch rekonstruierbar ist.
Grenzen
- Verschlüsselte Inhalte. Was in einer TLS-Verbindung übertragen wird, bleibt unsichtbar. Metadaten reichen für Muster, nicht für den Nachweis, welche Datei abgeflossen ist.
- Keine Reaktion. Zeek isoliert nichts. Die Reaktion läuft über Firewall, Switch oder EDR.
- Nur, was am Sensor vorbeikommt. Verkehr in der Cloud, im Homeoffice oder in Segmenten ohne Sensor existiert für Zeek nicht.
- Datenmengen. Ein Sensor an einer 10-Gigabit-Strecke erzeugt Logs im dreistelligen Gigabyte-Bereich pro Tag. Ohne Filterung und ein SIEM, das das trägt, wird aus Sichtbarkeit Speicherkosten.
- Analystenzeit. Logs beantworten Fragen, sie stellen keine. Ohne jemanden, der conn.log und dns.log regelmäßig mit Hypothesen durchgeht, bleibt der Sensor ein Archiv. Das ist der Punkt, an dem Threat Hunting beginnt.
Zeek und der Rest der Werkzeugkiste
Zeek ersetzt keinen EDR und wird von keinem ersetzt; der Agent sieht den Prozess, der Sensor sieht die Verbindung, und erst zusammen ergibt sich, welches Programm mit welchem Ziel gesprochen hat. Neben Suricata für Signaturen und Zeek für Kontext gehören zur Netzwerkseite ein Werkzeug für die PCAP-Analyse, etwa Wireshark für das Detail und Zui für das Durchsuchen großer Mitschnitte, und für wachsende Umgebungen eine Plattform, die Sensoren verwaltet. Security Onion bündelt das quelloffen, Corelight liefert Zeek als kommerzielles Produkt mit Support und veranstaltet regelmäßig Capture-the-Flag-Übungen auf Zeek-Basis, die für das Erlernen der Logs kaum zu schlagen sind.
Fazit
Zeek gibt dem Blue Team eine Perspektive, die kein Angreifer mit Kontrolle über einen Endpunkt manipulieren kann, und die alles erfasst, was keinen Agenten trägt. Es liefert keine Alarme, sondern die Daten, aus denen gute Alarme gebaut werden, und es kostet nichts außer einem Sensor, Speicherplatz und der Bereitschaft, sich in seine Logs einzuarbeiten. Wer das tut, sieht Beaconing, Bewegungen im Netz und Datenabfluss dort, wo andere nur eine Firewall haben, die „erlaubt“ protokolliert.