數據庫失陷昨天晚上，讀者群里一位小伙伴發消息說自己的數據庫被黑了，搞安全的我自然是立刻來了興趣，加班加點開始分析起來，不知道的還以為我要熬夜等剁手節呢。

[[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) 專業的安全產品

對于企業和政府單位，還需要專業級的安全產品，比如全流量分析產品用于案件回溯，找到對方是怎么進來的，便于找出系統漏洞，及時修補。

互聯網是一個充滿了惡意的環境，別讓你的服務器在云上裸奔。