Cloudflare 2026 Q3 DDoS 报告：攻击频次上升时，告警该按什么口径聚合

先给结论：当攻击从“少而大”变成“多而小”，告警不能只按单次峰值画一条线。比较可行的口径是三步——先把“一次攻击”定义清楚，再分三层聚合：单事件层看峰值与持续时长，分钟级窗口看去重后的事件计数，小时或天级看基线偏移与向量分布。Cloudflare 2026 Q3 报告给出的分布，正好解释了为什么单一阈值会同时产生漏报和噪声。

报告里能直接用的数字，先标注口径#

Cloudflare 在 2026 年 10 月 29 日发布的第 26 期 DDoS 威胁报告覆盖 2026 年 7 月至 9 月。以下数字均来自该报告，统计对象是 Cloudflare 全球网络，不是任何单个站点。

• 规模：该季度自动缓解 1,820 万次网络层 DDoS 攻击和 14.4 万亿次 HTTP DDoS 请求；换算约每小时 8,226 次网络层攻击、每天约 197,400 次，即每 0.44 秒一次。
• 流量：网络层缓解流量 272.6 PB，HTTP 层 95.1 PB。
• 形态：96% 的攻击在 10 分钟内结束，98% 低于 1 Gbps。
• 超大流量攻击：超过 1 Tbps 的网络层攻击从 Q2 的 805 次降到 Q3 的 251 次，降幅接近 69%。报告把这一变化与 2026 年初针对四个大型 IoT 僵尸网络（Aisuru、KimWolf、JackSkid、Mossad）的执法行动联系起来，用词是“可能”。
• 向量迁移：CLDAP 攻击季度环比下降 99.5%，Q3 仅占全部攻击的 0.05%；DNS 放大上升 215%，占网络层攻击 3.43%；其他 UDP 洪水从 14.06% 升到 31.31%。
• Mirai 类：8 月缓解量峰值 57.23 PB，占 Q3 网络层缓解字节的 46.5%；8 月 16、19、23、25 日各有单日超过 3 PB；最长的一次持续 49.7 小时。

有一处口径需要单独说明。报告正文把“+208%”标在 1,820 万次网络层攻击相对 2025 年同期的增长上，随后用 96% 和 98% 描述这批攻击的时长与带宽分布；而文章摘要把 208% 描述为“持续不到 10 分钟、低于 1 Gbps 的短时攻击”的增长。两者可能指向同一组数据的不同说法，但材料没有给出可以区分的两个数字。具体口径待核实，引用时建议按正文写法，注明是网络层攻击总量的同比。

为什么单看峰值会同时漏报和误报#

把上面的分布放到告警设计里，问题很直接。

如果按峰值带宽设阈值，比如 1 Gbps：报告称 98% 的攻击低于这个值。也就是说，绝大多数事件根本不会触发告警，而它们叠加起来的频次已经足以让服务不可用——报告里短时攻击主要打的是计算机软件、赌博与博彩、信息技术行业。

如果把阈值压低到能抓住这些小攻击：计数会迅速膨胀。全球口径是每 0.44 秒一次，即便单个站点只占极小比例，按事件逐条告警也会让值班通道失效。

如果用小时级聚合再平均：96% 的攻击不到 10 分钟，在一小时的窗口里会被稀释成一条平缓的曲线，峰值特征消失。

所以问题不在于“阈值定多少”，而在于用哪个维度、在哪个窗口上判定。峰值和计数回答的是两个不同问题：前者问“这次有多猛”，后者问“这段时间来了多少次”。频次上升时，后者必须先成立。

先把“一次攻击”定义清楚#

报告里的“mitigated attack”是 Cloudflare 自己的计数单位，它如何合并同一波攻击的多个数据包，材料没有展开。自建告警不能直接沿用这个单位，需要先给出自己的合并键。

建议的合并键至少包含四项：

• 目标资产：域名、IP、端口或业务线，取决于你的资产粒度。
• 攻击向量：SYN 洪水、UDP 洪水、DNS 放大、HTTP 应用层请求等。
• 源侧特征：源 IP 或 /24 网段集合，用于把同一批反射源归并。
• 时间邻近：间隔小于某个间隙（例如 60 秒）的相邻记录视为同一次事件。

合并键决定告警条数，也决定后续统计的分母。键太细，一次攻击会被拆成几十条；键太粗，不同攻击会被压成一条，掩盖向量迁移——而报告里 CLDAP 从 0.05%、DNS 放大升到 3.43%、UDP 升到 31.31%，这类结构变化恰恰需要靠向量维度才能看见。

三层聚合口径#

下面是一张可落地的分层表。三层不是替代关系，而是各自回答不同问题。

关于窗口长度，这里有一条推断：既然报告称 96% 的攻击在 10 分钟内结束，那么 L2 的抑制窗口如果短于这个量级，同一波攻击会被反复拆开告警；如果远长于它，又会把紧随其后的第二波吞掉。取 10 分钟上下作为起点是合理的，但这是推断而非报告结论，需要用自身流量回放验证。

一个可核对的聚合骨架#

下面的代码只示意聚合口径，未执行，也不连接任何真实数据源。环境假设为 Python 3.10+，只用标准库。阈值写成占位符，必须按自身资产基线填入。

# 未执行的示例：仅示意聚合口径
from collections import defaultdict
from dataclasses import dataclass, field

WINDOW_SEC = 600            # 10 分钟，与报告里 96% 攻击的时长对齐
PEAK_THRESHOLD_BPS = 0      # 占位：按自身资产基线设定
COUNT_THRESHOLD = 0         # 占位：按自身历史分位数设定
GAP_SEC = 60                # 相邻记录合并的最大间隔

@dataclass
class Bucket:
    events: int = 0
    keys: set = field(default_factory=set)
    peak_bps: int = 0
    bytes_total: int = 0
    vectors: dict = field(default_factory=lambda: defaultdict(int))

def merge_key(evt):
    # 合并键：目标 + 向量 + 源网段，可按资产粒度增删
    return (evt["asset"], evt["vector"], evt["src_prefix"])

def fold(events, now):
    buckets = defaultdict(Bucket)
    for e in events:
        if now - e["ts"] > WINDOW_SEC:
            continue                       # 窗口外丢弃
        w = int(e["ts"] // WINDOW_SEC)     # 按窗口分桶
        b = buckets[(e["asset"], w)]
        b.events += 1
        b.keys.add(merge_key(e))
        b.peak_bps = max(b.peak_bps, e["bps"])
        b.bytes_total += e["bytes"]
        b.vectors[e["vector"]] += 1
    return buckets

def verdict(b):
    # 双指标：峰值或去重计数任一越线即告警
    if b.peak_bps >= PEAK_THRESHOLD_BPS:
        return "peak"
    if len(b.keys) >= COUNT_THRESHOLD:
        return "count"
    return None

这段骨架里有三个刻意的选择：一是用 merge_key 去重，避免同一波攻击被源地址数量放大；二是峰值与计数分别判定，对应前文说的两个问题；三是把窗口边界对齐到固定刻度，让不同批次的结果可以对比。实际落地时还要补上分组基数上限，否则按资产乘向量分组会在攻击期间产生大量新分组。

落地时的几个边界#

全球报告不等于本地基线。报告的数据覆盖 Cloudflare 全球网络、330 多个城市、500 Tbps 容量，且由其系统自动缓解。单个业务的入口带宽、清洗能力和流量结构都不同，报告只能提供量级与形态参考，不能直接换算成阈值。

自动缓解不等于不需要告警。报告强调其系统在没有人工介入的情况下完成检测与缓解，并称多数攻击在分析师看到告警前就已结束。这句话对自建告警的启示是：告警的价值不在于“叫人来打”，而在于留下可复核的记录、发现基线漂移、以及在自动策略失效时兜底。

分组基数要设上限。向量维度很有用，但攻击期间新向量、新源网段会快速增加分组数量。建议对 L2 的分组数设硬上限，超出部分归入“其他”，并单独统计被归并的数量。

第三方接口场景要单独定口径。如果你的服务通过第三方 API 平台接入，入口侧的限流、超时与重试会改变你观察到的错误分布，此时按“请求失败数”聚合容易把平台侧限流误判为攻击。这类场景下，告警口径应绑定自身可观测的维度，而不是照搬网络层指标。平台侧的具体行为与配额待核实，需要以实际文档和自身日志为准。

小结#

报告给出的核心事实是：攻击总量在涨，但单个攻击在变短变小——96% 不到 10 分钟，98% 低于 1 Gbps，同时 1 Tbps 以上的攻击数量反而下降。这个组合意味着告警设计的重心要从“抓最大的那一次”转向“数清楚来了多少次”。

可执行的顺序是：先定义事件合并键，再确定三层窗口，然后用峰值与计数双指标判定，最后限制分组基数并定期回看向量分布。每一步都应留下可复核的记录，而不是只留一个阈值数字。