17、BLE拒绝服务攻击：连接请求洪泛、MTU协商耗尽、GATT操作风暴、设备资源耗尽
说到BLE安全，大家第一反应往往是配对破解、密钥窃取。但说实话，在实际攻防中，拒绝服务（DoS）攻击才是让设备“死”得最难看的方式。设备不响应了、蓝牙断连了、甚至直接重启了——这些场景我在项目里见过太多次。
今天我们就来聊聊BLE的四种典型DoS攻击手法。嗯，每一种我都踩过坑。
4.1 连接请求洪泛（Connection Request Flooding）
这是最粗暴的一种。攻击者疯狂发送CONNECT_REQ PDU，让目标设备的链路层疲于处理连接事件。
你想想看，BLE芯片的连接状态机是有限的。大多数芯片只能同时维护3到8个连接。一旦连接请求超过这个阈值，设备就会进入“假死”状态——新的合法连接进不来，已有的连接也可能被踢掉。
核心原理：攻击者伪造多个随机蓝牙地址，发起大量连接请求。设备每接受一个连接，就要分配内存、启动连接事件定时器、配置链路层参数。这些操作都是耗资源的。
我在做智能门锁项目时遇到过类似问题。测试阶段，我们用三台手机同时连接，门锁就挂了。后来一查，是连接队列溢出导致系统panic。嗯，从那以后我养成了一个习惯：所有BLE设备必须做连接数上限保护。
防御方案
- 连接速率限制：单位时间内只接受N个连接请求，超出则忽略
- 白名单过滤：只接受已知设备的连接
- 连接超时机制：对未完成配对的连接，30秒内强制断开
4.2 MTU协商耗尽（MTU Negotiation Exhaustion）
这个攻击手法比较“阴”。攻击者反复发起MTU（最大传输单元）协商请求，每次协商都要求一个极大的MTU值。
为什么会造成问题？因为MTU协商需要分配缓冲区。你想想，如果设备默认MTU是23字节，攻击者要求协商到512字节，设备就得重新分配一块512字节的缓冲区。反复协商几十次，内存就炸了。
我个人的经验：曾经有个IoT设备，内存只有64KB。攻击者连续发起20次MTU协商请求，设备直接OOM（内存耗尽）。后来我们加了一个限制：每次连接只允许协商一次MTU。
攻击流程
- 攻击者建立BLE连接
- 发送
MTU Request，请求值设为最大（如512） - 设备响应后，攻击者立即断开连接
- 重新连接，再次发起MTU协商
- 循环往复，直到设备内存耗尽
防御建议
- 限制每个连接的MTU协商次数（建议1次）
- 设置MTU协商冷却时间（如30秒内不可重复协商）
- 对MTU请求值做上限检查，拒绝不合理的大值
4.3 GATT操作风暴（GATT Operation Storm）
这是我最头疼的一种攻击。攻击者通过大量GATT读写操作，让设备CPU满载、蓝牙协议栈崩溃。
具体来说，攻击者会：
- 频繁读取特征值（每秒几百次）
- 写入大量数据到可写特征
- 反复开启/关闭通知（Notification/Indication）
- 遍历所有服务和特征，发起无效操作
我记得有一次，客户反馈他们的手环在连接某些手机时会死机。我们抓包一看，是某款手机在后台疯狂轮询所有特征值，每秒发起超过200次GATT操作。手环的MCU根本扛不住。
注意：GATT操作风暴不仅消耗CPU，还会大量占用蓝牙链路层的带宽。正常的数据传输会被严重干扰，甚至完全中断。
防御策略
| 防御手段 | 说明 | 推荐值 |
|---|---|---|
| 操作频率限制 | 每秒最多处理N次GATT操作 | 50次/秒 |
| 操作队列深度 | GATT请求队列最大长度 | 16 |
| 特征值访问控制 | 对敏感特征增加认证/授权检查 | 必须配对 |
| 通知频率限制 | 每秒最多发送N次通知 | 10次/秒 |
4.4 设备资源耗尽（Device Resource Exhaustion）
这是前面三种攻击的“集大成者”。攻击者综合利用多种手段，让设备的CPU、内存、电池、蓝牙带宽全部耗尽。
说白了，就是让设备“累死”。
常见的资源耗尽手法包括：
- CPU耗尽：大量加密计算请求（如反复配对）
- 内存耗尽：MTU协商 + GATT操作风暴组合
- 电池耗尽：保持连接 + 频繁通知，让设备无法进入休眠
- 带宽耗尽：大量数据写入，占满链路层带宽
真实案例：我曾经分析过一个蓝牙耳机被“玩死”的案例。攻击者通过反复配对-断开-再配对，让耳机的加密引擎持续工作。半小时后，耳机电池从100%掉到15%。用户还以为是电池坏了。
知识体系总览
下面这张图总结了四种DoS攻击的核心逻辑和防御思路。我建议你保存下来，做开发时对照着看。
写在最后
BLE拒绝服务攻击，说白了就是“欺负”设备资源有限。你想想，一个智能手环可能只有64KB内存、几十MHz主频，攻击者稍微用点力，设备就扛不住了。
我个人建议，在做BLE产品开发时，一定要把DoS防护当成功能需求来写。不要等到产品上市了，被用户投诉“连不上”、“死机”了才来补。那时候就晚了。
嗯，这一章的内容就到这里。记住一句话：在BLE的世界里，拒绝服务不是“能不能”的问题，而是“什么时候发生”的问题。提前做好防护，比事后补救强一百倍。