DDoS 报告里的“更多小规模攻击”：防护阈值、告警聚合与容量规划怎么改

先给出结论：这份报告里最值得开发者注意的，不是“攻击变大”，而是“攻击变密、变短、变小”。Cloudflare 称其网络在 2026 年第三季度（7—9 月）平均每小时自动缓解约 8,226 次网络层 DDoS 攻击，约合每 0.44 秒一次；其中 96% 在 10 分钟内结束，98% 峰值低于 1 Gbps（Cloudflare DDoS Threat Report 2026 Q3）。当攻击形态从“少数超大流量”转向“大量小流量”，只按带宽峰值设一个阈值，会同时产生两类错误：小攻击漏报；高频攻击让告警通道过载。下面按防护阈值、告警聚合、容量规划三部分说明怎么改，并标出哪些是报告事实、哪些是工程建议。

先对齐口径：这些数字描述的是谁的网络#

报告的统计对象是 Cloudflare 自有网络的缓解数据，时间窗为 2026 年 7 月至 9 月。报告称该季度在网络层缓解 1,820 万次攻击、在 HTTP 层缓解 14.4 万亿次请求，缓解流量分别为 272.6 PB 和 95.1 PB；报告还提到其网络覆盖 330 多个城市、容量 500 Tbps，这是厂商自述。这些数字是单厂商观测，不等于全网流量分布。把它当作“攻击形态变化的信号”比当作“所在行业的精确基线”更合适。

另一个需要留意的细节是 208% 这个数字。报告摘要写的是“持续 10 分钟以内、1 Gbps 以下的短时低带宽攻击激增 208%”，正文统计句则写“2026 Q3 网络层攻击 1,820 万次，较 2025 年同期增长 208%”。两处措辞指向的口径是否完全一致，需要对照原文图表确认；引用时建议保留原文表述，不要把它当成分项指标的独立结论。

阈值：把“峰值多少”换成“多快、多密、多短”#

98% 的攻击低于 1 Gbps，意味着只按带宽设阈值会漏掉绝大多数事件；但如果把阈值降到足以捕捉这些攻击，正常业务抖动又会被误判。可行的做法是把阈值拆成三个维度分别设条件，而不是合并成一个数。

• 速率维度：入向 pps / bps 相对于该目标同时段基线的偏离程度，而不是全网固定值。
• 连接维度：新建连接速率、半开连接数、单源并发数。报告称其他 UDP flood 占网络层攻击的比例从 14.06% 升至 31.31%，这类流量往往先在连接表上体现。
• 时间维度：检测窗口要短于攻击时长。96% 的攻击在 10 分钟内结束，如果检测窗口要 5 分钟、缓解下发又要几分钟，实际可用的防护窗口就很窄。

报告提到攻击者大量使用 booter（DDoS 租赁）服务，主要打击计算机软件、赌博与信息技术行业。这类攻击单次成本低、可重复发起，因此阈值策略还应包含“同一目标在时间窗内的累计触发次数”，否则单个小事件独立来看都不足以触发。

下表是分层思路的示意，不是厂商推荐值，也不是本文的测试结果；具体数值需要用自身业务基线标定。

告警聚合：按“目标 + 向量 + 时间窗”分组#

每小时 8,226 次攻击意味着平均每 0.44 秒就有一个事件。如果告警粒度是“一次攻击一条”，无论通知渠道还是值班人都承受不了。聚合的目标不是少报，而是让每条告警对应一个需要人做决定的问题。可以按以下三步处理：

1. 定分组键：目标资产 + 攻击向量（如 UDP flood、DNS 放大）+ 滚动时间窗（例如 15 分钟）。同一分组在窗口内只升级一次。
2. 分流自动与人工：已被平台自动清洗的事件记为计数指标，不进入呼叫通道；只有“缓解失败、跨阈值持续、命中未防护资产”才升级。
3. 保留原始计数：聚合告警里附上窗口内事件数、峰值与总量，避免“聚合”变成“看不见”。

报告称其系统在无人干预下完成检测与缓解，并强调多数攻击在人工看到告警前就已结束。对自建防护的含义是：告警系统的第一职责是确认自动缓解链路确实生效，第二职责才是通知人。

# 示意伪代码，未执行，仅说明聚合与升级结构
# 环境假设：事件流每条含 target_id、vector、started_at、peak_bps、mitigated
WINDOW_SECONDS = 15 * 60

def group_key(event):
    return (event.target_id, event.vector, event.started_at // WINDOW_SECONDS)

def should_page(group):
    # 只有“自动缓解未覆盖”或“窗口内累计次数超阈”才升级
    if not group.all_mitigated:
        return True
    return group.count >= group.count_threshold

容量规划：把“次数 × 时长”放进模型#

只盯着“最大攻击 Tbps”会低估小攻击的运营成本，也会高估超大攻击的常态频率。报告里两组数字要一起看：超过 1 Tbps 的网络层攻击从 Q2 的 805 次降到 Q3 的 251 次；同时 96% 的攻击在 10 分钟内结束，但该季度最长的一次 Mirai 类攻击持续了 49.7 小时（8 月 19—21 日）。前者说明“巨量攻击”数量在季度间波动很大，后者说明长尾时长可以远超短时攻击的画像。容量模型至少应包含以下几项：

• 清洗与带宽容量：按峰值 × 并发事件数估算，而不是单次峰值。
• 状态资源：连接表、会话表、限速桶。短时高频攻击会反复创建和释放状态。
• 下游管道：日志、计费、审计的写入量随“事件数”增长，而不是随“字节数”增长。1,820 万次事件对日志系统的压力，与 272.6 PB 流量是两条不同的曲线。
• 人工工时：值班响应时间 × 需人工介入的事件比例。

向量变化：规则不能只按上一季度热点配#

报告称 CLDAP 攻击环比下降 99.5%，Q3 仅占全部攻击的 0.05%；同期 DNS 放大增长 215% 至 3.43%，其他 UDP flood 升至 31.31%。这说明反射放大类规则要按协议族成套准备，而不是针对单个协议的峰值做永久扩容。CLDAP 的骤降可能与攻击工具切换有关，报告没有给出因果结论；不建议据此删除相关规则——保留规则的成本低，重新上线的成本高。

报告还提到，2026 年初针对 Aisuru、KimWolf、JackSkid、Mossad 四个 IoT 僵尸网络的执法行动，与超 1 Tbps 攻击数量下降在时间上重合；原文用“可能反映”这一措辞，属于推测而非因果证明。同时报告称新变种（Dysphoria、Evooo1Bot）仍在出现，Mirai 类在 8 月峰值达 57.23 PB，占当季网络层缓解字节的 46.5%。也就是说，不能因为“大攻击变少”就下调容量上限。

边界与待核实项#

• 报告数据仅覆盖 Cloudflare 网络；自建 IDC、区域运营商的分布可能明显不同。
• “208%”在两处表述中的统计口径是否一致，需对照原文与图表确认；本文按原文两处措辞分别保留，未做合并解释。
• 报告未披露各向量的检测延迟与误报率，因此无法据此设定具体阈值；上文分层表仅为示例，未经任何测试验证。
• “1 Gbps 以下足以压垮一台服务器或网站”是报告的说法，实际取决于目标配置，不宜直接当作基线。

可以落地的四件事#

1. 把阈值从单一带宽值改为“速率 + 连接 + 时间”三个条件，并加入同目标累计触发计数。
2. 告警按目标、向量、时间窗聚合；自动缓解事件进入指标层，只有缓解失败或命中未纳管资产才升级。
3. 容量模型同时计入事件次数与持续时间，日志与计费管道按事件数单独估算。
4. 反射放大规则按协议族保留，不因单一协议占比骤降而删除；季度数据只作为形态信号，不作为精确基线。