即使是在您的内部网络中，也请尽可能将集群隔离于其它系统部分之外。举例来说，一部分客户会将其集群部署在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自然就是扰得人心惶惶的骇客。
参考资料列表：
Catalin Cimpanu
MongoDB劫持者转移至ElasticSearch服务器