交易平台被打十有八九是从CCChallenge Collapsar应用层挑战开始的。这几年我所在的平台经历过的攻击从早期的单纯IP狂轰滥炸到后来的动态IP池、秒拨代理、模拟真人行为手法一路进化。尤其是标题里提到的“千亿级傀儡流量”说白了就是动辄百万级QPS的黑产肉鸡大军按普通业务峰值几十倍的量灌进来目的不是打崩你的网络带宽而是耗尽你的应用处理能力、数据库连接池、缓存带宽让你本人都分不清哪些是用户、哪些是灰产。这套“五重智能防护墙”不是哪个厂商的白皮书概念而是我们团队在真实攻防对抗里反复摸爬滚打后沉淀下来的一整套打法。它解决的核心问题是在超大流量冲击下如何尽可能精准地区分“真人用户”和“傀儡机”在保证正常交易体验的前提下把攻击流量挡在业务系统之外。这篇文章适合所有负责交易平台、电商抢购、高并发接口的运维、安全和后端开发同学阅读哪怕你单位暂时没有千亿级体量这套分层思路也完全能降维应用到日常防护中。1. 整体设计与思路拆解先说清楚CC攻击和普通DDoS的区别。DDoS打的是链路层和网络层流量一大交换机先扛不住那是一力降十会。CC攻击则是应用层的“软刀子”它利用的是HTTP/HTTPS协议本身的合法行为一个请求就是一个正常的TCP连接、一次正常的HTTP交互肉鸡们模拟的是真实用户的浏览、查询、下单行为只是数量多到让你无法处理。所以对付CC单靠加带宽或者硬抗是没用的必须要靠逻辑和策略。1.1 CC攻击的本质为什么交易平台被打得体无完肤交易平台天然是CC攻击的重灾区原因有三个。第一业务接口价值高行情查询、资产列表、下单成交这类接口每打一次都对服务器产生真实开销攻击者用最小成本就能消耗你最大的计算资源。第二接口特征明显懂行的人一看URL就知道哪个是查询持仓、哪个是拉取K线直接对着最贵的接口打。第三正常业务波动与攻击流量高度相似行情剧烈波动时用户会频繁刷新抢购时用户会疯狂点击这些正常行为本身就跟攻击没啥区别。所以你们会发现很多平台被打的时候第一反应是封IP然后误杀一大片真实用户投诉瞬间爆炸再然后攻击者换一批IP继续打形成恶性循环。这就引出一个关键认知CC防护的第一步不是拦截而是识别。你得先回答“谁是人、谁是机器”这个问题才有资格谈拦截策略。1.2 五重防护墙的漏斗式设计逻辑五重防护墙本质上是一个漏斗从网络边界到业务内部一层比一层精细每一层只放行“疑似可信”的流量层层筛下来攻击流量到业务层时已经所剩无几。这五层分别是第一重边缘流量清洗与源站隐匿。在流量到达源站之前先通过高防IP或CDN节点做一次粗筛干掉那些一看就是扫描器、僵尸网络特征明显的流量同时隐藏源站真实IP让攻击者无从绕过防护直捣黄龙。第二重协议指纹识别与客户端特征校验。从TLS握手特征比如JA3指纹、HTTP头顺序、Cookie生成规则等维度判断请求是不是来自一个“真正的浏览器”。这是很多团队容易忽略的层面却是效率极高的过滤器。第三重动态限频与滑动窗口算法。在请求进入业务逻辑之前以IP、会话、账号、设备指纹等多个维度做频率计算超过阈值直接拉黑或进入验证流程。第四重动态验证码与JS挑战。当流量特征可疑时不直接拒绝而是返回一段需要浏览器执行的计算脚本或人机验证用“计算成本”换“识别精度”。第五重业务风控与行为画像联动。把防护能力下沉到业务内部通过用户行为序列、设备指纹、业务规则等识别那些已经穿透前四层的高仿真攻击流量。这个设计逻辑的核心是“层层设防、逐步收敛”每一层只做自己最擅长的事情不追求单层完美。比如第一层不负责区分人机第二层不负责频率统计各司其职整体效果才会稳定。1.3 自研 vs 云厂商方案选型背后的取舍很多朋友会问直接买云WAF或者高防套餐不就行了吗为什么要费劲自研五重防护我的答案是云厂商方案是“标准品”适合起步阶段但面对千亿级傀儡流量时标准品存在两个问题——策略不可控和识别维度单一。标准WAF的限频规则通常只基于IP和URL面对动态IP池攻击时几乎失效因为攻击者每分钟换几万个IP你的IP维度频率统计形同虚设。另外标准的JS挑战是全局开关无法精细控制哪些接口需要挑战、哪些用户群可以豁免容易误伤API调用方和移动端App用户。所以我们的做法是“混合架构”云厂商的高防IP做第一层边缘清洗这部分自建成本太高买现成的合理自建WAF集群做第二到第四层业务内部嵌入风控SDK做第五层。这样每一层都可以自主调参攻击手法变化时我们能在一小时内完成策略迭代而不是等厂商排期。2. 核心防护细节与关键参数解析这一部分直接上干货我把每一重防护墙里最核心的技术细节、参数选择逻辑和实测经验展开讲。2.1 第一重边缘流量清洗与源站隐匿边缘清洗层解决的是两个问题大流量缓冲和源站IP保护。高防IP本质上是一个巨大的流量池攻击流量先打到高防节点被清洗掉DDoS流量后剩下的HTTP请求再回源到你的真实服务器。所以第一重的关键参数是回源策略。回源IP通常设为内网VIP或负载均衡地址绝不能把源站真实IP暴露在公网DNS记录里。我们在这上面吃过亏曾经因为配置失误攻击者通过历史DNS记录找到了源站IP然后直接绕过WAF打源站导致所有边缘防护全部失效。后来我们强制要求源站只允许来自高防节点的回源IP访问安全组层面直接白名单除此之外的一切来源统统拒绝。清洗策略层面第一重主要做的是“低水平特征粗筛”比如常见的恶意扫描UAUser-Agent、已知漏洞利用路径、畸形HTTP请求等。这些规则不需要太复杂主要是快速消耗掉低质量流量让后续层级专注于更难处理的攻击。实测下来第一重大概能清洗掉总量的20%-30%左右别指望它解决核心问题它就是个漏斗入口。这里有个注意事项回源协议的配置要贴近真实浏览器。比如高防节点回源时默认会用HTTP/1.1但你的源站如果强制HTTPS或HTTP/2就会频繁出现握手失败。我们最终把回源设为HTTPS/1.1源站侧关闭了不兼容的加密套件确保回源链路速度足够快不在边缘层引入额外延迟。2.2 第二重协议指纹识别与客户端特征校验这是对付“傀儡流量”最关键的一层。为什么因为真实浏览器发起的HTTPS请求和Python脚本、curl命令、Java HTTP客户端发起的请求在TLS握手层面有着明显差异。这些差异普通肉眼看不出但通过特征提取可以精确识别。业界最经典的TLS指纹是JA3。它通过对ClientHello包中的SSL/TLS版本、加密套件列表、扩展列表等信息做哈希生成一个唯一的“TLS指纹字符串”。真实浏览器的JA3指纹是相对固定的而大多数攻击工具基于OpenSSL或Python的requests库它们的指纹特征完全不同。我们在这一层的做法是白名单与黑名单并存。维护一份常见浏览器和移动端App的JA3指纹白名单凡是命中白名单的请求直接放行到下一层对于命中已知攻击工具指纹的请求直接返回403或进入假响应。剩下的未知指纹流量则进入动态限频层做进一步观察。除了JA3HTTP头顺序、Accept-Language、Accept-Encoding的设置方式也可以作为辅助特征。但这里我要强调一个容易犯的错误特征校验不能做成“硬拦截”因为用户的浏览器会升级TLS版本会迭代新版本浏览器会产生新的指纹。如果你把特征库写死可能一场攻击没挡住先把自己的真实用户全拦在外面了。我们的策略是“每日更新基线置信度打分”而不是简单的黑名单命中拦截。2.3 第三重动态限频与滑动窗口算法限频是CC防护的“基本盘”几乎每个防护方案都有但大多数做得太粗糙。粗粒度的固定限频比如每IP每秒5次请求在今天已经完全失效因为攻击者会控制每个肉鸡的请求速率让它看着就像正常用户在刷页面。动态限频要搞明白两件事限什么维度和阈值怎么算。我们最终采用的维度组合是IP 会话 设备指纹 账号ID四个维度同时做滑动窗口计数。滑动窗口算法的核心价值是应对“突发流量”相比固定窗口比如每分钟统计一次容易在窗口边界出现双倍流量穿透滑动窗口能把时间切成更细的片段以秒级粒度精确统计频率。举个例子我们的窗口大小是5秒每1秒滑动一次如果某个IP在任意5秒窗口内请求数超过阈值就触发限频动作。阈值怎么定这是最考验经验的环节我们用了两周时间做流量基线学习分析正常业务高峰期时真实用户在各维度上的请求分布。比如行情接口的正常单IP请求频率是每5秒2-3次那阈值就设在每5秒8次约3倍余量低于这个值一律放行高于这个值进入下一层验证而不是直接封禁。这套“先验证后封禁”的策略能极大减少误杀。另外提醒一个细节不要只统计请求次数要把请求的“成本”也加权。比如行情查询接口每次耗时1毫秒而下单接口每次耗时50毫秒那么同样10次请求下单接口对系统的压力是行情接口的50倍。我们会对不同接口设置不同的权重系数让限频真正反映“对服务器的消耗”而不是机械的请求数量。2.4 第四重动态验证码与JS挑战当你识别到某个会话的请求频率异常但又不确定一定是攻击时第四重就该上场了。它的核心思想是机器能高速发请求但让它执行一段需要“思考”或“计算”的客户端脚本成本就会急剧上升。JS挑战也叫JS Challenge的做法是服务器返回一段JavaScript代码内容是要求浏览器计算某个值比如基于时间戳和随机字符串做哈希计算正确后才能继续访问。真实浏览器是完整JS引擎执行这段代码毫秒级完成而大多数攻击脚本没有JS执行环境到这一步就会卡住。我们用的是自研挑战逻辑而不是现成的第三方验证码SDK原因是可以自由定制算法强度和生效范围。这里有几个参数直接关系到用户体验挑战有效时间默认120秒超过后重新挑战防止攻击者一次性通过后持续利用。失败重试次数允许3次超过后IP进入黑名单但要设置黑名单过期时间默认15分钟避免误伤动态IP用户。挑战触发率高峰期如果挑战量过大会增加正常用户的等待时间。我们的平滑方案是当系统负载超过70%时逐步提高挑战触发比例动态调节而不是一下子全量弹验证码。移动端App用户怎么办这是很多Web防护方案忽略的场景。App请求没有浏览器环境没法执行JS挑战所以我们为App提供了两种降级方案一种是嵌入SDK由SDK生成设备指纹并计算挑战值另一种是对无法完成挑战的请求直接落到第五重业务风控做“行为验证”用业务数据判断真伪。实测下来iOS和Android的主流环境都能正常适配。2.5 第五重业务风控与行为画像联动前四重防的是“机器特征”第五重防的是“仿真人”。到了这一层攻击者已经能用真实浏览器内核比如Playwright、Puppeteer模拟完整用户操作TLS指纹、JS挑战全部能通过请求频率也能伪装得像真人。这时候再靠“流量层特征”已经区分不开了必须结合业务数据来判断。我们做了三件事行为序列识别。真实用户在交易平台上的行为是相对固定的登录→浏览行情→查看K线→下单→确认。每个环节之间会有合理的间隔和前后依赖关系。如果某个会话的行为序列是“登录→直接下单→直接下单→直接下单”间隔小于1秒且没有任何浏览行为那大概率是脚本在跑。设备指纹与账号关联分析。同一设备指纹在短时间内关联多个账号或者同一账号从大量不同设备上登录这些都是典型的批量操作特征。我们把设备指纹通过Canvas、WebGL、时区、字体等生成纳入风控维度一旦发现异常关联账号直接进入人工复核或强制验证。业务规则拦截。针对交易类接口设定业务规则比如单账号每分钟下单次数上限、单个IP的单账号登录数上限等。这些规则直接嵌在业务代码里不走WAF因为只有业务侧才知道“什么是合理行为”。第五重是整个防护的“最后一道保险”它无法拦截所有攻击流量但能保证即使前四层被穿透攻击者也很难真正影响到核心交易业务的稳定性。对我们来说做到这一步防线才算真正完整。3. 实操过程与关键配置步骤前面讲完设计逻辑这一部分带大家走一遍我们实际的部署和实施流程。整个过程可以分为五个阶段每个阶段都有明确的输入、输出和验收标准。3.1 防护前的流量基线与摸底任何防护方案的部署最忌讳的就是“拿到手就配规则”。你连自己的正常流量长什么样都不知道配置出来的规则要么误杀要么漏杀。我们花了约两周时间做基线摸底核心是采集三个数据正常业务高峰期的QPS按接口维度拆分确定Top 20高消耗接口。真实用户的来源分布包括IP段、运营商、国家/地区、设备类型。当前已有的封禁/限频规则的误杀率和拦截率找出哪些规则是“摆设”哪些是“误伤大户”。我建议你在这个阶段至少要保留两周以上的访问日志日志中要包含客户端IP、UA、TLS指纹、请求路径、响应码、响应时间、会话ID、设备ID。这些字段是后续所有防护规则的数据基础。3.2 配置边缘清洗策略高防IP的接入以我们用的某云服务商高防产品为例接入流程大概是在DNS解析处将业务域名CNAME到高防IP源站记录删除公网解析。源站安全组配置白名单只允许高防回源IP段访问80/443端口。高防控制台开启TCP/UDP DDoS防护将清洗阈值设置为正常峰值带宽的2倍左右。开启HTTP/HTTPS CC防护策略但此时先不要开启高级规则只启用默认阈值观察7天日志。这里有个值得注意的点回源规则和高防策略要分阶段灰度。我们当时先把某个低流量的业务域名切过去跑了一个星期验证稳定性确认无误后才把所有域名迁移。如果一次性全量切完回源配置错误导致业务中断电商大促期间那就是事故。3.3 调整WAF规则与动态限频参数边缘层稳定后重心转到自建WAF集群。我们用的是开源WAF二次开发的方案部署了两个节点做负载均衡规则存储在Redis里方便热更新。动频率的核心配置流程在管理后台导入业务接口清单标记每个接口的成本权重按平均响应时间加权。设定“IP单维度”和“IP会话”两个预筛规则阈值参考基线数据的3倍初步拦截明显异常的突发流量。开启“IP设备指纹”维度的动态限频阈值按基线数据的5倍设置超过后触发JS挑战而非封禁。配置“账号设备指纹”维度规则阈值按基线数据的2倍设置超过后进入业务风控层。参数不是说设完就完了需要每周复盘一次根据误杀反馈和攻击记录动态调整。我们要特别留意“高峰误杀”——比如突发利好消息导致行情接口流量短时间暴增固定阈值很容易把散户全拦了。后来我们加了“负载感知”逻辑只有当后端负载超过80%时限频规则才提升到严格模式平时维持宽松阈值。3.4 JS挑战与人机验证的接入JS挑战层的接入相对简单主要是技术选型和触发条件配置。我们的做法是选择在Nginx层面通过Lua脚本嵌入挑战逻辑而不是改业务代码这样对开发团队透明。设置挑战触发条件当动态限频层判定“可疑”时返回一个302重定向到挑战页面。挑战页面是静态资源走了CDN加速用户无感知加载时间控制在100ms以内。为用户设置Cookie标记标记有效期默认30分钟标记在有效期内不再重复挑战。实测下来正常用户遇到JS挑战的成功率在99.5%以上卡住的主要是老旧浏览器、被禁用Cookie的隐私模式和一些非浏览器客户端。3.5 业务风控规则的联动落地第五重防护需要业务侧配合主要是把风控SDK嵌入App和Web前端。SDK采集设备指纹、行为序列、传感器数据并把这些信息加密上报到风控服务。服务端风控引擎再结合WAF传来的会话标签做综合判定。我们上线的前几周专门安排了一个“仿真人攻击演练”环节用自动化框架模拟真人浏览、下单流程测试风控规则的识别能力。第一轮演练时我们自己的模拟脚本成功绕过了所有规则后来加上了“鼠标轨迹分析”和“键盘输入间隔分布”才把高仿真攻击的识别率拉到90%以上。记住不要相信“开箱即用”的风控系统一定要用你们自己写的Bot脚本反复测试规则的有效性。4. 攻防演练与真实对抗复盘再完美的纸面设计都要拉到真实战场上检验。这一部分写我们经历过的一场大规模实战对抗以及从中总结出的经验。4.1 模拟攻击千亿级傀儡流量怎么打过来某天下午的防护升级测试中我们模拟了一场接近真实规模的攻击。攻击方使用了一个约50万台肉鸡的僵尸网络每台肉鸡控制每秒2-3个请求汇聚过来就是峰值超过150万QPS的流量。这个量级对源站来说是毁灭性的普通配置的Web服务器在几秒内就会连接数耗尽数据库连接池被打满应用直接假死。攻击的目标接口是行情列表最消耗数据库IO的接口之一和登录接口。第一波攻击直接绕过首页到达API网关我们观察到大量请求的TLS指纹完全一致同一个僵尸网络工具构建的HTTP头顺序和UA也高度雷同。这就是第二重指纹识别的用武之地将近40%的流量在第一轮指纹校验中被拦截。但攻击方很快调整策略换用真实浏览器内核替代脚本工具TLS指纹变正常了UA也变得五花八门第二层防护开始失效。这时候第三重动态限频发挥作用虽然每台肉鸡的请求频率都不高但它们的行为高度一致——访问路径高度重合、时间间隔极其均匀。我们通过“路径聚类的行为分析”识别出这些流量把它们引导到JS挑战层。4.2 对抗中的三波攻击手法变化真实的攻防对抗是一路“魔高一尺道高一丈”的过程。第一波攻击是“无脑刷量”特征明显简单限频UA指纹就能拦住大半这也是防护收益最高的一波。第二波是“分布式仿真攻击”攻击者换用自动化浏览器请求特征和真人几乎一致这一波对防护体系的考验最大。第三波是“混合式慢速攻击”攻击者故意把请求频率压到远低于正常用户的水平单个看起来完全无害但总的数量基数太大依然能把后端连接池慢慢耗尽。针对第三波慢速攻击我们调整了算法不再只看请求频率而是加入了“连接持续时间分析”。正常用户的HTTP请求往往是短连接而慢速攻击会刻意长时间占用连接让服务器资源慢慢耗尽。我们设置了连接最长保持时间默认60秒超时的连接直接断开并进入重认证流程这才堵住这个漏洞。4.3 各层防护的实际拦截数据整场模拟对抗持续了四个小时结束时我们统计了各层的拦截效果防护层级处理流量占比拦截准确率误杀率边缘清洗高防IP约25%高极低指纹识别TLS/HTTP约20%较高低动态限频多维度窗口约30%高中等JS挑战/验证码约15%高中等业务风控行为画像约10%中等低需要说明的是这个数据是“处理”而不是“拦截”因为JS挑战和业务风控并不直接拒绝所有可疑流量而是通过额外验证来确认身份。最终真正进入业务核心逻辑的流量被控制在了攻击总量的2%以下系统整体可用性始终保持在99.99%这就是五重防护的价值。5. 常见问题与排查技巧实录最后整理几个我们在实际运维中反复踩过的坑每一条都是真金白银买来的教训希望对大家有帮助。5.1 误杀正常用户怎么破这是CC防护中投诉量最大的问题。大促热卖时真实用户会高频刷新购物车、反复点击结算按钮这个行为特征和攻击脚本高度重合很容易被限频规则误伤。我们的解决方案是“分层递进别一刀切”。不要因为一个IP频率超标就直接封禁IP而是先把请求导向JS挑战如果挑战通过则标记为“高风险真人”允许继续访问但放大其后续请求的二次校验频率。另外要给热门接口和普通接口设置不同的频率阈值不能搞“全局一把尺”。最有效的兜底机制是“申诉通道”用户被拦截后可以提交申诉系统核实后自动解除并加入白名单避免因为误杀造成用户流失。5.2 绕过CDN直连源站的攻击这是一个非常常见的漏洞。攻击者只要拿到源站IP可以直接绕过所有CDN和WAF防护让边缘层形同虚设。源站IP泄露的途径很多历史DNS记录、邮件头、证书透明度日志、子域名的A记录等等。解决思路是三层第一源站只允许白名单IP访问第二对源站服务器上的所有域名做全站HTTPS并在证书中不暴露任何内部域名信息第三购买高防IP服务时确保所有流量都经过高防节点同时在防火墙层面干脆禁止公网直接访问源站。不过这里要提醒一句源站IP的安全不仅仅靠技术更要靠流程。曾经有个同事在外网贴了一个带服务器IP的故障排查帖当天就被扫描器发现并尝试攻击从那以后我们把“源站IP保密”写进了团队规范。5.3 慢速CC的识别难点前面提到慢速CC攻击把请求频率控制得极低让每个请求看起来都像真人操作传统的限频基本失效。这类攻击对交易平台危害尤其大因为它能持续消耗你的连接数、线程数而不会触发告警。我们最终落地的解决方案是“三管齐下”连接时长监控超时强制断开、重认证、请求路径熵分析真实用户访问路径呈现出很高的随机性而慢速攻击的路径高度重复通过信息熵算法可以识别出低熵路径、异步验证码间歇触发对低频率但低熵的会话随机触发一次验证码成本很低但对攻击者来说每次都要处理。实测下来慢速CC基本无处遁形。5.4 动态IP池让IP封禁失效秒拨IP和动态代理让“IP维度”的防护越来越不可靠攻击者每分钟能换几千个IP单IP频率完全在正常范围内你怎么封我们的应对思路是“弱化IP权重强化账号和设备维度”。IP不再是独立决策因子而是综合画像的一部分它只占很小权重更关键的是设备指纹同一个浏览器内核生成相同的指纹和账号行为同一个账号短时间内大量异常请求。攻击者可以换IP但很难换设备指纹和账号体系抓住这两个维度一切就迎刃而解。这套“去IP中心化”的思维建议所有被CC困扰的团队都认真思考一下。5.5 缓存击穿的处理方式攻击者很会挑软柿子捏找一个不设缓存的热点数据接口高频请求直接穿透所有缓存打到数据库导致数据库连接数瞬间飙满。即使你的防护层识别了大部分攻击流量漏网的那部分如果恰好命中“缓存穿透点”依然能把数据库打死。标准解法是业务侧做两级缓存本地缓存分布式缓存数据空值也做短时间缓存防止“穿透”对于价格、行情这类高频查询接口加入“单飞”策略即同一时刻同一Key的请求只允许一个线程真实查询数据库其余线程等待第一个线程的结果返回。再配合我们前面说的“成本加权限频”高消耗接口的防护优先级自动提高防止攻击者拿最贵的接口打你。写在最后五重防护墙上线到现在我们经历了很多次实战考验整体效果稳定但过程远比写出来复杂。每次攻防对抗结束团队都会做一次详细复盘把攻击者的新手法、防护层的薄弱点、误杀案例全部整理成文档形成自己的攻防知识库。我个人最大的体会是防护体系没有“搭完就完事”的一天它需要持续运营、持续调优、持续对抗你松懈一次攻击者就会趁虚而入。最后再分享一个小经验如果有条件一定要定期自己做攻防演练扮演一次“攻击者”去骚扰自己的系统。你会发现很多你以为固若金汤的防线其实漏洞百出。真到被打的时候再发现问题代价就太大了。