不久前,众多MongoDB实例成为了骇客们取乐的牺牲品。转眼之间,这些无(ling)孔(ren)不(tong)入(hen)的骇客又把目标锁定在了Elasticsearch,今天小编带来的就是360DBA团队分享的Elasticsearch安全策略,希望可以帮助到大家。

背景

不久前,众多MongoDB实例成为了骇客们取乐的牺牲品。转眼之间,这些无(ling)孔(ren)不(tong)入(hen)的骇客又把目标锁定在了Elasticsearch。说来也难怪,谁让Elasticsearch设计之初就定位在纯私网环境而不做权限和安全控制呢(这么说其实有些绝对,毕竟还有个叫Security Manager的东东嘛)。不过话又说回来,人家确实专门出了个收费的Shield来保护你,可是你不买账啊!(难怪骇客如此猖獗???!!!怎么感觉满满的都是套路啊,难道……)。

咳咳,跑远啦,咱回来接着唠。

如果说“如何保证Elasticsearch的安全”已成为大家年夜饭之前最大的心结,个人觉得并不为过了吧。幸好我们在决定使用Elasticsearch之前就提前预见到了这个问题,并做了相关工作来保证Elasticsearch的安全。下面就把一些干货分享给大家,希望能给大家提供一些借鉴和帮助。

安全策略

网络层

除却“内鬼”的因素,骇客的攻击基本都是通过外部网络,所以这里是保障Elasticsearch安全的第一道屏障。相信大家都有自己的网络安全策略,硬件防火墙也好,软件防火墙也罢,按照自己的需求做好设置和维护即可。可是如果没有的话,那对不起,“蓬门今始为君开”,骇客岂有不光顾的道理。

OS层

卸载公网IP

如果说网络屏障给大家圈起了“院墙”,那我们服务器上的公网IP就像是搭在后院墙上的“梯子”。虽然有了围墙,却也难保不会有顺梯翻墙的“梁上君子”。所以如果大家的Elasticsearch都在内网环境使用,尽量卸载掉没有使用的公网IP吧,腾出网卡做更多有意义的事情。

普通用户启动

之前已经不止一次的曝出Linux下各种ROOT提权的问题,所以还是建议使用非ROOT用户启动Elasticsearch吧,并且相关数据目录的权限和属主一并改为非ROOT用户。就像是把你家金库托管给你最信任的人一样。

Server层

替换默认端口

众所周知,Elasticsearch默认的http.port是9200,集群各节点间的通信端口transport.tcp.port是9300;这就像是你家金库的大门,如果一眼就能辨识,那骇客攻击就可以在最短的时间做到有的放矢。

所以强烈建议替换掉Elasticsearch的监控端口,就像是给你家金库做了个“暗门”,骇客想要进入金库至少先得找到门路才行。

用户及权限认证

如果说Elasticsearch是一个存放着宝贝,时刻受到“梁上君子”觊觎的保险柜,那么没有开启权限认证的Elasticsearch就像是没有密码锁一样,只要找到了这个保险柜,那里面的宝贝就可以任之取之了。所以要避免骇客入侵的最有力的手段,也是最后一层屏障,那就是用户及权限认证。

可是在开题我们就说到了,Elasticsearch本身没有用户及权限认证体系。

虽然官方提供了自己的权限管理系统—— Shield, 但是它——收费! (小编不自觉的竖起了中指)

本着“能免费用,绝不花钱买”的持家宗旨,在这里给大家介绍一款实用的开源Elasticsearch权限管理系统——Search Guard

先来看看Search Guard都支持哪些功能及特性:(请原谅小编是个截图党)

接下来就大家最关心的问题简单总结一下(这里只翻译一下免费版提供的功能)

  1. Search Guard支持Transport Layer(Node-to-node)和REST Layer(HTTP/HTTPS)的SSL/TLS加密传输,并且Transport Layer和REST Layer都可以单独配置是否开启SSL/TLS加密。

  2. Search Guard提供了一套完整的“用户-角色-权限”控制系统。免费版权限可以控制到indice/type、host级别。

  3. 如果需要Document level security(DLS)和Field level security(FLS)级别的权限控制,或者Audit logging审计功能,或者需要支持如LDAP、Kerberos等第三方用户认证系统的话,那就乖乖购买Enterprise License吧(每个集群一个License,无所谓集群规模)。

  4. Search Guard权限可以动态配置,我们可以把需要的权限添加到对应的文件,这些文件都作为文档存储在Elasticsearch中的searchguard索引中,然后通过sgadmin工具来更新配置(即将文件加载到ES),加载后立即生效,无需重启ES节点。

  5. Search Guard 以插件的形式发布,它要提供服务需要依赖Search Guard SSL。在Elasticsearch 5.x之前需要单独安装Search Guard和Search Guard SSL;Elasticsearch 5.x之后,Search Guard默认已经集成了对应版本的Search Guard SSL,无需单独安装了。

补充一点,Search Guard可以实现和Logstash、Kibana的完美结合,对于使用ELK的用户大可不必担心,修改集成很容易的。

并且,Elasticsearch在5.x之后,对Search Guard、Search Guard SSL (当然还有Logstash 、Kibana)等插件的版本号都做了统一,变得更加的简单直观了。

总结

以上是我们在部署Elasticsearch时所作的一些安全策略,把这些分享出来希望可以帮助到大家。有一些策略其实很简单,可往往越是细小的点,越容易被大家忽略,越容易成为日后维护的坑。

关于Search Guard的安装配置维护,我们后续会推出一个小的系列专门介绍,绝对干货,敬请期待!

声明:本文来自HULK一线技术杂谈,版权归作者所有。文章内容仅代表作者独立观点,不代表安全内参立场,转载目的在于传递更多信息。如有侵权,请联系 anquanneican@163.com。