干货丨安全故障导致 CPU 偏高问题处理

本文转自@twt社区，【作者】泊涯。

这段时间我们某台应用测试服务器就出现CPU高、且无法正常登录现状，具体情况如下：

2月28日下午临近六点时，开发人员突然发了截图给我说187服务器无法登陆，问我是否修改了密码，如下图一:

想想这段时间只有安装验测运维监控工具有用到187服务，但是也是10天前的事情，且没有去修改过密码，于是我也好奇登录下看看，发现确实出现问题，重新输入密码也不行，如下图二：

追根溯源：

发现187确实无法正常登录，但是该提示信息说明该服务器没有被关闭，只是ssh链接被篡改了，这时脑中第一反应，入侵者使用了一个可执行的SSH后门，而且这些组件以服务形式安装来为恶意软件提供驻留。

出于好奇和对刚部署监控工具的可用性，我登录运维服务监控，发现还能收集187服务CPU等资源信息，如下图三，只是CPU使用率偏高，应该是使用了什么恶意软件在为它自己提供服务，但也说明187服务还是可用，只是新建的ssh连接无法链接。

还好之前有一个惰性习惯，在另外一台电脑打开一个CRT，用完很少去关。此时刚好有打开187等服务器没关，还可以直接访问，发现是TSM服务导致CPU 高，cron的内存使用率偏高，问了下开发人员没有该服务，发现都没使用，就干掉为先。

于是就直接先kill掉，然后修改了下系统登录密码，但是还是要把问题追究到底，发现kill该进程后发现CPU立马掉下来，如下图四：

通过查证：tsm64是负责通过SSH暴力破解传播挖矿机和后门的扫描器，可以发送远程命令来下载和执行恶意软件。

看了下该进程对应的服务，安装路径配置路径如下：

root 31803 31798 84 07:44 ? 08:36:57 /tmp/.X19-unix/.rsync/c/lib/64/tsm --library-path /tmp/.X19-unix/.rsync/c/lib/64/ /usr/sbin/httpd rsync/c/tsm64 -t 505 -f 1 -s 12 -S 8 -p 0 -d 1 p ip

发现该服务应该只是一个shell服务，而且看了下远程监控收集的记录，发现是2月27日凌晨四点多的时候被侵入，植入病毒，导致CPU使用率高，也导致我们CRT无法正常登录，如下图五和图六：

分析下应该是有开启服务进程，才会导致CPU和内存偏高，而引起内存偏高的是cron进程，于是通过crontab -e发现确实被开启了进程服务，如下图七

接下来直截了当，停止服务，然后删除对应路径下文件和定时作业，继续观察两天，如下图8发现确实没有再复现问题。

总结：

虽然本次问题从发现到解决总用时十来分钟，但是纯属运气下得以快速解决，也说明了服务非功能故障处理的多维性、运维技术人员技术思维发散性和知识全面性，主要还是要多实战才是王道，本次问题主要原因是：

一、主因是服务器密码设置过于简单，导致被有机可乘。

二、服务器安全防护设置不够完善。

三、项目组人员上传文档没有进行严谨审核导致上传文件带有病毒才导致本次问题引发。

四、服务器系统用户登录权限不够完善。

五、碰到问题不恐慌、要静心、要冷静。