detecting-modbus-protocol-anomalies
作者 mukul975detecting-modbus-protocol-anomalies 可帮助检测 OT 和 ICS 网络中的可疑 Modbus/TCP 与 Modbus RTU 行为，包括无效功能码、越界寄存器访问、异常轮询时序、未经授权的写入以及格式异常的数据帧。适用于安全审计和基于证据的初步分诊。
该技能得分 78/100，说明它是面向需要 Modbus 专项异常检测指导用户的可靠候选项。仓库提供了足够的工作流细节、协议限制说明和可运行的支持材料，足以支撑安装；不过，在适配到具体 OT 环境时，用户仍需做一定的实施判断。
- 明确列出了针对 Modbus 的 OT 场景，包括功能码监控、寄存器校验、时序分析、未授权客户端检测以及格式异常数据帧检查。
- 包含可直接用于操作的资源：Python 脚本、Zeek/Suricata 示例，以及带有协议限制和日志字段说明的 API 参考。
- 技能明确说明了适用场景与不适用场景，有助于提升触发准确性，并减少智能体的猜测成本。
- 该技能更适合检测与分析流程；它并未提供完整的端到端 Modbus 安全处置或修复自动化能力。
- SKILL.md 中没有安装命令，因此用户可能需要结合脚本和参考文件自行推断安装与执行步骤。
detecting-modbus-protocol-anomalies 技能概览
这个技能适合做什么
detecting-modbus-protocol-anomalies 技能可以帮助你在 OT 和 ICS 网络中识别可疑的 Modbus/TCP 或 Modbus RTU 行为：无效功能码、越界寄存器访问、异常轮询节奏、未授权写入，以及畸形报文。它非常适合需要实用检测流程的 Security Audit 场景，而不是想先补一整套 Modbus 基础知识的场景。
适合谁使用
如果你是安全工程师、OT 分析师，或者负责验证 Modbus 流量是否符合已知正常行为的防守方，就可以使用 detecting-modbus-protocol-anomalies 技能。它最适合你已经有了抓包、Zeek 日志、Suricata 告警，或可重复的轮询基线，并且需要判断哪些行为属于异常。
它的不同之处
这个技能不只是一个提示词包装器。它把协议限制、检测启发式方法，以及围绕 Zeek、Suricata 和 Python 分析的示例工具组合在一起。相比泛泛的“分析这段流量”提示，它更能直接落地，尤其适合你希望模型基于具体的 Modbus 限制和日志字段来推理的时候。
如何使用 detecting-modbus-protocol-anomalies 技能
安装并加载上下文
标准安装时，先使用仓库中的 skill 路径，然后优先阅读核心指令文件：
npx skills add mukul975/Anthropic-Cybersecurity-Skills --skill detecting-modbus-protocol-anomalies
接着，在真正开始任务前检查 SKILL.md、references/api-reference.md 和 scripts/agent.py。这些文件会告诉你这个技能预期使用哪些字段、限制和检测方法。
提供正确的输入
要让 detecting-modbus-protocol-anomalies usage 发挥作用，最好从一个范围明确、基于证据的提示开始。建议包含：
- 协议类型：Modbus/TCP 或 Modbus RTU
- 数据来源：pcap、Zeek log、Suricata alert 或导出的事件日志
- 设备角色：PLC、HMI、historian、engineering workstation
- 如果有的话，已知正常的轮询模式
- 你的目标：detect、triage、explain 或 draft rules
一个好的提示可以这样写：
Analyze this Modbus/TCP capture for timing anomalies, invalid function codes, and unauthorized write behavior. Use the limits in the repo, assume the PLC should only accept function codes 3 and 4 from the HMI, and call out any events that exceed protocol bounds.
更容易得到好结果的推荐流程
- 先从抓包或日志格式入手，不要一上来就下结论。
- 先让它给出简短的异常摘要。
- 再要求按事件逐条解释，并对应到 Modbus 限制。
- 如有需要，在分析之后再让它提供 Zeek 或 Suricata 规则思路。
如果你的任务是面向审计的 detecting-modbus-protocol-anomalies guide，可以要求输出分成三类：已确认异常、可疑但可解释、正常基线行为。
先读哪些文件
优先阅读：
SKILL.md：了解预期的检测流程references/api-reference.md：查看协议阈值和示例规则逻辑scripts/agent.py：查看实际的解析与检测方式
detecting-modbus-protocol-anomalies 技能常见问题
这只适用于 Modbus/TCP 吗？
不是。这个技能同时覆盖 Modbus/TCP 和 Modbus RTU，但实际示例更偏向日志和报文分析。如果你手头只有未经解码的原始串口抓包，就要提供更多预处理细节。
没有 OT 安全经验也能用吗？
可以，只要你能说明流量来源和设备的预期行为。这个技能对分析类任务比较友好，但如果你已经不了解 Modbus 功能码和资产角色，就不适合直接拿来做生产环境响应。
它和通用提示词有什么区别？
detecting-modbus-protocol-anomalies skill 更有用，因为它会把模型锚定到协议特定的阈值、检测方法和字段名称上。通用提示词往往会漏掉 Modbus 的限制，比如读数量上限或功能码 allowlist。
什么时候不该用它？
不要把 detecting-modbus-protocol-anomalies 用在端到端 Modbus 加密、宽泛的网络分段设计，或者非 Modbus 工业协议上。如果你根本没有流量数据，只是想写策略、又没有任何报文或日志证据，它也不合适。
如何改进 detecting-modbus-protocol-anomalies 技能
不要只给告警，要给基线
最大的效果提升来自提供预期轮询间隔、允许的功能码，以及正常的源-目的地址对。没有基线时，这个技能依然能识别明显的协议违规，但在区分漂移和攻击方面会弱很多。
明确你想要的判定规则
如果你希望输出能支撑 Security Audit，就直接说明什么算可操作。比如：
- 标记任何不在 1, 2, 3, 4, 5, 6, 15, 16 之外的功能码
- 对读取寄存器数量超过 125 的情况告警
- 将新的客户端 IP 视为未授权，除非已加入白名单
这样就把任务从“总结流量”变成了“应用策略”。
注意常见失败模式
最常见的问题是缺少设备上下文、混淆 Modbus/TCP 和 RTU 假设，以及在日志字段不足时仍要求检测。如果第一轮输出过于笼统，先补强输入，再要求更长的解释。
从证据迭代到规则
一个好的 detecting-modbus-protocol-anomalies install 决策，通常会在你测试一个样本文件、审阅推理过程之后，进一步发展成更成熟的工作流；随后再用更严格的阈值或自定义 allowlist 做第二轮验证。如果第一版答案已经接近目标，优先用具体资产、地址和功能码预期去细化提示，而不是直接要求更大范围的重新分析。