摘要：# 当CC攻击冲过来时，ModSecurity能顶住吗？我的实战笔记 说实话，我第一次听说用ModSecurity（WAF模块）防CC攻击的时候，心里是打鼓的。毕竟这玩意儿在大家印象里就是个“规则检查员”，擅长拦SQL注入、XSS这些“技术活”。CC攻击…

当CC攻击冲过来时，ModSecurity能顶住吗？我的实战笔记

说实话，我第一次听说用ModSecurity（WAF模块）防CC攻击的时候，心里是打鼓的。毕竟这玩意儿在大家印象里就是个“规则检查员”，擅长拦SQL注入、XSS这些“技术活”。CC攻击？那可是实打实的海量请求，靠几条规则能行？

但现实就是这么打脸。我亲眼见过一个客户，上了昂贵的高防IP，结果因为CC攻击的请求“看起来太正常”，高防策略没触发，源站的CPU直接被打满。反倒是后来在源站Nginx前头挂了个配置了针对性规则的ModSecurity，把异常请求的特征给卡住了。

说白了，很多防护方案不是没用，而是用错了地方。 防CC，有时候真不是堆硬件就能解决的。

一、 先泼盆冷水：ModSecurity防CC，不是万能钥匙

别急着去翻配置文档，咱们先把预期拉回地面。

ModSecurity本身是个应用层防火墙，它的核心能力是解析和分析单个HTTP/HTTPS请求，然后根据规则（CRS规则集或自定义规则）决定是放行、拦截还是记录。它不擅长什么？

• 不擅长处理超大流量洪水。 如果攻击者用几十Gbps的流量直接冲你端口，ModSecurity所在的服务器自己就先网络拥堵或者资源耗尽了。这种得靠上游的流量清洗或者高防IP/高防CDN来抗。
• 不擅长判断“低频高质”的CC攻击。 如果攻击者把请求频率压得很低，低到和正常用户一样，但每个请求都去触发你最消耗数据库资源的搜索功能，ModSecurity单看请求本身也很难区分。

那它擅长什么？ 擅长抓“行为异常”和“请求特征”。

CC攻击（Challenge Collapsar，挑战黑洞）的本质，是模拟大量正常用户，集中访问消耗资源大的页面（比如搜索、登录、验证码刷新、API接口），耗尽服务器资源。攻击者的请求虽然“正常”，但为了追求效率，往往在工具、IP、User-Agent、请求频率、访问路径上露出马脚。

ModSecurity的战场就在这里：在流量到达你的应用（比如WordPress、某个API）之前，把那些“假装正常”的请求给筛出来。

二、 实战开始：三条核心规则思路（附代码）

别被复杂的规则语法吓到，防CC的核心逻辑就三点，我用人话给你翻译一下：

思路1：盯死“请求频率”——这是最直接的一招

攻击者再模拟真人，短时间内从同一个源（IP、Session）发出的请求数，通常也远高于真人。比如，真人一分钟内刷新首页10次顶天了，但攻击脚本可能一秒就发10次请求。

怎么用ModSecurity实现？

ModSecurity有个叫 modsecurity-crs 的官方规则集，里面就包含了防CC的规则。但默认的可能不够狠，我们可以自己调或者加规则。

举个例子，我们想限制对 /wp-login.php（WordPress登录页）的访问频率：

# 1. 创建一个计数器，键名包含IP和请求URI，60秒窗口
SecAction "id:1000, phase:1, nolog, pass, initcol:ip=%{REMOTE_ADDR}, setvar:ip.uri_counter=0"

# 2. 在请求处理阶段（phase:2），针对登录页进行计数和检查
SecRule REQUEST_URI "@streq /wp-login.php" \
    "id:1001, phase:2, pass, nolog, setvar:ip.uri_counter=+1"

# 3. 检查在60秒内，访问次数是否超过5次
SecRule ip:uri_counter "@gt 5" \
    "id:1002, phase:2, deny, status:429, \
    msg:'CC攻击嫌疑：短时间内对登录页请求过于频繁', \
    tag:'attack-ddos'"

大白话解释：

1. 给每个IP建个小本本（initcol），记录它访问特定URL的次数。
2. 只要它访问登录页，就给它记一笔（setvar:...=+1）。
3. 60秒内（规则默认窗口，可调）如果记了超过5笔，立马拦截（deny），返回429（Too Many Requests）状态码。

关键点：

• 阈值（5次）和时间窗口（60秒）要自己调。 调太低误伤正常用户，调太高没效果。最好先开 nolog, pass 模式跑几天，看看日志里正常用户的频率是多少。
• 别只针对一个URI。 把消耗资源的动态页面（如 /search, /api/v1/order）都加上。

思路2：识别“坏蛋工具”的指纹

很多CC攻击工具（比如著名的“狂人”系列、一些压力测试工具改的）为了省事，其HTTP请求头会带有明显的特征。比如 User-Agent 字段是固定的、奇怪的字符串，或者缺少一些正常浏览器必带的头（如 Accept-Language）。

# 拦截一些已知攻击工具的User-Agent
SecRule REQUEST_HEADERS:User-Agent "@pmFromFile cc-attack-tools-user-agents.txt" \
    "id:1100, phase:1, deny, status:403, \
    msg:'已知CC攻击工具流量', \
    tag:'attack-ddos'"

# 检查是否缺少常见的浏览器头部（可能为简单脚本）
SecRule &REQUEST_HEADERS:Accept "@eq 0" \
    "id:1101, phase:1, deny, status:403, \
    msg:'请求缺少Accept头部，疑似非浏览器流量', \
    tag:'attack-ddos'"

你需要自己维护一个 cc-attack-tools-user-agents.txt 文件，把网上搜集的、或者从自己日志里分析出的攻击工具UA放进去。这个规则属于“精准打击”，一打一个准。

思路3：给“异常会话”贴标签——高级玩法

真正的用户访问网站，行为是有逻辑的：先看首页，再点进文章，可能再评论。CC攻击脚本往往直奔主题，只反复刷一个耗资源的接口，会话（Session）行为极其单一。

ModSecurity可以通过链式规则（chain）来标记这种异常会话。

# 假设我们定义，一个会话在短时间内，超过80%的请求都指向同一个API端点，就是异常
SecRule REQUEST_URI "@beginsWith /api/" \
    "id:1200, phase:2, pass, nolog, \
    setvar:session.api_hit=+1, setvar:session.total_hit=+1"

SecRule REQUEST_URI "!@beginsWith /api/" \
    "id:1201, phase:2, pass, nolog, setvar:session.total_hit=+1"

# 链式规则：计算API请求占比，如果总请求>10且占比>80%，则标记为攻击者
SecRule session:total_hit "@gt 10" \
    "chain, id:1202, phase:2, deny, status:429, \
    msg:'会话行为异常：API请求占比过高'"
    SecRule session:api_hit "@div session:total_hit" "@gt 0.8"

这个规则稍微复杂点，但效果很好，能抓住那些“行为模式化”的机器人。

三、 避坑指南：别把自己拦在外面

这是我踩过最大的坑，也是新手最容易翻车的地方。

1. 先观察，后动刀。 把所有规则的动作用 pass, log 跑至少24小时，去日志里分析，看看你的规则会抓到多少请求，其中有多少可能是正常的。千万别一上来就 deny。
2. 给管理后台、爬虫、API合作伙伴加白名单。 用 SecRule 的 ctl:ruleRemoveById 或者 ctl:ruleRemoveByTag 指令，将特定的IP段或请求头排除在CC规则之外。不然你可能会发现后台登不上了，或者搜索引擎不收录你了。
3. 429状态码是你的朋友。 对于频率超限的，优先返回 429（太多请求）而不是 403（禁止）。这更符合HTTP标准，对搜索引擎也友好些。可以在返回时加个 Retry-After 头，告诉对方多久后再试。
4. 规则性能。 复杂的链式规则和大量计数器会对性能有影响。如果请求量巨大，要监控服务器负载。规则不是越多越好，是越准越好。

四、 所以，到底该怎么用？我的组合拳建议

把ModSecurity当成你源站服务器的最后一道贴身保镖。

1. 第一道防线（网络层）： 买（或租用）带DDoS/CC防护的高防IP或高防CDN。让它们去抗大流量洪水，做初步的IP信誉清洗和频率限制。这是必须的，别指望ModSecurity单扛。
2. 第二道防线（应用层前置）： 在高防之后，如果你的架构里有网关（比如Kong, APISIX）或负载均衡器（Nginx/OpenResty），可以在这一层做全局性的、基于IP或地域的频率限制。这比在ModSecurity里做更高效。
3. 第三道防线（应用层贴身）： 这就是ModSecurity的舞台了。 部署在你的Web服务器（Apache/Nginx）上，针对具体的应用路径、会话行为、攻击工具指纹进行精细化的、智能化的拦截。它能看到网关看不到的应用细节。

最后说句大实话： 没有一劳永逸的防护。攻击者在进化，你的规则也得定期维护。今天有效的规则，下个月可能就被绕过了。定期看日志，分析异常请求，更新你的“坏蛋名单”，才是长治久安的办法。

行了，规则和思路都给你了。具体配置时遇到问题，别怕，多查查ModSecurity的官方文档，那才是终极武器。去试试吧，记得——先开观察模式！