业务高峰期DDoSCC攻击应急防护预案

业务高峰期遭遇DDoS或者CC攻击，本质上不是“防不防得住”的问题，而是一场与时间赛跑的资源争夺战。攻击者赌的是你的应急响应滞后，赌的是你决策链条过长。所以，一份真正能落地的应急预案，核心逻辑不是堆砌硬件，而是预设好自动化触发机制和降级策略，确保业务不彻底停摆。

当攻击流量涌入，第一层防线往往是运营商的清洗服务或者云厂商的高防IP。但很多技术团队容易犯一个错误：把清洗阈值设置得过高，导致攻击流量已经挤垮了源站带宽，清洗还没触发。正确的做法是，在业务高峰期来临前，主动下调清洗触发阈值，哪怕这意味着部分正常流量可能被误判，也比源站直接被打挂要好。同时，必须在接入层做好基于业务特征的精准限流。不要只依赖简单的IP频率限制，攻击者早已用上了海量代理IP。更有效的手段是针对特定API接口的QPS限制，结合用户身份令牌进行限流。例如，对未登录用户的接口访问实施极其严苛的速率控制，而将正常用户的请求引导至缓存节点。

在应用层，CC攻击往往通过耗尽服务器的连接数或CPU资源来达成目的。简单的防火墙规则很难识别出模拟正常浏览行为的攻击。这里需要引入“令牌桶”或者“漏桶”算法进行动态限流。利用Nginx的Lua模块结合Redis集群，可以构建一套高效的分布式限流系统。核心逻辑是，将每个请求的限流状态存储在Redis中，当某个IP或Session在时间窗口内的请求次数超过预设值时，直接返回错误码，不再透传到后端应用。

# 示例：Nginx Lua 结合 Redis 的简易限流逻辑片段
location /api/ {
    access_by_lua_block {
        local redis = require "resty.redis"
        local red = redis:new()
        red:set_timeout(1000)
        local ok, err = red:connect("127.0.0.1", 6379)
        if not ok then
            ngx.exit(503)
            return
        end
        local key = "rate_limit:" .. ngx.var.binary_remote_addr
        local limit = 50  -- 单IP每秒最大请求数
        local current = red:get(key)
        if current and tonumber(current) > limit then
            ngx.exit(429)
            return
        end
        red:incr(key)
        red:expire(key, 1)
    }
    proxy_pass http://backend;
}

这段逻辑的精妙之处不在于代码本身，而在于将限流判断前置到了Nginx层面，避免了请求打到后端语言解释器，极大地节省了服务器资源。在业务高峰期，这种毫秒级的拦截效率就是生与死的区别。同时，Redis的原子性操作保证了分布式集群下计数的准确性，不会因为多节点部署而导致限流失效。

应急响应的最高原则是“弃车保帅”。当攻击流量穿透了清洗防线，或者攻击手法极其隐蔽难以识别时，必须果断启动业务降级。很多公司不敢做降级，是因为没有提前梳理好业务优先级。在高峰期，非核心功能如积分查询、个性化推荐、历史订单列表等，都应该有独立的开关，能够一键关闭。把这些非核心计算资源释放出来，全力保障登录、下单、支付等核心交易链路。同时，静态化是抵御CC攻击最有力的武器之一。将动态页面强制缓存为静态HTML，推送至CDN边缘节点。即使源站完全不可达，只要CDN缓存未过期，用户依然能看到基本页面内容。更进一步，可以构建多级缓存架构：浏览器缓存、CDN缓存、Nginx本地缓存、Redis分布式缓存，每一层都作为下一层的保护垫。

人工分析日志再封禁IP，在高峰期是完全来不及的。必须建立自动化的指纹识别系统。攻击流量无论怎么伪装，在特定维度上总会呈现出聚集性。除了常见的User-Agent和Referer检查，更隐蔽的指纹包括TLS握手特征、HTTP Header顺序、TCP初始窗口大小等。通过实时流处理框架如Kafka加Flink，对访问日志进行毫秒级分析。一旦发现某个特征（例如某个少见的Accept-Language组合）在短时间内请求量激增，且请求路径覆盖大量无关URL，系统应立即自动生成针对该特征的阻断规则，并通过API下发到网关或防火墙。这种闭环的自动化处置流程，将应急响应时间从分钟级压缩到了秒级。

在重保期间，源站IP的暴露是致命的。攻击者一旦绕过CDN直接攻击源站，所有应用层防护都会形同虚设。必须严格执行源站IP隐藏策略，历史解析过的旧IP要彻底废弃。所有对外业务只允许通过高防IP或CDN域名访问，并在源站防火墙设置白名单策略，只允许高防节点的回源IP地址段访问。在网络层，可以利用黑洞路由和流量清洗设备进行联动。当检测到目标IP的入向流量超过链路带宽的某个临界值时，运营商侧自动触发黑洞路由，将攻击流量引入黑洞，同时启动备用高防IP进行流量牵引和清洗。这个过程需要对BGP协议和路由策略有比较深入的掌控，确保切换过程中正常用户的无感。

技术手段再完善，如果监控是盲区，一切等于零。高峰期需要将监控粒度细化到接口级别，而不是只看服务器整体负载。当某个接口的响应时间陡然上升，或者错误率突破阈值，监控系统不仅要告警，更要能自动关联分析。例如，数据库慢查询激增是否与某个接口的流量暴涨同步发生。应急指挥需要有一个统一的“沙盘”，实时展示核心业务指标、攻击流量趋势、清洗量、各节点健康度。这个沙盘的作用是让决策者能在一分钟内判断出：攻击规模有多大、主要攻击手法是什么、当前防护是否有效、是否需要执行下一级预案。决策依据是数据，而不是感觉。

攻击停止并不意味着应急结束。很多次生灾害发生在策略回滚阶段。攻击期间临时上线的严苛限流规则和业务降级开关，如果忘记恢复，就会导致正常用户体验大幅下降，造成人为的故障。因此，应急预案中必须包含详细的回滚清单，每一项临时策略都要有对应的恢复操作和验证方法。同时，对攻击过程中捕获的日志、攻击源IP、攻击手法进行深度复盘，将这些攻击特征固化为常态化的防御规则，更新到WAF和IPS的策略库中。每一次攻击，都应该成为加固防护体系的一次实战演练。

纸面上的预案往往经不起实战的检验。在业务高峰期到来之前，组织无脚本的红蓝对抗演练非常必要。蓝军模拟各种复杂的DDoS和CC攻击组合，红军在没有提前通知的情况下进行防御。这种演练不是为了分出胜负，而是为了暴露预案中的逻辑漏洞。比如，自动切换高防IP的脚本是否真的能跑通？Redis限流在集群主从切换时是否会丢数？多级缓存穿透时，源站的抗压极限是多少？这些具体的数值和逻辑缺陷，只有通过实战化演练才能暴露。把演练中发现的问题逐一解决，预案才会真正具备生命力。