You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I’m exploring ways to contribute to the documentation, specifically around clarifying Zeek’s architectural visibility boundaries for new users. Many new users initially assume Zeek provides host-level context, full packet retention, or primarily signature-based detection, which can lead to confusion during deployment or incident response.
I would like to propose adding a small section under Deployment, Architecture, or Security Considerations that explains these intentional design boundaries:
Zeek does not store raw PCAP:
Zeek analyzes live traffic or packet captures to generate structured logs and extracted artifacts, but it does not retain raw packet captures as part of its normal operation. Organizations requiring packet retention typically deploy dedicated tools such as tcpdump, Arkime, or Stenographer alongside Zeek.
Zeek does not provide host-level context:
Zeek observes network activity rather than endpoint state, so it does not natively provide process execution, user logon information, kernel events, or other operating-system telemetry.
Zeek is not signature-based:
Zeek's primary detection model is protocol-aware scripting and behavioral analysis rather than signature matching. Although Zeek includes a Signature Framework, many deployments pair it with dedicated signature-based IDS tools such as Suricata or Snort to improve detection of known threats.
Encrypted traffic limits deep inspection:
When traffic is encrypted and cannot be decrypted, Zeek's visibility is largely limited to connection metadata, TLS handshake information (such as certificates and protocol parameters), and other observable network characteristics rather than application layer payloads.
My goal is to help new users understand Zeek’s intended role in a monitoring stack and prevent common misconceptions. Before drafting a PR, I would like to ask:
Would this content be appropriate for the documentation?
If so, where would you prefer it to be placed?
Are there any phrasing or scope guidelines I should follow?
Thank you for your guidance - I would be happy to prepare a PR once I know the preferred structure.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Hello Zeek Team,
I’m exploring ways to contribute to the documentation, specifically around clarifying Zeek’s architectural visibility boundaries for new users. Many new users initially assume Zeek provides host-level context, full packet retention, or primarily signature-based detection, which can lead to confusion during deployment or incident response.
I would like to propose adding a small section under Deployment, Architecture, or Security Considerations that explains these intentional design boundaries:
Zeek does not store raw PCAP:
Zeek analyzes live traffic or packet captures to generate structured logs and extracted artifacts, but it does not retain raw packet captures as part of its normal operation. Organizations requiring packet retention typically deploy dedicated tools such as tcpdump, Arkime, or Stenographer alongside Zeek.
Zeek does not provide host-level context:
Zeek observes network activity rather than endpoint state, so it does not natively provide process execution, user logon information, kernel events, or other operating-system telemetry.
Zeek is not signature-based:
Zeek's primary detection model is protocol-aware scripting and behavioral analysis rather than signature matching. Although Zeek includes a Signature Framework, many deployments pair it with dedicated signature-based IDS tools such as Suricata or Snort to improve detection of known threats.
Encrypted traffic limits deep inspection:
When traffic is encrypted and cannot be decrypted, Zeek's visibility is largely limited to connection metadata, TLS handshake information (such as certificates and protocol parameters), and other observable network characteristics rather than application layer payloads.
My goal is to help new users understand Zeek’s intended role in a monitoring stack and prevent common misconceptions. Before drafting a PR, I would like to ask:
Would this content be appropriate for the documentation?
If so, where would you prefer it to be placed?
Are there any phrasing or scope guidelines I should follow?
Thank you for your guidance - I would be happy to prepare a PR once I know the preferred structure.
All reactions