更早的呼声：不在公共网络中暴露集群
在ElasticSearch服务器集群收到攻击的当天，搜索及大数据专家Itamar Syn-Hershko便撰文
“抵抗被洗劫：妥善保护您的Elasticsearch集群”详细支招怎样对抗此次劫持，Itamar是以色列的独立咨询师，他的公司code972是Elastics公司的合作伙伴。
http://code972.com/blog/2017/01/107-dont-be-ransacked-securing-your-elasticsearch-cluster-properly
Itamar 强烈呼吁：
无论如何，请千万不要让您的集群节点暴露在网络当中。 虽然这听起来像是废话，但事实上用户们往往并没有切实遵循这项最佳实践。 您永远不应将自己的集群暴露在公共网络当中。
Itamar 对七条推荐实践进行了分析，探讨确保集群安全的“该”与“不该”作法。以下为其文章的翻译：
1、启用HTTP的节点应该仅监听私有IP
Elasticsearch可通过配置限定其所监听的IP，而大家可以控制作为其合法监听对象的本地主机、私有IP、公共IP或者这几类对象的组合。在现实使用中，我们没有任何理由yhElasticsearch监听公共IP或者可公开访问的DNS名称。
这项设置被称为network.bind_host或者简写为network.host，而大家应始终将其设定为仅适用于私有IP（在某些例外情况下，亦可加入某些本地主机）。
让我们再次重申：network.bind_host应当始终被设定为私有网络接口，而永远不可被设定为公共IP或者DNS。
这将影响到HTTP访问与本地Java客户端访问。在某些用例中，我们可能需要实现某客户端节点的公开访问，具体解决办法如下。
2、使用代理实现客户端通信
作为一类常见误区，人们通常表示“嘿，Elsticsearch属于REST over HTTP，我们直接通过智能HTML客户端进行访问即可。”事实上，这种作法极不可取。
如果大家的单页面应用需要查询Elastic并获取JSON作为显示内容，那么将通过具备过滤、审计记录以及最重要的数据密码保护功能的软件代理加以实现。
如果不这样做，那么我们很可能面临以下三种后果：（1）您将其明确绑定至某公共IP，这种作法非常危险; （2）导致数据面临意外修改的风险; （3）最糟糕的是，您无法控制谁在对哪些数据进行访问，而且全部数据皆可供外部查看。而本次出现的Elasticsearch集群劫持事件正是引发了这种情况。
另外，也不要暴露您的文件与索引结构，亦不可对您的瘦客户端同为其提供数据的数据存储系统进行耦合。您的客户端JavaScript绝对不应与Elastic DSL直接通信。
您的客户端应该与服务器端软件进行通信，并由后者将全部客户端请求转发至Elasticsearch DSL、执行查询、而后有选择地将来自Elasticsearch的响应结果返回至客户端。另外，在对Elasticsearch进行任何访问之前，您的服务器端应用显然应验证用户登录凭证，从而确保其身份及授权符合操作数据的相关要求。如若不然，您的集群很可能陷入风险，并直接导致数据为贪婪的攻击者所获取。
3、如果可能，将Elasticsearch运行在隔离网络当中
即使是在您的内部网络中，也请尽可能将集群隔离于其它系统部分之外。举例来说，一部分客户会将其集群部署在AWS之上，我建议大家将此类集群运行在VPC中，而后再为其设置两个独立安全组——其一面向整体集群，其二面向其中单一客户端节点，且该节点仅与要求访问集群的应用进行共享。
4、不要使用默认端口
再有，请不要使用默认端口——算是我有些多疑吧，但小心一点总是没错的。
默认端口的变更方式非常简单，感兴趣的朋友可以点击此处查看设置过程（英文原文）。
5、在不需要时禁用HTTP
Elasticsearch最好是被部署在服务器组当中，其中每台服务器充当单一角色——例如主节点、数据节点以及客户端节点。感兴趣的朋友可以点击此处查看官方说明文档中的相关内容（英文原文）。
请确保只在您的客户端节点上启用HTTP，且仅允许您的应用（来自私有网络之内）对其加以访问。在客户端节点上启用HTTP亦适用于全部集群通信皆立足 TCP端口（默认为9300）完成的JVM类系统，这是因为：（1）大家仍然需要开放HTTP端点以实现调试与维护; （2）长期运行的Java客户端也将迁移至HTTP。
感兴趣的朋友可以点击此处了解如何轻松禁用HTTP（英文原文）。
6、保护公共可用的客户端节点
在某些情况下，客户端节点需要公共可用以支持Kibana及Kopf等UI。虽然我仍然建议大家将这些节点部署在私有网络之后并仅允许通过VPN进行连接，但有时候VPN确实不易设置，而最方便快捷的作法无法是将Kibana实例直接部署在公开节点之上——这会同时导致整套集群暴露在互联网当中。
如果大家能够利用VPN保护自己的客户端Kibana、Kopf及其它节点（即借此将其仅绑定至私有IP），那么请务必采取这种方法。
如若不然，大家可以通过引入代理的方式实现保护。作为起点，大家可以点击此处了解如何利用简单的示例nginx配置文件建立密码保护代理以掩护您的客户端节点。此示例中包含Kibana、Kopf（静态）与实际Elasticsearch访问。
大家也可以利用Elastic的Shield或者SearchGuard等插件保护自己的集群并控制一切经由客户端节点的访问活动。
如果大家不得不选择通过公共网络访问节点，请确保利用HTTPS对其进行保护，同时禁止一切以明文方式传输数据及凭证的作法。再次强调，Shield与SearchGuard等nginx与Elasticsearch插件能够帮助大家轻松实现这一效果。
7、禁用脚本（2.x之前版本）
在Elasticsearch 2.x之前的版本中，其由于启用了多种非沙箱语言（mvel、groovy）的动态脚本功能而存在安全隐患。如果大家使用的集群部署有1.x或者0.x版本，请尽快进行升级。或者，至少应当禁用其动态脚本功能。
如果大家使用Elasticsearch 2.x版本，则应变更您的默认脚本语言并移除groovy（此语言不支持沙箱功能，且为默认语言）。
我个人发现，很多集群都是由通过Search API向Elasticsearch发送恶意脚本的方式遭遇入侵的。
发表评论