4. Modbus协议安全：安全漏洞分析与攻击防御
Modbus协议，说实话，是工控界的"老古董"了。1979年诞生的东西，那时候互联网都还没影儿呢。我刚开始接触工控安全时，第一个研究的协议就是它。为什么？因为太普遍了，也太脆弱了。
今天咱们就聊聊Modbus协议的那些安全漏洞，以及怎么防中间人攻击和重放攻击。这些内容，都是我这些年踩坑踩出来的经验。
4.1 Modbus协议的安全漏洞分析
Modbus协议在设计之初，压根就没考虑过安全问题。它只关心一件事：怎么让PLC和上位机通信。至于谁来读、谁来写、数据有没有被篡改？统统不管。
这就导致了几个致命问题：
- 无认证机制：任何设备只要连上网络，就能发送Modbus指令。我在某水厂项目中就见过，一个误接的调试笔记本，直接给PLC发了停止指令，整个供水系统停了半小时。
- 明文传输：所有数据都是明文的。你用Wireshark抓个包，啥都能看到。寄存器地址、读写值、功能码，一览无余。
- 功能码滥用：Modbus的功能码就那么几个，但攻击者可以利用它们做很多事。比如功能码0x10（写多个寄存器），攻击者可以批量修改参数。
- 广播攻击：Modbus支持广播模式，一个请求能发给所有从站。攻击者利用这个特性，可以一次性瘫痪整个系统。
核心问题：Modbus协议没有会话管理、没有身份验证、没有数据完整性校验。说白了，它就是个"裸奔"的协议。
我记得有一次做渗透测试，目标是一个工厂的能源管理系统。我只需要发送一个简单的Modbus写请求，就能修改电表的读数。你想想看，这要是被恶意利用，后果有多严重？
4.2 中间人攻击（MITM）原理与防御
中间人攻击，说白了就是攻击者插在你和PLC之间，偷听甚至篡改你们的通信。在Modbus场景下，这太容易实现了。
攻击原理
攻击者通过ARP欺骗、DNS劫持或物理接入，把自己伪装成合法的通信节点。然后：
- 截获Modbus请求
- 修改请求内容（比如把"读取温度"改成"关闭阀门"）
- 转发给PLC
- 再把PLC的响应篡改后返回给上位机
整个过程，上位机和PLC都以为自己在和对方通信，实际上中间有个"二传手"在搞鬼。
我个人的经验：在实验室环境里，用Ettercap配合Modbus插件，5分钟就能搭建一个中间人攻击环境。防御这种攻击，不能只靠协议本身。
防御方案
防御中间人攻击，我建议从三个层面入手：
| 层面 | 措施 | 说明 |
|---|---|---|
| 网络层 | 802.1X认证 | 防止未授权设备接入网络 |
| 传输层 | TLS/SSL加密 | Modbus/TCP over TLS，防止窃听和篡改 |
| 应用层 | 消息认证码（MAC） | 对Modbus报文计算HMAC，验证完整性 |
这里重点说说Modbus/TCP over TLS。嗯，这个方案其实挺成熟的，但很多工控厂商不愿意用。为什么？因为TLS握手会增加延迟，对实时性要求高的场景不友好。我曾经在一个运动控制项目中试过，加了TLS后，响应时间从2ms飙到了15ms，直接被客户否决了。
避坑指南：如果系统对实时性要求极高（比如伺服控制），不要硬上TLS。可以考虑在应用层做轻量级签名，或者使用专用加密芯片来加速。
4.3 重放攻击原理与防御
重放攻击，就是攻击者把之前抓到的合法数据包，重新发送一遍。Modbus协议没有时间戳和序列号，所以重放攻击特别容易得手。
攻击场景
举个例子：攻击者抓到了一个"打开阀门"的Modbus请求。即使他不知道这个请求的密码（其实Modbus也没密码），他只需要把这个包原封不动地再发一次，阀门就会再次打开。
更可怕的是，攻击者可以反复重放同一个包，让阀门不停地开关。这在化工、油气行业，简直就是灾难。
防御方案
防御重放攻击，核心思路是让每个数据包都"独一无二"。我常用的方法有：
- 时间戳：在Modbus报文中嵌入时间戳，接收方检查时间差是否在允许范围内。我习惯用毫秒级时间戳，精度够用。
- 序列号：每个会话维护一个递增的序列号，接收方只接受序列号递增的报文。这个方法简单有效，但需要维护状态。
- 一次性随机数（Nonce）：每次通信前，双方交换一个随机数，后续报文必须包含这个随机数。攻击者无法预测下一个随机数，所以重放无效。
实战建议：我推荐组合使用"时间戳+序列号"。时间戳防止跨时段重放，序列号防止同一时段内的重放。两者结合，基本能防住99%的重放攻击。
4.4 知识体系与核心逻辑
下面这张图，是我梳理的Modbus协议安全知识体系。你可以把它当作一个"作战地图"。
4.5 实战：Modbus安全加固示例
说了这么多理论，咱们来点实际的。下面是一个简单的Modbus/TCP安全加固示例，使用Python实现。
import socket
import hmac
import hashlib
import struct
import time
class SecureModbusClient:
def __init__(self, host, port, secret_key):
self.host = host
self.port = port
self.secret_key = secret_key.encode()
self.sequence = 0
def _build_secure_packet(self, modbus_pdu):
"""构建安全报文：原始PDU + 时间戳 + 序列号 + HMAC"""
timestamp = int(time.time() * 1000)
self.sequence += 1
# 组合数据
data = modbus_pdu + struct.pack('!QI', timestamp, self.sequence)
# 计算HMAC
mac = hmac.new(self.secret_key, data, hashlib.sha256).digest()
return data + mac
def send_request(self, modbus_pdu):
"""发送安全加固后的Modbus请求"""
secure_packet = self._build_secure_packet(modbus_pdu)
sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock.connect((self.host, self.port))
sock.send(secure_packet)
response = sock.recv(1024)
sock.close()
return response
# 使用示例
client = SecureModbusClient('192.168.1.100', 502, 'my_secret_key_123')
# 读取保持寄存器（功能码0x03）
pdu = bytes([0x03, 0x00, 0x00, 0x00, 0x0A]) # 从地址0读取10个寄存器
response = client.send_request(pdu)
print(f"响应数据: {response.hex()}")个人习惯：我一般把密钥存储在硬件安全模块（HSM）里，而不是写在代码中。这样即使代码泄露，攻击者也拿不到密钥。
4.6 总结与思考
Modbus协议的安全问题，说白了就是"历史遗留问题"。它诞生于一个信任的网络环境，现在却被用在充满敌意的互联网上。这就像把一栋没有锁的房子，搬到了闹市区。
防御中间人攻击和重放攻击，没有银弹。你需要根据实际场景，选择合适的方案。如果系统实时性要求不高，上TLS是最省心的。如果要求高，那就得在应用层做文章。
我曾经在一个风电项目中，遇到过一个奇葩问题：PLC每隔一段时间就会莫名其妙地重启。查了三个月，最后发现是上位机在发送Modbus广播包时，不小心把复位指令也广播出去了。这就是典型的"功能码滥用"问题。从那以后，我养成了一个习惯：在生产环境中，严格限制Modbus功能码的使用范围。
嗯，安全这东西，永远在路上。没有绝对的安全，只有不断加固的防线。
公众号:蓝海资料掘金营，微信deep3321