做嵌入式这些年我接触过很多跑在产线上的设备也用抓包软件看过不少工控报文。老实说Modbus、MQTT、Profinet 这几类协议在嵌入式项目里几乎是绕不开的“标准配置”但越是常见越容易在日常开发里被忽略安全设计。很多时候现场设备出问题排查到最后往往不是硬件故障而是一台被私接的电脑、一个开放的订阅主题或者一次没有认证的写寄存器操作。这种问题放在内部网络里也许影响不大一旦设备联网、接入平台风险就会被成倍放大。到这个专栏第 18 讲我想集中把嵌入式场景下的网络安全问题聊透。这一讲的内容分四块三种主流工控协议的风险拆解、一套适合资源受限设备的轻量防护体系设计、边缘网关上的安全改造实战以及第 17 讲课后思考题的完整解析。不管是做单片机、Linux 嵌入式还是物联网平台对接这一讲的内容都能直接用上。1. 三大工控协议风险拆解先弄明白漏洞在哪在谈防护之前得先把敌人看清楚。很多工程师觉得“我这设备在专网里又不连公网谁能攻击我”——这个想法我在项目里见过太多次了。事实上工控协议诞生得早设计目标就是“可靠通信”几乎没有考虑“对抗恶意输入”。下面逐个拆解。1.1 Modbus几十年不加密的工业“老大哥”Modbus 是从 1979 年走过来的协议Modicon现在的施耐德电气为了 PLC 通信而设计。它的优点很突出报文结构极其简单、实现成本低、几乎任何单片机都能跑。缺点也同样突出不加密、不认证、无完整性校验。Modbus 家族里最常见的两种形式一种是基于串口的 Modbus RTU另一种是基于以太网的 Modbus TCP。RTU 报文由从站地址、功能码、数据和 CRC16 校验组成TCP 则把 CRC16 换成了更标准的 TCP 校验但其应用层协议几乎原封不动。一个典型的写保持寄存器请求报文也就 8 到 12 个字节请求00 01 00 00 00 06 01 06 00 01 00 64 从站地址01 功能码06写单个保持寄存器 寄存器地址0x0001 写入数据0x0064十进制 100这段报文没有任何身份信息。只要攻击者的设备能访问到目标网关的 502 端口他就可以直接向 PLC 或从站下发这种“合法”指令。写线圈、写寄存器、甚至远程启停设备都是动动手指的事。实操中风险最大的几个点功能码滥用正常上位机只会用到 03读保持寄存器、04读输入寄存器等读取功能码一旦检测到有人持续发送 05、06、10 这类写功能码且不是生产计划内的操作就必须警惕。广播地址 0Modbus 支持广播帧地址 0 会发给所有从站。攻击者可以利用广播帧一次性重置一批设备制造大面积异常。扫描与枚举没有任何认证机制意味着任何人都可以扫描网络、枚举寄存器、读取工艺参数。对产线来说工艺参数本身就是核心机密。现场还有一个常见问题为了调试方便不少工程师会把 PLC、HMI、触摸屏、传感器全部放在同一个二层网络里谁都能互访。这种情况下哪怕没有“黑客”刻意攻击一个配置错误的设备也可能因为 IP 冲突或错误报文干扰整个 Modbus 网络。1.2 MQTT物联网总线上的明文与权限问题MQTT 在物联网场景里几乎是事实标准基于发布/订阅模型非常轻量。但很多嵌入式工程师把 MQTT 接上云平台之后就默认“安全了”实际上 MQTT 默认状态下是既不加密也不鉴权的。MQTT 默认端口 1883 是明文通信8883 才是 TLS 加密。默认配置的 Mosquitto broker 允许匿名访问任何客户端都能连上来发布和订阅任意 Topic。如果设备把生产数据发布到/factory/device001/temperature这样的主题上攻击者只要订阅这个主题就能持续窃听温度、运行状态、能耗数据更危险的是他可以伪造客户端向设备控制主题发布指令。MQTT 的权限控制核心在 Topic 的读写分离。拿一份典型 ACL访问控制列表来说# 只允许设备客户端发布自己的数据主题 user device001 topic write factory/device001/# topic read factory/device001/cmd # 只允许平台客户端订阅数据主题 user cloud_platform topic read factory/# topic write factory/device001/cmd如果把 write 和 read 权限搞混比如给所有客户端都开放factory/#的读写权限那整个消息总线等于裸奔。而且 Topic 本身是全局命名空间的任何客户端只要知道主题名就能尝试订阅所以主题命名需要做到“即使被枚举也难以推导”更要在 broker 侧做严格的 ACL。MQTT 的另一个风险是 Payload 明文。即便你启用了 TLSbroker 本身仍然能看到全部明文消息。如果平台侧不信任 broker可以在应用层对敏感字段做额外加密比如 AES-GCM。这里给个简单概念TLS 保护的是“传输过程中”应用层加密保护的是“在 broker 手里也是密文”。两者不冲突按需叠加。1.3 Profinet实时性优先背后的威胁面Profinet 是西门子主导的工业以太网协议在汽车、物流、半导体行业用得非常广。它的特点是实时性强、组态方便大量用于 PLC 与远程 IO、驱动、阀岛之间的高速通信。和 Modbus 最大的区别是Profinet 不只是“发几个字节指令”它包含设备发现、组态诊断、实时 IO 数据交换等一系列机制。这也意味着威胁面更大非预期设备接入Profinet 使用 GSDML 文件描述设备能力一旦有非预期设备接入网络可能抢占 IP、设备名Station Name导致 PLC 与合法设备通信中断。LLDP 与 ARP 欺骗Profinet 的拓扑发现依赖 LLDP地址解析依赖 ARP。工业环境下如果混入一个恶意节点可以冒充合法 IO 设备向 PLC 发送假数据而 PLC 只认设备名和 IP很难察觉。实时通道不可用传统防护Profinet 的实时报文RT/IRT走的是以太网类型 0x8892不走 IP 协议栈。传统的防火墙、IDS 基于 IP 做过滤对这类二层实时报文基本抓瞎必须用支持 Profinet 深度感知的工业防火墙或工业交换机策略。生产环境里最常见的安全盲区是“一个 PLC 下挂数十台 IO 设备全部同处一个大 VLAN且没有任何端口安全措施”。这种情况下哪怕只是往交换机上插一个普通开发板都可能因为设备名冲突把整条产线搞停。下面把三种协议的风险特征做个对照方便后面设计防护体系时对号入座协议典型端口认证机制加密机制完整性校验最核心风险Modbus TCP502无无仅 TCP 校验任意设备可读写寄存器Modbus RTU串口/RS-485无无CRC16总线设备可越权通信MQTT1883/8883用户名密码/证书可选 TLS依赖 TLS越权订阅、伪造发布Profinet34964 等厂商机制部分部分非预期设备接入、欺骗2. 轻量防护体系嵌入式设备资源不够怎么办拆完风险很多人第一反应是“上防火墙、上入侵检测”。但嵌入式设备不是服务器内存按 KB/MB 算CPU 主频几百 MHz 已经算高配没法直接跑重型安全软件。这一节分享的思路是用分层、轻量的方式把风险控制在可接受范围。2.1 分层而不是堆墙防护工控系统我个人的原则是“分层设防单点不过度设计”。把整个链路切成边界层、网络层、协议层、设备层每一层做一点不要做的太重的拦截比在某一层部署一个超级复杂的安全组件更现实也更稳。边界层用边缘网关做协议转换、白名单过滤、网络隔离。比如将 Modbus 从站设备和上位机网络隔开数据经过网关中转外部无法直接触达从站。网络层划分 VLAN、配置防火墙规则、限制端口访问来源。这一步不需要高性能硬件普通 Linux 的 iptables/nftables 就能做。协议层功能码白名单、寄存器地址范围限制、 Modbus 轮询频率限制、 MQTT Topic 权限收紧、 Profinet 的设备名与 MAC 绑定。设备层安全启动、固件签名、最小化服务、日志审计。这里要有一个观念转变安全不一定等于“加密”很多时候“不可达”比“加密”更有效。攻击者连端口都摸不到连报文都发不进来根本不需要纠结加密强度。2.2 协议白名单、功能码过滤和访问控制Modbus 的防护核心在于“只允许必要的操作”。以项目里常用的 Modbus TCP 网关为例可以维护一张表允许的从站地址允许的功能码允许的寄存器范围轮询周期103, 040x0000 - 0x00991s2030x0100 - 0x010F500ms303, 060x0200 - 0x020F2s网关拦截到功能码为 06 写操作但目标寄存器不在白名单范围时直接丢弃并记录日志。对于 RTU 总线上的从站设备如果自己实现了 Modbus 协议栈也建议在协议栈入口做同样的检查。例如 FreeModbus 移植时可以在eMBFuncWriteHoldingRegister回调里校验寄存器地址范围超出范围直接返回非法数据地址异常码 0x02。这个改造成本很低代码量不到十行却能挡住绝大多数扫描探测。MQTT 这边的核心是“专属主题 最小权限”。每个设备只允许发布自己的数据主题只允许订阅自己的命令主题。broker 端开启匿名访问禁用客户端使用独立账号有条件直接上设备证书双向认证。同时 Topic 命名不要暴露太多业务信息比如用设备序列号代替产线号设备名。Profinet 的访问控制更适合在管理型工业交换机上实施。开启端口安全后交换机学习端口上的 MAC 地址只允许白名单里的设备接入。同时为 PLC、IO 设备划分独立 VLAN将 HMI、工程师站等办公/调试设备放到另一个 VLAN中间通过路由策略做定向放通。2.3 加密与认证的工程化选择资源受限设备上做加密要先考虑硬件能力。多数现代 MCU如 STM32F2/F4/H7 系列、ESP32 等都内置 AES 硬件加速跑 AES-128-GCM 的开销并不大。但 TLS 握手过程涉及的 RSA/ECC 运算就比较吃 CPU 了尤其是 ephermeral ECDHE 密钥交换。实际项目中我的参考做法MCU 直接连 MQTT Broker优先用 MQTT over TLS8883 端口。TLS 库可以用 mbedTLS证书用设备证书出厂预置 服务器证书校验域名密钥交换用 ECDHE-ECDSA-AES128-GCM-SHA256这个套件在资源占用和安全性之间比较均衡。老设备串口上云老式 Modbus RTU 设备往往没有能力做 TLS这时用边缘网关做“安全代理”。网关负责和平台做 TLS 加密通信传统的串口设备只跟网关走本地明文 Modbus物理上已经处于隔离网络。这也是目前改造存量设备成本最低的方案。应用层数据保护如果端到端安全要求高比如传感器数据需要从 MCU 加密到平台才放心可以在应用层做 AES-128-GCM。设备端维护一个密钥加密 payload 中的敏感字段平台侧解密。密钥管理别做得太复杂建议用每台设备的唯一 ID 派生密钥哪怕一台设备的密钥泄露也不影响其他设备。2.4 异常监测与日志审计嵌入式设备的内存有限日志不会像服务器那样存几 GB。我的经验是维护一个环形缓冲区只记录关键事件比如非法功能码请求、来源 IP、时间戳。同时通过心跳机制把摘要上报到平台侧。举个例子[2025-01-18 14:23:02] Modbus TCP 非法访问来源 192.168.1.100目标寄存器 0x2000功能码 0x10已拦截 [2025-01-18 14:23:05] MQTT 连接失败客户端 device005原因证书验证失败 [2025-01-18 14:23:11] 设备 temperature_sensor_2 心跳超时重启轮询这些日志单看没有太大价值但累积起来可以看到攻击者的扫描规律。我是建议做一层简单的“连续失败锁定”比如 1 分钟内同一个来源 IP 连续 5 次访问非法功能码直接将该 IP 加入临时黑名单10 分钟后再解封。逻辑不复杂手写或者放到网关上用 shell 脚本都能实现。3. 边缘网关实战从 Modbus 到 MQTT 的轻量安全改造说了一堆理论不上实战等于白说。这一节我用一个很典型的场景走一遍完整流程现场有一批只支持 Modbus TCP 的老设备上位机需要把数据上云同时要防止第三方直接读写现场设备。做法是在中间加一个边缘网关做协议转换、安全过滤和加密传输。3.1 选型与拓扑网关硬件方面如果只是小规模试点我建议找一块带以太网口的 ARM Linux 开发板比如 RK3308、全志 H3/H5 这类就行内存 512MB 以上完全够用。如果想省电省空间也可以用 ESP32 W5500 的以太网方案但跑 TLS 会吃力一些建议只做透明转发和简单过滤加密交给上层。整体拓扑Modbus TCP 从站设备如温控器、电表 │ ▼ 边缘网关采集 白名单过滤 数据格式化 │ ▼MQTT over TLS, 8883 MQTT Broker │ ▼ 云平台/上位机关键设计原则Modbus 从站所在的二层网络与上位机/云平台网络完全隔离。网关是唯一的数据通道。即便上位机网络被攻破攻击者也接触不到 Modbus 从站本身。3.2 搭建步骤与核心配置第一步在网关上安装基础软件。以 Debian/Ubuntu 系统的 ARM 板为例apt update apt install -y python3 python3-pip mosquitto mosquitto-clients pip3 install pymodbus paho-mqtt第二步配置 MQTT Broker 的安全策略。编辑/etc/mosquitto/mosquitto.confallow_anonymous false password_file /etc/mosquitto/passwd acl_file /etc/mosquitto/acl listener 1883 127.0.0.1 listener 8883 0.0.0.0 cafile /etc/mosquitto/certs/ca.crt certfile /etc/mosquitto/certs/server.crt keyfile /etc/mosquitto/certs/server.key require_certificate true这里我把 1883 端口绑定到本地回环外部只能通过 8883 的 TLS 端口访问。ACL 文件示例如下user device_01 topic write gateway/device_01/data topic read gateway/device_01/cmd user cloud_platform topic read gateway/# topic write gateway/device_01/cmd第三步编写网关采集脚本。下面这段 Python 代码实现的是从 Modbus 从站读取保持寄存器功能码 03做地址白名单过滤然后封装成 JSON 发布到 MQTT。代码里的ALLOWED_FUNCTIONS和ALLOWED_REGISTERS就是白名单策略。import json import time from pymodbus.client import ModbusTcpClient from paho.mqtt import client as mqtt_client MODBUS_IP 192.168.10.10 MODBUS_PORT 502 SLAVE_ID 1 ALLOWED_FUNCTIONS [3, 4] ALLOWED_REGISTERS range(0x0000, 0x0100) MQTT_BROKER your-broker-host MQTT_PORT 8883 MQTT_TOPIC gateway/device_01/data MQTT_CLIENT_ID device_01 CA_CERT /etc/ssl/certs/ca.crt CLIENT_CERT /etc/ssl/certs/client.crt CLIENT_KEY /etc/ssl/private/client.key def on_connect(client, userdata, flags, rc): if rc 0: print(MQTT connected) else: print(fMQTT connect failed, rc{rc}) client mqtt_client.Client(client_idMQTT_CLIENT_ID) client.tls_set(CA_CERT, CLIENT_CERT, CLIENT_KEY) client.on_connect on_connect client.connect(MQTT_BROKER, MQTT_PORT, 60) client.loop_start() def check_modbus_request(function_code, address): if function_code not in ALLOWED_FUNCTIONS: return False if address not in ALLOWED_REGISTERS: return False return True while True: try: modbus_client ModbusTcpClient(MODBUS_IP, portMODBUS_PORT, timeout3) if modbus_client.connect(): registers modbus_client.read_holding_registers( address0x0000, count10, slaveSLAVE_ID ) if registers.isError() or not hasattr(registers, registers): print(Modbus read error) else: # 只发布白名单范围内的寄存器 valid_data {} for i, val in enumerate(registers.registers): addr 0x0000 i if addr in ALLOWED_REGISTERS: valid_data[freg_{addr:04X}] val payload { timestamp: int(time.time()), device_id: device_01, data: valid_data, } result client.publish(MQTT_TOPIC, json.dumps(payload), qos1) if result.rc mqtt_client.MQTT_ERR_SUCCESS: print(fPublished: {json.dumps(payload)}) modbus_client.close() except Exception as e: print(fError: {e}) time.sleep(2)第四步在网关上做端口级访问控制。这一步的目的是即使有人渗透到了网关所在的网络也不能直接访问网关自身的服务iptables -A INPUT -p tcp --dport 22 -s 192.168.200.0/24 -j ACCEPT iptables -A INPUT -p tcp --dport 22 -j DROP iptables -A INPUT -p tcp --dport 502 -s 192.168.10.0/24 -j ACCEPT iptables -A INPUT -p tcp --dport 502 -j DROP iptables -A INPUT -p tcp --dport 8883 -j ACCEPT iptables -A INPUT -p tcp --dport 1883 -j DROP上面规则的含义是仅允许本地调试网段访问 SSH仅允许 Modbus 从站网段访问 502 端口外部统一从 8883 走 TLS 上 MQTT1883 明文端口直接关闭。3.3 实测验证与常见坑部署完成后我习惯用几台机器验证一下效果。第一步模拟一个 Modbus 从站可以用 Modbus Slave 工具或者直接用 mbpoll 命令行工具起一个虚拟从站mbpoll -a 1 -t 3 -r 0 -c 10 -0 192.168.10.10 -p 502然后跑起来网关脚本观察 MQTT Broker 端是否收到数据。再做一个逆向验证直接向网关的 502 端口发送一条非白名单请求比如写寄存器功能码 06看网关是否拦截。用nc手写报文# Modbus TCP 请求从站1功能码06寄存器0x0001值0x0064 printf \x00\x01\x00\x00\x00\x06\x01\x06\x00\x01\x00\x64 | nc -w 2 网关IP 502如果白名单已经把功能码 06 禁掉这条请求应该得不到正常响应同时日志中会新增一条拦截记录。下面把我在现场踩过的坑整理一下供参考寄存器大小端问题Modbus 寄存器 16 位一个 32 位浮点数要占两个寄存器字节序和字序都可能导致数据完全错误。建议在网关侧统一转换成小端或大端并在 MQTT 消息里带上数据格式描述。QoS 选择QoS 0 实时性最好但可能丢消息适合监控类数据QoS 1 能保证至少一次送达但可能有重复适合控制类指令。控制指令建议平台侧做幂等处理避免重复执行。断线重连Modbus TCP 从站有时会重启网关脚本必须处理connect失败的情况保证下次轮询能自动恢复。MQTT 客户端同样要设置重连机制否则网关卡死现场数据就断了。时间同步边缘网关如果离线运行系统时间会漂移日志里的时间戳就不可信。建议网关上配 NTP 客户端没有外网就手动设置一个可靠的本地时间源。内存泄漏Python 脚本长时间运行某些库可能在异常路径下悄悄积累内存。建议用watch -n 5 free -m观察内存变化每周定时重启一次服务或者直接用 systemd 的Restarton-failure做守护。这些坑单独看都不大但叠在一起足以让一个安全改造项目烂尾。工程上的“稳”往往就是一个一个细节磨出来的。4. 第 17 讲课后思考题完整解析上一讲我们重点聊了串口通信、RS-485 总线以及 Modbus RTU 的底层机制课后留了四道思考题。这里把完整解析写出来每道题都补充了推导过程和工程经验方便对照理解。4.1 题一UART 波特率误差计算题目某 MCU 外部晶振为 12MHz通过 PLL 倍频后得到系统时钟UART 外设分频后配置成 115200bps实际波特率存在 0.2% 的误差。请问该误差能否保证稳定通信给出计算依据。解析UART 是异步协议收发双方没有共享时钟靠波特率一致来保证正确采样。接收端通常以 16 倍波特率时钟采样在每个 bit 的中点附近采样一次。假设一帧数据包含 1 个起始位、8 个数据位、1 个停止位共 10 个 bit。如果波特率存在 0.2% 误差那么一个 bit 的时间误差不会累积超过整个帧长度理论1帧时间 10 × (1 / 115200) ≈ 86.81 μs 实际1帧时间 10 × (1 / (115200 × 1.002)) ≈ 86.63 μs 累积误差 86.81 - 86.63 0.18 μs 误差占1个bit时间的比例 0.18 / 8.68 ≈ 2.1%接收端采样点在 bit 中点只要累计偏移不超过半个 bit 时间约 50%都能采到正确电平。UART 实际工程上通常要求收发双方波特率误差小于 2%你这个 0.2% 远在安全范围内。另外要注意误差的方向也很关键。如果双方误差方向相反总误差是两个误差之和所以设计时尽量选同批次晶振或同一参考时钟源。4.2 题二RS-485 终端电阻与信号反射题目RS-485 总线上什么情况下必须加终端电阻为什么通常选 120Ω终端电阻是否每个节点都要加解析RS-485 靠 A/B 两线间的电压差传输信号信号在双绞线上传输遇到阻抗不连续的位置会产生反射。特性阻抗大约 120Ω 的双绞线如果末端不匹配反射波会叠加在原始信号上导致波形畸变、误码。工程上可以按两条标准判断通信线缆长度超过 10 米建议加终端电阻超过 30 米基本必须加。波特率波特率越高单个 bit 时间越短反射对采样的影响越明显9600bps 以下短距离可能不加也行115200bps 及以上务必加。终端电阻只需要在总线的最远两端各加一个 120Ω 电阻中间节点的设备不需要接。原因在于信号是沿着总线从一端传到另一端的只有在物理末端才需要做阻抗匹配。中间节点如果也接 120Ω等于给总线多挂了并联负载驱动能力不够时反而会拉低信号幅值。实际项目里我遇到过一种情况总线两端的终端电阻都没加设备偶尔通信失败用示波器看波形能看到明显的过冲和振铃。加上 120Ω 电阻之后波形一下子干净了。另外注意RS-485 的 A/B 线不能接反接反的典型表现是所有设备都不通信但示波器能看到差分信号存在。4.3 题三Modbus RTU 帧间隔 3.5 字符时间的计算题目为什么 Modbus RTU 要求帧与帧之间的间隔不小于 3.5 个字符时间以 9600bps、8 数据位、无校验、1 停止位为例计算 3.5 个字符时间是多少毫秒解析Modbus RTU 没有类似 TCP 的长度字段接收端靠“静默时间”来切分帧。发送完一帧后必须等待至少 3.5 个字符时间的空闲才表示这一帧结束接收端检测到总线上持续空闲超过 3.5 个字符时间就认为之前收到的数据是一整帧。先算一个字符的时间。UART 帧结构1 个起始位 8 个数据位 1 个停止位 10 bit无校验时。1 bit 时间 1 / 9600 ≈ 104.17 μs 1 个字符时间 10 × 104.17 μs ≈ 1041.7 μs 3.5 个字符时间 3.5 × 1041.7 μs ≈ 3645.9 μs ≈ 3.65 ms工程实现时很多协议栈会把这个值向上取整到 4ms甚至留 1ms 余量避免晶振误差导致误判。注意还有另一个关键间隔帧内部的字节间隔不能大于 1.5 个字符时间否则接收端认为帧提前结束。对于 9600bps1.5 个字符时间约 1.56ms。如果驱动里出现频繁发送“粘帧”大概率是发送间隔控制没做好。实测中有一个容易忽略的点RS-485 是半双工总线从发送切换到接收收发器本身需要时间一般几十微秒到几百微秒。如果主机发完请求立刻切到接收可能丢掉从站回复的前几个字节所以驱动程序里发送完成后要加一个小延时再切换方向。这个延时和波特率相关我一般取 0.5 个字符时间以上。4.4 题四为什么说 Modbus RTU 不校验数据内容但依赖 CRC16题目Modbus RTU 的 CRC16 能防止数据被篡改吗为什么它和 TCP/IP 的校验有什么区别解析CRC16 的本质是检错码不是防篡改的密码学校验。它能在噪声干扰、电平抖动等随机错误发生时大概率发现数据位翻转但无法抵御有意的恶意篡改。原因在于 CRC16 算法是公开的多项式固定攻击者只要知道报文内容就能重新计算 CRC16 并附在后面接收端根本看不出区别。TCP/IP 的校验和也是一样的逻辑它只验证传输过程中是否发生比特错误没有任何对抗恶意修改的能力。所以 Modbus RTU 或者 Modbus TCP 只要暴露给不可信网络就必须在协议上层做防护——要么通过网关隔离要么加应用层认证码比如 HMAC-SHA256。基于这个思路在讲解 Modbus 防护体系的第 18 讲里我建议对 RTU 报文做“CRC16 应用层消息认证码”双重校验。CRC16 承担物理层检错消息认证码承担防篡改两者缺一不可。这道题的核心结论是不要把检错和防篡改混为一谈。检错解决“线路噪声”防篡改解决“击者故意构造报文”。工控现场两者都会遇到但原因和手段截然不同。想通这一点再看第 18 讲的风险拆解就明白为什么单纯的 CRC 校验远远不够了。
嵌入式设备网络安全：三大工控协议风险拆解与轻量防护体系
做嵌入式这些年我接触过很多跑在产线上的设备也用抓包软件看过不少工控报文。老实说Modbus、MQTT、Profinet 这几类协议在嵌入式项目里几乎是绕不开的“标准配置”但越是常见越容易在日常开发里被忽略安全设计。很多时候现场设备出问题排查到最后往往不是硬件故障而是一台被私接的电脑、一个开放的订阅主题或者一次没有认证的写寄存器操作。这种问题放在内部网络里也许影响不大一旦设备联网、接入平台风险就会被成倍放大。到这个专栏第 18 讲我想集中把嵌入式场景下的网络安全问题聊透。这一讲的内容分四块三种主流工控协议的风险拆解、一套适合资源受限设备的轻量防护体系设计、边缘网关上的安全改造实战以及第 17 讲课后思考题的完整解析。不管是做单片机、Linux 嵌入式还是物联网平台对接这一讲的内容都能直接用上。1. 三大工控协议风险拆解先弄明白漏洞在哪在谈防护之前得先把敌人看清楚。很多工程师觉得“我这设备在专网里又不连公网谁能攻击我”——这个想法我在项目里见过太多次了。事实上工控协议诞生得早设计目标就是“可靠通信”几乎没有考虑“对抗恶意输入”。下面逐个拆解。1.1 Modbus几十年不加密的工业“老大哥”Modbus 是从 1979 年走过来的协议Modicon现在的施耐德电气为了 PLC 通信而设计。它的优点很突出报文结构极其简单、实现成本低、几乎任何单片机都能跑。缺点也同样突出不加密、不认证、无完整性校验。Modbus 家族里最常见的两种形式一种是基于串口的 Modbus RTU另一种是基于以太网的 Modbus TCP。RTU 报文由从站地址、功能码、数据和 CRC16 校验组成TCP 则把 CRC16 换成了更标准的 TCP 校验但其应用层协议几乎原封不动。一个典型的写保持寄存器请求报文也就 8 到 12 个字节请求00 01 00 00 00 06 01 06 00 01 00 64 从站地址01 功能码06写单个保持寄存器 寄存器地址0x0001 写入数据0x0064十进制 100这段报文没有任何身份信息。只要攻击者的设备能访问到目标网关的 502 端口他就可以直接向 PLC 或从站下发这种“合法”指令。写线圈、写寄存器、甚至远程启停设备都是动动手指的事。实操中风险最大的几个点功能码滥用正常上位机只会用到 03读保持寄存器、04读输入寄存器等读取功能码一旦检测到有人持续发送 05、06、10 这类写功能码且不是生产计划内的操作就必须警惕。广播地址 0Modbus 支持广播帧地址 0 会发给所有从站。攻击者可以利用广播帧一次性重置一批设备制造大面积异常。扫描与枚举没有任何认证机制意味着任何人都可以扫描网络、枚举寄存器、读取工艺参数。对产线来说工艺参数本身就是核心机密。现场还有一个常见问题为了调试方便不少工程师会把 PLC、HMI、触摸屏、传感器全部放在同一个二层网络里谁都能互访。这种情况下哪怕没有“黑客”刻意攻击一个配置错误的设备也可能因为 IP 冲突或错误报文干扰整个 Modbus 网络。1.2 MQTT物联网总线上的明文与权限问题MQTT 在物联网场景里几乎是事实标准基于发布/订阅模型非常轻量。但很多嵌入式工程师把 MQTT 接上云平台之后就默认“安全了”实际上 MQTT 默认状态下是既不加密也不鉴权的。MQTT 默认端口 1883 是明文通信8883 才是 TLS 加密。默认配置的 Mosquitto broker 允许匿名访问任何客户端都能连上来发布和订阅任意 Topic。如果设备把生产数据发布到/factory/device001/temperature这样的主题上攻击者只要订阅这个主题就能持续窃听温度、运行状态、能耗数据更危险的是他可以伪造客户端向设备控制主题发布指令。MQTT 的权限控制核心在 Topic 的读写分离。拿一份典型 ACL访问控制列表来说# 只允许设备客户端发布自己的数据主题 user device001 topic write factory/device001/# topic read factory/device001/cmd # 只允许平台客户端订阅数据主题 user cloud_platform topic read factory/# topic write factory/device001/cmd如果把 write 和 read 权限搞混比如给所有客户端都开放factory/#的读写权限那整个消息总线等于裸奔。而且 Topic 本身是全局命名空间的任何客户端只要知道主题名就能尝试订阅所以主题命名需要做到“即使被枚举也难以推导”更要在 broker 侧做严格的 ACL。MQTT 的另一个风险是 Payload 明文。即便你启用了 TLSbroker 本身仍然能看到全部明文消息。如果平台侧不信任 broker可以在应用层对敏感字段做额外加密比如 AES-GCM。这里给个简单概念TLS 保护的是“传输过程中”应用层加密保护的是“在 broker 手里也是密文”。两者不冲突按需叠加。1.3 Profinet实时性优先背后的威胁面Profinet 是西门子主导的工业以太网协议在汽车、物流、半导体行业用得非常广。它的特点是实时性强、组态方便大量用于 PLC 与远程 IO、驱动、阀岛之间的高速通信。和 Modbus 最大的区别是Profinet 不只是“发几个字节指令”它包含设备发现、组态诊断、实时 IO 数据交换等一系列机制。这也意味着威胁面更大非预期设备接入Profinet 使用 GSDML 文件描述设备能力一旦有非预期设备接入网络可能抢占 IP、设备名Station Name导致 PLC 与合法设备通信中断。LLDP 与 ARP 欺骗Profinet 的拓扑发现依赖 LLDP地址解析依赖 ARP。工业环境下如果混入一个恶意节点可以冒充合法 IO 设备向 PLC 发送假数据而 PLC 只认设备名和 IP很难察觉。实时通道不可用传统防护Profinet 的实时报文RT/IRT走的是以太网类型 0x8892不走 IP 协议栈。传统的防火墙、IDS 基于 IP 做过滤对这类二层实时报文基本抓瞎必须用支持 Profinet 深度感知的工业防火墙或工业交换机策略。生产环境里最常见的安全盲区是“一个 PLC 下挂数十台 IO 设备全部同处一个大 VLAN且没有任何端口安全措施”。这种情况下哪怕只是往交换机上插一个普通开发板都可能因为设备名冲突把整条产线搞停。下面把三种协议的风险特征做个对照方便后面设计防护体系时对号入座协议典型端口认证机制加密机制完整性校验最核心风险Modbus TCP502无无仅 TCP 校验任意设备可读写寄存器Modbus RTU串口/RS-485无无CRC16总线设备可越权通信MQTT1883/8883用户名密码/证书可选 TLS依赖 TLS越权订阅、伪造发布Profinet34964 等厂商机制部分部分非预期设备接入、欺骗2. 轻量防护体系嵌入式设备资源不够怎么办拆完风险很多人第一反应是“上防火墙、上入侵检测”。但嵌入式设备不是服务器内存按 KB/MB 算CPU 主频几百 MHz 已经算高配没法直接跑重型安全软件。这一节分享的思路是用分层、轻量的方式把风险控制在可接受范围。2.1 分层而不是堆墙防护工控系统我个人的原则是“分层设防单点不过度设计”。把整个链路切成边界层、网络层、协议层、设备层每一层做一点不要做的太重的拦截比在某一层部署一个超级复杂的安全组件更现实也更稳。边界层用边缘网关做协议转换、白名单过滤、网络隔离。比如将 Modbus 从站设备和上位机网络隔开数据经过网关中转外部无法直接触达从站。网络层划分 VLAN、配置防火墙规则、限制端口访问来源。这一步不需要高性能硬件普通 Linux 的 iptables/nftables 就能做。协议层功能码白名单、寄存器地址范围限制、 Modbus 轮询频率限制、 MQTT Topic 权限收紧、 Profinet 的设备名与 MAC 绑定。设备层安全启动、固件签名、最小化服务、日志审计。这里要有一个观念转变安全不一定等于“加密”很多时候“不可达”比“加密”更有效。攻击者连端口都摸不到连报文都发不进来根本不需要纠结加密强度。2.2 协议白名单、功能码过滤和访问控制Modbus 的防护核心在于“只允许必要的操作”。以项目里常用的 Modbus TCP 网关为例可以维护一张表允许的从站地址允许的功能码允许的寄存器范围轮询周期103, 040x0000 - 0x00991s2030x0100 - 0x010F500ms303, 060x0200 - 0x020F2s网关拦截到功能码为 06 写操作但目标寄存器不在白名单范围时直接丢弃并记录日志。对于 RTU 总线上的从站设备如果自己实现了 Modbus 协议栈也建议在协议栈入口做同样的检查。例如 FreeModbus 移植时可以在eMBFuncWriteHoldingRegister回调里校验寄存器地址范围超出范围直接返回非法数据地址异常码 0x02。这个改造成本很低代码量不到十行却能挡住绝大多数扫描探测。MQTT 这边的核心是“专属主题 最小权限”。每个设备只允许发布自己的数据主题只允许订阅自己的命令主题。broker 端开启匿名访问禁用客户端使用独立账号有条件直接上设备证书双向认证。同时 Topic 命名不要暴露太多业务信息比如用设备序列号代替产线号设备名。Profinet 的访问控制更适合在管理型工业交换机上实施。开启端口安全后交换机学习端口上的 MAC 地址只允许白名单里的设备接入。同时为 PLC、IO 设备划分独立 VLAN将 HMI、工程师站等办公/调试设备放到另一个 VLAN中间通过路由策略做定向放通。2.3 加密与认证的工程化选择资源受限设备上做加密要先考虑硬件能力。多数现代 MCU如 STM32F2/F4/H7 系列、ESP32 等都内置 AES 硬件加速跑 AES-128-GCM 的开销并不大。但 TLS 握手过程涉及的 RSA/ECC 运算就比较吃 CPU 了尤其是 ephermeral ECDHE 密钥交换。实际项目中我的参考做法MCU 直接连 MQTT Broker优先用 MQTT over TLS8883 端口。TLS 库可以用 mbedTLS证书用设备证书出厂预置 服务器证书校验域名密钥交换用 ECDHE-ECDSA-AES128-GCM-SHA256这个套件在资源占用和安全性之间比较均衡。老设备串口上云老式 Modbus RTU 设备往往没有能力做 TLS这时用边缘网关做“安全代理”。网关负责和平台做 TLS 加密通信传统的串口设备只跟网关走本地明文 Modbus物理上已经处于隔离网络。这也是目前改造存量设备成本最低的方案。应用层数据保护如果端到端安全要求高比如传感器数据需要从 MCU 加密到平台才放心可以在应用层做 AES-128-GCM。设备端维护一个密钥加密 payload 中的敏感字段平台侧解密。密钥管理别做得太复杂建议用每台设备的唯一 ID 派生密钥哪怕一台设备的密钥泄露也不影响其他设备。2.4 异常监测与日志审计嵌入式设备的内存有限日志不会像服务器那样存几 GB。我的经验是维护一个环形缓冲区只记录关键事件比如非法功能码请求、来源 IP、时间戳。同时通过心跳机制把摘要上报到平台侧。举个例子[2025-01-18 14:23:02] Modbus TCP 非法访问来源 192.168.1.100目标寄存器 0x2000功能码 0x10已拦截 [2025-01-18 14:23:05] MQTT 连接失败客户端 device005原因证书验证失败 [2025-01-18 14:23:11] 设备 temperature_sensor_2 心跳超时重启轮询这些日志单看没有太大价值但累积起来可以看到攻击者的扫描规律。我是建议做一层简单的“连续失败锁定”比如 1 分钟内同一个来源 IP 连续 5 次访问非法功能码直接将该 IP 加入临时黑名单10 分钟后再解封。逻辑不复杂手写或者放到网关上用 shell 脚本都能实现。3. 边缘网关实战从 Modbus 到 MQTT 的轻量安全改造说了一堆理论不上实战等于白说。这一节我用一个很典型的场景走一遍完整流程现场有一批只支持 Modbus TCP 的老设备上位机需要把数据上云同时要防止第三方直接读写现场设备。做法是在中间加一个边缘网关做协议转换、安全过滤和加密传输。3.1 选型与拓扑网关硬件方面如果只是小规模试点我建议找一块带以太网口的 ARM Linux 开发板比如 RK3308、全志 H3/H5 这类就行内存 512MB 以上完全够用。如果想省电省空间也可以用 ESP32 W5500 的以太网方案但跑 TLS 会吃力一些建议只做透明转发和简单过滤加密交给上层。整体拓扑Modbus TCP 从站设备如温控器、电表 │ ▼ 边缘网关采集 白名单过滤 数据格式化 │ ▼MQTT over TLS, 8883 MQTT Broker │ ▼ 云平台/上位机关键设计原则Modbus 从站所在的二层网络与上位机/云平台网络完全隔离。网关是唯一的数据通道。即便上位机网络被攻破攻击者也接触不到 Modbus 从站本身。3.2 搭建步骤与核心配置第一步在网关上安装基础软件。以 Debian/Ubuntu 系统的 ARM 板为例apt update apt install -y python3 python3-pip mosquitto mosquitto-clients pip3 install pymodbus paho-mqtt第二步配置 MQTT Broker 的安全策略。编辑/etc/mosquitto/mosquitto.confallow_anonymous false password_file /etc/mosquitto/passwd acl_file /etc/mosquitto/acl listener 1883 127.0.0.1 listener 8883 0.0.0.0 cafile /etc/mosquitto/certs/ca.crt certfile /etc/mosquitto/certs/server.crt keyfile /etc/mosquitto/certs/server.key require_certificate true这里我把 1883 端口绑定到本地回环外部只能通过 8883 的 TLS 端口访问。ACL 文件示例如下user device_01 topic write gateway/device_01/data topic read gateway/device_01/cmd user cloud_platform topic read gateway/# topic write gateway/device_01/cmd第三步编写网关采集脚本。下面这段 Python 代码实现的是从 Modbus 从站读取保持寄存器功能码 03做地址白名单过滤然后封装成 JSON 发布到 MQTT。代码里的ALLOWED_FUNCTIONS和ALLOWED_REGISTERS就是白名单策略。import json import time from pymodbus.client import ModbusTcpClient from paho.mqtt import client as mqtt_client MODBUS_IP 192.168.10.10 MODBUS_PORT 502 SLAVE_ID 1 ALLOWED_FUNCTIONS [3, 4] ALLOWED_REGISTERS range(0x0000, 0x0100) MQTT_BROKER your-broker-host MQTT_PORT 8883 MQTT_TOPIC gateway/device_01/data MQTT_CLIENT_ID device_01 CA_CERT /etc/ssl/certs/ca.crt CLIENT_CERT /etc/ssl/certs/client.crt CLIENT_KEY /etc/ssl/private/client.key def on_connect(client, userdata, flags, rc): if rc 0: print(MQTT connected) else: print(fMQTT connect failed, rc{rc}) client mqtt_client.Client(client_idMQTT_CLIENT_ID) client.tls_set(CA_CERT, CLIENT_CERT, CLIENT_KEY) client.on_connect on_connect client.connect(MQTT_BROKER, MQTT_PORT, 60) client.loop_start() def check_modbus_request(function_code, address): if function_code not in ALLOWED_FUNCTIONS: return False if address not in ALLOWED_REGISTERS: return False return True while True: try: modbus_client ModbusTcpClient(MODBUS_IP, portMODBUS_PORT, timeout3) if modbus_client.connect(): registers modbus_client.read_holding_registers( address0x0000, count10, slaveSLAVE_ID ) if registers.isError() or not hasattr(registers, registers): print(Modbus read error) else: # 只发布白名单范围内的寄存器 valid_data {} for i, val in enumerate(registers.registers): addr 0x0000 i if addr in ALLOWED_REGISTERS: valid_data[freg_{addr:04X}] val payload { timestamp: int(time.time()), device_id: device_01, data: valid_data, } result client.publish(MQTT_TOPIC, json.dumps(payload), qos1) if result.rc mqtt_client.MQTT_ERR_SUCCESS: print(fPublished: {json.dumps(payload)}) modbus_client.close() except Exception as e: print(fError: {e}) time.sleep(2)第四步在网关上做端口级访问控制。这一步的目的是即使有人渗透到了网关所在的网络也不能直接访问网关自身的服务iptables -A INPUT -p tcp --dport 22 -s 192.168.200.0/24 -j ACCEPT iptables -A INPUT -p tcp --dport 22 -j DROP iptables -A INPUT -p tcp --dport 502 -s 192.168.10.0/24 -j ACCEPT iptables -A INPUT -p tcp --dport 502 -j DROP iptables -A INPUT -p tcp --dport 8883 -j ACCEPT iptables -A INPUT -p tcp --dport 1883 -j DROP上面规则的含义是仅允许本地调试网段访问 SSH仅允许 Modbus 从站网段访问 502 端口外部统一从 8883 走 TLS 上 MQTT1883 明文端口直接关闭。3.3 实测验证与常见坑部署完成后我习惯用几台机器验证一下效果。第一步模拟一个 Modbus 从站可以用 Modbus Slave 工具或者直接用 mbpoll 命令行工具起一个虚拟从站mbpoll -a 1 -t 3 -r 0 -c 10 -0 192.168.10.10 -p 502然后跑起来网关脚本观察 MQTT Broker 端是否收到数据。再做一个逆向验证直接向网关的 502 端口发送一条非白名单请求比如写寄存器功能码 06看网关是否拦截。用nc手写报文# Modbus TCP 请求从站1功能码06寄存器0x0001值0x0064 printf \x00\x01\x00\x00\x00\x06\x01\x06\x00\x01\x00\x64 | nc -w 2 网关IP 502如果白名单已经把功能码 06 禁掉这条请求应该得不到正常响应同时日志中会新增一条拦截记录。下面把我在现场踩过的坑整理一下供参考寄存器大小端问题Modbus 寄存器 16 位一个 32 位浮点数要占两个寄存器字节序和字序都可能导致数据完全错误。建议在网关侧统一转换成小端或大端并在 MQTT 消息里带上数据格式描述。QoS 选择QoS 0 实时性最好但可能丢消息适合监控类数据QoS 1 能保证至少一次送达但可能有重复适合控制类指令。控制指令建议平台侧做幂等处理避免重复执行。断线重连Modbus TCP 从站有时会重启网关脚本必须处理connect失败的情况保证下次轮询能自动恢复。MQTT 客户端同样要设置重连机制否则网关卡死现场数据就断了。时间同步边缘网关如果离线运行系统时间会漂移日志里的时间戳就不可信。建议网关上配 NTP 客户端没有外网就手动设置一个可靠的本地时间源。内存泄漏Python 脚本长时间运行某些库可能在异常路径下悄悄积累内存。建议用watch -n 5 free -m观察内存变化每周定时重启一次服务或者直接用 systemd 的Restarton-failure做守护。这些坑单独看都不大但叠在一起足以让一个安全改造项目烂尾。工程上的“稳”往往就是一个一个细节磨出来的。4. 第 17 讲课后思考题完整解析上一讲我们重点聊了串口通信、RS-485 总线以及 Modbus RTU 的底层机制课后留了四道思考题。这里把完整解析写出来每道题都补充了推导过程和工程经验方便对照理解。4.1 题一UART 波特率误差计算题目某 MCU 外部晶振为 12MHz通过 PLL 倍频后得到系统时钟UART 外设分频后配置成 115200bps实际波特率存在 0.2% 的误差。请问该误差能否保证稳定通信给出计算依据。解析UART 是异步协议收发双方没有共享时钟靠波特率一致来保证正确采样。接收端通常以 16 倍波特率时钟采样在每个 bit 的中点附近采样一次。假设一帧数据包含 1 个起始位、8 个数据位、1 个停止位共 10 个 bit。如果波特率存在 0.2% 误差那么一个 bit 的时间误差不会累积超过整个帧长度理论1帧时间 10 × (1 / 115200) ≈ 86.81 μs 实际1帧时间 10 × (1 / (115200 × 1.002)) ≈ 86.63 μs 累积误差 86.81 - 86.63 0.18 μs 误差占1个bit时间的比例 0.18 / 8.68 ≈ 2.1%接收端采样点在 bit 中点只要累计偏移不超过半个 bit 时间约 50%都能采到正确电平。UART 实际工程上通常要求收发双方波特率误差小于 2%你这个 0.2% 远在安全范围内。另外要注意误差的方向也很关键。如果双方误差方向相反总误差是两个误差之和所以设计时尽量选同批次晶振或同一参考时钟源。4.2 题二RS-485 终端电阻与信号反射题目RS-485 总线上什么情况下必须加终端电阻为什么通常选 120Ω终端电阻是否每个节点都要加解析RS-485 靠 A/B 两线间的电压差传输信号信号在双绞线上传输遇到阻抗不连续的位置会产生反射。特性阻抗大约 120Ω 的双绞线如果末端不匹配反射波会叠加在原始信号上导致波形畸变、误码。工程上可以按两条标准判断通信线缆长度超过 10 米建议加终端电阻超过 30 米基本必须加。波特率波特率越高单个 bit 时间越短反射对采样的影响越明显9600bps 以下短距离可能不加也行115200bps 及以上务必加。终端电阻只需要在总线的最远两端各加一个 120Ω 电阻中间节点的设备不需要接。原因在于信号是沿着总线从一端传到另一端的只有在物理末端才需要做阻抗匹配。中间节点如果也接 120Ω等于给总线多挂了并联负载驱动能力不够时反而会拉低信号幅值。实际项目里我遇到过一种情况总线两端的终端电阻都没加设备偶尔通信失败用示波器看波形能看到明显的过冲和振铃。加上 120Ω 电阻之后波形一下子干净了。另外注意RS-485 的 A/B 线不能接反接反的典型表现是所有设备都不通信但示波器能看到差分信号存在。4.3 题三Modbus RTU 帧间隔 3.5 字符时间的计算题目为什么 Modbus RTU 要求帧与帧之间的间隔不小于 3.5 个字符时间以 9600bps、8 数据位、无校验、1 停止位为例计算 3.5 个字符时间是多少毫秒解析Modbus RTU 没有类似 TCP 的长度字段接收端靠“静默时间”来切分帧。发送完一帧后必须等待至少 3.5 个字符时间的空闲才表示这一帧结束接收端检测到总线上持续空闲超过 3.5 个字符时间就认为之前收到的数据是一整帧。先算一个字符的时间。UART 帧结构1 个起始位 8 个数据位 1 个停止位 10 bit无校验时。1 bit 时间 1 / 9600 ≈ 104.17 μs 1 个字符时间 10 × 104.17 μs ≈ 1041.7 μs 3.5 个字符时间 3.5 × 1041.7 μs ≈ 3645.9 μs ≈ 3.65 ms工程实现时很多协议栈会把这个值向上取整到 4ms甚至留 1ms 余量避免晶振误差导致误判。注意还有另一个关键间隔帧内部的字节间隔不能大于 1.5 个字符时间否则接收端认为帧提前结束。对于 9600bps1.5 个字符时间约 1.56ms。如果驱动里出现频繁发送“粘帧”大概率是发送间隔控制没做好。实测中有一个容易忽略的点RS-485 是半双工总线从发送切换到接收收发器本身需要时间一般几十微秒到几百微秒。如果主机发完请求立刻切到接收可能丢掉从站回复的前几个字节所以驱动程序里发送完成后要加一个小延时再切换方向。这个延时和波特率相关我一般取 0.5 个字符时间以上。4.4 题四为什么说 Modbus RTU 不校验数据内容但依赖 CRC16题目Modbus RTU 的 CRC16 能防止数据被篡改吗为什么它和 TCP/IP 的校验有什么区别解析CRC16 的本质是检错码不是防篡改的密码学校验。它能在噪声干扰、电平抖动等随机错误发生时大概率发现数据位翻转但无法抵御有意的恶意篡改。原因在于 CRC16 算法是公开的多项式固定攻击者只要知道报文内容就能重新计算 CRC16 并附在后面接收端根本看不出区别。TCP/IP 的校验和也是一样的逻辑它只验证传输过程中是否发生比特错误没有任何对抗恶意修改的能力。所以 Modbus RTU 或者 Modbus TCP 只要暴露给不可信网络就必须在协议上层做防护——要么通过网关隔离要么加应用层认证码比如 HMAC-SHA256。基于这个思路在讲解 Modbus 防护体系的第 18 讲里我建议对 RTU 报文做“CRC16 应用层消息认证码”双重校验。CRC16 承担物理层检错消息认证码承担防篡改两者缺一不可。这道题的核心结论是不要把检错和防篡改混为一谈。检错解决“线路噪声”防篡改解决“击者故意构造报文”。工控现场两者都会遇到但原因和手段截然不同。想通这一点再看第 18 讲的风险拆解就明白为什么单纯的 CRC 校验远远不够了。
