记一次被劫持挂马经历：Elasticsearch的远程执行漏

起因：

公司使用的是Ucloud的云主机服务，今天上午突然被告知有一台服务器的出口流量激增，对外发包量短时间内达到了100万，而且都是UDP类型的，第一感觉就是：诶呀，莫不是被黑了，被当肉鸡了呀！

探究：

立马登录对应的服务器，首先使用iftop查看流量状况

可以看出出口流量好吓人，1分钟内累计700M流量，查了一下这2个IP地址，一个是在美国，一个是在浙江电信；

赶紧查看正在运行的进程，找出疑似进程，还真有所发现：

怀疑/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中添加如下一行即可

然后重启ES即可；

法二：升级ES至1.2版本以上也可，因为在ES1.2版本中已 默认关闭了远程执行脚本的功能， 但需考虑与Logstash的兼容性问题；

后续：

根据官方的资料，为了保证ES的安全性，不可以root身份启动ES，且可考虑使用代理(负载均衡器也可)，对外开放非9200端口（如9300），转发至内网的9200端口，可有效防止小人们的恶意端口扫描；

因为已经被挂马了一次，所以在重新启用ES之前，还需全面检查被入侵的主机是否还有其它隐患，这就涉及web安全扫描的内容了，暂时小白，还未了解，故希望有经验的前辈可以多多请教！