mysql max_allowed_packet自动重置为1024 终结解决
- 背景：
测试环境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配置段进行修改。（终极修改, 修改后重启数据库，永久生效）
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 用户做业务操作。
