接手的某项目部署于某云平台centos服务器上，由tomcat作为中间件提供应用，且购买了该平台的域名服务，从2019年底上线运营，一直运行比较平稳，可能还没正式用起来，用的人也不是很多吧。但凡事总有个但是，近期发现云服务器CPU资源占用稳定在50%以上，且系统盘各目录被持续定入core.1234之类的陌生文件，导致磁盘空间占用超高。
紧接着操作服务器，不管执行什么命令，都会有这个错误提示：
ERROR: ld.so: object '/usr/local/lib/libs.so' from /etc/ld.so.preload cannot be preloaded: ignored.
虽然报错后命令还是会正常执行，但看到这个错误提示却很不爽。百度了半天也没有什么好的结果。
因为陌生进程（.libs）的资源抢占，导致系统的java进程经常挂起，于是手动kill掉对应的.libs进程，重新启动tomcat应用提供服务（因系统设计问题，无法做多节点负载部署）。初始kill掉.libs进程后，cpu占用率瞬间下降到正常水平，但其可能同时存在配套的定时监控进程（有点事后诸葛，清理掉病毒之后才想到这点），隔断时间（不定期）就会把.libs进程重新启动（用crontab –l命令检查没有发现定时任务），然后挤掉java进程，导致不得不经常监控和重启tomcat。
经公司运维人员排查，“排除”了服务器中病毒的情况，因为是新接手的服务器，除了tomcat相关的几个目录文件外，其它的文件情况一概不清楚，也不太好放开去排查清理。
因为租用了该云平台上的六台服务器，有三台同时中招，好在数据库服务器还算安全，怀疑是云平台的安全漏洞引起的，于是提交问题到云平台技术支持后也只是得到了象征性的很官方的回复套话，实在无语：
没办法，只能靠自己摸索了，好在甲方用户给了相对充足的修复时间，但自己对运维这块确实没什么经验，尤其是linux系统，心里还是没底。但即使这样，依然对技术支持的回复持怀疑态度，强迫症个性驱使自己下决心搞定它。
首先，做了充足的备份，包括数据库、程序、附件等。
然后，同时在另外一台备用服务上重新部署应用。
最后，将域名地址重新绑定到新的服务器上。
确保新的服务器环境正常后，采取了平台技术支持的建议，先尝试了修改服务器密码，清除tomcat的mangaer目录，无果！
再退一步，尝试重装系统，重新部署应用，一切正常。再一看备用服务器，泥马，又中招了！难道还跟有域名有关？但奇怪的是另外一台没有绑定域名的服务器也同样中招！讲不通啊。
把域名又换回到新装系统的旧服务器上，以为这样可以高枕无忧了，再慢慢花时间去排查其它服务器上的问题。
结果，到了第二天一早上班，打开系统，正常，松了口气。再远程打开新装系统的那台服务器，差点吐出一口老血，又莫名多出了几个.libs进程，CPU又飙升到50%以上，这才重装完系统不到24小时，心中一万只草泥马奔腾而过！手里的早餐也瞬间不香了！
再用crontab –l命令检查定时任务，
What？竟然发现了定时任务，对着百度搜索，竟然找到了有同等遭遇的兄弟：https://my.oschina.net/u/4559667/blog/4996218，倍感亲切啊！
好吧，确定是中了挖矿病毒啊！赶紧把这问题反馈到了云平台的技术支持，结果给出了让人崩溃的答复：
目前也只是查到了挖矿病毒的存在现实，但尚未清楚是通过何种途径被感染到的。也只能先医治表面上的症状。查看病毒文件发现它不停地收集服务器的用户账号信息同步到远程服务器上然后进行ssh连接控制目标服务器。
先参考了一些网友的如下医治方法：
查看占用cpu率最高的几个进程
ps aux|head -1;ps aux|grep -v PID|sort -rn -k +3|head
# -s 9标识强制关闭 2477标识进程数
# kill -s 9 2477
#把/etc/ld.so.preload 文件清空
echo "" > /etc/ld.so.preload
#其中chattr +i命令是给文件夹加锁，删除完赶紧上锁，防止恶意文件再复制进去
# chattr root用户可能会没权限。
# 先用lsattr 命令看一下 都有啥权限
#chattr + 增加权限 - 去掉权限 具体用法看问题描述
chattr +i /etc
#删除定时任务 crontab -e 进入vim模式，删除
#将/var/spool/cron/*下的所有Linux定时器删除
#好奇的话打开文件看一下里面是内容 猜的没错的话应该是一段定时脚本
rm -rf /var/spool/cron/*
#将r/etc/cron.d/*下的所有Linux定时器删除
#cron执行时，也就是要读取三个地方的配置文件：
#一是/etc/crontab，二是/etc/cron.d目录下的所有文件，三是每个用户的配置文件
rm -rf /etc/cron.d/*
#同上(加锁)
chattr +i /var/spool/cron/
#我的错误信息：ERROR: ld.so: object '/usr/local/lib/libs.so'...
#所以移除下面这个文件，具体以你报错的文件为准
rm -f /usr/local/lib/libs.so
#同上(加锁)
chattr +i /usr/local/lib
killall kworkerds
rm -f /var/tmp/kworkerds*
rm -f /var/tmp/1.so
rm -f /tmp/kworkerds*
rm -f /tmp/1.so
rm -f /var/tmp/wc.conf
rm -f tmp/wc.conf
最后，改密码，重启，再改密码！
但是，可是，该死的.libs进程隔段时间又跑出来了！除了泥马我还能说些什么！！
索性，心一横，直接找.libs进程的启动文件，直接干掉这些文件试试吧，linux不是号称一切皆文件的么。
ps –aux | grep .libs 查找对应的进程信息
ll /proc/pID 找到对应的可执行文件所在目录
Kill掉对应进程
rm掉对应的可执行文件
添加对目标服务器107.172.214.23的连接拒绝策略（包含出入）
iptables -A OUTPUT -p tcp -d w.apacheorg.top --dport 1234 -j DROP
iptables -A OUTPUT -p tcp -d 107.172.214.23 --dport 1234 -j DROP
iptables -A OUTPUT -d 107.172.214.23 -j DROP
iptables -I INPUT -s 107.172.214 -j DROP
service iptables save
service iptables restart
systemctl status iptables.service
iptables -L -n
修改root密码，重启系统！
值得欣慰的是，这个方法好像奏效了，清理后，系统平稳运行了几天，目前还在监控中。遗憾的是最终没有查到病毒的入侵途径，有可能确实是root密码被攻陷。只能加强后期的root账号防范了。其它几台服务器做了同样清理之外，目前也处于平稳运行状态了。
