Modbus 协议异常检测实战指南：基于 Zeek、Suricata 与 Python 的 OT 网络入侵检测方案-迪斯科星球

Modbus 协议异常检测实战指南：基于 Zeek、Suricata 与 Python 的 OT 网络入侵检测方案

【免费下载链接】Anthropic-Cybersecurity-Skills817 structured cybersecurity skills for AI agents · Mapped to 6 frameworks: MITRE ATT&CK, NIST CSF 2.0, MITRE ATLAS, D3FEND, NIST AI RMF & MITRE F3 (Fight Fraud) · agentskills.io standard · Works with Claude Code, GitHub Copilot, Codex CLI, Cursor, Gemini CLI & 20+ platforms · 29 security domains · Apache 2.0项目地址: https://gitcode.com/GitHub_Trending/an/Anthropic-Cybersecurity-Skills

Modbus 是工业控制（ICS/SCADA）环境中最常见的通信协议，但其本身没有任何原生安全机制，极易被攻击者利用来操纵工艺参数或破坏生产流程。本指南以 Anthropic-Cybersecurity-Skills 仓库中 detecting-modbus-protocol-anomalies 技能为核心，系统讲解如何通过函数码监控、寄存器范围校验、时序分析与深度包检测识别 Modbus 流量中的异常，并结合 Zeek 协议分析器、Suricata 入侵检测规则与 Python 统计模型构建完整的 OT 侧异常检测方案。读完本文，你将掌握 Modbus 协议硬性限制、六大异常检测规则、规则引擎的落地配置，以及可直接运行的检测脚本用法。

Modbus 协议基础与硬性限制

在部署任何检测方案之前，必须先理解 Modbus 协议的底层结构与协议规定的硬性上限。Modbus/TCP 运行在 TCP 502 端口，报文由MBAP 头（Modbus Application Protocol Header）与PDU（Protocol Data Unit）组成。其中 MBAP 头包含事务 ID、协议 ID（固定为 0x0000）、长度字段与单元 ID（Unit ID），PDU 则承载功能码与数据。

api-reference.md 中明确给出了判定"读取量是否越界"所依赖的协议极限值，这是检测逻辑正确性的根基：

参数	最大值
线圈读取数量（Coil read quantity）	2000
寄存器读取数量（Register read quantity）	125
寄存器写入数量（Register write quantity）	123
单元 ID 范围（Unit ID range）	1-247
PDU 大小（PDU size）	253 字节

这些数值在检测脚本中被直接引用：scripts/agent.py中定义了MAX_REGISTER_READ = 125与MAX_COIL_READ = 2000，任何超过该上限的读请求都会被标记为异常。值得注意的边界细节是：单元 ID 为 0 时代表广播（面向所有从站），因此广播写操作在 OT 环境中属于高危信号（详见后文检测规则）。

Modbus 的功能码决定了操作类型，SKILL.md 中给出了完整的功能码清单：

读操作：FC 1（读取线圈）、FC 2（读取离散输入）、FC 3（读取保持寄存器）、FC 4（读取输入寄存器）
写操作：FC 5（写单个线圈）、FC 6（写单个寄存器）、FC 15（写多个线圈）、FC 16（写多个寄存器）、FC 22（掩码写寄存器）、FC 23（读/写多个寄存器）
诊断操作：FC 7（读异常状态）、FC 8（诊断）、FC 11（获取通信事件计数器）、FC 12（获取通信事件日志）、FC 17（报告从站 ID）、FC 43（封装接口传输）

异常检测方法：五大核心检测维度

api-reference.md 将 Modbus 流量异常归纳为五大类，每类都有明确的触发条件与严重级别：

异常类型	检测条件	严重级别
时序偏差（Timing deviation）	轮询间隔超出容差范围	MEDIUM-HIGH
过量读取（Excessive read）	读取数量超过协议上限	HIGH
非法功能码（Invalid function code）	不在标准功能码集合中	HIGH
Modbus 扫描（Modbus scan）	同一来源使用超过 5 种不同功能码	HIGH
寄存器范围违规（Register range violation）	地址超出配置范围	MEDIUM

其中"Modbus 扫描"规则在scripts/agent.py的detect_scan_patterns()中有更细致的实现：不仅统计单一来源的功能码种类数（unique_fcs > 5即告警），还会检查是否同时出现 FC 17（Report Slave ID）与 FC 43（Encapsulated Interface Transport）——这两者的组合是设备枚举（Device Enumeration）攻击的典型特征，攻击者借此批量识别网络中的 PLC/RTU 设备型号与能力。

Zeek Modbus 日志字段与解析

Zeek（原 Bro）内置 Modbus 协议分析器，可将 502 端口的 Modbus/TCP 流量解析为结构化日志。api-reference.md给出了 Zeekmodbus.log的标准字段定义：

#fields ts uid id.orig_h id.orig_p id.resp_h id.resp_p func exception quantity

各字段含义：

字段	含义
`ts`	事件时间戳
`uid`	Zeek 连接唯一标识
`id.orig_h`/`id.orig_p`	源 IP 与源端口
`id.resp_h`/`id.resp_p`	目的 IP 与目的端口
`func`	Modbus 功能码
`exception`	异常响应码
`quantity`	读/写操作的数量字段

scripts/agent.py中的parse_modbus_log()专门解析这种 TSV 格式的 Zeek 日志：跳过所有以#开头的行（包括#fields头），将后续行按 Tab 分割并与字段头对齐组装成字典。这意味着你可以把 Zeek 采集的现成日志直接喂给检测脚本，无需重新抓包，极大降低了部署成本。

Suricata Modbus 检测规则

对于希望在网络边界做实时检测的场景，Suricata 提供了modbus关键字，可在 502 端口上直接对 PDU 进行语义级匹配。api-reference.md给出了两条可直接落地的规则：

alert modbus any any -> any 502 (msg:"Modbus Invalid Function Code"; \ modbus: function !1,!2,!3,!4,!5,!6,!15,!16; sid:4000001;) alert modbus any any -> any 502 (msg:"Modbus Excessive Register Read"; \ modbus: function 3; modbus: quantity > 125; sid:4000002;)

规则解析：

第一条（sid:4000001）：匹配任何不在标准集合 {1,2,3,4,5,6,15,16} 内的功能码，用于发现非法功能码请求。!前缀表示取反，即"功能码不是这些值"。
第二条（sid:4000002）：匹配 FC 3（读保持寄存器）且读取数量大于 125 的请求，直接对应协议硬性限制表中的寄存器读取上限。

这种基于 Suricata 的检测方式与 Python 脚本形成互补：Suricata 负责线速实时告警，Python 分析器负责事后深度审计与基线比对。相关技能 detecting-modbus-command-injection-attacks 还提供了针对写功能码的 Suricata 规则（如对 FC 5、FC 16 单独告警），可作为功能码白名单的补充参考。

基于 Scapy 的深度包检测

当需要从原始 pcap 数据包出发进行灵活分析时，Scapy 提供了ModbusADURequest层，可直接解析 Modbus 应用数据单元：

from scapy.contrib.modbus import ModbusADURequest from scapy.all import rdpcap pkts = rdpcap("modbus.pcap") for pkt in pkts: if pkt.haslayer(ModbusADURequest): print(f"FC={pkt.funcCode} Len={pkt.len}")

这段代码遍历 pcap 中所有包含 Modbus 请求层的报文，提取功能码（funcCode）与长度（len）。注意，scripts/agent.py的MODBUS_FUNCTIONS字典仅覆盖 {1,2,3,4,5,6,15,16} 这 8 个核心功能码，因此任何func值不在该集合内的请求都会被detect_register_anomalies()标记为invalid_function_code——这实际上把"标准功能码集合"作为了隐式的白名单。

基线监控：基于统计模型的时序异常检测

OT 环境与 IT 环境最大的差异在于其流量具有高度确定性：PLC 的轮询周期通常是固定的（如每 1 秒一次）。这一特性使得时序分析成为检测异常行为（如被植入恶意轮询、扫描器探测、中间人篡改）的高效手段。

api-reference.md给出了基线监控的核心思路：

# Expected polling behavior expected_interval = 1.0 # seconds tolerance = 0.5 # Alert if interval < 0.5s or > 3.0s

即：以 1.0 秒为期望轮询间隔，0.5 秒为容差，任何短于 0.5 秒或长于 3.0 秒的间隔都触发告警。scripts/agent.py的detect_timing_anomalies()在此基础上做了更精细的分级：

间隔小于expected_interval - tolerance→HIGH（轮询过频，可能是扫描或重放）
间隔大于expected_interval * 3→MEDIUM（轮询中断，可能是从站异常或通信被切断）

而 SKILL.md 中完整的ModbusAnomalyDetector类采用了更严格的统计学方法——z-score 检验：当会话的间隔样本数超过 10 个时，计算当前间隔相对基线均值与标准差的 z 分数，若z_score > 5.0则判定为TIMING_ANOMALY。相比固定阈值，z-score 方法能自适应不同轮询周期的从站设备，误报率更低。基线数据通过load_baseline()从 JSON 文件加载，其中包含polling_interval_avg_sec与polling_interval_stddev字段，以及allowed_function_codes允许列表——这对应了"最小 1-2 周正常流量基线采集"的前置要求。

CLI 用法与规则引擎实现

api-reference.md提供了检测脚本的命令行接口：

python agent.py --modbus-log modbus.log python agent.py --modbus-log modbus.log --expected-interval 2.0

--modbus-log指定 Zeek 导出的 modbus.log 文件（必填），--expected-interval用于覆盖默认的 1.0 秒轮询期望间隔。脚本会依次执行三类检测并输出 JSON 报告：

python scripts/agent.py --modbus-log modbus.log --expected-interval 2.0

输出结构包含timestamp、total_events、findings与total_findings，其中每条finding携带type、pair、severity、source及触发详情，便于后续接入 SIEM 或生成工单。

在 pcap 分析场景下，SKILL.md 中内嵌的完整实现还提供了六个深度检测规则，它们共同构成了一个可运行的异常检测引擎：

UNAUTHORIZED_CLIENT（严重级）：请求来源 IP 不在set_authorized_clients()配置的授权主站列表中，映射 MITRE ATT&CKT0886 Remote Services。
UNAUTHORIZED_FUNCTION_CODE（写操作严重级/其余高级）：功能码不在该会话的允许列表中；写类功能码（FC 5/6/15/16/22/23）违规被判定为严重级，映射T0855 Unauthorized Command Message。
WRITE_OPERATION（高级）：任何写操作都会被记录，并提取目标寄存器地址，映射T0836 Modify Parameter。
TIMING_ANOMALY（中级）：z-score 大于 5.0 的轮询间隔偏差，映射T0831 Manipulation of Control。
PROTOCOL_VIOLATION（高级）：MBAP 头中的协议 ID 不为 0（标准规定必须为 0x0000），映射T0830 Man in the Middle。
BROADCAST_WRITE（严重级）：单元 ID 为 0 且功能码为写操作，广播写会影响所有从站设备，映射T0855 Unauthorized Command Message。

从源码结构看，检测引擎以ModbusSession为粒度维护状态（已见功能码计数、寄存器地址集合、最近 500 个轮询间隔、请求与写入计数），process_packet()通过解析 MBAP 头的struct.unpack(">H", ...)大端序字段（事务 ID、协议 ID、长度、单元 ID、功能码）来逐包判定请求方向与内容，仅分析主站发往 502 端口的请求报文。

报告输出格式

检测完成后，SKILL.md 定义了标准化的报告结构，便于直接对接 SOC 事件流：

Modbus Protocol Anomaly Detection Report ========================================== Capture Period: YYYY-MM-DD to YYYY-MM-DD Packets Analyzed: [N] Sessions: [N] ANOMALIES: [N] UNAUTHORIZED_CLIENT: [N] UNAUTHORIZED_FUNCTION_CODE: [N] WRITE_OPERATION: [N] TIMING_ANOMALY: [N] BROADCAST_WRITE: [N]

内置的generate_report()会按严重级别（critical/high/medium/low）与异常类型分别统计，并输出 Top 15 异常明细，包括时间戳、异常类型、源/目的 IP、单元 ID、功能码与详细描述，为取证调查提供可直接引用的证据链。

适用场景、边界与框架映射

该检测方案适用于以下 OT 安全场景：

在 OT 环境部署 Modbus 专用入侵检测（需网络 SPAN/TAP 镜像 502 端口流量）
为确定性的 Modbus 轮询模式建立基线模型（建议采集 1-2 周正常流量）
调查 OT 监控工具标记的可疑 Modbus 流量
在工业防火墙上实现功能码白名单
检测可能操纵工艺设定值的未授权 Modbus 写命令

使用边界（SKILL.md 明确声明）：本方案不适用于端到端加密 Modbus 通信（Modbus 本身无原生安全机制，防火墙级防护请参考 implementing-network-segmentation-for-ot）；不适用于多协议统一监控（请参考 detecting-anomalies-in-industrial-control-systems）；也不适用于对 Modbus 实现的主动模糊测试（请参考 performing-plc-firmware-security-analysis）。

从框架覆盖角度看，该技能的元数据（SKILL.md 的 frontmatter）映射了 MITRE ATT&CK 的 T1078（有效账户）、T1190（面向公网的漏洞利用）、T1059（命令与脚本解释器）、T0816（面向设备的远程利用）与 T0836（修改参数），以及 NIST CSF 的 PR.IR-01、DE.CM-01、ID.AM-05、GV.OC-02 与 MITRE ATLAS 的 AML.T0070、AML.T0066、AML.T0082，与仓库 ATTACK_COVERAGE.md 及 MITRE ATT&CK 覆盖统计中的映射体系一致，可直接纳入组织的合规度量与检测覆盖审计。

总结

Modbus 协议异常检测的关键在于"以确定性对抗异常"：协议硬性限制（读取量、单元 ID、PDU 大小）提供了越界行为的客观判据，功能码语义（读/写/诊断）提供了操作意图的分级依据，而 OT 流量天然的轮询规律则让统计基线（固定阈值或 z-score）成为发现异常的最强信号。通过 api-reference.md 中的协议限制表、五大检测维度、Zeek 日志字段、Suricata 规则、Scapy 分析代码与基线监控逻辑，配合 scripts/agent.py 中可直接运行的检测实现，你可以在 SPAN/TAP 镜像的 502 端口流量上快速搭建一套覆盖实时告警与深度审计的 OT 侧 Modbus 入侵检测能力。

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

企业官网建设流程全解析