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 行為：無效的 function code、超出範圍的暫存器存取、異常的輪詢時間、未授權寫入，以及格式異常的封包。當你需要的是實用的偵測工作流程，而不是一篇全面的 Modbus 入門時，它很適合用於 Security Audit。
適合哪些人使用
如果你是資安工程師、OT 分析師，或是正在驗證 Modbus 流量是否符合已知良好行為的防守方，建議使用 detecting-modbus-protocol-anomalies 技能。當你已經有封包擷取、Zeek logs、Suricata alerts，或可重複的輪詢基準，並且需要判斷哪些行為屬於異常時，這個技能最有價值。
這個技能的差異在哪裡
這個技能不只是把 prompt 包一層而已。它把協定限制、偵測 heuristics，以及圍繞 Zeek、Suricata 和 Python 分析的範例工具整合在一起。相較於通用的「分析這段流量」prompt，它更能落地，特別是在你希望模型根據具體的 Modbus 限制與 log 欄位來推理時。
如何使用 detecting-modbus-protocol-anomalies 技能
安裝並載入脈絡
標準安裝時，請先使用 repository skill path，然後先閱讀核心指令檔：
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 有好的效果，起手式應該是精準、以證據為本的 prompt。請包含：
- 協定類型：Modbus/TCP 或 Modbus RTU
- 資料來源：pcap、Zeek log、Suricata alert，或匯出的事件 log
- 裝置角色：PLC、HMI、historian、engineering workstation
- 已知良好的輪詢模式，如果你有的話
- 你的問題：偵測、初步分流、解釋，或草擬規則
一個強而有力的 prompt 會像這樣：
分析這段 Modbus/TCP capture 的時間異常、無效 function codes，以及未授權寫入行為。請使用 repo 內的限制，假設 PLC 只應接受來自 HMI 的 function codes 3 和 4，並指出任何超出協定界限的事件。
建議的工作流程，結果會更好
- 先從 capture 或 log 格式開始，不要先下結論。
- 先要求一個簡短的異常摘要。
- 再要求逐筆事件的推理，並連結到 Modbus 的限制。
- 若有需要，在分析完成後再請它提供 Zeek 或 Suricata rule 的構想。
如果你的任務是要產出一份 detecting-modbus-protocol-anomalies guide 供稽核使用，建議把輸出分成三類：已確認異常、可疑但可解釋、以及正常基準行為。
先讀哪些檔案
優先閱讀：
SKILL.md：了解預期的偵測流程references/api-reference.md：查看協定閾值與範例 rule 邏輯scripts/agent.py：理解實際的解析與偵測方法
detecting-modbus-protocol-anomalies 技能 FAQ
這個技能只適用於 Modbus/TCP 嗎？
不是。這個技能同時涵蓋 Modbus/TCP 與 Modbus RTU，但實際範例更偏向 log 與封包分析。如果你手上只有原始序列埠擷取資料，沒有解碼脈絡，通常需要提供更多前處理細節。
沒有 OT 資安經驗也能用嗎？
可以，只要你能描述流量來源與預期的裝置行為。這個技能對分析任務來說對新手友善，但若你要直接拿去處理 production response，而你還不理解 Modbus function codes 與資產角色，就不算是新手安全。
這和一般 prompt 有什麼不同？
detecting-modbus-protocol-anomalies skill 更有用，因為它會把模型錨定在協定特定的閾值、偵測方法與欄位名稱上。一般 prompt 常常會漏掉 Modbus 的限制，例如讀取數量上限或 function-code allowlist。
什麼情況下不該用它？
不要把 detecting-modbus-protocol-anomalies 用在端到端的 Modbus 加密、廣泛的網路分段設計，或非 Modbus 的工業協定上。如果你根本沒有流量資料，只是想寫政策文字、而沒有封包或 log 證據，這個技能也不適合。
如何改進 detecting-modbus-protocol-anomalies 技能
提供基準，不要只丟 alerts
品質提升最大的關鍵，是把預期的輪詢間隔、允許的 function codes，以及正常的來源與目的端配對一起提供給模型。沒有基準時，這個技能仍然能抓出明顯的協定違規，但在區分漂移與攻擊時會弱很多。
說清楚你要它依什麼規則做決策
如果你希望輸出能支援 Security Audit，就直接說明什麼算是可行動的結果。例如：
- 將任何超出 1、2、3、4、5、6、15、16 的 function code 標記出來
- 對超過 125 的 register reads 發出警示
- 除非已列入白名單，否則將新的 client IP 視為未授權
這樣任務就會從「摘要流量」變成「套用政策」。
留意常見失敗模式
最常見的錯誤包括：缺少裝置脈絡、混淆 Modbus/TCP 與 RTU 的假設、以及在 log 欄位不足時仍要求偵測。如果第一次結果太模糊，先改善輸入，再要求更長的解釋。
從證據迭代到規則
一個強而有力的 detecting-modbus-protocol-anomalies install 決策，通常會在你先測一個樣本檔、檢視推理過程，然後再用更嚴格的閾值或自訂 allowlist 做第二輪時，變成真正好用的工作流程。如果第一次答案已經接近需求，請改用更具體的資產、位址與 function-code 預期來微調 prompt，而不是直接要求它做更大範圍的重新分析。