We are very happy to make a release candidate of Zeek 3.1 available today. After last year’s 3.0, this is the first feature release following our new release schedule, bringing new functionality & improvements to users interested in upgrading more frequently than our traditional annual cycle allowed for.
Some highlights in Zeek 3.1 include:
- We are introducing the first, experimental version of a new supervisor framework, which provides an entirely new deployment mode for Zeek. Currently, ZeekControl is the primary tool to operate clusters of Zeek processes. The supervisor framework shifts that functionality into Zeek itself, enabling Zeek to spawn & monitor cluster nodes as child processes—workers, loggers, and managers. We plan to further evolve this new model over time, with the goal to eventually come to a more standard Unix-style service model that can fully replace ZeekControl. We encourage you to give the supervisor framework a try. You will need to write a bit of custom script code to configure your cluster, but we have documentation to get you started.
- We have replaced Zeek’s old select-based I/O loop with a new architecture that does no longer spin waiting for active I/O sources. The new architecture now waits for sources to actively notify it when activity occurs. If you’re running Zeek on a low-volume traffic stream, you should see a substantially reduced CPU load. These changes do come with a couple of breaking changes, though: Zeek now supports only a single packet source at a time (i.e., no more multiple -r or -i flags); and for C++ plugins, the IOSource API has changed fairly substantially—except for existing packet sources, which should remain functional with little to no changes. Let us know if you encounter any problems with your plugin, and we’ll be happy to help. We also have more documentation on the new architecture upcoming.
- There is now a new &on_change table/set attribute that allows script writers to specify a callback function to execute when container elements are inserted/updated/deleted. This functionality prepares for some upcoming updates to Zeek’s cluster state synchronization, but it can already be very useful on it own as well. See the on_change documentation for information.
- A new optional script policy/protocols/conn/speculative-service.zeek adds a speculative_service field to conn.log that reports educated guesses on a connection’s protocol/service in cases where Zeek’s normal protocol detection has exhausted the buffers required for a more reliable decision.
Starting with Zeek 3.1, compiling Zeek from source now requires a C++17 compiler, as well as CMake >= 3.0. The installation section of the manual includes updated instructions for several platforms.
Please note that in Zeek 3.1, the backwards-compatibility wrappers & work-arounds that we had introduced with 3.0 to ease the Bro-to-Zeek renaming pain, have either changed their operation or in some cases been removed. Generally, anything that was reporting a naming-related warning in 3.0 now aborts with a corresponding error message. In cases where 3.0 silently continued to accept old names, 3.1 now reports warnings. Most importantly, the latter includes loading of scripts with .bro endings, which are now flagged and should be renamed to .zeek.
As usual, see NEWS for full 3.1 release notes, and CHANGES for the exhaustive list of changes. We don’t recommend release candidates for production usage, but we encourage you to give them a try and let us know if you spot any rough edges. We’ll do our best to address any issues for the final release, which we expect to come out in about two weeks.
The best place to get started and to get feedback is the Zeek mailing list. The mailing list should be your first stop for just about anything. If you are interested in what is going on in the community, it is going to be posted on the mailing list. Have questions about the usage of Zeek, or how other people are using it, then the mailing list is the right place for that. Want to announce a Zeek related project of yours, post it to the mailing list.
To join the mailing list just follow this link. The archives of the mailing list also are open to the public. The archives do not offer a search interface, but you can search them with google by appending “site:mailman.icsi.berkeley.edu inurl:pipermai/zeek” to your query, as in this example.