没想到竟是由于它！让个人服务器变成了别人的挖矿工具

前言

服务器好端端的居然中了挖矿病毒！！！

可怜我那 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。直接，就出来了一堆结果，挖矿病毒。

我去，听这名字，难不成就是传说中的比特币挖矿？无论那么多了，先解决当前的问题吧。

解决问题

一、确认病毒位置

先经过 systemctl status {进程号} 查看一下它的状态信息，以及有没有相关联的进程。以  sysupdate 进程号 16142为例。

能够发现它是从昨天晚上九点开始运行起来的。怪不得，昨天下午下班前还能用，今天就不能用了。

还能够经过 ls -l proc/{进程号}/exe 命令查看它具体的位置。最后发现都在 /etc 目录下。

如上图，这五个都是“挖矿病毒所用到的文件”。哼哼，从颜色上就能看出来他们是一伙的。

然而，我并无着急把它们清除掉，却忽然脑子一抽，想研究一下它们的脚本。由于我看到有一个 update.sh ，里边确定写了一些病毒执行相关的命令。

我把他们所有都复制到了我本身的目录下 /root/test/。而后打开了 update.sh 脚本，看里边写了些什么。

我估计，能看着服务器都被病毒***了，还有闲情研究人家是怎么制做病毒的，我是第一个吧。。

虽然菜鸡我对 linux 不熟，可是大概能够看出来一些东西，如SELINUX 系统被关闭了，个人 authorized_keys 文件也被改动了，居然无耻的还把 wget、curl 等命令改了名字。

下边，还能够看到病毒脚本的网络路径。难不成是从这个地址下载下来的？

二、删除定时任务

看一下有没有定时任务，由于有可能它会跑一个定时任务，定时的执行脚本，生成病毒文件和进程等。

能够进入 /var/spool/cron/ 目录查看定时任务。也能够经过 crontab -l查看。

没想到却都没有发现。

**若是有的话，**删除 /var/spoool/cron/目录下的全部文件。或者执行crontab -r命令，清空任务列表。

三、杀掉进程，删除病毒文件

用 kill -9 {进程号} 把上边的两个进程都杀掉，而后删除 /etc 目录下的那五个文件。

注意删除文件时，直接用普通的 rm -rf 不能行。由于病毒文件被锁定了，须要经过 chattr -i {文件名} 解锁以后，再删除。

四、删除 authorized_keys 文件

这个文件里记录了能够经过 ssh 免密登陆的全部终端的公钥。路径在 ~/.ssh/authorized_keys 。经过 vi 命令打开。

能够看到文件里已经被改动了，多了两个未知的公钥，这确定就是***者的公钥。前面的三个都是我本身的公钥。

能够直接删除此文件，等稍后再修复为本身的公钥。

五、恢复 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/curl

六、修复 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 的这个漏洞外，就没有其余收获了。主要是，个人安全意识仍是比较薄弱吧。

毕竟，服务器只是拿来玩玩用的。最后实在不行也能够重装系统，完事又是一条好汉。

公司的服务器确定不会这样的，都有专门的运维人员来作这些安全工做。若是是线上服务器被人家拉去挖矿，好歹能拿我这篇文章吹牛逼了。。。

-END-