来源 | 小白学黑客

责编 | 晋兆雨

头图 | 付费下载于视觉中国

数据库失陷

昨天晚上，读者群里一位小伙伴发消息说自己的数据库被黑了，搞安全的我自然是立刻来了兴趣，加班加点开始分析起来，不知道的还以为我要熬夜等剁手节呢。

这位小伙伴使用了某云平台搭建了一个自己的网站，昨天登录却发现了奇怪的报错：

看来是数据库出了问题，随后查看数据库，才发现粗事情了···

看来是遭勒索黑产团队盯上了，根据上面的提示信息，有两个数据库被他给下载后干掉了，分别是：kodbox、zxl。

这位小伙伴给了我账户密码，登录了上去。

用Navicat连接查看了一下，果然，这两个库中只剩下一个名字为WARNING的表，表中只有一行记录，留下了勒索者的威胁信息：

接下来，打算用SSH登录到服务器上，看看有没有什么蛛丝马迹。

首先检查了系统登录日志，并没有发现有可疑的IP登录记录。

再检查了系统用户列表，也没有发现有可疑的用户出现。

接着查看MySQL的日志，虽然这位小伙伴说没有开启binlog，但实际发现是开启的，并且日志文件也存在：

随后，在mysql-bin.000023中，找到了案发现场，使用mysqlbinlog工具查看binlog日志：

根据binlog时间戳显示，案发时间是在11月10日上午8:32-8:34分，短短两分钟之内完成的。

根据日志记录，攻击者并没有备份数据的操作，而是简单粗暴的进行了DROP操作，所以别指望乖乖听话打钱就能摆平。

接下来，准备查看一下MySQL的登录日志，看看这段时间是哪个IP和哪个用户名登录上来的。

很遗憾general日志没有开启：

再看看user表，一个神秘的admin用户出现在了这里，居然用的还是弱口令：123456

这不是等于开了一扇大门让人随意进出吗？

既然有binlog，要恢复起来还是比较容易。

其他发现

除了MySQL，在检查系统安全日志的时候，发现日志文件出奇的大：

不看不知道，一看吓一跳，里面全是来自各种IP的SSH暴力破解登录的记录，持续24小时在尝试，感觉受到了暴击：

用tail -f 命令打开的情况下，就是持续不断的在刷屏增长，可见攻势之猛烈。

幸好这位小伙伴的系统密码强度还算可以，不然早晚给打穿了。

但这持续不断的暴力登录也挺烦人的，应该让防火墙来干活了，没想到一检查防火墙竟然是关掉的状态。。。我感觉快要窒息了。

赶紧把防火墙扶起来工作，再给配一条规则，一分钟之内超过3次的SSH连接就给拒掉：

iptables -I INPUT -p tcp --dport 22 -m state --state NEW -m recent --name SSH_RECENT --rcheck --seconds 60 --hitcount 3 -j DROP

再次检查secure日志，增长的速度明显放缓了。

安全建议

这次经历表明，安全离我们并不遥远。

所幸这个小伙伴这次的数据并不重要，而且还开启了binlog，没有造成什么重要的损失。可如果没有开启呢？万一是公司项目呢？那后果就严重了。

安全这根弦还是时常要紧绷，下面是几个小建议：

• 日志记录

在业务允许的条件下，尽可能的开启详尽的日志记录，以便在案发后溯源追踪。包括但不限于操作系统日志、审计日志、Web访问日志、数据库连接登录日志、数据操作日志等等。

• 数据备份

定时进行关键数据的备份存储，遇到勒索加密也能从容应对。

• 密码强度

不要用弱口令，数字、字母大小写、特殊符号一起上，一个好的密码可以帮你抗住一大半的攻击可能。

• 定期修改密码

就算用上了高强度密码，也不是一劳永逸，除了技术攻击，还有社会工程学，一个密码走遍天下风险极高，时不时修改密码也是非常有必要的。

• 防火墙

防火墙的重要性就不必多说了，用好防火墙，将绝大多数攻击者拒之门外。

• 专业的安全产品

对于企业和政府单位，还需要专业级的安全产品，比如全流量分析产品用于案件回溯，找到对方是怎么进来的，便于找出系统漏洞，及时修补。

互联网是一个充满了恶意的环境，别让你的服务器在云上裸奔~

更多阅读推荐

• 如何在SQL Server 2019中添加数据敏感度分类的命令

• 深度揭秘：腾讯存储技术发展史

• 一文教你如何在生产环境中在Kubernetes上部署Jaeger

• 如何在SQL Server 2019中添加数据敏感度分类的命令

• 一周内咸鱼疯转 2.4W 次，最终被所有大厂封杀！