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