首页 > > 网络编程 > Mysql >

mysql max_allowed_packet自动重置为1024 终结解…

2018-06-17 22:51:31来源：未知阅读 ()

背景：

测试环境1台centOS机器，最近一段频繁报“

Caused by: com.mysql.jdbc.PacketTooBigException: Packet for query is too large (1354 > 1024). You can change this value on the server by setting the max_allowed_packet' variable

”，记录解决问题的思路，最终找到问题根源：黑客入侵，总结经验。

思路：

查看max_allowed_packet ：

show global VARIABLES like '%max_allowed_packet%'; (注意：mysql 系统参数分为session和global 之分， session只当前连接生效，global 全局连接生效）

1）.通过mysql客户端，set global max_allowed_packet = 2*1024*1024*10; （修改后，重启数据库会恢复为默认）

2）. 修改my.cnf 在[mysqld]段或者mysql的server配置段进行修改。（终极修改, 修改后重启数据库，永久生效）

　　如下: max_allowed_packet = 20M

通过方法2修改完成后，通过客户端生效。但发现，过一段时间（有时几个小时，有时1~2天），自动变为1024。

思考：google 发现有说被黑客攻击，本来不相信，因为是内网环境。无奈出现情况，越来越频繁，刚更改后，过一会就变为1024。以下帖子给了启发：

http://stackoverflow.com/questions/28979660/why-mysql-max-allowed-packet-reset-to-1m-automatically

mysql 有general_log, 会记录所有执行的sql命令，因为耗费性能，默认是关闭。

mysql> show variables like '%log%';
+-----------------------------------------+---------------------------------+
| Variable_name                           | Value                           |
+-----------------------------------------+---------------------------------+
| back_log                                | 50                              |
| binlog_cache_size                       | 32768                           |
| binlog_direct_non_transactional_updates | OFF                             |
| binlog_format                           | STATEMENT                       |
| expire_logs_days                        | 0                               |
| general_log                             | OFF                             |
| general_log_file                        | /var/run/mysqld/mysqld.log      |

打开general_log:

mysql> set global general_log = ON;

查看general_log：

tail -f /var/run/mysqld/mysqld.log |grep max_allowed_packet （查看log，但打印大量实时sql操作）

tail -f /var/run/mysqld/mysqld.log |grep max_allowed_packet >1.txt （过滤max_allowed_packet，并输出到文件1.txt)

果然发现，有以下修改：

160804  8:59:41      172 Query    SET GLOBAL max_allowed_packet=1024
          172 Query    SET GLOBAL max_allowed_packet=1024
          173 Query    SET GLOBAL max_allowed_packet=1024
160804  8:59:49      173 Query    SET GLOBAL max_allowed_packet=1024

172 Query SET GLOBAL max_allowed_packet=1024

了解到general_log 日志中，172 为用户连接Id（mysql 会对每一个连接分配唯一id），在全量general log中过滤id为172的操作如下：

（很遗憾，由于机器被攻击，总监要求对机器进行系统还原，在写日志时，log被删除了），大概如下：

 connect root@someipaddress on
   Query select 0x4D5A900..........(verylong)
   Query select sys_exe('cmd /c  c:/windows/nbvqc4.vbs')
   .........
   set global max_allowed_packet 1024
   ........

从登陆ip 查询到时美国的一个IP，操作主要有：从某一网站，下载脚本，并执行；打开mysql相关安全参数，设置相关变量。

至此，非常确定mysql 数据库被黑客攻击了。

疑问：

1. mysql部署在内网，外网如何访问？

　　原来，之前便其它合作伙伴提供外网测试环境，让网管把外网IP，影射到了此机器。导致通过公网IP直接访问到了此台机器。

验证：

　　1）. 通过外网IP, 使用mysql客户端，可以直接连接到mysql服务。

　　 2). 通过外网IP, 使用xshell 登陆成功。

2. 黑客怎么知道了用户名/密码？

由于是测试机器，mysql使用了简单了密码（root/123456) , 被猜到，破解太容易了。

3. 防火墙呢？

由于开启防火墙，在系统测试时，出现各种麻烦。就关闭了。service iptables status;

[root@bo bryant]# service iptables status;
iptables: Firewall is not running.
[root@bo bryant]#

4. 黑客是怎么发现漏洞的，为什么入侵目的？

猜测大概流程：通过扫描软件扫描公网ip，测试到机器端口未关闭，如22，3306（应对1：开启防火墙，只开放服务端口，禁用其它端口外网访问），尝试暴力密码登陆（应对策略2：复杂密码策略，可建立白名单，对于多次连接失败，进行日志记录和预警）。通过日志发现了，黑客主要操作为：在mysql中调用了系统命令（下载远程文件，增加执行权限，并执行），打开相关安全参数。

查看机器登陆历史及登陆失败历史，发现近段时间，有大量外网登陆失败情况，如下图中oracle, svn ,apache 用户，黑客通过常用应用的用户名/密码在不停的尝试登陆系统：

producti ssh:notty    217.76.78.35     Mon Aug  1 10:49 - 10:49  (00:00)    
producti ssh:notty    217.76.78.35     Mon Aug  1 10:49 - 10:49  (00:00)    
swsoft   ssh:notty    217.76.78.35     Mon Aug  1 10:49 - 10:49  (00:00)    
swsoft   ssh:notty    217.76.78.35     Mon Aug  1 10:49 - 10:49  (00:00)    
iraf     ssh:notty    217.76.78.35     Mon Aug  1 10:49 - 10:49  (00:00)    
iraf     ssh:notty    217.76.78.35     Mon Aug  1 10:49 - 10:49  (00:00)    
svn      ssh:notty    217.76.78.35     Mon Aug  1 10:49 - 10:49  (00:00)    
svn      ssh:notty    217.76.78.35     Mon Aug  1 10:49 - 10:49  (00:00)    
oracle   ssh:notty    217.76.78.35     Mon Aug  1 10:49 - 10:49  (00:00)    
oracle   ssh:notty    217.76.78.35     Mon Aug  1 10:49 - 10:49  (00:00)    
root     ssh:notty    217.76.78.35     Mon Aug  1 10:49 - 10:49  (00:00)    
lab      ssh:notty    217.76.78.35     Mon Aug  1 10:48 - 10:48  (00:00)    
lab      ssh:notty    217.76.78.35     Mon Aug  1 10:48 - 10:48  (00:00)    
root     ssh:notty    217.76.78.35     Mon Aug  1 10:48 - 10:48  (00:00)    
root     ssh:notty    217.76.78.35     Mon Aug  1 10:48 - 10:48  (00:00)    
apache   ssh:notty    217.76.78.35     Mon Aug  1 10:48 - 10:48  (00:00)    
apache   ssh:notty    217.76.78.35     Mon Aug  1 10:48 - 10:48  (00:00)    
root     ssh:notty    217.76.78.35     Mon Aug  1 10:48 - 10:48  (00:00)    
root     ssh:notty    217.76.78.35     Mon Aug  1 10:48 - 10:48  (00:00)    
root     ssh:notty    217.76.78.35     Mon Aug  1 10:48 - 10:48  (00:00)