起因：

公司使用的是Ucloud的云主機(jī)服務(wù)，今天上午突然被告知有一臺(tái)服務(wù)器的出口流量激增，對(duì)外發(fā)包量短時(shí)間內(nèi)達(dá)到了100萬，而且都是UDP類型的，第一感覺就是：誒呀，莫不是被黑了，被當(dāng)肉雞了呀！

探究：

立馬登錄對(duì)應(yīng)的服務(wù)器，首先使用iftop查看流量狀況

可以看出出口流量好嚇人，1分鐘內(nèi)累計(jì)700M流量，查了一下這2個(gè)IP地址，一個(gè)是在美國(guó)，一個(gè)是在浙江電信；

趕緊查看正在運(yùn)行的進(jìn)程，找出疑似進(jìn)程，還真有所發(fā)現(xiàn)：

[.ECC6DFE919A382]這個(gè)進(jìn)程還想冒充系統(tǒng)進(jìn)程，疑點(diǎn)極大，而且/tmp/freeBSD也是一個(gè)很奇怪的東西，而498這個(gè)UID對(duì)應(yīng)的用戶是elasticsearch，想起來昨天部署了Elasticsearch + Logstash，以實(shí)現(xiàn)日志統(tǒng)計(jì)系統(tǒng)，不會(huì)是ES有bug吧，繼續(xù)查看原因

懷疑/tmp/freeBSD就是被掛馬的程序，可惜已經(jīng)被刪除了，無法查看了

原因：

罪魁禍?zhǔn)撞槌鰜砹?，?xì)致的原因還需要詳查，所以現(xiàn)在最重要的就是解決問題，迅速kill掉相關(guān)進(jìn)程，再次查看iftop發(fā)現(xiàn)流量迅速回落了，更加證實(shí)了我們的判斷；

接下來就需要查找被劫持掛馬的原因和具體的劫持方式，以絕后患，而通過外部搜索引擎也是很快就定位了問題的原因，就是“Elasticsearch遠(yuǎn)程任意代碼執(zhí)行”漏洞：

• ElasticSearch有腳本執(zhí)行(scripting)的功能，可以很方便地對(duì)查詢出來的數(shù)據(jù)再加工處理； ElasticSearch用的腳本引擎是MVEL，這個(gè)引擎沒有做任何的防護(hù)，或者沙盒包裝，所以直接可以執(zhí)行任意代碼。；

• 而在ElasticSearch 1.2之前的版本里，默認(rèn)配置是打開動(dòng)態(tài)腳本功能的，因此用戶可以直接通過http請(qǐng)求，執(zhí)行任意代碼。；

• 其實(shí)官方是清楚這個(gè)漏洞的，在文檔里有說明： 

• 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.

終于找到原因，那就解決吧

解決方案：

法一：手動(dòng)關(guān)閉ES遠(yuǎn)程執(zhí)行腳本的功能，即在每一個(gè)ES節(jié)點(diǎn)的配置文件elasticsearch.yml中添加如下一行即可

script.disable_dynamic: true 

然后重啟ES即可；

法二：升級(jí)ES至1.2版本以上也可，因?yàn)樵贓S1.2版本中已默認(rèn)關(guān)閉了遠(yuǎn)程執(zhí)行腳本的功能，但需考慮與Logstash的兼容性問題；

后續(xù)：

1. 根據(jù)官方的資料，為了保證ES的安全性，不可以root身份啟動(dòng)ES，且可考慮使用代理(負(fù)載均衡器也可)，對(duì)外開放非9200端口（如9300），轉(zhuǎn)發(fā)至內(nèi)網(wǎng)的9200端口，可有效防止小人們的惡意端口掃描；

2. 因?yàn)橐呀?jīng)被掛馬了一次，所以在重新啟用ES之前，還需全面檢查被入侵的主機(jī)是否還有其它隱患，這就涉及web安全掃描的內(nèi)容了，暫時(shí)小白，還未了解，故希望有經(jīng)驗(yàn)的前輩可以多多請(qǐng)教！

博客鏈接：http://xxrenzhe.blog.51cto.com/4036116/1532469