我的博客被黑客攻击了！

如果有人注意到的话，今天上午 11 点前，博客是访问不了。|| 除了我自己，有人注意到吗……？||

我本来以为是缓存的问题，就没有管。过了一会儿发现还是无法访问。于是我重启了一下服务器，但是仍然显示错误。

可能是出事了。我登录了 SSH，检查所有的服务。不过全部显示「正常运行」。

然后不知道怎么凑巧点开了 Navicat，连上了 MongoDB。突然发现所有的博客数据都被清空了，还有一个 READ__ME_TO_RECOVER_YOUR_DATA.README 数据库。数据库里面是一个比特币交易地址，大概意思是让你给钱就恢复。

** 给钱是不可能的。** 下面就讲讲我的恢复过程。

黑客是如何连接上数据库的#

首先要明白黑客是通过什么途径连接上我的数据库的，否则可能恢复的内容仍然会被覆盖。

我想起来昨天晚上，我需要用 Navicat 登录数据库修复一些迁移出错的问题。但是我平常用 MariaDB，导致我对 MongoDB 的指令几乎忘光了。

因此，我找 ChatGPT 为我生成了一堆指令，使得我可以通过一定的账户密码登录。我没有仔细看，不过粘贴进去就能够远程登录了，就没有管。

这么一想，很可能是那些指令的问题。我检查了指令的内容。一看吓一跳，ChatGPT 帮我打开了远程登录权限，关闭了防火墙。更正要的是，在数据库内 createUser() 后，它没有启动鉴权！

这就代表着任何人只要拿到了源服务器 IP 就可以远程登录数据库。还好目前站点挂在 Cloudflare 上，理论上源 IP 被隐藏了（只是理论。通过一定技术，也可以找到源 IP。|| 只要你肯找，网上也有类似的免费查询服务 ||）。

那么，黑客拿到源服务器 IP 多半是通过自动化程序暴力试出来的。

检查被删除的内容#

由于黑客自称拿到了我的数据，所以我要先检查自动化程序到底拿到了什么数据，以及是否通过漏洞留下了病毒。

由于所有的软件都是我亲自安装和配置的的，所以很容易就拿到了数据库的日志。

{"t":{"$date":"2024-07-19T03:07:24.728+08:00"},"s":"I",  "c":"NETWORK",  "id":22943,   "ctx":"listener","msg":"Connection accepted","attr":{"remote":"37.120.206.51:38104","uuid":{"uuid":{"$uuid":"20875d27-2321-452c-a717-1520dd7816f4"}},"connectionId":43,"connectionCount":27}}

{"t":{"$date":"2024-07-19T03:07:24.729+08:00"},"s":"I",  "c":"NETWORK",  "id":51800,   "ctx":"conn43","msg":"client metadata","attr":{"remote":"37.120.206.51:38104","client":"conn43","negotiatedCompressors":[],"doc":{"driver":{"name":"PyMongo","version":"4.6.1"},"os":{"type":"Linux","name":"Linux","architecture":"x86_64","version":"5.4.0-189-generic"},"platform":"CPython 3.8.10.final.0"}}}

很快就可以看到是一个罗马尼亚的 IP 第一个登录了我的数据库。使用的是 Python，暴力破解的源服务器 IP 地址。

然后就可以检查剩下的日志，看见它 drop 了一堆数据表，创建 READ__ME_TO_RECOVER_YOUR_DATA.README 后就立刻登出了，全程只花了 25 秒。

接下来居然能够看到其他 IP 的登录，也是同样的协议，出现的也是几乎相同的内容。就这样反复被覆盖后，上午 8 点，最后一个 READ__ME_TO_RECOVER_YOUR_DATA.README 被创建。估计这些服务器都是一个黑客策划的。

不过我一条条看完了日志，drop 操作后相当利索地就登出了。看起来并没有插入任何新的内容。

这也证明了文件系统和 SSH 都是安全的，那么恢复起来就很简单。

恢复数据#

首先想到了 opLog，不过根本没有启动复制集，所以直接跳过这个解决方案。

这个时候想到了准备退款的阿里云服务器。昨天晚上因为太晚了所以没有销毁，远程登录，拿到了数据库内容。可惜数据库里面的内容有些旧，缺少 7 月 18 日的日记。不过日记被同步到了 xLog 上面，也很容易恢复。

https://oimaster.top/notes/7

不过出于自己太懒，我想了想有没有其他的解决方案。这时候突然想起来 mx-space 是有自动备份系统的，每天凌晨 1:00 会自动创建全站的备份，就代表我其实有黑客访问之前的数据。通过 ssh，很容易就找到了备份文件（毕竟我没有使用 docker 等技术，所有文件都知道放在哪里了 || 不过如果使用了 docker 也没这档事 ||）。

然后上传备份文件，就解决啦！

避免再次发生#

|| 首先是追 ChatGPT。这东西很快就认错了。|| 以后问 ChatGPT 必须要检查它到底干了什么，检查代码。

我开启了防火墙，关闭了 MongoDB 的外部登录（反正数据已经迁移完了）。为了避免有自己疏忽的地方，我又去腾讯云的面板封锁了除了 80 和 22 以外的所有端口。

我也继续开启每天一次的自动数据备份。

问题就这样解决了。

如果你也有服务器……#

如果你也有一台服务器，请务必检查数据库和 SSH 是否安全，鉴权是否开启！

另外，千万不要付钱尝试恢复数据！有以下理由：

太贵了，根本付不起。
通过搜索类似的情况，发现给钱后，「黑客」并不会恢复你的数据，而是继续抬价，直到榨完你的钱包！
一晚上有多次登录的记录。就算你给了钱，恢复的也是上一个 READ__ME_TO_RECOVER_YOUR_DATA.README。
黑客那里根本没有你的数据。证明如下：
- 通过日志，自动化程序只执行了 drop 和 create，没有复制任何你的数据。
- 我有大量的数据，根据腾讯云面板，黑客只创建了几百 KB 的流量。
- 数据如果要在 drop 命令之前拷贝出来，就说明黑客要在 1 秒内完成所有的复制。然而根据我的服务器的带宽，这是不可能的。

你还要记得定时备份。只有每日备份的人才能笑得出来，平静地写一篇记录恢复过程的博客。

此文由 Mix Space 同步更新至 xLog
原始链接为 https://oimaster.top/posts/soft-engi/recu-data