一次伺服器被入侵的處理經過

容器為何自動停止?

伺服器為何操作卡頓?

進程的神秘連接到底指向何處?

發現——自動停止的容器

某日發現部署在伺服器上的一個容器被停掉了，開始以為是同事誤操作停止或刪除了。

但登錄伺服器重新啟動容器的時候發現一個奇怪的現象：容器啟動後幾秒鐘便會自動停止。

一般來說這種情況可能是容器本身有問題。

但是查看容器日誌並未得到任何錯誤信息，而且該容器鏡像已在其它伺服器穩定部署運行，應該不會有bug。

所以猜測是系統資源不足，例如磁碟、內存、CPU。

查看磁碟剩餘量還比較多，但是在用top命令查看CPU和內存的時候發現了異常：某個進程CPU使用率達到了99%。

當然這種情況對於我們公司的伺服器來說也不是什麼特別驚奇的事，因為我們通常會在伺服器上執行一些計算任務，佔用大量CPU也是很正常的事情。

但由於這台伺服器除了我幾乎沒有其他同事使用，而且進程命令行看不到，所以引起了我的懷疑。

驗證——異常不止一處

挖礦進程身份確認

如此高的CPU使用率，讓我想到的是最近流行的挖礦病毒。

通過netstat -anp命令查看該進程是否建立了外部網路連接。

果然建立一個連接，指向 5.196.26.96 這個IP地址。在 https://www.ipip.net/ip.html 查詢一下該IP地址，指向國外某地。

進一步驗證了我的猜測。因為國內的伺服器有嚴格的備案管理機制，所以很多攻擊者都會將伺服器部署到國外。

為了進一步確認，再次到威脅情報平台進行查詢 https://x.threatbook.cn/ip/5.196.26.96 。

平台也給出了威脅警告，可以大膽的推定這就是一個挖礦進程。

當然如果想進一步確認，可以提取執行文件的md5值到相關網站進行辨認。

挖礦程序從哪裡來?

挖礦程序一般都是由木馬下載腳本然後執行，所以用history命令檢查一下下載行為。

沒有找到可疑的下載，很可能黑客清除了操作記錄或者是通過別的途徑下載。

為了進一步排除可能有其它病毒程序作為守護進程定時啟動或者開機啟動挖礦進程，檢查一下crontab配置信息。

也未找到新添加的可疑文件，所以黑客應該並沒有設置定時任務。

同時也未找到可疑的開機啟動項配置。

可疑的鏡像與容器

到了這一步，線索中斷。只能換個角度思考了~

據管理員說平時這台伺服器很少使用，而且使用的是強密碼，密碼泄露的可能性很小。

再結合我部署的容器停止時間進行分析，應該是在我部署完成後幾小時內伺服器被入侵的。

所以懷疑很可能和我的操作有關係。

在使用docker命令進行查找的時候又發現了新的情況。

一些容器使用了未知鏡像(heybb/theimg2)或者使用了非官方的鏡像(zoolu/ubuntu)。

上docker hub上搜索這些鏡像，都找不到Dockerfile，也無readme之類的說明。而且上傳時間都很新，但是下載量增長卻很快。

這就奇怪了，這種既無說明，命名也十分怪異的鏡像竟然會被多次下載，所以可以推斷就是黑客上傳的攜帶木馬的鏡像。

再利用docker inspect命令查看這些容器，發現該容器並沒有通過掛載目錄的方式寫入系統文件，而是會執行一個 mac.sh 的腳本文件。

用cat命令查看該文件，只有一行命令

顯然這是在挖門羅幣。

小結

現在發現不止一個黑客入侵了伺服器，有的黑客部署了挖礦容器，有的黑客部署了挖礦進程並刪除了記錄。

處理——清除進程，關閉漏洞

首要任務當然是清除挖礦進程和容器，以及對應的執行文件和鏡像。

當然這只是治標不治本的方法。

要從根本上解決問題需要進行溯源分析，避免伺服器再次被入侵。

結合以上線索以及個人經驗分析，很可能利用Docker的漏洞進行入侵的。

我在部署容器的時候啟動 Docker remote API 服務，很可能這個服務暴露到了公網上，立即在瀏覽器中輸入伺服器IP地址和對應埠，果然可以訪問!

原來伺服器運營商並沒有提供默認的防火牆服務，機器上的埠是直接暴露在公網上的。

黑客入侵的途徑也基本上可以猜測了，通過 Docker remote API 伺服器操作容器，將帶有挖礦進程的容器部署到伺服器上。

或者將挖礦程序通過目錄掛載的方式拷貝到伺服器上，以某種方式觸發並執行。

要修復這個漏洞也很簡單，停止對外暴露服務。

建議

網路安全其實是一個很重要的課題，但是開發人員很多時候都缺乏對其足夠重視。

針對這次事件，總結了幾個經驗：

除了一些 web 服務(http/https)，不要使用默認埠。

黑客的入侵操作一般都是自動化的、批量的。

操作是使用埠掃描工具，對特定的默認埠掃描。

比如本例中肯定是掃描到本伺服器的 2375 埠(2375是Docker remote API的默認埠)之後進行攻擊的。

這個原理其實有點像打電話詐騙，用一些很低級的騙術把容易受騙的人群篩選出來。

所以我們平常在編寫程序時盡量避免使用默認埠。

不要通過綁定 0.0.0.0 的方式暴露本不需要對外提供訪問的服務。

之前在啟動 Docker remote API 服務時監聽 0.0.0.0 IP，是因為看到很多網上教程都是如此配置，但其實存在了很大的安全隱患。(把事情做好和把事情做完區別真的很大!)

其實該服務在使用中並不需要提供給外網，實際上只要監聽子網IP就夠了。比如 127.0.0.1、 172.17.0.1。

儘可能多的考慮非正常情況

在開發的時候我們除了考慮程序正常的輸入輸出之外，還需要假設一些特殊的情況來進行測試。

下面是開發者和黑客的思維方式區別：

開發者：A - 程序 - B

黑客：S - 程序 - ?

開發者考慮的是保證輸入A，就可以得到B。黑客很多時候會輸入開發者未考慮的S，從而發現bug或漏洞。

使用防火牆限制埠訪問。

網路服務，防火牆很重要。

這次的入侵和雲伺服器廠商都會自帶防火牆的思維定勢有關係。

通過證書驗證訪問者的身份。

對於需要提供對外訪問的服務，使用身份驗證也是一種有效避免攻擊的手段。

例如Docker就支持TLS證書來驗證服務端和客戶端的身份。

總結

排查入侵木馬的過程很像扮演一個偵探，通過犯罪現場的蛛絲馬跡找到兇手以及行兇手法。

還好當初在發現問題的時候並沒有馬上採取重裝系統這種簡單粗暴的方式解決問題，不然漏洞依舊存在，伺服器依然會被攻擊。

關於更多更權威網路安全的知識可以參考《OWASP TOP10 2017》，裡面有最常見的10類漏洞以及防禦措施。

像本文中的Docker遠程未授權漏洞以及類似的redis未授權漏洞都屬於 OWASP TOP 10 中的漏洞。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！