昨天凌晨收到告警，登录接口每秒被刷了上千次。这场景太熟悉了——典型的CC攻击。搞安全的兄弟们都懂，这种针对登录页的洪水攻击，光靠改密码策略根本挡不住。今天直接上干货，分享三组实战验证过的规则配置，专治各种不服。

第一招：掐死高频请求的脖子

别整那些花里胡哨的，先把请求频率打下来。Nginx的limitreqzone模块是首选武器。重点不是限制单个IP，而是识别攻击特征：短时间内对同一URI的重复轰炸。

/tab配置核心参数： limitreqzone $binaryremoteaddr zone=authlimit:10m rate=30r/m; location /login { /tab limitreq zone=authlimit burst=5 nodelay; }

关键在这几个数： 1. rate=30r/m 表示每分钟只允许30次请求，折算下来2秒1次，正常登录完全够用 2. burst=5 给突发流量留点余地，避免误伤 3. nodelay 直接拒绝超额请求，不给攻击者排队机会 实测下来，这套规则能干掉90%的脚本爆破，CPU立马从100%降到20%以下。

第二招：给可疑流量贴标签

单纯限频可能误伤，得加上行为分析。Fail2ban的多维度过滤机制这时候就派上用场了。配置重点看这三个指标：

/tab过滤规则示例（/etc/fail2ban/jail.local）： [nginx-cc] enabled = true filter = nginx-cc-action maxretry = 10 findtime = 120 bantime = 3600 action = iptables-multiport[name=cc,port="http,https"]

解释几个硬核参数： - maxretry=10：120秒内10次失败请求直接拉黑 - findtime=120：统计时间窗口设为2分钟 - bantime=3600：封禁1小时起步 更狠的玩法是联动Redis实时黑名单，把封禁IP推送到所有边缘节点。

第三招：人机验证精准拦截

遇到高级攻击时，前两招可能被绕过。这时候验证码策略必须上场。但别傻乎乎全程验证，那体验太差。重点保护登录前的凭证校验环节：

/tab推荐配置策略： 1. 首次请求：直接放行 2. 同IP第3次请求：触发滑动验证 3. 第5次请求：启用算式验证码 4. 持续异常：强制点击验证

在Nginx用luarestywaf实现最顺手： accessbyluablock { /tab local counters = ngx.shared.ipcounters /tab local key = ngx.var.binaryremoteaddr /tab local reqcount = counters:incr(key, 1, 0, 60) /tab if reqcount > 5 then /tab /tab ngx.exec("/captcha") /tab end }

注意别踩坑： - 验证码服务必须独立部署，避免被攻击连带拖垮 - 拒绝使用前端生成的验证码，那等于没装锁

实战组合拳怎么打

这三组规则要分层部署才有效： 1. 前端用Nginx限频扛住大部分流量 2. 中间层Fail2ban动态封禁可疑IP 3. 应用层验证码拦截穿透防御的请求 重点在于规则联动：当某IP触发验证码时，自动将其QPS阈值降低50%。

最后提醒几个关键点： - 千万别依赖IP黑名单，现在攻击都用秒换IP的代理池 - 登录错误提示必须统一返回“用户名或密码错误” - 定期检查limitreq的zone内存使用量，10m约支持8万IP - 测试时用ab -c 100 -n 10000模拟攻击，观察拦截效果

这些规则在我们生产环境跑了两年，每天拦下几十万次恶意请求。碰到暴力破解别慌，按这个流程走一遍，半小时内就能把攻击流量压下去。有具体场景卡住了随时交流，搞安全的就是要实战见真章。