当DDoS攻击不再“轰轰烈烈”——正在蔓延的“低调漫长攻击”

做运维的都知道，传统的DDoS攻击很好认：监控面板上流量突然拉满，带宽告警炸了，服务器瞬间卡死。
但最近一年多，出现了一种完全相反的套路。攻击不再追求“一锤子砸死你”，而是用极低的速率、极长的持续时间慢慢耗你。你甚至可能几天都发现不了自己被打了。

一个真实的攻击案例

2026年4月，一家AIGC平台遭遇了一次特殊的DDoS攻击。

这次攻击持续了5个小时，累计发出了24.5亿次请求。但有意思的是——它全程没有触发这家平台传统防护系统的流量限制机制。

为什么？

因为攻击者把请求速率控制得非常低。峰值只有每秒20.5万次请求，平均约13.6万次。每个来源IP平均每9秒才发一次请求。

9秒一次是什么概念？大多数系统的CC防护阈值设置在每秒几十甚至上百次。9秒一次远低于任何告警线，所以全程静默，没有任何告警。

更狡猾的是，攻击流量呈现波浪式周期性波动，中间穿插短暂停顿。目的是让防护系统中的限速计数器重置，让防御系统误以为流量已经恢复正常。

这场攻击背后的僵尸网络横跨16402个自治系统，涉及约120万个独立IP地址。流量来源既包括AWS、谷歌云、DigitalOcean等主流云平台，也包含大量匿名化“肉鸡”。

攻击者还伪造了HTTP Headers、Cookies、URL参数和浏览器指纹，让流量看起来完全像正常用户在访问。

这不是个例，是新趋势

安全公司DataDome的研究人员指出，这起事件反映出DDoS攻击思路正在发生根本性演进。

攻击方式已不再单纯依赖超大规模流量，而是开始模仿真实用户行为，以绕过传统基于IP和流量阈值的防御机制。

绿盟科技《DDoS攻击威胁报告》（2026版）也印证了这一趋势：DDoS攻击正从传统的带宽堆积型对抗，向以认知速度、策略精度与决策效率为核心的智能化对抗转变。攻击方式由流量压制逐步演进为高针对性的精准打击，隐蔽性与破坏力显著提升。

Radware的2026年Q1报告提供了更详细的数据：

• 2026年Q1网络层DDoS攻击数量同比增长107%
• Web DDoS攻击数量同比增长187.1%
• 93% 的Web DDoS攻击峰值低于10万RPS
• 超过500万RPS的高强度攻击占比从2024年的4%下降到了1%

换句话说：攻击者正在主动降低单次攻击的强度，以换取更长的持续时间和更低的暴露风险。

为什么这种攻击更难防？

传统的DDoS防御体系建立在两个核心假设上：

1. 攻击是“突发”的，流量会突然暴涨
2. 攻击源IP是集中的，可以通过IP封禁来缓解

但“低调漫长攻击”把这两个假设都推翻了。

阈值失效：每个IP每9秒才发一次请求，远低于任何合理的限速阈值。你不可能把9秒访问一次的用户全封掉。

总量惊人：单个IP的请求量很小，但120万个IP加起来，5小时就能产生24.5亿次请求。这对后端服务的压力是持续性的、累积性的。

难以识别：攻击流量伪造了完整的浏览器指纹、Cookie、HTTP头，和真实用户几乎无法区分。

消耗的是“软资源”：这种攻击不是打带宽，是打连接池、CPU、数据库连接。带宽监控全绿，业务已经挂了——这种场景越来越常见。

怎么应对？

应对这种新型攻击，传统的“阈值+黑名单”模式已经不够了。几个方向可以参考：

1. 行为基线建模

不再只看“单次请求”是否异常，而是为每个用户（或每个IP）建立长期的行为画像。正常用户访问一个网站会有点击、滚动、停留、页面跳转等行为序列，而攻击脚本只是在循环请求固定URL。偏离基线过大的，即使单次请求看起来正常，也应标记为可疑。

2. 滑动窗口统计

不只看瞬时速率，还要看一段时间内的累计行为。单个IP 9秒一次不违规，但如果在过去1小时内累计请求了400次（平均也是9秒一次），可能就该被关注了。

3. AI驱动的异常检测

传统规则引擎面对伪造的浏览器指纹和HTTP头基本失效。需要利用机器学习在流量数据中自动发现异常聚类——比如某类请求的时序分布、TLS握手特征、HTTP协议行为等维度上存在统计偏差。

4. 挑战-响应机制

对可疑请求下发JavaScript计算挑战或验证码。真实浏览器能正常执行，而脚本化的攻击流量很难完美模拟。这是一种有效的“人机分离”手段。

绿盟的报告也指出，2025年已出现由AI驱动的DDoS攻击平台。这些平台能够针对目标自动生成最优攻击方案与参数配置。防御端如果不引入AI能力，光靠人工配规则，很难跟上攻击者的节奏。

小结

“低调漫长攻击”正在成为DDoS领域的新常态。它不像UDP Flood那样简单粗暴，但更难发现、更难防御、更难溯源。

对运维团队来说，需要重新审视自己的防护体系：

• 你的告警阈值是不是只盯着“带宽突增”？
• 你的限速策略能不能识别“低频但持续”的异常？
• 你有没有能力区分“真实用户”和“伪装成用户的脚本”？

这些问题，值得花点时间想一想。