WAF实战：从CC攻击到业务风控的服务器安全防护

1. 服务器安全防护的现状与痛点

去年双十一大促期间，我们的电商平台遭遇了持续72小时的CC攻击。攻击者利用数万个代理IP轮番发起请求，导致服务器CPU长期维持在98%以上，正常用户几乎无法完成下单。更糟的是，同一时期还出现了大量利用漏洞脚本批量注册的"羊毛党"，他们用自动化工具抢光了所有优惠券和限量商品。这两类攻击让我们的运维团队连续加班一周，损失直接超过七位数。

这类安全威胁在当今互联网环境中已成常态。根据我多年运维经验，中小型网站主要面临三类典型攻击：

1. 脚本自动化攻击：包括暴力破解（SSH/RDP登录）、漏洞扫描（如WordPress插件漏洞）、API滥用（短信/邮件轰炸）等。攻击者通常使用Python、Go等编写的自动化工具，特征是高频率、有规律的请求。

2. CC攻击（Challenge Collapsar）：通过海量HTTP请求耗尽服务器资源。与DDoS不同，CC攻击的每个请求都模拟正常用户，传统防火墙难以识别。我们遇到的案例中，攻击流量峰值达到8万QPS。

3. 业务逻辑漏洞利用：比如优惠券无限领取、支付金额篡改等。这类攻击往往需要定制化防护，通用安全方案难以覆盖。

2. 传统防护方案的局限性

最初我们尝试用Nginx限流和Fail2ban组合方案：

nginx复制# Nginx限流配置示例
limit_req_zone $binary_remote_addr zone=api_limit:10m rate=10r/s;

location /api {
    limit_req zone=api_limit burst=20 nodelay;
    proxy_pass http://backend;
}

配合Fail2ban监控日志：

ini复制# /etc/fail2ban/jail.local
[nginx-cc]
enabled = true
port = http,https
filter = nginx-cc
logpath = /var/log/nginx/access.log
maxretry = 100
findtime = 60
bantime = 3600

这套方案存在三个致命缺陷：

1. IP黑名单效果有限：攻击者使用代理IP池或僵尸网络时，单个IP的请求量可能并不突出，但总量依然致命。我们曾封禁2000+IP仍无法缓解攻击。

2. 静态规则适应性差：CC攻击的请求路径和参数会动态变化，人工维护规则库成本极高。有次攻击者仅修改了User-Agent就绕过了我们的防护。

3. 业务层防护缺失：无法识别如"同一手机号1秒内多次获取验证码"这类业务逻辑攻击。羊毛党正是利用这个漏洞批量注册了上万个账号。

3. WAF的深度集成实践

经过多轮测试，我们最终选择了雷池（SafeLine）WAF。与云WAF不同，它的开源版本支持本地化部署，避免业务数据经过第三方。以下是关键配置步骤：

3.1 部署架构设计

我们采用旁路部署模式，通过镜像流量实现零侵入：

code复制客户端 → 负载均衡 → [WAF检测] → 业务服务器
                   ↗ 镜像流量

这种架构下，即使WAF宕机也不影响正常业务，同时能获取完整的请求数据。Nginx配置示例：

nginx复制# 在LB层配置流量镜像
mirror /mirror;
mirror_request_body on;

location = /mirror {
    internal;
    proxy_pass http://waf:8080$request_uri;
    proxy_set_header X-Real-IP $remote_addr;
}

3.2 规则配置策略

雷池WAF的核心优势在于动态规则引擎。我们针对不同攻击类型设置了分层防护：

特别重要的是开启"学习模式"至少24小时，让WAF建立正常的流量基线。我们曾因跳过这一步导致误封正常用户。

3.3 业务逻辑防护实现

通过自定义规则实现业务层防护。例如防羊毛党规则：

lua复制-- 检查同一设备ID在10分钟内领取优惠券超过3次
if ngx.var.cookie_device_id and ngx.var.uri == "/coupon/get" then
    local key = "anti_cheat:" .. ngx.var.cookie_device_id
    local count = redis:incr(key)
    if count == 1 then
        redis:expire(key, 600)
    end
    if count > 3 then
        return ngx.exit(403)
    end
end

配合前端埋点收集设备指纹，大幅提高了攻击者的作弊成本。

4. 防护效果与调优经验

上线首月即拦截了超过200万次恶意请求，其中：

• 自动化工具攻击占比62%
• CC攻击占比28%
• 业务漏洞利用尝试10%

三个关键调优经验：

1. 误报处理：初期因User-Agent规则过于严格，导致部分老旧客户端无法访问。通过以下方法优化：

   • 设置白名单路径（如静态资源）
   • 对拦截请求添加验证码而非直接封禁
   • 建立误报反馈通道快速调整规则

2. 性能损耗控制：开启全量检测时CPU负载增加约15%。通过以下措施降低影响：

   • 对已知安全IP跳过部分检测
   • 关闭非必要正则匹配
   • 使用硬件加速SSL解密

3. 规则更新机制：建立每周规则评审制度，结合攻击日志分析新增威胁模式。曾通过分析日志发现攻击者利用HTTP/2的流量特征绕过检测，及时更新了协议层防护规则。

5. 进阶防护方案组合

单一WAF并非银弹，我们最终形成的防御体系包含：

1. 网络层：云厂商的DDoS防护+自建IP信誉库
2. 应用层：WAF+自定义业务风控规则
3. 主机层：Fail2ban补强SSH防护
4. 监控层：实时流量分析告警

特别推荐GMSSH（Go Modified SSH）替代标准SSH服务。它在协议层面混淆了握手过程，让自动化爆破工具失效。实测使SSH暴力破解尝试下降90%：

bash复制# 安装GMSSH
wget https://github.com/gmssh/gmssh/releases/download/v1.0.0/gmssh_linux_amd64
chmod +x gmssh_linux_amd64
mv gmssh_linux_amd64 /usr/local/bin/gmssh

# 修改sshd配置
echo "Port 2222" >> /etc/ssh/sshd_config
echo "GMSSHPort 22" >> /etc/ssh/sshd_config
systemctl restart sshd

这套组合方案实施后，服务器安全事件处理时间从月均40小时降至不足2小时。最直观的变化是凌晨3点的告警电话终于不再响起。