网络安全网络IDS【免费下载链接】zeekZeek is a powerful network analysis framework that is much different from the typical IDS you may know.项目地址https://gitcode.com/gh_mirrors/ze/zeek点击查看免费下载本文以仓库中自动生成的 autogenerated-packet-analyzer-index.rst 为骨架系统梳理 Zeek 内置的全部报文分析器packet analyzer从PacketAnalyzer::Tag枚举的 35 个分析器标识到每个分析器对外暴露的 Zeek 事件与函数签名、参数语义与触发条件并对照 src/packet_analysis 下的 C 实现与 scripts/base/packet-protocols 下的注册脚本讲清分析器如何被挂载、如何逐层转发、事件何时触发的完整链路。读完本文你将能读懂任意packet_analysis相关脚本掌握编写 ARP、GTPv1、Geneve、Teredo、VXLAN 等事件处理器的准确姿势并具备在源码层面定位分析器行为的能力。1. 背景Zeek 的报文分析器框架是什么Zeek 在传统协议分析器面向会话/连接如 HTTP、DNS 的Analyzer之外维护着一套独立的报文级packet-level分析器体系即packet_analysis框架。它逐包处理抓取到的原始帧负责解析链路层头Ethernet、VLAN、Linux SLL、IEEE 802.11 等识别并解封装隧道协议GRE、GTPv1、Geneve、VXLAN、Teredo、AYIYA、IPTunnel 等解析网络层与传输层IP、TCP、UDP、ICMP、IGMP并把数据交给会话层分析器继续处理。框架的核心类全部位于 src/packet_analysisManager分析器总管理器持有全部已注册分析器实例std::mapstd::string, AnalyzerPtr analyzers负责实例化、启停、ProcessPacket()入口调度与未知协议上报Analyzer所有报文分析器的抽象基类核心虚函数是AnalyzePacket()转发用ForwardPacket()协议探测用DetectProtocol()Dispatcher维护协议标识identifier→ 子分析器的映射表供父分析器按头字段查表转发Component以插件组件形式把每个分析器注册进Manager。处理流程见 Manager.cc 的ProcessPacket()每收到一个包Manager先清理分析器栈analyzer_stack.clear()然后把整包从Root分析器开始沿链路层类型标识逐层向下转发——这正是下文所有事件与函数赖以触发的执行环境。2.PacketAnalyzer::Tag35 个内置分析器标识总览文档第一部分定义了PacketAnalyzer::Tag枚举是脚本层引用分析器的唯一入口。下表按功能分组列出全部枚举值对应源码目录为 src/packet_analysis/protocol分类Tag 枚举说明实现目录链路层ANALYZER_ETHERNETEthernet 帧protocol/ethernet链路层ANALYZER_VLANVLAN802.1Qprotocol/vlan链路层ANALYZER_VNTAGCisco VN-Tagprotocol/vntag链路层ANALYZER_LLC逻辑链路控制protocol/llc链路层ANALYZER_SNAPSNAP 封装protocol/snap链路层ANALYZER_NOVELL_802_3Novell 802.3 变体protocol/novell_802_3链路层ANALYZER_PPP/ANALYZER_PPPSERIALPPP / 串行 PPPprotocol/ppp、protocol/ppp_serial链路层ANALYZER_PPPOEPPPoEprotocol/pppoe链路层ANALYZER_FDDIFDDIprotocol/fddi链路层ANALYZER_LINUXSLL/ANALYZER_LINUXSLL2Linux cooked capture v1/v2protocol/linux_sll、protocol/linux_sll2链路层ANALYZER_IEEE802_11/ANALYZER_IEEE802_11_RADIO802.11 / Radiotapprotocol/ieee802_11、protocol/ieee802_11_radio链路层ANALYZER_NFLOGnetfilter logprotocol/nflog链路层ANALYZER_NULLBSD nullDLT_NULLprotocol/null地址解析ANALYZER_ARPARP事件最丰富之一protocol/arp网络层ANALYZER_IPIPv4/IPv6 统一入口protocol/ip网络层ANALYZER_TCP/ANALYZER_UDP传输层会话适配protocol/tcp、protocol/udp网络层ANALYZER_ICMP/ANALYZER_IGMPICMP / IGMPprotocol/icmp、protocol/igmp网络层ANALYZER_UNKNOWN_IP_TRANSPORT未知 IP 传输层protocol/unknown_ip_transport隧道ANALYZER_GREGRE 隧道protocol/gre隧道ANALYZER_GTPV1GTPv1事件最丰富之一protocol/gtpv1隧道ANALYZER_GENEVEGeneve 隧道protocol/geneve隧道ANALYZER_VXLANVXLAN 隧道protocol/vxlan隧道ANALYZER_TEREDOTeredoIPv6 过渡protocol/teredo隧道ANALYZER_AYIYAAYIYA 隧道protocol/ayiya隧道ANALYZER_IPTUNNELIP-in-IPprotocol/iptunnel隧道ANALYZER_MPLS/ANALYZER_PBBMPLS / PBBprotocol/mpls、protocol/pbb系统ANALYZER_ROOT根分析器入口占位protocol/root系统ANALYZER_SKIP跳过分析protocol/skip注意ANALYZER_ICMP、ANALYZER_TCP、ANALYZER_UDP、ANALYZER_UNKNOWN_IP_TRANSPORT四个 Tag 出现在枚举中但该参考文档没有为它们单列插件小节——它们主要作为 IP 层向传输层转发、以及后续会话分析器的接驳点存在参见 scripts/base/packet-protocols/ip/main.zeek 中IPPROTO_TCP/IPPROTO_UDP/IPPROTO_ICMP的注册。Root分析器值得单独说明在 Root.cc 中它的AnalyzePacket()直接触发InternalError因为 Root 只作为Manager::ProcessPacket()的转发起点root_analyzer-ForwardPacket(...)真正的逻辑由Dispatcher按packet-link_type查表交给对应链路层分析器。3. ARP 分析器arp_request/arp_reply/bad_arpARP 是本参考文档中第一个、也是事件语义最完整的分析器对应源码目录 src/packet_analysis/protocol/arp。3.1 三个事件的签名与参数arp_request与arp_reply签名完全一致差异仅在触发场景为 ARP 请求或应答event arp_request(mac_src: string, mac_dst: string, SPA: addr, SHA: string, TPA: addr, THA: string); event arp_reply(mac_src: string, mac_dst: string, SPA: addr, SHA: string, TPA: addr, THA: string);参数类型含义mac_srcstring帧的源 MAC 地址mac_dststring帧的目的 MAC 地址SPAaddrSender Protocol Address发送方协议地址IPv4SHAstringSender Hardware Address发送方硬件地址形如aa:bb:cc:dd:ee:ffTPAaddrTarget Protocol Address目标协议地址THAstringTarget Hardware Address目标硬件地址bad_arp针对 Zeek 无法合理解释的 ARP 包event bad_arp(SPA: addr, SHA: string, TPA: addr, THA: string, explanation: string);除与上面相同的四个地址参数外多出的explanation: string是对为什么该包被判定为 bad的简短文字说明。3.2 触发语义与源码实现从 ARP.cc 可还原完整的判定链路这些判定直接决定了上述事件何时触发头完整性检查sizeof(struct arp_pkthdr) len时记truncated_ARPweird硬件类型检查仅接受ARPHRD_ETHER1与ARPHRD_IEEE8026且要求ar_hln 6以太网地址长度否则触发bad_arpunknown-arp-hw-address/corrupt-arp-header协议类型检查仅支持ETHERTYPE_IP0x0800且ar_pln 4IPv4不支持 IPv6 地址源码注释明确We dont support IPv6 addresses一致性校验帧的 L2 源地址必须等于 ARP 发送方硬件地址ar_sha否则触发bad_arpweird-arp-shaopcode 分派ARPOP_REQUEST1→arp_requestARPOP_REPLY2→arp_replyRARP/InARP 等未实现 opcode 与未知 opcode 均触发bad_arpunimplemented-arp-opcode/invalid-arp-opcode。也就是说只要 MAC 地址格式/长度非法、协议地址非 IPv4、或发送方地址与帧源地址不符Zeek 就会通过bad_arp事件报告并附上原因字符串。这也是 events.bif 中该事件文档标注非标准硬件地址格式或硬件地址与报文发起者不匹配的落地实现。3.3 关于bad_arp的启用限制文档 TODO 的实锤参考文档在bad_arp条目下附了一条todoZeek 当前默认配置并不激活产生该事件的协议分析器——对应的脚本尚未移植完成若想启用需要为它注册端口或添加 DPD动态协议检测payload 签名。这一点在 src/packet_analysis/protocol/arp/events.bif 中同样存在编写依赖bad_arp的脚本前务必知晓默认安装下该事件不会触发。4. 隧道类分析器的事件与函数详解隧道分析器是报文分析器最有价值的应用场景它们负责剥离外层头、解出内层包并同时把隧道本身的信息以事件形式暴露给脚本层。参考文档中隧道相关的事件/函数如下。4.1 Genevegeneve_packet与PacketAnalyzer::Geneve::get_options事件签名event geneve_packet(outer: connection, inner: pkt_hdr, vni: count);参数类型含义outerconnectionGeneve 隧道外层连接innerpkt_hdr内层 Ethernet 帧头与传输层头vnicountGeneve Network IdentifierVNI文档明确标注RFC 8926 定义的协议该事件按包触发实时分析时处理它可能特别昂贵同款标注还出现在 VXLAN、Teredo、GTPv1 G-PDU 事件上。测试用例 testing/btest/core/tunnels/geneve.zeek 展示了标准用法——配合load base/frameworks/tunnels与load base/protocols/conn在事件里打印c$id、inner与vni对应抓包样本在 testing/btest/Traces/tunnels/geneve.pcap。配套函数BIF定义于 src/packet_analysis/protocol/geneve/functions.biffunction PacketAnalyzer::Geneve::get_options(): geneve_options_vec_vec;返回当前包所有层级的 Geneve options外层 vector 的最后一个条目是最内层Geneve 头的 options返回类型是PacketAnalyzer::Geneve::Optionrecord 的 vector 的 vectorgeneve_options_vec_vec。测试 testing/btest/core/tunnels/geneve-get-options.zeek 与样本 testing/btest/Traces/tunnels/geneve-many-options.pcap 可用于验证多 options 场景下的取值顺序。4.2 VXLANvxlan_packetevent vxlan_packet(outer: connection, inner: pkt_hdr, vni: count);参数语义与geneve_packet完全同构RFC 7348outer为 VXLAN 隧道外层连接inner为 VXLAN 封装的 Ethernet 头与传输层头vni为 VXLAN Network Identifier。同样按包触发、实时分析成本高。4.3 Teredo四个事件与一个函数Teredo 是 IPv6-over-UDP 过渡隧道RFC 4380参考文档为它列出 4 个事件全部按包触发event teredo_packet(outer: connection, inner: teredo_hdr); # 任意 Teredo 隧道内的 IPv6 包 event teredo_authentication(outer: connection, inner: teredo_hdr); # 使用 Teredo authentication 封装方式 event teredo_origin_indication(outer: connection, inner: teredo_hdr); # 使用 origin indication 封装方式 event teredo_bubble(outer: connection, inner: teredo_hdr); # Bubble 包Next Header 为 IPPROTO_NONEouterTeredo 隧道外层连接innerTeredo 封装的 IPv6 包头与传输层头teredo_bubble的判定依据内层 IPv6 包 Next Header 值为IPPROTO_NONE即 Teredo bubble四个事件彼此以zeek:see交叉引用方便按需求组合使用。另有与 GTPv1 同构的状态清理函数function PacketAnalyzer::TEREDO::remove_teredo_connection(cid: conn_id): bool;它配合new_teredo_state事件定义于 scripts/base/packet-protocols/teredo/main.zeek使用该事件在每连接 Teredo 状态创建时触发主要用于安装连接移除钩子以清理内部 per-connection Teredo 状态——remove_teredo_connection即该清理动作的脚本层入口。4.4 GTPv1控制面信令事件全集GTPv1 分析器目录 src/packet_analysis/protocol/gtpv1解析器由 gtpv1.pac 等 binpac 文件生成除通用事件外还针对 GTPv1-C 控制面消息提供成套事件event new_gtpv1_state(c: connection); event gtpv1_message(c: connection, hdr: gtpv1_hdr); event gtpv1_g_pdu_packet(outer: connection, inner_gtp: gtpv1_hdr, inner_ip: pkt_hdr); event gtpv1_create_pdp_ctx_request(c: connection, hdr: gtpv1_hdr, elements: gtp_create_pdp_ctx_request_elements); event gtpv1_create_pdp_ctx_response(c: connection, hdr: gtpv1_hdr, elements: gtp_create_pdp_ctx_response_elements); event gtpv1_update_pdp_ctx_request(c: connection, hdr: gtpv1_hdr, elements: gtp_update_pdp_ctx_request_elements); event gtpv1_update_pdp_ctx_response(c: connection, hdr: gtpv1_hdr, elements: gtp_update_pdp_ctx_response_elements); event gtpv1_delete_pdp_ctx_request(c: connection, hdr: gtpv1_hdr, elements: gtp_delete_pdp_ctx_request_elements); event gtpv1_delete_pdp_ctx_response(c: connection, hdr: gtpv1_hdr, elements: gtp_delete_pdp_ctx_response_elements);语义要点new_gtpv1_statescripts/base/packet-protocols/gtpv1/main.zeek新 GTP 分析器为某连接实例化时触发用途与new_teredo_state一致——安装连接移除钩子以清理 per-connection GTPv1 内部状态gtpv1_message任何带 GTPv1 头的 GTP 消息都会触发是通用入口gtpv1_g_pdu_packet按包触发的 G-PDU 事件UDP 载荷为 GTP 头 IPv4/IPv6 包实时处理成本高inner_gtp为 GTP 头inner_ip为内层 IP 与传输层头六个 PDP Context 事件一一对应 Create/Update/Delete 的 Request/Response 六种控制面消息elements为构成消息的 Information Elements 集合类型随消息不同而不同gtp_*_pdp_ctx_*_elements各具专属 record 类型。配套函数与 Teredo 同构function PacketAnalyzer::GTPV1::remove_gtpv1_connection(cid: conn_id): bool;4.5 AYIYA / GRE / IPTunnel / MPLS / PBB仅组件注册AYIYA、GRE、IPTunnel、MPLS、PBB 五个隧道分析器在参考文档中没有事件/函数小节属于纯转发型分析器。它们的职责全部体现在注册脚本中例如 scripts/base/packet-protocols/ayiya/main.zeek 把 AYIYA 的 IPv4/IPv6 载荷直接交给ANALYZER_IPevent zeek_init() { PacketAnalyzer::register_packet_analyzer(PacketAnalyzer::ANALYZER_AYIYA, IPPROTO_IPV4, PacketAnalyzer::ANALYZER_IP); PacketAnalyzer::register_packet_analyzer(PacketAnalyzer::ANALYZER_AYIYA, IPPROTO_IPV6, PacketAnalyzer::ANALYZER_IP); }4.6 其余隧道/链路层分析器小结PPPoE 提供唯一的会话函数function PacketAnalyzer::PPPoE::session_id(): count;返回当前包的 PPPoE Session ID若不存在则返回0xFFFFFFFF超出合法 Session ID 范围作为哨兵值。IP、VLAN、LinuxSLL、IEEE 802.11、LLC、SNAP、NFLog、FDDI、Null、Skip、PPPSerial、NOVELL_802_3 等分析器在参考文档中均只有组件条目对应各自的ANALYZER_*枚举事件与函数由其他协议模块如 conn 框架间接消费因此不在此参考页重复列出。5. IGMP 分析器成员关系事件IGMP 分析器由 Spicy 实现src/packet_analysis/protocol/igmp/igmp.spicy 与 igmp.evt脚本层类型定义在 scripts/base/packet-protocols/igmp/types.zeek事件定义在 scripts/base/packet-protocols/igmp/spicy-events.zeek。event IGMP::message(packet: raw_pkt_hdr, msg_type: IGMP::MessageType); # 每个被处理的 IGMP 消息 event IGMP::membership_query(source: addr, group_addr: addr); # 每个 Membership Query event IGMP::membership_report_v1(source: addr, group_addr: addr); # IGMPv1 Membership Report event IGMP::membership_report_v2(source: addr, group_addr: addr); # IGMPv2 Membership Report event IGMP::membership_report_v3(source: addr, groups: vector of IGMP::Group); # IGMPv3 Membership Report event IGMP::leave_group(source: addr, group_addr: addr); # IGMPv2 Leave Group参数语义IGMP::message全量入口packet为原始包头raw_pkt_hdrmsg_type为IGMP::MessageType枚举membership_query/membership_report_v1/v2/leave_groupsource为源地址group_addr为组播组地址membership_report_v3IGMPv3 支持多组记录故第二个参数是vector of IGMP::Group。值得注意的细节membership_report_v1、membership_report_v2、membership_report_v3、leave_group四个事件的源码定位并不在 IGMP 分析器目录而在策略脚本 scripts/policy/protocols/conn/multicast-participants.zeek——它们由 policy 层在底层事件之上派生而来用于维护组播参与者视图。这印证了参考文档作为自动生成索引的本质事件可能来自bif、Spicy EVT 或纯 Zeek 脚本三个来源参考文档的:source-code:指令即记录每个符号的定义位置。6. 理解组件注册 事件分派的完整链路参考文档列出的是结果理解其生成机制能帮你更准确地使用这些 API。核心机制落在两个文件BIF 层 src/packet_analysis/packet_analysis.bif 与脚本注册层 scripts/base/packet-protocols。6.1 脚本层挂载register_packet_analyzerBIF 函数packet_analysis.bif在 C 侧调用parent_analyzer-RegisterProtocol(identifier, child)把标识 → 子分析器写入父分析器的Dispatcherfunction register_packet_analyzer(parent: PacketAnalyzer::Tag, identifier: count, child: PacketAnalyzer::Tag): bool;各内置模块在zeek_init中完成挂载例如 scripts/base/packet-protocols/ethernet/main.zeek 的完整映射表EtherType → 分析器PacketAnalyzer::register_packet_analyzer(PacketAnalyzer::ANALYZER_ETHERNET, 0x8847, PacketAnalyzer::ANALYZER_MPLS); # MPLS PacketAnalyzer::register_packet_analyzer(PacketAnalyzer::ANALYZER_ETHERNET, 0x88E7, PacketAnalyzer::ANALYZER_PBB); # PBB PacketAnalyzer::register_packet_analyzer(PacketAnalyzer::ANALYZER_ETHERNET, 0x0800, PacketAnalyzer::ANALYZER_IP); # IPv4 PacketAnalyzer::register_packet_analyzer(PacketAnalyzer::ANALYZER_ETHERNET, 0x86DD, PacketAnalyzer::ANALYZER_IP); # IPv6 PacketAnalyzer::register_packet_analyzer(PacketAnalyzer::ANALYZER_ETHERNET, 0x0806, PacketAnalyzer::ANALYZER_ARP); # ARP PacketAnalyzer::register_packet_analyzer(PacketAnalyzer::ANALYZER_ETHERNET, 0x8035, PacketAnalyzer::ANALYZER_ARP); # RARP PacketAnalyzer::register_packet_analyzer(PacketAnalyzer::ANALYZER_ETHERNET, 0x8100, PacketAnalyzer::ANALYZER_VLAN); # 802.1Q PacketAnalyzer::register_packet_analyzer(PacketAnalyzer::ANALYZER_ETHERNET, 0x88A8, PacketAnalyzer::ANALYZER_VLAN); # 802.1ad PacketAnalyzer::register_packet_analyzer(PacketAnalyzer::ANALYZER_ETHERNET, 0x9100, PacketAnalyzer::ANALYZER_VLAN); # 802.1Q 旧值 PacketAnalyzer::register_packet_analyzer(PacketAnalyzer::ANALYZER_ETHERNET, 0x8864, PacketAnalyzer::ANALYZER_PPPOE); PacketAnalyzer::register_packet_analyzer(PacketAnalyzer::ANALYZER_ETHERNET, 0x8926, PacketAnalyzer::ANALYZER_VNTAG);类似地scripts/base/packet-protocols/ip/main.zeek 挂载 IP 层到隧道/传输层的映射IPPROTO_IPIP→IPTunnel、IPPROTO_GRE→GRE、IPPROTO_TCP→TCP、IPPROTO_UDP→UDP 等scripts/base/packet-protocols/geneve/main.zeek 挂载 Geneve 的协议类型映射0x6558→Ethernet 透明以太网、0x0800→IP、0x86DD→IP、0x0806→ARP。6.2 按名注册与协议探测try_register_packet_analyzer_by_name(parent: string, identifier: count, child: string): bool与register_packet_analyzer等价但接收分析器名字符串而非 Tag 枚举名字无法解析到已知分析器时静默失败并返回falsepacket_analysis.bifregister_protocol_detection(parent: PacketAnalyzer::Tag, child: PacketAnalyzer::Tag): bool注册协议探测子分析器。当 identifier 查表失败时由父分析器调用child的DetectProtocol()进行模式/字节匹配判定基类默认返回false见 Analyzer.h。这正对应参考文档 3.3 节提到的DPD payload 签名启用方式——bad_arp等默认不激活的事件分析器可通过register_protocol_detection或注册端口来激活。6.3 启停控制与调试PacketAnalyzer::__disable_analyzer(id: PacketAnalyzer::Tag): bool与PacketAnalyzer::__enable_analyzer(id: PacketAnalyzer::Tag): bool脚本层控制某分析器是否参与报文处理C 侧分别落到Manager::DisableAnalyzer()/EnableAnalyzer()Manager.cc注意它们操作的是Component的 enabled 标志而Analyzer::IsEnabled()在 Analyzer.h 反映该状态packet_mgrzeek::packet_analysis::Manager*在初始化后依次完成实例化全部组件 → 逐一Initialize()→ 取Root分析器 → 读取UnknownProtocol::*采样配置见 Manager.cc调试手段Manager::DumpDebug()在zeek_init()事件之后把全部已注册分析器及其Dispatcher内容输出到analyzer调试流DEBUG 构建下可用-B analyzer开启。6.4 未知协议上报当某分析器在ForwardPacket()中遇到无法转发的协议标识时走Manager::ReportUnknownProtocol()Manager.cc它会以分析器名 协议号为键做采样限速UnknownProtocol::sampling_rate/sampling_threshold/sampling_duration/first_bytes_count均从脚本变量读取并携带BuildAnalyzerHistory()生成的分析器栈历史触发unknown_protocol事件。分析器栈由TrackAnalyzer()在转发过程中逐层压栈、ProcessPacket()开始时清空见 Manager.h因此unknown_protocol事件能给出包经过了哪些分析器的完整路径。7. 实战如何编写一个隧道事件处理器结合参考文档的事件签名与测试仓库testing/btest 下有大量可直接对照的用例一个标准的用法是加载基础框架 → 订阅事件 → 打印/告警。以 Geneve 为例testing/btest/core/tunnels/geneve.zeek# TEST-EXEC: zeek -b -r $TRACES/tunnels/geneve.pcap %INPUT out # TEST-EXEC: btest-diff out # TEST-EXEC: btest-diff conn.log # TEST-EXEC: btest-diff tunnel.log load base/frameworks/tunnels load base/protocols/conn event geneve_packet(c: connection, inner: pkt_hdr, vni: count) { print geneve_packet, c$id, inner, vni; }实操要点按需加载框架订阅隧道事件前通常需要load base/frameworks/tunnels并配合load base/protocols/conn才能获得完整的connection上下文认清按包触发事件的成本geneve_packet、vxlan_packet、teredo_*、gtpv1_g_pdu_packet全部按包触发文档与源码都明确标注实时分析下开销显著——生产环境应避免在其中做重逻辑优先聚合或抽样参数类型严格对应outer是connection而非pkt_hdr隧道连接对象inner是pkt_hdr内层包头vni是count——写处理器时按表对照即可无需自行猜测字段类型内层再分发Geneve/VXLAN 的inner是Ethernet 头 传输层头的复合pkt_hdr可继续交给tunnels框架生成tunnel.log测试中btest-diff tunnel.log即验证这一点无需在事件处理器里手工解包验证素材仓库自带 testing/btest/Traces/tunnels/geneve.pcap、geneve-arp.pcap、geneve-ipv6.pcap、geneve-many-options.pcap 等样本与配套.zeek测试可直接zeek -r复现验证。8. 速查表事件/函数 → 定义位置参考文档每条符号都带:source-code:指向本文汇总为一张符号 → 仓库实现速查表便于按图索骥符号定义位置arp_request/arp_reply/bad_arpsrc/packet_analysis/protocol/arp/events.bifC 触发逻辑见 ARP.ccgeneve_packetsrc/packet_analysis/protocol/geneve/events.bifPacketAnalyzer::Geneve::get_optionssrc/packet_analysis/protocol/geneve/functions.bifnew_gtpv1_statescripts/base/packet-protocols/gtpv1/main.zeekgtpv1_message及 6 个 PDP Context 事件src/packet_analysis/protocol/gtpv1/events.bifPacketAnalyzer::GTPV1::remove_gtpv1_connectionsrc/packet_analysis/protocol/gtpv1/functions.bifIGMP::message/IGMP::membership_queryscripts/base/packet-protocols/igmp/spicy-events.zeekIGMP::membership_report_*/IGMP::leave_groupscripts/policy/protocols/conn/multicast-participants.zeekPacketAnalyzer::PPPoE::session_idsrc/packet_analysis/protocol/pppoe/functions.bifteredo_packet/teredo_authentication/teredo_origin_indication/teredo_bubblesrc/packet_analysis/protocol/teredo/events.bifnew_teredo_statescripts/base/packet-protocols/teredo/main.zeekPacketAnalyzer::TEREDO::remove_teredo_connectionsrc/packet_analysis/protocol/teredo/functions.bifvxlan_packetsrc/packet_analysis/protocol/vxlan/events.bifregister_packet_analyzer等 5 个 BIFsrc/packet_analysis/packet_analysis.bif各分析器的默认挂载映射scripts/base/packet-protocols 下各main.zeek处理入口与未知协议上报src/packet_analysis/Manager.cc9. 结语本文以参考文档 autogenerated-packet-analyzer-index.rst 为主线把PacketAnalyzer::Tag的 35 个标识、ARP/GTPv1/Geneve/VXLAN/Teredo/IGMP 的事件与函数签名、以及BIF 注册 → Dispatcher 查表 → 逐层转发 → 事件上抛的实现链路完整串了起来。需要再次强调的是该文档是 zeekygen 自动生成的索引型参考——它不承诺默认激活每个事件如bad_arp的 TODO 说明也不保证事件一定由分析器目录下的代码定义如 IGMP 的四个成员事件来自 policy 脚本。因此在基于这些 API 开发时最可靠的做法是以本文速查表定位定义源文件再对照 scripts/base/packet-protocols 的注册脚本确认该分析器在当前配置下确实被挂载最后用 testing/btest 中的样本抓包做实测验证。赞分享网络安全网络IDS【免费下载链接】zeekZeek is a powerful network analysis framework that is much different from the typical IDS you may know.项目地址https://gitcode.com/gh_mirrors/ze/zeek点击查看免费下载相关推荐Zeek 协议分析器脚本接口全索引Analyzer::Tag、插件组件与事件函数详解Zeek 协议分析器脚本接口全索引Analyzer::Tag、插件组件与事件函数详解 本篇技术指南以 Zeek 官方自动生成的协议分析器索引 autogen网络安全网络IDSZeek 文件分析器File Analyzers完全指南Files::Tag 枚举、内置插件事件与函数参考Zeek 文件分析器File Analyzers完全指南Files::Tag 枚举、内置插件事件与函数参考 导读 本文基于 Zeek 官方脚本参考文档 d网络安全网络IDSZeek Packet Analyzer BIF 函数全解析注册、检测、启停与校验和忽略机制Zeek Packet Analyzer BIF 函数全解析注册、检测、启停与校验和忽略机制 本篇技术指南以 Zeek 官方 API 参考文档 base/bi网络安全网络IDS上一篇.NET runtime CoreCLR WebAssembly 构建与调试指南从 emscripten 编译到 Node.js/浏览器运行下一篇CANN/ge CountBatch批处理功能创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Zeek 报文分析器（Packet Analyzer）全量参考：Tag 索引、事件函数与源码实现解析
网络安全网络IDS【免费下载链接】zeekZeek is a powerful network analysis framework that is much different from the typical IDS you may know.项目地址https://gitcode.com/gh_mirrors/ze/zeek点击查看免费下载本文以仓库中自动生成的 autogenerated-packet-analyzer-index.rst 为骨架系统梳理 Zeek 内置的全部报文分析器packet analyzer从PacketAnalyzer::Tag枚举的 35 个分析器标识到每个分析器对外暴露的 Zeek 事件与函数签名、参数语义与触发条件并对照 src/packet_analysis 下的 C 实现与 scripts/base/packet-protocols 下的注册脚本讲清分析器如何被挂载、如何逐层转发、事件何时触发的完整链路。读完本文你将能读懂任意packet_analysis相关脚本掌握编写 ARP、GTPv1、Geneve、Teredo、VXLAN 等事件处理器的准确姿势并具备在源码层面定位分析器行为的能力。1. 背景Zeek 的报文分析器框架是什么Zeek 在传统协议分析器面向会话/连接如 HTTP、DNS 的Analyzer之外维护着一套独立的报文级packet-level分析器体系即packet_analysis框架。它逐包处理抓取到的原始帧负责解析链路层头Ethernet、VLAN、Linux SLL、IEEE 802.11 等识别并解封装隧道协议GRE、GTPv1、Geneve、VXLAN、Teredo、AYIYA、IPTunnel 等解析网络层与传输层IP、TCP、UDP、ICMP、IGMP并把数据交给会话层分析器继续处理。框架的核心类全部位于 src/packet_analysisManager分析器总管理器持有全部已注册分析器实例std::mapstd::string, AnalyzerPtr analyzers负责实例化、启停、ProcessPacket()入口调度与未知协议上报Analyzer所有报文分析器的抽象基类核心虚函数是AnalyzePacket()转发用ForwardPacket()协议探测用DetectProtocol()Dispatcher维护协议标识identifier→ 子分析器的映射表供父分析器按头字段查表转发Component以插件组件形式把每个分析器注册进Manager。处理流程见 Manager.cc 的ProcessPacket()每收到一个包Manager先清理分析器栈analyzer_stack.clear()然后把整包从Root分析器开始沿链路层类型标识逐层向下转发——这正是下文所有事件与函数赖以触发的执行环境。2.PacketAnalyzer::Tag35 个内置分析器标识总览文档第一部分定义了PacketAnalyzer::Tag枚举是脚本层引用分析器的唯一入口。下表按功能分组列出全部枚举值对应源码目录为 src/packet_analysis/protocol分类Tag 枚举说明实现目录链路层ANALYZER_ETHERNETEthernet 帧protocol/ethernet链路层ANALYZER_VLANVLAN802.1Qprotocol/vlan链路层ANALYZER_VNTAGCisco VN-Tagprotocol/vntag链路层ANALYZER_LLC逻辑链路控制protocol/llc链路层ANALYZER_SNAPSNAP 封装protocol/snap链路层ANALYZER_NOVELL_802_3Novell 802.3 变体protocol/novell_802_3链路层ANALYZER_PPP/ANALYZER_PPPSERIALPPP / 串行 PPPprotocol/ppp、protocol/ppp_serial链路层ANALYZER_PPPOEPPPoEprotocol/pppoe链路层ANALYZER_FDDIFDDIprotocol/fddi链路层ANALYZER_LINUXSLL/ANALYZER_LINUXSLL2Linux cooked capture v1/v2protocol/linux_sll、protocol/linux_sll2链路层ANALYZER_IEEE802_11/ANALYZER_IEEE802_11_RADIO802.11 / Radiotapprotocol/ieee802_11、protocol/ieee802_11_radio链路层ANALYZER_NFLOGnetfilter logprotocol/nflog链路层ANALYZER_NULLBSD nullDLT_NULLprotocol/null地址解析ANALYZER_ARPARP事件最丰富之一protocol/arp网络层ANALYZER_IPIPv4/IPv6 统一入口protocol/ip网络层ANALYZER_TCP/ANALYZER_UDP传输层会话适配protocol/tcp、protocol/udp网络层ANALYZER_ICMP/ANALYZER_IGMPICMP / IGMPprotocol/icmp、protocol/igmp网络层ANALYZER_UNKNOWN_IP_TRANSPORT未知 IP 传输层protocol/unknown_ip_transport隧道ANALYZER_GREGRE 隧道protocol/gre隧道ANALYZER_GTPV1GTPv1事件最丰富之一protocol/gtpv1隧道ANALYZER_GENEVEGeneve 隧道protocol/geneve隧道ANALYZER_VXLANVXLAN 隧道protocol/vxlan隧道ANALYZER_TEREDOTeredoIPv6 过渡protocol/teredo隧道ANALYZER_AYIYAAYIYA 隧道protocol/ayiya隧道ANALYZER_IPTUNNELIP-in-IPprotocol/iptunnel隧道ANALYZER_MPLS/ANALYZER_PBBMPLS / PBBprotocol/mpls、protocol/pbb系统ANALYZER_ROOT根分析器入口占位protocol/root系统ANALYZER_SKIP跳过分析protocol/skip注意ANALYZER_ICMP、ANALYZER_TCP、ANALYZER_UDP、ANALYZER_UNKNOWN_IP_TRANSPORT四个 Tag 出现在枚举中但该参考文档没有为它们单列插件小节——它们主要作为 IP 层向传输层转发、以及后续会话分析器的接驳点存在参见 scripts/base/packet-protocols/ip/main.zeek 中IPPROTO_TCP/IPPROTO_UDP/IPPROTO_ICMP的注册。Root分析器值得单独说明在 Root.cc 中它的AnalyzePacket()直接触发InternalError因为 Root 只作为Manager::ProcessPacket()的转发起点root_analyzer-ForwardPacket(...)真正的逻辑由Dispatcher按packet-link_type查表交给对应链路层分析器。3. ARP 分析器arp_request/arp_reply/bad_arpARP 是本参考文档中第一个、也是事件语义最完整的分析器对应源码目录 src/packet_analysis/protocol/arp。3.1 三个事件的签名与参数arp_request与arp_reply签名完全一致差异仅在触发场景为 ARP 请求或应答event arp_request(mac_src: string, mac_dst: string, SPA: addr, SHA: string, TPA: addr, THA: string); event arp_reply(mac_src: string, mac_dst: string, SPA: addr, SHA: string, TPA: addr, THA: string);参数类型含义mac_srcstring帧的源 MAC 地址mac_dststring帧的目的 MAC 地址SPAaddrSender Protocol Address发送方协议地址IPv4SHAstringSender Hardware Address发送方硬件地址形如aa:bb:cc:dd:ee:ffTPAaddrTarget Protocol Address目标协议地址THAstringTarget Hardware Address目标硬件地址bad_arp针对 Zeek 无法合理解释的 ARP 包event bad_arp(SPA: addr, SHA: string, TPA: addr, THA: string, explanation: string);除与上面相同的四个地址参数外多出的explanation: string是对为什么该包被判定为 bad的简短文字说明。3.2 触发语义与源码实现从 ARP.cc 可还原完整的判定链路这些判定直接决定了上述事件何时触发头完整性检查sizeof(struct arp_pkthdr) len时记truncated_ARPweird硬件类型检查仅接受ARPHRD_ETHER1与ARPHRD_IEEE8026且要求ar_hln 6以太网地址长度否则触发bad_arpunknown-arp-hw-address/corrupt-arp-header协议类型检查仅支持ETHERTYPE_IP0x0800且ar_pln 4IPv4不支持 IPv6 地址源码注释明确We dont support IPv6 addresses一致性校验帧的 L2 源地址必须等于 ARP 发送方硬件地址ar_sha否则触发bad_arpweird-arp-shaopcode 分派ARPOP_REQUEST1→arp_requestARPOP_REPLY2→arp_replyRARP/InARP 等未实现 opcode 与未知 opcode 均触发bad_arpunimplemented-arp-opcode/invalid-arp-opcode。也就是说只要 MAC 地址格式/长度非法、协议地址非 IPv4、或发送方地址与帧源地址不符Zeek 就会通过bad_arp事件报告并附上原因字符串。这也是 events.bif 中该事件文档标注非标准硬件地址格式或硬件地址与报文发起者不匹配的落地实现。3.3 关于bad_arp的启用限制文档 TODO 的实锤参考文档在bad_arp条目下附了一条todoZeek 当前默认配置并不激活产生该事件的协议分析器——对应的脚本尚未移植完成若想启用需要为它注册端口或添加 DPD动态协议检测payload 签名。这一点在 src/packet_analysis/protocol/arp/events.bif 中同样存在编写依赖bad_arp的脚本前务必知晓默认安装下该事件不会触发。4. 隧道类分析器的事件与函数详解隧道分析器是报文分析器最有价值的应用场景它们负责剥离外层头、解出内层包并同时把隧道本身的信息以事件形式暴露给脚本层。参考文档中隧道相关的事件/函数如下。4.1 Genevegeneve_packet与PacketAnalyzer::Geneve::get_options事件签名event geneve_packet(outer: connection, inner: pkt_hdr, vni: count);参数类型含义outerconnectionGeneve 隧道外层连接innerpkt_hdr内层 Ethernet 帧头与传输层头vnicountGeneve Network IdentifierVNI文档明确标注RFC 8926 定义的协议该事件按包触发实时分析时处理它可能特别昂贵同款标注还出现在 VXLAN、Teredo、GTPv1 G-PDU 事件上。测试用例 testing/btest/core/tunnels/geneve.zeek 展示了标准用法——配合load base/frameworks/tunnels与load base/protocols/conn在事件里打印c$id、inner与vni对应抓包样本在 testing/btest/Traces/tunnels/geneve.pcap。配套函数BIF定义于 src/packet_analysis/protocol/geneve/functions.biffunction PacketAnalyzer::Geneve::get_options(): geneve_options_vec_vec;返回当前包所有层级的 Geneve options外层 vector 的最后一个条目是最内层Geneve 头的 options返回类型是PacketAnalyzer::Geneve::Optionrecord 的 vector 的 vectorgeneve_options_vec_vec。测试 testing/btest/core/tunnels/geneve-get-options.zeek 与样本 testing/btest/Traces/tunnels/geneve-many-options.pcap 可用于验证多 options 场景下的取值顺序。4.2 VXLANvxlan_packetevent vxlan_packet(outer: connection, inner: pkt_hdr, vni: count);参数语义与geneve_packet完全同构RFC 7348outer为 VXLAN 隧道外层连接inner为 VXLAN 封装的 Ethernet 头与传输层头vni为 VXLAN Network Identifier。同样按包触发、实时分析成本高。4.3 Teredo四个事件与一个函数Teredo 是 IPv6-over-UDP 过渡隧道RFC 4380参考文档为它列出 4 个事件全部按包触发event teredo_packet(outer: connection, inner: teredo_hdr); # 任意 Teredo 隧道内的 IPv6 包 event teredo_authentication(outer: connection, inner: teredo_hdr); # 使用 Teredo authentication 封装方式 event teredo_origin_indication(outer: connection, inner: teredo_hdr); # 使用 origin indication 封装方式 event teredo_bubble(outer: connection, inner: teredo_hdr); # Bubble 包Next Header 为 IPPROTO_NONEouterTeredo 隧道外层连接innerTeredo 封装的 IPv6 包头与传输层头teredo_bubble的判定依据内层 IPv6 包 Next Header 值为IPPROTO_NONE即 Teredo bubble四个事件彼此以zeek:see交叉引用方便按需求组合使用。另有与 GTPv1 同构的状态清理函数function PacketAnalyzer::TEREDO::remove_teredo_connection(cid: conn_id): bool;它配合new_teredo_state事件定义于 scripts/base/packet-protocols/teredo/main.zeek使用该事件在每连接 Teredo 状态创建时触发主要用于安装连接移除钩子以清理内部 per-connection Teredo 状态——remove_teredo_connection即该清理动作的脚本层入口。4.4 GTPv1控制面信令事件全集GTPv1 分析器目录 src/packet_analysis/protocol/gtpv1解析器由 gtpv1.pac 等 binpac 文件生成除通用事件外还针对 GTPv1-C 控制面消息提供成套事件event new_gtpv1_state(c: connection); event gtpv1_message(c: connection, hdr: gtpv1_hdr); event gtpv1_g_pdu_packet(outer: connection, inner_gtp: gtpv1_hdr, inner_ip: pkt_hdr); event gtpv1_create_pdp_ctx_request(c: connection, hdr: gtpv1_hdr, elements: gtp_create_pdp_ctx_request_elements); event gtpv1_create_pdp_ctx_response(c: connection, hdr: gtpv1_hdr, elements: gtp_create_pdp_ctx_response_elements); event gtpv1_update_pdp_ctx_request(c: connection, hdr: gtpv1_hdr, elements: gtp_update_pdp_ctx_request_elements); event gtpv1_update_pdp_ctx_response(c: connection, hdr: gtpv1_hdr, elements: gtp_update_pdp_ctx_response_elements); event gtpv1_delete_pdp_ctx_request(c: connection, hdr: gtpv1_hdr, elements: gtp_delete_pdp_ctx_request_elements); event gtpv1_delete_pdp_ctx_response(c: connection, hdr: gtpv1_hdr, elements: gtp_delete_pdp_ctx_response_elements);语义要点new_gtpv1_statescripts/base/packet-protocols/gtpv1/main.zeek新 GTP 分析器为某连接实例化时触发用途与new_teredo_state一致——安装连接移除钩子以清理 per-connection GTPv1 内部状态gtpv1_message任何带 GTPv1 头的 GTP 消息都会触发是通用入口gtpv1_g_pdu_packet按包触发的 G-PDU 事件UDP 载荷为 GTP 头 IPv4/IPv6 包实时处理成本高inner_gtp为 GTP 头inner_ip为内层 IP 与传输层头六个 PDP Context 事件一一对应 Create/Update/Delete 的 Request/Response 六种控制面消息elements为构成消息的 Information Elements 集合类型随消息不同而不同gtp_*_pdp_ctx_*_elements各具专属 record 类型。配套函数与 Teredo 同构function PacketAnalyzer::GTPV1::remove_gtpv1_connection(cid: conn_id): bool;4.5 AYIYA / GRE / IPTunnel / MPLS / PBB仅组件注册AYIYA、GRE、IPTunnel、MPLS、PBB 五个隧道分析器在参考文档中没有事件/函数小节属于纯转发型分析器。它们的职责全部体现在注册脚本中例如 scripts/base/packet-protocols/ayiya/main.zeek 把 AYIYA 的 IPv4/IPv6 载荷直接交给ANALYZER_IPevent zeek_init() { PacketAnalyzer::register_packet_analyzer(PacketAnalyzer::ANALYZER_AYIYA, IPPROTO_IPV4, PacketAnalyzer::ANALYZER_IP); PacketAnalyzer::register_packet_analyzer(PacketAnalyzer::ANALYZER_AYIYA, IPPROTO_IPV6, PacketAnalyzer::ANALYZER_IP); }4.6 其余隧道/链路层分析器小结PPPoE 提供唯一的会话函数function PacketAnalyzer::PPPoE::session_id(): count;返回当前包的 PPPoE Session ID若不存在则返回0xFFFFFFFF超出合法 Session ID 范围作为哨兵值。IP、VLAN、LinuxSLL、IEEE 802.11、LLC、SNAP、NFLog、FDDI、Null、Skip、PPPSerial、NOVELL_802_3 等分析器在参考文档中均只有组件条目对应各自的ANALYZER_*枚举事件与函数由其他协议模块如 conn 框架间接消费因此不在此参考页重复列出。5. IGMP 分析器成员关系事件IGMP 分析器由 Spicy 实现src/packet_analysis/protocol/igmp/igmp.spicy 与 igmp.evt脚本层类型定义在 scripts/base/packet-protocols/igmp/types.zeek事件定义在 scripts/base/packet-protocols/igmp/spicy-events.zeek。event IGMP::message(packet: raw_pkt_hdr, msg_type: IGMP::MessageType); # 每个被处理的 IGMP 消息 event IGMP::membership_query(source: addr, group_addr: addr); # 每个 Membership Query event IGMP::membership_report_v1(source: addr, group_addr: addr); # IGMPv1 Membership Report event IGMP::membership_report_v2(source: addr, group_addr: addr); # IGMPv2 Membership Report event IGMP::membership_report_v3(source: addr, groups: vector of IGMP::Group); # IGMPv3 Membership Report event IGMP::leave_group(source: addr, group_addr: addr); # IGMPv2 Leave Group参数语义IGMP::message全量入口packet为原始包头raw_pkt_hdrmsg_type为IGMP::MessageType枚举membership_query/membership_report_v1/v2/leave_groupsource为源地址group_addr为组播组地址membership_report_v3IGMPv3 支持多组记录故第二个参数是vector of IGMP::Group。值得注意的细节membership_report_v1、membership_report_v2、membership_report_v3、leave_group四个事件的源码定位并不在 IGMP 分析器目录而在策略脚本 scripts/policy/protocols/conn/multicast-participants.zeek——它们由 policy 层在底层事件之上派生而来用于维护组播参与者视图。这印证了参考文档作为自动生成索引的本质事件可能来自bif、Spicy EVT 或纯 Zeek 脚本三个来源参考文档的:source-code:指令即记录每个符号的定义位置。6. 理解组件注册 事件分派的完整链路参考文档列出的是结果理解其生成机制能帮你更准确地使用这些 API。核心机制落在两个文件BIF 层 src/packet_analysis/packet_analysis.bif 与脚本注册层 scripts/base/packet-protocols。6.1 脚本层挂载register_packet_analyzerBIF 函数packet_analysis.bif在 C 侧调用parent_analyzer-RegisterProtocol(identifier, child)把标识 → 子分析器写入父分析器的Dispatcherfunction register_packet_analyzer(parent: PacketAnalyzer::Tag, identifier: count, child: PacketAnalyzer::Tag): bool;各内置模块在zeek_init中完成挂载例如 scripts/base/packet-protocols/ethernet/main.zeek 的完整映射表EtherType → 分析器PacketAnalyzer::register_packet_analyzer(PacketAnalyzer::ANALYZER_ETHERNET, 0x8847, PacketAnalyzer::ANALYZER_MPLS); # MPLS PacketAnalyzer::register_packet_analyzer(PacketAnalyzer::ANALYZER_ETHERNET, 0x88E7, PacketAnalyzer::ANALYZER_PBB); # PBB PacketAnalyzer::register_packet_analyzer(PacketAnalyzer::ANALYZER_ETHERNET, 0x0800, PacketAnalyzer::ANALYZER_IP); # IPv4 PacketAnalyzer::register_packet_analyzer(PacketAnalyzer::ANALYZER_ETHERNET, 0x86DD, PacketAnalyzer::ANALYZER_IP); # IPv6 PacketAnalyzer::register_packet_analyzer(PacketAnalyzer::ANALYZER_ETHERNET, 0x0806, PacketAnalyzer::ANALYZER_ARP); # ARP PacketAnalyzer::register_packet_analyzer(PacketAnalyzer::ANALYZER_ETHERNET, 0x8035, PacketAnalyzer::ANALYZER_ARP); # RARP PacketAnalyzer::register_packet_analyzer(PacketAnalyzer::ANALYZER_ETHERNET, 0x8100, PacketAnalyzer::ANALYZER_VLAN); # 802.1Q PacketAnalyzer::register_packet_analyzer(PacketAnalyzer::ANALYZER_ETHERNET, 0x88A8, PacketAnalyzer::ANALYZER_VLAN); # 802.1ad PacketAnalyzer::register_packet_analyzer(PacketAnalyzer::ANALYZER_ETHERNET, 0x9100, PacketAnalyzer::ANALYZER_VLAN); # 802.1Q 旧值 PacketAnalyzer::register_packet_analyzer(PacketAnalyzer::ANALYZER_ETHERNET, 0x8864, PacketAnalyzer::ANALYZER_PPPOE); PacketAnalyzer::register_packet_analyzer(PacketAnalyzer::ANALYZER_ETHERNET, 0x8926, PacketAnalyzer::ANALYZER_VNTAG);类似地scripts/base/packet-protocols/ip/main.zeek 挂载 IP 层到隧道/传输层的映射IPPROTO_IPIP→IPTunnel、IPPROTO_GRE→GRE、IPPROTO_TCP→TCP、IPPROTO_UDP→UDP 等scripts/base/packet-protocols/geneve/main.zeek 挂载 Geneve 的协议类型映射0x6558→Ethernet 透明以太网、0x0800→IP、0x86DD→IP、0x0806→ARP。6.2 按名注册与协议探测try_register_packet_analyzer_by_name(parent: string, identifier: count, child: string): bool与register_packet_analyzer等价但接收分析器名字符串而非 Tag 枚举名字无法解析到已知分析器时静默失败并返回falsepacket_analysis.bifregister_protocol_detection(parent: PacketAnalyzer::Tag, child: PacketAnalyzer::Tag): bool注册协议探测子分析器。当 identifier 查表失败时由父分析器调用child的DetectProtocol()进行模式/字节匹配判定基类默认返回false见 Analyzer.h。这正对应参考文档 3.3 节提到的DPD payload 签名启用方式——bad_arp等默认不激活的事件分析器可通过register_protocol_detection或注册端口来激活。6.3 启停控制与调试PacketAnalyzer::__disable_analyzer(id: PacketAnalyzer::Tag): bool与PacketAnalyzer::__enable_analyzer(id: PacketAnalyzer::Tag): bool脚本层控制某分析器是否参与报文处理C 侧分别落到Manager::DisableAnalyzer()/EnableAnalyzer()Manager.cc注意它们操作的是Component的 enabled 标志而Analyzer::IsEnabled()在 Analyzer.h 反映该状态packet_mgrzeek::packet_analysis::Manager*在初始化后依次完成实例化全部组件 → 逐一Initialize()→ 取Root分析器 → 读取UnknownProtocol::*采样配置见 Manager.cc调试手段Manager::DumpDebug()在zeek_init()事件之后把全部已注册分析器及其Dispatcher内容输出到analyzer调试流DEBUG 构建下可用-B analyzer开启。6.4 未知协议上报当某分析器在ForwardPacket()中遇到无法转发的协议标识时走Manager::ReportUnknownProtocol()Manager.cc它会以分析器名 协议号为键做采样限速UnknownProtocol::sampling_rate/sampling_threshold/sampling_duration/first_bytes_count均从脚本变量读取并携带BuildAnalyzerHistory()生成的分析器栈历史触发unknown_protocol事件。分析器栈由TrackAnalyzer()在转发过程中逐层压栈、ProcessPacket()开始时清空见 Manager.h因此unknown_protocol事件能给出包经过了哪些分析器的完整路径。7. 实战如何编写一个隧道事件处理器结合参考文档的事件签名与测试仓库testing/btest 下有大量可直接对照的用例一个标准的用法是加载基础框架 → 订阅事件 → 打印/告警。以 Geneve 为例testing/btest/core/tunnels/geneve.zeek# TEST-EXEC: zeek -b -r $TRACES/tunnels/geneve.pcap %INPUT out # TEST-EXEC: btest-diff out # TEST-EXEC: btest-diff conn.log # TEST-EXEC: btest-diff tunnel.log load base/frameworks/tunnels load base/protocols/conn event geneve_packet(c: connection, inner: pkt_hdr, vni: count) { print geneve_packet, c$id, inner, vni; }实操要点按需加载框架订阅隧道事件前通常需要load base/frameworks/tunnels并配合load base/protocols/conn才能获得完整的connection上下文认清按包触发事件的成本geneve_packet、vxlan_packet、teredo_*、gtpv1_g_pdu_packet全部按包触发文档与源码都明确标注实时分析下开销显著——生产环境应避免在其中做重逻辑优先聚合或抽样参数类型严格对应outer是connection而非pkt_hdr隧道连接对象inner是pkt_hdr内层包头vni是count——写处理器时按表对照即可无需自行猜测字段类型内层再分发Geneve/VXLAN 的inner是Ethernet 头 传输层头的复合pkt_hdr可继续交给tunnels框架生成tunnel.log测试中btest-diff tunnel.log即验证这一点无需在事件处理器里手工解包验证素材仓库自带 testing/btest/Traces/tunnels/geneve.pcap、geneve-arp.pcap、geneve-ipv6.pcap、geneve-many-options.pcap 等样本与配套.zeek测试可直接zeek -r复现验证。8. 速查表事件/函数 → 定义位置参考文档每条符号都带:source-code:指向本文汇总为一张符号 → 仓库实现速查表便于按图索骥符号定义位置arp_request/arp_reply/bad_arpsrc/packet_analysis/protocol/arp/events.bifC 触发逻辑见 ARP.ccgeneve_packetsrc/packet_analysis/protocol/geneve/events.bifPacketAnalyzer::Geneve::get_optionssrc/packet_analysis/protocol/geneve/functions.bifnew_gtpv1_statescripts/base/packet-protocols/gtpv1/main.zeekgtpv1_message及 6 个 PDP Context 事件src/packet_analysis/protocol/gtpv1/events.bifPacketAnalyzer::GTPV1::remove_gtpv1_connectionsrc/packet_analysis/protocol/gtpv1/functions.bifIGMP::message/IGMP::membership_queryscripts/base/packet-protocols/igmp/spicy-events.zeekIGMP::membership_report_*/IGMP::leave_groupscripts/policy/protocols/conn/multicast-participants.zeekPacketAnalyzer::PPPoE::session_idsrc/packet_analysis/protocol/pppoe/functions.bifteredo_packet/teredo_authentication/teredo_origin_indication/teredo_bubblesrc/packet_analysis/protocol/teredo/events.bifnew_teredo_statescripts/base/packet-protocols/teredo/main.zeekPacketAnalyzer::TEREDO::remove_teredo_connectionsrc/packet_analysis/protocol/teredo/functions.bifvxlan_packetsrc/packet_analysis/protocol/vxlan/events.bifregister_packet_analyzer等 5 个 BIFsrc/packet_analysis/packet_analysis.bif各分析器的默认挂载映射scripts/base/packet-protocols 下各main.zeek处理入口与未知协议上报src/packet_analysis/Manager.cc9. 结语本文以参考文档 autogenerated-packet-analyzer-index.rst 为主线把PacketAnalyzer::Tag的 35 个标识、ARP/GTPv1/Geneve/VXLAN/Teredo/IGMP 的事件与函数签名、以及BIF 注册 → Dispatcher 查表 → 逐层转发 → 事件上抛的实现链路完整串了起来。需要再次强调的是该文档是 zeekygen 自动生成的索引型参考——它不承诺默认激活每个事件如bad_arp的 TODO 说明也不保证事件一定由分析器目录下的代码定义如 IGMP 的四个成员事件来自 policy 脚本。因此在基于这些 API 开发时最可靠的做法是以本文速查表定位定义源文件再对照 scripts/base/packet-protocols 的注册脚本确认该分析器在当前配置下确实被挂载最后用 testing/btest 中的样本抓包做实测验证。赞分享网络安全网络IDS【免费下载链接】zeekZeek is a powerful network analysis framework that is much different from the typical IDS you may know.项目地址https://gitcode.com/gh_mirrors/ze/zeek点击查看免费下载相关推荐Zeek 协议分析器脚本接口全索引Analyzer::Tag、插件组件与事件函数详解Zeek 协议分析器脚本接口全索引Analyzer::Tag、插件组件与事件函数详解 本篇技术指南以 Zeek 官方自动生成的协议分析器索引 autogen网络安全网络IDSZeek 文件分析器File Analyzers完全指南Files::Tag 枚举、内置插件事件与函数参考Zeek 文件分析器File Analyzers完全指南Files::Tag 枚举、内置插件事件与函数参考 导读 本文基于 Zeek 官方脚本参考文档 d网络安全网络IDSZeek Packet Analyzer BIF 函数全解析注册、检测、启停与校验和忽略机制Zeek Packet Analyzer BIF 函数全解析注册、检测、启停与校验和忽略机制 本篇技术指南以 Zeek 官方 API 参考文档 base/bi网络安全网络IDS上一篇.NET runtime CoreCLR WebAssembly 构建与调试指南从 emscripten 编译到 Node.js/浏览器运行下一篇CANN/ge CountBatch批处理功能创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考