记一次被劫持挂马经历--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的兼容性问题；

后续：

1. 根据官方的资料，为了保证ES的安全性，不可以root身份启动ES，且可考虑使用代理(负载均衡器也可)，对外开放非9200端口（如9300），转发至内网的9200端口，可有效防止小人们的恶意端口扫描；
2. 因为已经被挂马了一次，所以在重新启用ES之前，还需全面检查被入侵的主机是否还有其它隐患，这就涉及web安全扫描的内容了，暂时小白，还未了解，故希望有经验的前辈可以多多请教！

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