MySQL如何配置以防止非法用户暴力破解数据库密码

FAILED_LOGIN_ATTEMPTS与PASSWORD_LOCK_TIME必须成对设置且依赖validate_password插件启用，仅对caching_sha2_password或mysql_native_password用户生效；单独设置无效，单位为天，锁定期满需成功登录才解锁。

FAILED_LOGIN_ATTEMPTS 和 PASSWORD_LOCK_TIME 必须成对设置

单独执行 ALTER USER 'u'@'%' FAILED_LOGIN_ATTEMPTS 3 不会触发任何锁定行为，MySQL 静默忽略。这两个参数是硬性绑定的：缺一不可，顺序无关，但少一个就完全失效。

• 新建用户时必须一次性写全：CREATE USER 'api'@'%' IDENTIFIED WITH caching_sha2_password BY 'pwd' FAILED_LOGIN_ATTEMPTS 3 PASSWORD_LOCK_TIME 0.04167（锁 1 小时）
• 已有用户修改需连认证插件一起换：ALTER USER 'api'@'%' IDENTIFIED WITH caching_sha2_password BY 'newpwd' FAILED_LOGIN_ATTEMPTS 3 PASSWORD_LOCK_TIME 0.04167
• PASSWORD_LOCK_TIME 单位是「天」：锁 5 分钟要写 0.00347（5 ÷ 1440），写 0 表示永久锁定，不是“不锁定”
• 锁定期满后不会自动解锁——必须有一次成功登录，才会重置失败计数并清除 account_locked = 'Y'

validate_password 插件不是可选，而是必需

即使参数写全、插件匹配，validate_password 没启用，失败登录也不会累加计数，mysql.user 里永远看不到 account_locked = 'Y'，错误日志里也搜不到 Too many failed login attempts。

• 检查是否激活：SELECT PLUGIN_NAME, PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME = 'validate_password'，状态必须是 ACTIVE
• 启用方式二选一：配置文件加 plugin_load_add = validate_password.so 后重启；或运行 INSTALL PLUGIN validate_password SONAME 'validate_password.so'
• 启用后会附带激活密码强度策略（如 validate_password.length），可能影响已有建用户脚本，需提前验证

connection_control 插件装两个组件才生效

只装 CONNECTION_CONTROL 是不够的，它负责延迟逻辑，但失败计数依赖配套组件 CONNECTION_CONTROL_FAILED_LOGIN_ATTEMPTS。没装后者，SHOW VARIABLES LIKE '%connection_control%' 看不到任何相关变量，所有配置都白配。

• 必须按顺序执行：INSTALL PLUGIN CONNECTION_CONTROL SONAME 'connection_control.so'，再执行 INSTALL PLUGIN CONNECTION_CONTROL_FAILED_LOGIN_ATTEMPTS SONAME 'connection_control.so'
• connection_control_failed_connections_threshold 参数不写进 my.cnf 就不持久——SET GLOBAL 设置后重启即失效
• 注意单位：connection_control_min_connection_delay 是毫秒，不是秒；max 值设太高（如 60000）可能卡死连接池，引发 Too many connections
• 'root'@'localhost' 和所有本地连接默认被绕过，这是设计行为，不是 bug

别信“%”通配符，IP 白名单才是第一道墙

只要 3306 端口对公网开放，且用户 Host 是 '%' ，暴力破解就始终存在真实风险。MySQL 自身的账户锁定只是最后一道防线，不是替代网络隔离的方案。

• 禁用远程 root：DELETE FROM mysql.user WHERE user='root' AND host!='localhost'，然后 FLUSH PRIVILEGES
• 业务账号必须绑定具体 IP 或内网段：CREATE USER 'webapp'@'192.168.10.50' IDENTIFIED BY 'strong_pwd'
• 云环境务必在安全组层面只放行应用服务器内网 IP；物理机用 iptables 或 ufw 严格限制源地址
• bind-address 绝不能设为 0.0.0.0，优先设为 127.0.0.1 或内网地址

真正起作用的从来不是单点配置，而是 caching_sha2_password + validate_password + FAILED_LOGIN_ATTEMPTS/PASSWORD_LOCK_TIME 三者同时在线，再加上 CONNECTION_CONTROL_FAILED_LOGIN_ATTEMPTS 的延迟压制和防火墙层的 IP 白名单——少任何一个环节，攻击者都可能找到绕过路径。