网络安全网络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 仓库中的 base/protocols/irc/files.zeek 脚本及其 Zeekygen 参考文档doc/scripts/base/protocols/irc/files.zeek.rst为核心系统讲解 Zeek 如何为 IRC 协议接入 Files 文件分析框架从记录扩展、文件句柄fuid生成、协议注册到 DCC 传输中文件名与 MIME 类型的自动补全再到集群环境下的注意事项。读完本文你将理解 IRC 会话日志irc.log中fuid字段的来源与含义掌握IRC::get_file_handle的自定义方式并能借助 Files 框架对 IRC 传输的文件做溯源与深度分析。一、背景IRC 分析器与文件分析框架的衔接点Zeek 的 IRC 支持由module IRC承载核心会话脚本位于 scripts/base/protocols/irc/main.zeek它定义了IRC::Info记录含ts、uid、id、nick、user、command、value、addl等字段并通过Log::create_stream(..., $pathirc)将 IRC 命令与会话信息写入irc.log同时用Analyzer::register_for_ports在默认端口 6666/6667/6668/6669/tcp 上启用 IRC 分析器。然而IRC 传输的真正“内容”往往不是命令文本而是通过 DCCDirect Client-to-Client协议传输的文件。要让 Zeek 像对待 HTTP、FTP 那样对 IRC 承载的文件进行提取、重组、MIME 嗅探和深度分析就必须让 IRC 分析器与 Files 框架对接。这正是files.zeek的职责所在它是 IRC 协议与 base/frameworks/files 框架之间的“适配层”。该脚本通过三个load指令建立依赖./dcc-sendDCC 传输预期管理、base/utils/conn-ids连接标识工具、base/frameworks/files文件框架本体。从源码结构看files.zeek本身不直接分析文件内容而是负责两件事一是为 Files 框架提供生成文件句柄的回调二是在文件事件中把 DCC 上下文文件名、MIME 类型回填到 IRC 会话记录。二、记录扩展IRC::Info.fuid与fa_file.ircfiles.zeek的export块首先对两个记录做了redef扩展这是它与 Files 框架交互的数据基础redef record Info { ## File unique ID. fuid: string log optional; }; redef record fa_file { irc: IRC::Info optional; };IRC::Info.fuidstring log optional文件唯一 IDFile Unique ID。它是 Files 框架分配给每个被跟踪文件句柄的标识符与文件分析框架产生的files.log中的fuid一一对应。正因为它带log属性irc.log的每条记录都能携带本次会话关联文件的fuid从而把 IRC 会话日志与文件分析日志files.log、文件内容日志串联起来——这是溯源“谁在 IRC 上传了什么文件”的关键字段。fa_file.ircIRC::Info optional反向挂在 Files 框架的fa_file记录上让每个被跟踪的文件都能携带其所属的 IRC 会话信息。optional表示该字段并非每个文件都存在例如非 IRC 来源的文件就没有此字段脚本中通过f?$irc这样的字段存在性判断来安全访问。这种“双向挂接”的设计体现了 Zeek 脚本常见的扩展模式在源记录上增加输出字段在框架记录上增加上下文引用二者在事件处理阶段完成拼接。三、文件句柄提供者IRC::get_file_handle文档摘要中列出的唯一函数是IRC::get_file_handle其类型签名在源码中声明并实现如下global get_file_handle: function(c: connection, is_orig: bool): string; function get_file_handle(c: connection, is_orig: bool): string { return cat(Analyzer::ANALYZER_IRC_DATA, c$start_time, c$id, is_orig); }该函数接收连接c与方向标志is_orig返回一个字符串作为文件的唯一句柄。其实现将ANALYZER_IRC_DATA分析器标签、连接开始时间、连接四元组c$id和方向拼接起来cat。从源码结构看这样生成的句柄天然具备两个特性唯一性连接标识加时间戳足以区分同一连接上不同方向、不同时间段的文件可复现性给定相同的连接与方向信息生成的句柄稳定一致便于跨日志关联。值得注意的是IRC::Info.fuid正是这个返回值。在后续file_over_new_connection事件中脚本执行irc$fuid f$id;——f$id即 Files 框架为文件分配的唯一 ID它由get_file_handle回调产生详见第五节从而把 IRC 会话记录与文件 ID 正式绑定。自定义文件句柄策略时可以用redef覆盖IRC::get_file_handle注意需保持相同签名例如在集群环境中把 worker 节点信息加入句柄以避免不同 worker 之间 fuid 冲突。四、协议注册zeek_init与Files::register_protocolfiles.zeek通过zeek_init事件优先级 5把 IRC 的 DATA 分析器注册进 Files 框架event zeek_init() priority5 { Files::register_protocol(Analyzer::ANALYZER_IRC_DATA, Files::ProtoRegistration($get_file_handle IRC::get_file_handle)); }Files::register_protocol的签名与ProtoRegistration记录定义在 scripts/base/frameworks/files/main.zeektype ProtoRegistration: record { ## A callback to generate a file handle on demand when ## one is needed by the core. get_file_handle: function(c: connection, is_orig: bool): string; ## A callback to describe a file. ... describe: function(f: fa_file): string defaultfunction(f: fa_file): string { return ; }; }; global register_protocol: function(tag: Analyzer::Tag, reg: ProtoRegistration): bool;要点解读注册以分析器标签为键ANALYZER_IRC_DATA是 IRC 数据通道即 DCC 文件传输所用连接的分析器标签每个协议只能为同一标签注册一次回调重复注册时register_protocol返回false。ProtoRegistration至少需要get_file_handle回调describe回调带默认实现返回空字符串IRC 未提供自定义描述这与 HTTP 用 URL 描述文件的策略不同——从源码看IRC 的文件描述保持默认空值。注意注册的是ANALYZER_IRC_DATA而非ANALYZER_IRC这体现了 IRC 分析器的“双连接”模型——命令通道IRC与数据通道IRC_DATA即 DCC 文件传输被区分对待只有数据通道上的流量才会被 Files 框架追踪为文件。五、Files 框架的底层回调机制理解get_file_handle何时被调用需要看 Files 框架核心脚本 scripts/base/frameworks/files/main.zeek 中的同名事件get_file_handleevent get_file_handle(tag: Analyzer::Tag, c: connection, is_orig: bool) priority5 { if ( tag !in registered_protocols ) { if ( ! missing_get_file_handle_warned[tag] ) { missing_get_file_handle_warned[tag] T; Reporter::warning(fmt(get_file_handle() handler missing for %s, tag)); } set_file_handle(fmt(%s-fallback-%s-%s-%s, tag, c$uid, is_orig, network_time())); return; } local handler registered_protocols[tag]; set_file_handle(handler$get_file_handle(c, is_orig)); }这一实现揭示了三条重要事实每当 Files 核心需要为新连接上的文件生成句柄时就会触发该事件并通过set_file_handle落地若某分析器标签没有注册回调框架会发出get_file_handle() handler missing告警并退回到一个“fallback”格式的句柄tag-fallback-uid-is_orig-时间——这正是files.zeek必须在zeek_init中抢先注册回调的原因已注册的回调通过registered_protocols[tag]表查找并执行IRC::get_file_handle的返回值最终成为文件 ID 并回填到fuid。此外file_new优先级 10与file_over_new_connection优先级 10事件是 Files 框架侧更高优先级的通用处理器负责set_info(f)、重组缓冲区设置等基础设施工作IRC 脚本的处理器特意取优先级 5保证在框架基础工作完成后、其他低优先级处理器之前执行。六、事件联动把 DCC 上下文回填到文件files.zeek通过两个文件事件完成 IRC 上下文与文件对象的融合event file_over_new_connection(f: fa_file, c: connection, is_orig: bool) priority5 { if ( [c$id$resp_h, c$id$resp_p] !in dcc_expected_transfers ) return; local irc dcc_expected_transfers[c$id$resp_h, c$id$resp_p]; irc$fuid f$id; if ( irc?$dcc_file_name ) f$info$filename irc$dcc_file_name; f$irc irc; } event file_sniff(f: fa_file, meta: fa_metadata) priority5 { if ( f?$irc meta?$mime_type ) f$irc$dcc_mime_type meta$mime_type; }file_over_new_connection当一个文件与新连接关联时触发。逻辑分三步用连接响应方地址/端口[c$id$resp_h, c$id$resp_p]查询dcc_expected_transfers表——该表由 dcc-send.zeek 维护记录了“预期将要发生的 DCC 传输”若命中说明这条连接就是 IRC 信令中预告过的 DCC 传输把文件 ID 写入 IRC 会话记录irc$fuid f$id若预告信息中含文件名dcc_file_name则把它设置为文件的filename元数据f$info$filename使后续文件分析能直接使用原始文件名最后将整个 IRC 记录挂到f$irc。file_sniff文件内容经 MIME 嗅探后触发。若文件确实来自 IRCf?$irc且嗅探出了 MIME 类型则回填f$irc$dcc_mime_type。这一步让irc.log在文件分析完成后能记录“这个 DCC 文件实际是什么类型”与预告的文件名相互印证。七、与 DCC 传输预告机制的协作files.zeek的功能高度依赖 dcc-send.zeek 的预告机制。该脚本注释中给出了一个典型的 DCC 触发示例PRIVMSG my_nick :^ADCC SEND whateverfile.zip 3640061780 1026 41709^Airc_dcc_message事件优先级 5解析出dcc_type、文件名argument、目标地址address、端口dest_port与大小size后仅对SEND类型做处理c$irc$dcc_file_name argument; c$irc$dcc_file_size size; local p count_to_port(dest_port, tcp); Analyzer::schedule_analyzer(0.0.0.0, address, p, Analyzer::ANALYZER_IRC_DATA, 5 min); dcc_expected_transfers[address, p] c$irc;关键机制梳理预期表dcc_expected_transfers: table[addr, port] of Info read_expire5mins以“目标地址端口”为键记录 5 分钟内到期自动清理表中保存的Info随后成为f$irc的内容来源调度分析器Analyzer::schedule_analyzer(0.0.0.0, address, p, Analyzer::ANALYZER_IRC_DATA, 5 min)主动在目标地址/端口上调度 IRC DATA 分析器让 Zeek 即使在该连接尚未建立时也知道该跟踪什么容量防护max_dcc_expected_transfers: count 5000 redef设为 0 可禁用检查超过上限时上报irc_max_dcc_expected_transfers_exceededweird防止被攻击者用大量假 DCC 预告撑爆表服务标记scheduled_analyzer_applied优先级 10命中预期表时为连接添加c$service[irc-dcc-data]服务标签并注册连接移除钩子finalize_irc_data用于在连接结束时清理残留的预期状态。集群模式下的关键注意点源码注释中明确警告DCC 预告A 对 B 说与实际传输连接B 与 C 之间可能落在不同 worker上。为此 dcc-send.zeek 采用 proxy/manager 中转worker 发现irc_dcc_message后把预告发布到代理轮询话题Cluster::rr_topic(Cluster::proxy_pool, dcc_transfer_rr_key)manager/proxy 再向所有 worker 广播dcc_transfer_add同样地dcc_transfer_remove、连接移除钩子中的清理也会通过集群发布同步。若单机运行或传输连接恰在同 worker则直接写本地表并调度分析器。八、测试验证与实战使用仓库测试目录提供了 IRC DCC 功能的直接验证素材testing/btest/scripts/base/protocols/irc/basic.test用$TRACES/irc-dcc-send.pcapng重放 DCC 传输并处理irc_dcc_send_ack事件打印已接收字节数testing/btest/scripts/base/protocols/irc/events.test同样基于irc-dcc-send.pcapng逐一触发并输出 IRC 相关事件testing/btest/scripts/base/protocols/irc/max-dcc-send-expected.zeek通过redef IRC::max_dcc_expected_transfers 15;压测预期表容量限制验证irc_max_dcc_expected_transfers_exceededweird 的触发路径dcc-first-command.zeek、malformed-dcc.zeek覆盖 DCC 命令顺序异常与畸形主机/端口等边界场景。你可以用仓库内的 pcap 痕迹快速验证完整链路离线模式即可无需真实网络zeek -b -r testing/btest/Traces/irc/irc-dcc-send.pcapng scripts/base/protocols/irc运行后观察输出irc.log中应出现带fuid、dcc_file_name、dcc_file_size、dcc_mime_type的记录files.log中对应fuid的文件条目与之一致若同时加载文件分析策略如scripts/policy/frameworks/files/下的提取脚本还能看到实际提取出的文件内容。九、扩展实践基于 fuid 的跨日志溯源利用IRC::Info.fuid这一设计可以实现典型的“IRC 文件溯源”查询以irc.log中的fuid为键在files.log中查找同一fuid即可获得文件大小、MIME 类型、分析器标签、甚至files.log关联的文件内容 IDsource/fuid链配合files.log中total_bytes、seen_bytes等字段可评估传输完成度。若需要自定义句柄生成策略例如集群中按 worker 区分命名空间可按如下方式覆盖保持签名一致redef IRC::get_file_handle function(c: connection, is_orig: bool): string { return cat(my-irc, c$start_time, c$id, is_orig); };需要注意fuid同时被写入irc.log与files.log自定义时必须保证同连接同方向的返回值稳定一致否则两条日志将无法关联。十、小结base/protocols/irc/files.zeek是理解 Zeek 协议分析器与 Files 框架协作方式的极佳范例它的核心贡献可归纳为三点记录扩展为IRC::Info增加fuid输出字段为fa_file增加irc上下文字段打通会话日志与文件日志句柄提供通过IRC::get_file_handle生成稳定唯一的文件 ID并经zeek_init注册到Files::register_protocol使 Files 核心在有需要时回调上下文回填利用file_over_new_connection与file_sniff事件把 DCC 预告的文件名与实际嗅探的 MIME 类型写入 IRC 会话记录。结合 dcc-send.zeek 的预期传输表、集群发布机制与 main.zeek 的底层回调实现读者既能直接上手使用也能照此模式为其他自定义协议编写自己的文件集成脚本。赞分享网络安全网络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 的 IRC 协议分析base/protocols/irc 包结构、日志模型与 DCC 文件提取实战指南Zeek 的 IRC 协议分析base/protocols/irc 包结构、日志模型与 DCC 文件提取实战指南 本指南围绕 Zeek 仓库中 base/pr网络安全网络IDSZeek 文件提取实战深入解析 base/files/extract 框架与 FileExtract 模块Zeek 文件提取实战深入解析 base/files/extract 框架与 FileExtract 模块 导读 本文围绕 Zeek 内置脚本包 base/f网络安全网络IDSZeek 智能框架Intel Framework的文件分析集成base/frameworks/intel/files.zeek 深度解析Zeek 智能框架Intel Framework的文件分析集成 base/frameworks/intel/files.zeek 深度解析 base/fr网络安全网络IDS上一篇rkt 生产环境用户案例全览从 BlaBlaCar 到 Kubernetes 的落地实践下一篇Flutter Go终极指南掌握go-cli命令行工具快速开发Flutter组件创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/10/9 1:38:04 · 阅读 1.2k Zeek 中 IRC 文件传输提取与 Files 框架集成：深入 base/protocols/irc/files.zeek
网络安全网络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 仓库中的 base/protocols/irc/files.zeek 脚本及其 Zeekygen 参考文档doc/scripts/base/protocols/irc/files.zeek.rst为核心系统讲解 Zeek 如何为 IRC 协议接入 Files 文件分析框架从记录扩展、文件句柄fuid生成、协议注册到 DCC 传输中文件名与 MIME 类型的自动补全再到集群环境下的注意事项。读完本文你将理解 IRC 会话日志irc.log中fuid字段的来源与含义掌握IRC::get_file_handle的自定义方式并能借助 Files 框架对 IRC 传输的文件做溯源与深度分析。一、背景IRC 分析器与文件分析框架的衔接点Zeek 的 IRC 支持由module IRC承载核心会话脚本位于 scripts/base/protocols/irc/main.zeek它定义了IRC::Info记录含ts、uid、id、nick、user、command、value、addl等字段并通过Log::create_stream(..., $pathirc)将 IRC 命令与会话信息写入irc.log同时用Analyzer::register_for_ports在默认端口 6666/6667/6668/6669/tcp 上启用 IRC 分析器。然而IRC 传输的真正“内容”往往不是命令文本而是通过 DCCDirect Client-to-Client协议传输的文件。要让 Zeek 像对待 HTTP、FTP 那样对 IRC 承载的文件进行提取、重组、MIME 嗅探和深度分析就必须让 IRC 分析器与 Files 框架对接。这正是files.zeek的职责所在它是 IRC 协议与 base/frameworks/files 框架之间的“适配层”。该脚本通过三个load指令建立依赖./dcc-sendDCC 传输预期管理、base/utils/conn-ids连接标识工具、base/frameworks/files文件框架本体。从源码结构看files.zeek本身不直接分析文件内容而是负责两件事一是为 Files 框架提供生成文件句柄的回调二是在文件事件中把 DCC 上下文文件名、MIME 类型回填到 IRC 会话记录。二、记录扩展IRC::Info.fuid与fa_file.ircfiles.zeek的export块首先对两个记录做了redef扩展这是它与 Files 框架交互的数据基础redef record Info { ## File unique ID. fuid: string log optional; }; redef record fa_file { irc: IRC::Info optional; };IRC::Info.fuidstring log optional文件唯一 IDFile Unique ID。它是 Files 框架分配给每个被跟踪文件句柄的标识符与文件分析框架产生的files.log中的fuid一一对应。正因为它带log属性irc.log的每条记录都能携带本次会话关联文件的fuid从而把 IRC 会话日志与文件分析日志files.log、文件内容日志串联起来——这是溯源“谁在 IRC 上传了什么文件”的关键字段。fa_file.ircIRC::Info optional反向挂在 Files 框架的fa_file记录上让每个被跟踪的文件都能携带其所属的 IRC 会话信息。optional表示该字段并非每个文件都存在例如非 IRC 来源的文件就没有此字段脚本中通过f?$irc这样的字段存在性判断来安全访问。这种“双向挂接”的设计体现了 Zeek 脚本常见的扩展模式在源记录上增加输出字段在框架记录上增加上下文引用二者在事件处理阶段完成拼接。三、文件句柄提供者IRC::get_file_handle文档摘要中列出的唯一函数是IRC::get_file_handle其类型签名在源码中声明并实现如下global get_file_handle: function(c: connection, is_orig: bool): string; function get_file_handle(c: connection, is_orig: bool): string { return cat(Analyzer::ANALYZER_IRC_DATA, c$start_time, c$id, is_orig); }该函数接收连接c与方向标志is_orig返回一个字符串作为文件的唯一句柄。其实现将ANALYZER_IRC_DATA分析器标签、连接开始时间、连接四元组c$id和方向拼接起来cat。从源码结构看这样生成的句柄天然具备两个特性唯一性连接标识加时间戳足以区分同一连接上不同方向、不同时间段的文件可复现性给定相同的连接与方向信息生成的句柄稳定一致便于跨日志关联。值得注意的是IRC::Info.fuid正是这个返回值。在后续file_over_new_connection事件中脚本执行irc$fuid f$id;——f$id即 Files 框架为文件分配的唯一 ID它由get_file_handle回调产生详见第五节从而把 IRC 会话记录与文件 ID 正式绑定。自定义文件句柄策略时可以用redef覆盖IRC::get_file_handle注意需保持相同签名例如在集群环境中把 worker 节点信息加入句柄以避免不同 worker 之间 fuid 冲突。四、协议注册zeek_init与Files::register_protocolfiles.zeek通过zeek_init事件优先级 5把 IRC 的 DATA 分析器注册进 Files 框架event zeek_init() priority5 { Files::register_protocol(Analyzer::ANALYZER_IRC_DATA, Files::ProtoRegistration($get_file_handle IRC::get_file_handle)); }Files::register_protocol的签名与ProtoRegistration记录定义在 scripts/base/frameworks/files/main.zeektype ProtoRegistration: record { ## A callback to generate a file handle on demand when ## one is needed by the core. get_file_handle: function(c: connection, is_orig: bool): string; ## A callback to describe a file. ... describe: function(f: fa_file): string defaultfunction(f: fa_file): string { return ; }; }; global register_protocol: function(tag: Analyzer::Tag, reg: ProtoRegistration): bool;要点解读注册以分析器标签为键ANALYZER_IRC_DATA是 IRC 数据通道即 DCC 文件传输所用连接的分析器标签每个协议只能为同一标签注册一次回调重复注册时register_protocol返回false。ProtoRegistration至少需要get_file_handle回调describe回调带默认实现返回空字符串IRC 未提供自定义描述这与 HTTP 用 URL 描述文件的策略不同——从源码看IRC 的文件描述保持默认空值。注意注册的是ANALYZER_IRC_DATA而非ANALYZER_IRC这体现了 IRC 分析器的“双连接”模型——命令通道IRC与数据通道IRC_DATA即 DCC 文件传输被区分对待只有数据通道上的流量才会被 Files 框架追踪为文件。五、Files 框架的底层回调机制理解get_file_handle何时被调用需要看 Files 框架核心脚本 scripts/base/frameworks/files/main.zeek 中的同名事件get_file_handleevent get_file_handle(tag: Analyzer::Tag, c: connection, is_orig: bool) priority5 { if ( tag !in registered_protocols ) { if ( ! missing_get_file_handle_warned[tag] ) { missing_get_file_handle_warned[tag] T; Reporter::warning(fmt(get_file_handle() handler missing for %s, tag)); } set_file_handle(fmt(%s-fallback-%s-%s-%s, tag, c$uid, is_orig, network_time())); return; } local handler registered_protocols[tag]; set_file_handle(handler$get_file_handle(c, is_orig)); }这一实现揭示了三条重要事实每当 Files 核心需要为新连接上的文件生成句柄时就会触发该事件并通过set_file_handle落地若某分析器标签没有注册回调框架会发出get_file_handle() handler missing告警并退回到一个“fallback”格式的句柄tag-fallback-uid-is_orig-时间——这正是files.zeek必须在zeek_init中抢先注册回调的原因已注册的回调通过registered_protocols[tag]表查找并执行IRC::get_file_handle的返回值最终成为文件 ID 并回填到fuid。此外file_new优先级 10与file_over_new_connection优先级 10事件是 Files 框架侧更高优先级的通用处理器负责set_info(f)、重组缓冲区设置等基础设施工作IRC 脚本的处理器特意取优先级 5保证在框架基础工作完成后、其他低优先级处理器之前执行。六、事件联动把 DCC 上下文回填到文件files.zeek通过两个文件事件完成 IRC 上下文与文件对象的融合event file_over_new_connection(f: fa_file, c: connection, is_orig: bool) priority5 { if ( [c$id$resp_h, c$id$resp_p] !in dcc_expected_transfers ) return; local irc dcc_expected_transfers[c$id$resp_h, c$id$resp_p]; irc$fuid f$id; if ( irc?$dcc_file_name ) f$info$filename irc$dcc_file_name; f$irc irc; } event file_sniff(f: fa_file, meta: fa_metadata) priority5 { if ( f?$irc meta?$mime_type ) f$irc$dcc_mime_type meta$mime_type; }file_over_new_connection当一个文件与新连接关联时触发。逻辑分三步用连接响应方地址/端口[c$id$resp_h, c$id$resp_p]查询dcc_expected_transfers表——该表由 dcc-send.zeek 维护记录了“预期将要发生的 DCC 传输”若命中说明这条连接就是 IRC 信令中预告过的 DCC 传输把文件 ID 写入 IRC 会话记录irc$fuid f$id若预告信息中含文件名dcc_file_name则把它设置为文件的filename元数据f$info$filename使后续文件分析能直接使用原始文件名最后将整个 IRC 记录挂到f$irc。file_sniff文件内容经 MIME 嗅探后触发。若文件确实来自 IRCf?$irc且嗅探出了 MIME 类型则回填f$irc$dcc_mime_type。这一步让irc.log在文件分析完成后能记录“这个 DCC 文件实际是什么类型”与预告的文件名相互印证。七、与 DCC 传输预告机制的协作files.zeek的功能高度依赖 dcc-send.zeek 的预告机制。该脚本注释中给出了一个典型的 DCC 触发示例PRIVMSG my_nick :^ADCC SEND whateverfile.zip 3640061780 1026 41709^Airc_dcc_message事件优先级 5解析出dcc_type、文件名argument、目标地址address、端口dest_port与大小size后仅对SEND类型做处理c$irc$dcc_file_name argument; c$irc$dcc_file_size size; local p count_to_port(dest_port, tcp); Analyzer::schedule_analyzer(0.0.0.0, address, p, Analyzer::ANALYZER_IRC_DATA, 5 min); dcc_expected_transfers[address, p] c$irc;关键机制梳理预期表dcc_expected_transfers: table[addr, port] of Info read_expire5mins以“目标地址端口”为键记录 5 分钟内到期自动清理表中保存的Info随后成为f$irc的内容来源调度分析器Analyzer::schedule_analyzer(0.0.0.0, address, p, Analyzer::ANALYZER_IRC_DATA, 5 min)主动在目标地址/端口上调度 IRC DATA 分析器让 Zeek 即使在该连接尚未建立时也知道该跟踪什么容量防护max_dcc_expected_transfers: count 5000 redef设为 0 可禁用检查超过上限时上报irc_max_dcc_expected_transfers_exceededweird防止被攻击者用大量假 DCC 预告撑爆表服务标记scheduled_analyzer_applied优先级 10命中预期表时为连接添加c$service[irc-dcc-data]服务标签并注册连接移除钩子finalize_irc_data用于在连接结束时清理残留的预期状态。集群模式下的关键注意点源码注释中明确警告DCC 预告A 对 B 说与实际传输连接B 与 C 之间可能落在不同 worker上。为此 dcc-send.zeek 采用 proxy/manager 中转worker 发现irc_dcc_message后把预告发布到代理轮询话题Cluster::rr_topic(Cluster::proxy_pool, dcc_transfer_rr_key)manager/proxy 再向所有 worker 广播dcc_transfer_add同样地dcc_transfer_remove、连接移除钩子中的清理也会通过集群发布同步。若单机运行或传输连接恰在同 worker则直接写本地表并调度分析器。八、测试验证与实战使用仓库测试目录提供了 IRC DCC 功能的直接验证素材testing/btest/scripts/base/protocols/irc/basic.test用$TRACES/irc-dcc-send.pcapng重放 DCC 传输并处理irc_dcc_send_ack事件打印已接收字节数testing/btest/scripts/base/protocols/irc/events.test同样基于irc-dcc-send.pcapng逐一触发并输出 IRC 相关事件testing/btest/scripts/base/protocols/irc/max-dcc-send-expected.zeek通过redef IRC::max_dcc_expected_transfers 15;压测预期表容量限制验证irc_max_dcc_expected_transfers_exceededweird 的触发路径dcc-first-command.zeek、malformed-dcc.zeek覆盖 DCC 命令顺序异常与畸形主机/端口等边界场景。你可以用仓库内的 pcap 痕迹快速验证完整链路离线模式即可无需真实网络zeek -b -r testing/btest/Traces/irc/irc-dcc-send.pcapng scripts/base/protocols/irc运行后观察输出irc.log中应出现带fuid、dcc_file_name、dcc_file_size、dcc_mime_type的记录files.log中对应fuid的文件条目与之一致若同时加载文件分析策略如scripts/policy/frameworks/files/下的提取脚本还能看到实际提取出的文件内容。九、扩展实践基于 fuid 的跨日志溯源利用IRC::Info.fuid这一设计可以实现典型的“IRC 文件溯源”查询以irc.log中的fuid为键在files.log中查找同一fuid即可获得文件大小、MIME 类型、分析器标签、甚至files.log关联的文件内容 IDsource/fuid链配合files.log中total_bytes、seen_bytes等字段可评估传输完成度。若需要自定义句柄生成策略例如集群中按 worker 区分命名空间可按如下方式覆盖保持签名一致redef IRC::get_file_handle function(c: connection, is_orig: bool): string { return cat(my-irc, c$start_time, c$id, is_orig); };需要注意fuid同时被写入irc.log与files.log自定义时必须保证同连接同方向的返回值稳定一致否则两条日志将无法关联。十、小结base/protocols/irc/files.zeek是理解 Zeek 协议分析器与 Files 框架协作方式的极佳范例它的核心贡献可归纳为三点记录扩展为IRC::Info增加fuid输出字段为fa_file增加irc上下文字段打通会话日志与文件日志句柄提供通过IRC::get_file_handle生成稳定唯一的文件 ID并经zeek_init注册到Files::register_protocol使 Files 核心在有需要时回调上下文回填利用file_over_new_connection与file_sniff事件把 DCC 预告的文件名与实际嗅探的 MIME 类型写入 IRC 会话记录。结合 dcc-send.zeek 的预期传输表、集群发布机制与 main.zeek 的底层回调实现读者既能直接上手使用也能照此模式为其他自定义协议编写自己的文件集成脚本。赞分享网络安全网络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 的 IRC 协议分析base/protocols/irc 包结构、日志模型与 DCC 文件提取实战指南Zeek 的 IRC 协议分析base/protocols/irc 包结构、日志模型与 DCC 文件提取实战指南 本指南围绕 Zeek 仓库中 base/pr网络安全网络IDSZeek 文件提取实战深入解析 base/files/extract 框架与 FileExtract 模块Zeek 文件提取实战深入解析 base/files/extract 框架与 FileExtract 模块 导读 本文围绕 Zeek 内置脚本包 base/f网络安全网络IDSZeek 智能框架Intel Framework的文件分析集成base/frameworks/intel/files.zeek 深度解析Zeek 智能框架Intel Framework的文件分析集成 base/frameworks/intel/files.zeek 深度解析 base/fr网络安全网络IDS上一篇rkt 生产环境用户案例全览从 BlaBlaCar 到 Kubernetes 的落地实践下一篇Flutter Go终极指南掌握go-cli命令行工具快速开发Flutter组件创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考