卍 花径不曾缘客扫, 蓬门今始为君开. 古佛拈花方一笑, 痴人说梦已三生!

Redis服务器被劫持风波

NoSql 拈花古佛 7606℃ 0评论 繁體

俗话说全猛于虎,之前多多少少有所小体会;这次的上线Redis服务器被劫严重影响了开发测试和线上环境,在解决的过程也对安全方面了解了很多;总结了这次过程的排查流程以及采取的相应测试,在此与大家共享。

被劫风波

一、问题:

1、开发,生产,测试服务器(shiro :246;开发:251; 测试:204;生产:164,165)每台机器的Redis服务(全部或部分,其中若为单机版的Redis则为全部,有集群则为部分)未启动;

注:判断Redis启动没问题的步骤:

(1)利用命令: ps -ef | grep redis 查询Redis服务(下图以246为例,黄框部分代表6379的Redis服务正在运行)

Redis服务器被劫持风波

(2)在客户机上利用Redis Desktop Manager客户端连接服务(能够连上并加装上数据说明Redis服务正常)—(若连接不上检查服务器和个人机的防火墙,以及Redis的配置文件中的bind绑定的IP)

Redis服务器被劫持风波

2、将Redis服务重新启动,发现Redis服务没有起来:

(1)查询Redis所占用的进程—用ps -ef |grep redis 命令查询Redis服务的进程号(如下图,黄框中代表Redis在6379的端口启动着,所占用进程为3684)

Redis服务器被劫持风波

(2)用kill -9 3684(Redis所占用的进程号,集群版可能有多个端口号需要都杀掉)

(3)用./redis-server & 命令启动Redis

(4)正常启动后发现不报错,并能正常访问,这次发现Redis服务竟然没有起来

    二、排查过程:

1、通过检查所有Redis服务发现共同的特点:使用默认端口6379的都挂掉;其中246的情况最为严重(246上执行命令反应比较环慢)

2、在246上查看服务器性能消耗情况(执行top命令,出来数据后用Ctrl C组合键数据按CPU排序,用Ctrl M键按内存排序),发现有一恶意进程持续占用CPU特别高,如下:

Redis服务器被劫持风波

3、怀疑此恶意进程是黑客通过定时任务或开机启动脚本植入,在246服务器上用crontab –r发现一定时任务:

Redis服务器被劫持风波

4、去网上查,根据文章(http://m.blog.csdn.net/article/details?id=54140321&winzoom=1)操作了部分:将/var/spool/cron目录下的root文件删除(文件内容为3中的定时任务),用(kill-9 PID)将恶意进程(AnXqV.yam)杀掉观察;

5、发现过了五六分钟这个进程又自己起来,此时在246上通过命令find / -name AnXqV查看发现有很多文件和网上遇到情况一样确认被挖矿入侵(http://www.setphp.com/981.html)

6、通过本地浏览器访问定时任务中的网址:http://www.haveabitchin.com/pm.sh?0222从黑客网站上下载一个脚本(pm.sh);

7、分析pm.sh中的文件发现了黑客想做的事情,大概内容如下:

Redis服务器被劫持风波

8、根据pm中的相关路径将246上如下恶意文件删除:

(1)/var/spool/cron/root

(2)/var/spool/cron/crontabs/root

(3)~/.ssh/authorized_keys

(4)/var/spool/cron/authorized_keys

(5)/tmp中的11个文件

Redis服务器被劫持风波

查看了这几个文件除了log文件其他均为乱码,查看log文件内容:

①一直试图在访问病毒的网站

Redis服务器被劫持风波

②在DNS上查找一些网址,猜测它是监测服务器是否可以有通路访问到它的网站

Redis服务器被劫持风波

③在站长之家上查询IP信息,再查询Digital Ocean猜测应该是某黑客在Digital Ocean上租用的服务来搞的:

Redis服务器被劫持风波

④其中它对应的网站:

Redis服务器被劫持风波

9、检查其他Redis服务器上有无可疑文件,发现204上的一个可疑文件,/var/spool/cron/中的root;

10、将246上的可疑文件和redis缓存文件dump.rdb以及204上的可疑文件删除,启动各个Redis服务器的服务正常。

注:246上删除redis的缓存文件如下:

/tmp/dump.rdb

/usr/local/redis/bin/ dump.rdb

/var/spool/cron/ dump.rdb

11、现在再看看情况,其中有疑惑的地方:

(1)病毒通过哪台机器以及如何入侵到局域网,现在连外网机器除了ITOO的生产Jboss外还有其他机器

(2)246和204的病毒是自己本身上的病毒还是局域网其他机器来遥控的

三、Redis防护建议:

1、Redis本身防护

(1)不要使用默认端口(6379)

(2)增加Redis用户名和密码

(3)在Redis绑定指定IP访问(位置配置文件[redis.config]中的bind节点)

2、Linux服务器

(1)Redis服务器不要暴露在外网

(2)开启防火墙,限制IP可以访问(iptables命令)

(3)用容器(如Docker等)管理起服务器,这样中病毒后排查不出原因需要重新装环境的时候影响小并且可以快速恢复。

   四、Redis参考资料:

1、CentOS7安装redis被AnXqV挖矿程序入侵

2、阿里云服务器被挖矿minerd入侵的解决办法

3、Google基础设施安全设计概述翻译和导读

4、codis与pika的docker化 (Redis替代解决方案)

【总结】

1、安全无小事,重视起安全;

2、在侦查病毒的时候,真如一朋友所说想破案一样;

3、要事第一,学会衡量;在这次解决的过程中,因为严重影响了开发人员的开发,所以在解决的过程中要先稳定开发环境,不能让人员闲置起来。

转载请注明:拈花古佛 » Redis服务器被劫持风波

喜欢 (0)or分享 (0)
发表我的评论
取消评论

表情

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址