Zeek Network Security Monitoring: Setup and Logs

Zeek is the network monitor that describes what happened rather than shouting an alarm: it produces protocol transaction logs, extracted file metadata and behavioural notices, which makes it the natural evidence layer under an alerting tool. This guide covers sensor placement and tap-versus-SPAN choices, running Zeek against a pcap and then live traffic, reading the log set and pivoting between logs with the connection UID, and moving from a standalone instance to a managed cluster with zeekctl. It also notes where Zeek deliberately stops - it is not a full-content capture tool and only partly an alerting engine.

Where to put the sensor

Visibility determines value. The most useful single tap point in most networks is the uplink between an access layer and the rest of the infrastructure, because it sees every flow that crosses between segments without requiring NGFW or endpoint cooperation. A dedicated span port on a managed switch is the minimum acceptable option; a powered network tap is preferred because it never drops frames under load and cannot be reconfigured away by accident. Note that if the device at that point performs NAT, every client will appear with the same source address in the logs.

First run against a pcap

zeek -r quickstart.pcap LogAscii::use_json=T
ls
# conn.log  http.log  weird.log

Zeek writes one log per protocol or observation type. conn.log records every connection with a unique identifier (uid); protocol logs such as http.log, dns.log and ssl.log reuse that same uid, which is what makes pivoting trivial: find the connection, then grep the same UID across every other log. weird.log holds protocol anomalies - an invalid HTTP method, a malformed header - which is often the most interesting file on a compromised segment.

Live capture

zeek -i en0 -C

The -C flag ignores checksum errors. This is not a hack: modern NICs and hypervisors use checksum offload, so packets captured locally legitimately have uninitialised checksums, and Zeek discards bad-checksum packets by default. On a properly tapped production segment you generally leave checksums enabled.

Custom scripts

# example.zeek
event http_request(c: connection, method: string, original_URI: string, unescaped_URI: string, version: string)
{
    print fmt("HTTP request: %s %s (%s->%s)", method, original_URI, c$id$orig_h, c$id$resp_h);
}

zeek example.zeek -r quickstart.pcap

Zeek's scripting language is event-based, so extending it means writing handlers rather than parsing text output. Start by loading policies from $PREFIX/share/zeek/policy rather than writing detection logic from scratch.

Clusters with zeekctl

# $PREFIX/etc/node.cfg
[logger-1]
type=logger
host=localhost

[manager]
type=manager
host=localhost

[proxy-1]
type=proxy
host=localhost

[worker-1]
type=worker
host=localhost
interface=eth1
lb_method=custom
lb_procs=4

zeekctl deploy
zeekctl status
zeekctl top
zeekctl diag proxy-1
zeekctl cron

deploy validates policy syntax, distributes configuration and restarts the cluster - use it for every change rather than restarting nodes by hand. Workers analyse packets, the manager aggregates state, the logger writes files, and the proxy handles internal communication. ZeekControl has no process watchdog of its own, so putting zeekctl cron in a crontab entry is what gives you automatic restarts of crashed nodes.

Shipping logs onward

Production deployments forward the log directory to a SIEM or object store. JSON output plus a shipper keeps the parsing cost low - see Fluent Bit to Elasticsearch pipelines and Grafana Loki with Promtail for the two most common patterns. For signature-based detection alongside Zeek's transaction view, see Suricata IDS/IPS configuration.

原文链接：https://docs.zeek.org/en/lts/quickstart.html