DDoS 攻击变短变密之后：防护阈值与告警口径怎么改

Cloudflare 2026 Q3 DDoS 报告给出的关键变化不是“攻击变多了”，而是攻击的形状变了：单次更短、频次更高。对写告警规则的人来说，最直接的一条是——如果阈值仍以峰值带宽为唯一触发条件，这一季度 98% 的网络层攻击都落在阈值以下。

下面先列报告里可以直接引用的事实，再谈阈值为什么失效、告警口径怎么调整，最后说明这份报告的适用边界。文中所有建议均为推断或建议，不是报告结论。

报告里可以直接引用的事实#

据 Cloudflare 第 26 期 DDoS 威胁报告（覆盖 2026 年 7—9 月），其网络在该季度自动缓解了 1,820 万次网络层 DDoS 攻击和 14.4 万亿次 HTTP DDoS 请求，折算约每小时 8,226 次网络层攻击、每天约 197,400 次，即平均每 0.44 秒一次。缓解流量为网络层 272.6 PB、HTTP 层 95.1 PB。来源：Cloudflare DDoS Threat Report 2026 Q3

攻击形状方面，报告称本季度 96% 的网络层攻击在 10 分钟内结束，98% 低于 1 Gbps，并把这类“短促、中低带宽、高频次”的攻击描述为 DDoS-for-hire（租用式打站服务）的典型特征，主要指向软件、赌博与博彩、信息技术行业。

反向的变化是超大流量攻击减少：超过 1 Tbps 的网络层攻击从 Q2 的 805 次降至 Q3 的 251 次，降幅接近 69%。报告把这一下降与 2026 年初针对 Aisuru、KimWolf、JackSkid、Mossad 四个大型 IoT 僵尸网络的执法行动并置，用词是“possibly a reflection”，即推测性关联，不是因果结论。同一段落也指出，IoT 僵尸网络仍在衍生新变种（如 Dysphoria、Evooo1Bot），8 月 Mirai 类缓解流量峰值达 57.23 PB，占该季度网络层缓解字节的 46.5%，其中 8 月 16、19、23、25 日各超过 3 PB，最长的一次持续 49.7 小时。

攻击向量发生了剧烈切换：CLDAP（无连接轻量目录访问协议）洪水环比下降 99.5%，Q3 仅占全部攻击的 0.05%；DNS 放大增长 215%，占网络层攻击的 3.43%；其他 UDP 洪水从 14.06% 升至 31.31%。地理上，美国回到被攻击最多位置，中国第二，印度尼西亚以 2.93% 进入前三；加拿大从第 16 位升至第 6 位，以色列上升 7 位至第 10 位。

引用时有一处统计口径需要标注：报告摘要把 208% 的增长归于“持续 10 分钟以内、1 Gbps 以下的短促攻击”，正文中同一数字用于描述 1,820 万次网络层攻击相对 2025 年同期的同比增幅。两处是否完全同一统计定义，本次材料未给出更细说明，直接当成两个独立指标引用并不稳妥。

为什么旧阈值会失效：三处算术#

• 98% 低于 1 Gbps。以 1 Gbps 为下限的告警，最多只能看到 2% 的事件。这不是灵敏度问题，是覆盖范围问题。
• 96% 在 10 分钟内结束。人工确认加处置的时间通常以十分钟计。报告据此强调“自治”是重点：多数攻击在分析师看到告警之前就已经结束。这是自动缓解应优先于人工介入的量化理由。
• 每小时 8,226 次。如果每次都产生一条告警，一天接近 20 万条，告警本身会成为噪声源，真正需要处理的少数事件反而被淹没。

但“小”不等于“无害”。98% 的攻击低于 1 Gbps，这是带宽维度的分布，报告没有给出这些攻击造成的业务影响分布。对单机服务，几百 Mbps 的短促脉冲叠加应用层请求，足以触发超时与客户端重试放大。因此不能因为带宽低就整体降级处置。

告警口径怎么调：四个方向#

以下是基于上述数据提出的建议，不是报告给出的规范。

1. 缩短统计窗口。攻击时长集中在 10 分钟以内，5 分钟或 1 小时的均值会把短脉冲抹平。建议保留原始事件记录，另外计算 1 分钟滑窗指标。
2. 把事件频率作为主指标。“变密”体现在单位时间内的攻击次数，而不是单次峰值。频率异常比峰值异常更贴合这一季度的攻击形态。
3. 按向量分桶设基线。CLDAP 在一个季度内从上半年高增长跌到 0.05%，其他 UDP 从 14% 翻到 31%。用一套统一阈值，会同时产生误报和漏报。
4. 把“已缓解”和“有影响”分开。报告统计的是其网络内自动缓解的攻击次数，不等于业务受损。自己的告警也应至少分两层：被防护吸收的，和穿透到业务的。

一个示意性的告警规则（未执行）#

下面的片段只用来表达字段和判断顺序，不是可运行实现，也未在任何环境执行。阈值需要用自身流量基线确定，不能照搬报告中的数字。

# 未执行示例：仅示意告警口径，不是可运行代码
event = {
    "started_at": "...",       # 攻击开始时间
    "duration_s": 0,           # 持续秒数
    "peak_bps": 0,             # 峰值带宽
    "vector": "udp",           # udp | dns_amp | cldap | other
    "mitigated": True,         # 是否被防护自动吸收
    "business_impact": False,  # 是否有可观测的业务影响
}

def should_alert(events, now, window_s=60):
    recent = [e for e in events if now - e["started_at"] <= window_s]
    # 第一优先级：穿透防护或已产生业务影响
    if any(not e["mitigated"] or e["business_impact"] for e in recent):
        return "page"
    # 第二优先级：窗口内事件频率超过自身基线
    if len(recent) >= FREQ_THRESHOLD:
        return "ticket"
    return None

这份报告不能回答什么#

• 数据来自 Cloudflare 自有网络，统计的是“经过其网络且被其缓解”的攻击，不能直接当作全网攻击总量。
• 攻击“次数”依赖其检测与分类方法，跨厂商的计数不可直接比较。
• 季度环比受外部事件影响明显。报告自己对 1 Tbps 以上攻击下降使用“possibly”，属于推测，执法行动与攻击减少之间没有给出因果证据。
• 报告未提供各向量的误报率，也未提供攻击对业务影响的分布，这两项需要自己测量。
• 以上均为 2026 Q3 的数据，写作时点为 2026 年 11 月 1 日；后续版本可能修订口径。

上线前核对清单#

1. 现有告警的最小统计窗口是多少？能否捕捉 10 分钟以内的事件？
2. 触发条件是否只有带宽一项？事件频率是否单独记录？
3. 攻击向量是否有分类字段，还是全部混在一个计数里？
4. 告警能否区分“已缓解”与“有业务影响”？通知渠道是否分级？
5. 是否保留原始事件，而不只是聚合后的分钟均值？
6. 阈值是否来自自身历史基线，而不是其他网络报告中引用的数字？

报告能说明攻击长什么样，不能说明你的阈值该设多少。后者只能用自己的流量基线来定，并且要在下一次攻击形态变化时重新校准。