1. MQTT协议安全威胁全景
MQTT 协议，说白了就是物联网世界的「信使」。它轻量、省带宽，特别适合传感器、嵌入式设备这些资源受限的场景。但轻量也意味着安全机制相对薄弱——我刚开始接触 MQTT 时，总觉得它就是个发布/订阅的消息管道，能出什么大问题？直到在一次车联网项目中，亲眼看到攻击者通过伪造终端发送虚假定位数据，导致整个调度系统瘫痪……嗯，从那以后我再也不敢轻视 MQTT 的安全防护了。
这一章，咱们先把 MQTT 面临的主要安全威胁梳理清楚。你只有知道「敌人」长什么样，才能有针对性地布防。
1.1 中间人攻击（Man-in-the-Middle, MITM）
中间人攻击是 MQTT 通信中最常见的威胁之一。攻击者通过 ARP 欺骗、DNS 劫持或伪造 Broker 等手段，插入到客户端与 Broker 之间，窃听甚至篡改所有通信数据。
我在一个智能家居项目中遇到过这种情况：客户反馈灯控指令偶尔失灵，排查后发现是有人用树莓派在楼道里做了 ARP 欺骗，拦截了手机 App 发给 Broker 的开关指令。后来强制启用 TLS 加密，问题才彻底解决。
防护要点：
- 强制使用 TLS/SSL 加密通信（MQTT over TLS，端口 8883）
- 客户端验证 Broker 证书，防止伪造 Broker
- 使用双向认证（客户端证书 + Broker 证书）
1.2 重放攻击（Replay Attack）
重放攻击，说白了就是攻击者把截获的合法消息「原封不动」地重新发送一遍。MQTT 协议本身没有消息唯一性校验，所以重放攻击很容易得手。
举个例子：攻击者截获了一条「打开车库门」的 MQTT 消息，然后反复重放这条消息——你的车库门就会不停地开、关、开、关……
防护要点：
- 消息中加入时间戳（Timestamp）和一次性随机数（Nonce）
- 服务端校验消息的唯一性，拒绝重复消息
- 使用消息序列号（Sequence Number）并做连续性校验
1.3 拒绝服务攻击（Denial of Service, DoS）
MQTT Broker 本身是资源密集型服务，面对大量恶意连接或消息洪泛时很容易崩溃。常见的 DoS 攻击方式包括：
| 攻击类型 | 攻击方式 | 危害 |
|---|---|---|
| 连接洪泛 | 大量伪造 CONNECT 报文 | 耗尽 Broker 连接池，拒绝合法客户端 |
| 消息洪泛 | 高频发布大量消息 | 堵塞 Broker 消息队列，导致正常消息延迟或丢失 |
| 订阅爆炸 | 客户端订阅大量通配符主题 | 消耗 Broker 内存和 CPU，影响路由性能 |
| 遗嘱滥用 | 恶意设置大量遗嘱消息 | Broker 需要维护大量遗嘱，异常断开时集中触发 |
我记得有一次做压力测试，用 1000 个模拟客户端同时向 Mosquitto Broker 发起 CONNECT 请求，结果 Broker 直接 OOM 挂掉了。你想想看，如果这是生产环境，后果不堪设想。
防护要点：
- 限制单个客户端的连接速率和消息发布频率
- 设置最大客户端连接数、最大订阅数
- 启用连接认证，拒绝未授权客户端的连接请求
- 使用反向代理（如 Nginx、HAProxy）做流量清洗
1.4 身份伪造（Identity Spoofing）
MQTT 的客户端身份认证机制非常基础——默认只靠 Client ID 和用户名/密码。如果这些凭证泄露或被暴力破解，攻击者就能伪装成合法客户端。
更可怕的是，MQTT 协议允许客户端自定义 Client ID。攻击者完全可以伪造一个与合法设备相同的 Client ID 来连接 Broker，导致原设备被踢下线（Session 冲突）。
防护要点：
- 使用 X.509 证书进行双向认证
- 启用强密码策略，定期轮换凭证
- 结合 IP 白名单或 MAC 地址绑定
- 使用 OAuth 2.0 或 JWT 等现代认证机制
1.5 消息篡改（Message Tampering）
消息篡改发生在攻击者已经成功实施中间人攻击之后。攻击者可以修改 MQTT 消息的 Payload，甚至篡改 Topic 名称，将消息路由到错误的主题。
举个例子：在智能电网场景中，攻击者截获了「关闭 3 号断路器」的指令，将其篡改为「关闭 1 号断路器」——这可能导致大面积停电事故。
防护要点：
- 使用 TLS 加密传输，防止中间人篡改
- 消息体使用 HMAC 或数字签名进行完整性校验
- 服务端对消息 Payload 做合法性校验（如 JSON Schema 验证）
1.6 威胁全景图
下面这张图，是我梳理的 MQTT 安全威胁全景。它把攻击面、攻击手段和防护措施串在了一起，方便你建立全局视角。
1.7 威胁优先级与应对策略
面对这么多威胁，不可能一次性全部解决。我个人习惯按「风险等级」来排优先级：
| 威胁类型 | 风险等级 | 优先级 | 推荐措施 |
|---|---|---|---|
| 中间人攻击 | 极高 | P0（立即修复） | 强制 TLS，禁用明文端口 |
| 身份伪造 | 高 | P0（立即修复） | 双向证书认证 + 强密码策略 |
| 消息篡改 | 高 | P1（尽快修复） | TLS + 消息签名 |
| 拒绝服务攻击 | 中高 | P1（尽快修复） | 速率限制 + 连接数限制 |
| 重放攻击 | 中 | P2（计划修复） | 时间戳 + Nonce + 序列号 |
1.8 本章小结
MQTT 协议的安全威胁，说白了就是三个维度：通信被窃听（中间人攻击）、身份被冒充（身份伪造）、消息被破坏（篡改、重放、拒绝服务）。
建立全局视角的意义在于：你不需要一次性解决所有问题，但必须知道「敌人」可能从哪里来。后面的章节，我会逐一拆解每种威胁的防护方案，包括 TLS 配置、证书管理、ACL 权限控制、消息加密等实战内容。
嗯，这一章就到这里。记住一句话：安全不是功能，而是整个系统的属性。从设计的第一天起，就要把安全考虑进去。