DDoS攻击也在用AI了？聊聊我们遇到的“智能攻击”和应对思路

DDoS攻击也在用AI了？聊聊我们遇到的“智能攻击”和应对思路
今年上半年，我们一个客户的API服务频繁出现间歇性卡顿。监控上看带宽正常、CPU正常、数据库连接也正常，但业务就是时不时超时。
查了大半个月，最后发现是被打了——一种我们从来没见过的攻击方式。

先交代背景

客户是做海外社交产品的，日活大概几十万，主要接口走HTTPS，业务部署在AWS上，前面挂了WAF和基础防护。

从3月份开始，用户陆续反馈“APP偶尔加载慢”，集中在每天晚上8点到11点。我们的第一反应是晚高峰流量大，加了服务器，问题依旧。

排查过程很漫长：

• 第一步看带宽：正常，没有突增
• 第二步看CPU：正常，没有飙高
• 第三步看数据库：慢查询没有明显变化
• 第四步看连接数：偏高，但没到上限

这就很奇怪了。所有常规指标都是绿的，但用户体验确实在下降。

翻日志才发现问题

最后是翻了一个星期access log才找到线索。

我们把慢请求的日志单独拎出来看，发现一个规律：那些响应时间超过3秒的请求，有60%以上来自同一个用户代理特征——不是同一个IP，而是同一种TLS指纹和HTTP头组合。

这个组合的特征是：

• TLS版本：1.3
• 加密套件：特定的几个组合
• User-Agent：Chrome 120系的某个版本
• 请求路径：集中在 /api/user/info 和 /api/feed/list 两个接口
• 每个IP的请求频率：约每分钟3-5次

每分钟3-5次，远低于任何CC防护的阈值。但问题是，这个特征的请求分布在超过10万个独立IP上。加起来，这两个接口每天多承受了上千万次请求。

后来我们联系了云防护厂商（群联科技）的技术支持一起看，他们的判断是：这很可能是一次AI辅助生成的慢速攻击。

AI攻击和传统攻击有什么区别？

传统的自动化攻击有几个明显的“破绽”：

• IP集中：几千个IP反复刷
• 频率固定：每隔几秒精准地发一次请求
• 特征单一：User-Agent、Accept头完全一样
• 路径集中：只打一个URL

但这次遇到的攻击完全不一样：

IP极度分散：10万个独立IP，来自全球各地，大部分是真实的住宅IP（不是机房IP），很难通过IP归属地来做拦截。

频率不规律：每个IP的请求间隔在10秒到3分钟之间随机波动，模仿真实用户的使用习惯。

行为有“上下文”：攻击者并不是只刷一个接口，而是会先请求首页、再请求feed、再请求user/info，模仿了一个完整的用户访问路径。只是每一步都特别快——正常用户看一页需要停留几十秒，攻击脚本只停留一两秒就跳到下一步了。

这就像是有人用大量真人在帮你刷数据，但每个“真人”只刷了几下就走了。

传统的WAF规则对这种流量几乎无效。因为它不是“恶意流量”，它是“看起来像正常流量但量特别大”的流量。

怎么区分正常用户和AI攻击？

这个问题我们想了很久，最后用了几个组合策略。

1. 行为序列分析

这是最有效的一招。

真实用户的访问路径是有“时间黏性”的：看一篇文章会停留几分钟、刷信息流会有停顿、输入内容有键盘敲击间隔。这些行为在时间轴上呈现出“突发+间隔”的模式。

而即使是AI模拟的攻击，也做不到完美的时间分布。攻击脚本通常是请求完一个URL立刻请求下一个，停留时间要么固定、要么随机，但缺少人类行为的那种“长尾分布”。

我们配合群联的AI引擎做了个实验：把正常的用户访问日志和攻击流量混在一起，让模型去找区别。结果发现，攻击流量的页面停留时间分布和真实用户有明显差异——真实用户的停留时间分布是长尾的（大部分人看几秒就走，少部分人看很久），而攻击流量的停留时间是均匀分布或者集中在一个很窄的区间。

2. 交互深度检测

正常用户访问一个功能完整的应用，会产生一系列交互：点击、滑动、输入、滚动。攻击脚本通常只走主干路径，不会触发那些“无回报”的交互。

比如我们的feed流，正常用户会往下滑3到5次才会点进一个详情页。攻击脚本通常是进来、请求feed数据、立刻退出。把这个行为作为一个特征维度，能筛掉大量脚本。

3. 挑战-响应分层

对可疑但不确定的请求，下发轻量级的挑战（比如一个简单的JavaScript计算任务）。真实浏览器能在几十毫秒内完成并返回结果，而脚本化的请求要么无法执行、要么需要额外加载渲染引擎，耗时显著更长。

这套方案加上去之后，晚高峰的异常请求被砍掉了大约70%，响应时间恢复正常。

事后总结

这次攻击给我最大的感触是：攻击者也在进化。

以前觉得“只要我带宽够大、阈值够低，就能防住”。但现在发现，攻击早就不是“大力出奇迹”的路子了。攻击者开始跟你玩战术：用合法的行为做非法的量，让你找不到明确的拦截依据。

如果你的业务也遇到过类似的情况——“监控全绿但业务异常慢”，建议考虑一下是不是遇到了这类智能攻击。

应对思路大概三点：

1. 不要只依赖单一维度的告警：带宽、CPU正常不等于业务安全，加一层应用层的访问日志分析
2. 行为基线比规则更重要：维护一份正常用户的行为特征模型，比维护几万条黑白名单规则更管用
3. 借助AI做对抗AI：手工写规则已经跑不过攻击脚本的生成速度了

最后提一句，群联的技术支持在这次排查中帮了不少忙，他们对这类新型攻击已经有成熟的应对方案，接入方式也很简单（CNAME解析就行）。如果你也有类似的困扰，可以了解一下他们的AI防御产品，不要钱先测试，合适了再考虑付费。