有人通過 Redis 攻陷了我的服務器...

　　好吧，我也做了回標題黨，像我這么細心的同學，怎么可能讓服務器被入侵呢？

　　其實是這樣的，昨天我和一個朋友聊天，他說他自己有一臺云服務器運行了 Redis 數(shù)據(jù)庫，有一天突然發(fā)現(xiàn)數(shù)據(jù)庫里的數(shù)據(jù)全沒了，只剩下一個奇奇怪怪的鍵值對，值看起來像一個 RSA 公鑰的字符串，他以為是誤操作刪庫了，幸好自己的服務器里沒啥重要的數(shù)據(jù)，也就沒在意。

　　經(jīng)過一番攀談交心了解到，他跑了一個比較古老已經(jīng)停止維護的開源項目，安裝的舊版本的 Redis，而且他對 Linux 的使用不是很熟練。我就知道，他的服務器已經(jīng)被攻陷了，想到也許還會有不少像我這位朋友的人，不重視操作系統(tǒng)的權限、防火墻的設置和數(shù)據(jù)庫的保護，我就寫一篇文章簡單看看這種情況出現(xiàn)的原因，以及如何防范。

　　PS：這種手法現(xiàn)在已經(jīng)行不通了，因為新版本 Redis 都增加了 protected mode，增加了安全性，我們只能在本地簡單模擬一下，就別亂試了。

　　其實這種攻擊手法都是 2015 年的事了，那時候 Redis 的安全保護機制比較差，只能靠運維人員來合理配置以保證數(shù)據(jù)庫的安全。有段時間，全球幾萬個 Redis 節(jié)點遭到了攻擊，出現(xiàn)了上述奇怪的現(xiàn)象，所有數(shù)據(jù)被清空，只剩一個鍵叫，它的值形似 RSA 公鑰的字符串。

　　后來查證，攻擊者利用 Redis 動態(tài)設置配置和數(shù)據(jù)持久化的功能，把自己的 RSA 公鑰寫入到了被攻擊服務器的這個文件，從而可以用私鑰直接登錄對方的 root 用戶，侵入對方系統(tǒng)。

　　淪陷的服務器安全防護做的很不好，具體如下：

　　1、Redis 的端口是默認端口，而且可以從公網(wǎng)訪問。

　　2、Redis 還沒設密碼。

　　3、Redis 進程是由 root 用戶啟動的。

　　以上每個點都是比較危險的，合在一起，那真是很致命了。且不說別人把公鑰寫到你的系統(tǒng)里，就說連上你的數(shù)據(jù)庫然后刪庫，那損失都夠大了。那么具體的流程是什么呢，下面我在本地回環(huán)地址上簡單演示一下。

　　Redis 監(jiān)聽的默認端口是 6379，我們設置它接收網(wǎng)卡 127.0.0.1 的連接，這樣我從本地肯定可以連接 Redis，以此模擬「從公網(wǎng)可以訪問 Redis」這一條件。

　　現(xiàn)在我是名叫 fdl 的普通用戶，我想用 ssh 登錄我系統(tǒng)上的 root 用戶，要輸入 root 的密碼，我不知道，所以沒辦法登錄。

　　除了密碼登錄之外，還可以使用 RSA 密鑰對登錄，但是必須要把我的公鑰存到 root 的家目錄中。我們知道目錄的權限設置是不允許任何其他用戶闖入讀寫的：

　　但是，我發(fā)現(xiàn)自己竟然可以直接訪問 Redis：

　　如果 Redis 是以 root 的身份運行的，那么我就可以通過操作 Redis，讓它把我的公鑰寫到 root 的家目錄中。Redis 有一種持久化方式是生成 RDB 文件，其中會包含原始數(shù)據(jù)。

　　我露出了邪惡的微笑，先把 Redis 中的數(shù)據(jù)全部清空，然后把我的 RSA 公鑰寫到數(shù)據(jù)庫里，這里在開頭和結尾加換行符目的是避免 RDB 文件生成過程中損壞到公鑰字符串：

　　命令 Redis 把生成的數(shù)據(jù)文件保存到中的文件中：

　　現(xiàn)在，root 的家目錄中已經(jīng)包含了我們的 RSA 公鑰，我們現(xiàn)在可以通過密鑰對登錄進 root 了：

　　看一下剛才寫入 root 家的公鑰：

　　亂碼是 GDB 文件的某種編碼吧，但是中間的公鑰被完整保存了，而且 ssh 登錄程序竟然也識別了這段被亂碼包圍的公鑰！

　　至此，擁有了 root 權限，就可以為所欲為了。。。

　　雖然現(xiàn)在基本不會受到這種攻擊（新版本的 Redis 沒有密碼時默認不對外網(wǎng)開放），但是對于系統(tǒng)的安全性是每個人都應該重視的。

　　我們自己折騰東西，用個低配云服務器，為了省事兒一般也不認真配置防火墻，數(shù)據(jù)庫不設密碼或者設成 admin、root 這樣簡單的密碼，反正也沒啥數(shù)據(jù)。這樣肯定不是個好習慣。

　　現(xiàn)在我們的計算機系統(tǒng)越來越完善，每個成熟的項目都由最優(yōu)秀的一幫人維護，從技術上說應該算是無懈可擊了，那么唯一可能出問題的地方就在于使用它們的人。

　　就像經(jīng)?？吹接腥说?QQ 被盜，我相信盜號的人肯定不是跑到騰訊的數(shù)據(jù)庫里盜號，肯定是 QQ 號主安全防范意識差，在哪個釣魚網(wǎng)站輸入了自己的賬號密碼，導致被盜。我基本沒見過微信被盜的，可能是微信弱化密碼登錄，改用二維碼掃描登錄的原因。這應該也算是一種安全方面的考量吧，畢竟微信是有支付功能的。

　　上面這種騙局對于技術人來說，看看 url，瀏覽器分析一下網(wǎng)絡包就很容易識別出來，但是你還別不信，一般人真的搞不明白怎么識別釣魚網(wǎng)站和官方網(wǎng)站。就像我真沒想到都 2020 年了，還有人在找 Redis 的這個漏洞，而且還有人中招。。。

　　那么說回 Redis 數(shù)據(jù)庫的使用，在官網(wǎng)上明確寫出了安全防護的建議，我簡單總結一下吧：

　　1、不要用 root 用戶啟動 Redis Server，而且一定要設置密碼，而且密碼不要太短，否則容易被暴力破解。

　　2、配置服務器防火墻和 Redis 的 config 文件，盡量不要讓 Redis 與外界接觸。

　　3、利用 rename 功能偽裝 flushall 這種危險命令，以防被刪庫，丟失數(shù)據(jù)。

　　4、不要使用默認端口，這樣減小了外界發(fā)現(xiàn) Redis 服務的概率。

　　最后再補充一下，Linux 的用戶權限是值得重視的，一般都不用 root 用戶，而是用普通用戶啟動服務。這一點騰訊云的服務器比較好，會幫給你創(chuàng)建好一個普通用戶，默認登錄這個用戶；而阿里云的服務器是默認直接登 root，所以建議自己創(chuàng)建一個普通用戶使用。

　　以上，重視數(shù)據(jù)安全，從細節(jié)做起，希望對你有幫助。

　　歷史文章：

　　數(shù)據(jù)結構和算法學習指南

　　經(jīng)典動態(tài)規(guī)劃：打家劫舍系列問題

　　如何高效判斷回文單鏈表？