短促高频 DDoS 攻击下，告警窗口、采样粒度与限速策略怎么改

先给结论：把告警从“分钟均值加持续 N 分钟”改成“短评估窗口命中加分级升级”，把采样分辨率前移到入口侧并按路由与协议保留秒级聚合，把限速从按带宽改成按请求速率与并发的双层令牌桶，同时对 UDP 反射向量做入口侧过滤。这四条分别对应短促攻击的三个特征：持续时间短、单次带宽低、靠请求数而不是字节数压垮服务。

报告里的攻击形态发生了什么变化#

Cloudflare 在 2026 年第三季度 DDoS 威胁报告中给出的数据是：当季其网络自主缓解了 1820 万次网络层 DDoS 攻击和 14.4 万亿次 HTTP DDoS 请求，折算约每小时 8,226 次网络层攻击、每天约 197,400 次，即平均每 0.44 秒一次。网络层缓解流量合计 272.6 PB，HTTP 层 95.1 PB。网络层攻击总量较 2025 年同期增长 208%。

更关键的是分布：96% 的攻击在 10 分钟内结束，98% 的带宽低于 1 Gbps。报告把这些短促、中低带宽、高数量的攻击归为 DDoS-for-hire（按次租赁的“booter”）服务的典型特征，主要打在计算机软件、赌博与博彩、信息技术行业。与此同时，超过 1 Tbps 的超大规模攻击从第二季度的 805 次降到第三季度的 251 次，降幅接近 69%；报告认为这可能与 2026 年初针对四个大型 IoT 僵尸网络（Aisuru、KimWolf、JackSkid、Mossad）的执法行动有关，但同时强调 IoT 僵尸网络仍是持久的高流量威胁。

攻击向量的迁移同样值得注意：CLDAP（无连接轻量目录访问协议，UDP 389）洪水在第三季度降到仅占攻击总数的 0.05%，环比下降 99.5%；DNS 放大上升 215%，占网络层攻击的 3.43%；其他 UDP 洪水从 14.06% 升至 31.31%。这几类都是“伪造源 IP 的小请求换大响应”的反射放大模式，或者直接灌 UDP 包迫使目标消耗网络与计算资源。

对 API 平台来说，这些数字的含义是：你更可能遇到的是几十秒内错误率和连接数突然飙升，而不是带宽被打满。只监控出向与入向流量，或者只按 Gbps 设阈值，会漏掉绝大多数事件。

告警窗口：从“持续触发”改为“短窗命中加分级”#

分钟级均值会把短尖峰摊平。一次持续 40 秒、把错误率推到 30% 的攻击，在 5 分钟均值里只剩 4%，低于多数人的告警阈值。如果规则再要求“持续 3 分钟”，而 96% 的攻击在 10 分钟内就结束了，判定往往发生在攻击收尾之后。

建议的改法：

• 评估窗缩短到 15–30 秒。如果用 Prometheus 的 rate()，窗口至少要覆盖两个抓取间隔，否则会得到锯齿状结果。抓取间隔 15 秒、评估窗 30 秒是常见组合。
• 基线按同星期同小时取。API 流量有强周期性，用固定绝对值做阈值早晚会误报或漏报。用 7 天或 28 天同时段的分位数做参照，比用昨天同一时刻更稳。
• 用“连续命中窗口数”分级，而不是单一持续时长。单窗偏离只记录不通知；连续两窗命中发通知；连续三窗或跨 5 分钟仍偏离才升级为事故。这样短攻击会被记录成事件，但不会把值班人员叫醒一次就结束的噪声。
• 把抑制期和升级路径分开。告警抑制是为了不刷屏，不能顺手把升级也抑制掉。

下面是一个结构示意，未执行，仅说明拆窗与分级的关系：

# 未执行示例：仅示意短窗检测与分级，阈值需自行标定
groups:
- name: edge-burst
  rules:
  - record: api:err_ratio_30s
    expr: |
      sum by (route) (rate(http_requests_total{status=~"5.."}[30s]))
      /
      sum by (route) (rate(http_requests_total[30s]))

  - alert: APIErrorBurstShort
    # 连续 2 个评估周期命中才通知，单周期只留痕
    expr: api:err_ratio_30s > 0.15
    for: 1m
    labels:
      severity: warning

  - alert: APIErrorBurstSustained
    expr: api:err_ratio_30s > 0.15
    for: 3m
    labels:
      severity: critical

需要核实的一点：不同监控栈对 for 与评估间隔的组合语义略有差异，落地前应先确认你使用的版本在评估间隔变化时如何计算持续时间。

采样粒度：分辨率要留在入口侧#

短攻击在中心侧做 60 秒聚合就消失了。可行的做法是把聚合位置前移：边缘节点按 1 秒计数，按 10 秒向上汇报；中心只保存已经按路由模板聚合好的时间序列，不保存原始请求维度。

• 标签用路由模板，不用原始 URL。/v1/orders/:id 是一个标签值，/v1/orders/8842 不是。否则标签基数会让存储先于攻击崩溃。
• 保留 top-k 而不是全量。源 IP、ASN、目标端口、协议这几类维度，按窗口保留前 K 个即可。排查时通常只需要知道“前 100 个来源贡献了多少比例”。
• 日志侧用触发式采样。常态低采样率，检测到短窗异常时临时提高采样并写入环形缓冲，事后可以回看攻击窗口内的完整请求。这个方案的成本与保留时长需要按自身流量估算，不能照抄。
• UDP 侧单独统计。网络层攻击不体现在 HTTP 指标里。至少要有按协议和端口的数据包速率与源地址分布。

粒度提高的代价是存储与采集开销。比较务实的顺序是先确认入口侧是否具备秒级计数能力，再决定中心侧保留多久的高分辨率数据。

限速策略：按请求速率分层，别按带宽#

98% 的攻击低于 1 Gbps，说明攻击者不需要大带宽就能压垮单台服务器。限速的目标因此不是“挡住流量”，而是“保住并发与队列”。

建议用两层令牌桶：

1. 突发桶：秒级、容量小、补充快。吸收正常用户的短促突发，同时把异常突发截断。
2. 持续桶：分钟级、速率低。限制长期占用，防止攻击者用略低于突发阈值的速率持续消耗。

再加一层并发连接上限，因为短攻击常用大量半开连接或慢请求占住 worker。惩罚时长要有上限并做指数退避，例如从 10 秒起、上限 60 秒；一次封 10 分钟，在短攻击场景里等于用一次误判换来十分钟的业务损失。

# 未执行示例：Nginx 限速分层结构示意，需按版本验证串联行为
limit_req_zone  $binary_remote_addr zone=api_burst:20m     rate=20r/s;
limit_req_zone  $binary_remote_addr zone=api_sustained:20m rate=5r/s;
limit_conn_zone $binary_remote_addr zone=conn_per_ip:10m;

server {
    limit_conn conn_per_ip 30;

    location /v1/ {
        limit_req zone=api_burst     burst=40  nodelay;
        limit_req zone=api_sustained burst=100;
        limit_req_status 429;
        # 慢请求同样占用连接，超时值要一起收紧
        client_header_timeout 10s;
        client_body_timeout   10s;
    }
}

两个 zone 同时生效时，请求需要同时满足两层才被放行；burst 设得过大等于没有限速，设得过小会误伤正常的批量调用。这两个值必须用自己的流量分布来定，不能直接采用示例数字。

对 UDP 反射向量，限速通常不是第一道防线。更有效的是入口侧策略：不对外提供开放 DNS 解析器和 CLDAP 服务，对 UDP 389、53 等端口的入向请求做源地址校验，并在上游落实 BCP 38（源地址伪造过滤）。报告显示 CLDAP 占比已降到 0.05%，但 DNS 放大与其他 UDP 洪水合计已超过三成，这部分仍然需要在网络边界处理。

落地顺序#

1. 先确认入口侧能给出 10 秒粒度的分路由计数，以及网络层的协议与端口分布。没有这个前提，后面几步都无法验证效果。
2. 改告警：缩评估窗、换基线、加分级。先用观察模式跑一到两周，比对旧规则漏掉了哪些事件。
3. 调限速：先加并发上限与突发桶，观察误伤率，再收紧持续桶。
4. 做一次针对短攻击的演练：40 秒左右、低于 1 Gbps、集中在单一高频路由。确认告警在攻击结束前触发，限速在没有大面积误伤的情况下生效。

边界与待核实#

报告数据来自 Cloudflare 覆盖 330 多个城市、500 Tbps 容量的网络，是全网视图，不必然适用于单个 API 平台的流量结构；文中所有阈值都是需要重新标定的起点，不是结论。报告提到的攻击目标行业与地理分布（第三季度美国重回最受攻击位置，中国第二，印度尼西亚以 2.93% 升至第三；加拿大从第 16 位升至第 6 位，以色列上升 7 位至第 10）对判断自身风险有参考价值，但能否外推到具体平台，取决于你的用户与源站分布，这一点本次材料不足以判断。

文中两段配置均为未执行示例，没有在具体版本上运行过；Prometheus 的 for 语义、Nginx 多 limit_req 串联行为、以及入口侧采样对存储的实际开销，都需要在你自己的环境中核实后再上线。