
网络安全网络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 官方文档 doc/scripts/base/bif/types.bif.zeek.rst 展开系统解析 Zeek 内核在运行时内部使用的全部枚举类型从 RPC/MOUNT3/NFS3 协议状态码到隧道类型Tunnel::Type、链路与网络层协议标识link_encap、layer3_proto再到表变更事件、Reporter 日志级别与 AF_Packet 抓包选项。读完本文你将能理解这些内置类型在 Zeek 脚本与 C 内核之间的绑定关系、每个枚举值的语义与数值来源并掌握在真实抓包与协议分析场景中它们如何被底层模块引用。一、文档定位一份由 Zeekygen 生成的内核类型参考base/bif/types.bif.zeek是 Zeek 运行时内置BIF脚本的一部分官方文档页面 doc/scripts/base/bif/types.bif.zeek.rst 即 Zeekygen 工具针对该脚本自动生成的 API 参考其页面简介只有一句话Declaration of various types that the Zeek core uses internally.即Zeek 核心内部使用的各种类型的声明。该脚本并非手工维护而是由 BIFBro/Zeek Interface机制在构建期生成真正的类型定义源码位于 src/types.bif其首行注释与文档完全一致##! Declaration of various types that the Zeek core uses internally.。Zeek 的构建流程通过 bifcl 编译器把src/types.bif加工为base/bif/types.bif.zeek脚本同时生成对应的 C 绑定如BifEnum::Tunnel::Type、BifType::Enum::link_encap使同一份枚举定义既能被 Zeek 脚本引用也能被 C 内核直接访问。文档覆盖了 6 个命名空间下的 14 个枚举类型命名空间枚举类型用途GLOBALrpc_statusONC RPC 调用状态MOUNT3proc_t/status_t/auth_flavor_tMOUNTv3 协议过程号、返回状态、认证类型NFS3proc_t/status_t/time_how_t/file_type_t/stable_how_t/createmode_tNFSv3 协议过程号与语义参数TunnelType隧道封装类型GLOBALlink_encap/layer3_proto二层封装与三层协议标识GLOBALTableChange表元素变更类型ReporterLevel日志/告警级别AF_PacketFanoutMode/ChecksumModeLinux AF_Packet 抓包选项二、RPC 协议状态rpc_statusrpc_status是定义在 GLOBAL 命名空间的枚举用于描述一次 ONC RPC 调用RFC 5531 体系的处理结果共 10 个成员枚举值含义RPC_SUCCESS调用成功RPC_PROG_UNAVAIL程序不可用RPC_PROG_MISMATCH程序版本不匹配RPC_PROC_UNAVAIL过程不可用RPC_GARBAGE_ARGS参数无法解析RPC_SYSTEM_ERR远端系统错误RPC_TIMEOUT调用超时RPC_VERS_MISMATCH协议版本不匹配RPC_AUTH_ERROR认证错误RPC_UNKNOWN_ERROR未知错误与内核 C 侧的对应关系在 src/analyzer/protocol/rpc/RPC.h 中内核以uint8_t常量复现了同一套状态语义RPC_SUCCESS 0、RPC_PROG_UNAVAIL 1、RPC_PROG_MISMATCH 2、RPC_PROC_UNAVAIL 3、RPC_GARBAGE_ARGS 4、RPC_SYSTEM_ERR 5这是 RPC 应答accept_stat字段的取值而RPC_VERS_MISMATCH与RPC_AUTH_ERROR属于reject_stat分支中的明细类型RPC_MISMATCH 0、RPC_AUTH_ERROR 1。这解释了文档中rpc_status为何把两套状态合并在 src/analyzer/protocol/rpc/RPC.cc 中有一段关键注释——Note that RPC_MISMATCH 0 RPC_SUCCESS.即协议层面拒绝且版本不匹配与接受且成功恰好数值同为 0因此解析器将其规整为独立的RPC_VERS_MISMATCH枚举值。实际使用中RPC 分析器用该枚举判断请求是否成功例如 src/analyzer/protocol/rpc/MOUNT.cc 与 src/analyzer/protocol/rpc/NFS.cc 均以bool rpc_success (rpc_status BifEnum::RPC_SUCCESS);决定后续事件是否触发src/analyzer/protocol/rpc/Portmap.cc 同样基于status BifEnum::RPC_SUCCESS判断 portmap 查询是否有效。也就是说这个枚举既是文档中的类型声明也是整个 RPC 分析器Portmap/MOUNT/NFS共享的成功判定基准。三、MOUNT3 与 NFS3 协议枚举过程号、状态码与参数语义Zeek 内置了对 MOUNTv3 与 NFSv3 的协议分析能力对应源码目录 src/analyzer/protocol/rpc。src/types.bif为这两个协议各声明了一组枚举分别覆盖过程号、返回状态和语义参数。3.1 MOUNT3 命名空间MOUNT3::proc_t过程号——共 7 个成员源码中带有编号与实现进度注释枚举值数值源码注释PROC_NULL0donePROC_MNT1donePROC_DUMP2not implementedPROC_UMNT3donePROC_UMNT_ALL4donePROC_EXPORT5not implementedPROC_END_OF_PROCS6not implementedMOUNT3::status_t返回状态——数值与 POSIX errno 风格一致另有两个 MOUNT 特有值MNT3ERR_NOTSUPP 10004、MNT3ERR_SERVERFAULT 10006以及哨兵值MOUNT3ERR_UNKNOWN 0xffffffff。完整成员为MNT3_OK(0)、MNT3ERR_PERM(1)、MNT3ERR_NOENT(2)、MNT3ERR_IO(5)、MNT3ERR_ACCES(13)、MNT3ERR_NOTDIR(20)、MNT3ERR_INVAL(22)、MNT3ERR_NAMETOOLONG(63)、MNT3ERR_NOTSUPP(10004)、MNT3ERR_SERVERFAULT(10006)、MOUNT3ERR_UNKNOWN(0xffffffff)。MOUNT3::auth_flavor_t认证类型——AUTH_NULL(0)、AUTH_UNIX(1)、AUTH_SHORT(2)、AUTH_DES(3)与 RPC 认证 flavor 的协议定义一致可对照 src/analyzer/protocol/rpc/RPC.h 中同名的 C 常量。3.2 NFS3 命名空间NFS3::proc_t过程号——覆盖 NFSv3 的全部 22 个过程PROC_NULL 0到PROC_COMMIT 21外加哨兵PROC_END_OF_PROCS 22。源码同样标注了实现进度例如PROC_GETATTR、PROC_READ、PROC_WRITE等标记为 done而PROC_ACCESS、PROC_FSSTAT、PROC_FSINFO等标记为 not implementedPROC_CREATE、PROC_MKDIR标记为 partial——这反映的是 Zeek 分析器当前对 NFSv3 各过程的解析覆盖范围。NFS3::status_t返回状态——成员数量最多28 个同样遵循 errno 风格NFS3ERR_OK(0)、NFS3ERR_PERM(1)、NFS3ERR_NOENT(2)、NFS3ERR_IO(5)、NFS3ERR_NXIO(6)、NFS3ERR_ACCES(13)、NFS3ERR_EXIST(17)、NFS3ERR_XDEV(18)、NFS3ERR_NODEV(19)、NFS3ERR_NOTDIR(20)、NFS3ERR_ISDIR(21)、NFS3ERR_INVAL(22)、NFS3ERR_FBIG(27)、NFS3ERR_NOSPC(28)、NFS3ERR_ROFS(30)、NFS3ERR_MLINK(31)、NFS3ERR_NAMETOOLONG(63)、NFS3ERR_NOTEMPTY(66)、NFS3ERR_DQUOT(69)、NFS3ERR_STALE(70)、NFS3ERR_REMOTE(71)以及 NFS 特有错误区间NFS3ERR_BADHANDLE(10001)、NFS3ERR_NOT_SYNC(10002)、NFS3ERR_BAD_COOKIE(10003)、NFS3ERR_NOTSUPP(10004)、NFS3ERR_TOOSMALL(10005)、NFS3ERR_SERVERFAULT(10006)、NFS3ERR_BADTYPE(10007)、NFS3ERR_JUKEBOX(10008)最后以NFS3ERR_UNKNOWN 0xffffffff收尾。语义参数枚举——三个小型枚举用于描述 NFS 调用的参数选择NFS3::time_how_t时间设置方式DONT_CHANGE(0)不修改时间、SET_TO_SERVER_TIME(1)设为服务器时间、SET_TO_CLIENT_TIME(2)设为客户端指定时间NFS3::file_type_t文件类型FTYPE_REG(1)、FTYPE_DIR(2)、FTYPE_BLK(3)、FTYPE_CHR(4)、FTYPE_LNK(5)、FTYPE_SOCK(6)、FTYPE_FIFO(7)NFS3::stable_how_t写稳定性UNSTABLE(0)、DATA_SYNC(1)、FILE_SYNC(2)NFS3::createmode_t创建模式UNCHECKED(0)、GUARDED(1)、EXCLUSIVE(2)。值得注意的是src/types.bif 在同一命名空间下还声明了一批record类型如info_t、fattr_t、sattr_t、readargs_t、writeargs_t等它们本身不带字段定义真正的字段定义在基础脚本 scripts/base/init-bare.zeek 中该文件同时引用了link_encap、layer3_proto等枚举。这是 BIF 机制的典型用法类型在 C 侧占位声明、在 Zeek 脚本侧补充字段实现事件参数的类型化传递。四、隧道识别Tunnel::TypeTunnel::Type是 Zeek 隧道检测体系的核心枚举定义于 src/types.bif共 10 个成员枚举值含义Tunnel::NONE非隧道流量默认值Tunnel::IPIP-in-IP 隧道含 GRE 等直接承载 IP 的场景Tunnel::AYIYAAYIYAIPv6 隧道封装Tunnel::TEREDOTeredo 隧道Tunnel::SOCKSSOCKS 代理封装Tunnel::GTPv1GTPv1移动网络隧道Tunnel::HTTPHTTP 封装隧道Tunnel::GREGRE 隧道Tunnel::VXLANVXLANUDP 封装Tunnel::GENEVEGENEVE 隧道源码中的流转路径该枚举贯穿抓包 → 包分析 → 会话管理整条链路包对象初始化src/iosource/Packet.cc 在Packet::Init()中将tunnel_type重置为BifEnum::Tunnel::NONE保证每个新数据包从非隧道基线开始对应头文件 src/iosource/Packet.h 的默认值隧道分析器判定src/packet_analysis/protocol/iptunnel/IPTunnel.cc 从packet-tunnel_type取出类型并按隧道深度限制BifConst::Tunnel::max_depth检查嵌套层数超限时抛出Weird(exceeded_tunnel_max_depth)隧道连接建模src/TunnelEncapsulation.h 中EncapsulatingConn的构造函数以BifEnum::Tunnel::Type作为类型参数且operator对不同隧道类型采用不同的等价判定IP/GRE隧道端点反转仍视为同一隧道L85-L89VXLAN因目的端口恒定还额外校验目的端口L91-L97其余类型则要求五元组完全一致。因此Tunnel::Type不只是给隧道起个名字它直接决定了隧道 UID 的分配与去重逻辑进而影响tunnel.log中每一条隧道记录的归并方式。五、链路与网络层标识link_encap 与 layer3_protolink_encap与layer3_proto是 GLOBAL 命名空间下的两个极简枚举用于描述数据包的二层封装与三层协议link_encapLINK_ETHERNET以太网封装、LINK_UNKNOWN未知封装layer3_protoL3_IPV4、L3_IPV6、L3_ARP、L3_UNKNOWN。在 raw_pkt_hdr 记录中的落地它们的典型消费点是 src/iosource/Packet.cc 的ToRawPktHdrVal()。该方法构造raw_pkt_hdr记录其内嵌l2_hdr记录的字段布局注释Packet.cc L103-L116明确标注了encap: link_encap; ## L2 link encapsulation. proto: layer3_proto; ## L3 protocol.实现中若链路类型为以太网DLT_EN10MB则encap字段填入BifEnum::LINK_ETHERNETL121否则填入LINK_UNKNOWNL154proto字段根据l3_proto成员映射为L3_IPV4/L3_IPV6/L3_ARPL93-L101其中 ARP 是以太网之上识别出的 ARPL149-L151。这两类枚举因此成为 Zeek 将原始包头部统一抽象为脚本可见记录时的标准分类标签。六、运行时基础设施TableChange 与 Reporter::Level6.1 TableChange表元素变更事件TableChange定义于 src/types.bif描述一张 Zeek 表中单个元素发生的变更类型共 4 个成员枚举值含义TABLE_ELEMENT_NEW新元素加入TABLE_ELEMENT_CHANGED既有元素值被修改TABLE_ELEMENT_REMOVED元素被显式删除TABLE_ELEMENT_EXPIRED元素因过期interval/expire_func被清理它在两个核心模块中被使用值语义层src/Val.cc 在构造TableVal的变更列表时逐元素判定其状态并填入对应的BifEnum::TableChange值集群发布层src/cluster/PublishOnChangeState.cc 与 L320 将BifEnum::TableChange作为变更即发布publish-on-change机制的事件类型L548 按变更类型分支处理发布逻辑头文件 src/cluster/PublishOnChangeState.h 还提供了table_change_to_bit()将枚举映射为位掩码。6.2 Reporter::Level日志与告警级别Reporter::Level定义于 src/types.bif是 Zeek 内部日志/告警系统的分级枚举带显式数值INFO 0 WARNING 1 ERROR 2它对应 Zeek 脚本中Reporter::info()、Reporter::warning()、Reporter::error()等函数的语义分级脚本侧可通过Reporter::Level对告警消息的严重程度进行编程式判断与过滤。七、AF_Packet 抓包选项FanoutMode 与 ChecksumModeAF_Packet 是 Zeek 在 Linux 上高性能抓包的数据源插件源码目录 src/iosource/af_packetsrc/types.bif为其声明了两个配置枚举。7.1 AF_Packet::FanoutMode多队列分流模式enum FanoutMode %{ FANOUT_HASH, # PACKET_FANOUT_HASH FANOUT_CPU, # PACKET_FANOUT_CPU FANOUT_QM, # PACKET_FANOUT_QM FANOUT_CBPF, # PACKET_FANOUT_CBPF FANOUT_EBPF, # PACKET_FANOUT_EBPF %}源码注释直接标注了每个成员对应的 Linux 内核PACKET_FANOUT_*常量FANOUT_HASH按包哈希分流、FANOUT_CPU按 CPU 分流、FANOUT_QM按队列映射分流、FANOUT_CBPF经典 BPF 分流、FANOUT_EBPFeBPF 分流。选择不同模式会影响多队列网卡流量在多个 Zeek 进程/线程间的分发策略从而影响抓包吞吐与排序保证。7.2 AF_Packet::ChecksumMode校验和验证模式enum ChecksumMode %{ ## Ignore checksums, i.e. always assume they are correct. CHECKSUM_OFF, ## Let Zeek compute and verify checksums. CHECKSUM_ON, ## Let the kernel handle checksum offloading. ## Note: Semantics may depend on the kernel and driver version. CHECKSUM_KERNEL, %}三个成员分别对应三种校验策略CHECKSUM_OFF忽略校验和一律假定校验正确——适合校验和本身不可靠或为性能放弃校验的场景CHECKSUM_ON由 Zeek 计算并验证校验和——最严格的模式代价是额外的 CPU 开销CHECKSUM_KERNEL交由内核处理校验卸载offloading——依赖网卡/驱动能力文档明确提示语义可能取决于内核与驱动版本。该枚举通常在 AF_Packet 抓包配置如 Zeek 配置中的 checksum 相关选项中引用决定 Zeek 对捕获帧的 L2/L3/L4 校验和字段的信任与验证程度。八、脚本侧使用方式与定位建议由于 BIF 类型对 Zeek 脚本全局可见上述枚举无需load即可直接引用。常见的脚本侧用法包括# 判断隧道类型配合 tunnel 相关事件/字段 if ( tunnel_type Tunnel::VXLAN ) print VXLAN tunnel detected; # 引用日志分级 Reporter::error(fmt(something failed at level %s, Reporter::ERROR)); # 判断网络层协议配合 raw_pkt_hdr 等 if ( pkt_hdr$l2$proto L3_IPV6 ) print IPv6 packet;需要查找具体脚本用法时可在仓库中检索枚举名例如scripts/base/init-bare.zeek中定义了引用link_encap、layer3_proto的记录类型C 侧则以BifEnum::/BifType::Enum::前缀引用如BifEnum::Tunnel::Type、BifType::Enum::link_encap-GetEnumVal(...)。定位建议这份文档是理解 Zeek协议状态码如何映射为脚本类型的入口。结合 src/types.bif类型声明源头、src/iosource/Packet.cc链路/网络层与隧道枚举消费点、src/analyzer/protocol/rpcRPC/MOUNT/NFS 枚举消费点与 src/cluster/PublishOnChangeState.ccTableChange 消费点即可形成声明 → 绑定 → 使用的完整认知闭环。若需查看 Zeek 内置脚本对这些类型的其他引用可直接在 scripts/base 与 scripts/policy 目录中检索对应枚举名。赞分享网络安全网络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 内置 BIF 模块全解析base/bif 脚本层内置函数、类型与事件体系导览Zeek 内置 BIF 模块全解析base/bif 脚本层内置函数、类型与事件体系导览 Zeek 的脚本层script layer之所以能直接调用底层 C网络安全网络IDSZeek base/bif 包深度解析BIF 加载机制与内置功能全景Zeek base/bif 包深度解析BIF 加载机制与内置功能全景 base/bif/__load__.zeek 是 Zeek 脚本层所有内置函数BIF网络安全网络IDSebpf-go中的常量与枚举类型类型安全的内核交互ebpf go中的常量与枚举类型类型安全的内核交互 在eBPFExtended Berkeley Packet Filter开发中与内核交互的类型安全是系统底层网络可观测性上一篇CANN/hcomm通信线程获取API下一篇终极指南Open3D零拷贝技术实现3D数据处理效率最大化创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考