CC防护Web应用防火墙自定义规则防护特定接口

CC防护Web应用防火墙（WAF）自定义规则的核心就是针对你业务中那些容易被CC攻击的特定接口，比如登录接口、短信验证码接口、搜索接口、数据查询接口等，通过设定精准的访问频率限制、请求特征匹配和行为分析策略，把恶意的高频请求拦截在外面，同时不影响正常用户的访问体验。说白了，就是给你的接口装一个"智能门卫"，只放行正常人，把刷接口的机器人和攻击者挡在门外。

很多企业用了WAF之后发现，默认规则只能挡住通用型的攻击，但针对自己业务特有的接口，比如一个每秒被刷几百次的查询接口，通用规则根本管不了。这时候就必须上自定义规则，根据你自己的业务逻辑、接口路径、请求参数来量身定做防护策略。下面我会从规则设计思路、具体配置方法、实战案例到调优技巧，把这件事讲透。

WAF自带的CC防护通常是基于全局频率限制的，比如设定每个IP每秒最多访问50次。但实际业务中问题远比这复杂。有些接口正常用户一天也就调几次，但攻击者一秒就能打几百次；有些接口需要区分登录用户和匿名用户，匿名用户的频率限制应该更严格；还有些接口虽然访问量大，但请求体很小，和真正的CC攻击特征完全不同。通用规则一刀切，要么拦得太狠影响业务，要么拦得太松形同虚设。

所以自定义规则的价值就在于"精准"。你可以针对单个接口设定单独的频率阈值，可以根据请求头、请求参数、Cookie、User-Agent等多维度做匹配，甚至可以结合业务状态做动态调整。比如短信验证码接口，正常用户一天最多发5条，你就可以设定单IP单日不超过10次，超过直接拦截。

设计自定义CC防护规则，需要从三个层面入手：识别目标接口、定义攻击特征、设定处置动作。

第一步，识别目标接口。你要先梳理出哪些接口是CC攻击的重灾区。一般来说，这几类接口最容易被盯上：需要消耗服务器资源的查询接口（比如复杂SQL查询）、需要触发外部调用的接口（比如发短信、发邮件）、需要鉴权但鉴权成本低的接口（比如登录、注册）、以及返回数据量大的接口（比如导出、报表）。把这些接口的URL路径、请求方法（GET/POST）、参数结构全部列出来。

第二步，定义攻击特征。CC攻击的本质是高频、重复、自动化。具体特征包括：同一IP短时间内大量请求同一接口、请求间隔极其规律（比如精确到毫秒级）、User-Agent异常或为空、缺少正常浏览器的Cookie和Session、请求参数高度重复等。你需要把这些特征转化成WAF能理解的规则条件。

第三步，设定处置动作。最常见的是直接拦截（返回403或429），也可以设定为人机验证（返回验证码页面）、限速（降低响应频率）、或者记录日志但不拦截（用于观察期）。建议初期先用限速+记录的方式观察，确认规则不误伤正常用户后再切换为直接拦截。

不同的WAF产品配置方式有所不同，但逻辑是相通的。下面以常见的几种WAF为例，讲解具体怎么配。

如果你用的是基于Nginx的WAF（比如开源的ModSecurity或者商业版），自定义规则通常写在配置文件里。针对特定接口的CC防护，可以这样写：

# 针对 /api/sms/send 短信接口的CC防护
SecRule REQUEST_URI "@streq /api/sms/send" \
    "id:1001,\
    phase:1,\
    pass,\
    nolog,\
    chain"
    SecRule REQUEST_METHOD "@streq POST" \
        "t:none,\
        setvar:'ip.sms_count=+1',\
        expirevar:ip.sms_count=60"
    SecRule IP:SMS_COUNT "@gt 10" \
        "t:none,\
        deny,\
        status:429,\
        log,\
        msg:'CC attack detected on SMS API'"

这段规则的意思是：当有人POST请求 /api/sms/send 接口时，系统会在60秒内计数，如果同一个IP超过10次就返回429状态码并记录日志。你可以根据实际业务调整这个10次的阈值。

如果你用的是云WAF（比如国内主流云厂商提供的Web应用防火墙），通常在控制台里通过可视化界面配置。一般路径是：进入WAF控制台 → 找到你的域名 → 进入自定义规则或高级防护 → 新建规则 → 设置匹配条件（URL路径、请求方法等）→ 设置频率限制参数 → 设置处置动作。云WAF的好处是支持可视化拖拽和实时生效，不需要重启服务。

还有一种常见的做法是在WAF前面再加一层基于Redis的限流组件。这种方式更灵活，适合高并发场景。核心逻辑是用Redis的计数器做滑动窗口限流：

# 伪代码示例：基于Redis的接口限流逻辑
function checkRateLimit(ip, apiPath, maxRequests, windowSeconds) {
    key = "rate_limit:" + ip + ":" + apiPath
    current = redis.incr(key)
    if current == 1 {
        redis.expire(key, windowSeconds)
    }
    if current > maxRequests {
        return false  // 触发限流
    }
    return true  // 放行
}

// 针对查询接口的调用
if apiPath == "/api/user/search" {
    if !checkRateLimit(clientIP, apiPath, 30, 60) {
        return HTTP_429_TOO_MANY_REQUESTS
    }
}

这种方式的优势是可以针对每个接口单独设定不同的阈值，而且Redis本身性能极高，不会成为瓶颈。

案例一：登录接口防护。登录接口是CC攻击的首选目标，因为鉴权成本低、攻击者可以用字典批量撞库。防护方案：针对 /api/login 接口，设定单IP每分钟不超过5次，同时检测请求体中是否包含常见的暴力破解特征（比如username字段长度异常、password字段包含特殊字符组合）。另外，对连续失败超过5次的IP直接加入临时黑名单，封锁30分钟。

案例二：短信验证码接口防护。这个接口一旦被刷，企业要承担短信费用损失。防护方案：设定单IP单日不超过10次，单手机号单日不超过5次，同时增加图形验证码前置校验（在发短信之前先过验证码），这样即使攻击者绕过了频率限制，也会被验证码挡住。

案例三：数据查询接口防护。比如 /api/report/export 这种导出接口，一次请求可能要查询大量数据，非常消耗资源。防护方案：设定单IP每分钟不超过3次，同时检测请求是否携带有效的鉴权Token，没有Token的请求直接拒绝。另外可以对导出接口增加异步处理机制，先返回任务ID，后台慢慢生成，避免同步请求压垮服务器。

案例四：搜索接口防护。搜索接口通常是GET请求，容易被直接用脚本批量调用。防护方案：针对 /api/search 接口，设定单IP每秒不超过10次，同时检测查询关键词是否有明显的自动化特征（比如关键词长度极短、请求间隔完全一致、缺少Referer头）。可以配合前端增加请求签名机制，让每个请求携带一个带时间戳的签名，WAF验证签名有效性，过期或伪造的直接拦截。

规则配好了不代表万事大吉，调优才是长期工作。第一个技巧是分阶段上线。先把规则设为"观察模式"，只记录不拦截，跑一到两周，分析日志看看有没有误伤正常用户。比如你发现某个正常用户因为网络原因IP会频繁变化，导致被误拦，那就需要调整规则，改用Session或设备指纹来做标识，而不是单纯依赖IP。

第二个技巧是设置多级阈值。不要只设一个"超过就拦截"的硬阈值，而是设梯度：比如超过阈值的80%先限速，超过100%才拦截，超过150%直接拉黑。这样可以给突发的正常流量留缓冲，同时对真正的攻击快速响应。

第三个技巧是结合业务高峰期做动态调整。比如电商大促期间，正常访问量本身就很高，这时候如果还用平时的阈值就会大量误拦。可以设置定时任务或者通过API在高峰期自动放宽限制，活动结束后恢复正常。

第四个技巧是关注误报率。每周至少看一次WAF的拦截日志，统计误报比例。如果误报率超过5%，说明规则需要优化。常见的误报原因包括：CDN回源IP被当成攻击源、内网用户通过同一出口IP访问、爬虫被误判为CC攻击等。针对这些情况，可以设置白名单或者增加更精细的识别条件。

自定义规则不是孤立的，它需要和其他防护手段形成体系。在网络层，可以配合DDoS高防服务，先把大流量的DDoS攻击清洗掉，减轻WAF的压力。在应用层，可以在代码里增加业务级别的限流（比如用令牌桶算法），作为WAF的补充。在数据层，可以对频繁访问的接口增加缓存，减少数据库压力，即使被刷也不至于把数据库打垮。

另外，建议开启WAF的日志审计功能，把所有被拦截的请求详细记录下来，包括时间、IP、请求路径、请求参数、User-Agent等。这些数据不仅用于规则调优，还可以作为安全事件的溯源依据。如果发现某个IP持续攻击，可以把它加入永久黑名单，或者提交给安全团队做进一步分析。

很多人在配置自定义规则时容易犯几个错误。第一是规则太宽松，形同虚设。比如把阈值设得特别高，觉得"反正不会误伤"，结果攻击者稍微控制一下频率就能绕过。第二是规则太复杂，维护成本高。写了一大堆嵌套条件，结果自己都看不懂，出了问题没法快速排查。建议每条规则控制在3-5个条件以内，逻辑清晰，注释写清楚。

第三个误区是只关注IP维度。现在很多攻击者用代理IP池，单一IP的频率可能不高，但总量很大。这时候需要增加设备指纹、Session关联、行为分析等多维度识别，不能只盯着IP看。第四是忽略了API接口的防护。现在很多业务是前后端分离，API接口直接暴露在外面，比传统Web页面更容易被攻击，必须同等重视。

最后提醒一点，自定义规则不是配完就不管了。攻击手法在不断演变，规则也需要持续迭代。建议每月做一次规则审查，每季度做一次全面的防护策略评估，确保你的WAF始终能跟上最新的威胁。

CC防护WAF自定义规则防护特定接口，本质上就是把通用防护变成精准防护。核心步骤是：找出高风险接口、分析攻击特征、编写匹配规则、设定合理阈值、持续调优迭代。不管你用的是开源WAF还是云WAF，逻辑都是一样的。关键在于你对自己业务的理解有多深，规则设计就能有多精准。不要怕麻烦，前期多花时间打磨规则，后期就能少处理很多安全事故。把接口防护做扎实了，你的Web应用才能真正扛住高频攻击的考验。