Netzwerkmonitoring mit Zeek: Installation, Logs und Wazuh-Integration

Netzwerkmonitoring mit Zeek: Installation, Logs und Wazuh-Integration

Dieser Artikel beschreibt die Installation von Zeek als verhaltensbasierte Ergänzung zur signaturbasierten Suricata-Erkennung, die Struktur der wichtigsten Log-Dateien und die Einbindung in Wazuh als SIEM.

Einordnung

Zeek erzeugt aus mitgelesenem Netzwerkverkehr strukturierte, protokollspezifische Log-Dateien, unabhängig davon, ob eine Signatur anschlägt. Während Suricata die Frage "ist das bösartig?" beantwortet, beantwortet Zeek die Frage "was ist im Netz passiert?". Beide Sichten ergänzen sich und lassen sich am selben Mirror-Port parallel betreiben.

Voraussetzungen

Benötigte Komponenten

• Eigene VM oder gemeinsamer Host mit der bestehenden Suricata-IDS-VM am OVS-Mirror-Port
• Rocky Linux oder Debian als Basis
• Netzwerkinterface im Promiscuous-/Mirror-Modus
• Wazuh-Agent auf demselben Host für die spätere Log-Weiterleitung

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

Schritt 1: Zeek installieren

Repository einbinden (Rocky Linux 9)

dnf install -y epel-release
rpm --import https://download.opensuse.org/repositories/security:zeek/CentOS_9/repodata/repomd.xml.key
curl -o /etc/yum.repos.d/security:zeek.repo https://download.opensuse.org/repositories/security:zeek/CentOS_9/security:zeek.repo
dnf install -y zeek

PATH ergänzen

• echo 'export PATH=/opt/zeek/bin:$PATH' >> /etc/profile.d/zeek.sh
• source /etc/profile.d/zeek.sh

Schritt 2: Monitoring-Interface konfigurieren

Node-Konfiguration anpassen

• vim /opt/zeek/etc/node.cfg

[zeek]
type=standalone
host=localhost
interface=eth1

eth1 ist hier das Interface, das am OVS-Mirror-Port hängt (dasselbe Segment, das auch die separate Suricata-IDS-VM bedient).

Netzwerke definieren

• vim /opt/zeek/etc/networks.cfg

172.26.52.0/24    Kurs-DMZ

Konfiguration deployen

zeekctl deploy
zeekctl status

Schritt 3: Log-Struktur

Zeek schreibt standardmäßig nach /opt/zeek/logs/current/, mit täglicher Rotation nach /opt/zeek/logs/<datum>/. Die wichtigsten Logs:

conn.log

• Jede Verbindung mit Dauer, übertragenen Bytes, Ports, Protokoll, TCP-Flags (`conn_state`)
• Basis für Baseline-Analysen und Anomalieerkennung, unabhängig von Alerts

http.log

• Jede HTTP-Anfrage mit Host, URI, User-Agent, Statuscode, übertragener Dateityp

dns.log

• Alle DNS-Anfragen inkl. aufgelöster IPs – zentral für die Erkennung von C2-Domains oder DNS-Tunneling

ssl.log

• TLS-Handshakes mit Zertifikatsdetails, SNI, JA3-Fingerprint

files.log

• Metadaten zu allen erkannten Dateiübertragungen (MIME-Type, Hash, Größe) über alle Protokolle hinweg

Beispiel

conn.log lesen

cat /opt/zeek/logs/current/conn.log | zeek-cut id.orig_h id.resp_h id.resp_p proto service duration orig_bytes resp_bytes

Schritt 4: Beispiel – Zeek-Sicht auf den EICAR-Vorfall

Am selben Beispielangriff wie im NetworkMiner-Artikel (EICAR-Download per HTTP) lässt sich der Unterschied in der Sichtbarkeit gut zeigen: Suricata meldet einen konkreten Alert, Zeek liefert unabhängig davon den vollständigen Kontext der Verbindung.

http.log nach der betroffenen IP filtern

cat /opt/zeek/logs/current/http.log | zeek-cut id.orig_h id.resp_h method host uri resp_mime_types | grep 172.26.52.50

files.log auf den übertragenen Dateihash prüfen

cat /opt/zeek/logs/current/files.log | zeek-cut fuid tx_hosts rx_hosts source mime_type total_bytes md5

Der resultierende MD5-Hash der Datei lässt sich direkt gegen Threat-Intel-Feeds abgleichen – auch für Dateien, für die (noch) keine Suricata-Signatur existiert. Das ist der zentrale Mehrwert gegenüber der rein signaturbasierten Sicht: Zeek protokolliert jede Übertragung, unabhängig davon, ob sie zum Zeitpunkt der Erfassung als bösartig bekannt war.

Schritt 5: Integration in Wazuh

Zeek-Logs per Filebeat/Wazuh-Agent einlesen

In der ossec.conf des Wazuh-Agents auf dem Zeek-Sensor:

<localfile>
  <log_format>json</log_format>
  <location>/opt/zeek/logs/current/conn.log</location>
</localfile>
<localfile>
  <log_format>json</log_format>
  <location>/opt/zeek/logs/current/dns.log</location>
</localfile>
<localfile>
  <log_format>json</log_format>
  <location>/opt/zeek/logs/current/http.log</location>
</localfile>

Hinweis: Zeek muss dafür im JSON-Log-Format ausgeben statt im klassischen TSV-Format. Dazu in /opt/zeek/share/zeek/site/local.zeek ergänzen:

@load policy/tuning/json-logs.zeek

Anschließend zeekctl deploy erneut ausführen.

Custom-Decoder/Regeln in Wazuh

Analog zur bestehenden Coraza-WAF- und OPNsense-Integration lassen sich eigene Decoder für die Zeek-JSON-Felder (`id.orig_h`, `id.resp_h`, `proto`, `service` etc.) anlegen, um in Wazuh gezielt nach Auffälligkeiten zu suchen, z. B.:

• Verbindungen mit ungewöhnlich langer Dauer oder Datenvolumen (`conn.log`)
• DNS-Anfragen an bekannte C2-Domains oder mit auffälliger Entropie im Query-Namen (`dns.log`)
• Selbstsignierte oder abgelaufene Zertifikate (`ssl.log`)

Zusammenfassung des Workflows

1. Zeek auf einer eigenen VM oder parallel zur Suricata-IDS-VM am OVS-Mirror-Port installieren
2. Monitoring-Interface und überwachte Netze in `node.cfg`/`networks.cfg` festlegen
3. JSON-Logging aktivieren, `zeekctl deploy`
4. Wichtige Logs kennen: `conn.log`, `http.log`, `dns.log`, `ssl.log`, `files.log`
5. Logs über den Wazuh-Agent einlesen und mit eigenen Decodern/Regeln auswerten
6. Als Ergänzung zu Suricata nutzen: Zeek liefert den Kontext, auch wenn keine Signatur greift