ANBOB™

谈起安全防护方面，数据库用户可能会遭遇暴力破解的风险，在oracle数据库中有profile配置如配置尝试次数据等，同时在11g起引入了密码延迟认证，增加密码失败后尝试的时长，也带来了新的问题如较高的libarary cache lock, 12c等有所增强，但oracle dba还是一般配置28401 event禁用该特性，详细的看我之前的blog,  在MySQL中同样应对不同密码的破解，根据密码库，暴力攻击包括攻击者尝试许多密码或密码短语，希望直到最终猜对，类似DDos攻击。MySQL中的解决方案可以安装connection_control插件库，在MySQL 8.0 中引入，并向后移植到 MySQL 5.7 和 MySQL 5.6，但同样它也带了新的问题。

connection_control插件库

Connection_control插件库允许管理员在连续指定次数的不成功登录尝试后，增加服务器对连接的响应延迟。该技术可以减缓针对 MySQL 用户帐户的暴力攻击。包含两个插件：
CONNECTION_CONTROL 检查传入的连接尝试，并根据需要向服务器响应添加延迟。 该插件还公开了可以配置其操作的系统变量以及提供基本监控信息的状态变量。
CONNECTION_CONTROL_FAILED_LOGIN_ATTEMPTS 实现一个 INFORMATION_SCHEMA 表，该表公开失败的连接尝试的更详细的监视信息。

配置

[mysqld]
plugin-load-add=connection_control.so
connection-control=FORCE_PLUS_PERMANENT
connection-control-failed-login-attempts=FORCE_PLUS_PERMANENT
connection_control_failed_connections_threshold=5
connection_control_max_connection_delay=2147483647
connection_control_min_connection_delay=1500

可以SET GLOBAL动态配置参数如

SET GLOBAL connection_control_failed_connections_threshold = 3;
SET GLOBAL connection_control_min_connection_delay = 1000;  
SET GLOBAL connection_control_min_connection_delay = 90000;

也可以永久配置参数如

SET PERSIST connection_control_failed_connections_threshold = 3;
SET PERSIST connection_control_min_connection_delay = 1000;

connection_control插件库后会发生什么？
我们在配置启用了connection_control插件库可以在上线前测试一下，使用shell

# for i in `seq 1 53`;   do time mysql-uroot -p"Incorrect_pwd" -d mysql
-h xxx.xx.x.x 2>&1 >/dev/null | grep meh ;   done
0.093
0.092
0.093
1.093
2.093
3.105
4.093
5.093
...

1， 从processlist可以看到失败的链接在等待 “Waiting in connection_control plugin.”状态
2， 从达到尝试connection_control_failed_connections_threshold次数后延迟时间逐渐增加，在之前不会遇到任何延迟
3， 从可以监控到当前尝试失败的次数 SELECT FAILED_ATTEMPTS FROM INFORMATION_SCHEMA.CONNECTION_CONTROL_FAILED_LOGIN_ATTEMPTS;
4， 如果已经产生了延迟认证，但是下一次正确的密码登录也会等待之前积累的延迟秒数据后，得到服务器的反馈，登录成功。
5, 查看认证在暴力登录可以从information_schema.connection_control_failed_login_attempts;
6， 如何重置当前登录失败的计数？重新配置一下该参数即可，如SET GLOBAL connection_control_failed_connections_threshold = 4;
7， 风险即使使用尝试错误的密码登录，没有成功，但是在等待数据库认证前，它也会占用数据库的max_connection最大连接数中的资源， 所以可能会导致数据库连接数耗尽，提示too many connections,
MYSQL中定义为Bug #89155 Connection-control exhausts all max_connection resources

对于国产数据库，像oceanbase for MySQL的参数同样和connection_control类似，支持密码失败延迟认证功能，不确认OB是否也存在同样的问题。毕竟oracle在密码延迟认证开始也是一个问题特性。

总结:
MySQL的connection_control插件库引入了密码延迟认证的功能，但是应用的连接在等待服务的反馈前，同样会占用数据库的连接数，有可能导致连接数耗尽。应尽快从监控表找到尝试登录的主机屏蔽，或临时connection_control_failed_connections_threshold=0禁用延迟，清理掉等待连接应急。

打赏

微信扫一扫，打赏作者吧～