MongoDB、Elasticsearch遭大范围劫持，如何才能让服务器免于灾难？

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 运行一套隔离型不可路由网络当中。
• 如果您必须通过互联网访问对应集群，请通过防火墙、VPN、反向代理或者其它技术手段限制来自互联网的集群访问请求。
• 而作为最佳实践原则，我们始终建议您：
• 升级至 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 最好是被部署在服务器组当中，其中每台服务器充当单一角色——例如主节点、数据节点以及客户端节点。感兴趣的朋友可以点击此处查看官方说明文档中的相关内容（英文原文）。

请确保只在您的客户端节点上启用 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 发送恶意脚本的方式遭遇入侵的。

在 Itamar 看来：Elasticsearch 目前已经被广泛应用于从日志记录到搜索在内的各类敏感文件用例当中。无论如何，存储在 Elasticsearch 上的数据实际上相当安全，即很难被恶意人士所窃取。

正因为如此，大家不应自寻烦恼。请确保您的集群深深隐藏在私有网络当中，且仅接受来自您自有应用的访问。

禁用各类您不需要的功能，且尽可能隐藏您的设置（例如默认端口）、您的数据结构甚至是您正在使用 Elasticsearch 这一事实。

最后，我将继续密切关注这场安全危机的发展情况，并根据事态随时为大家带来更多新消息。

如果还有问题，还有大神可以求助吗？

除了 Elastic 公司和安全专家 Itamar 给开出的普适良方，如果你还有问题怎么办呢？

或许可以求助一位行侠仗义的 Hacker， Victor Gevers 堪称一位 Hacker 道德模范，从 1998 年起，他负责捉住了 5211 个安全漏洞。他所在的 GDI Foundation 公司是一个非盈利组织，公司的使命是让免费公开的互联网更安全，这家不足十人的荷兰公司致力于发掘安全漏洞。

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

黑客 hacker：具有开拓者精神的人，勇于实践；

骇客 cracker：搞破坏的人。

两类人共性是技术高超，但是出发点是不同的。上面所说的 Victor 和他的同事们当属正义的 Hacker。而发来勒索信息的 P1l4tos 自然就是扰得人心惶惶的骇客。

参考资料列表：

1. Catalin Cimpanu

MongoDB 劫持者转移至 ElasticSearch 服务器

https://www.bleepingcomputer.com/news/security/mongodb-hijackers-move-on-to-elasticsearch-servers/
2. Mike Paquette

保护您的数据免受勒索攻击侵扰

https://www.elastic.co/blog/protecting-against-attacks-that-hold-your-data-for-ransom
3. Itamar Syn-Hershko

抵抗被洗劫：妥善保护您的 Elasticsearch 集群

http://code972.com/blog/2017/01/107-dont-be-ransacked-securing-your-elasticsearch-cluster-properly
4. Niall Merrigan 的 twitter 文 https://twitter.com/nmerrigan
5. Victor Gevers 的 twitter 文 https://twitter.com/0xDUDE