1. 千亿级傀儡流量到底长什么样从一次凌晨突袭说起做交易所系统安全这些年我自认为对CC攻击已经脱敏了。带宽型DDoS再猛那是砸钱就能解决的事真正让人头皮发麻的是那种不温不火、专门盯着应用层打的CC攻击。2026年开春我们一线值班遭遇的那场攻防才算真正刷新了我对“傀儡流量”的认知对方调度了几百万台被控设备组成了一个规模惊人的攻击军团在几个小时内向交易核心接口倾泻了超过1800亿次请求。这个数字听起来像夸张的PR稿但它是多节点累计的真实统计。如果你没在交易类系统一线扛过峰值可能很难想象这个量级意味着什么。凌晨4点17分监控大屏的告警声几乎同时从三个机房响起入口QPS从正常的2.3万在五分钟内跳到500万然后继续往上冲到4点35分突破了1800万。更可怕的是新建连接数从平时的3.5万每秒暴涨到600万每秒负载均衡器的连接表在几分钟内被打满紧接着后端多个核心API节点的CPU直接顶到100%接口超时率从0.05%一路飙到59%。整个交易链路像被一块巨石堵住了喉咙用户端看到的是转圈、超时、下单失败客服群瞬间炸锅。“千亿级”这个词不是一秒钟的量级而是整场攻击累计的量级。拿我们这次来说攻击大约持续了5个小时单看某一秒可能只有800到1500万请求但架不住一秒一秒地叠加。几个入口节点、几个核心机房防护设备上的计数器全部破表把日志汇总之后一加累计请求量超过1800亿次。这就是傀儡流量的恐怖之处它不需要某一个节点有多高的带宽量大、持续、分布广靠“蚁群战术”把应用层的处理能力一点一点吃干榨净。1.1 现场复盘攻击前的30分钟迹象事后回看监控攻击其实是有前兆的。凌晨3点50分左右日志系统里开始出现大量“请求特征高度一致”的流量来源IP遍及全球但User-Agent却惊人地统一。4点刚过部分海外节点的延迟开始升高我们当时还以为是运营商链路波动。直到4点17分告警爆发大家才意识到前面那半小时是攻击方在做“火力侦察”用小规模流量探测哪些接口响应慢、哪些节点防御薄弱顺便把WAF的封禁策略摸了个底。这里有个很重要的经验攻击方通常会先试探再全面开火。如果你在监控里发现某类请求的分布异常均匀、UA异常统一、来源IP却又极度分散哪怕量还不大也要立刻提高警惕。我们后来把这种“三异常”作为CC攻击的前置预警规则写进了监控系统在后续几次小型攻击中提前了10到15分钟发现别小看这十几分钟足够把核心服务从边缘节点摘掉或提前拉高缓存命中率。1.2 “千亿级”怎么算出来的请求量、连接数、带宽的三重冲击很多人对CC攻击的理解还停留在“多IP多线程发请求”的阶段真实的傀儡流量要复杂得多。攻击方控制的不只是服务器还有大量摄像头、路由器、智能电视这类IoT设备这些设备的系统版本、网络栈、浏览器环境各不相同但在攻击指挥中心的统一调度下它们会按照预设的节奏向目标接口发起请求。这种流量的特点有三个一是源IP极分散几乎无法用简单的IP封禁解决二是请求路径高度集中专门挑下单、查余额、登录这类业务价值最高的接口三是单请求的字节数不大但并发数极大真正吃掉的不是带宽而是应用层的连接处理能力和业务逻辑计算资源。我们统计了这次攻击对三类资源的影响数据如下指标正常时段攻击峰值影响说明入口QPS约2.3万突破1800万API节点CPU全面打满新建连接数/秒约3.5万超过600万连接表耗尽新用户无法接入出口带宽约800Mbps接近40Gbps骨干链路拥塞回包延迟飙升业务请求成功率99.95%最低跌至41%下单、登录大面积超时这个表就是凯发团队当时贴在作战室墙上的“战况图”。带宽冲击反而最小真正的杀手是连接数和QPS。所以后来我们做防护设计时有一条铁律不能只按带宽买防护必须按“应用层每秒能处理多少请求”来估算容量。1.3 傀儡流量不是普通爬虫设备指纹里藏着的线索第一次遭遇时我们犯过错误——把傀儡流量当成普通爬虫来封。普通爬虫的请求模式相对固定封UA、封IP段就能挡住一大半。但这次攻击连的UA列表五花八门伪装成了各种操作系统和浏览器版本单个IP的请求频率也刻意压得很低每个IP每分钟只发几次从频率上看完全是“正常用户”。真正的破绽藏在设备指纹里大量请求的TLS握手参数、TCP窗口大小、HTTP头顺序高度雷同和它们表面上花花绿绿的UA完全不符。这种感觉就像一群人戴着不同的面具但走路姿势一模一样。我们迅速调整策略不再看单个IP的行为而是看“群体特征”把同一时间段内TLS指纹相同、请求路径相同、时间规律相同的流量归为一类直接对整个聚类进行处理。这一刀切下去攻击流量立刻被识别出了大概三成剩下的虽然还在变化指纹但已经为我们后续的纵深防御争取到了宝贵的时间。后来我们把这套“群体指纹聚类”的思路做成了常态化的检测模块一直沿用到现在。2. 五重防护墙的整体设计每层解决一个特定的“为什么”交完第一波火我们复盘时达成了一个共识靠任何单一手段都挡不住这种量级的傀儡流量。WAF的规则库再大也扛不住每秒上千万的请求CDN清洗得再快也拦不住那些直连IP的穿透流量。必须把防护拆成多层每一层解决一个特定问题让攻击者在每一层都要付出新的成本最终打到业务层的请求被压缩到一个可控的范围。我们最终落地的方案是五重防护墙。很多人会以为五层就是“五种防护技术叠在一起”其实不是它是按照漏斗模型设计的越靠前端的层处理得越快、成本越低但判断越粗越靠后的层判断越精准、代价越大只对前几层还没滤掉的流量做精细决策。攻击流量从外往里走每过一层就少一批等到了业务层剩下的必须是真实用户的请求。2.1 设计原则五层不是叠加而是漏斗式过滤这里要先说清楚一个底层逻辑网络层的防护必须快快到你不能让攻击流量进入业务代码业务层的防护必须准准到你不能把正常的高频交易用户误杀成机器人。这两者天然矛盾所以才需要中间层做缓冲。第一层是传输层特征初筛相当于大门保安只看TLS指纹、TCP栈特征、来源IP信誉判定可疑的直接丢弃速度最快、成本最低但它只能识别“明显可疑”的流量。第二层是连接与频率治理相当于楼道闸机用令牌桶和并发连接限制把超过容量的请求挡在门外或降级处理这一层不关心请求是否来自真人只关心“系统能不能承受”。第三层是人机挑战相当于进电梯前的门禁给疑似请求下发一个需要真实浏览器环境才能完成的计算证明攻击者要伪造这个成本的曲线很陡。第四层是业务语义防护相当于进办公室的工牌验证通过蜜罐、动态令牌、会话绑定确认这个请求不仅是“人”还是“在正常业务语义下发起的人”。第五层是跨节点协同清洗相当于整栋楼的安保联动多个入口发现同一批傀儡特征后全局同步封禁防止攻击方逐个节点打地鼠。2.2 总览表五层职责、判据与失败代价把五层拆开看每一层的定位完全不同也各有各的代价层级防护名称核心判据主要代价处理时效第一层传输指纹初筛TLS/JA指纹、TCP栈特征、IP信誉极低仅丢包微秒级第二层连接与频率治理令牌桶、并发连接、慢速连接体征中低排队或短暂拒绝毫秒级第三层智能人机挑战JS计算证明、行为轨迹、WebAssembly支持中高增加用户交互成本秒级第四层业务语义防护蜜罐、动态令牌、会话绑定高需定制改造请求级第五层跨节点协同清洗多节点特征同步、清洗中心牵引高涉及网络架构调整分钟级这套设计的核心思路是让攻击者在每一层都要付出递增的成本。第一层被拦它要换TLS指纹第二层被限它要扩大傀儡规模第三层被挡它要模拟浏览器环境第四层被识破它要摸清业务语义。每多一层攻击方的软成本就翻几倍。到第五层时即便还剩下少量漏网流量也因为攻击规模被前面几层削掉了绝大多数完全在业务系统的承受范围内。3. 逐层攻坚实录从协议指纹到语义蜜罐的部署细节理论说得再漂亮落地才是真功夫。这一部分我把我们实际部署每一层的细节、参数和坑都写出来可能有读者觉得某些设计“过于复杂”但经历过一次千亿级流量冲击之后你会明白这些复杂都是必要的。3.1 第一层TLS与TCP指纹怎么把傀儡设备先挑出来第一层依赖的指纹数据主要包括三类TLS ClientHello指纹业界常说的JA3/JA4、TCP初始窗口大小与MSS、IP包的TTL分布特征。正常浏览器的TLS指纹相对固定但数量有限几大主流浏览器加上各自版本撑死了十几个高频指纹。傀儡设备则不同恶意SDK往往全局复用同一套网络栈参数哪怕它在请求头里把UA伪装得再像ChromeTLS指纹也会出卖它。我们当时在七层负载均衡上挂了一个指纹识别模块把过往正常用户流量的指纹建立基线库再对实时请求做比对。部署时最需要注意的是阈值设定不能看到指纹不在基线库里就直接丢因为企业用户的私有App浏览器、老版本系统、甚至某些国密浏览器都会产生“非主流指纹”。我们最初把阈值设得太严结果误伤了两个合作方的内部系统。后来改成“指纹异常记分制”指纹可疑记2分、UDP端口异常记1分、IP信誉差记3分累计达到5分才进入丢弃或验证流程误杀率降到了可忽略的水平。第一层只适合做“快而粗”的过滤不适合做判断的终点。它最理想的效果是把攻击流量中特征最明显的那部分先削掉。我们的实测数据是第一层过滤掉了约35%的攻击请求耗时几乎可以忽略这相当于给后面的精细检测减轻了三分之一的压力。3.2 第二层接口级令牌桶和“瞬时限流降级”参数怎么定第二层是保护业务系统不被冲垮的关键。我们用的是经典的令牌桶算法但对不同的接口设置不同的速率参数绝不能一刀切。以我们的交易平台为例行情查询接口属于高频读接口正常QPS就能到1.5万攻击峰值时到了800万。令牌桶rate设为5万、burst设为8万超过部分的请求先进入队列等待队列长度超过阈值就返回503并带上Retry-After头部。登录接口属于安全敏感接口rate压到500、burst压到800超过直接进入人机验证流程。下单接口最敏感rate设为3000、burst设为4000超限后不仅限流还会对来源做二次设备指纹比对。除了限流还有降级策略。攻击方最喜欢打的往往是那些计算密集但业务价值不高的接口比如行情历史数据查询、K线导出。我们的做法是当系统负载超过85%时自动把这类非核心接口降级为只读缓存模式不再查询后端数据库直接返回最近5分钟的缓存数据。这一招见效极快核心交易链路的CPU占用率肉眼可见地往下掉。降级判断必须在网关层做不能在业务代码里做否则业务代码本身可能已经被拖垮了。第二层的另外一个重要任务是识别慢速CC攻击。有些傀儡流量不走高并发路线而是采用Slowloris方式用极慢速的请求体占用连接池一个攻击源就能拖住几十条连接。我们在线程池里设置了“最大空闲时间”和“最小发送速率”两个参数超过3秒不发送数据或发送速率低于500字节每秒的连接直接断开配合连接数上限慢慢磨死连接池的战术基本失效。3.3 第三层智能JS挑战落地时踩到的兼容性坑第三层是我们投入最多、踩坑也最多的层。原理不复杂服务器下发一段计算挑战真实浏览器通过JavaScript或WebAssembly在本地完成哈希计算拿到一个短期票证傀儡工具要么不执行JS要么执行起来成本极高。这个设计类似工作量证明机制思路没问题但落地时遇到了一堆兼容性问题。最痛的坑是App内置WebView。很多用户的交易操作是在手机App上完成的App内嵌的WebView默认禁用JavaScript或版本老旧我们上线JS挑战后大量正常用户被拦在门外客服电话直接被打爆。解决方式是做UA分级挑战对主流浏览器派发WebAssembly高难度挑战对老旧WebView派发纯JavaScript低难度挑战对完全没有JS能力的客户端直接放行进入第四层做其他验证。另一个坑是挑战的超时窗口设置。最初设置为30秒结果攻击方利用这个时间窗口先拿到挑战再用分布式算力慢慢算算了之后再批量提交依然能造成大量请求积压。后来我们把挑战改成短生命周期15秒有效过期必须重新获取同时把难度参数和服务器的负载动态挂钩——负载越高挑战难度越大这样攻击者在高峰期发起挑战的成本会成倍上升。这一层的效果非常显著。上线之后攻击流量进入业务层的比例又下降了40%左右而且剩余的攻击流量明显开始改变策略不再横冲直撞地高频请求而是尝试模拟真实浏览器环境这就为我们第四层的语义防护创造了条件。3.4 第四层语义蜜罐和请求令牌防住“适应型”傀儡能走到第四层的流量说明已经通过了基础指纹筛查和JS挑战。这里面既有真实用户也有开始模拟浏览器的“适应型”傀儡。区分它们的核心在于业务语义——机器人不理解业务的上下文只会按照指令复制粘贴。我们部署的第一类语义蜜罐是“隐形链接”在页面里埋了正常用户不可能看到的隐藏链接和隐藏表单CSS把它们移出可视区域再用透明样式覆盖。用户永远不会点击但爬虫和傀儡会按照页面结构去抓取所有链接一旦请求了这些隐形地址立刻就能判定为自动化工具直接打入黑名单并同步到全局情报库。第二类蜜罐更巧妙叫“假数据接口”。我们在非关键路径上部署了一个返回伪造行情数据的接口正常情况下没有任何真实业务依赖它。攻击方如果大量请求这个接口说明它只是在无差别扫流量而不是真正关心业务数据。我们专门监控这个假接口的访问量一旦突破阈值就把访问来源整体标黑。这个方法在实战中非常有效因为它不依赖攻击者的指纹只看它是否“贪吃”诱导数据。除了蜜罐动态令牌也是这一层的重点。每个真实用户的会话都绑定一个一次性令牌令牌与用户ID、设备指纹、会话上下文绑定同一令牌只能使用一次。傀儡即使通过了JS挑战想要大规模伪造动态令牌的难度也极高因为它必须维持海量真实会话状态这在分布式环境下几乎不可能低成本实现。3.5 第五层跨节点清洗怎么避免“保护了A节点打瘫了B节点”第五层是全局协同层。CC攻击有一个很狡猾的策略叫“多点游击”攻击流量在不同机房之间来回切换你封了A节点它立刻把流量转向B节点。如果每个节点的防护都是孤岛攻防就会变成打地鼠永远处于被动。我们做的第五层本质上是一套全局情报同步网络。所有边缘节点实时把自己的攻击流量特征、封禁IP集合、指纹聚类结果同步到中心的威胁情报池再反向分发到所有节点。任何节点发现的新型攻击特征30秒内全网点生效。这个看似简单实际架构很复杂既要保证同步延迟足够低又要防止情报池本身成为攻击目标所以我们给情报同步做了独立通道和双向校验。跨节点协同还有一个更关键的动作BGP流量牵引。当某个机房的攻击流量超过本地的处置能力时通过路由宣告把被攻击IP的流量牵引到集中的清洗中心清洗完毕后再把干净流量回注到源站。这里有个很容易被忽略的坑回注链路的带宽规划。我们第一次启用牵引时只给“去程”买了足够的带宽结果攻击流量被清洗干净了正常的回程流量却在回注链路上堵死了用户体验反而更差。后来我们把回注带宽设计成至少是正常业务峰值的三倍才彻底解决这个瓶颈。4. 被视野盲区坑过的三次教训流量清洗中的误杀与回源这五层防护并不是一夜之间搭起来的。中间经历了三次比较严重的线上事故每一次都让我们意识到防护系统本身如果设计不好就会变成另一种“攻击”。我把这几个教训写出来比列一堆成功参数更有参考价值。4.1 教训一正常高频交易用户被JS挑战拦成“机器人”我们团队在灰度测试期间曾经把一个专业做高频交易的大客户给拦了。对方用的是一个定制化的极速交易终端底层浏览器引擎做了大量精简优化很多标准JS特性不可用。我们的JS挑战模块识别到这种异常环境直接把它当成了傀儡连续拒绝交易请求。客户那边一个小时损失了上百笔正常交易投诉电话直接打到了CTO那里。这次事故的根因在于我们把人机挑战当成了“铁律”没有给已知可信客户端留出豁免通道。修复方案是在挑战模块前增加一个“可信客户端白名单”判断。凡是持有有效API密钥且来源IP在长期备案白名单内的请求直接跳过JS挑战走第四层的API签名校验。同时给挑战模块增加了一个学习模式上线前先用一周正常流量训练确定哪些环境特征组合一定是真实客户再逐步放开拦截强度。这次事故之后我给自己立了一条规矩任何防护层都必须有旁路、有灰度、有回退按钮。防护的本质是保护业务不是展示技术能力。一个让正常用户无法交易的防护策略再先进也是失败的。4.2 教训二动态令牌动了老客户API的兼容性动态令牌机制在保护网页端和App端时效果很好但到了开放API这里翻了车。一些老的量化交易客户通过API做程序化交易他们维持着长连接、频繁拉取账户数据完全没有走我们动态令牌的“浏览器会话”模式。第四层上线后这些API调用因为缺少动态令牌大量返回401客户的量化策略全部停摆。这是一个典型的“内部视角”错误。我们设计防护时脑子里想的全是攻击者的行为特征忽略了真实用户中有相当一部分不是“人”而是合法的程序。修复方案是给开放API单独设计一套认证链路API Key签名、时间戳防重放、设备绑定标识三项组合对通过认证的合法API请求完全跳过动态令牌校验同时把这套认证逻辑沉淀成SDK提供给客户让他们能在不改变业务代码的前提下完成安全升级。这次教训让我深刻体会到交易平台的防护边界不是“人机之分”而是“可信与不可信之分”。合法API客户端虽然不是“人”但它们是可信的就应该被放行而傀儡流量虽然看起来像“人”但不可信就应该被拦截。4.3 教训三清洗中心回源拥塞正常请求在“最后一公里”被堵死这个坑在3.5节里提过这里展开说一下细节。我们第一次做全球流量牵引时某机房遭遇了大规模CC攻击按照预案我们把流量全部牵引到了清洗中心。清洗中心确实把攻击流量滤掉了但干净流量回注源站的链路只有原来机房带宽的一半。攻击高峰一过业务请求正常反弹回注链路立刻瓶颈所有正常请求都卡在清洗中心和源站之间的通道里。那一刻我们才真正理解DDoS清洗不是“把脏水倒掉再把清水倒回来”那么简单回程通道的容量也是防护的一部分。解决方案除了扩带宽还加了“本地优先”策略当某个节点的攻击规模没有超过本地处理能力的80%时优先在本地完成过滤不轻易触发全局牵引。只有攻击超过了本地阈值才启用到清洗中心的牵引链路。这样一来回注链路的压力被控制在可预期范围内不再成为新的瓶颈。4.4 决策建议给每层防护都装上“手动开关”总结三次教训最终落地的运营守则就一条每个防护层级都必须支持两种模式——检测模式和阻断模式。检测模式下系统只标记可疑流量不实际拦截用于验证规则的准确性阻断模式下才真正执行丢包、限流、验证码等动作。新规则上线必须先在检测模式跑至少24小时确认无误杀后再切换到阻断模式。另外每个关键规则都要有一个顺手的“一键降级”入口当业务大促、大型发布会、New Listing等特殊时段来临时可以临时放宽部分阈值防止防护策略本身成为新的性能瓶颈。5. 攻防结束后的持久战指标度量与持续调优那场攻击最终在持续了大约5个小时后偃旗息鼓。为什么停下来不是因为攻击方好心而是因为我们的五层防护把它的“攻击性价比”打到了低于阈值。当攻击方发现每投入1000万次请求真正能到达业务层的只剩下几万次且这几万次也会被业务层的限流和语义校验处理掉时继续攻击就变成了一件纯粹的亏本买卖。5.1 最终效果峰值请求回落、可用性恢复攻击后期的数据很说明问题。入口层看到的请求量仍然维持在每秒600万左右但经过五层过滤后真正到达业务应用层的请求被压缩到了每秒55万其中有大约20万是正常用户的请求其余35万虽未完全拦截但频率已大幅降低被业务层的令牌桶和排队机制从容消化。核心交易接口的耗时从攻击初期的8000毫秒回落到了300毫秒以内业务成功率回升到99.7%。虽然还没有达到日常的99.95%但对于正在遭受大规模CC攻击的系统来说这个可用性已经足够让用户正常完成交易了。攻击方明显不甘心在停火后48小时内又发起了几次试探性攻击但量级已经从千万级别降到了百万级别而且每次都被我们在前两层就识别出来基本没有对业务造成可感知的影响。这个阶段我反而更警惕因为这说明攻击方正在收集我们的防护情报下一次攻击大概率会更换指纹、更换协议、寻找新的漏洞。攻防一旦开始就不会有真正的终点。5.2 我们坚持看的四个指标经历了这次千亿级攻防后团队内部形成了每周复盘的习惯主要盯四个指标。第一个是“有效请求率”即最终到达业务层并被成功处理的请求占入口请求的比例。正常时通常在90%以上攻击高峰期会骤降到个位数这个指标反映了整体防护的过滤效率。第二个是“误杀率”即被拦截的正常用户请求占正常请求的比例我们给自己定的红线是低于0.5%超过这个值必须立刻核查规则。第三个是“攻击成本比”简单理解就是攻击方每消耗1元成本能够对我们造成多少损失。通过这个指标我们调整防护强度——如果攻击成本比太高说明防护过强了影响了正常用户体验太低则说明防护失效了需要加固。第四个是“恢复时间”从攻击触发到业务指标恢复至正常水平的时间我们要求核心交易场景下恢复时间控制在10分钟以内。这四个指标不是互相独立的。比如过度追求有效请求率误杀率就会上升过度保护正常用户攻击流量就会渗透进业务层。我们每个季度的调优本质上就是在四个指标之间找平衡点。5.3 攻击者也会进化接下来半年我们做什么列表那场攻防结束后的半年里我们做了三件持续性的事情。一是把模拟攻击常态化。每个月做一次红蓝对抗红方专门研究如何穿透我们现有的五层防护。有一次红方成功用“慢速低频率分布式请求”钻了空子每个源IP的请求频率极低完全不像攻击但整体规模庞大把我们的语义蜜罐和动态令牌都绕了过去。这个案例逼着我们开发了第六个检测维度——群体行为基线偏离度不再看单个请求而是看“整体流量的熵值变化”。二是优化人机挑战的体验。我们和前端团队一起把JS挑战的计算方式改成了渐进式用户浏览页面时不感知、不打扰只有检测到异常请求时才静默插入挑战。挑战难度从0到100动态调节80%的用户完全感受不到它的存在只有被判定为高风险的会话才会遇到高难度挑战。三是持续建设黑灰产情报库。和多家交易平台建立了攻击特征共享机制别人家平台刚遭受的新型攻击特征我们这里隔天就能同步到防护规则库。这种同行之间的防御协作效果远好于任何孤立的防护系统。我们自己也把实践中总结的攻击模式反哺给了情报库帮助同行少踩几个坑。回看这次千亿级傀儡流量攻防战五重防护墙的意义不只是挡下了一次攻击而是建立了一套可以持续进化的防御框架。攻击者会换工具、换指纹、换战术但只要这个框架的每一层都能独立演进攻防的天平就不会一边倒。对我们做安全的人来说这才是真正让人安心的状态。