The Zeek team is proud to announce Zeek 7.2! Work on this release began in December 2024 and includes some 1,200 commits, 330 merged pull requests, and 130 closed issues. The 7.2 release brings important new features, matures Zeek’s ability to run on alternative cluster backends, and includes several bugfixes.
As the final feature release in the 7.x cycle, 7.2 continues the architectural work established in 7.1 that we’ll build on for the foreseeable future. Most importantly, 7.2 introduces the Storage Framework, a new way of allowing script developers to store and retrieve key/value pairs in external datastores. The release ships with support for SQLite and Redis, and defaults to Zeek’s standard JSON serialization to represent the data. As usual in Zeek, the backend implementations are pluggable, and users are free to add additional storage solutions and provide alternative serialization formats. New script-layer APIs provide synchronous and asynchronous ways of managing these stores, addressing a wide range of use-cases such startup initialization, persistence to disk, or distribution of state across the cluster at runtime.
The Storage Framework aims to replace Broker’s hardwired datastores, continuing our effort to focus Broker on a topic-based pub/sub layer. Broker’s own datastores provide many things: a low-level key/val API, a high-level cluster-wide propagation mechanism, and syntactical convenience for Zeek scripts via Broker-backed tables. All of this functionality remains available. We have also not yet switched over Zeek’s own uses of data stores to the new framework, but aim to do so in the lead-up to Zeek 8. We encourage users to explore the new framework, as it’ll be the recommended way of addressing storage needs going forward.
We’ve continued 7.1’s work on pluggable cluster backends. The ZeroMQ backend has matured considerably and now looks highly promising in our testing. Like Broker, ZeroMQ works out-of-the-box: you do not need to run a standalone message broker to use it — but you can, if you’d prefer to do so. We’re planning to switch to ZeroMQ as Zeek’s default cluster backend by 8.1, and encourage early adopters to explore it. We’re also providing an experimental NATS.io backend for interested users, via a standalone Zeek package.
Continuing the messaging theme, Zeek now features its own experimental WebSocket implementation. Since WebSockets have become a primary way for users to integrate third-party applications into Zeek, reducing dependence on Broker for this important functionality makes intuitive sense. To use the new implementation, users only need to switch existing Broker::listen_websocket() calls to Cluster::listen_websocket(). Importantly, the new sockets do not use TLS by default, simplifying troubleshooting and use of external WebSocket clients. Here too, Broker’s functionality has remained unchanged, but we aim for Zeek’s implementation to become the de-facto choice going forward.
We’ve also made important changes to Zeek’s use of Broker. The backpressure concept for each peering, introduced in 7.1, now defaults to a drop-oldest-queued-message policy in overflow situations, rather than simply (and invasively) disconnecting the peer. We’ve also established new metrics to enable detailed tracking of buffer dynamics, bumped the buffer size limits to 8192 messages for both Broker peerings and Broker’s WebSocket connections, and reduced retry intervals across the board. In our test sites, these changes allow clusters to operate more smoothly and snappily, with less message loss in case of load bursts, and with better telemetry.
The protocol analysis subsystem has also undergone changes. Protocols listed in conn.log’s services field are now sorted deterministically in protocol-confirmation order, which will often reflect the layering of protocols on the wire. We’ve also updated Zeek’s handling of analyzers’ protocol violations: where Zeek previously tolerated a fixed number of protocol violations before giving up on a protocol, a single violation prior to confirmation will now immediately lead Zeek to disable the analyzer. This behavior reduces noise in analyzer.log, and provides symmetry with protocol confirmations. We’ve added additional tuning knobs for this behavior, too.
This release ships with Spicy 1.13, which in addition to bug fixes also adds new features, notably native support for parsing UTF-16, productivity improvements for working bytes and string values, as well as built out support for parsing blocks introduced in 1.12.
Zeek 7.2 contains many additional changes and improvements, so please take a moment to read Zeek’s and Spicy’s release notes for the full list of changes.
As laid out by our release cadence, the arrival of 7.2 means we no longer support the 7.1 series, which concluded with 7.1.1. Support for the 7.0.x LTS line continues, and we just released 7.0.7 with a set of bug fixes, including updates to our QUIC and LDAP parsers, as well as a bump to Spicy 1.11.4. Our next long-term-support (LTS) release, 8.0, is slated to arrive in the summer, and you’re welcome to explore our planned work on its project board.
We would like to thank our community members for their contributions to Zeek: Aashish Sharma, Anthony Verez, Anthony Kasza, @biswajitutil, Brendan Kapp, Carlos Lopez, Chris Hinshaw, Faan Rossouw, @FishyFluffer, Fupeng Zhao, @Herbert-Karl, @jbaggs, Jan Grashöfer, Julian Krieger, Justin Azoff, Kshitiz Bartariya, @Laotree, Mark Overholser, Mike Dopheide, @mnhsrj, Mohan Dhawan, @philipp-tg, Seth Hall, and @timo-mue — thank you!
Feedback and questions are always welcome, so please feel free to get in touch via our community channels.
We’d also like to thank Corelight for its continued support of the Zeek project.