早上睡觉被一条条的阿里云服务器告警信息惊醒,提示我的服务器CPU使用率超过80%,我就纳闷了我的服务器平时CPU使用率还不到10%,这次怎么会这么高。服务器有异常是肯定的了,我的服务器在云控制台配置了安全组策略,服务器修改了ssh端口,开启了防火墙,设置了hosts.allow hosts.deny等防范措施。这都能被***我也是醉了。

登上服务器,首先用top查看

[root@iZ11r3dkZ ~]# top
top - 08:35:19 up 127 days, 13:32,  2 users,  load average: 4.11, 4.17, 4.05
Tasks: 112 total,   3 running, 109 sleeping,   0 stopped,   0 zombie
%Cpu(s): 99.6 us,  0.4 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem:   8011936 total,  6693204 used,  1318732 free,   249428 buffers
KiB Swap:        0 total,        0 used,        0 free.  1893760 cached Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                                                
 1948 root      20   0  411256  33504   1840 S 395.9  0.4 807:08.47 yam                                                                                    
27677 root      20   0 6180036 3.305g  20564 S   1.6 43.3 201:02.07 java                                                                                   
   13 root      20   0       0      0      0 S   0.8  0.0 277:13.81 rcu_sched                                                                              
 7484 root      20   0  136952   4144   1012 S   0.8  0.1   1366:29 /usr/local/apac                                                                        
12136 root      20   0  123628   1564   1116 R   0.8  0.0   0:00.01 top

你会注意到有个yam进程占用CPU时间395.9%。对这就是异常 的发源地。


然后再用ps -ef | grep yam 查看该进程详细信息

[root@iZ11r3dkvpbZ ~]# ps -ef | grep yam
root      1948     1 99 04:47 ?        13:27:50 ./yam -c 1 -M stratum+tcp://enriquedolas%40gmail.com:x@xmr.pool.minergate.com:45660/xmr

然后查了一下后面的yam······指令,发现这就是利用redis漏洞进行***的脚本


之后很长的一段时间一直在和redis漏洞的***脚本作斗争。。。。。一个是gg3lady文件,还有一个是yam文件

尝试了两个个小时也无法彻底关闭相关进程和删除这两个脚本。

 

于是换了一种角度思考,既然病毒程序总是自己启动,我为何不从自动启动的地方开始处理。

然后找到计划任务的文件/etc/crontab

发现里面果然多了一行计划任务*/3 * * * * root /etc/cron.hourly/gcc.sh

先删除这行计划任务。

再输入top命令(top命令可以查看系统中占用最多资源的进程)

发现一个名为wyvrzccbqr的程序占用最多。。。。。(之前靠#ps -ef 命令竟然更本看不到它)

看到它的pid为473

先暂停他(不要直接杀,否则会再生)# kill -STOP 473
刪除 /etc/init.d 內的档案# find /etc -name '*wyvrzccbqr*' | xargs rm -f
刪除 /usr/bin 內的档案# rm -f /usr/bin/wyvrzccbqr
查看 /usr/bin 最近变动的档案,如果是病毒也一并刪除,其他可疑的目录也一样# ls -lt /usr/bin | head

结果显示有个名为doeirddtah的文件也很可疑。于是一起删掉# rm -f /usr/bin/doeirddtah

現在杀掉病毒程序,就不會再产生。#pkill wyvrzccbqr
刪除病毒本体。# rm -f /lib/libudev.so


这样问题就解决了


剩下的就是修复redis漏洞了。

                

         Redis未授权访问漏洞

 一、漏洞描述和危害 

 
Redis因配置不当可以未授权访问,被***者恶意利用。
***者无需认证访问到内部数据,可能导致敏感信息泄露,***也可以恶意执行flushall来清空所有数据。

***者可通过EVAL执行lua代码,或通过数据备份功能往磁盘写入后门文件。

如果Redis以root身份运行,***可以给root账户写入SSH公钥文件,直接通过SSH登录受害服务器。
 

二、已确认被成功利用的软件及系统  
 
对公网开放,且未启用认证的redis服务器。

三、建议修复方案
 
1、指定redis服务使用的网卡 (
需要重启redis才能生效
在 redis.conf 文件中找到 “# bind 127.0.0.1” ,把前面的#号去掉,然后保存。注:修改后只有本机才能访问Redis。
 
2、设置访问密码 (
需要重启redis才能生效
在 redis.conf 中找到“requirepass”字段,在后面填上你需要的密码,Redis客户端也需要使用此密码来访问Redis服务。
 
3、修改Redis服务运行账号 
需要重启redis才能生效
请以较低权限账号运行Redis服务,且禁用该账号的登录权限。另外可以限制***者往敏感写入文件,但是Redis数据还是能被***访问到,或者被***恶意删除。

 

4、设置防火墙策略

如果正常业务中Redis服务需要被其他服务器来访问,可以设置iptables策略仅允许指定的IP来访问Redis服务。