写在前面的话
Modbus 不安全。这不是什么新发现——1979 年 Modicon 设计这个프로토콜的时候，连互联网都没普及，更不会想到有一天 PLC 会通过 4G 模块直接暴露在公网上。那时候的威胁模型是「电缆会不会被老鼠咬断」，不是「有没有人在 502 포트上做中间人攻击」。
但这不代表 Modbus 不能用。一个프로토콜的문제和엔지니어링现场的문제是两回事。在机柜里、在被隔离的控制网上、在一对一物理연결的 RS-485 总线上，Modbus 明文的缺点几乎不构成威胁。문제出在什么时候？出在你把那根 RS-485 线接上一个 4G DTU，然后 DTU 配了个公网 IP，然后默认密码还没改。
这篇글不讲安全理论，讲九个你我都可能遇到的情况——不是「如果」而是「已经发生过」。然后我们讨论在不换设备、不推翻现有架构的前提下，怎么把风险降到一个可接受的水平。
Modbus 到底缺了什么
先搞清楚 Modbus 缺失的到底是什么。不是「不安全」三个字就能概括的。
**没有인증机制。** Modbus TCP 的 MBAP 头里有个 Unit ID 필드，1 바이트。这玩意儿是设备주소，不是身份凭证。任何能建立 TCP 연결到 502 포트的人，都可以보내기기능 코드 0x03 读유지 레지스터、기능 코드 0x06 写单个레지스터。试试看：telnet 过去发 `x00x01x00x00x00x06x01x03x00x00x00x01` ——只要设备在线，它就会返回레지스터데이터。不需要密码，不需要 token，不需要任何形式的身份验证。
拿기능 코드 0x05 写单个코일来说。这一帧只有 12 바이트：
| TX ID | Proto | Len | UID | FC | Coil Addr | Value |
|---------|-------|------|-----|-----|-----------|----------|
| 00 01 | 00 00 | 00 06| 01 | 05 | 00 01 | FF 00 |这个帧的意思是：把设备 01 的코일주소 0001 置为 ON。如果你是一个合法的 SCADA 클라이언트，这没문제。如果你是一个连上 502 포트的陌生人，这也是有效的。设备不会区别对待。
**没有加密。** TCP 载荷里的每一个바이트都是明文。Wireshark 用 `modbus` 过滤器可以直接看到事务 ID、기능 코드、레지스터주소、데이터值。抓一包 Modbus TCP 流量等于拿到整套레지스터 매핑表。一个有心人看你工厂的 Modbus 流量五分钟，能画出所有设备的레지스터图。
**CRC 验不了篡改。** Modbus RTU 的 CRC-16 和 Modbus TCP 依赖的 TCP 체크섬，设计目的都是检测物理传输层的比特错误——线缆소음、电磁干扰导致的데이터翻转。它们不是密码学哈希，不能防刻意篡改。攻击者截获一帧，改레지스터 값，重新계산 CRC，转发出去，슬레이브无法区分这一帧是不是被改过。
看一下攻击流：
原始帧 (마스터→슬레이브): 01 06 00 01 17 70 D8 0B (写유지 레지스터주소0001=6000, 对应50Hz)
截获→篡改后帧: 01 06 00 01 02 58 C9 C3 (改成600, 对应5Hz)CRC 变了，但攻击者也算得出来。슬레이브收到后照样执行。变频器上限频率从 50Hz 变成了 5Hz——모터没烧，但泵不出水了。
**没有防重放。** Modbus 没有时间戳、没有시퀀스号保护（MBAP 里的事务 ID 只是用来일치请求与响应，不是安全순번）。同一帧可以无限重放。上个月你给风机发了停机指令，攻击者录下来，下个月再发一次——解码完全一样，设备照样停。
九个真实风险시나리오
不是说理论上的漏洞，是下面这些事情已经在不同现场发生过。有些是我自己碰到的，有些是同行聊起的，有些是公开보고서里的。
시나리오 1：Modbus TCP 直连公网——502 포트暴露在 Shodan 上
Shodan 上搜 `port:502`，结果数一直在涨。两三年前公开데이터大概六七千台，现在早就过万了。这些设备里有 PLC、RTU、게이트웨이、智能电表，有的跑在데이터中心，有的挂在水厂 SCADA 的主干网上。Shodan 还会抓取设备返回的 Modbus 响应，直接표시 장치型号、固件버전。
什么都不用破解。你把设备 IP 配成公网주소，502 포트没做任何 ACL——这就跟把车间大门开着、设备操作面板对着马路一样。
nmap 扫一下更直观：
nmap -p 502 --script modbus-discover <target_ip>这个 NSE 스크립트会尝试읽기设备信息。如果设备响应了 0x11（보고서슬레이브 ID）或 0x2B（设备识别），它直接告诉你制造商、产品代码、固件버전。零门槛。
시나리오 2：水厂/变电站 Modbus RTU 通过 4G DTU 透明传输上云
现场用的是 RS-485 跑 Modbus RTU，几十台仪表挂在总线上。为了远程监控，加了个 4G DTU，설정成透明传输모드——DTU 把시리얼 포트데이터打包成 TCP 包发到云端服务器。公网 IP，포트 8899（不是 502，但差别不大）。
문제来了：DTU 和云服务器之间的链路是明文 TCP。任何能在这段链路做 MITM（中间人）的人——不一定是国家级攻击者，可能是运营商内部人员、4G 信号劫持设备、或者同基站下的其他设备利用 LTE 네트워크漏洞——都可以：
1. 监听所有 Modbus RTU 流量，拿到完整的레지스터 매핑和实时데이터 2. 注入伪造的写指令（기능 코드 0x06 或 0x10），修改设备매개변수 3. 甚至向슬레이브보내기广播指令（주소 0x00），同时控制总线上所有设备
去年有个水厂的案例：攻击者通过公开的클라우드 플랫폼 IP 连上了 DTU 的后台管理포트（默认密码 admin/admin），直接看到整个泵站的控制界面。万幸只是看了，没操作。
시나리오 3：Modbus 转 MQTT 게이트웨이——MQTT 侧裸奔
这种架构现在很常见：Modbus RTU 设备 → 게이트웨이做프로토콜转换 → MQTT Broker（云端或本地）→ 上层적용消费。
게이트웨이把레지스터데이터映射成 MQTT Topic，比如 `/plant1/pump1/pressure` → 유지 레지스터 40001 的值。这个设计本身没문제——MQTT 的发布/订阅模型确实比 Modbus 轮询更适合云端시나리오。
문제出在 MQTT 侧：很多部署没开 TLS，Broker 不需要클라이언트证书인증，Topic 没有 ACL。攻击者只要知道 Broker 주소和포트（通常 1883，明文 MQTT 默认포트），用 `mosquitto_sub` 就能订阅所有 Topic：
mosquitto_sub -h <broker_ip> -p 1883 -t "#" -v`#` 是 MQTT 的多级通配符，订阅所有 Topic。几秒钟后，整个工厂的온도、压力、电表读数、设备状态전체到手。如果 Broker 还允许发布（很多게이트웨이的双向控制功能依赖这个），攻击者可以直接向控制 Topic 보내기指令：
mosquitto_pub -h <broker_ip> -p 1883 -t "/plant1/pump1/control" -m "STOP"시나리오 4：工厂内网 Wi-Fi 上的 Modbus TCP 被嗅探
不少工厂为了布线方便，把 Modbus TCP 设备和 SCADA 服务器挂在同一个 Wi-Fi 네트워크上。Wi-Fi 密码写在设备标签上，贴在机柜外面——防君子不防小人。
内部员工（或者访客、维保人员、离职员工留下的设备）连上这个 Wi-Fi 后，Modbus TCP 流量全是广播域内的明文。Wireshark 抓包：
过滤器: modbus && tcp.port == 502抓个十分钟就能把所有设备的레지스터 매핑画出来。如果攻击者还想更进一步，ARP 欺骗把 SCADA 服务器的流量引到自己机器上，然后作为中间人转发——设备端的 Modbus 통신不会中断，SCADA 界面一切正常，后台的데이터已经在被实时窃取。
시나리오 5：빌딩 자동제어 BACnet-Modbus 게이트웨이설정页未设密码
빌딩 자동제어系统里，BACnet 和 Modbus 经常会混在一个게이트웨이上。比如 Delta Controls、Siemens Desigo 的一些게이트웨이产品，既有 Modbus RTU 인터페이스接仪表，又有 BACnet/IP 인터페이스上 BMS。
这些게이트웨이通常会提供一个 Web 설정页面。默认情况下，很多통합商上线时只改 IP 주소、설정好레지스터 매핑，密码还是出厂默认——或者压根没设密码。Web 页面暴露了完整的레지스터 매핑表、设备주소、기능 코드설정、甚至在线디버깅功能——可以直接在里面发 Modbus 读写指令。
Shodan 上搜 `BACnet gateway` 或特定게이트웨이型号的产品页面，能找到不少这样的入口。进去了不只是看데이터——能直接在 Web 界面上改공조(HVAC)阀门开度、设에어컨온도设定值、启停冷水机组。
시나리오 6：风电场 SCADA 的 Modbus 控制指令被重放
风电场 SCADA 系统通常用 Modbus TCP 和风机 PLC 통신。控制指令包括启停、桨距角调整、偏航控制、功率限制等。
2015 年乌克兰电网攻击事件之后，大家对 OT 安全总算开始重视。但风场的情况比较特殊——很多风场建在偏远地区，远程运维依赖 VPN 或专线，运维人员流动性大，VPN 账号管理经常跟不上。
如果一条「紧急停机」Modbus 指令（기능 코드 0x05，写某一个코일）在传输过程中被坏人截获——无论通过什么手段，可能是 VPN 클라이언트被控、可能是运维笔记本被植入木马、可能是内网横向移动——这个帧可以被저장下来。攻击者不需要理解 Modbus 프로토콜细节，不需要知道레지스터 매핑，只需要几个月后在夜间重放这个帧。风机收到后就会执行停机。
重放不挑时间、不挑目标。录一次，发一百次。而 Modbus 프로토콜原生没有任何机制能阻止这件事。
시나리오 7：OEM 设备默认설정被利用
OEM 设备厂商为了提高出货效率，所有的 PLC/RTU 用统一的슬레이브 주소（比如주소 01）、统一的기능 코드支持列表、甚至统一的레지스터 매핑。更糟糕的是，有些厂商在固件里写死了통신매개변수——没法改。
这在设备디버깅阶段很方便。但在实际部署以后，变成安全噩梦。
假设一个분산형光伏项目用了同一批逆变器，所有设备的슬레이브 주소都是 01，레지스터 매핑完全一样（40001=功率，40003=电压，40005=运行状态，40101=开关机控制）。攻击者攻破其中一台设备或者中间的네트워크节点，他等于拿到了所有设备的控制蓝图。别的设备不用重新侦察——레지스터 매핑完全是同一份。
시나리오 8：레지스터쓰기攻击——修改设备매개변수
这个시나리오最危险。Modbus 的유지 레지스터不光存测量데이터，还存设备매개변수。变频器上限频率、PID 매개변수、报警阈值、校准스케일 계수——都在레지스터里。能写레지스터的人就能改变设备的物理行为。
具体例子：
| 设备 | 레지스터주소 | 매개변수 | 正常值 | 恶意值 | 后果 |
|---|---|---|---|---|---|
| 变频器 | 40018 | 上限频率 | 5000 (=50Hz) | 500 (=5Hz) | 泵出水不足，产线停产 |
| 温控器 | 40005 | 目标온도 | 250 (=25.0℃) | 800 (=80.0℃) | 过温保护跳闸，或者反过来改低导致冻结 |
| 电表 | 40045 | 电流变比 | 100 | 1 | 电量데이터偏差百倍，能耗核算崩盘 |
| PLC | 40001 | 运行모드 | 1 (运行) | 0 (정지) | 直接让 PLC 정지执行逻辑 |
不需要做什么复杂攻击。nmap 的 modbus-discover 스크립트扫一遍拿到레지스터 매핑，然后 modbus-cli 或 pymodbus 直接往里写：
from pymodbus.client import ModbusTcpClient
client = ModbusTcpClient('192.168.1.100')
client.write_register(18, 500) # 把变频器上限频率改成5Hz四行代码。不需要任何权限。变频器收到了就执行。
시나리오 9：RS-485 总线物理接入——车间门没锁
RS-485 总线的物理安全性几乎是零。总线上的所有设备共享一对差分信号线（A+/B-），任何人在总线的任何位置接上一个 USB-RS485 컨버터，就能：
1. **被动监听**：把所有 RS-485 流量记录下来，离线分析 2. **主动注入**：伪装成마스터或者슬레이브보내기指令 3. **总线干扰**：持续보내기데이터造成总线冲突，DDoS 整个네트워크
一个 USB-RS485 컨버터淘宝十几块钱。一个机智的攻击者在夜班巡检时，趁人不注意把컨버터藏在线槽里，加一个微型 4G 模块做远程接入。谁能发现？没有人会定期检查 RS-485 总线的电气特性。
关键是 RS-485 总线的设计本身就是多站共享介质，不需要交换机、不需要포트接入许可。物理上挂上去就是네트워크的一员。Modbus RTU 的슬레이브 주소只有 1-247，攻击者可以枚举所有주소，逐个探测设备유형。
分层防御：从物理层到监控层的完整方案
讲完九个시나리오之后，一个自然而然的结论是：不能靠单一手段解决 Modbus 安全문제。它的문제分布在프로토콜栈的每一层，防护也得跟着分。
下面这些方案不是在讲理论——每一条都有对应的产品、오픈소스도구或者설정方法。按自己的现场条件挑着用。
네트워크层：把 Modbus 关进笼子
**第一条铁律：Modbus 502 포트绝对不要直接暴露在公网上。** 这句话怎么强调都不过分。如果你的设备供应商跟你说「直接把 IP 配成公网的，我们远程维护方便」——换供应商。
具体操作：
**防火墙 ACL 白名单。** 不是黑名单，是白名单。502 포트只允许指定 IP（SCADA 服务器、데이터采集게이트웨이）访问。Linux iptables 两行搞定：
iptables -A INPUT -p tcp --dport 502 -s 192.168.10.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 502 -j DROP如果你的设备 CPU 跑不动 iptables，用硬件防火墙（几百块的小型工业防火墙就行），或者至少在路由器/三层交换机上做 ACL。
**VLAN 隔离。** 把 Modbus 设备放在独立的 VLAN 里，和办公네트워크、Wi-Fi 네트워크、访客네트워크完全隔离。VLAN 间路由只放行 SCADA 服务器到 502 포트的流量，其他一概不路由。交换机포트上做 MAC 绑定，防止有人把设备拔了换自己的笔记本。
**VPN/IPsec 隧道。** 需要远程访问的시나리오，走 VPN 而不是把포트开到公网上。IPsec 或 WireGuard 都可以。OpenVPN 的설정不复杂：
# 服务端只允许 502 포트流量通过隧道
push "route 192.168.10.0 255.255.255.0"这保证了 Modbus 流量始终在加密隧道里传输。即使攻击者拦截了 VPN 链路，TLS/AES 加密也会让他拿不到明文。
传输层：Modbus 加 TLS 的方案
提到 Modbus 加 TLS，得先说现状：**Modbus Organization 在 2018 年 10 月发布了 Modbus/TCP Security 사양**。核心变化：默认포트从 502 改为 802，TLS 1.2 强制，X.509v3 证书做身份인증，同时引入基于角色的访问控制（Role-Based Access Control，RBAC）。
사양定义了四个角色：
| 角色 ID | 角色名 | 权限 |
|---|---|---|
| 0 | Administrator | 全기능 코드、全레지스터、设备管理 |
| 1 | Operator | 读写所有레지스터，不能改설정 |
| 2 | Engineer | 디버깅诊断权限 |
| 3 | Observer | 只读데이터，不能写 |
这彻底解决了 Modbus 无인증的문제——클라이언트必须持有有效证书才能建立 TLS 연결，证书中的角色필드决定了能执行哪些기능 코드。
但现实是，支持 802 포트的设备少得可怜。绝大多数存量设备只支持 502 明文。不换设备怎么加 TLS？
**stunnel 方案。** stunnel 是一个轻量的 TLS 代理，能把任意 TCP 연결封装到 TLS 隧道里。部署架构：
SCADA 클라이언트 → stunnel(本地127.0.0.1:1502) → TLS → stunnel(远程) → 设备(502)stunnel 설정很短：
# 클라이언트 stunnel.conf
[modbus-client]
client = yes
accept = 127.0.0.1:1502
connect = 192.168.10.1:802
verifyChain = yes
CAfile = /etc/stunnel/ca.pem
cert = /etc/stunnel/client.pem
key = /etc/stunnel/client.key
# 服务端 stunnel.conf
[modbus-server]
client = no
accept = 802
connect = 127.0.0.1:502
cert = /etc/stunnel/server.pem
key = /etc/stunnel/server.key
CAfile = /etc/stunnel/ca.pem
verifyChain = yes클라이언트软件连 `127.0.0.1:1502` 而不是直连设备的 502。中间的 TLS 加密对上层完全透明。stunnel 本身只有几百 KB，可以跑在嵌入式 Linux 게이트웨이、树莓派、甚至 OpenWrt 路由器上。
**注意：** stunnel 解决的是传输加密문제，不解决적용层인증문제。它保证了传输链路不被窃听和篡改，但一旦 TLS 隧道建好，Modbus 帧本身依然是明文——只是这个明文只在加密隧道和保护的内网之间传输。如果攻击者能进入内网并直接连设备的 502，stunnel 保护不了。
적용层：Modbus 安全代理/게이트웨이
如果你不能在每个设备端部署 stunnel，或者需要更细粒度的控制，在 Modbus 总线和上层적용之间加一个安全代理/게이트웨이是性价比最高的方案。
Moxa MGate 시리즈、Hilscher netTAP、Advantech ADAM-4570 这些工业게이트웨이都支持访问控制列表。你可以在게이트웨이上설정：
- 哪个 IP 可以访问哪些슬레이브 주소 - 允许哪些기능 코드通过 - 레지스터级读写控制——比如주소 40001-40050 只读，40051-40100 可读写 - 연결速率限制（防暴力轮询/DoS）
选型时看清楚：不是所有 Modbus 게이트웨이都支持安全策略。很多廉价게이트웨이只是做透传，ACL 功能在选型表里要找 `Access Control` 或 `Security Policy` 필드。
오픈소스方案也不是没有。用 pymodbus 写一个代理也就几百行代码：
# 简化版 Modbus 安全代理逻辑
ALLOWED_FUNCTION_CODES = {0x03, 0x04, 0x06, 0x10} # 只允许这些기능 코드
READ_ONLY_REGISTERS = range(40001, 40051) # 这个주소段只读
def proxy_handler(request):
if request.function_code not in ALLOWED_FUNCTION_CODES:
return exception_response(request.function_code, 0x01) # 非法기능 코드
if request.function_code in {0x06, 0x10}:
for addr in request.주소es:
if addr in READ_ONLY_REGISTERS:
return exception_response(request.function_code, 0x02) # 非法데이터주소
# 转发到实际设备
return forward_to_device(request)这几行挡掉了시나리오 8 里大部分레지스터쓰기攻击。
物理层：RS-485 总线的物理安全
物理安全听起来「低级」，但九个시나리오里至少三个和物理接入有关。
最低成本也能做的几件事：
1. **机柜上锁。** 不只是一个简单的钥匙锁——用电子门禁，记录谁什么时候开了哪个机柜。异常时间（凌晨两三点）的机柜开门=物理安全事件。 2. **RS-485 总线用带屏蔽的双绞线走线槽。** 线槽加封条，拆开有痕迹。不是防不住，是让攻击者留下证据。 3. **USB 포트禁用。** 工厂里的산업 제어机/HMI 不需要插 U 盘。BIOS 禁用 USB、Windows 组策略禁用可移动存储。有人插 USB-RS485 컨버터，系统不识别。 4. **总线终端电阻加防拆센서。** RS-485 总线两端各有一个 120Ω 终端电阻。如果一个电阻被제거（有人在线中间接了一个监听设备导致阻抗变化），总线的电气特性会变化——可以用总线分析仪检测。
花不了多少钱，但挡住 90% 的物理接入攻击足够了。
监控层：Modbus 流量异常检测
前面的所有措施都是「不让他进来」。但对「已经进来了」或者「合法用户做了不合法的事」的情况，你还需要检测能力。
Modbus 流量的异常特征很明确——正是因为프로토콜简单，异常更容易识别：
**轮询周期突变。** SCADA 系统通常以固定周期轮询设备（比如每秒一次）。如果某个슬레이브的请求频率突然从 1 次/秒变成 100 次/秒，大概率不是 SCADA 的行为。可能是有人在暴力扫描레지스터。
**非표준기능 코드出现。** 一个只用了 0x03（读유지 레지스터）和 0x06（写单个레지스터）的系统，突然出现 0x08（诊断）或 0x2B（设备识别）请求——这是侦察行为的典型特征。
**非工作时间流量。** 工厂停产时段（比如晚上 11 点到早上 6 点），Modbus 总线上不应该有大量读写指令。如果有，报警。
**异常기능 코드组合。** 短时间内出现 0x05（写单个코일）、0x06（写单个레지스터）、0x10（写多个레지스터）的密集组合，且目标주소跨越多个不相邻的区域——几乎可以确定是恶意操作。
오픈소스도구方面：
# Zeek (原Bro) 有 Modbus 프로토콜분석器
# 写一个检测스크립트放在 Zeek 的策略目录Wireshark + Modbus 插件可以用来做离线流量审计。把一天的总线流量抓下来，用 Wireshark 的 `Statistics` → `Protocol Hierarchy` → `Modbus` 看기능 코드分布。기능 코드 0x08 和 0x2B 的出现是红旗。
nmap 的 `modbus-discover` NSE 스크립트应该周期性地从你自己的 SCADA 服务器运行，检查有没有新的 Modbus 设备出现在네트워크上：
nmap -p 502 --script modbus-discover 192.168.10.0/24发现了不属于你的设备，事情就严重了。
合规性参考
不展开讲法规条文，只说对 Modbus 部署直接有影响的几条。
**IEC 62443-3-3** 定义了산업 자동화和控制系统的七个基础要求（FR1-FR7）。其中 FR2（使用控制）要求对工业통신实施인증和授权，FR3（系统完整性）要求对통신데이터进行完整性체크섬。明文 Modbus 直接不符合 FR2 和 FR3。加 stunnel/VPN 后可以满足密码学层面的要求。
**NERC CIP（北美电力可靠性표준）** 的 CIP-005 要求对电力系统电子安全边界（ESP）实施访问控制。这意味着如果你在美国电力行业用 Modbus 传输控制指令，502 포트必须在 ESP 内部或者通过 ESP 的加密隧道，不能裸奔。CIP-007 还要求系统打补丁和最小化포트，和 Modbus 设备的固件管理直接相关。
**中国等保 2.0（GB/T 22239-2019）** 对산업 제어系统有专门的扩展要求。主要包括：控制네트워크和非控制네트워크之间实施边界防护和기술隔离；使用广域网进行控制指令传输时采用加密인증；工业控制系统内部根据业务划分安全域并实施隔离。用 Modbus 的设备如果在等保三级及以上的系统里，基本的네트워크隔离、통신加密、访问控制是硬性要求，没有可选余地。
这些合规要求不是摆设——审计的时候会查네트워크架构图、防火墙规则、抓包验证。拿 Modbus TCP 明文走公网通不过任何一项合规审计。
最低成本防护清单
如果你在一个中小工厂、预算有限、设备老旧不能换、也没有专职安全엔지니어링师，下面 5 条是你现在就能做的。**这 5 条挡住 90% 的攻击，不需要额外采购设备：**
1. **检查所有 502 포트是否可以从公网访问。** 到 https://www.shodan.io 搜你的公网 IP 段，或者在外部네트워크用 `nmap -p 502 <公网IP>` 扫一遍。发现暴露的，立刻关掉포트映射或者加 AC。 2. **Modbus 게이트웨이/DTU 改默认密码。** 不只是게이트웨이的 Web 管理页面——确认 DTU 的 AT 指令설정密码（如果支持）、MQTT Broker 的인증、VPN 的预共享密钥，전체改掉。 3. **把 Modbus 设备放在独立 VLAN，설정白名单 ACL。** 如果交换机不支持 VLAN，至少划一个独立的 IP 子网，路由器上做 ACL，只允许 SCADA 服务器 IP 访问 502。 4. **在 SCADA 服务器上跑一次 Wireshark 抓包审计。** 记录一小时的总线流量，检查有没有异常기능 코드（0x08, 0x2B）、有没有出现在不该在的设备주소。 5. **定期用 nmap 扫描 Modbus 네트워크。** 写个 cron 每周跑一次 `nmap -p 502 --script modbus-discover <子网>`，把출력 diff 一下。出现新设备=有人接了什么东西进去。
把上面 5 条落实了，再谈要不要上专用的 OT 安全平台、要不要做 SIEM 통합。大多数小工厂连第一条都没做。
和 OPC UA 的安全模型对比
聊 Modbus 安全绕不开 OPC UA。不是说谁替代谁，是搞清楚两者的安全模型差距，避免选型时做出离谱决策。
| 维度 | Modbus TCP (原生) | OPC UA |
|---|---|---|
| 인증 | 无 | X.509 证书、用户名/密码、Kerberos |
| 传输加密 | 无 | TLS 1.2/1.3 (UA-TCP) 或 HTTPS (UA-HTTPS) |
| 데이터签名 | 无 | 每条消息可单独签名 (UA-SecureConversation) |
| 访问控制 | 无 | 会话级+节点级 ACL |
| 审计로그 | 依赖적용层 | 内置审计事件유형 |
| 프로토콜复杂度 | 极简，12 바이트帧 | 2진수编码，完整 OO 对象模型 |
OPC UA 把安全做进了프로토콜栈，从传输层到적용层都有对应的安全机制。Modbus 把一切扔给了实现者。这不是 OPC UA 比 Modbus 「更好」——这是两种完全不同的设计哲学。OPC UA 的安全复杂度也是代价：TLS 握手、证书管理、信任链、CRL/OCSP 吊销检查——这些在嵌入式 Modbus 设备上是天方夜谭。STM32 跑 Modbus RTU 只需要一个 UART 和两三百行 C 代码，跑 OPC UA 需要 TLS 库、XML 분석器、至少几十 KB 的 RAM。
所以结论不是「大家都用 OPC UA」。是：如果你本来就在用 Modbus，别因为它不安全就推翻整个系统换成 OPC UA——加 stunnel、防火墙 ACL、安全代理的成本远低于换프로토콜。如果你是新建系统、选型阶段、设备자료充足、需要面向 IT/OT 融合架构——OPC UA 天然的安全能力会让你在后期的合规和运维上省很多事。
写在后面
Modbus 的安全문제不是一个기술문제，是一个엔지니어링管理문제。프로토콜本身没有安全能力，但你可以通过部署架构把它放到一个受保护的환경里。就像你不会把一台没有防火墙的服务器直接挂在公网上一样，你也不应该让 Modbus 设备直接面对不可信네트워크。
说到底，最危险的从来不是프로토콜漏洞，而是有人觉得「我们这种小厂没人攻击」。攻击者不挑大厂小厂——自动化扫描도구一视同仁，502 포트开着就进来。
有문제再聊，或者你自己开 Wireshark 抓一包看看——大概率你会被惊到的。
답글 작성