资讯站点海量访问下CC攻击过滤技巧

处理资讯站点海量访问下的CC攻击，本质上是在和攻击者比拼资源解析效率。传统的防火墙规则在面对分布式的、模拟真实浏览行为的CC攻击时，延迟和误杀率都高得惊人。核心思路必须从“全量请求分析”转向“极轻量级前置过滤”，把恶意流量挡在应用逻辑和数据库之外，最好挡在服务器计算资源之外。

不要在Web服务器层面硬抗。Nginx或Apache虽然有连接限制模块，但在海量CC攻击下，频繁的accept和close事件本身就会拖垮CPU。最有效的第一道防线是内核层面的包过滤或DPDK（数据平面开发套件）技术。利用Linux内核的iptables配合ipset，或者更高级的XDP（eXpress Data Path）技术，可以在网卡驱动层直接丢弃恶意数据包。例如，通过分析流量特征，将攻击源IP实时加入ipset黑名单，由iptables直接DROP，这种处理速度是应用层防火墙的数百倍。对于千万级并发，XDP程序能在纳秒级完成包过滤，几乎不消耗CPU资源。

CC攻击之所以难防，是因为它经常完成TCP三次握手，甚至发起合法的HTTP请求。针对这一点，必须引入无状态的验证机制。最经典的方案是“SYN Cookie”的HTTP版——客户端重定向验证。当请求到达边缘节点时，不立即创建会话或连接后端，而是返回一个302重定向，并在重定向URL中嵌入一个加密的、带时效的令牌。合法的浏览器会自动跟随重定向并携带令牌，而绝大多数CC攻击脚本不具备完整的重定向跟随和Cookie管理能力。验证通过后，将该源IP加入一个有时效的白名单，后续请求直接放行。这能过滤掉99%的低级攻击脚本。

对于能跟随重定向的高级攻击工具，需要嵌入JavaScript挑战。但要注意，不能粗暴地使用让用户等待5秒的旧式JS跳转，这会严重伤害搜索引擎爬虫和真实用户体验。现代技巧是执行一个极轻量级的、基于浏览器指纹的JS计算。让客户端计算一个特定的哈希值或执行一次WebGL渲染指纹采集，然后将结果作为Token回传。攻击脚本通常基于无头浏览器或简单的HTTP库，其JS执行环境与真实浏览器存在细微差异，例如对Canvas指纹、WebGL渲染器字符串、或者对特定DOM事件的支持缺失。通过在边缘层验证这些指纹特征，可以精准识别并拦截模拟器流量，而对真实用户完全无感。

针对资讯站点，正常用户的访问路径和CC攻击有本质区别。正常用户会浏览首页、列表页、内容页，请求中会携带Referer，对图片、CSS、JS等静态资源有自然的加载序列。而CC攻击往往集中打击某一个或几个高开销的搜索接口或动态页面，且请求头组合单一。建立一个基于Nginx Lua或OpenResty的实时分析层，统计每个IP在滑动时间窗口内的请求多样性、静态资源命中率、以及页面停留时间推断。如果某个IP在10秒内请求了20次同一个API接口，且从不请求任何静态资源，直接触发惩罚。更进一步，可以对接第三方的威胁情报IP信誉库，或者自建信誉库：对于在全网范围内发起过扫描、撞库行为的IP，直接提升其风险分值。

CC攻击的核心目标是耗尽服务器资源，尤其是数据库查询。对于资讯站点，90%以上的内容是可以静态化的。不要等到攻击发生时再想缓存策略，而应该在架构设计上就实现动静分离。对于文章详情页，强制全页缓存到CDN边缘节点，即使后端被攻击，边缘节点仍可正常服务。关键在于，针对攻击者可能频繁穿透缓存的带参数请求，如“?from=attack_test_random”，要配置严格的参数过滤与缓存键规范。只允许合法的分页参数和搜索参数穿透到后端，其余非法参数组合一律返回缓存中的默认版本或直接忽略参数后服务。这样，攻击者制造的海量随机参数请求，反而全部命中了CDN缓存，变成了给CDN做压力测试，源站毫发无伤。

当上述自动化手段都无法完全甄别时，验证码是最后一道防线，但部署方式必须隐形。不要等到服务器已经高负载时才弹出验证码，那时为时已晚。应该在流量清洗层，根据IP的信誉分和实时行为分，动态决定是否注入验证码。例如，对于低风险IP，完全无感知；对于中风险IP，在页面异步加载一个不可见的验证码挑战，在后台静默完成验证；只有对高风险IP，才弹出可见的滑块或点击验证。这种分级响应机制，既保护了普通用户，又能在攻击流量达到阈值前，逐步消耗攻击者的计算资源和IP池。

以下是一段在OpenResty中实现的简易但高效的令牌桶限流和UA特征过滤代码，它直接运行在Nginx的access阶段，性能极高：

-- 定义共享内存，存储IP访问频率
local limit_req = require "resty.limit.req"
local lim, err = limit_req.new("my_limit_req_store", 200, 100)
-- 每秒200个请求，突发容量100，对于正常资讯浏览足够

if not lim then
    ngx.log(ngx.ERR, "failed to instantiate a resty.limit.req object: ", err)
    return ngx.exit(500)
end

-- 基础UA黑名单，拦截常见的攻击库标识
local ua = ngx.var.http_user_agent
if ua and (ua:find("ApacheBench") or ua:find("python-requests") or ua:find("Go-http-client")) then
    ngx.exit(444) -- 直接关闭连接，不返回任何信息
end

-- 获取请求来源IP
local key = ngx.var.binary_remote_addr
local delay, err = lim:incoming(key, true)
if not delay then
    if err == "rejected" then
        -- 触发限流，返回444或重定向到验证页面
        ngx.exit(444)
    else
        ngx.log(ngx.ERR, "failed to limit req: ", err)
        return ngx.exit(500)
    end
end

-- 如果请求被延迟，说明接近阈值，可在此注入隐形挑战逻辑
if delay > 0 then
    -- 可以设置一个响应头，或者记录日志，后续分析
    ngx.header["X-Rate-Limit-Delay"] = delay
end

这段代码展示了如何在请求处理的早期阶段，用极低的成本拦截掉特征明显的脚本攻击和超频请求。实际部署时，可以将444状态码替换为向验证服务发起的内部重定向。

防守不能总是被动响应。需要建立一套离线分析系统，将访问日志实时投递到大数据平台。通过分析历史数据，找出攻击流量的隐蔽特征，例如集中在某个地区的AS号、特定的TCP窗口大小、或者TLS握手中的特定密码套件偏好。一旦提炼出新的特征，立即通过API自动下发规则到边缘过滤层。这种“学习-提炼-下发”的闭环，能让防御体系具备进化能力。例如，发现某次攻击的源IP都来自几个特定的云服务商网段，且正常用户极少，就可以临时对这些网段实施更严格的验证策略。

假设攻击流量极其庞大且高度拟人化，穿透了所有技术防线，此时必须保证核心业务可用。对资讯站点而言，搜索功能、评论发布功能、个性化推荐接口是CPU消耗大户。在监控到这些接口的响应时间超过阈值时，应自动触发业务降级。例如，搜索功能暂时关闭复杂排序，仅提供基于时间的简单检索；评论功能临时关闭，或切换为审核后可见模式；推荐接口直接返回编辑精选的热门文章列表，而不是实时计算。这种业务层面的熔断机制，确保了即使在被攻击的最坏情况下，用户依然能够正常阅读文章内容，保住了资讯站点的根本价值。