【实战记录】记录服务器遭到攻击全过程（Redis漏洞）

概述

在原本的做项目过程中，更加注重于项目功能的实现。而忽略了一个很重要的东西——项目容灾能力。原来的我虽然对黑客攻击有所耳闻，但是总觉得自己离这些东西很遥远，这种事情应该不会发生到我身上。正是因为疏忽，便有了本次被攻击的经历。好在攻方手段比较常见，而且服务器报警及时，我反应迅速，才勉强化解了本次危机。

事件全流程叙述

晚上睡前打算看一眼服务器状态，这一看不要紧，直接给我吓到。（贴出一部分，后续还有多次攻击）

好家伙，这确实是我第一次碰到这样的事情，进报警日志细看，发现服务器被异地SSH连接了，盲猜应该是被暴力破解密码。然后点进控制台…我人傻了，这还真是给硬破开的。

说实话这时候心理确实慌，毕竟第一次经历。但是慌乱中又带有一丝兴奋，瞬间燃起斗志，很快冷静下来之后，先提交了阿里紧急工单，然后开始沉下心解决。

最早的报警是说挖矿程序，我百思不得其解。我服务器一直好好的呀，哪儿来的挖矿程序，难道是我自己不小心下载了木马程序？？

我顺着控制台的日志，一路百度，终于发现了和我类似的案例。都是服务器被当成矿机入侵了，但是好端端的没有漏洞怎么会被入侵呢。我仔细回忆自己最近的操作，两天前部署了Redis…等等！好像刚刚看见了一个Redis漏洞导致的攻击事件。

回去再看一遍，发现那个兄弟遇到的情形和我高度吻合。果断直接百度 Redis 挖矿。直接打开新世界大门。

因为自己没有经验，整个处理过程都在和脚本斗智斗勇。只能说攻击者永远都会比你多想一步。当我尝试终止 Redis 服务时，我一个 Root 账户居然因为权限不足失败了。

紧接着，我尝试使用 chattr 工具进行赋权，然后戏剧性的一幕发生了，控制台提示找不到命令。

这是直接给我卸载了吗。正当我迷茫的时候，手机再次收到报警短信：系统存在蠕虫病毒代码和后门程序，我意识到应该先想办法阻断攻击者来源。但是此时密钥被对方修改，因为没有权限，修改SSH密码也一直失败。

我迅速转战控制台，通过其他验证方式重新取得 管理员权限 ，至此，一切开始慢慢得到控制，我迅速修改SSH密码，然后开始云查杀。

不得不说，“问题程序”都十分隐蔽。除去最显眼的几个文件，比较令我印象深刻的有藏匿于系统定时任务中的程序以及藏在 /tmp 文件夹下的部分文件。

但是在人工+工具双管齐下的猛烈攻势下，根据文件创建的时间进行筛选，很快筛选清理了一批脚本。然后更换Redis 默认端口，重启项目，修改防火墙。

但是一直有个ip挂在我这里，阻断也阻断不了，直接逆向一下看看是哪个混帐东西。


查到了他的网站，找到联系方式，直接发邮件警告一下！

然后直接把这个 ip 通过 iptables 全端口拉黑。

到这里整个事件基本结束，系统中可能仍然存在清理不干净的地方。其他的后续慢慢再弄。

本次解决方案总结

根本原因：Redis漏洞

先大致了解一下攻击过程：

通俗的讲，因为Redis默认使用 6379 端口。攻击者先使用扫描工具扫到开启了6379端口的服务器，然后攻击

者将自己的密钥，通过Redis替换文件机制中存在的漏洞，偷偷摸摸塞到你的服务器里，这个时候，攻击者就

已经获得了SSH连接的能力。可以对服务器开始进一步破坏。

止损方案

• 关闭服务器，防火墙立刻关闭 6379 端口。切断攻击输入源。
• 利用服务器快照进行回滚。
• 云查杀，处理可疑文件。
• 快速提交工单，获取专业人士的建议及帮助

预防方案

• 经常对服务器进行快照备份
• 更换端口，不使用默认端口，设置更复杂的密码
• 多留心 Redis 的更新日志，在漏洞被批露之后快速反应起来会减少损失。
• 开发时不再将实现功能作为第一要素，而要兼顾安全性。

主要原因：自身因素

对于云端部署的风险没有给予足够重视，对于漏洞没有引起足够重视。

总结

通过本次事件，收获了不少额外的知识，也警醒着自己未知的东西还有很多，必须时刻保持警醒，减少不必要的损失。