本文转自 @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 发现的确没有再复现问题。
总结：
尽管本次问题从发现到解决总用时十来分钟，然而纯属运气下得以疾速解决，也阐明了服务非性能故障解决的多维性、运维技术人员技术思维发散性和常识全面性，次要还是要多实战才是王道，本次问题次要起因是：
一、主因是服务器明码设置过于简略，导致被无隙可乘。
二、服务器平安防护设置不够欠缺。
三、项目组人员上传文档没有进行谨严审核导致上传文件带有病毒才导致本次问题引发。
四、服务器零碎用户登录权限不够欠缺。
五、碰到问题不恐慌、要静心、要沉着。