共计 2882 个字符，预计需要花费 8 分钟才能阅读完成。
前言
服务器好端端的居然中了挖矿病毒！！！
可怜我那 1 核 2 G 的服务器，又弱又小，却还罢黜不了被拉去当矿工的命运，切实是惨啊惨。
事件原来是这样的。。。
就在今天下午，我筹备登陆本人的近程服务器搞点货色的时候，忽然发现 ssh 登陆不上了。
如上，提醒被回绝。这个问题很显著就是服务器没有我的公钥，或者不辨认我的公钥，而后回绝登录。
这就很难办了，我确定我的公钥是始终没有变动过的，不应该会呈现这种状况啊。
还有让我头疼的是，我当初为了平安起见，设置过此台服务器只能通过 ssh 的形式免密登录。而且禁止了明码间接登录，这样也避免了他人通过破解我的明码而登录服务器。
以后，只有我这个 mac 还有家里的 win 两台电脑有 ssh 权限。（其实，过后我也想到了这种状况，就怕万一有一天某台电脑登录不上，另外一台还能做备选。嘿嘿，我是不是很机智！）
那么，目前的解决办法，就是要么等着上班回家，用另外一个电脑操作，把以后这个电脑的公钥加到服务器的authorized_keys 文件里。要么，就只能把服务器重装了。
然而，好奇心驱使我去探索一下，到底是什么起因导致了服务器连贯不上，而不是间接重装服务器。那样的话，就太没意思了。
通过 VNC 形式登录服务器
因为我用的是腾讯云服务器嘛，于是，就登录到了腾讯云的控制台，想看一下是否还有其它“走后门”的形式，让我绕过 ssh 或者不受明码登录的限度。
没想到，还真的有办法。如下图，能够通过 VNC 的形式进去，而后输出账号密码就能够间接登录，不受限制。
能够看到曾经进入服务器了。上一次登录工夫是昨天下午，这个工夫点没错。
发现问题
当然，失常来讲，我应该先去 authorized_keys 文件检查一下我的公钥是否有问题。然而，习惯性的操作让我 top 了一下，却发现了另外一个问题。
等等，这是什么鬼！有一个 sysupdate 过程占用了 CPU 51.2%，另外还有一个过程 networkservice 占用了 47.8%。这两个加起来，就曾经占用了 99% 了。
实际上，在腾讯云后盾也能监控到服务器的实时情况。
很显著，这两个过程是比拟异样的。而且，之前也没有见过这种名字。于是，习惯性的，我就在网上搜了一下 sysupdate。间接，就进去了一堆后果，挖矿病毒。
我去，听这名字，难不成就是传说中的比特币挖矿？不论那么多了，先解决以后的问题吧。
解决问题
1、确认病毒地位
先通过 systemctl status {过程号} 查看一下它的状态信息，以及有没有相关联的过程。以 sysupdate 过程号 16142 为例。
能够发现它是从昨天晚上九点开始运行起来的。怪不得，昨天下午上班前还能用，明天就不能用了。
还能够通过 ls -l proc/{过程号}/exe 命令查看它具体的地位。最初发现都在 /etc 目录下。
如上图，这五个都是“挖矿病毒所用到的文件”。哼哼，从色彩上就能看进去他们是一伙的。
然而，我并没有焦急把它们革除掉，却忽然脑子一抽，想钻研一下它们的脚本。因为我看到有一个 update.sh，里边必定写了一些病毒执行相干的命令。
我把他们全副都复制到了我本人的目录下 /root/test/。而后关上了 update.sh 脚本，看里边写了些什么。
我预计，能看着服务器都被病毒攻打了，还有闲情钻研人家是怎么制作病毒的，我是第一个吧。。
尽管菜鸡我对 linux 不熟，然而大略能够看进去一些货色，如 SELINUX 零碎被敞开了，我的 authorized_keys 文件也被改变了，居然无耻的还把 wget、curl 等命令改了名字。
下边，还能够看到病毒脚本的网络门路。难不成是从这个地址下载下来的？
2、删除定时工作
看一下有没有定时工作，因为有可能它会跑一个定时工作，定时的执行脚本，生成病毒文件和过程等。
能够进入 /var/spool/cron/ 目录查看定时工作。也能够通过 crontab -l查看。
没想到却都没有发现。
如果有的话 ，删除 /var/spoool/cron/ 目录下的所有文件。或者执行crontab -r 命令，清空工作列表。
3、杀掉过程，删除病毒文件
用 kill -9 {过程号} 把上边的两个过程都杀掉，而后删除 /etc 目录下的那五个文件。
留神删除文件时，间接用一般的 rm -rf 不能行。因为病毒文件被锁定了，须要通过 chattr -i {文件名} 解锁之后，再删除。
4、删除 authorized_keys 文件
这个文件里记录了能够通过 ssh 免密登录的所有终端的公钥。门路在 ~/.ssh/authorized_keys。通过 vi 命令关上。
能够看到文件里曾经被改变了，多了两个未知的公钥，这必定就是攻击者的公钥。后面的三个都是我本人的公钥。
能够间接删除此文件，等稍后再修复为本人的公钥。
5、复原 wget 和 curl 命令
从 update.sh 文件中能够看到这两个命令名称被改了，对于习惯了这样应用的人来说必定不爽，那就改回来就好了。
如下为可选的的命令。我这里就须要前两行就行了，因为 which cur 之后发现，只存在 /bin 下，/usr/bin/ 不存在
mv /bin/wge /bin/wget
mv /bin/cur /bin/curl
mv /usr/bin/wge /usr/bin/wget
mv /usr/bin/cur /usr/bin/curl6、修复 SELINUX
SELinux 是 linux 的一个平安子系统。能够通过命令 getenforce 查看服务状态。
其实从 update.sh 文件中也能够看到此服务被敞开了。
批改 /etc/selinux/config 文件，将 SELINUX=disabled 批改为 SELINUX=enforcing。
批改实现后，须要重启服务器能力失效。
找到起因
其实，以上步骤搞完，还差一步。
你总不能被攻打的不明不白吧，为什么他人会攻打到你的服务器呢。
起初，从网上找到了一篇介绍，说：
挖矿病毒，利用 Redis 的未受权拜访破绽进行攻打。
Redis 默认配置为 6379 端口无明码拜访，如果 redis 以 root 用户启动，攻击者能够通过公网间接链接 redis，向 root 账户写入 SSH 公钥文件，以此获取服务器权限注入病毒
我去，看完之后，感觉这个形容几乎不能太准了。
因为，昨天下午，我就是因为要测试通过 redis 的 zset 来实现延时队列的一个性能。用本地代码连贯了服务器的 redis。过后就在防火墙中把 6379 端口关上了。
谁曾想，一早晨的功夫，就被人家攻打了。
我想，挖矿人必定也是找大量的机器来试验，看是否通过这些破绽（必定不限于只有 redis），操纵对方的服务器。于是，我就侥幸的成为了那个倒霉蛋。
最初，我粗犷的把 redis 服务关了，并且去掉了 6379 的端口。
额，其实有更温顺的计划可选，比方更改 redis 的默认端口号，或者给 redis 增加明码。
最初
感觉整篇下来，如同除了晓得 redis 的这个破绽外，就没有其余播种了。次要是，我的安全意识还是比拟单薄吧。
毕竟，服务器只是拿来玩玩用的。最初切实不行也能够重装系统，完事又是一条好汉。
公司的服务器必定不会这样的，都有专门的运维人员来做这些平安工作。如果是线上服务器被人家拉去挖矿，好歹能拿我这篇文章吹牛逼了。。。