按需防护模式适配不同场景CC攻击防御

CC攻击的防御难点从来不在“有没有防护”，而在“防护是不是按需生效”。很多业务一接入通用CC策略，要么误杀正常用户，要么在突发流量下形同虚设。真正有效的做法，是把防护模式与业务场景拆开，针对登录、搜索、API、活动页等不同入口配置差异化的CC防御规则。按需防护的核心逻辑是：先识别当前请求属于哪个场景，再匹配该场景下的人机验证强度、速率阈值和处置动作，而不是对全站套用同一套拦截标准。

CC攻击之所以难以用单一策略应对，是因为攻击者会模拟真实用户行为。比如对登录接口发起低频撞库，每个IP每分钟只请求几次，传统基于固定阈值的限速根本拦不住；而对搜索接口发起高频遍历，请求量瞬间拉满，又需要更激进的频控。如果把搜索接口的严格频控套到登录接口上，正常用户输错几次密码就被封禁；反过来把登录接口的宽松策略套到搜索接口，攻击流量又直接穿透。所以按需防护的第一层，就是按URL路径、请求方法、参数特征把业务拆成多个防护域。

实施按需防护前，需要先梳理业务里哪些入口容易被CC攻击盯上。通常可以按功能划分：账号体系类接口（注册、登录、找回密码）、数据查询类接口（搜索、筛选、列表翻页）、交易操作类接口（下单、支付、提交表单）、内容展示类页面（文章详情、商品详情、活动落地页）。每一类场景的访问频率基线、单IP合理请求量、用户交互节奏都不同。比如一个正常用户在商品详情页可能连续浏览几十个SKU，但在支付接口一分钟内最多提交几次。如果不对场景做区分，频控阈值只能取一个折中值，结果就是两边都不讨好。

场景识别可以通过请求特征自动完成，不必依赖人工标注。常见做法是在网关层或WAF层配置规则，根据URI前缀、HTTP方法、Content-Type、特定参数名来标记请求所属场景。例如所有以/api/login开头的请求归入“登录场景”，以/api/search开头的归入“搜索场景”。标记完成后，每个场景挂载独立的防护策略，策略之间互不影响。这样攻击者即便绕过了A场景的阈值，也无法用同一套请求特征去打B场景。

固定阈值限速是最基础的CC防御手段，但按需防护要求阈值本身也是动态的、多维的。单IP每分钟请求次数只是其中一个维度，还需要结合单IP并发连接数、单会话请求间隔、单参数重复度、UA特征一致性等指标综合判断。以登录场景为例，正常用户输错密码后会有几秒到几十秒的思考时间，攻击脚本则是毫秒级连续提交。此时“请求间隔中位数”比“每分钟总请求数”更能区分人和机器。可以设定：单IP对登录接口的请求间隔中位数小于2秒且连续失败超过5次，触发滑块验证；验证失败再升级为短时封禁。

搜索场景的防护重点在于防止攻击者用大量随机关键词消耗后端数据库资源。可以针对搜索参数做去重和复杂度检测：同一个IP在短时间内提交的关键词如果重复率低于某个阈值，或者关键词长度、字符集分布异常，直接判定为CC攻击。还可以对搜索结果页码做限制，正常用户很少翻到第50页以后，攻击脚本为了拖库往往会遍历深分页。把“深分页请求占比”纳入搜索场景的速率模型，能有效拦截那些靠翻页绕过频控的攻击。

很多站点一遇到CC攻击就全站弹验证码，结果攻击没完全挡住，正常用户体验直线下降。按需防护的做法是把人机验证作为分级处置手段，只在特定条件下触发。第一级是无感校验，比如检查Cookie有效性、JS执行结果、浏览器指纹一致性，这些对用户透明；第二级是轻量交互，比如滑块、点选，只在请求行为异常时出现；第三级是强验证，比如短信验证码或扫码，只用于账号体系核心操作。不同场景挂载不同的验证级别，登录场景可以直接上强验证，内容展示场景最多到无感校验。

触发条件的设定要结合场景的容忍度。活动页在整点秒杀时请求量会瞬间飙升，如果此时因为流量突增就弹滑块，反而会挡住真实抢购用户。正确做法是提前预估活动流量峰值，把阈值调到峰值以上，同时开启无感校验过滤掉明显的脚本流量。对于API接口，人机验证往往不适用，因为调用方是程序而不是浏览器。这时需要换成签名校验、Token时效校验、请求序列校验等机器可执行的验证方式，本质上也是按场景选择验证手段。

CC防御的处置动作不能只有“放行”和“封禁”两种极端。封禁IP虽然简单直接，但在NAT出口大量用户共享IP的场景下会误伤一片。按需防护要求处置动作分级递进：先观察、再限速、再验证、再短时封禁、最后长时封禁。观察阶段只记录日志不干预，用于积累行为基线；限速阶段对超阈值请求做排队或降级处理；验证阶段要求客户端完成额外校验；短时封禁通常设置为几分钟到几十分钟，既能打断攻击节奏，又不会对正常用户造成长期影响。

封禁的粒度也要按场景调整。对于登录接口，封禁IP容易误伤企业出口或校园网，可以改为封禁“IP+账号”组合，或者封禁特定设备指纹。对于API接口，封禁IP通常有效，因为API调用方一般是固定服务器。对于搜索接口，可以封禁“IP+UA”组合，避免误伤同一出口下使用不同浏览器的用户。处置动作的生效时间也要有衰减机制，比如第一次触发封禁10分钟，第二次30分钟，第三次2小时，避免攻击者反复试探。

静态规则的最大问题是跟不上攻击手法的变化。按需防护要求每个场景都维护一套实时行为基线，基线数据来自最近一段时间的正常流量统计。比如登录接口的基线显示，正常用户平均每分钟请求1.2次，失败率低于15%，请求间隔中位数在8秒以上。当实时流量偏离基线超过一定幅度时，自动收紧策略；流量恢复后自动放宽。这种动态调整可以用滑动窗口算法实现，窗口长度按场景设定，登录场景取30分钟，搜索场景取5分钟，活动页取1分钟。

实时基线的另一个作用是发现慢速CC攻击。慢速CC攻击的请求速率很低，每分钟只有几次，但持续时间长，每个请求都消耗大量服务器资源。固定阈值限速对这种攻击无效，但通过对比实时行为基线与历史基线，可以发现某些IP的请求间隔异常均匀、请求内容高度相似、资源消耗显著偏高。把这些特征纳入评分模型，即使请求速率不超标，也能触发验证或限速。

要在现有架构上落地按需防护，不需要推翻重建。通常可以在WAF层或网关层增加一个场景路由模块，把请求按规则打标后分发到不同的策略引擎。策略引擎内部维护每个场景的计数器、滑动窗口、行为基线，输出处置建议。处置动作由网关执行，可以是返回验证页、注入JS挑战、丢弃请求、重定向等。关键是把策略配置做成可热更新的，攻击手法变化时不用重启服务。

配置管理上，建议为每个场景建立独立的策略配置文件，包含阈值参数、验证级别、处置动作、白名单规则。白名单要支持按IP段、UA、Cookie、Header等多种条件组合，避免误伤搜索引擎爬虫、监控探针、合作伙伴API调用。日志层面要记录每个请求命中的场景、触发的规则、采取的处置动作，方便事后复盘和调参。没有日志支撑的CC防御，调优只能靠猜。

测试验证环节不能只靠压测工具模拟。压测工具产生的流量特征和真实CC攻击有差异，建议在灰度环境回放真实攻击样本，观察策略命中率和误杀率。同时要定期做攻防演练，用变种攻击手法测试策略的鲁棒性。按需防护不是一劳永逸的配置，而是一个持续迭代的过程。业务上新功能、流量结构变化、攻击工具升级，都需要重新审视各场景的防护策略是否仍然匹配。

最终衡量按需防护效果的标准只有两条：攻击流量是否被有效压制，正常用户是否无感通过。任何一条不达标，都说明场景拆分不够细、阈值设定不够准、处置动作不够合理。把这两条标准量化成可监控的指标，比如攻击期间的业务可用性、正常用户的验证触发率、误封申诉量，才能让CC防御从“能挡”进化到“挡得准”。