前言
自用的云服务器除了运行着一个web服务外，已经很久没有去管它了。早上，对象的手机突然收到了阿里云的“威胁短信”，如果7月26日还是没有解决服务器挖矿的现象，就将服务器停用。对象大惊，于是作为家里的劳动力担当，我便被派去解决这一次事件。
思路
首先既然被阿里云识别是挖矿行为，可以先登录控制台看一下为什么会被定位成挖矿行为的原因。不出所料，CPU的使用率已经高达100%。
支线
过程中发现有个警告事件：非常用IP登录。20号进行过通过SSH登录了服务器，IP在西班牙。由于已经很久没上过服务器，所以应该是密码被爆破或者通过某种渠道获取到了。做了两个措施：
- 安全组里对该IP进行了全端口的拦截。
- 更改root账户密码
passwd root。考虑新建账户然后关闭root账户的远程访问权限，不过还有问题没解决，这个操作先滞后。
主线
旁枝末节的事情处理完毕，该处理被拿去挖矿这件大事。首先通过top命令可以看到，有个ld-linux-x86-64进程的CPU使用率高达99.9%，基本已经确定确实是挖矿行为导致的。这是一种标准的行为，通过伪装成系统级的执行指令触发的进程来混淆视线。不过奇怪的是，网上查到的只要是跟挖矿相关的基本都是ld-linux-x86-64，难道这种黑别人服务器来挖矿的行为是已经同质化了？一键黑服务器然后一键运行统一脚本？
借助网上冲浪，大致了解了一下大家遇到这个问题的一些解决思路。主要思路都是：找到执行程序 => 杀死进程 => 删除执行程序。
一开始想的是黑客说不定比较笨，直接访问服务器然后操作。通过history看了一下，并没有发现异常。后来了解到history是不靠谱的，可以被清空的，并且默认只显示1k行，之前也没做过特别的操作收集的操作，失败。
然后尝试通过进程去定位执行源 ps -ef | grep 进程标识，并没有看出异常所在。有考虑是不是父进程，top上通过快捷键f进入展示选项，通过空格选择了PPID（进程的父进程），Q退出，结果发现父进程的PID是1.... 系统进程，由于数据量太杂，并没有发现实际有效的信息，失败。
看到网上有个方案是通过相似名称去匹配找到了执行程序，尝试了一下：
find -r -name "ld-linux*" /
居然！
真的！
找到了!
支线
不过一开始我犯了一个比较憨憨的问题，以为找到了，然后加上网上方案没细说，加上自己着实是一个Linux小白，就直接把/usr/lib64/ld-linux-x86-64.so.2删除了。。。。删除了。。。于是除了cd以外的像ls where之类指令都没法使用了。
紧急查了一下解决方案，还好还好，我删的应该是一个软连接，只需要重新建立一下软连接就可以。既然是软连接，我只需要找到它的实际指向位置，重新建立一下就好。
不过
等会。。我怎么知道它的实际指向位置？
这文件都被我删了，而且相关指令都不能用了，啊这，这可咋整，难道我要重装了么，可是服务器有正在运行的服务还没有备份，而且我该如何向对象交代。。。。
怀着忐忑的心情，决定先不告诉她，我再挣扎一下。我看网上的方案里实际的地址都是/lib64/ld-2.28.so，试了一下
难道我这个系统还跟别人的不一样？想到我是阿里云的云服务器，立马找了一个有阿里云的朋友，让他给了我他服务器的软连接实际映射地址/lib64/ld-2.21.so。不愧是阿里云，这都不一样，然后我试了一下。
这可咋搞，没帮我对象解决服务器问题，反而让她用不了了，虽然她昨天榴莲吃坏了，不会有新榴莲，但搓衣板在所难免。惆怅之时，我发现了一个规律，发现网上的是ld-2.28.so，我那朋友的ld-2.21.so，实际的映射路径应该是ld-2.xx.so，不过可能根据不同的设备和系统，可能xx这里的数据会有不同，而这一定是个数字，也就是说，我可以物理爆破，我还有机会！
嗯，挺好，也就试了17次成功了。然后执行：
/lib64/ld-2.17.so/bin/ln -s /lib64/ld-2.17.so /lib64/ld-linux-x86-64.so.2
建立软连接，哦吼，一切正常，今天可以昂着头回家了。
继续主线
这次留了个心眼，看了一下/dev/shm/.x/里的文件，run文件里有个IP地址，有cron.d配置了重启后在启动，已经具有非常高的嫌疑。做了个压缩备份，然后毅然rm -rf .x重启了一下。挖矿程序总算没有再执行，经过一段时间的观测，基本确认已经将挖矿的内容解决掉了。哦吼，已经不用担心7月26日的停机了。
后续
要想办法避免以后再次出现被拿去挖矿的情况， 要避免主账户登录，防止账户泄露。
