企业官网建设流程全解析

• 网络安全
• 网络
• IDS

导读

本文以 Zeek 的监控定位为出发点，系统讲解如何围绕 Zeek 搭建一套完整的网络安全监控（NSM）体系：从"检测与响应"的分析工作流（匹配已知指标 vs. 假设驱动猎杀）、传感器在网络中的部署位置选择，到日志的存储、格式与回顾方法。读完本文，你将掌握 Zeek 在四类监控数据中的能力边界、如何在 SOHO 与"可见网络"架构中选点部署传感器、如何利用 Community ID 将 IDS 告警与 Zeek 日志关联 pivot，以及如何配置日志输出格式与压缩以便对接 SIEM 平台。

一、Zeek 在网络安全监控数据谱系中的定位

Zeek 官方文档将网络安全监控数据划分为四种类型，而 Zeek 开箱即用地擅长其中两类：

也就是说，无需任何重大配置，Zeek 就能以日志形式提供"线路上经过的协议与文件"的总结（事务数据与提取内容数据）。同时 Zeek 也能以notice的形式提供一定程度的警报数据——分析师可以根据需要修改 Zeek 脚本创建自定义告警。但若需要专门的入侵检测告警引擎，Suricata 或 Snort 这类专用 IDS 可能更合适。而 Zeek 并不以 PCAP 格式采集全内容数据，该功能由其他开源项目提供。

从源码结构看，这条定位贯穿了整个仓库：src/analyzer/（协议分析器）、src/file_analysis/（文件分析框架）、scripts/base/frameworks/notice/（notice 框架）分别对应事务数据、提取内容与告警数据三条产出路径。

二、检测与响应工作流：Matching、Hunting 与告警 Pivot

安全事件检测与响应，广义上始于安全数据的采集，继之以分析。在没有明确恶意活动告警的情况下，调查人员有两种分析范式：匹配（Matching）与猎杀（Hunting）。

2.1 Matching：已知指标匹配

Matching 指在安全数据中查询、审阅已知入侵指标（IoC）的迹象——匹配某个 IP 地址、用户名、HTTP User-Agent 字符串，或 Zeek 从网络流量中推导出的数百个字段中的任意一个或组合。这类活动极易自动化，本质是对采集数据中"预期中的坏"做检索。

2.2 Hunting：假设驱动的科学方法

一些团队常把"查询 IoC"误称为 hunting，但那其实只是搜索功能。真正的 hunting 更接近科学方法：提出假设 → 在样本与生产数据中验证假设 → 反复精炼流程，直到得出结果或被证伪。分析师可以设想某种敌手行为在 Zeek 数据中会如何显现，再去查询数据寻找支持或否定假设的证据。由于依赖人工构建"安全实验"并常常需要一点直觉，hunting 很难自动化。

2.3 告警驱动的 Pivot 工作流

在"事件检测告警"工作流中，IDS 生成告警引起安全团队成员注意。由于 IDS 告警往往信息量不足，分析师需要佐证数据来判断告警属于正常、可疑还是恶意活动。此时分析师可以从 IDS 告警pivot（跳转）到 Zeek 生成的各类日志：

• 若 IDS 告警携带 Zeek 支持的Community ID，分析师可以轻松把 IDS 告警与具体的 Zeek 日志关联起来；
• 基于 Zeek 提供的数据，分析师可能直接解决事件；
• 至少，分析师能借助初始 IDS 通知之外的更多数据，加速告警验证与确认流程。

2.4 外部刺激驱动的验证

最后，Zeek 数据还能改进任何外部刺激触发的验证流程。例如 EDR 或杀毒代理报告某系统上有可疑进程，或用户/同事报告面向互联网的 Web 服务器存在可疑活动——分析师只需查询存放 Zeek 日志的仓库，就能尽可能全面地了解相关系统。这一安全设计模式价值巨大，因为它不触碰可疑资产本身：

1. 入侵者不会察觉安全团队正在调查；
2. 资产的取证完整性得以保持——分析师操作的是存储在设备之外的日志。

2.5 源码级佐证：Community ID 实现

Community ID 关联能力的底层实现在 src/communityid.bif 中，它通过 BIF 机制向 Zeek 脚本暴露了community_id_v1内置函数：

function community_id_v1%(cid: conn_id, seed: count &default=0, do_base64: bool &default=T%): string

从实现细节看，该函数对连接五元组做规范化处理（必要时交换源/目的以保持方向无关性）、按传输层协议区分 TCP/UDP/ICMP/ICMPv6，再以 SHA-1 计算哈希，最终输出带1:版本前缀的字符串（默认再做 Base64 编码以缩短长度，相关代码见 src/communityid.bif）。

在策略层，Zeek 通过两个脚本把该哈希接入日常日志：

• scripts/policy/protocols/conn/community-id-logging.zeek：定义CommunityID::seed（默认 0，16 位哈希种子）与CommunityID::do_base64（默认 T）两个 option，为Conn::Info记录追加community_id字段，并在new_connection事件中计算填充；
• scripts/policy/frameworks/notice/community-id.zeek：把community_id同步到Notice::Info，使 notice 日志也能携带该 ID，并可通过CommunityID::Notice::enabled在运行时开关。

启用方式（两脚本会自动加载所需的base/protocols/conn与 notice 框架）：

$ zeek -r ./traces/get.pcap protocols/conn/community-id-logging LogAscii::use_json=T $ jq < conn.log { "ts": 1362692526.869344, "uid": "CoqLmg1Ds5TE61szq1", "id.orig_h": "141.142.228.5", "id.orig_p": 59856, "id.resp_h": "192.150.187.43", "id.resp_p": 80, "proto": "tcp", ... "community_id": "1:yvyB8h+3dnggTZW0UEITWCst97w=" }

community_id_v1也可以直接在命令行对任意conn_id记录求值，方便在脚本或一次性调查中手工比对：

$ zeek -e 'print community_id_v1([$orig_h=141.142.228.5, $orig_p=59856/tcp, $resp_h=192.150.187.43, $resp_p=80/tcp])' 1:yvyB8h+3dnggTZW0UEITWCst97w=

三、仪表化与采集：传感器的部署位置

Zeek 被设计用于观察实时网络流量。虽然它也能处理 PCAP 格式的抓包文件，但多数用户部署 Zeek 是为了对网络使用模式获得近实时洞察：管理员让 Zeek "嗅探"一个或多个网络接口，基于所见流量生成事务日志、洞察与提取的文件内容。

3.1 两种运行形态：单机实验 vs. 专用传感器

• 单机运行：在承担通用计算任务的计算机上运行 Zeek，观察进出该机的流量。例如用办公笔记本做实验——这是熟悉 Zeek 日志的最简单方式，类似在自己电脑上运行 Tcpdump 或 Wireshark 用于教学。
• 传感器（Sensor）运行：多数用户把 Zeek 部署在一台专门用于网络安全监控的机器上。安全人员称其为"sensor"，会专门选择、配置并部署它来观察网络流量，把位置选在环境中对多台计算机都有可见性的地方，用 Zeek 对该网段做仪表化。

选点优先级：在网络中找出单一位置，用网络 TAP 或交换机 SPAN 端口实现最大可见性——即能看见网络上所有设备的流量，且强烈偏好以设备原始源 IP 地址来识别它们。

3.2 标准 SOHO 架构：为什么默认不适于监控

对 Zeek 新手，在家或小办公室尝试部署是常见起点。下图是标准 SOHO 网络架构，字母 A–D 是四个候选监控位置。

背景知识：多数家庭与小办公室经 ISP 提供的客户驻地设备（CPE）接入互联网；ISP 还提供兼具路由与无线接入点（WAP）功能的网关设备——常见形态是 WAN 侧一条千兆铜缆以太网连 ISP CPE，LAN 侧四个千兆铜缆以太网口供设备接入，客户设备经 WiFi 或铜缆连入。路由器 WAN 侧通常持有 ISP 分配的公网 IP，LAN 侧提供 RFC 1918 私网地址（常见于 192.168.0.0/16 网段），并通过 NAT（严格说是网络端口地址转换 NPAT）让客户设备共享单个公网 IP。个别情况下多个住户甚至共享同一公网 IP、仅靠端口范围区分彼此。

逐一评估 A–D 四个位置：

结论：标准 SOHO 架构并不适合网络安全监控——默认没有好位置能看到通常调查所需的原始源 IP 地址。

3.3 可见网络架构：把可见性设计进去

与上图相对的是"可见网络架构"（Visible Network Architecture）——可见性在设计阶段就被纳入，而非事后补救。

该架构的关键改动：

• ISP 路由器不再兼任 WAP（WiFi 能力被禁用；严格说只要无人使用，WiFi 不必物理禁用）；
• 客户自购路由器（是否提供 NAT 均可）；
• 客户明确拥有一台交换机，有线设备接入，且该交换机带SPAN 端口；
• 客户明确拥有自己的无线接入点，以**桥接（bridge）**模式工作、不做 NAT。

关键点：不要以为买一台新的路由/WAP 组合设备就行。必须拆分这些功能——消费级路由器不提供 SPAN 端口，而廉价消费级交换机反而提供。本架构正是利用这一点获得合适的监控位置。

逐一评估 A–G：

结论：D 是最佳监控位置，前提是客户 WAP 不做 NAT；若客户 WAP 充当带 NAT 的路由器，则 D 点看到的所有无线设备都会是同一个源 IP。在面向可见性设计的架构中，在 D 点引入网络 TAP 或直接 SPAN 交换机上行链路，即可满足可见性需求。

3.4 简化版可见网络架构

上述架构还可进一步简化：去掉 C 与 D 之间的客户路由器，必要时直接依赖 ISP 路由器。

此时 C 与 D 逻辑上相似，Zeek 传感器部署在 C 或 D 均可；后续讨论默认以D 点监控为准。

3.5 在 D 点获取流量的两种手段

• 交换机 SPAN 端口：在客户交换机上启用 SPAN（端口镜像）；
• 网络 TAP：在 D 点部署物理分路器。

专业 Zeek 用户在有条件时优先选择高质量、有源的网络 TAP，原因包括不依赖交换机配置、不丢包、物理隔离等；在 SOHO 或测试环境中 TAP 不可用，可管理交换机的 SPAN 端口是合格替代方案。

一旦 TAP 或 SPAN 端口把流量供给 Zeek 传感器，就可以转向仪表化与采集之外的事项（即下面的存储与回顾）。从仓库佐证看，传感器接入流量后由 src/iosource/ 的包源（pcap、af_packet 等）驱动 src/packet_analysis/ 的分包处理链路，再分发给 src/analyzer/ 的协议分析器与 src/file_analysis/ 的文件分析器，最终沉淀为各类日志。

四、存储与回顾：日志、格式与 SIEM 对接

4.1 默认存储位置与路径

Zeek 消化流量（实时接口或 PCAP 文件）时产生多种日志与其他产物，默认写入由配置文件指定的存储位置。核心配置项在 scripts/base/frameworks/logging/main.zeek：

• Log::default_logdir（默认""，即当前工作目录）：默认日志目录，同时用于轮转日志存放；
• Log::default_writer（默认WRITER_ASCII）：默认写入器；
• Log::separator（默认\t）、Log::set_separator（默认,）、Log::empty_field（默认(empty)）、Log::unset_field（默认-）：控制 ASCII 输出的字段分隔与空值表示。

路径解析由Log::default_path_func依据日志流 ID 自动派生（例如conn流得到conn.log）；在命令行加载 site 脚本时，脚本搜索前缀通过zeek -p/--prefix或$ZEEK_PREFIXES环境变量控制（见 src/Options.cc）。

4.2 输出格式：ASCII 与 JSON

Zeek 具备把日志写成多种格式并执行压缩、归档等管理操作的能力。最常用的格式选项集中在 scripts/base/frameworks/logging/writers/ascii.zeek 的LogAscii模块，常用项如下（均可在命令行以LogAscii::xxx=值覆盖，也可作为日志 Filter 的$config逐过滤器设置）：

命令行覆盖示例（输出 JSON 并压缩）：

$ zeek -r ./traces/quickstart.pcap LogAscii::use_json=T LogAscii::gzip_level=6

回顾方式可以简单到使用操作系统自带的文本处理工具；视日志格式不同，也可以使用 Zeek 随附的专用处理工具（例如zeek-cut，见 tools/zeek-cut/）。在许多情况下，管理员会把日志投递到专门的存储与回顾应用——即统称的SIEM（安全与信息事件管理）平台，其中部分以开源形式提供，部分为商业产品。Zeek 的 JSON 输出、时间戳与字段规范化设计，正是为了降低这类对接成本。

4.3 分析工作流与存储结合

回顾 第二节 的工作流：matching 场景下，分析师直接查询 Zeek 事务日志库匹配 IoC；hunting 场景下，分析师在样本与生产数据中验证假设；IDS 告警场景下，借助 Community ID 字段把告警与conn.log、notice.log等记录关联。无论哪种范式，都依赖一个可查询、可保留的日志存储——这正是 Zeek 日志管理能力（格式、压缩、归档）与 SIEM 对接存在的意义。

五、小结：从采集到分析的一条龙实践要点

1. 明确能力边界：Zeek 默认产出事务数据与提取内容数据，notice 机制提供部分告警能力，全内容 PCAP 留存需借助其他工具；
2. 选对范式：自动化匹配 IoC 用 matching；需要探索未知敌手行为时，用假设驱动、可证伪的 hunting 流程；
3. 善用 Community ID：加载 community-id-logging.zeek 与 community-id.zeek，即可用1:...形式的流哈希在 IDS 告警与 Zeek 日志之间 pivot，底层由community_id_v1（src/communityid.bif）保证方向无关的稳定计算；
4. 把可见性设计进网络：优先采用"可见网络架构"，在 D 点（或简化架构的 C 点）用有源 TAP 或交换机 SPAN 获取流量，确保看到原始源 IP；
5. 管理好日志生命周期：用LogAscii::use_json、LogAscii::gzip_level等配置控制格式与压缩，按需对接开源或商业 SIEM，让日志沉淀为可持续查询的取证资产。

• 网络安全
• 网络
• IDS