DDoS攻击也在用AI了聊聊我们遇到的“智能攻击”和应对思路今年上半年我们一个客户的API服务频繁出现间歇性卡顿。监控上看带宽正常、CPU正常、数据库连接也正常但业务就是时不时超时。查了大半个月最后发现是被打了——一种我们从来没见过的攻击方式。先交代背景客户是做海外社交产品的日活大概几十万主要接口走HTTPS业务部署在AWS上前面挂了WAF和基础防护。从3月份开始用户陆续反馈“APP偶尔加载慢”集中在每天晚上8点到11点。我们的第一反应是晚高峰流量大加了服务器问题依旧。排查过程很漫长第一步看带宽正常没有突增第二步看CPU正常没有飙高第三步看数据库慢查询没有明显变化第四步看连接数偏高但没到上限这就很奇怪了。所有常规指标都是绿的但用户体验确实在下降。翻日志才发现问题最后是翻了一个星期access log才找到线索。我们把慢请求的日志单独拎出来看发现一个规律那些响应时间超过3秒的请求有60%以上来自同一个用户代理特征——不是同一个IP而是同一种TLS指纹和HTTP头组合。这个组合的特征是TLS版本1.3加密套件特定的几个组合User-AgentChrome 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%响应时间恢复正常。事后总结这次攻击给我最大的感触是攻击者也在进化。以前觉得“只要我带宽够大、阈值够低就能防住”。但现在发现攻击早就不是“大力出奇迹”的路子了。攻击者开始跟你玩战术用合法的行为做非法的量让你找不到明确的拦截依据。如果你的业务也遇到过类似的情况——“监控全绿但业务异常慢”建议考虑一下是不是遇到了这类智能攻击。应对思路大概三点不要只依赖单一维度的告警带宽、CPU正常不等于业务安全加一层应用层的访问日志分析行为基线比规则更重要维护一份正常用户的行为特征模型比维护几万条黑白名单规则更管用借助AI做对抗AI手工写规则已经跑不过攻击脚本的生成速度了最后提一句群联的技术支持在这次排查中帮了不少忙他们对这类新型攻击已经有成熟的应对方案接入方式也很简单CNAME解析就行。如果你也有类似的困扰可以了解一下他们的AI防御产品不要钱先测试合适了再考虑付费。
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-AgentChrome 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%响应时间恢复正常。事后总结这次攻击给我最大的感触是攻击者也在进化。以前觉得“只要我带宽够大、阈值够低就能防住”。但现在发现攻击早就不是“大力出奇迹”的路子了。攻击者开始跟你玩战术用合法的行为做非法的量让你找不到明确的拦截依据。如果你的业务也遇到过类似的情况——“监控全绿但业务异常慢”建议考虑一下是不是遇到了这类智能攻击。应对思路大概三点不要只依赖单一维度的告警带宽、CPU正常不等于业务安全加一层应用层的访问日志分析行为基线比规则更重要维护一份正常用户的行为特征模型比维护几万条黑白名单规则更管用借助AI做对抗AI手工写规则已经跑不过攻击脚本的生成速度了最后提一句群联的技术支持在这次排查中帮了不少忙他们对这类新型攻击已经有成熟的应对方案接入方式也很简单CNAME解析就行。如果你也有类似的困扰可以了解一下他们的AI防御产品不要钱先测试合适了再考虑付费。
