道路千萬條，安全第一條——一次服務器被入侵的處理通過

容器爲什麼自動中止？

服務器爲什麼操做卡頓？

進程的神祕鏈接到底指向何處？

發現——自動中止的容器

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

但登陸服務器從新啓動容器的時候發現一個奇怪的現象：容器啓動後幾秒鐘便會自動中止。

通常來講這種狀況多是容器自己有問題。

可是查看容器日誌並未獲得任何錯誤信息，並且該容器鏡像已在其它服務器穩定部署運行，應該不會有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.... 。

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

固然若是想進一步確認，能夠提取執行文件的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.一、 172.17.0.1。

儘量多的考慮非正常狀況

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

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

開發者：A -> 程序 -> B

黑客：S -> 程序 -> ?

開發者考慮的是保證輸入A，就能夠獲得B。黑客不少時候會輸入開發者未考慮的S，從而發現bug或漏洞。

使用防火牆限制端口訪問。

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

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

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

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

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

總結

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

還好當初在發現問題的時候並無立刻採起重裝系統這種簡單粗暴的方式解決問題，否則漏洞依舊存在，服務器依然會被攻擊。

關於更多更權威網絡安全的知識能夠參考《OWASP TOP10 2017》，裏面有最多見的10類漏洞以及防護措施。

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