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

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

新老客户大回馈,云服务器低至5折

 

  • 背景:

测试环境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)    

 

5. 黑客为什么要修改 max_allowed_packet 1024 ?

修改了max_allowed_packet =1024,将导致所有数据操作,如果返回结果>1024,将报错。 修改此参数,很容易让用户发现数据问题,推测是骇客是故意暴露自己,也许只为了炫耀一下。

  • 总结:

1. 再次证明在遇到复杂技术问题google 比百度要靠谱多

2. 日志分析是解决问题的必须途径

3. 增加信息安全意识,原来黑客离我们并不远,如果不是故意暴露自己,我们也不会发现此机器被黑,黑客控制此机器后,可以轻易使用此机器,进行相关非法活动。

 

具体:

1. 外网机器,一定要开启防火墙,只开放提供服务端口,禁用其它端口。 制定相关安全策略,如记录登陆用户ip,定期查看登陆用户历史及登陆失败记录,对于反复登陆能拒绝登陆。

2. 系统用户名,应该根据需要确定是否使用root用户,具体业务最好使用普通用户权限。因为root用户,拥有系统系统的全部权限。

3.密码:用户密码一定不要使用简单密码,最好使用密码生成器生成负责密码(大小写,特殊字符,长度)

4. 数据安全:

mysql应该给不同业务创建不同用户,并赋予有限功能权限,禁止root 用户做业务操作。

 

 

标签:

版权申明:本站文章部分自网络,如有侵权,请联系:west999com@outlook.com
特别注意:本站所有转载文章言论不代表本站观点,本站所提供的摄影照片,插画,设计作品,如需使用,请与原作者联系,版权归原作者所有

上一篇:mysql颠覆实战笔记(一)--设计一个项目需求,灌入一万数据先

下一篇:大数据量高并发的数据库优化