数据库失陷昨天晚上，读者群里一位小伙伴发消息说自己的数据库被黑了，搞安全的我自然是立刻来了兴趣，加班加点开始分析起来，不知道的还以为我要熬夜等剁手节呢。
[[351807]]
这位小伙伴使用了某云平台搭建了一个自己的网站，昨天登录却发现了奇怪的报错：
看来是数据库出了问题，随后查看数据库，才发现粗事情了···
看来是遭勒索黑产团队盯上了，根据上面的提示信息，有两个数据库被他给下载后干掉了，分别是：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
这不是等于开了一扇大门让人随意进出吗?
[[351808]]
既然有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，没有造成什么重要的损失。可如果没有开启呢?万一是公司项目呢?那后果就严重了。
安全这根弦还是时常要紧绷，下面是几个小建议：
(1) 日志记录
在业务允许的条件下，尽可能的开启详尽的日志记录，以便在案发后溯源追踪。包括但不限于操作系统日志、审计日志、Web访问日志、数据库连接登录日志、数据操作日志等等。
(2) 数据备份
定时进行关键数据的备份存储，遇到勒索加密也能从容应对。
(3) 密码强度
不要用弱口令，数字、字母大小写、特殊符号一起上，一个好的密码可以帮你抗住一大半的攻击可能。
(4) 定期修改密码
就算用上了高强度密码，也不是一劳永逸，除了技术攻击，还有社会工程学，一个密码走遍天下风险极高，时不时修改密码也是非常有必要的。
(5) 防火墙
防火墙的重要性就不必多说了，用好防火墙，将绝大多数攻击者拒之门外。
(6) 专业的安全产品
对于企业和政府单位，还需要专业级的安全产品，比如全流量分析产品用于案件回溯，找到对方是怎么进来的，便于找出系统漏洞，及时修补。
互联网是一个充满了恶意的环境，别让你的服务器在云上裸奔。
文章来源网络，作者：运维，如若转载，请注明出处：https://shuyeidc.com/wp/127932.html<
