这个数字，应该让你睡不着觉

先说一个让人倒吸一口凉气的数字：研究人员扫描了 2931 个暴露在外的 MySQL 数据库，发现其中 2930 个已经被勒索软件运营商盯上了。

这不是预测。不是"可能会发生"。

是确认已被锁定。

比例是多少？99.96%。

如果你还以为暴露的数据库可能没人发现、就这么安静地躺在那儿等别人不小心撞见——这个数据直接击碎了这种幻想。威胁行为者没有在等。他们早就在监视了。

六年了，这套套路还在用

让人不安的还不止这个：他们用的手法一点都不高级。不是那种传说中的零日漏洞攻击链。

本质上，这套方法从 2019 到 2020 年左右就在流传了。

具体是这样的：

• 自动化扫描暴露的数据库端口（MySQL 是 3306）
• 撞库攻击试试默认密码或者弱密码
• 数据库探测找出高价值目标
• 静默窃取数据在加密之前先把数据搬走
• 部署勒索软件而且时间线越压越紧

工具确实成熟了，自动化程度也提高了。但核心入口是什么？

配置错误。端口暴露。测试环境忘了关，还连着公网。

这不是什么国家级黑客干的事。就是大规模的扫描作业，有组织地把数据库入侵做成了一门高效的生意。

为什么暴露的数据库成了待宰的羔羊

你可能会问：既然大家都知道有这个问题，为什么数据库还是到处暴露？

答案说出来很简单：

1. 开发者图方便 —— 本地开发的时候端口全开，方便调试。上线的时候有时候就把这套配置一起打包了。

2. 云服务配置错误 —— 云主机经常一开始安全组就是"全开"状态，"先测一下再说"。

3. 测试环境被遗忘 —— 那个 2022 年的 staging 服务器？还跑着呢，还暴露着呢。

4. 根本不知道自己暴露了什么 —— 团队根本不清楚哪些东西是对着公网的。

5. 觉得"谁会来攻击我们" —— 答案是：那些不挑食的自动化 bots，管你是谁先扫了再说。

这对你的基础设施意味着什么

如果你在跑 MySQL 数据库——不管是应用数据、分析数据还是客户数据——请把暴露的实例当成已经被入侵来处理。就算你还没看到任何入侵痕迹。

攻击者的逻辑是这样的：

• 数据库一般没什么监控
• 备份可能和被黑的系统放在一起
• 公司慌了神，多半会选择直接付赎金而不是费劲恢复备份
• 检测和响应速度太慢，足够他们完成加密

说实话，很多情况下他们还真没判断错。

现在该做的事

先排查自己暴露了什么：

• 用 Shodan、Censys、BinaryEdge 这些工具查查你的 IP 是不是出现在互联网扫描库里
• 检查云服务商的安全组和网络 ACL
• 确保数据库端口绝对不允许 0.0.0.0/0 全网访问

把认证做扎实：

• 所有数据库账号都用强密码，而且要各不相同
• 能限 IP 的地方尽量限 IP
• 考虑通过 VPN 或者跳板机隧道连接，别直接暴露

检查备份策略：

• 备份存不存储在离线状态或者独立的安全区域？
• 上次成功恢复测试是什么时候？
• 有没有时间点恢复能力？

把日志和监控开起来：

• 数据库审计日志要记录连接尝试、查询、管理员操作
• 对异常访问或者批量数据导出设置告警
• 考虑用数据库审计监控（DAM）工具

大局：安全本身就是基础设施

这不只是数据库的问题。这件事提醒我们：安全必须被当成基础设施的一部分来对待，不能是事后补救。

在 NameOcean，我们反复看到同样的模式——创业公司和开发者为了赶进度、跑功能，无意中把基础设施暴露了出来。快速迭代的压力是真实的，但一次勒索事件或者数据泄露的代价，远高于一开始就把安全做对所需的工时。

你的域名商、主机服务商、DNS 配置——这些全都是入口点，都值得和你花心思保护的数据库层一样的关注。

结语：假设你正在被盯着

那 2930 个被标记的数据库不是个例。它们代表的是一种普遍现实：

如果你的数据库暴露在公网，它已经进入了某些人的视野。

这套攻击手法存在了六年，是因为它真的管用。别因为"这招我听过了"就松懈。让这种熟悉感转化为行动的动力。

排查你的暴露面。把访问权限锁死。验证你的备份。记住一句话：在当前的安全形势下，"没人知道我们"不是安全策略。

祝你安全。