道路千萬條，安全第一條——一次服務器安全處理經過

容器為何自動停止？

服務器為何操作卡頓？

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

發現——自動停止的容器

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

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

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

但是查看容器日志并未得到任何錯誤信息，而且該容器鏡像已在其它服務器穩定部署運行，應該不會有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 中的漏洞。