Elasticsearch成挟持新目标，专家迅速回应支招使用者

2023-12-03 13:44:58

译者 | 核子可乐

编辑 | 木环

MongoDB事件之后，再起波澜

经过在MongoDB各服务器间长达数日的肆虐，一群恶意分子又开始将其劫持矛头指向Elasticsearch服务器，并要求受害者支付类似的赎金。

第一波针对Elasticsearch服务器所有者的打击发生于1月12日，其中部分受害者通过Elasticsearch论坛反映了相关情况。

与此前曾经出现的MongDB劫持活动类似，如今新一波指向Elasticsearch集群的恶意***再次袭来。目前全球各地的Elasticsearch集群正受到大范围劫持，其中仅留下一条与赎金要求相关的索引定义，具体如下所示：

根据已经报告的勒索说明，***活动似乎全部源自同一***组织，名为P1l4tos。留言中写明：

如果希望恢复你的数据库，向以下钱包中发送0.2比特币：1DAsGY4Kt1a4LCTPMH5vm5PqX32eZmot4r！在比特币发送完成后，向p1l4t0s@sigaint.org邮箱发送你的服务器IP。

截至撰稿之时，以上列出的比特币地址仅收到一笔赎金款项。

Elasticsearch劫持事件更多细节（一）已有超过800台服务器遭受劫持

作为持续关注此前MongoDB***活动的安全研究人员之一，Niall Merrigan已经开始追踪本轮Elasticsearch***活动。截至本文撰稿时，Merrigan在twitter上的最新报告称已经有超过800台服务器遭受劫持。

Elasticsearch是一套基于Java的搜索引擎，主要用于在各类大型Web服务及企业网络当中进行信息检索。据称，***者利用低强度、易猜出的密码对暴露在互联网当中的各Elasticsearch服务器发起***。

（二）仍有约35000台Elasticsearch服务器在线运行

根据Shodan查询结果显示，目前仍有约35000个Elasticsearch实例可通过互联网进行接入。2015年8月，来自BinaryEdge公司的安全专家们发现当时在线运行的Elasticsearch实例仅为8990个，而其时个中包含的信息总量为531199 TB。

（三）安全界早有预警

2015年12月，AlienVault通过实验发现，***者能够利用两项不同的安全漏洞对Elasticsearch服务器进行劫持，并将其添加至僵尸网络当中。

MongoDB也有相同的境遇，在MongoDB事件发生前，其实业界已经告知很多MongoDB数据库处于令人不安的开放状态。2015年12月，Shodan经过调查之后发现当时互联网上共有至少35,000个可公开访问，无须身份验证的MongoDB实例。（悲伤的是，一年多之后，开放式MongoDB数据库的数量不降反增，估计共有多达99,000个数据库有被劫持风险。）

（四）技术反思 and“一语成谶”

随着此前针对MongoDB服务器之***活动的出现，业内人士考虑其需要花费多长时间才会将恶意矛头指向其它技术方案。

Bleeping Computer的安全观察员Catalin Cimpanu曾经在2017年1月9日公开表示其担忧：

我在考虑这些MongoDB劫持者需要多长时间来发现其它互联网可访问目标，包括Redis、CouchDB以及Elasticsearch服务器。

问题的答案是三天。

其它可能的潜在***目标还包括Apache CouchDB、Redis以及Memcached，其皆可通过互联网轻松访问且在安全水平上甚至不及MongoDB。

Elastic官方：正确配置，可防数据丢失

ES的劫持事件发生第二天，2017年1月13日，Elastic公司撰写了一篇博客“保护您的数据免受勒索***侵扰”。文中表示此次事件对Elastic Cloud的客户影响甚微，其中安全产品X-Pack 会随机分配彼此独立密码的配合。而对于其他用户，Elastic公司不建议将Elasticsearch实例暴露在互联网中；对于已有的非安全且面向互联网的Elasticsearch，Elastic公司同样给出了六条建议。附文章地址为：https://www.elastic.co/blog/protecting-against-attacks-that-hold-your-data-for-ransom。下面为全文译文：

上周末，一轮恶意***的大规模来袭导致数千台开源数据库中的数据遭遇复制、删除及勒索性加密等严重问题。尽管上述***活动中并未使用任何恶意软件或者“勒索软件”，且与产品安全漏洞并无关联，但最终仍然造成了严重的数据丢失甚至数据泄露安全事故。不过好消息是，我们完全可以通过正确配置轻松防止类似***行为造成的数据丢失后果。因此，让我们以此为鉴高度关注Elasticsearch实例的安全保护工作，特别是保护那些可通过互联网加以接入的实例。

选择使用Elastic Cloud的客户可以放心，其使用随机分配的彼此独立密码配合X-Pack安全产品对集群加以保护。客户为这些集群选择对应的AWS服务区，而集群本身亦被部署在冗余防火墙及代理之后。默认配置提供来自互联网的加密TLS通信内容，且Elastic每七天对集群数据进行一次备份。

对于其它部署选项，我们强烈建议大家确保那些可能存在安全问题的Elasticsearch实例不会直接暴露在互联网当中。具体请参阅我们2013年发布的博文。我们还将相关建议以localhost内默认安装绑定的形式加以实施。尽管如此，面对各类互联网可访问实例，我们已经意识到其中存在的安全隐患。

如果大家拥有一套非安全且面向互联网的Elasticsearch实例，那么我们强烈建议您立即采取以下措施以保护您的数据：

对全部数据备份至安全位置，并考虑使用Curator快照。

对您的环境进行重新配置，从而将Elasticsearch运行一套隔离型不可路由网络当中。

如果您必须通过互联网访问对应集群，请通过防火墙、***、反向代理或者其它技术手段限制来自互联网的集群访问请求。

而作为最佳实践原则，我们始终建议您：

升级至Elastic Stack的最新版本。

如果您运行的是v2.x版本，请检查您的scripting设置; 在新的v5.x版本中则请检查Painless脚本设置。

利用X-Pack安全工具添加TLS加密、验证、授权以及IP过滤等功能，从而保护您的Elasticsearch实例。

专家对策：不在公共网络中暴露集群

在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最好是被部署在服务器组当中，其中每台服务器充当单一角色——例如主节点、数据节点以及客户端节点。感兴趣的朋友可以查看官方说明文档中的相关内容（链接：https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-node.html）。

请确保只在您的客户端节点上启用HTTP，且仅允许您的应用（来自私有网络之内）对其加以访问。在客户端节点上启用HTTP亦适用于全部集群通信皆立足 TCP端口（默认为9300）完成的JVM类系统，这是因为：（1）大家仍然需要开放HTTP端点以实现调试与维护; （2）长期运行的Java客户端也将迁移至HTTP。感兴趣的朋友可以点击此处了解如何轻松禁用HTTP（英文原文）。

6、保护公共可用的客户端节点

在某些情况下，客户端节点需要公共可用以支持Kibana及Kopf等UI。虽然我仍然建议大家将这些节点部署在私有网络之后并仅允许通过***进行连接，但有时候***确实不易设置，而最方便快捷的作法无法是将Kibana实例直接部署在公开节点之上——这会同时导致整套集群暴露在互联网当中。

如果大家能够利用***保护自己的客户端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发送恶意脚本的方式遭遇***的。

在Itamar看来：Elasticsearch目前已经被广泛应用于从日志记录到搜索在内的各类敏感文件用例当中。无论如何，存储在Elasticsearch上的数据实际上相当安全，即很难被恶意人士所窃取。正因为如此，大家不应自寻烦恼。请确保您的集群深深隐藏在私有网络当中，且仅接受来自您自有应用的访问。禁用各类您不需要的功能，且尽可能隐藏您的设置（例如默认端口）、您的数据结构甚至是您正在使用Elasticsearch这一事实。最后，我将继续密切关注这场安全危机的发展情况，并根据事态随时为大家带来更多新消息。

不过，还有大神可以求助吗？

除了Elastic公司和安全专家Itamar给开出的普适良方，如果你还有问题怎么办呢？或许可以求助一位行侠仗义的Hacker， Victor Gevers堪称一位Hacker道德模范，从1998年起，他负责捉住了5211个安全漏洞。他所在的GDI Foundation公司是一个非盈利组织，公司的使命是让免费公开的互联网更安全，这家不足十人的荷兰公司致力于发掘安全漏洞。

在此前对MongoDB事件的文章报道中，高效开发运维公众号的一位技术粉丝bill0 Ng强烈建议对“***”和“骇客”两次进行区分并称：