前言
下午,我准备登陆自己的远程服务器搞点东西的时候,突然发现 ssh 登陆不上了。
如上,提示被拒绝。这个问题很明显就是服务器没有我的公钥,或者不识别我的公钥,然后拒绝登录。
这就很难办了,我确定我的公钥是一直没有变动过的,不应该会出现这种情况啊。
还有让我头疼的是,我当初为了安全起见,设置过此台服务器只能通过 ssh 的方式免密登录。而且禁止了密码直接登录,这样也防止了别人通过破解我的密码而登录服务器。
但是,好奇心驱使我去探究一下,到底是什么原因导致了服务器连接不上,而不是直接重装服务器。
通过 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 脚本,看里边写了些什么。
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/curl
6、修复 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 的这个漏洞外,就没有其他收获了。主要是,我的安全意识还是比较薄弱吧。
感谢你看到这里,我是程序员麦冬,一个java开发从业者,深耕行业六年了,每天都会分享java相关技术文章或行业资讯
欢迎大家关注和转发文章,后期还有福利赠送!