Zeek: a network monitor that keeps application-layer state rather than a rule set

The state model is the difference from a typical IDS

The repository description makes the claim directly: Zeek is a network analysis framework much different from the typical IDS you may know. Four key features explain what that means.

In-depth analysis comes from analyzers shipped for many protocols, which enable high-level semantic analysis at the application layer rather than matching bytes against signatures. Adaptability comes from a domain-specific scripting language that enables site-specific monitoring policies, and the README notes this means Zeek is not restricted to any particular detection approach. Efficiency is a claim about targeting high-performance networks and being used operationally at a variety of large sites. The fourth is the one that separates it: Zeek keeps extensive application-layer state about the network it monitors and provides a high-level archive of that network's activity.

So an event from Zeek arrives with the surrounding conversation attached rather than as an isolated match.

The consequence runs both ways. You get something queryable after the fact, which is what incident work needs, and you pay for it in memory and in log volume, because state retained across connections is state retained per connection.

The top-level Makefile describes itself as a subset

The build instructions in the README are short: clone, then `./configure && make && sudo make install`. The first line of the Makefile qualifies that considerably.

#
# A simple static wrapper for a number of standard Makefile targets,
# mostly just forwarding to build/Makefile. This is provided only for
# convenience and supports only a subset of what CMake's Makefile
# offers. For more, execute that one directly.
#

BUILD=build
REPO=$$(cd $(CURDIR) && basename $$(git config --get remote.origin.url | sed 's/^[^:]*://g'))
VERSION_FULL=$(REPO)-$$(cd $(CURDIR) && cat VERSION)
GITDIR=$$(test -f .git && echo $$(cut -d" " -f2 .git) || echo .git)
REALPATH=$$($$(realpath --relative-to=$(shell pwd) . >/dev/null 2>&1) && echo 'realpath' || echo 'grealpath')

Real work happens in a CMake-generated makefile under a `build/` directory, and the wrapper explicitly does not expose everything it can do. If you need a target beyond the forwarded set, the file tells you to run the generated one directly.

Three of those variable definitions are worth noticing because they are about the checkout rather than the build. `REPO` comes from the basename of `git config --get remote.origin.url`. `GITDIR` handles `.git` being a file rather than a directory, which is what a worktree or a submodule checkout produces. `REALPATH` probes for a flag and picks a different tool.

The consequence is that the three commands in the README are the supported path, and the wrapper's own comment tells you where to go when they are not enough.

Two macOS accommodations appear in the same file

The `REALPATH` definition is a portability switch.

REALPATH=$$($$(realpath --relative-to=$(shell pwd) . >/dev/null 2>&1) && echo 'realpath' || echo 'grealpath')

The `--relative-to` option is probed by running it and discarding the output. If it works, the variable names `realpath`; if it does not, it names `grealpath`, the GNU variant that does support relative output. The two tools differ across the macOS and Linux userlands, and the Makefile picks automatically rather than asking you to.

The second accommodation is a comment further down, attached to the `dist` target.

# The COPYFILE_DISABLE flag used in the tar commands below is an undocumented feature
# of the tar binary on macOS. It causes tar to avoid including any of the special files
# that macOS litters around the repository directory, such as ._ resource files, none
# of which should be included in the distribution packages.

That flag suppresses the `._` resource-fork files macOS scatters through a directory tree, which would otherwise end up inside a release tarball.

The consequence is a good signal about the project's user base. Two separate notes about macOS specifics in one convenience wrapper, one of them documenting behaviour the tool itself calls undocumented, is what a build that is actually used on developer laptops looks like.

The tarball drops four vendored copies of one test framework

The same file explains what gets cut from a release tarball, and the reason is given as three categories: test frameworks, standalone-only dependencies, and duplicate vendored copies.

DIST_EXCLUDE = \
	auxil/broker/auxil/prometheus-cpp/3rdparty/googletest \
	auxil/prometheus-cpp/3rdparty/googletest \
	auxil/rapidjson/thirdparty/gtest \
	auxil/spicy/3rdparty/benchmark \
	auxil/spicy/3rdparty/justrx/3rdparty/benchmark \
	auxil/spicy/3rdparty/libunistd \
	auxil/spicy/3rdparty/vcpkg

Read down the list and the duplication is the point. Google Test appears three times, under broker's nested prometheus copy, under prometheus itself, and under rapidjson's `thirdparty/gtest`. The benchmark framework appears twice under spicy, once directly and once nested inside another vendored project. libunistd and vcpkg are dropped as standalone-only dependencies of spicy.

The consequence is that a git checkout and a distribution tarball are not the same tree. Anyone packaging Zeek from the tarball gets a leaner source tree than someone who cloned the repository, and anyone reproducing a build from source needs to know which of the two they have before comparing results.

The clone is not finished until submodules arrive

The README gives the clone as a single line, and the recursive flag on it is the whole instruction.

git clone --recursive https://github.com/zeek/zeek

The reason is visible two ways. There is a `.gitmodules` file at the repository root, which is what makes it a submodule checkout at all, and the exclusion list quoted above names vendored trees nested several directories deep under `auxil/`, which is what submodules produce.

With the dependencies in place, the build is the configure, make and root install sequence. The docs link in that sentence is a prerequisites page, so the compiler, the libraries and the generator tooling are enumerated there rather than here.

The consequence is that a plain `git clone` leaves you with an incomplete tree. If you are scripting a build, put the recursive flag in the clone rather than in a later repair step.

Eight quality configs sit at the root, and one of them is for Python

The tooling story is unusually visible for a C++ project of this size. The root carries `.clang-format`, `.clang-tidy`, `.cmake-format.json`, `.pre-commit-config.yaml`, `.typos.toml` and `ruff.toml`, alongside `.git-blame-ignore-revs` and `.update-changes.cfg`.

The first three are C++ and CMake. The typo checker is language-agnostic, the pre-commit config wires them into a commit hook, and `.git-blame-ignore-revs` exists so that a whole-tree reformat can be excluded from blame, which only makes sense if reformatting is automated and frequent.

`ruff.toml` is the outlier. Ruff is a Python linter and formatter, so a Python lint configuration in the root of a C++ repository means Python source lives in this tree and is held to the same gate as the C++. The `testing/` and `scripts/` directories are where you would expect to find it.

The README's own tooling section is separate from all of this and names three external analysers: Clang-Tidy, Coverity, and PVS-Studio, described as a static analyser for C, C++, C# and Java. It says these are used to help discover issues to fix, amongst a number of others.

The consequence for a contributor is that style is machine-enforced before review. Expect a commit hook to reformat your C++ and fail on style, and expect large reformat commits to be filtered out of blame rather than reviewed.

Two README files, a security model and an AI policy

The repository root holds both `README` and `README.md`, which is a duplication worth noting before you edit either.

Alongside them sit `SECURITY.md` and a separate `SECURITY_MODEL.md`, which is the more unusual of the pair.

There is also `AI_POLICY.md` alongside `AGENTS.md`. Their contents are not described in the README.

The remaining governance files are the conventional set: `CODE_OF_CONDUCT.md`, `CONTRIBUTING.md`, `COPYING` for the BSD licence and `COPYING-3rdparty` for the vendored code, which is the file that pairs with everything under `auxil/`.

The consequence is practical. Before you open a pull request against this project, `AI_POLICY.md` and `SECURITY_MODEL.md` are the two documents most likely to change what you are allowed to submit.

What Zeek cannot do for you, and where that work lands

Four limits, and each one moves work onto you rather than removing it.

It cannot give you a detection policy. The adaptability feature is framed as enabling site-specific monitoring policies and explicitly as not being restricted to any particular detection approach. Zeek includes scripts and a notice framework, but the meaning of notices and the desired response depend on the site. Review and configure the available policies, and add site-specific detections where needed.

It cannot tell you what it will cost you. Efficiency is stated as targeting high-performance networks and being used operationally at a variety of large sites, with no throughput figure, no hardware description and no memory model. The counterweight is the fourth feature, extensive application-layer state and a high-level archive of activity. Plan disk and memory from your own traffic, because the documentation will not do it for you.

The documented install needs root: the sequence ends in `sudo make install`, and the build needs the dependencies on the linked prerequisites page plus the recursive submodules. Prebuilt downloads for stable releases are on the project website.

And it does not wrap up the whole job. Documentation, the community and the mailing lists are pointed at as places to learn more, with an online playground for trying the scripting language before you install anything.

Editorial conclusion

Adopt Zeek when you need a network monitor that produces application-layer state you can query after the fact, rather than a signature matcher that emits alerts, and when you have a C++ toolchain, the submodules and a host you are willing to install to. Do not expect a detection policy on day one, because the framework is deliberately not restricted to any particular detection approach, which means the analyzers are what you get and the monitoring policy is yours to write. Clone with the recursive flag so the vendored trees under auxil/ are fetched, plan memory and log volume from your own traffic rather than from the efficiency claim, which arrives without a figure, and prefer a container or a dedicated account over a root install. If you plan to contribute, read AI_POLICY.md and SECURITY_MODEL.md before opening a pull request.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. zeek/zeek on GitHub