摘要：為了進一步確認，再次到威脅情報平臺進行查詢。再結(jié)合我部署的容器停止時間進行分析，應(yīng)該是在我部署完成后幾小時內(nèi)服務(wù)器被入侵的。要從根本上解決問題需要進行溯源分析，避免服務(wù)器再次被入侵。結(jié)合以上線索以及個人經(jīng)驗分析，很可能利用的漏洞進行入侵的。

容器為何自動停止？

服務(wù)器為何操作卡頓？

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

某日發(fā)現(xiàn)部署在服務(wù)器上的一個容器被停掉了，開始以為是同事誤操作停止或刪除了。

但登錄服務(wù)器重新啟動容器的時候發(fā)現(xiàn)一個奇怪的現(xiàn)象：容器啟動后幾秒鐘便會自動停止。

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

但是查看容器日志并未得到任何錯誤信息，而且該容器鏡像已在其它服務(wù)器穩(wěn)定部署運行，應(yīng)該不會有bug。

所以猜測是系統(tǒng)資源不足，例如磁盤、內(nèi)存、CPU。

查看磁盤剩余量還比較多，但是在用top命令查看CPU和內(nèi)存的時候發(fā)現(xiàn)了異常：某個進程CPU使用率達到了99%。

當(dāng)然這種情況對于我們公司的服務(wù)器來說也不是什么特別驚奇的事，因為我們通常會在服務(wù)器上執(zhí)行一些計算任務(wù)，占用大量CPU也是很正常的事情。

但由于這臺服務(wù)器除了我?guī)缀鯖]有其他同事使用，而且進程命令行看不到，所以引起了我的懷疑。

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

通過netstat -anp命令查看該進程是否建立了外部網(wǎng)絡(luò)連接。

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

進一步驗證了我的猜測。因為國內(nèi)的服務(wù)器有嚴(yán)格的備案管理機制，所以很多攻擊者都會將服務(wù)器部署到國外。

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

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

當(dāng)然如果想進一步確認，可以提取執(zhí)行文件的md5值到相關(guān)網(wǎng)站進行辨認。

挖礦程序從哪里來？

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

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

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

也未找到新添加的可疑文件，所以黑客應(yīng)該并沒有設(shè)置定時任務(wù)。

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

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

據(jù)管理員說平時這臺服務(wù)器很少使用，而且使用的是強密碼，密碼泄露的可能性很小。

再結(jié)合我部署的容器停止時間進行分析，應(yīng)該是在我部署完成后幾小時內(nèi)服務(wù)器被入侵的。

所以懷疑很可能和我的操作有關(guān)系。

在使用docker命令進行查找的時候又發(fā)現(xiàn)了新的情況。

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

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

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

再利用docker inspect命令查看這些容器，發(fā)現(xiàn)該容器并沒有通過掛載目錄的方式寫入系統(tǒng)文件，而是會執(zhí)行一個 mac.sh 的腳本文件。

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

顯然這是在挖門羅幣。

現(xiàn)在發(fā)現(xiàn)不止一個黑客入侵了服務(wù)器，有的黑客部署了挖礦容器，有的黑客部署了挖礦進程并刪除了記錄。

首要任務(wù)當(dāng)然是清除挖礦進程和容器，以及對應(yīng)的執(zhí)行文件和鏡像。

當(dāng)然這只是治標(biāo)不治本的方法。

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

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

我在部署容器的時候啟動 Docker remote API 服務(wù)，很可能這個服務(wù)暴露到了公網(wǎng)上，立即在瀏覽器中輸入服務(wù)器IP地址和對應(yīng)端口，果然可以訪問！

原來服務(wù)器運營商并沒有提供默認的防火墻服務(wù)，機器上的端口是直接暴露在公網(wǎng)上的。

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

或者將挖礦程序通過目錄掛載的方式拷貝到服務(wù)器上，以某種方式觸發(fā)并執(zhí)行。

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

網(wǎng)絡(luò)安全其實是一個很重要的課題，但是開發(fā)人員很多時候都缺乏對其足夠重視。

針對這次事件，總結(jié)了幾個經(jīng)驗：

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

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

比如本例中肯定是掃描到本服務(wù)器的 2375 端口（2375是Docker remote API的默認端口）之后進行攻擊的。

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

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

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

其實該服務(wù)在使用中并不需要提供給外網(wǎng)，實際上只要監(jiān)聽子網(wǎng)IP就夠了。比如 127.0.0.1、 172.17.0.1。

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

下面是開發(fā)者和黑客的思維方式區(qū)別：

開發(fā)者：A -> 程序 -> B

黑客：S -> 程序 -> ?

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

網(wǎng)絡(luò)服務(wù)，防火墻很重要。

這次的入侵和云服務(wù)器廠商都會自帶防火墻的思維定勢有關(guān)系。

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

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

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

還好當(dāng)初在發(fā)現(xiàn)問題的時候并沒有馬上采取重裝系統(tǒng)這種簡單粗暴的方式解決問題，不然漏洞依舊存在，服務(wù)器依然會被攻擊。

關(guān)于更多更權(quán)威網(wǎng)絡(luò)安全的知識可以參考《OWASP TOP10 2017》，里面有最常見的10類漏洞以及防御措施。

像本文中的Docker遠程未授權(quán)漏洞以及類似的redis未授權(quán)漏洞都屬于 OWASP TOP 10 中的漏洞。