公司使用的是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中新增如下一行即可

1. script.disable_dynamic: true 

然後重啟ES即可；

法二：升級ES至1.2版本以上也可，因為在ES1.2版本中已預設關閉了遠端執行指令碼的功能，但需考慮與Logstash的相容性問題；

後續：

1. 根據官方的資料，為了保證ES的安全性，不可以root身份啟動ES，且可考慮使用代理(負載均衡器也可)，對外開放非9200埠（如9300），轉發至內網的9200埠，可有效防止小人們的惡意埠掃描；

2. 因為已經被掛馬了一次，所以在重新啟用ES之前，還需全面檢查被入侵的主機是否還有其它隱患，這就涉及web安全掃描的內容了，暫時小白，還未了解，故希望有經驗的前輩可以多多請教！