起因:
公司使用的是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安全扫描的内容了,暂时小白,还未了解,故希望有经验的前辈可以多多请教!
转载于:https://blog.51cto.com/xxrenzhe/1532469