Zeek Network Security Monitoring: Logs That Tell the Story

What Zeek does differently

Most network security tools are built to shout when something matches a known-bad pattern. Zeek (originally called Bro) takes a different approach: it watches traffic passively and writes down what happened, in detail, for every connection. Who talked to whom, for how long, over which protocol, which domain was looked up, which certificate was presented, which file was transferred.

That record is what makes zeek network security monitoring so useful. When an alert fires somewhere else, or you simply want to know what a device on your network has been doing, the answer is already in the logs.

Zeek vs Suricata

If you’ve read our guide to Suricata IDS at home, the natural question is whether you need both. They complement each other:

• Suricata is signature-driven. It compares traffic against rules and raises alerts. Great for “tell me when something bad happens”.
• Zeek is description-driven. It produces protocol-aware logs of everything, and its scripting language lets you build your own detections on top. Great for “tell me what happened”.

Many security teams run both on the same traffic: Suricata for the alert, Zeek for the context needed to investigate it.

Where to put the sensor

Zeek needs to see the traffic, so placement matters more than hardware:

• A mirror (SPAN) port on a managed switch, copying traffic from your router’s uplink, is the easiest option at home.
• A network TAP is more reliable under load but costs more.
• Running Zeek on the router or firewall itself works for small networks if it has spare CPU.
• Use a dedicated interface for monitoring with no IP address, separate from the management interface.

For a typical home or small-office network, a modest mini PC is plenty. Busy networks need more cores, because Zeek scales by running multiple worker processes.

Installing and running it

The Zeek project publishes binary packages for the major Linux distributions, which is the simplest route. Once installed, zeekctl manages the processes. Set the monitoring interface in node.cfg, then:

sudo zeekctl install
sudo zeekctl deploy
sudo zeekctl status

Logs appear under the Zeek log directory, rotated hourly by default. For shipping into a SIEM, switch to JSON output by loading the JSON logging policy in local.zeek:

@load policy/tuning/json-logs

The logs worth knowing

• conn.log – every connection: endpoints, ports, protocol, duration, bytes in each direction.
• dns.log – every DNS query and answer. Often the fastest way to spot a compromised or chatty device.
• http.log – methods, hosts, URIs and user agents for unencrypted HTTP.
• ssl.log and x509.log – TLS versions, server names and certificate details, even though the payload is encrypted.
• files.log – files seen on the wire, with hashes you can check against threat intelligence.
• notice.log and weird.log – Zeek’s own observations of unusual or suspicious behaviour.

The bundled zeek-cut tool pulls out just the columns you want from the tab-separated logs:

cat conn.log | zeek-cut id.orig_h id.resp_h id.resp_p proto service duration

Putting it to work

On its own, Zeek gives you an investigation tool. Fed into a SIEM such as Wazuh or an Elastic stack, it becomes a searchable history of your network that detection rules can run against. Good first exercises:

• List every domain your smart-home devices look up in a day, and question the ones you don’t recognise.
• Find devices still negotiating old TLS versions.
• Look for long-lived connections with small, regular data transfers – a classic sign of beaconing.

Zeek has a learning curve, mostly because it shows you so much. But once you’ve used zeek network security monitoring to answer “what was that device doing at 3am?” in thirty seconds, it’s hard to go back to a network you can’t see into.