記一次被劫持掛馬經歷：Elasticsearch的遠程執行漏洞
起因：
公司使用的是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安全掃描的內容了，暫時小白，還未了解，故希望有經驗的前輩可以多多請教！
