簡單來講，就是我們的機器被用來挖礦了…

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

具體原因排查

iptables為空

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

kubelet裸奔

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

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

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

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

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

然后文件中禁止匿名訪問的配置沒有讀取

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

改進方案

其實該問題理論上講是可以避免的，是因為出現(xiàn)了多層漏洞才會被有心人掃到，我從外到內(nèi)整理了一下可能改進的策略。

1. 機器防火墻設(shè)置，機器防火墻是整個系統(tǒng)最外層，即使機器的防火墻同步失敗，也不能默認(rèn)開放所有端口，而是應(yīng)該全部關(guān)閉，等待管理員連接到tty終端上檢查。
2. 使用機器時，假如機器不是暴露給外部使用的，公網(wǎng)IP可有可無的時候，盡量不要有公網(wǎng)IP，我們的機器才上線1天就被掃描到了漏洞，可想而知，公網(wǎng)上是多么的危險
3. 使用kubelet以及其他系統(tǒng)服務(wù)時，端口監(jiān)聽方面是不是該有所考量？能不能不監(jiān)聽?0.0.0.0，而是只監(jiān)聽本機的內(nèi)網(wǎng)IP。
4. 使用kubelet以及其他程序，設(shè)計或是搭建系統(tǒng)時, 對于匿名訪問時的權(quán)限控制, 我們需要考慮到假如端口匿名會出現(xiàn)什么問題，是否應(yīng)該允許匿名訪問，如果不允許匿名訪問，那么怎么做一套鑒權(quán)系統(tǒng)?
5. 系統(tǒng)管理員操作時，是否有一個比較規(guī)范化的流程，是不是該只使用腳本操作線上環(huán)境? 手動操作線上環(huán)境帶來的問題并不好排查和定位。
   我這里不是拋出疑問，只是想告訴大家，考慮系統(tǒng)設(shè)計時，有必要考慮下安全性。

總結(jié)

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