一、DTU概述与安全威胁
各位同学，咱们今天聊聊DTU。这东西在工业物联网里，说白了就是个“数据搬运工”。我做了十几年工控安全，见过太多因为DTU出问题的案例了。嗯，咱们先从最基础的讲起。
1.1 DTU是什么？
DTU，全称Data Terminal Unit，数据终端单元。它的核心任务就一个：把现场设备的数据，通过无线网络（比如4G/5G）传到远端服务器。
你想想看，工厂里的PLC、传感器、仪表，它们大多只支持串口（RS232/RS485）或者以太网。但现场离控制中心可能几十公里远，拉光纤成本太高。这时候DTU就派上用场了——它把串口数据打包成TCP/IP包，通过移动网络发出去。
核心功能三要素：
- 数据采集：从串口/网口读取设备数据
- 协议转换：把Modbus、PPI等工业协议封装成TCP/IP
- 无线传输：通过4G/5G/NB-IoT发送到云端
我记得2018年做一个水厂项目，现场用的就是某品牌的4G DTU。当时调试时发现，设备每隔5分钟上报一次水位数据，但服务器经常收不到。后来一查，是DTU的心跳包设置有问题。这种坑，我踩过不止一次。
1.2 DTU的工作原理
DTU的工作流程，其实不复杂。我习惯把它分成三步：
- 上电初始化：DTU启动后，先读配置文件，包括服务器IP、端口、APN（接入点名称）等。
- 拨号联网：通过AT指令控制4G模块拨号，获取IP地址。
- 建立连接：主动向服务器发起TCP/UDP连接，然后进入数据透传模式。
这里有个关键点：DTU通常是主动发起连接的一方。为什么？因为现场设备大多在内网，没有公网IP。DTU拨号后拿到的是运营商的内网IP，所以它必须主动连服务器。服务器只需要监听端口就行。
我的经验：很多初学者搞不清“主动连接”和“被动连接”的区别。记住一句话：DTU是“打电话”的人，服务器是“接电话”的人。如果DTU不主动打，服务器永远等不到数据。
数据透传模式下，DTU就是个“管道”。它不关心数据内容，只管把串口收到的字节流原封不动地发到服务器，反过来也一样。但正是这种“透明”，带来了安全隐患——你想想看，如果数据在传输过程中被截获，对方看到的就是明文的Modbus指令。
1.3 在工业物联网中的应用场景
DTU的应用场景，说白了就是“远、散、偏”的地方。我列几个典型的：
| 行业 | 典型场景 | 传输数据 |
|---|---|---|
| 水务 | 泵站、水厂、管网监测 | 水位、流量、压力、阀门状态 |
| 电力 | 配电房、光伏电站、充电桩 | 电压、电流、功率、开关状态 |
| 环保 | 污染源监测、空气质量站 | PM2.5、SO2、NOx、温度湿度 |
| 油田 | 油井、输油管道、储油罐 | 压力、温度、流量、液位 |
| 农业 | 大棚、灌溉、养殖场 | 土壤湿度、光照、CO2浓度 |
你看，这些场景有个共同点：设备分散在野外，无人值守，靠有线网络不现实。DTU加4G，成了最经济的选择。但问题也来了——这些数据一旦被篡改，后果可能很严重。
我举个例子。2019年某地一个污水处理厂，攻击者通过破解DTU的弱密码，远程修改了加药泵的启停指令。结果导致药剂过量投加，整个生化池的菌种全部死亡，停产了3天。这种损失，可不是几千块钱能解决的。
1.4 DTU面临的主要安全威胁
好了，前面铺垫了这么多，咱们进入正题。DTU面临的安全威胁，我归纳为四大类。这四种攻击，我在项目中都遇到过。
1.4.1 数据窃听
说白了就是“偷听”。攻击者在通信链路上部署嗅探设备，抓取DTU和服务器之间的数据包。
为什么会这样？因为很多DTU默认使用明文传输。Modbus RTU over TCP，数据包里的寄存器地址、数值，直接用Wireshark就能看到。我曾在某工厂做渗透测试，用一台笔记本连上现场的Wi-Fi，5分钟就抓到了PLC的启停指令。
注意：数据窃听最大的危害不是“被看到”，而是为后续攻击提供情报。攻击者通过分析数据包，可以摸清设备的控制逻辑、参数范围，然后精准地发动篡改攻击。
1.4.2 数据篡改
比窃听更危险的是篡改。攻击者截获数据包后，修改其中的内容，再转发出去。
举个例子。一个温度传感器上报“45℃”，攻击者改成“25℃”。服务器以为一切正常，实际上设备已经过热了。这种攻击在工业场景下，轻则导致产品质量不合格，重则引发火灾、爆炸。
我曾经参与过一个燃气管道监测项目。当时发现，DTU和服务器之间没有做任何完整性校验。理论上，攻击者只要在中间人位置，就能把“压力正常”改成“压力超限”，或者反过来。虽然最后没出事，但想想都后怕。
1.4.3 重放攻击
重放攻击，就是“录下来再放一遍”。攻击者先记录一段合法的数据包，然后在某个时间点重新发送。
你想想看，如果攻击者录下了“打开阀门”的指令，然后在半夜3点重放一次，会发生什么？阀门会莫名其妙地打开。更可怕的是，这种攻击很难被检测到，因为数据包本身是合法的，只是时间不对。
我记得有个案例：某水电站的闸门控制系统，用的就是DTU远程控制。攻击者通过重放攻击，在非调度时段打开了泄洪闸，导致下游水位暴涨。虽然最后查出来是重放攻击，但损失已经造成了。
我的建议：对抗重放攻击，最有效的手段是加时间戳和随机数。服务器收到数据包后，检查时间戳是否在合理范围内（比如±5秒），同时验证随机数是否被使用过。这样，录下来的包过几分钟就失效了。
1.4.4 设备劫持
设备劫持，是最高级别的威胁。攻击者完全控制了DTU，把它变成自己的“肉鸡”。
怎么做到的？常见的方式有：
- 弱口令爆破：很多DTU出厂默认密码是admin/admin，或者123456。攻击者用字典一跑就开了。
- 固件漏洞：DTU的Web管理界面存在命令注入、缓冲区溢出等漏洞，攻击者利用漏洞获取shell。
- 后门账号：有些厂商在固件里留了调试账号，忘了删掉。
一旦DTU被劫持，攻击者可以做很多事情：
- 修改DTU的配置，把数据转发到攻击者的服务器
- 以DTU为跳板，攻击内网的其他设备
- 植入恶意固件，让DTU变成僵尸网络的一员
我2017年做过一个应急响应。某工厂的DTU全部被劫持，攻击者利用它们发起了DDoS攻击，导致整个工厂的网络瘫痪。后来一查，所有DTU用的都是同一个默认密码。你说冤不冤？
总结一下：
- 数据窃听：明文传输，一抓一个准
- 数据篡改：无完整性校验，改了也不知道
- 重放攻击：录下来再放，合法但恶意
- 设备劫持：弱口令+漏洞，直接拿下
这四种威胁，不是孤立存在的。往往是先窃听，再篡改；先劫持，再重放。所以咱们做防护，得从整体考虑。
好了，第一章的内容就到这里。下一章咱们聊聊加密算法基础——怎么给DTU的数据穿上“防弹衣”。