网站安全防护实战：WAF规则配置与CC攻击防御策略

2026年7月16日互联网

随着 Web 应用安全威胁日益复杂，WAF（Web Application Firewall）已成为网站安全防护的标配。本文将深入探讨 WAF 的核心防护机制，并通过实际配置演示如何构建有效的 CC 攻击防御体系。

一、WAF 防护架构概述

WAF 工作在 HTTP 层，通过解析请求内容匹配规则集，拦截恶意流量。与网络层防火墙不同，WAF 能理解 HTTP 语义，检测 SQL 注入、XSS 跨站脚本、命令注入等应用层攻击。

# ModSecurity 核心配置示例
SecRuleEngine On
SecRequestBodyAccess On
SecRule REQUEST_HEADERS:Content-Type "text/xml" \
     "id:1000,phase:1,t:none,t:lowercase,pass,nolog,ctl:requestBodyProcessor=XML"

# OWASP CRS 规则集加载
Include /etc/modsecurity/owasp-crs/crs-setup.conf
Include /etc/modsecurity/owasp-crs/rules/*.conf

# 自定义规则：拦截特定 User-Agent
SecRule REQUEST_HEADERS:User-Agent \
     "@pmni scanners.txt" \
     "id:1001,phase:1,deny,status:403,log,msg:'Scanner blocked'"

ModSecurity 是最成熟的开源 WAF 引擎，配合 OWASP CRS（Core Rule Set）规则集，可以覆盖绝大多数 OWASP Top 10 威胁。但默认配置容易产生误报，需要根据业务特点进行调优。

二、CC 攻击的特征与识别

CC（Challenge Collapsar）攻击通过模拟正常用户请求，高频访问消耗服务器资源。与 DDoS 的网络层洪泛不同，CC 攻击流量看起来完全合法，传统的限速策略难以有效应对。

CC 攻击的典型特征包括：单一 IP 或 IP 段高频请求同一 URL；请求间隔极度均匀（机器人特征）；User-Agent 异常或频繁变化；忽略静态资源只请求动态接口；请求参数模式高度重复。

# Nginx 限速配置：基于请求速率
http {
    # 定义请求限速区域
    limit_req_zone $binary_remote_addr zone=api_limit:10m rate=30r/s;
    limit_req_zone $binary_remote_addr zone=static_limit:10m rate=100r/s;
    
    # 连接数限制
    limit_conn_zone $binary_remote_addr zone=conn_limit:10m;

    server {
        listen 80;
        
        # 动态接口限速
        location /api/ {
            limit_req zone=api_limit burst=50 nodelay;
            limit_conn conn_limit 20;
            limit_req_status 429;
            proxy_pass http://backend;
        }
        
        # 静态资源宽松限速
        location ~* \.(js|css|png|jpg|gif|woff2)$ {
            limit_req zone=static_limit burst=200 nodelay;
            proxy_pass http://backend;
        }
    }
}

burst 参数允许短时突发流量，nodelay 确保突发请求不延迟排队而是立即处理。429 状态码明确告知客户端请求过多，比 403 更语义准确。

三、多维度 CC 防御策略

单纯的速率限制无法应对分布式 CC 攻击。需要结合行为分析、人机验证和智能限速构建多层防御体系。

# Lua + Nginx 实现智能限速
# /etc/nginx/lua/cc_defense.lua

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
    return
end

local client_ip = ngx.var.remote_addr
local uri = ngx.var.uri
local key = "cc:" .. client_ip .. ":" .. uri

-- 滑动窗口计数
local count = red:incr(key)
if count == 1 then
    red:expire(key, 10) -- 10秒窗口
end

-- 三级阈值策略
if count > 200 then
    -- 第三级：封禁 IP 30 分钟
    red:setex("ban:" .. client_ip, 1800, "1")
    ngx.exit(ngx.HTTP_FORBIDDEN)
elif count > 100 then
    -- 第二级：要求人机验证
    if not ngx.var.cookie_cc_token then
        ngx.header["Set-Cookie"] = "cc_challenge=1; Path=/; HttpOnly"
        ngx.exit(ngx.HTTP_MOVED_TEMPORARILY)
    end
elif count > 60 then
    -- 第一级：动态延迟
    ngx.sleep(0.5)
end

-- 检查 IP 封禁状态
local banned = red:get("ban:" .. client_ip)
if banned then
    ngx.exit(ngx.HTTP_FORBIDDEN)
end

red:set_keepalive(10000, 100)

三级策略形成了递进式防御：第一级通过延迟降低攻击效率但不影响正常用户；第二级要求人机验证过滤自动化工具；第三级直接封禁恶意 IP。使用 Redis 滑动窗口确保计数精确且分布式环境下共享状态。

四、WAF 规则调优与误报处理

WAF 规则误报是生产环境中最常见的痛点。建议采用先检测后拦截的渐进式部署策略：先以 DetectionOnly 模式运行，收集日志分析误报，再逐步切换为拦截模式。

# 误报排除规则示例
# 排除特定 URL 的某条规则
SecRule REQUEST_URI "@beginsWith /api/search" \
    "id:1002,phase:1,pass,nolog,ctl:ruleRemoveById=942100"

# 全局排除特定参数的规则检测
SecRule ARGS_NAMES "@streq description" \
    "id:1003,phase:2,pass,nolog,ctl:ruleRemoveById=941120-942200"

# 基于请求来源的信任白名单
SecRule REMOTE_ADDR "@ipMatch 10.0.0.0/8,192.168.0.0/16" \
    "id:1004,phase:1,pass,nolog,ctl:ruleEngine=Off"

# 日志级别配置
SecAuditEngine RelevantOnly
SecAuditLogFormat JSON
SecAuditLog /var/log/modsecurity/audit.log
SecRule RESPONSE_STATUS "@gt 399" "id:1005,phase:5,pass,log,msg:'Blocked request'"

排除规则应该尽可能精确，避免使用 ctl:ruleEngine=Off 全局关闭。通过 ruleRemoveById 针对特定规则排除，通过 ARGS_NAMES 针对特定参数排除，将安全保障范围控制在最小必要程度。

五、实战架构建议

首先，WAF 应部署在负载均衡器之后、应用服务器之前，作为反向代理拦截恶意请求。其次，建立 WAF 日志的实时监控和告警体系，使用 ELK 或 Loki 对拦截日志进行可视化分析，及时调整规则。第三，定期进行安全扫描和渗透测试，验证 WAF 规则的覆盖度。第四，对于高价值业务，考虑部署云 WAF 加本地 WAF 的双层防护，云 WAF 负责大流量清洗，本地 WAF 负责精细化规则匹配。最后，CC 防御策略需要持续迭代，攻击者的手法在不断进化，防御策略也应保持动态调整。

网站安全是一场没有终点的攻防博弈。WAF 和 CC 防御不是配置一次就一劳永逸的，需要持续监控、分析和优化，才能在保障业务正常运转的同时有效抵御安全威胁。