CC攻击

上周三凌晨两点，朋友发来一条消息：“网站又挂了，攻击CPU跑满，攻击带宽没动。攻击”我让他把Nginx的攻击访问日志发我。打开一看，攻击请求全打在同一个搜索接口上，攻击User-Agent清一色是攻击Python-urllib，IP倒是攻击有几百个，但请求间隔精确到毫秒——人手动不出来这种节奏。攻击

这就是攻击CC攻击。全称Challenge Collapsar，攻击名字来源于以前国内一个叫“黑洞”的攻击防护设备，攻击者用大量看似合法的攻击请求把它打穿。说白了，攻击它不靠流量硬冲，而是用“正常请求”压垮你的应用层。你带宽闲着，CPU却烧到冒烟。

很多人把CC和DDoS混为一谈。DDoS是洪水，堵住门就完事；CC是伪装成顾客，反复让你查库存、算价格、生成页面，最后收银员累趴下。区别在于，DDoS打的是网络层，CC打的是业务逻辑层。你防火墙再厚，只要80端口开着，请求就得进后端。

去年有个电商客户被CC打了三天。攻击者盯着商品详情页，每个请求都带上不同的Session ID，绕过简单频率限制。页面要查数据库、渲染模板、调推荐接口，单次响应200毫秒。攻击峰值每秒8000请求，后端只有4台应用服务器，算下来CPU利用率直接飙到100%。运维加了带宽没用，因为出口流量才30Mbps。后来上了验证码，攻击者换了个接口继续打——这次是搜索建议，每次输入一个字母就发请求。你看，CC攻击者不傻，他们专挑你计算密集又不需要登录的接口。

怎么防？我自己的经验是三层。

第一层在边缘。用CDN或者反向代理做请求特征过滤。比如同一个IP在1秒内超过20次请求，直接返回429。但别只靠IP，攻击者手里有代理池。看User-Agent、Referer、Cookie的异常组合。我见过一个案例，攻击请求的Accept-Language全是en-US,en;q=0.9，而正常用户大部分是zh-CN。这种细节能帮你筛掉一大半。

第二层在应用。给每个接口设不同的成本阈值。登录接口加图形验证码，搜索接口加滑动窗口限速，详情页做静态化或缓存。有个技巧：对匿名用户返回简化版页面，登录后才给完整功能。攻击者一般不会费劲注册账号。

第三层在监控。别只看带宽和QPS，盯CPU的sys和user时间，看数据库慢查询数量，看Nginx的upstream_response_time。CC攻击的典型特征是：QPS涨了3倍，但带宽只涨了10%，CPU的sys占比飙升——因为大量时间花在上下文切换和协议解析上。

说到底，CC攻击打的是成本差。攻击者发一个请求的成本几乎为零，你处理一个请求可能要查三次数据库、调两次外部API。防守方要做的，就是把攻击者的成本拉高——加验证、加缓存、加异步。别想着完全挡住，那不可能。目标是让攻击者觉得不划算，换下一个目标。

凌晨四点，朋友按我说的加了接口级限速和UA黑名单。CPU降到15%。攻击者又试了十分钟，走了。日志里留下最后一条记录：GET /search?q=aaaa...aa，后面跟了8000个a。你看，连攻击脚本都懒得改。