疫情在全世界肆无忌惮蔓延，但在我大中华国内得到有效控制，这不仅仅体现一个国家的综合实力也体现我们大中华亿万民心团结，才能一次一次的战胜住在外界看起来各种不可抗击的力量，国之战神在于民心，团结力量大，而我们做为IT行业运维技术人员，自身不仅要具备实战技术好，也要项目组组员都有质量运维意识，才能一起共同做好线上线下系统运营运维技术保障，做好对众多服务的非功能性、功能性等防控，确保服务的高可用性、高可靠性、高维护性、高稳定性、高安全性等确保企业业务运营正常。

不然组员对服务器上传代码工程包或者安装部署某个服务控件时会不经意间上传了有***性代码、侵害性程序，会导致系统瘫痪，类似我们在这疫情期间，我们自身戴好口罩、强健身体、小区出入做好各种安防、出入证、量体温、社区喷雾杀毒等，类似我们服务器设置好防火墙、配置好访问端口、对于每个上传文档做好安全代码扫描、定期做好性能测试等各类非功能指标检验测试等确保服务器正常运行，但是有时百密一疏，导致出问题，例如，这段时间我们某台应用测试服务器就出现CPU高、且无法正常登录现状，具体原因如下：

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

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

（图二）

发现187确实无法正常登录，但是该提示信息说明该服务器没有被关闭，只是ssh链接被串改了，这时脑门第一反应，***者使用了一个可执行的SSH后门，而且这些组件以服务形式安装来为恶意软件提供驻留。
出于好奇和对刚部署监控工具的可用性，我登录运维服务监控节目，发现还能收集187服务CPU等资源信息，如下图三，只是CPU使用率偏高，应该是使用了什么恶意软件在为他自己提供服务，但也说明187服务还是可用，只是新建的ssh连接无法链接，

![](https://s1.51cto.com/images/blog/202003/01/ad704e19df4c78c0dfb31ff67afbb7b4.png?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=)

， （图三）
还好之前有一个懒性习惯，在另外一台电脑有打开一个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发现确实没有在复现问题。
（图八）

图九

总结：
虽然本次问题从发现到解决总用时十来分钟，但是纯属运气下得以快速解决，也说明了服务非功能故障处理的多维性、运维技术人员技术思维发散性和知识全面性，主要是还是要多实战才是王道，本次问题主要原因是：
一：服务器密码设置过于简单导致被有机可乘，主因。
二：服务器安全防护设置不够完善
三：项目组人员上传文档没有进行严谨审核导致上传文件带有病毒才导致本次问题引发。
四：服务器系统用户登录权限不够完善；
五：碰到问题不恐慌、要静心、要冷静；