mysql连接控制插件需手动安装启用,否则配置无效;默认绕过localhost等连接,阈值不持久化且按用户+主机独立计数,需结合防火墙与最小权限原则综合防护。

mysql连接控制插件没启用,登录失败次数不记账
插件不启用,connection_control 和 connection_control_failed_connections_threshold 这些配置就只是配置文件里的文字。MySQL 启动时不会自动加载它,必须手动安装并开启。
实操建议:
- 先连上 MySQL,执行
INSTALL PLUGIN connection_control SONAME 'connection_control.so';(Linux)或'connection_control.dll'(Windows) - 确认已加载:
SELECT PLUGIN_NAME, PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME = 'connection_control';,状态得是ACTIVE - 检查变量是否生效:
SHOW VARIABLES LIKE 'connection_control%';,特别注意connection_control_failed_connections_threshold默认是 3,太低容易误锁;建议调成 5–10 - 如果报错
Plugin 'connection_control' is disabled,说明 mysqld 启动时加了--plugin-load-add=connection_control=OFF或配置里写了disabled_storage_engines类似干扰项,得清理
设置了阈值但没触发延迟,可能是用户白名单在起作用
connection_control 插件默认把 localhost、127.0.0.1 以及所有 skip-grant-tables 模式下的连接都绕过控制——这很合理,但也常被忽略。
实操建议:
- 检查当前连接来源:
SELECT USER(), CURRENT_USER();,如果返回的是'root'@'localhost',那不管输错多少次都不会被限流 - 生产环境远程管理账号务必用具体 IP 或域名创建,比如
CREATE USER 'admin'@'192.168.10.50';,别依赖'root'@'localhost'做日常操作 - 插件对
super_priv用户不强制限流(MySQL 8.0.19+ 可通过connection_control_failed_connections_threshold配合connection_control_min_connection_delay控制,但 root 仍可能豁免),所以别让业务账号拥有SUPER权限
暴力破解没拦住,因为应用层重试太快,插件根本来不及响应
插件的限流逻辑是:连续失败达到阈值后,后续每次连接尝试都会被强制延迟(默认 1000ms)。但如果客户端用短连接 + 快速重试(比如 Python 的 mysql-connector 默认重试 1 次且间隔极短),看起来就像“没生效”。
实操建议:
- 调高基础延迟:
SET GLOBAL connection_control_min_connection_delay = 2000;(单位毫秒),避免被快速重试冲掉效果 - 确认应用是否启用了连接池;如果用了
maxReconnects=3这类参数,实际一次错误会引发多次底层连接尝试,得在中间件或负载均衡层也做频率限制 - 观察日志:
SELECT * FROM performance_schema.events_statements_summary_by_digest WHERE DIGEST_TEXT LIKE '%ERROR%';,配合错误日志里的Access denied for user行数,判断是真实攻击还是误配导致的高频失败
连接被锁死却查不到记录,因为 failed_connections 计数只存在内存中
connection_control_failed_connections_threshold 的计数不是持久化到磁盘的,重启 MySQL 就清零。而且它只针对单个用户+主机组合(如 'attacker'@'203.204.205.206'),不同 IP 即使同名用户也不共享计数。
实操建议:
- 不要指望靠查某张表来“看历史失败次数”,这个计数没有对应视图暴露;唯一可观测方式是开慢日志 + 错误日志,过滤
Access denied并按 host 分组统计 - 如果发现某个 IP 突然大量失败,优先在防火墙层封禁,比如
iptables -A INPUT -s 203.204.205.206 -j DROP,比依赖 MySQL 插件更及时 - 插件无法防御密码正确但权限不足的试探(比如知道账号、猜库名/表名),这类行为不会触发
Access denied for user,得靠审计日志(audit_log插件)或代理层识别
真正难防的不是连不上,而是连得上但权限太宽——插件只能卡住“错密码”,卡不住“对密码+错权限设计”。所以账号最小权限原则比任何连接控制都关键。










