网络安全网络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 的监控定位为出发点系统讲解如何围绕 Zeek 搭建一套完整的网络安全监控NSM体系从检测与响应的分析工作流匹配已知指标 vs. 假设驱动猎杀、传感器在网络中的部署位置选择到日志的存储、格式与回顾方法。读完本文你将掌握 Zeek 在四类监控数据中的能力边界、如何在 SOHO 与可见网络架构中选点部署传感器、如何利用 Community ID 将 IDS 告警与 Zeek 日志关联 pivot以及如何配置日志输出格式与压缩以便对接 SIEM 平台。一、Zeek 在网络安全监控数据谱系中的定位Zeek 官方文档将网络安全监控数据划分为四种类型而 Zeek 开箱即用地擅长其中两类数据类型含义Zeek 能力事务数据Transaction Data会话的元数据如连接两端地址、端口、协议、时长、字节数✅ 默认生成即各类协议日志提取内容数据Extracted Content从流量中还原出的文件、证书、字符串等对象✅ 默认生成经文件分析框架提取警报数据Alert Data明确标记为恶意或可疑的事件告警⚠️ 部分提供notice 机制可自定义扩展全内容数据Full Content完整 PCAP 原始报文留存❌ 不采集需借助其他开源项目也就是说无需任何重大配置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 日志的仓库就能尽可能全面地了解相关系统。这一安全设计模式价值巨大因为它不触碰可疑资产本身入侵者不会察觉安全团队正在调查资产的取证完整性得以保持——分析师操作的是存储在设备之外的日志。2.5 源码级佐证Community ID 实现Community ID 关联能力的底层实现在 src/communityid.bif 中它通过 BIF 机制向 Zeek 脚本暴露了community_id_v1内置函数function community_id_v1%(cid: conn_id, seed: count default0, do_base64: bool defaultT%): string从实现细节看该函数对连接五元组做规范化处理必要时交换源/目的以保持方向无关性、按传输层协议区分 TCP/UDP/ICMP/ICMPv6再以 SHA-1 计算哈希最终输出带1:版本前缀的字符串默认再做 Base64 编码以缩短长度相关代码见 src/communityid.bif。在策略层Zeek 通过两个脚本把该哈希接入日常日志scripts/policy/protocols/conn/community-id-logging.zeek定义CommunityID::seed默认 016 位哈希种子与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_jsonT $ 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:yvyB8h3dnggTZW0UEITWCst97w }community_id_v1也可以直接在命令行对任意conn_id记录求值方便在脚本或一次性调查中手工比对$ zeek -e print community_id_v1([$orig_h141.142.228.5, $orig_p59856/tcp, $resp_h192.150.187.43, $resp_p80/tcp]) 1:yvyB8h3dnggTZW0UEITWCst97w三、仪表化与采集传感器的部署位置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 CPELAN 侧四个千兆铜缆以太网口供设备接入客户设备经 WiFi 或铜缆连入。路由器 WAN 侧通常持有 ISP 分配的公网 IPLAN 侧提供 RFC 1918 私网地址常见于 192.168.0.0/16 网段并通过 NAT严格说是网络端口地址转换 NPAT让客户设备共享单个公网 IP。个别情况下多个住户甚至共享同一公网 IP、仅靠端口范围区分彼此。逐一评估 A–D 四个位置位置位置描述可行性评估AISP CPE 外侧电缆入地❌ 客户无法触及BISP CPE 与路由器之间的铜缆⚠️ 可插 TAP 或带 SPAN 的小型可管理交换机如 Netgear GS30Xe 级别但路由器 NAT 使所有流量都显示为同一源 IP——无论 100 台还是 1 台设备都共享该 IP安全分析师极难追踪可疑/恶意流量的源头C路由器与无线终端之间的链路❌ 基本不可行。渗透测试与无线排障工具无法以安全分析师可用的形式暴露 WiFi 流量现代 WiFi 协议下D路由器与有线终端之间的链路⚠️ 可行需装 TAP 或 SPAN但会漏掉全部 WiFi 流量结论标准 SOHO 架构并不适合网络安全监控——默认没有好位置能看到通常调查所需的原始源 IP 地址。3.3 可见网络架构把可见性设计进去与上图相对的是可见网络架构Visible Network Architecture——可见性在设计阶段就被纳入而非事后补救。该架构的关键改动ISP 路由器不再兼任 WAPWiFi 能力被禁用严格说只要无人使用WiFi 不必物理禁用客户自购路由器是否提供 NAT 均可客户明确拥有一台交换机有线设备接入且该交换机带SPAN 端口客户明确拥有自己的无线接入点以**桥接bridge**模式工作、不做 NAT。关键点不要以为买一台新的路由/WAP 组合设备就行。必须拆分这些功能——消费级路由器不提供 SPAN 端口而廉价消费级交换机反而提供。本架构正是利用这一点获得合适的监控位置。逐一评估 A–G位置评估A❌ 仍不可触及B❌ 仍是坏主意C✅ 好选项在此放网络 TAP 或带 SPAN 的小交换机前提是客户路由器与客户 WAP 都不做 NATD✅ 更优选项只需保证客户 WAP 不做 NAT若能在客户交换机上做上行口 SPAN甚至无需再引入交换机或 TAPE❌ 只能看到有线设备漏掉 WiFiF❌ 只能看到 WiFi 设备漏掉有线G❌ 与图 1 相同基本不可能结论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.zeekLog::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 与 JSONZeek 具备把日志写成多种格式并执行压缩、归档等管理操作的能力。最常用的格式选项集中在 scripts/base/frameworks/logging/writers/ascii.zeek 的LogAscii模块常用项如下均可在命令行以LogAscii::xxx值覆盖也可作为日志 Filter 的$config逐过滤器设置配置项默认值说明LogAscii::use_jsonF输出 JSON 格式利于对接 SIEM、jq 等工具LogAscii::json_timestampsJSON::TS_EPOCHJSON 时间戳格式默认 Unix 纪元秒浮点LogAscii::json_include_unset_fieldsF是否输出未设置的可选字段设为 T 则以 null 输出LogAscii::gzip_level0gzip 压缩级别0 表示不压缩启用后文件名追加扩展名LogAscii::gzip_file_extensiongz压缩文件扩展名LogAscii::include_metaT是否在 ASCII 日志中包含列名、类型等元信息行JSON 下隐式关闭LogAscii::enable_utf_8T合法 UTF-8 序列原样写入日志命令行覆盖示例输出 JSON 并压缩$ zeek -r ./traces/quickstart.pcap LogAscii::use_jsonT LogAscii::gzip_level6回顾方式可以简单到使用操作系统自带的文本处理工具视日志格式不同也可以使用 Zeek 随附的专用处理工具例如zeek-cut见 tools/zeek-cut/。在许多情况下管理员会把日志投递到专门的存储与回顾应用——即统称的SIEM安全与信息事件管理平台其中部分以开源形式提供部分为商业产品。Zeek 的 JSON 输出、时间戳与字段规范化设计正是为了降低这类对接成本。4.3 分析工作流与存储结合回顾 第二节 的工作流matching 场景下分析师直接查询 Zeek 事务日志库匹配 IoChunting 场景下分析师在样本与生产数据中验证假设IDS 告警场景下借助 Community ID 字段把告警与conn.log、notice.log等记录关联。无论哪种范式都依赖一个可查询、可保留的日志存储——这正是 Zeek 日志管理能力格式、压缩、归档与 SIEM 对接存在的意义。五、小结从采集到分析的一条龙实践要点明确能力边界Zeek 默认产出事务数据与提取内容数据notice 机制提供部分告警能力全内容 PCAP 留存需借助其他工具选对范式自动化匹配 IoC 用 matching需要探索未知敌手行为时用假设驱动、可证伪的 hunting 流程善用 Community ID加载 community-id-logging.zeek 与 community-id.zeek即可用1:...形式的流哈希在 IDS 告警与 Zeek 日志之间 pivot底层由community_id_v1src/communityid.bif保证方向无关的稳定计算把可见性设计进网络优先采用可见网络架构在 D 点或简化架构的 C 点用有源 TAP 或交换机 SPAN 获取流量确保看到原始源 IP管理好日志生命周期用LogAscii::use_json、LogAscii::gzip_level等配置控制格式与压缩按需对接开源或商业 SIEM让日志沉淀为可持续查询的取证资产。赞分享网络安全网络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点击查看免费下载相关推荐用 Meshery 部署 Azure Monitor Containers容器洞察、指标采集与日志流式监控实战用 Meshery 部署 Azure Monitor Containers容器洞察、指标采集与日志流式监控实战 本文以 Meshery 设计目录Design云原生微服务运维DevOps终极指南Marlin硬件监控与传感器数据采集全解析终极指南Marlin硬件监控与传感器数据采集全解析 Marlin固件作为全球最流行的3D打印机开源固件其强大的硬件监控与传感器数据采集功能是确保打印质量和设智能硬件嵌入式固件物联网硬件监控的幕后英雄LibreHardwareMonitor传感器数据采集全流程解析硬件监控的幕后英雄LibreHardwareMonitor传感器数据采集全流程解析 你是否曾好奇任务管理器中的CPU温度、风扇转速等数据从何而来这些看似简单指标监控创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考