mysqlmax_allowed_packet⾃动重置为1024终结解决
背景：
测试环境1台centOS机器，最近⼀段频繁报“
Caused by: sql.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）. 修改myf  在[mysqld]段或者mysql的server配置段进⾏修改。（终极修改, 修改后重启数据库，永久⽣效）
  如下: max_allowed_packet = 20M
通过⽅法2修改完成后，通过客户端⽣效。但发现，过⼀段时间（有时⼏个⼩时，有时1~2天），⾃动变为1024。
思考：google 发现有说被⿊客攻击，本来不相信，因为是内⽹环境。⽆奈出现情况，越来越频繁，刚更改后，过⼀会就变为1024。以下帖⼦给了启发：
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 & （过滤max_allowed_packet，并输出到⽂件1.txt)
果然发现，有以下修改：
1608048:59:41172 Query    SET GLOBAL max_allowed_packet=1024
172 Query    SET GLOBAL max_allowed_packet=1024
173 Query    SET GLOBAL max_allowed_packet=1024
1608048:59:49173 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 (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  110:49-10:49  (00:00)
producti ssh:notty    217.76.78.35    Mon Aug  110:49-10:49  (00:00)
swsoft  ssh:notty    217.76.78.35    Mon Aug  110:49-10:49  (00:00)
swsoft  ssh:notty    217.76.78.35    Mon Aug  110:49-10:49  (00:00)
iraf    ssh:notty    217.76.78.35    Mon Aug  110:49-10:49  (00:00)
iraf    ssh:notty    217.76.78.35    Mon Aug  110:49-10:49  (00:00)
svn      ssh:notty    217.76.78.35    Mon Aug  110:49-10:49  (00:00)
svn      ssh:notty    217.76.78.35    Mon Aug  110:49-10:49  (00:00)
oracle  ssh:notty    217.76.78.35    Mon Aug  110:49-10:49  (00:00)
oracle  ssh:notty    217.76.78.35    Mon Aug  110:49-10:49  (00:00)
root    ssh:notty    217.76.78.35    Mon Aug  110:49-10:49  (00:00)
lab      ssh:notty    217.76.78.35    Mon Aug  110:48-10:48  (00:00)
lab      ssh:notty    217.76.78.35    Mon Aug  110:48-10:48  (00:00)
root    ssh:notty    217.76.78.35    Mon Aug  110:48-10:48  (00:00)
root    ssh:notty    217.76.78.35    Mon Aug  110:48-10:48  (00:00)
apache  ssh:notty    217.76.78.35    Mon Aug  110:48-10:48  (00:00)
apache  ssh:notty    217.76.78.35    Mon Aug  110:48-10:48  (00:00)
root    ssh:notty    217.76.78.35    Mon Aug  110:48-10:48  (00:00)
root    ssh:notty    217.76.78.35    Mon Aug  110:48-10:48  (00:00)
root    ssh:notty    217.76.78.35    Mon Aug  110:48-10:48  (00:00)
5. ⿊客为什么要修改max_allowed_packet 1024 ?
修改了max_allowed_packet =1024，将导致所有数据操作，如果返回结果>1024，将报错。修改此参数，很容易让⽤户发现数据问题，推测是骇客是故意暴露⾃⼰，也许只为了炫耀⼀下。
mysql下载失败怎么办
总结：
1. 再次证明在遇到复杂技术问题google ⽐百度要靠谱多
2. ⽇志分析是解决问题的必须途径
3. 增加信息安全意识，原来⿊客离我们并不远，如果不是故意暴露⾃⼰，我们也不会发现此机器被⿊，⿊客控制此机器后，可以轻易使⽤此机器，进⾏相关⾮法活动。
具体：
1. 外⽹机器，⼀定要开启防⽕墙，只开放提供服务端⼝，禁⽤其它端⼝。制定相关安全策略，如记录登陆⽤户ip，定期查看登陆⽤户历史及登陆失败记录，对于反复登陆能拒绝登陆。
2. 系统⽤户名，应该根据需要确定是否使⽤root⽤户，具体业务最好使⽤普通⽤户权限。因为root⽤户，拥有系统系统的全部权限。
3.密码：⽤户密码⼀定不要使⽤简单密码，最好使⽤密码⽣成器⽣成负责密码（⼤⼩写，特殊字符，长度）
4. 数据安全：
mysql应该给不同业务创建不同⽤户，并赋予有限功能权限，禁⽌root ⽤户做业务操作。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。