Modbus セキュリティ防护白皮书：9个明文传输的真实风险场景与分层防御方案

写前に面的话

Modbus 不セキュリティ。这ではない什么新发现——1979 year Modicon 设计这个协议的时候，连互联网都没普及，更不会想到有一天 PLC 会経由 4G モジュール直接暴露在公网上。那时候的威胁模型是「电缆会不会被老鼠咬断」，ではない「有ない人在 502 ポート上做中间人攻击」。

但这不代表 Modbus 不能用。一个协议的問題和工程现场的問題是两回事。在机柜里、在被絶縁的控制网上、在一对一物理连接的 RS-485 バス上，Modbus 明文的缺点几乎不构成威胁。問題出在什么时候？出在你把那根 RS-485 ライン上のリンク一个 4G DTU，然后 DTU 配了个公网 IP，然后デフォルトパスワード还没改。

这件の記事不讲セキュリティ理论，讲九个你我都可能遇到的情况——ではない「もし」而是「已经发生过」。然后我们讨论在不换デバイス、不推翻现有架构的前提下，怎么把风险降到一个可接受的水平。

Modbus 到底缺了什么

先搞清楚 Modbus 缺失的到底是什么。ではない「不セキュリティ」三个字就能概括的。

**ない认证机制。** Modbus TCP 的 MBAP 头里有个 Unit ID field，1 byte。这玩意儿是デバイスアドレス，ではない身份凭证。任何能建立 TCP 连接到 502 ポート的人，都可以送信機能コード 0x03 Read the hold register、function code 0x06 write single register。试试看：telnet 过去发 `x00x01x00x00x00x06x01x03x00x00x00x01` ——只要デバイスオンライン，它就会戻るレジスタのデータ。必要なし。パスワード，必要なし。 token，必要なし。任何形式的身份验证。

拿機能コード 0x05 シングルコイルを書く。来说。这一フレーム只有 12 bytes：

| 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、function code、register address、データ值。抓一包 Modbus TCP トラフィック等于拿到整套レジスタマッピングテーブル。一个有心人看你工厂的 Modbus トラフィック五分，能画出全装備。的レジスタ图。

**CRC 验不了篡改。** Modbus RTU 的 CRC-16 和 Modbus TCP 依赖的 TCP checksum，设计目的都是检测物理传输层的比特エラー——线缆噪声、電磁干渉による干渉导致的データ翻转。它们ではないパスワード学哈希，不能防刻意篡改。攻击者截获一フレーム，改レジスタの値，重新計算 CRC，转发出去，スレーブ无法区分这一フレーム是ではない被改过。

看一下攻击流：

元のフレーム (master→slave): 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 只是用来マッチングリクエスト与レスポンス，ではないセキュリティ番号）。同一フレーム可以无限重放。上个月你给风机发了停机指令，攻击者录下来，下个月再发一次——解码完全一样，デバイス照样停。

九个真实风险场景

ではない说理论上的漏洞，是下面这些事情已经在不同现场发生过。いくつかは我自己碰到的，いくつかは同行聊起的，いくつかは公开报告里的。

Scenarios 1：Modbus TCP 直连公网——502 ポート暴露在 Shodan 上

Shodan 上搜 `port:502`，结果数一直在涨。两三年前公开データ大概六七千台，现在早就过万了。这些デバイス里有 PLC、RTU、ゲートウェイ、スマートメーター，有的跑在データ中心，有的挂在水厂 SCADA 的主干网上。Shodan 还会抓取デバイス戻る的 Modbus Response，直接表示デバイス型号、固件版本。

什么都不用破解。你把デバイス IP 配成公网アドレス，502 ポート没做任何 ACL——这就跟把车间大门开着、デバイス操作面板对着马路一样。

nmap 扫一下更直观：

nmap -p 502 --script modbus-discover <target_ip>

这个 NSE 脚本会尝试読み取りデバイス信息。もしデバイスレスポンス了 0x11（駅からの報告 ID）或 0x2B（デバイス识别），它直接告诉你制造商、製品コードの作成、固件版本。零门槛。

Scenarios 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. 注入伪造的命令を書く。（function code 0x06 或 0x10），修改デバイス参数 3. 甚至向スレーブ送信广播指令（address 0x00），同时控制バス上全装備。

去年有个水厂的案例：攻击者経由公开的クラウド·プラットフォーム IP 连上了 DTU 的后台管理ポート（デフォルトパスワード admin/admin），直接看到整个泵站的控制界面。万幸只是看了，没操作。

Scenarios 3：Modbus 转 MQTT ゲートウェイ——MQTT 侧裸奔

这种架构现在很常见：Modbus RTU device → ゲートウェイ做プロトコル変換 → 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"

Scenarios 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 界面一切正常，后台的データ已经在被实时窃取。

Scenarios 5：Building Automation BACnet-Modbus ゲートウェイの構成页未设パスワード

ビルの自動制御系统里，BACnet 和 Modbus 经常会混在一个ゲートウェイ上。比如 Delta Controls、Siemens Desigo 的一些ゲートウェイ产品，既有 Modbus RTU 接口接仪表，又有 BACnet/IP 接口上 BMS。

这些ゲートウェイ通常会提供一个 Web 設定ページ。デフォルト情况下，很多集成商上线时只改 IP address、設定好レジスタマップ，パスワードまだ出厂デフォルト——或者压根没设パスワード。Web ページ暴露了完全的レジスタマッピングテーブル、Device address、機能コード設定、甚至オンラインデバッグ功能——可以直接在里面发 Modbus 读命令を書く。。

Shodan 上搜 `BACnet gateway` 或特定ゲートウェイ型号的产品ページ，能找到不少这样的入口。进去了不只是看データ——能直接在 Web 界面上改暖通阀门开度、设空调温度の設定值、启停冷水机组。

Scenarios 6：风电场 SCADA 的 Modbus 控制指令被重放

风电场 SCADA 系统通常用 Modbus TCP 和风机 PLC Communication。控制指令包括启停、桨距角调整、偏航控制、功率限制等。

2015 年乌克兰电网攻击事件之后，大家对 OT セキュリティ总算开始重视。但风场的情况比较特殊——很多风场建在偏远地区，远程运维依赖 VPN 或专线，运维人员流动性大，VPN 账号管理经常跟不上。

もし一条「紧急停机」Modbus 指令（function code 0x05，写某一1つのコイル）在传输过程中被坏人截获——无论経由什么手段，可能是 VPN クライアント側は被控、可能是运维笔记本被植入木马、可能是内网横向移動——这个フレーム可以被保存下来。攻击者必要なし。理解 Modbus protocol细节，必要なし。知道レジスタマップ，只需要几个月后在夜间重放这个フレーム。风机收到后就会执行停机。

重放不挑时间、不挑目标。录一次，发一百次。而 Modbus protocol原生ない任何机制能阻止这件事。

Scenarios 7：OEM デバイスデフォルト設定被利用

OEM デバイス厂商为了提高出货效率，すべての的 PLC/RTU 用统一駅からの住所（比如アドレス 01）、统一的機能コードのサポートリスト、甚至统一的レジスタマップ。更糟糕的是，一部の厂商在固件里写死了通信パラメータ——没法改。

这在デバイスデバッグ阶段很方便。但在实际部署以后，变成セキュリティ噩梦。

假设一个分布式光伏项目用了同一批逆变器，全装備。駅からの住所都是 01，レジスタマップ完全一样（40001=功率，40003=电压，40005=実行状態の状態，40101=スイッチマシン控制）。攻击者攻破其中一台デバイス或者中间的网络节点，他等于拿到了全装備。的控制蓝图。别的デバイス不用重新侦察——レジスタマップ完全是同一份。

Scenarios 8：レジスタ写入攻击——修改デバイス参数

这个场景最危险。Modbus 保持レジスタです。不光存测量データ，还存デバイス参数。周波数変換器上限频率、PID parameter、アラームしきい値、校准系数——都在レジスタ里。能写レジスタ的人就能改变デバイス的物理行为。

具体例子：

device	register address	parameter	正常值	恶意值	后果
周波数変換器	40018	上限频率	5000 (=50Hz)	500 (=5Hz)	泵出水不足，产线停产
サーモスタット	40005	目标温度	250 (=25.0℃)	800 (=80.0℃)	过温保护跳闸，或者反过来改低导致冻结
電気メーター	40045	电流变比	100	1	电量データ偏差百倍，能耗核算崩盘
PLC	40001	运行モード	1 (run)	0 (Stop)	直接让 PLC 停止执行逻辑

必要なし。做什么复杂攻击。nmap 的 modbus-discover 脚本扫一遍拿到レジスタマップ，然后 modbus-cli 或 pymodbus 直接往里写：

from pymodbus.client import ModbusTcpClient
client = ModbusTcpClient('192.168.1.100')
client.write_register(18, 500)  # 把周波数変換器上限频率改成5Hz

四行代码。必要なし。任何权限。周波数変換器受信しました就执行。

Scenarios 9：RS-485 バス物理接入——车间门没锁

RS-485 バス的物理セキュリティ性几乎是零。バス上的全装備。共享一对差動信号です线（A+/B-），任何人在バス的任何位置接上一个 USB-RS485 Converters，就能：

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 Server、データの収集ゲートウェイ）アクセス。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 year 10 月发布了 Modbus/TCP Security 规范**。核心变化：デフォルトポート从 502 改为 802，TLS 1.2 强制，X.509v3 证书做身份认证，同时引入基于角色的アクセス控制（Role-Based Access Control，RBAC）。

规范定义了四个角色：

Role ID	角色名	权限
0	Administrator	全機能コード、全レジスタ、デバイス管理
1	Operator	読み書きすべてのレジスタ，不能改設定
2	Engineer	デバッグ诊断权限
3	Observer	只データの読み取り，書けない。

这彻底解決了 Modbus 无认证的問題——クライアント側は必须持有有效证书才能建立 TLS connect，证书中的角色字段决定了能执行哪些機能コード。

但现实是，サポート 802 ポート的装備が少ない。得可怜。绝大多数存量デバイス只サポート 502 明文。不换デバイス怎么加 TLS？

**stunnel 方案。** stunnel 是一个轻量的 TLS 代理，能把任意 TCP 连接封装到 TLS 隧道里。部署架构：

SCADA クライアント側は → stunnel(本地127.0.0.1:1502) → TLS → stunnel(remote) → device(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 ゲートウェイ、Raspberry Pi、甚至 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` field。

开源方案也ではないない。用 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.addresses:
            if addr in READ_ONLY_REGISTERS:
                return exception_response(request.function_code, 0x02)  # Illegal data address
    
    # 转发到实际デバイス
    return forward_to_device(request)

这几行挡掉了场景 8 里主に。レジスタ写入攻击。

物理層は：RS-485 バス的物理セキュリティ

物理セキュリティ听起来「低级」，但九个场景里至少三个和物理接入有关。

最低成本也能做的几件事：

1. **机柜上锁。** 不只是一个简单的钥匙锁——用電子门禁，记录谁什么时候开了哪个机柜。異常时间（凌晨两三点）的机柜开门=物理セキュリティ事件。 2. **RS-485 バス用带屏蔽的ツイストペア走线槽。** 线槽加封条，拆开有痕迹。ではない防不住，是让攻击者留下证据。 3. **USB ポート無効。** 工厂里的工控机/HMI 必要なし。插 U 盘。BIOS 無効 USB、Windows 组策略無効可移動存储。有人插 USB-RS485 Converters，系统不识别。 4. **バス終端抵抗加防拆センサーは。** RS-485 バス两端各有一个 120Ω 終端抵抗。もし一个电阻被削除（有人オンライン中间接了一个监听デバイス导致阻抗变化），バス的电气特性会变化——可以用バス分析仪检测。

花不了多少钱，但挡住 90% 的物理接入攻击足够了。

モニタリング层：Modbus トラフィック異常检测

前面的すべての措施都是「不让他进来」。但对「已经进来了」或者「合法用户做了不合法的事」的情况，你还需要检测能力。

Modbus トラフィック的異常特征很明确——正是因为协议简单，異常更容易识别：

**ポーリング周期突变。** SCADA 系统通常以固定周期ポーリングデバイス（比如每秒一次）。もし某个スレーブ的リクエスト频率突然从 1 次/秒变成 100 次/秒，大概率ではない SCADA 的行为。可能是有人在暴力扫描レジスタ。

**非標準機能コード出现。** 一个只用了 0x03（read holding registers）和 0x06（write single register）的系统，突然出现 0x08（诊断）或 0x2B（デバイス识别）Request——这是侦察行为的典型特征。

**非営業時間トラフィック。** 工厂停产时段（比如晚上 11 点到早上 6 点），Modbus バス上不应该有大量读命令を書く。。もし有，报警。

**異常な機能コード组合。** 短时间内出现 0x05（write single coil）、0x06（write single register）、0x10（write multiple registers）的密集组合，且目标アドレス跨越多个不相邻的エリア——几乎可以确定是恶意操作。

オープンソースツール方面：

# Zeek (原Bro) 有 Modbus protocol解析器
# 写一个检测脚本放在 Zeek 的策略目录

Wireshark + Modbus 插件可以用来做オフライントラフィック审计。把一天的バストラフィック抓下来，用 Wireshark 的 `Statistics` → `Protocol Hierarchy` → `Modbus` 看機能コード分布。function code 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）。among them 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 ポート是否可以从公网アクセス。** to https://www.shodan.io 搜你的公网 IP 段，或者在外部网络用 `nmap -p 502 <公网IP>` 扫一遍。发现暴露的，立刻关掉ポートマッピング或者加 AC。 2. **Modbus ゲートウェイ/DTU 改デフォルトパスワード。** 不只是ゲートウェイ的 Web 管理ページ——Confirm DTU 的 AT 指令設定パスワード（もしサポート）、MQTT Broker 的认证、VPN 的预共享密钥，すべて改掉。 3. **把 Modbus デバイス放在独立 VLAN，設定ホワイトリスト。 ACL。** もしスイッチ交換機サポートなし。 VLAN，至少划一个独立的 IP 子网，ルーターで行う。 ACL，只允许 SCADA Server 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 bytesフレーム	二进制编码，complete 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 抓一包看看——大概率你会被惊到的。