Zeek for Network Traffic Analysis

Zeek (originally called Bro) is a passive, open-source network security monitoring (NSM) framework. Unlike signature-based intrusion detection systems (IDS) like Snort or Suricata, Zeek does not primarily inspect packet payloads for known attack patterns. Instead, it focuses on creating high-fidelity, structured logs of network activity. These logs capture metadata about connections, DNS queries, HTTP requests, SSL/TLS certificates, file transfers, and more. The core philosophy is that by faithfully recording what happened on the network, security analysts can later query, correlate, and analyze the data to detect both known and unknown threats.

Zeek was developed at Lawrence Berkeley National Laboratory and is now maintained by the Zeek community. It is widely used in enterprise security operations centers (SOCs), research institutions, and incident response teams. On the CS0-003 exam, you need to understand Zeek's role in the security monitoring ecosystem, its log types, and how it complements other tools like firewalls, IDS/IPS, and SIEMs.

Zeek operates in two primary layers: the event engine and the policy script interpreter.

To start Zeek on an interface:

zeek -i eth0

To run Zeek with a specific script:

zeek -i eth0 /path/to/script.zeek

To list available scripts:

zeek --print-scripts

To check Zeek status using zeekctl:

zeekctl status

Example output:

Name       Type       Host          Status    Pid    Started
zeek       standalone localhost     running   12345  01 Jan 00:00:00

To view live logs:

tail -f /var/log/zeek/current/conn.log

To check for errors:

grep -i error /var/log/zeek/current/notice.log

- conn.log: Connection records. Key fields: ts, uid, id.orig_h, id.orig_p, id.resp_h, id.resp_p, proto, service, duration, orig_bytes, resp_bytes, conn_state. - conn_state values: S0 (connection attempt seen, no reply), S1 (connection established, not closed), S2 (connection established and close attempt by originator), S3 (connection established and close attempt by responder), SF (normal establishment and termination), REJ (connection rejected), etc. - http.log: HTTP requests. Fields: ts, uid, id.orig_h, id.orig_p, id.resp_h, id.resp_p, method, host, uri, referrer, user_agent, status_code, etc. - dns.log: DNS queries. Fields: ts, uid, id.orig_h, id.orig_p, id.resp_h, id.resp_p, proto, query, qtype, qclass, rcode, answers, TTLs. - ssl.log: SSL/TLS handshakes. Fields: ts, uid, id.orig_h, id.orig_p, id.resp_h, id.resp_p, version, cipher, server_name, certificate_chain, subject, issuer. - notice.log: Alerts generated by Zeek scripts. Fields: ts, uid, id.orig_h, id.orig_p, id.resp_h, id.resp_p, note, msg, sub, src, dst, p, n. - files.log: Files extracted from the network. Fields: ts, uid, id.orig_h, id.orig_p, id.resp_h, id.resp_p, fuid, tx_hosts, rx_hosts, conn_uids, mime_type, filename, duration, local_orig, is_orig.

Zeek's scripting language is event-driven. A simple script to log all HTTP requests with a specific user-agent:

event http_request(c: connection, method: string, original_URI: string, unescaped_URI: string, version: string) {
    if (c$http?$user_agent && c$http$user_agent == "BadAgent") {
        print fmt("Suspicious user-agent from %s", c$id$orig_h);
    }
}

To load custom scripts, place them in $PREFIX/share/zeek/site/ and add @load directives in local.zeek.

Zeek is CPU and memory intensive. For high-speed networks (10 Gbps+), use cluster mode where multiple Zeek workers process traffic in parallel. Use zeekctl to manage clusters. Key tuning parameters: redef for buffer sizes and timeouts. Avoid loading unnecessary scripts to reduce overhead.

On the CS0-003 exam, you may be asked to:

Zeek is a cornerstone of network security monitoring, providing rich metadata for threat detection and investigation. Its log-based approach allows for flexible analysis and integration. For the CS0-003 exam, focus on its architecture, log types, and how it fits into the security operations workflow.

Scenario 1: Monitoring a Corporate Network for Malware C2 Communications

A large enterprise deploys Zeek on a span port at the internet gateway to monitor all inbound and outbound traffic. The security team uses Zeek's conn.log and dns.log to detect beaconing behavior. They write custom scripts that flag connections to IP addresses with low TTL values or domains that are algorithmically generated (DGA). For example, a script checks dns.log for queries to domains with high entropy names. When a match is found, Zeek generates a notice in notice.log. The team then correlates that notice with ssl.log to see if the connection used TLS and what certificate was presented. This helps identify malware that uses HTTPS for C2. In production, Zeek handles 2 Gbps of traffic using a cluster of four workers. The team tunes tcp_inactivity_timeout to 10 minutes to avoid missing long-lived C2 sessions.

Scenario 2: Incident Response after a Phishing Attack

After a user clicks a malicious link in a phishing email, the incident response team uses Zeek logs to determine the extent of the compromise. They query http.log for the user's IP address around the time of the click to see what URLs were accessed. They find a request to a malicious domain and a subsequent download of a .exe file. Zeek's files.log shows the extracted file with a MIME type of application/x-dosexec. The team retrieves the file hash from files.log and scans it against a sandbox. They also check conn.log for any outbound connections from the infected host to external IPs, finding a long-lived connection to a C2 server. Zeek's ssl.log reveals the TLS certificate used, which was self-signed. The team uses this information to block the IP and certificate on the firewall.

Scenario 3: Compliance Monitoring for Data Exfiltration

A financial institution uses Zeek to monitor for potential data exfiltration. They focus on conn.log for large data transfers (e.g., orig_bytes or resp_bytes exceeding 100 MB). They also monitor ftp.log and http.log for uploads to external sites. Custom scripts tag connections to cloud storage providers and generate alerts if the amount of data sent exceeds a threshold. In production, Zeek is deployed in a cluster with load balancing across multiple interfaces. The team uses zeekctl to manage the cluster and regularly reviews notice.log for policy violations. They also integrate Zeek logs with their SIEM to automate alerting and reporting for compliance audits.

Common Misconfigurations and Pitfalls