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

容器為何自動停止？

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

進(jìn)程的神秘連接到底指向何處？

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

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

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

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

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

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

當(dāng)然這種情況對于我們公司的服務(wù)器來說也不是什么特別驚奇的事，因?yàn)槲覀兺ǔ诜?wù)器上執(zhí)行一些計(jì)算任務(wù)，占用大量CPU也是很正常的事情。

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

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

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

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

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

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

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

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

挖礦程序從哪里來？

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

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

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

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

同時也未找到可疑的開機(jī)啟動項(xiàng)配置。

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

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

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

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

在使用docker命令進(jìn)行查找的時候又發(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ù)器，有的黑客部署了挖礦容器，有的黑客部署了挖礦進(jìn)程并刪除了記錄。

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

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

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

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

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

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

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

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

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

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

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

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

操作是使用端口掃描工具，對特定的默認(rèn)端口掃描。

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

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

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

之前在啟動 Docker remote API 服務(wù)時監(jiān)聽 0.0.0.0 IP，是因?yàn)榭吹胶芏嗑W(wǎng)上教程都是如此配置，但其實(shí)存在了很大的安全隱患。（把事情做好和把事情做完區(qū)別真的很大！）

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

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

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

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

黑客：S -> 程序 -> ?

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

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

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

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

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

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

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

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

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