Zeek 是什么：被动式开源网络流量分析框架的定位、能力与架构解析

• 网络安全
• 网络
• IDS

导读：本文以 Zeek 官方手册《What Is Zeek?》为核心，系统阐述 Zeek 的定位——一个被动式的开源网络流量分析框架（Network Security Monitor，NSM），而非传统签名型 IDS。你将了解到 Zeek 默认产出的交易日志、文件提取与检测能力、事件引擎与脚本解释器两层架构、集群扩展方式，以及它相对于 Snort/Suricata、Wireshark 等工具的边界，从而准确判断它在你的安全监控体系中的适用位置。

一、Zeek 的定位：被动式网络流量分析框架

Zeek 是一个被动式（passive）的开源网络流量分析器。所谓"被动"，是指它只监听并解读经过网络链路的数据包，不参与数据包的转发，也不直接阻断流量。许多运维团队将其作为网络安全监控器（NSM）使用，用于支撑对可疑或恶意活动的调查；同时，Zeek 的能力并不局限于安全领域，它也广泛用于性能测量与网络排障等流量分析任务。

官方文档对 Zeek 的定位给出了非常明确的三句判断（见 doc/about/what.rst）：

• Zeek不是经典的基于签名的入侵检测系统（IDS）；虽然它也支持签名匹配这类传统功能，但 Zeek 的脚本语言让它能够承载远比签名检测更宽广的恶意活动发现思路，包括语义误用检测、异常检测和行为分析。
• Zeek不是Wireshark 意义上的逐帧协议分析器，不会在帧级别描绘网络流量的每一个元素，也不是大规模以 PCAP 形式存储流量的系统。它处于"快乐的中间地带"：产出紧凑而高保真的网络日志，帮助理解网络流量与使用模式。
• Zeek不参与内核的包转发决策，无法直接阻断、丢弃或修改网络流量；但它通过脚本层 API 与交换机、防火墙等网络基础设施交互，间接实现这类策略。若需要内联（in-path）的入侵防御（IPS），则应考虑以 IPS 模式运行的 Snort 或 Suricata。

二、第一价值：开箱即用的丰富日志

新用户从 Zeek 获得的第一个收益，就是它默认生成的大量网络活动日志。这些日志不仅包含链路上每条连接的综合记录（connection log），还包含应用层会话记录，例如：

• 所有 HTTP 会话及其请求的 URI、关键头部、MIME 类型与服务器响应；
• 带应答的 DNS 请求；
• SSL 证书；
• SMTP 会话的关键内容；
• 以及更多协议细节。

默认情况下，Zeek 将所有这些信息写入结构良好的制表符分隔（TSV）或 JSON 日志，方便外部软件进行后处理。用户也可以让外部数据库或 SIEM 产品消费、存储、处理并呈现这些数据用于查询。

从源码看连接日志的生成

连接日志（conn.log）并非硬编码在 C++ 核心中，而是由 Zeek 脚本实现。在 scripts/base/protocols/conn/main.zeek 中可以看到，脚本定义了一个log_conn事件，将Conn::Info记录（包含连接的历史状态history等字段）交给日志框架：

## Event that can be handled to access the :zeek:type:`Conn::Info` ## record as it is sent on to the logging framework. global log_conn: event(rec: Info); redef record connection += { conn: Info &optional; };

这正印证了 what.rst 中"所有默认分析（包括日志）都由脚本完成，没有任何特定分析被硬编码进系统核心"这一论断。

三、开箱即用的检测与分析功能

除了日志，Zeek 还内置了一系列分析与检测能力，包括：

• 从网络会话中提取文件（file extraction）；
• 通过对接外部注册表检测恶意软件；
• 报告网络上出现的已知存在漏洞的软件版本；
• 识别流行的 Web 应用；
• 检测SSH 暴力破解（brute-forcing）；
• 校验SSL 证书链；
• 等等。

这些能力使得 Zeek 在"开箱即用"层面就具备相当的检测深度，同时它的脚本机制让用户能进一步自定义告警（notice）逻辑，为安全团队提供"判断"（judgement）形式的告警输出。

四、核心架构：事件引擎 + 脚本解释器

Zeek 的架构从宏观上分为两大组件，官方架构图（见 doc/images/architecture.png）清晰地展示了这一分层：

• 事件引擎（Event Engine，又称核心）：把进入的报文流规约为一系列高层事件（events）。这些事件以**策略中立（policy-neutral）**的术语描述网络活动——即它们描述网络上"看到了什么"（what），而不解释"为什么"（why）或是否重要。
• 脚本解释器（Script Interpreter）：执行用 Zeek 脚本语言编写的一组事件处理器（event handlers），为事件赋予语义。这些脚本表达站点的安全策略，例如当监控器检测到不同类型的活动时应该采取什么动作；更一般地，脚本可以从输入流量中推导任意所需的属性与统计信息。

一个典型的例子：链路上的每个 HTTP 请求都会转化为对应的http_request事件。该事件的 C++ 侧声明位于 src/analyzer/protocol/http/events.bif：

event http_request%(c: connection, method: string, original_URI: string, unescaped_URI: string, version: string%);

事件携带了涉及的 IP 地址与端口、被请求的 URI 以及使用的 HTTP 版本，但不传达任何进一步解释——例如该 URI 是否对应一个已知的恶意站点。这种"解释"工作留给脚本解释器来完成。

事件引擎内部的流水线

事件引擎由若干子组件构成，其中最重要的是报文处理流水线，自上而下依次为：

1. 输入源（input sources）：从网络接口摄取进入的网络流量；
2. 报文分析（packet analysis）：处理底层协议，从链路层开始；
3. 会话分析（session analysis）：处理应用层协议，如 HTTP、FTP 等；
4. 文件分析（file analysis）：剖析会话中传输的文件内容。

事件引擎还提供插件架构，允许从 Zeek 核心代码库之外添加以上任一类组件，按需扩展 Zeek 的能力。

脚本语言的本质：领域专属的"Python"

Zeek 为用户提供一种图灵完备的领域专属脚本语言来表达任意分析任务。可以把 Zeek 语言理解为"领域专属的 Python（或 Perl）"：与 Python 一样，系统自带大量预置功能（相当于"标准库"），但用户也可以通过编写自定义代码，以新颖的方式使用 Zeek。关键在于——Zeek 的全部默认分析（包括日志）均由脚本完成，这正是它不同于"固化为少量硬编码分析任务"的其他网络监控工具的根本之处。

此外，Zeek 脚本语言允许脚本跨连接与主机边界维护状态、跟踪并关联其观察对象的演化过程；脚本还能生成实时告警，并按需执行任意外部程序，例如用于触发对攻击的主动响应。

五、面向高速网络的扩展：Zeek 集群

Zeek 专门面向高速、大流量的网络监控场景。大量站点（大学、研究实验室、超算中心、开放科学社区、大型企业与政府机构）用它保护自身基础设施，越来越多的站点用它监控10GE 网络，部分站点已迁移到100GE 链路。

为适应高性能场景，Zeek 支持可扩展的负载均衡：

• 大型站点通常运行"Zeek 集群（Zeek Cluster）"：高速前端负载均衡器把流量分发到合适数量的后端 PC 上；
• 每台后端 PC 运行专用于自身流量分片的 Zeek 实例；
• 一个**中心管理器（manager）**负责协调进程、跨后端同步状态，并为运维人员提供集中的配置管理与聚合日志访问界面；
• Zeek 集成的管理框架ZeekControl开箱即用地支持这类集群部署。

集群特性同时支持单系统与多系统两种形态——这构成 Zeek 可扩展性优势的一部分。管理员可以在单个系统内尽可能多地扩展 Zeek，需要时再透明地增加更多系统。

六、网络安全管理数据视角：Zeek 覆盖了哪几类数据

理解 Zeek 的价值，还可以借助网络安全管理（NSM）的经典数据分类框架（见 doc/about/why.rst）。安全团队依赖四类数据源：第三方情报、网络数据、基础设施与应用数据（含云环境日志）、端点数据；而 Zeek 主要是收集与分析第二类——网络数据的平台。

在网络数据内部，又可分为四种类型：全量内容（full content）、交易数据（transaction data）、提取内容（extracted content）与告警数据（alert data），分别对应记录流量、总结流量、提取内容（文件）与判断流量。

Zeek 作为 NSM 平台，能够覆盖其中至少两种、某种意义上三种数据类型：

交易日志是"无判断、策略中立"的：它们以中立方式描述链路上所见协议与活动，把"是否恶意"的判断留给分析人员或上层脚本。

七、部署形态：从单机嗅探到传感器

Zeek 既可以处理 PCAP 格式的报文捕获文件，也支持实时监听。实际部署中有几种典型形态（详见 doc/about/monitoring.rst）：

• 单机自监控：在用于一般计算的单台计算机（如办公笔记本）上运行 Zeek，观察流向该机的流量。这是熟悉 Zeek 日志的简单入门方式，类似在个人电脑上运行 Tcpdump 或 Wireshark 用于学习。
• 专用传感器（sensor）：大多数用户选择一台专门用于 NSM 的计算机，将其部署在能"看到"多台机器流量的网络位置（如通过网络分流器 tap 或交换机 SPAN 端口），对特定网段进行监控。

传感器选址的核心诉求是：找到一个单一位置，通过 tap 或 SPAN 端口获得最大可见性，即能看到网段内所有设备的流量，且优先以原始源 IP 地址识别设备。文档特别分析了典型的家庭/小型办公（SOHO）网络——由于路由器 NAT 的存在，所有内网设备共享单一公网 IP，导致安全分析难以追溯可疑流量的真正来源；而"面向可见性设计"的网络架构（路由器与无线 AP 功能分离、自带带 SPAN 端口的交换机、WAP 不做 NAT）才能在合适的监控点（如图中的位置 D）获得高质量流量。

八、运维生态与历史背景

Zeek 拥有可追溯至 1990 年代的深厚历史（见 doc/about/history.rst）：

• 1995 年，Vern Paxson 在劳伦斯伯克利国家实验室（LBNL）设计并实现了最初版本，原名Bro——取"监控与隐私侵犯如影随形"的奥威尔式提醒之意；
• 1996 年 LBNL 首次部署，1998 年相关论文获 USENIX Security 最佳论文奖；
• 此后 NSF 资助 ICSI 持续研究与开发，2012 年 2.0 版本完成大规模用户侧改造，同年加入原生 IPv6 支持；2014 年推出 try.zeek.org 在线实验平台；随后加入 Broker 通信框架（支撑集群与外部通信）与 2016 年的 Zeek 包管理器；
• 2018 年秋项目更名为Zeek，2019 年秋发布首个以 Zeek 命名的 3.0 版本。

当前仓库中，Broker 通信框架位于 auxil/broker，包管理器位于 auxil/package-manager，而官方文档全集可从 doc/about/index.rst 进入。

九、总结：Zeek 适合什么、不适合什么

一句话概括：Zeek 是为"解读网络流量并基于流量生成日志"而优化的系统，而非为字节匹配（byte-matching）而优化。

适合的场景：

• 需要高保真交易日志支撑安全调查、威胁狩猎（hunting）与事件响应取证；
• 需要从流量中提取文件送入沙箱分析；
• 需要用图灵完备脚本语言实现自定义检测（语义误用、异常、行为分析）与状态关联；
• 需要在高速、大流量环境（10GE/100GE）下以集群方式横向扩展。

不适合的场景：

• 需要签名检测的经典 IDS 场景——应优先考虑 Snort、Suricata；
• 需要逐帧查看流量细节——应使用 Wireshark；
• 需要大规模PCAP 全量留存——应交给专门的抓包存储软件；
• 需要内联阻断的 IPS——应使用 Snort/Suricata 的 IPS 模式（Zeek 只能通过脚本 API 间接联动交换机与防火墙）。

理解这份定位清单，是在安全监控体系里为 Zeek 找到正确身位的第一步。

• 网络安全
• 网络
• IDS