不可能！我的内网服务器怎么会被黑客入侵？_内网会不会被黑客攻击

---

背景

最近，公司内网的一台centOS机器，上面安装了MySQL数据库，Redis等软件，测试系统时，只要遇到大的查询（列表显示比较多的数据），频繁报“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”。
因为是服务器，不存在关机的情况，就手动用命令修改了设置【set global max_allowed_packet=2048】，结果半天不到，又出现这种错误提示，去查询max_allowed_packet设置发现又变成了1024，很好奇的情况下就开始了如下排查经历。最终发现被黑客入侵了，频繁修改参数导致的。

---

一、解决办法

问题既然出了，首先要先解决参数设置的问题，然后再来查找为什么频繁出现设置被复原的情况吧，先看max_allowed_packet的参数。

1、查看max_allowed_packet设置

代码如下：

show golbal variables like %max_allowed_packet%;
//注意：mysql系统参数分为session和global 之分， 
//session只当前连接生效，
//global 全局连接生效
1
2
3
4

查看发现果然是1024，二话不说，先改掉，不然一会儿测试就要来打人了！！！

2、设置方式

代码如下：

//方式1：通过MySQL客户端（Navicat）设置（用命令行也行，大家开心就行）：
set global max_allowed_packet=2048;#修改后重启数据库会恢复成设置之前的数据
//方式2：修改my.conf文件，在[mysqld]段或者mysql的server配置段修改。此乃终极修改方式，
[mysqld]
max_allowed_packet=2048
1
2
3
4
5

如果用方式2修改的话，即使是又变成了1024，重启也可以解决，也就是传说中的“重启大法”。

但是，作为一个有“情怀”的程序猿，天天重启也不是个事儿啊，服务器上还有一堆的系统和软件，都要重启一遍，可能实施也要骂娘了。于是乎，上网看看是不是服务器疯了，会智能化自动复原。

不搜不知道，一搜吓一跳，网上说可能被黑客入侵。

what？？？我服务器是内网服务器，黑客是怎么进来的？难道是有内鬼？

那就让正义的我，来把你揪出来!

---

二、揪出内鬼

1、查日志(打开genearl_log)

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
1
2
3
4
5
6
7
8
9
10
11
12
13
14

查看general_log：

#查看log，但打印大量实时sql操作
tail -f /var/run/mysqld/mysqld.log |grep max_allowed_packet 
#过滤max_allowed_packet，并输出到文件1.txt
tail -f /var/run/mysqld/mysqld.log |grep max_allowed_packet >1.txt （
1
2
3
4

果然发现，有以下修改：

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 
1
2
3
4
5

了解到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
   ........
1
2
3
4
5
6

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

2、结论

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

---

三、疑问

1、MySQL是部署内网的，外网怎么访问？

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

• 过外网IP, 使用mysql客户端，可以直接连接到mysql服务。
• 通过外网IP, 使用xshell 登陆成功

2、黑客是怎么知道用户名和密码的？

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

3、防火墙怎么没防住？

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

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

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)    
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

5、黑客为什么要修改max_allowed_packet参数呢？

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

四、防护措施

1. 开启防火墙

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

2. 用户名设置

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

3.密码设置

用户密码一定不要使用简单密码，最好使用密码生成器生成负责密码（大小写，特殊字符，长度）

4. 权限设置

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

五、总结

• 再次证明没有一件事情的发生是无中生有的，只要愿意去挖掘，总会有新发现
• 日志分析是解决问题的必须途径。
• 增加信息安全意识，原来黑客离我们并不远，如果不是故意暴露自己，我们也不会发现此机器被黑，黑客控制此机器后，可以轻易使用此机器，进行相关非法活动。