服务器Redis实例中挖矿病毒排查及处理

文章系转载，方便整理和归纳，源文地址 https://z.itpub.net/article/detail/E0D0607EFA91E5FA88035F74D040DD26
巧不巧的我的服务器也被挖矿了，应该就是这个方法搞的

却说这一日，Redis正如往常一般工作，不久便收到了一条SAVE命令。

虽说这Redis常被用来当做缓存，数据只存在于内存中，却也能通过SAVE命令将内存中的数据保存到磁盘文件中以便持久化存储。

只见Redis刚打开文件，准备写入，不知何处突然冲出几个大汉将其擒住。

到底是怎么回事？Redis一脸懵。

这事还得要从一个月之前说起。

挖矿病毒

一个月前，突如其来的警报声打破了Linux帝国夜晚的宁静，CPU占用率突然飙升，却不知何人所为。在unhide的帮助下，总算揪出了隐藏的进程。本以为危机已经解除，岂料···

夜已深了，安全警报突然再一次响了起来。

“部长，rm那小子是假冒的，今天他骗了我们，挖矿病毒根本没删掉，又卷土重来了！”

安全部长望向远处的天空，CPU工厂门口的风扇又开始疯狂地转了起来···

无奈之下，部长只好再次召集大家。

unhide再一次拿出看家本领，把潜藏的几个进程给捉了出来。kill老哥拿着他们的pid，手起刀落，动作干脆利落。

这一次，没等找到真正的rm，部长亲自动手，清理了这几个程序文件。

“部长，总这么下去不是个办法，删了又来，得想个长久之计啊！”，一旁的top说到。

“一定要把背后的真凶给揪出来！”，ps说到。

“它们是怎么混进来的，也要调查清楚！”，netstat说到。

“对，对，就是”，众人皆附和。

部长起身说道，“大家说得没错，在诸位到来之前，我已经安排助理去核查了，相信很快会有线索。”

此时，防火墙上前说道：“为了防止走漏消息，建议先停掉所有的网络连接”

“也罢，这三更半夜的，对业务影响也不大，停了吧！”，安全部长说到。

不多时，助理行色匆匆地赶了回来，在部长耳边窃窃私语一番，听得安全部长瞬时脸色大变。

“sshd留一下，其他人可以先撤了”，部长说到。

大伙先后散去，只留下sshd，心里不觉忐忑了起来。

“等一下，kill也留一下”，部长补充道。

一听这话，sshd心跳的更加快了。

助理关上了大门，安全部长轻声说到：“据刚刚得到的消息，有人非法远程登录了进来，这挖矿病毒极有可能就是被人远程上传了进来”

sshd一听这话大惊失色，慌忙问道：“难道登录密码泄露了？”

“应该不是，是使用的公私钥免密登录”，一旁的助理回答到。

“你看，在/root/.ssh/authorized_keys文件中，我们发现了一个新的登录公钥，这在之前是没有的”，随后，助理输出了这文件的内容：

[root@xuanyuan ~]# cat .ssh/authorized_keys
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABA······

“绝不是我干的”，sshd急忙撇清。

“远程登录，这不是你负责的业务吗？”，助理问到。

“确实是我负责，但我也只是按程序办事，他能用公私钥登录的前提是得先把公钥写入进来啊，所以到底是谁写进来的，这才是关键！”，sshd说到。

“说的没错，别紧张，想想看，有没有看到过谁动过这个文件？”，部长拍了下sshd的肩膀说到。

“这倒是没留意”

部长紧锁眉头，来回走了几步，说道：“那好，这公钥我们先清理了。回去以后盯紧这个文件，有人来访问立刻报给我”

“好的”，sshd随后离开，发现自己已经吓出了一身冷汗。

凶手浮现

时间一晃，一个月就过去了。

自从把authorized_keys文件中的公钥清理后，Linux帝国总算是太平了一阵子，挖矿病毒入侵事件也渐渐被人淡忘。

这天晚上夜已深，sshd打起了瞌睡。

突然，“咣当”一声，sshd醒了过来，睁眼一看，竟发现有程序闯入了/root/.ssh目录！

这一下sshd睡意全无，等了一个多月，难道这家伙要现身了？

sshd不觉紧张了起来，到底会是谁呢？

此刻，sshd紧紧盯着authorized_keys文件，眼睛都不敢眨一下，生怕错过些什么。

果然，一个身影走了过来，径直走向这个文件，随后打开了它！

sshd不敢犹豫，赶紧给安全部长助理发去了消息。

那背影转过身来，这一下sshd看清了他的容貌，竟然是Redis！

收到消息的部长带人火速赶了过来，不等Redis写入数据，就上前按住了他。

“好家伙，没想到内鬼居然是你！”，sshd得意的说到。

Redis看着众人，一脸委屈，“你们这是干什么？我也没做什么坏事啊”

“人赃并获，你还抵赖？说吧，你为什么要来写authorized_keys文件？”

“那是因为我要来执行数据持久化存储，把内存中的数据写到文件中保存”，Redis答道。

“你持久化存储，为什么会写到authorized_keys文件里面来？”，sshd继续质问。

“刚刚收到几条命令，设置了持久化存储的文件名就是这个，不信你看”，说罢，Redis拿出了刚刚收到的几条命令：

CONFIG SET dir /root/.ssh
CONFIG SET dbfilename authorized_keys
SAVE

“第一条指定保存路径，第二条指定保存的文件名，第三条就是保存数据到文件了”，Redis继续解释到。

安全部长仔细看着几条命令，说道：“把你要写入的数据给我看看”

“这可有点多，你等一下”，说罢，Redis拿出了所有的键值数据，散落一地。

众人在一大片数据中看花了眼。

“部长快看！”，sshd突然大叫。

顺着他手指的方向，一个醒目的公钥出现在了大家面前。

ssh-rsa AAAAB3NzaC1yc2EAA···

“果然是你！”

Redis还是一脸懵，还不知发生了什么。

“你这家伙，被人当枪使了！你写的这个文件可不是普通文件，你这要是写进去了，别人就能远程登录进来了，之前的挖矿病毒就是这么进来的！”，sshd说到。

一听这话，Redis吓得赶紧掐断了网络连接。

“给你下命令的究竟是谁，又是怎么连接上你的？”，部长问到。

Redis不好意思的低下了头，只说道：“不瞒您说，我这默认就没有密码，谁都可以连进来”

安全部长听得眼睛都瞪圆了，愤而离去。

只听得一声大叫，kill老哥又一次手起刀落。

彩蛋

“部长，不好了”

“什么事，慌慌张张的”

“我的数据全都被加密了！”，MySQL气喘吁吁的说到···

总结：这种就是利用了Redis默认端口无密码操作，生成了ssh免密登录的配置文件。要从以下方面进行解决：

Redis要设置密码
端口不要是6379默认端口
不要用root用户启动Redis

另外参考这个文章 https://www.cnblogs.com/Cl0ud/p/13873085.html