我的博客被黑客攻擊了！

如果有人注意到的話，今天上午 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