数据库内核月报－ 2020/05 - MySQL · 插件分析 · Connection Control - 《数据库内核月报》

插件介绍
基本使用
- 插件的安装与卸载
- 插件参数
基本原理
实现分析
小结

本文基于mysql 8.0.13.

插件介绍

MySQL 5.6.35 开始提供Connnection Control 插件；

如果客户端在连续失败登陆一定次数后，那么此插件可以给客户端后续登陆行为的响应增加一个延迟。该插件可以防止恶意暴力破解MySQL账户。该插件包含以下2个组件：


1. - CONNECTION_CONTROL：检查mysql的刚建立连接的响应是否需要延迟，并且提供一些系统变量和状态参数；方便用户配置插件和查看此插件基本的状态。
2. - CONNECTION_CONTROL_FAILED_LOGIN_ATTEMPTS：提供了一个INFORMATION_SCHEMA类型的表，用户在此表中可以查看更详细关于登陆失败连接的信息。

基本使用

插件的安装与卸载

安装可以通过配置文件静态安装，也可以在MySQL中动态安装。

静态安装


1. -- 配置文件增加以下配置
2. [mysqld]
3. plugin-load-add                                 = connection_control.so

动态安装


1. -- 插件动态安装启用
2. mysql> INSTALL PLUGIN CONNECTION_CONTROL SONAME 'connection_control.so';
3. mysql> INSTALL PLUGIN CONNECTION_CONTROL_FAILED_LOGIN_ATTEMPTS SONAME 'connection_control.so';

5. -- 验证是否正常安装
6. mysql> SHOW PLUGINS;

卸载


1. -- 插件卸载
2. UNINSTALL PLUGIN CONNECTION_CONTROL;
3. UNINSTALL PLUGIN CONNECTION_CONTROL_FAILED_LOGIN_ATTEMPTS;

更多关于插接件安装/卸载的信息请点击

插件参数

connection_control_failed_connections_threshold：失败登陆次数达到此值后触发延迟。
值域：[0, INT_MAX32(2147483647)]，0表示关闭此功能。
默认值：3
connection_control_max_connection_delay：登陆发生延迟时，延迟的最大时间；此值必须大于等于connection_control_min_connection_delay。
值域：[1, INT_MAX32(2147483647)]
默认值：INT_MAX32
单位：毫秒
connection_control_min_connection_delay：登陆发生延迟时，延迟的最小时间，此值必须小于等于connection_control_max_connection_delay。
值域：[1000, INT_MAX32(2147483647)]
默认值：1000
单位：毫秒

基本原理

Connection Control 插件通过订阅MYSQL_AUDIT_CONNECTION_CLASSMASK 来处理 MYSQL_AUDIT_CONNECTION_CONNECT(完成认证后触发)和MYSQL_AUDIT_CONNECTION_CHANGE_USER(完成COM_CHANGE_USER RPC后触发)子事件；通过这两种子事件的处理来检查给客户端发送回包时是否需要延迟。
Connection Control 插件通过 LF hash来存储不同账户的失败登陆信息。LF hash中的key为user@host **，这里的user与host**将遵循以下条件：
如果在MySQL的security context有proxy user信息，那么这个信息将用于user与host；
否则，查看security context是否有priv_user 和 priv_host信息，如果有则用于user与host；
否则，将security context中已经连接的user 和 host信息用于user与host。
LF hash的更新：对于每次失败的登陆通过user@host **的key值对其value加1；对于每次成功的登陆，如果需要延迟，处理完延迟后将user@host **从LF hash中删除。
为什么在达到connection_control_failed_connections_threshold失败登陆次数后的第一次成功登陆需要延迟？
这其实还是出于对攻击者开销的考虑；如果成功登陆后马上返回，不需要延迟，那么攻击者就可以使用更少的连接数，进一步攻击者所消耗的资源就会更少；为了增加攻击者的开销，在连续失败登陆后的第一次成功登陆，还是会产生延迟。
具体延迟的时间如何计算？
一旦连续的失败登陆次数超过设定阈值，那么就会产生延迟，并且延迟随着失败次数增加而增加，上限为connection_control_max_connection_delay；具体的计算方式如下：
MIN ( MAX((failed_attempts - threshold), MIN_DELAY), MAX_DELAY)

实现分析

从上一小节的基本原理我们知道Connection Control插件主要是通过订阅处理MYSQL_AUDIT_CONNECTION_CONNECT与MYSQL_AUDIT_CONNECTION_CHANGE_USER事件来实现的。

主要处理流程如下：


1. //创建一个新线程，处理新连接
2. handle_connection() in connection_handler_per_thread.cc
3. |
4. | //准备工作
5. ->thd_prepare_connection() in sql_connect.cc
6. |
7. | //进行登陆操作
8. ->login_connection() in sql_connect.cc
9. |
10. | //对此连接的有效性进行验证
11. ->check_connection() in sql_connect.cc
12. |
13. | //验证登陆
14. ->acl_authenticate() in sql_authentication.cc
15. |
16. | //对登陆连接事件进行处理
17. ->mysql_audit_notify() in sql_audit.cc
18. |
19. | //对登陆连接事件进行处理，并获得错误码
20. ->mysql_audit_notify() in sql_audit.cc
21. |
22. | //获取需要处理登陆事件的插件
23. ->mysql_audit_acquire_plugins() in sql_audit.cc
24. |
25. | //将连接事件分发，并按照需求是都获取插件处理的返回值
26. ->event_class_dispatch_error() in sql_audit.cc
27. |
28. | //将连接事件分发
29. ->event_class_dispatch() in sql_audit.cc
30. |
31. | // 调用插件的相关处理函数处理连接事件
32. ->plugins_dispatch() in sql_audit.cc
33. |
34. | //检查当前插件是否需要处理此事件
35. ->check_audit_mask（）in sql_audit.cc
36. |
37. | //connection_control处理连接事件
38. ->connection_control_notify() in connection_control.cc
39. |
40. | //依次遍历订阅了连接事件的订阅者处理此事件
41. ->notify_event() in connection_control_coordinator.cc
42. |
43. | //处理连接事件
44. ->notify_event() in connection_delay.cc

下面我们主要看一下最终Connection Control插件是怎么处理连接事件的。


2. /**
3. @brief  Handle a connection event and if requried,
4. wait for random amount of time before returning.
5. We only care about CONNECT and CHANGE_USER sub events.
6. @param [in] thd                THD pointer
7. @param [in] coordinator        Connection_event_coordinator
8. @param [in] connection_event   Connection event to be handled
9. @param [in] error_handler      Error handler object
10. @returns status of connection event handling
11. @retval false  Successfully handled an event.
12. @retval true   Something went wrong.
13. error_buffer may contain details.
14. */

16. bool Connection_delay_action::notify_event(
17. MYSQL_THD thd, Connection_event_coordinator_services *coordinator,
18. const mysql_event_connection *connection_event,
19. Error_handler *error_handler) {

21. ...

23. // 只关注CONNECT与CHANGE_USER事件
24. if (subclass != MYSQL_AUDIT_CONNECTION_CONNECT &&
25. subclass != MYSQL_AUDIT_CONNECTION_CHANGE_USER)
26. DBUG_RETURN(error);

28. RD_lock rd_lock(m_lock);

30. int64 threshold = this->get_threshold();

32. // 拿到当前阈值检查阈值是否有效，DISABLE_THRESHOLD=0
33. if (threshold <= DISABLE_THRESHOLD) DBUG_RETURN(error);

35. int64 current_count = 0;
36. bool user_present = false;
37. Sql_string userhost;

39. make_hash_key(thd, userhost);

41. DBUG_PRINT("info", ("Connection control : Connection event lookup for: %s",
42. userhost.c_str()));

44. // 获取到当前失败登陆的次数
45. user_present = m_userhost_hash.match_entry(userhost, (void *)&current_count)
46. ? false
47. : true;

49. // 如果失败次数超过阈值，无论这次连接成功与否，都需要延迟
50. // 同时更新统计信息
51. if (current_count >= threshold || current_count < 0) {

53. ulonglong wait_time = get_wait_time((current_count + 1) - threshold);

55. if ((error = coordinator->notify_status_var(
56. &self, STAT_CONNECTION_DELAY_TRIGGERED, ACTION_INC))) {
57. error_handler->handle_error(
58. ER_CONN_CONTROL_STAT_CONN_DELAY_TRIGGERED_UPDATE_FAILED);
59. }

61. // 在产生延迟时，需要释放读写锁，以减少锁的粒度
62. // 防止阻塞对于IS table的数据访问
63. rd_lock.unlock();
64. conditional_wait(thd, wait_time);
65. rd_lock.lock();
66. }

68. if (connection_event->status) {

70. // 如果此次登陆失败，那么更新LF Hash
71. if (m_userhost_hash.create_or_update_entry(userhost)) {
72. error_handler->handle_error(
73. ER_CONN_CONTROL_FAILED_TO_UPDATE_CONN_DELAY_HASH, userhost.c_str());
74. error = true;
75. }
76. } else {

78. // 如果此次登陆成功并且LF Hash中有数据，那么就删除LF Hash中的数据
79. if (user_present) {
80. (void)m_userhost_hash.remove_entry(userhost);
81. }
82. }

84. DBUG_RETURN(error);
85. }

小结

1，通过分析Connection Control处理流程与具体实现，我们可以知道插件是如何来处理连接事件的。

2，该插件虽然可以防止恶意暴力破解MySQL账户，但是可能会浪费MySQL的资源；


1. - 比如如果短时间内有大量的恶意攻击，该插件虽然可以防止破解mysql账户，但是会消耗主机资源(每一个连接创建一个线程)；
2. - 如果这里使用了线程池，虽然可以避免消耗主机资源，但是等线程池中的线程被消耗光，再有新连接来就会拒绝服务。

原文：http://mysql.taobao.org/monthly/2020/05/08/