防御CC攻击业务侧接口保护配合防护

CC攻击的可怕之处不在于流量有多大，而在于它把压力精准地导向了业务逻辑最脆弱的那一层。很多运维人员习惯性地把防御重心放在网络入口的流量清洗上，却忽略了即使请求穿过了防火墙、WAF和限速设备，最终落到应用服务器上的每一次数据库查询、每一次动态页面渲染，依然可能成为压垮业务的最后一根稻草。业务侧接口保护配合防护，本质上是在应用层建立第二道防线，让那些看似“合法”的请求无法真正消耗核心资源。

先明确一个基本判断：网络层的CC防护解决的是“请求能不能进来”，业务侧的接口保护解决的是“请求进来后有没有资格消耗资源”。两者不是替代关系，而是接力关系。如果只做前者，攻击者可以构造完全符合HTTP协议规范的请求，模拟正常用户的访问行为，但请求频率极高、目标接口极重，比如搜索接口、短信发送接口、登录校验接口、订单提交接口。这些请求在流量清洗设备看来就是普通流量，但到了业务服务器上，一次请求可能触发几十次数据库读写，攻击成本与防御成本严重不对等。

业务侧接口保护的第一原则是“先验证，后执行”。任何可能消耗服务器资源的操作，都必须经过轻量级的验证步骤。验证步骤本身要足够轻，轻到攻击者发起一百万次验证也不会对服务器造成明显压力，但验证通过后的业务操作要有严格的频次和资格限制。具体落地时，可以从以下几个层面展开。

第一层是接口粒度的频次控制。很多系统只做了IP粒度的限速，比如单IP每秒最多10个请求。但CC攻击者往往拥有大量IP资源，单IP限速很容易被绕过。更有效的做法是对关键接口单独设置频次阈值，并且把限速维度从IP扩展到用户ID、设备指纹、会话Token等业务标识。比如登录接口，同一个账号10秒内最多尝试3次，同一个设备指纹1分钟内最多尝试5次，同一个IP 1分钟内最多尝试20次。多层维度叠加后，攻击者即使更换IP，也会因为设备指纹或账号维度被拦截。

第二层是异步化与削峰填谷。对于短信验证码、邮件发送、支付回调通知这类高成本接口，不要同步处理。请求进来后先写入消息队列，由后台消费者按固定速率处理。这样即使瞬间涌入大量请求，业务服务器也不会被直接打垮，队列可以起到缓冲作用。同时配合队列长度监控，当队列积压超过阈值时，直接拒绝新的入队请求并返回友好提示。攻击者看到的是请求被快速拒绝，而正常用户在队列未满时依然可以正常使用服务。

第三层是验证码与行为验证的精准投放。很多人反感验证码，认为影响用户体验，但验证码恰恰是区分正常用户与自动化攻击最有效的手段之一。关键是要做到“精准投放”，而不是全站开启。可以在接口频次控制触发后，对该请求来源自动弹出验证码。比如同一IP或设备指纹在1分钟内请求登录接口超过5次，第6次请求必须通过滑块验证或图形验证码才能继续。正常用户偶尔触发验证码，体验影响可控；攻击者面对验证码，自动化脚本的效率和成本会大幅上升。

下面给出一个基于Nginx + Lua + Redis的轻量级业务侧接口保护实现思路。这个方案不需要修改业务代码，通过网关层脚本即可完成大部分防护逻辑。

-- 在Nginx的access_by_lua阶段执行
local redis = require "resty.redis"
local cjson = require "cjson"

local function get_redis()
    local red = redis:new()
    red:set_timeout(1000)
    local ok, err = red:connect("127.0.0.1", 6379)
    if not ok then
        return nil
    end
    return red
end

local function check_rate_limit(key, limit, window)
    local red = get_redis()
    if not red then
        return true  -- Redis故障时放行，避免误伤
    end
    local current = red:incr(key)
    if current == 1 then
        red:expire(key, window)
    end
    red:set_keepalive(10000, 100)
    if current > limit then
        return false
    end
    return true
end

-- 获取客户端标识：优先使用设备指纹，其次使用IP
local device_id = ngx.var.cookie_device_id or ngx.var.remote_addr
local uri = ngx.var.uri

-- 针对登录接口的多维度限速
if uri == "/api/login" then
    local ip_key = "rate:login:ip:" .. ngx.var.remote_addr
    local device_key = "rate:login:device:" .. device_id
    
    if not check_rate_limit(ip_key, 20, 60) then
        ngx.status = 429
        ngx.say(cjson.encode({code = 429, msg = "请求过于频繁，请稍后再试"}))
        return ngx.exit(429)
    end
    
    if not check_rate_limit(device_key, 10, 60) then
        ngx.status = 429
        ngx.say(cjson.encode({code = 429, msg = "操作过于频繁，请稍后再试"}))
        return ngx.exit(429)
    end
end

-- 针对搜索接口的限速，搜索接口通常较重
if uri == "/api/search" then
    local search_key = "rate:search:ip:" .. ngx.var.remote_addr
    if not check_rate_limit(search_key, 30, 60) then
        ngx.status = 429
        ngx.say(cjson.encode({code = 429, msg = "搜索频率过高，请稍后再试"}))
        return ngx.exit(429)
    end
end

这段代码的核心价值在于：它在请求进入业务逻辑之前就完成了频次校验，被拦截的请求根本不会触达应用服务器和数据库。Redis的INCR操作是原子性的，单次操作耗时在亚毫秒级别，即使攻击者每秒发起数万次请求，Redis也能轻松应对，而业务服务器则完全不受影响。

需要注意的是，上述代码中的限速阈值需要根据实际业务场景调整。登录接口的阈值应该比搜索接口更严格，因为登录接口涉及密码校验，计算成本更高。同时要监控Redis的可用性，一旦Redis故障，限速逻辑应该自动降级为放行或使用本地内存计数，避免因为防护组件故障导致业务全挂。

业务侧接口保护不是孤立存在的，它需要与网络层的CC防护形成联动。一个典型的配合流程是这样的：网络层防护设备（如高防IP、抗DDoS设备）首先对进入机房的流量进行清洗，过滤掉明显的攻击流量，比如SYN Flood、UDP Flood、HTTP Flood中的异常包。清洗后的流量进入WAF，WAF根据规则库拦截SQL注入、XSS等攻击请求。经过这两层过滤后，剩下的请求才到达业务网关，此时业务侧接口保护开始发挥作用。

这种分层防护的好处是每一层都只处理自己最擅长的事情。网络层防护擅长处理大流量攻击，业务侧接口保护擅长处理精细化、模拟正常行为的攻击。如果攻击流量特别大，网络层防护会先扛住大部分压力，业务侧接口保护只需要处理“漏网之鱼”。如果攻击流量不大但请求非常精准，网络层防护可能无法识别，此时业务侧接口保护就成了最后一道防线。

在实际部署中，还有一个容易被忽视的配合点：业务侧接口保护产生的拦截数据应该反馈给网络层防护设备。比如业务侧发现某个IP段在短时间内大量触发限速规则，可以将这些IP段同步给网络层防护设备，在网络入口直接封禁。这种“业务侧发现、网络侧封禁”的联动机制，可以大幅提升整体防护效率。实现方式可以通过API对接，也可以将拦截日志输出到统一的日志平台，由网络层防护设备定期拉取并更新黑名单。

很多系统在触发限速后，统一返回HTTP 429状态码。这样做虽然简单，但会给攻击者一个明确的信号：这个接口有频次限制，换个IP继续打。更聪明的做法是差异化返回。对于触发限速的请求，可以返回HTTP 200，但响应内容是一个空数据或缓存的静态内容，让攻击者误以为请求成功但业务没有响应。或者随机返回不同的错误码，增加攻击者的判断成本。当然，这种做法需要谨慎使用，避免影响正常用户的体验和问题排查。

另一个细节是限速窗口的滑动性。固定窗口限速存在边界问题，比如1分钟窗口内前59秒没有请求，最后1秒突然涌入大量请求，固定窗口算法无法有效拦截。滑动窗口或令牌桶算法可以更平滑地控制请求速率。如果使用Redis实现，可以用ZSET来做滑动窗口计数，但要注意内存占用。对于大多数业务场景，固定窗口配合合理的阈值已经足够，不必过度设计。

防护措施上线后，监控是验证效果的关键。需要监控的指标包括：每个接口的请求量、触发限速的次数、限速后的拦截率、Redis的QPS和延迟、业务服务器的CPU和内存使用率。当拦截率突然升高时，可能意味着正在遭受攻击，也可能意味着正常用户的访问模式发生了变化。需要结合业务数据判断，避免误伤。

告警阈值要设置得合理。比如登录接口的限速触发次数在5分钟内超过1000次，就应该发出告警，提示可能正在遭受撞库或CC攻击。同时要保留详细的拦截日志，包括请求来源IP、设备指纹、请求时间、触发的是哪条规则。这些日志不仅是安全审计的依据，也是后续优化限速阈值的数据基础。

业务侧接口保护配合网络层防护，本质上是在用最小的成本构建纵深防御体系。网络层防护解决“量”的问题，业务侧接口保护解决“质”的问题。两者配合起来，才能应对那些既不像洪水一样汹涌、又不像漏洞攻击那样有明显特征的CC攻击。对于任何有在线业务的企业来说，这套组合拳不是可选项，而是必选项。