MQTT 安全威胁分析：常见攻击场景与实战避坑
大家好，我是你们的讲师。今天咱们来聊聊 MQTT 协议里那些让人头疼的安全威胁。说实话，我在做物联网安全评估的时候，见过太多因为忽视这些基础威胁而翻车的项目了。你想想看，一个智能工厂的传感器数据被篡改，或者一个车联网的指令被重放，后果有多严重？
MQTT 协议本身设计得轻量高效，但它在安全方面其实留了不少「坑」。嗯，咱们今天就一个一个把它填上。
MQTT 中间人攻击（Man-in-the-Middle, MITM）
这是最经典的攻击场景之一。攻击者潜伏在客户端和 Broker 之间，拦截、修改甚至伪造通信数据。说白了，就是你的设备在和 Broker 说话，但中间有个「二道贩子」在偷听和篡改。
核心问题：MQTT 默认的 TCP 连接是明文传输的。攻击者只要在同一个网络里（比如公共 Wi-Fi、被攻破的路由器），就能轻松抓包。
我在一个智慧楼宇项目里就遇到过这种情况。客户反馈说某些灯控指令偶尔失效，排查了半天，发现是有人在楼道里用树莓派做了个 ARP 欺骗，把 Broker 的流量全给劫了。攻击者没改数据，只是「选择性丢弃」了一些关灯指令——你说气不气人？
要防这个，最直接的办法就是上 TLS/SSL 加密。但注意，光有加密还不够，还得做证书校验。我见过不少项目只配了 TLS 却没验证服务端证书，结果攻击者自己签个假证书照样能中间人。
避坑指南：我曾经在一个项目中看到开发人员把 Broker 的 CA 证书直接硬编码在客户端代码里，而且没做证书过期检查。结果证书过期那天，整个生产环境全部断连。记住：证书生命周期管理一定要纳入运维流程。
身份伪造（Identity Spoofing）
MQTT 的 Client ID 是客户端连接时的唯一标识。但问题来了——这个 ID 默认是明文传输的，而且很多 Broker 根本不校验这个 ID 是否合法。攻击者只要知道一个合法的 Client ID，就能冒充那个设备发布或订阅消息。
你想想看，如果攻击者冒充了一个温度传感器的 ID，往 Broker 里发了个「温度 200℃」的假数据，那后续的空调控制系统会怎么反应？
| 攻击方式 | 利用点 | 后果 |
|---|---|---|
| Client ID 伪造 | Broker 未校验 Client ID 合法性 | 冒充合法设备发布假数据 |
| 用户名/密码暴力破解 | 弱密码或无锁定机制 | 获取合法账户权限 |
| Token 窃取 | Token 明文传输或存储 | 直接使用窃取的 Token 连接 |
我个人习惯的做法是：Client ID + 用户名/密码 + 证书三层绑定。光有密码不够，光有证书也不够，三者必须同时匹配才能连接。我在一个车联网项目里就是这么做的，虽然配置麻烦了点，但从来没出过身份伪造的问题。
数据篡改（Data Tampering）
这个威胁和中间人攻击是「好兄弟」。攻击者截获了 MQTT 报文后，可以随意修改 Payload 里的内容，然后再转发出去。由于 MQTT 本身没有数据完整性校验机制（除非应用层自己加），接收方根本不知道数据被改过。
我记得有一次帮一个农业物联网项目做安全审计。他们的传感器上报土壤湿度数据，Broker 再根据数据控制灌溉阀门。攻击者把湿度值从 30% 改成了 80%，结果阀门一直不开，地里的苗全旱死了。这就是典型的数据篡改攻击。
注意：MQTT 的 QoS 机制只保证投递可靠性，不保证数据完整性。即使用了 QoS 2，数据在传输过程中仍然可能被篡改。
解决方案其实不复杂：应用层加数字签名或 HMAC。发布方对 Payload 计算签名，订阅方验证签名。我一般推荐用 HMAC-SHA256，性能开销小，安全性也够用。
重放攻击（Replay Attack）
攻击者不需要理解数据内容，只需要把之前抓到的合法报文重新发送一遍，就能达到攻击目的。比如，攻击者抓到了一个「打开车门」的指令，然后在你锁车离开后，把这个指令重放一遍——车门就开了。
MQTT 协议本身没有防重放机制。你可能会说：「我用 TLS 加密了，攻击者抓不到明文。」但加密只防窃听，不防重放。攻击者虽然看不懂数据，但他可以把整个加密报文原封不动地再发一次。
怎么防？我常用的办法是：在 Payload 里加入时间戳和序列号。接收方检查时间戳是否在允许的偏差范围内（比如 ±5 秒），同时检查序列号是否已经用过。我在一个智能门锁项目里就是这么做的，效果很好。
避坑指南：我曾经在一个项目中只加了时间戳，没加序列号。结果攻击者在同一秒内重放报文，时间戳校验通过了。后来我改成「时间戳 + 序列号」双校验，才彻底堵住这个漏洞。
拒绝服务攻击（Denial of Service, DoS）
MQTT Broker 是物联网系统的核心节点，一旦被 DoS 攻击打垮，整个系统就瘫痪了。攻击方式有很多种：
- 连接洪水：大量伪造的 CONNECT 报文耗尽 Broker 的连接资源
- 消息洪水：大量高频 PUBLISH 报文撑爆 Broker 的消息队列
- 订阅风暴：大量 SUBSCRIBE 请求导致 Broker 路由表膨胀
- 遗嘱消息滥用：利用 Will Message 机制让 Broker 不断处理假离线事件
我记得有个客户，他们的 MQTT Broker 用的是开源 Mosquitto，默认配置没做任何限制。结果被攻击者用 100 个僵尸设备同时发 CONNECT 报文，Broker 直接 OOM 崩溃了。恢复后他们问我怎么办，我说：「先把连接速率限制、消息大小限制、客户端数量限制都加上。」
| 防御措施 | 说明 | 推荐配置 |
|---|---|---|
| 连接速率限制 | 限制单位时间内来自同一 IP 的连接数 | 10 次/秒/IP |
| 消息大小限制 | 拒绝超过指定大小的 PUBLISH 报文 | 256KB |
| 客户端数量限制 | 设置 Broker 最大并发连接数 | 根据硬件资源设定 |
| Topic ACL | 限制客户端可发布/订阅的 Topic | 最小权限原则 |
未授权订阅（Unauthorized Subscription）
这个威胁在物联网场景里特别常见。攻击者只要知道 Topic 名称（很多项目 Topic 命名规则很简单，比如 sensor/temperature/001），就能直接订阅并窃取数据。
MQTT 的 Topic 是分层的，攻击者甚至可以用通配符 + 和 # 来订阅整个 Topic 树。比如订阅 sensor/# 就能拿到所有传感器数据。
我见过最离谱的一个案例：某智能家居厂商把所有设备的数据都发到 home/data/# 这个 Topic 下，而且 Broker 没开任何 ACL 认证。结果被一个安全研究员用手机上的 MQTT 客户端直接订阅了所有数据——包括门锁状态、摄像头画面、甚至孩子的活动轨迹。
核心原则：Topic 访问控制必须做到「最小权限」。每个客户端只能订阅它业务需要的 Topic，不能多给一个通配符权限。
我个人习惯的做法是：在 Broker 层面配置细粒度的 ACL，同时结合证书的 Common Name 或 Subject Alternative Name 来做 Topic 权限映射。比如，证书 CN 为 sensor-001 的设备，只能发布到 sensor/001/data，只能订阅 sensor/001/control。
威胁全景图
下面这张图是我自己整理的 MQTT 常见威胁全景图，方便大家从整体上理解这些攻击之间的关系。
这张图把攻击者、合法客户端和 Broker 之间的关系画清楚了。你看，攻击者可以从多个方向发起攻击，而防御措施也需要层层叠加，不能只靠单一手段。