不可能!我的内网服务器怎么会被黑客入侵?


背景

最近,公司内网的一台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 全局连接生效

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

2、设置方式

代码如下:

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

如果用方式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

查看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 (

果然发现,有以下修改:

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相关安全参数,设置相关变量。

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]# 

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参数呢?

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

四、防护措施

1. 开启防火墙

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

2. 用户名设置

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

3.密码设置

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

4. 权限设置

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

五、总结

  • 再次证明没有一件事情的发生是无中生有的,只要愿意去挖掘,总会有新发现
  • 日志分析是解决问题的必须途径。
  • 增加信息安全意识,原来黑客离我们并不远,如果不是故意暴露自己,我们也不会发现此机器被黑,黑客控制此机器后,可以轻易使用此机器,进行相关非法活动。
已标记关键词 清除标记
相关推荐
©️2020 CSDN 皮肤主题: 书香水墨 设计师:CSDN官方博客 返回首页