起因:
公司使用的是Ucloud的雲主機服務,今天上午突然被告知有一臺服務器的出口流量激增,對外發包量短時間內達到了100萬,而且都是UDP類型的,第一感覺就是:誒呀,莫不是被黑了,被當肉雞了呀!
探究:
立馬登錄對應的服務器,首先使用iftop查看流量狀況
可以看出出口流量好嚇人,1分鐘內累計700M流量,查了一下這2個IP地址,一個是在美國,一個是在浙江電信;
趕緊查看正在運行的進程,找出疑似進程,還真有所發現:
[.ECC6DFE919A382]這個進程還想冒充系統進程,疑點極大,而且/tmp/freeBSD也是一個很奇怪的東西,而498這個UID對應的用戶是elasticsearch,想起來昨天部署了Elasticsearch + Logstash,以實現日誌統計系統,不會是ES有bug吧,繼續查看原因
懷疑/tmp/freeBSD就是被掛馬的程序,可惜已經被刪除了,無法查看了
原因:
罪魁禍首查出來了,細緻的原因還需要詳查,所以現在最重要的就是解決問題,迅速kill掉相關進程,再次查看iftop發現流量迅速回落了,更加證實了我們的判斷;
接下來就需要查找被劫持掛馬的原因和具體的劫持方式,以絕後患,而通過外部搜索引擎也是很快就定位了問題的原因,就是“Elasticsearch遠程任意代碼執行”漏洞:
ElasticSearch有腳本執行(scripting)的功能,可以很方便地對查詢出來的數據再加工處理; ElasticSearch用的腳本引擎是MVEL,這個引擎沒有做任何的防護,或者沙盒包裝,所以直接可以執行任意代碼。;
而在ElasticSearch 1.2之前的版本里,默認配置是打開動態腳本功能的,因此用戶可以直接通過http請求,執行任意代碼。;
其實官方是清楚這個漏洞的,在文檔裏有說明:
First, you should not run Elasticsearch as the root user, as this would allow a script to access or do anything on your server, without limitations. Second, you should not expose Elasticsearch directly to users, but instead have a proxy application inbetween.
終於找到原因,那就解決吧
解決方案:
法一:手動關閉ES遠程執行腳本的功能,即在每一個ES節點的配置文件elasticsearch.yml中添加如下一行即可
script.disable_dynamic: true
然後重啓ES即可;
法二:升級ES至1.2版本以上也可,因爲在ES1.2版本中已默認關閉了遠程執行腳本的功能,但需考慮與Logstash的兼容性問題;
後續:
根據官方的資料,爲了保證ES的安全性,不可以root身份啓動ES,且可考慮使用代理(負載均衡器也可),對外開放非9200端口(如9300),轉發至內網的9200端口,可有效防止小人們的惡意端口掃描;
因爲已經被掛馬了一次,所以在重新啓用ES之前,還需全面檢查被***的主機是否還有其它隱患,這就涉及web安全掃描的內容了,暫時小白,還未了解,故希望有經驗的前輩可以多多請教!