Hey there, sorry to hear your site's getting hammered with brute force attacks—those botnet-driven login attempts are such a pain, especially with the database CPU spike they're causing. Let's walk through actionable fixes to lock this down and get things back to normal:

1. 渐进式账户锁定 #

• 实现渐进式账户锁定：比如连续3次登录失败后，锁定账户15分钟；如果失败次数涨到5次，锁定1小时；10次以上就锁6小时。这种阶梯式的限制既不会搞砸正常用户的登录体验，又能彻底挫败批量暴力尝试。
• 关键细节：锁定时不要明确提示「账户已锁定」，统一返回「用户名或密码错误」——别给攻击者机会枚举哪些账户是真实存在的。

2. 登录请求速率限制 #

• 在Web服务器或应用层加速率限制：比如每个IP地址1分钟内最多允许5次登录请求。Linux环境下可以用fail2ban自动拦截频繁发起请求的IP；如果是代码层面实现，用Redis记录每个IP的请求次数，超过阈值就临时拦截。
• 提前封禁已知的僵尸网络IP段，能从源头减少一部分恶意请求。

3. 隐藏账户存在性 #

• 不管输入的用户名是否在你的数据库里，登录失败时都返回完全一致的提示，比如「登录信息不正确」。绝对不要区分「用户名不存在」和「密码错误」，这能直接切断攻击者枚举有效账户的途径。

4. 强制多因素认证（MFA） #

• 给所有用户开启MFA，尤其是管理员等高权限账户。就算攻击者拿到了泄露的邮箱和密码，没有二次验证（比如短信验证码、Google Authenticator、硬件密钥）也没法登录。
• 可以先给活跃度高或权限高的用户强制开启，再逐步覆盖所有用户，降低推广阻力。

5. 优化数据库负载 #

• 既然数据库CPU飙升，先检查登录相关的SQL查询：比如查询用户名的字段一定要加索引，避免全表拖慢数据库。
• 把频繁查询的用户基础信息缓存到Redis或Memcached，减少直接打数据库的请求次数。

6. 实时监控与告警 #

• 搭个日志监控系统跟踪登录行为，比如用ELK Stack把登录日志可视化，设置告警规则——比如10分钟内某IP失败20次就触发邮件/短信告警。
• 定期导出异常IP列表，加到防火墙黑名单里，长期压制恶意请求。

额外小建议 #

• 提醒用户定期更换密码，别用已经在数据泄露事件中暴露过的密码（可以在登录时后台比对泄露密码库，但要注意用户隐私安全）。
• 赶紧改掉或禁用「admin」「root」这类默认高危用户名，很多攻击者会优先试这些。

内容的提问来源于stack exchange，提问作者victor.alm