For more information, see the About Zeek page in our documentation.

Spicy is a parser generator that makes it easy to create robust C++ parsers for network protocols, file formats, and more. Spicy is a bit like a “yacc for protocols”, but it’s much more than that: It’s an all-in-one system enabling developers to write attributed grammars that describe both syntax and semantics of an input format using a single, unified language.

Zeek supports network operations at a broad variety of sites, including major corporations, universities, research labs, and supercomputing centers. It’s also used widely by researchers to prototype novel network analyses and, more generally, for measuring network properties.

Zeek is developed and maintained by a group of researchers and engineers sharing a joint interest in advancing today’s network monitoring capabilities to keep pace with the rapid development of the online world.

Historically, the Zeek Project relied heavily on research and development grants from external organizations such as the National Science Foundation and the Department of Energy. Since 2017, Corelight has served as the custodian of the Zeek project. While not the owner, Corelight actively supports Zeek by providing financial backing, contributing code, and advocating for the project within the cybersecurity community, ensuring its continued evolution and impact.

In 2018, the long-established “Bro” system was renamed “Zeek”. For the rationale behind changing the name and the selection of Zeek as the new name, see the associated blog posting or the unveiling video.

Absolutely. Like any open-source project, Zeek critically depends on its community to move forward. We gladly accept patches, small and large, from individuals and organizations. We consider any contributions we receive for inclusion into the mainline distribution. Note that Zeek’s architecture is highly modular and a wide range of extensions is feasible without needing to modify Zeek itself. Zeek features its own package manager to administer such extensions.

If you have specific project ideas we encourage you to get in touch with us first to discuss it; we’ll aim to help and smooth the path for later inclusion into Zeek. That way we can also tell you early on if we believe an extension wouldn’t be a good fit for the main Zeek distribution.

Please keep in mind that all code contributed to Zeek must be subject to the same BSD license as the system itself; we will implicitly assume so if not stated otherwise. Please note that Zeek cannot even link to libraries with incompatible licenses (such as GPL).

Please refer to our Contribution Guide for more details.

We aim to provide three feature releases per year, each receiving bugfix releases as needed. We also offer long-term support releases, each valid for approximately one year. Please refer to our release cadence documentation for details.

We are eager to work with the community to resolve security vulnerabilities in Zeek in a timely and responsible manner, and to properly acknowledge the contributor(s). Please review our Security Reporting guidelines for details.

We do not, and we have no plans for one.

Yes, please refer to our Security Release Process, and particularly the Private Distributors Group.

Yes, please take a look at our roadmap documentation. Our roadmap depends to a large degree on the interests of the people working on the code base, including members of the core project as well as external contributors.

The Zeek Project does not offer individual assistance.

We do not perform contract work but we’re happy to provide pointers to commercial options where we are aware of them. If you are offering commercial Zeek work, let us know and we’ll keep you in mind when somebody asks.

Feel free to use our contact form, email us, or contact us on our community channels.

Zeek is open-source software. The system, including all its subcomponents, comes with the very permissive BSD license, which allows for pretty much unrestricted use as long as you leave the attributions in the source code in place. Read the license for the details.

All the documentation, and all our content on www.zeek.org that’s not otherwise marked, is licensed under the Creative Commons Attribution 4.0 International License. Occasionally we reuse content from external sources (e.g., trace files) that may be subject to different licenses even if not explicitly pointed out.

Yes, we encourage you to do so. Zeek’s BSD license imposes no restriction on integrating or bundling Zeek with your product; in particular you do not need to publish your modifications if you’d rather not do so. That said, we would certainly appreciate it if you credited the Zeek Project, or could at least tell us where it’s being used. If you develop custom functionality that might be useful to others, please consider contributing it back to the Zeek Project.

Please note that there are restrictions on how you may refer to your modified Zeek version; see next question.

In order to protect users’ trust in the system, the Zeek Project reserves the rights to the Zeek name and logo, and similarly for the older Bro name and logo. While we are generally happy to give people permission to use these under many circumstances, we maintain the right to decide on a case-by-case basis. For more information, please see the guidelines for using our marks and logos.

We provide Docker images and binary packages, and provide documentation for building from source. Some platforms ship with native support for Zeek thanks to community contributions. Please see our documentation for details.

For most people we recommend running our current Long-Term Support (LTS) release train. We provide two additional release trains every year, which are more short-lived but provide more immediate access to new features. All of our release trains receive bugfix releases, and we generally encourage you to upgrade as soon as possible. For details, including our support policy, take a look at our release cadence.

This is a vast topic and there are many good guides out there. Consider:

• The SEPTun II and III guides, written for Suricata but mostly equally applicable to Zeek
• Berkeley Lab’s documentation of 100GB+ monitoring
• An IMC 2010 paper by Lothar Braun et al., evaluating packet capture performance on commodity hardware
• Fabian Schneider’s research on Packet Capture in 10-Gigabit Ethernet Environments Using Contemporary Commodity Hardware

See the documentation of the Notice Framework for details, and consult Zeek’s list of notice types to get a sense of their utility.

We curate a set of publicly available packet traces on our Traces page. Zeek also ships with its own set of small captures for testing purposes; you can find these in the source repository.

Take a look at our troubleshooting documentation.

By default Zeek’s deep packet inspection engine discards packets with invalid checksums. This can be a problem if one wants to analyze locally generated/captured traffic on a system that offloads checksumming to the network adapter. In this setting all packets transmitted by the machine will have bad checksums because at capture time they haven’t yet undergone checksum calculation (which happens on the NIC). Bad checksums in packet traces may also be a result of packet alteration tools, for example when addresses or ports get rewritten without subsequent checksum correction. In live traffic invalid checksums will be rare and affected packets won’t be processed by endpoints, which is why Zeek opts to discard them by default.

You have three options to work around bad checksums:

1. The -C command line option to Zeek.

2. An script-level option called ignore_checksums that you can redefine (e.g. in your $PREFIX/share/zeek/site/local.zeek):

redef ignore_checksums = T;

3. Disable checksum offloading for your network adapter, but note that this is not always possible or desirable. Disable checksum offloading on the NIC using ethtool

--offload <int> rx off tx off

Replace <int> with the name of your interface.

The longer answer: It really depends! It depends on what you want to analyze, on your skill level, your knowledge of the network stack, the protocol, Zeek’s architecture, C++, Zeek scripting, and more.

Here are tips to get you started:

• If you’d like to make a new kind of packet visible to Zeek, take a look at the packet source machinery in the codebase.
• To add a new packet-level protocol, consult Zeek’s Packet Analysis framework and consult the existing examples here.
• For transport-level protocols, take a look at the DPD/analyzer framework and consult the existing examples here.
• For new analyzers, the tool of choice for writing the parser is Spicy, our parser generator. It provides a safe, dedicated language to capture the syntax and semantics of protocols, and provides convenient integration with Zeek.
• A new analyzer generally comes in the form of a native-code plugin, usually shipped via Zeek package. Take a look at our plugin documentation, and its Spicy-specific variant.
• When looking at older analyzers you’ll notice that Zeek still uses parsers generated by BinPAC, an early precursor of Spicy. Writing new analyzers with BinPAC is possible but not recommended.