modbus-anomaly-detectionlisted

## When to Use - Monitoring a Modbus TCP segment for unauthorized write function codes. - Hunting for register scanning or a new master-slave pair on port 502. - Investigating operator reports of unexplained setpoint changes. - Hardening an existing IDS deployment that has no OT-specific rules. ## Prerequisites - Suricata 7.x. Verify with `suricata --build-info`. The `modbus` keyword requires libhtp-independent protocol support and a `stream.memcap` sized for the segment. - Zeek 5.x. Verify with `zeek --version`. - Baseline pair list from `passive-ot-network-discovery` (`modbus_profile.txt`, `hosts.csv`). - Site variables for the ruleset: `$PLC_SERVERS`, `$HMI_SERVERS`, `$UNIT_WHITELIST`. - Python 3.10 or newer for the triage script. - Credentials: none for analysis. IDS reload rights for deployment. - Authorization: segment owner sign-off for rule deployment. Live test traffic is gated. - Upstream skills: `passive-ot-network-discovery` for the baseline pair list. ### Safety This skill is passive by default. Active steps are gated in the Workflow section. - Passive. Authors rules and analyzes captures and IDS logs. Safe to run during normal operations. ## Workflow 1. Extract the authorized master-slave pairs from the discovery baseline: `tshark -r baseline.pcapng -Y "modbus" -T fields -e ip.src -e ip.dst -e modbus.unit_id | sort -u > pairs.txt` 2. Author the ruleset from `references/detection-rules.md`. Fill the site variables. Every write-code rule uses the native