摘要：# 网站被“刷”到卡死？手把手教你用WAF把恶意请求拦在门外 上周有个做电商的朋友半夜给我打电话，声音都变了：“老王，我们网站突然卡得不行，后台全是登录失败的提示，但客服根本没收到那么多咨询！” 我一听就明白了——又是个典型的CC攻击（Challeng…

网站被“刷”到卡死？手把手教你用WAF把恶意请求拦在门外

上周有个做电商的朋友半夜给我打电话，声音都变了：“老王，我们网站突然卡得不行，后台全是登录失败的提示，但客服根本没收到那么多咨询！”

我一听就明白了——又是个典型的CC攻击（Challenge Collapse）。这玩意儿不像DDoS那样搞流量轰炸，它专挑你网站最费资源的环节下手，比如登录接口、搜索功能、下单页面，用一堆假用户慢慢“磨”你的服务器。最气人的是，攻击流量看起来跟正常访问没太大区别，很多基础防火墙直接就放过去了。

我自己帮客户处理过不下几十次这类情况，发现一个挺普遍的现象：很多公司其实买了WAF（Web应用防火墙），但配置得跟没配差不多。规则要么太松，形同虚设；要么太紧，把真实用户也给误杀了。今天咱就不聊那些空泛的理论，直接上干货，说说怎么用WAF实实在在地把恶意请求给摁住。

先搞明白，CC攻击到底在“攻击”什么？

说白了，CC攻击的核心就俩字：消耗。

攻击者手里控制着一大堆“肉鸡”（被操控的电脑或服务器），或者干脆租用廉价的代理IP池。他们不用研究什么复杂漏洞，就模仿正常用户的行为，反复访问你网站上那些特别“吃”CPU和数据库资源的动态页面。

比如：

• 疯狂刷新你的商品详情页（尤其是带复杂查询和库存校验的）
• 持续用不同账号尝试登录，触发你的密码错误锁定逻辑
• 高频搜索一些不存在的关键词，让你的数据库索引原地爆炸
• 不断往购物车里添加商品，但不结算，拖慢你的会话处理

关键点来了：这些请求，单看任何一个，似乎都合法。你的服务器还得老老实实去数据库查询、生成页面、返回结果。可当成千上万个这样的请求同时涌过来，服务器的CPU和数据库连接池很快就被占满了，真正的用户自然就卡在外面了。

很多低配的云主机或虚拟主机，可能几百个这样的并发请求就扛不住了——攻击成本低得吓人。

WAF不是“开关”，你得会调

很多人觉得，买了WAF服务，开个“CC防护”按钮就万事大吉了。这想法真挺危险的。我见过不少案例，默认规则一开，自家搞促销的活动页面也被当成攻击给封了，市场部同事差点找运维拼命。

WAF更像一个智能过滤器，你得告诉它：什么样的是坏人？抓到了怎么办？

第一步：先给自家网站“画个像”

在制定任何规则之前，你得先搞清楚自己网站的正常访问长啥样。这步不能省。

1. 看日志：找个业务平稳期（比如凌晨），导出访问日志看看。正常用户访问首页、商品页的频率大概是多少？一个IP一分钟访问几十次页面，算正常吗？（对于内容站，可能正常；对于企业官网，就极不正常了）
2. 找特征：你网站的登录、搜索、提交订单的URL路径是什么？它们的正常参数格式是怎样的？（比如，搜索关键词通常多长？订单ID是什么格式？）
3. 定基线：基于历史数据，给关键页面设定一个合理的访问频率基线。这是后续所有规则的基础。

第二步：制定“抓坏人”的核心规则（实战配置思路）

这里我分享几个经过验证、效果立竿见影的规则配置思路。注意，具体阈值需要根据第一步的“画像”来调整。

规则1：针对高频访问单一页面的“点射”

• 场景：攻击者往往盯着一个消耗大的页面（如 /product/detail?id=xxx）猛刷。
• WAF规则可以这么设：
  • 检测窗口：60秒
  • 触发条件：同一IP（或同一会话）对同一URL路径（可忽略参数）请求超过30次
  • 处置动作：将该IP放入黑名单，拦截5-10分钟
• 说人话：一个正常用户，一分钟内看30次同一个商品详情页？除非他在疯狂比价或者页面有bug自动刷新，否则大概率是脚本。先关它一会儿“禁闭”。

规则2：揪出“广撒网”的搜索攻击

• 场景：用脚本随机生成关键词，疯狂调用你的站内搜索（/search?q=乱七八糟的关键词）。
• WAF规则可以这么设：
  • 检测窗口：120秒
  • 触发条件：同一IP发起超过50次搜索请求，且这些请求中，关键词的平均长度异常（比如极短或无意义字符组合），或命中率极低（搜索结果为0的比例超高）
  • 处置动作：验证码挑战，通过则放行，失败则拦截
• 说人话：正常人搜索是有目的、有逻辑的。如果某个IP在短时间内用一堆乱码或短词搜个不停，还啥都搜不到，不是攻击就是爬虫。让它输个验证码自证清白。

规则3：给登录接口加上“金钟罩”

• 场景：攻击者用常见用户名列表，不断尝试撞库爆破。
• WAF规则可以这么设（多层防御）：
  1. 频率限制：同一IP，1分钟内对 /login 的POST请求超过10次，触发验证码。
  2. 账号保护：同一用户名（从请求体中提取），1小时内尝试登录失败超过5次，临时锁定该账号的登录请求30分钟（注意，是锁定来自任何IP的该账号登录尝试，防止攻击者换IP继续撞）。
  3. IP行为分析：如果一个IP在短时间内，用超过10个不同的用户名尝试登录，且成功率极低，直接封禁该IP24小时。
• 说人话：登录是重地，防守必须严。既要防单个IP猛攻，也要防用一堆账号试探。规则要套着用。

规则4：识别“慢速”但持续的消耗攻击

• 场景：高级点的攻击会故意放慢请求频率，比如每秒1-2次，但长时间不间断，专门绕过基于短时高并发的检测规则。
• WAF规则可以这么设：
  • 检测窗口：延长到10分钟甚至30分钟
  • 触发条件：同一IP在长时间窗口内，对网站动态页面的总请求数超过一个很高的阈值（比如10分钟内请求1000次），且请求间隔异常均匀
  • 处置动作：限速（将该IP的访问频率限制到正常水平）或二次验证
• 说人话：这种攻击像“文火慢炖”，更隐蔽。需要把观察时间拉长，看它的总“工作量”是不是大得不像个真人。

第三步：必做的“安全动作”与高级技巧

光有规则还不够，这些操作能让你事半功倍：

1. 开启日志并定期分析：WAF的拦截日志是宝藏。每周花点时间看看，你不仅能发现攻击，还可能找到自己规则的误杀情况（把正常用户拦了），及时优化。
2. 设置告警：别等业务挂了才知道。在WAF里设置告警，当拦截的CC攻击IP数或请求数在短时间内飙升时，立即通过短信、钉钉、微信通知你。
3. 善用“人机验证”：对于可疑但又不能一棍子打死的请求，验证码（尤其是滑动拼图、点选等对用户体验影响较小的）是神器。能拦住99%的简易攻击脚本。
4. 源站隐藏是终极后手：如果你的服务器IP暴露了，攻击者可能绕过WAF直接打源站。务必确保WAF是回源代理模式，并且源站服务器只接受来自WAF节点的流量（通过防火墙白名单实现）。这样，攻击者根本找不到你服务器的真实门牌号。
5. 别迷信“无限防护”：有些WAF产品宣传“无限防护CC”，但仔细看条款，可能对拦截动作次数有限制。搞清楚你的套餐上限，别真被打时才发现规则触发多了要额外付费。

几个你可能踩的坑，我直接说了

• 阈值设得太死：搞活动时，真实用户访问量会暴增。别把规则阈值设得刚好卡在平时流量上限，要留出至少2-3倍的余量，或者针对活动页面单独设置宽松策略。
• 忽略API和移动端：现在很多业务逻辑在APP里，攻击也可能针对API接口（/api/v1/...）。你的WAF规则必须覆盖这些接口路径，并且要考虑移动端网络特性（比如请求可能来自少数几个运营商的网关IP）。
• “配完即忘”：攻击手法在进化。今天流行打登录，明天可能就打评论提交了。定期（比如每季度）根据最新的攻击日志，复审和调整你的WAF规则，非常必要。

说到底，CC防御没有一劳永逸的“银弹”。它是一场攻防成本的博弈。你的目标不是挡住世界上所有的攻击（那不可能），而是把攻击者的成本抬得足够高，高到他觉得攻击你不再划算。

通过精细化的WAF配置，你完全可以把那些用现成工具、低成本代理IP的“脚本小子”们挡在门外。而对于更高级的、定制化的攻击，你也有了清晰的日志和响应流程，能快速定位、升级防护方案。

最后说句大实话：安全措施，平时觉得是成本，出事时才知是投资。 花点时间把WAF规则调好，可能比事后焦头烂额、业务停摆的损失，要小得多。

行了，思路和实战方法都在这了，赶紧去看看你的WAF控制台吧。如果配置时拿不准，记住一个原则：宁严勿松，但一定要开观察模式或验证码先行，避免误伤真实用户。