3. MQTT 安全威胁分析：中间人攻击、重放攻击、拒绝服务攻击、身份伪造
各位同学，咱们今天聊点实在的。MQTT 协议本身很轻量，但轻量不代表安全。我在车联网项目里摸爬滚打这几年，见过太多因为忽视安全威胁而翻车的案例。说白了，MQTT 在车联网里跑，就像一辆没上锁的智能汽车停在路边——看着高级，其实谁都能拉开车门。
这一节，我带你逐个拆解四种最常见的攻击方式。你想想看，攻击者会怎么对你的车联网系统下手？
核心观点：MQTT 协议本身只提供基础的安全机制（如 TLS 加密），但车联网场景下，攻击面远不止网络层。理解威胁，才能设计防御。
3.1 中间人攻击（MITM）
中间人攻击，说白了就是攻击者偷偷插在你和服务器之间。你发给服务器的数据，他先看一遍；服务器发给你的指令，他先改一遍。我在一个 TSP（Telematics Service Provider）平台项目中遇到过，攻击者伪造了一个假的 Broker，诱导车载终端连接上去。
为什么会这样？因为很多车厂早期为了省成本，MQTT 连接不启用 TLS。数据在网络上裸奔，谁都能抓包。
⚠️ 真实案例：某共享汽车平台，车载终端通过 MQTT 上报 GPS 位置和车门状态。攻击者在公共 Wi-Fi 环境下部署伪基站，截获了所有 MQTT 报文。结果是什么？攻击者可以实时追踪车辆位置，甚至远程解锁车门。
中间人攻击的典型流程：
- 嗅探：攻击者通过 ARP 欺骗或 DNS 劫持，将流量导向自己的设备。
- 拦截：攻击者截获 Client 与 Broker 之间的 CONNECT、PUBLISH、SUBSCRIBE 报文。
- 篡改：修改报文内容，比如把“车门锁定”改成“车门解锁”。
- 转发：将篡改后的报文发送给真正的 Broker 或 Client。
💡 我的建议：车联网场景下，TLS 是底线。别跟我说“TLS 增加延迟”，你想想看，车辆被远程控制的风险和几毫秒的延迟，哪个更重要？我习惯在车载端强制启用 TLS 1.3，并校验服务器证书的指纹。
3.2 重放攻击
重放攻击很有意思。攻击者不需要破解你的加密，他只需要把之前抓到的合法报文再发一遍。比如，他抓到你之前发送的“打开车窗”指令，然后在你开车时重放这个报文——车窗就莫名其妙打开了。
我记得有一次做渗透测试，发现某款 T-Box 的 MQTT 报文里没有时间戳和序列号。攻击者只要抓到一个合法的 CAN 总线控制指令，就能无限重放。嗯，这其实很危险。
重放攻击的防御要点：
- 时间戳校验：每条消息携带毫秒级时间戳，Broker 端校验时间差（一般容忍 5 秒以内）。
- 序列号机制：每条消息携带递增的序列号，Broker 记录已处理的最大序列号，重复的丢弃。
- 一次性 Token：每条消息使用一次性 Nonce，服务端校验 Nonce 是否已被使用。
| 防御手段 | 实现方式 | 抗重放能力 | 性能开销 |
|---|---|---|---|
| 时间戳 | 消息 Payload 头部携带 Unix 时间戳 | 中等（依赖时钟同步） | 低 |
| 序列号 | Client 维护递增计数器，Broker 记录 | 高（需持久化） | 中 |
| 一次性 Token | 每次请求前从 Broker 获取 Token | 极高 | 高（增加一次交互） |
避坑指南：我曾经在项目中只用了时间戳，结果发现车载终端 RTC 时钟漂移严重，导致大量合法消息被丢弃。后来我改成“时间戳 + 序列号”双校验，才彻底解决问题。
3.3 拒绝服务攻击（DoS）
拒绝服务攻击，就是让 Broker 忙到没空理你。车联网场景下，DoS 攻击的后果很严重——车辆收不到远程指令，紧急呼叫打不通，OTA 升级中断。
MQTT Broker 的 DoS 攻击常见手法：
- CONNECT 洪水：攻击者伪造大量 Client ID 发起连接，耗尽 Broker 的连接池。
- PUBLISH 洪水：攻击者以极高频率发布消息，填满 Broker 的缓冲区。
- SUBSCRIBE 滥用：攻击者订阅大量 Topic，导致 Broker 维护庞大的订阅树。
- 遗嘱消息炸弹：攻击者设置大量遗嘱消息，然后断开连接，触发 Broker 发送遗嘱。
⚠️ 真实教训：某新能源车企的 MQTT Broker 没有做连接速率限制。一次营销活动导致大量终端同时上线，Broker 瞬间被 CONNECT 报文淹没，整个车联网平台瘫痪了 2 小时。嗯，从那以后，我设计的 Broker 都强制开启连接限流。
防御 DoS 攻击，我建议从这几个维度入手：
- 连接限流：每个 IP 每秒最多允许 10 次 CONNECT 尝试。
- 消息速率限制：每个 Client 每秒最多发布 100 条消息。
- Topic 深度限制：订阅 Topic 的层级不超过 8 层。
- 黑名单机制：异常行为自动加入黑名单，封禁 30 分钟。
💡 我的习惯：在 Broker 前面加一层反向代理（如 Nginx + lua），在代理层做流量清洗。这样即使 Broker 被攻破，代理层还能挡住大部分攻击流量。
3.4 身份伪造
身份伪造，就是攻击者冒充合法设备接入 MQTT 网络。车联网里，每辆车都有一个唯一的 Client ID。如果攻击者伪造了这个 ID，他就能订阅这辆车的所有 Topic，甚至发布控制指令。
我记得有一次做安全审计，发现某款车机使用固定的 Client ID（比如 VIN 号），而且 MQTT 密码是硬编码在固件里的。攻击者只要反编译固件，就能拿到所有车辆的“身份证”。
身份伪造的常见场景：
- Client ID 伪造：攻击者使用已知的 Client ID 连接 Broker。
- 证书伪造：攻击者伪造客户端证书，绕过双向 TLS 认证。
- Token 窃取：攻击者通过钓鱼或中间人攻击获取 JWT Token。
| 认证方式 | 安全性 | 车联网适用性 | 部署复杂度 |
|---|---|---|---|
| 用户名 + 密码 | 低（密码易泄露） | 不推荐 | 低 |
| 客户端证书（双向 TLS） | 高 | 推荐 | 中 |
| JWT Token | 中（需配合短有效期） | 适合云端 | 中 |
| PSK（预共享密钥） | 中（密钥管理复杂） | 适合资源受限设备 | 低 |
核心建议：车联网场景下，我强烈推荐使用双向 TLS 认证。每辆车出厂时烧录唯一的客户端证书，证书绑定车辆 VIN 号。Broker 端校验证书的 CN 字段是否在白名单中。这样即使攻击者拿到了证书，也无法在其他车辆上使用。
嗯，这四种攻击方式，你仔细看会发现它们经常组合出现。比如，中间人攻击可以用来窃取 Token，然后进行身份伪造；身份伪造成功后，又可以发起重放攻击。所以，防御不能只防一种，要打组合拳。
💡 最后提醒一句：安全不是一锤子买卖。我见过太多项目上线时安全做得很好，但半年后证书过期、固件不更新，又回到了裸奔状态。安全需要持续运营，定期做渗透测试，及时更新黑名单和证书。