MySQL被黑的一次记录

最新推荐文章于 2024-06-10 13:07:24 发布

程序猿集锦

最新推荐文章于 2024-06-10 13:07:24 发布

阅读量770

点赞数 1

分类专栏： MySQL 文章标签：数据库 mysql 安全运维

本文链接：https://blog.csdn.net/javaanddonet/article/details/109705296

版权

36 篇文章 25 订阅

订阅专栏

微信搜索“coder-home”或扫一扫下面的二维码，关注公众号，第一时间了解更多干货分享，还有各类视频教程资源。扫描它，带走我
在这里插入图片描述

不知道大家有没有经历过MySQL数据库被黑底的情况，今天给大家分享一下我这次的经历。

昨天我们的一个同事给我们反馈说，我们的一个应用不能正常使用了，我们就去排查了一下具体的原因。最后定位到是数据库连接有问题，再进一步排查发现表都不存在了，只有一个这样的表在我们的数据库里面。

在这里插入图片描述

打开这个表之后，里面有这样下面截图中的这样的信息。
在这里插入图片描述

大概意思就是：我们的数据库被他们给攻击了，数据已经备份到他们的服务器上，要向恢复数据库需要在9天之内根据他们给出的链接和token去支付比特币。否则他们就把数据卖给其他人使用了。

我们是使用的云服务器，然后我们就赶紧通联系云服务商。我们和云服务商一起排查。

我们平时的访问是下面这样的流程。

然后我们按照如下的几个方向排查问题出现在哪里：

经过最后的层层排查最后发现以下几种可能：

MySQL服务器，除了443端口之外还对公网暴露了3306、22端口。
- 这个应是在云平台开端口的时候配置错误了，本想对内网开放，却错误操作，把端口开放到了外网。与此同时，MySQL的root密码确实比较简单，如果想暴力破解应该也很容易。
黑客通过SQL注入的方式把数据库表给删除。
- 这个可能性不是很大，因为我们扫描了我们的代码，里面的SQL都是配置在spring boot的配置文件中，没有使用${para}这方式传入参数到SQL语句中。

让我们庆幸的是，这次被攻击的环境是一个测试环境，不是真正的生产环境。另外对于这个数据我们本地都有备份。所以这个对于我们来说不太重要。

另外就是我们根据连接点击进去看到需要我们支付0.05个比特币，折合人民币大概5000元左右。后来网上也查了一下，即便是你支付了比特币，你的数据页不一定能拿回来。他们可能任务你既然支付了比特币，那么这个数据可能对你特别的重要，所以他们会进一步要求支付更多的比特币。

最后，我们没有理会这个，而是基于我们本地备份数据，重新部署我们测试环境的数据库。

既然这次被黑掉了，以后如果不提高警惕，还有可能在这个地方再栽倒一次。所以，我们最后制定了以下安全措施。

云服务器网络层面
- 服务器端口在开放的时候，一定要走审批流程，再三确定是否需要对外开放某个端口。
- 安全组定期审查。
云服务器层面
- 在服务器上登录MySQL数据库的时候，不能把密码写在命令行中，因为在history中可以看到密码。
- 服务器的登录必须需要通过跳板机才可以访问。
数据库配置层面
- MySQL的端口号，不使用3306，改为其他端口。
- MySQL的root用户名称，不再使用root，改为其他名称。
- 应用在部署的时候，连接数据库需要单独创建应用使用的账号密码，不能直接使用root这一的管理员账号连接数据库。
- 在授权的时候，禁止远程连接到MySQL服务，如果需要远程连接，则对指定IP地址进行授权
- 某一个账号在连续3次输入错误密码后，禁用该账号。
- 数据库要定时定点的备份。
- 开启数据库的审核日志功能。
- bin-log功能要开启。
数据库账号密码层面
- 密码一定要足够长、足够复杂，要包含大写字母、小写字母、特殊符号、数字四种规则。
- 如果有可能可以考虑使用base64加密后的字符串作为密码。
应用层面
- 连接MySQL数据库的账号和密码，不能使用明文的方式配置在配置文件中。需要加密后配置在配置文件中。

结束语：

后续的在给大家分享如果开启MySQL的日志审计功能、如何配置账号密码3次输入错误被禁止登录的功能等等。

敬请期待…

关注