Modbus 协议异常检测实战指南基于 Zeek、Suricata 与 Python 的 OT 网络入侵检测方案【免费下载链接】Anthropic-Cybersecurity-Skills817 structured cybersecurity skills for AI agents · Mapped to 6 frameworks: MITRE ATTCK, 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-SkillsModbus 是工业控制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与PDUProtocol Data Unit组成。其中 MBAP 头包含事务 ID、协议 ID固定为 0x0000、长度字段与单元 IDUnit IDPDU 则承载功能码与数据。api-reference.md 中明确给出了判定读取量是否越界所依赖的协议极限值这是检测逻辑正确性的根基参数最大值线圈读取数量Coil read quantity2000寄存器读取数量Register read quantity125寄存器写入数量Register write quantity123单元 ID 范围Unit ID range1-247PDU 大小PDU size253 字节这些数值在检测脚本中被直接引用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不在标准功能码集合中HIGHModbus 扫描Modbus scan同一来源使用超过 5 种不同功能码HIGH寄存器范围违规Register range violation地址超出配置范围MEDIUM其中Modbus 扫描规则在scripts/agent.py的detect_scan_patterns()中有更细致的实现不仅统计单一来源的功能码种类数unique_fcs 5即告警还会检查是否同时出现 FC 17Report Slave ID与 FC 43Encapsulated 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事件时间戳uidZeek 连接唯一标识id.orig_h/id.orig_p源 IP 与源端口id.resp_h/id.resp_p目的 IP 与目的端口funcModbus 功能码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(fFC{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 ATTCKT0886 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 ATTCK 的 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 ATTCK 覆盖统计 中的映射体系一致可直接纳入组织的合规度量与检测覆盖审计。总结Modbus 协议异常检测的关键在于以确定性对抗异常协议硬性限制读取量、单元 ID、PDU 大小提供了越界行为的客观判据功能码语义读/写/诊断提供了操作意图的分级依据而 OT 流量天然的轮询规律则让统计基线固定阈值或 z-score成为发现异常的最强信号。通过 api-reference.md 中的协议限制表、五大检测维度、Zeek 日志字段、Suricata 规则、Scapy 分析代码与基线监控逻辑配合 scripts/agent.py 中可直接运行的检测实现你可以在 SPAN/TAP 镜像的 502 端口流量上快速搭建一套覆盖实时告警与深度审计的 OT 侧 Modbus 入侵检测能力。【免费下载链接】Anthropic-Cybersecurity-Skills817 structured cybersecurity skills for AI agents · Mapped to 6 frameworks: MITRE ATTCK, 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Modbus 协议异常检测实战指南基于 Zeek、Suricata 与 Python 的 OT 网络入侵检测方案【免费下载链接】Anthropic-Cybersecurity-Skills817 structured cybersecurity skills for AI agents · Mapped to 6 frameworks: MITRE ATTCK, 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-SkillsModbus 是工业控制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与PDUProtocol Data Unit组成。其中 MBAP 头包含事务 ID、协议 ID固定为 0x0000、长度字段与单元 IDUnit IDPDU 则承载功能码与数据。api-reference.md 中明确给出了判定读取量是否越界所依赖的协议极限值这是检测逻辑正确性的根基参数最大值线圈读取数量Coil read quantity2000寄存器读取数量Register read quantity125寄存器写入数量Register write quantity123单元 ID 范围Unit ID range1-247PDU 大小PDU size253 字节这些数值在检测脚本中被直接引用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不在标准功能码集合中HIGHModbus 扫描Modbus scan同一来源使用超过 5 种不同功能码HIGH寄存器范围违规Register range violation地址超出配置范围MEDIUM其中Modbus 扫描规则在scripts/agent.py的detect_scan_patterns()中有更细致的实现不仅统计单一来源的功能码种类数unique_fcs 5即告警还会检查是否同时出现 FC 17Report Slave ID与 FC 43Encapsulated 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事件时间戳uidZeek 连接唯一标识id.orig_h/id.orig_p源 IP 与源端口id.resp_h/id.resp_p目的 IP 与目的端口funcModbus 功能码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(fFC{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 ATTCKT0886 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 ATTCK 的 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 ATTCK 覆盖统计 中的映射体系一致可直接纳入组织的合规度量与检测覆盖审计。总结Modbus 协议异常检测的关键在于以确定性对抗异常协议硬性限制读取量、单元 ID、PDU 大小提供了越界行为的客观判据功能码语义读/写/诊断提供了操作意图的分级依据而 OT 流量天然的轮询规律则让统计基线固定阈值或 z-score成为发现异常的最强信号。通过 api-reference.md 中的协议限制表、五大检测维度、Zeek 日志字段、Suricata 规则、Scapy 分析代码与基线监控逻辑配合 scripts/agent.py 中可直接运行的检测实现你可以在 SPAN/TAP 镜像的 502 端口流量上快速搭建一套覆盖实时告警与深度审计的 OT 侧 Modbus 入侵检测能力。【免费下载链接】Anthropic-Cybersecurity-Skills817 structured cybersecurity skills for AI agents · Mapped to 6 frameworks: MITRE ATTCK, 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
