成人网站泄露 108 亿数据后，一个 Elasticsearch 爱好者的思考

昨天晚上看到《成人网站泄露 108 亿数据，内含 50 万中国用户》的文章，因为数据是基于Elasticsearch存储的，出于好奇，查了一些国外的报道，才有了这篇文章的思考。

1、信息滞后及一手资料的重要性

国内首发时间较国际首发时间晚了5天。也就是我们看到的鲜活的标题是5天后的第二手、第三手数据。

第一手资料的重要性不言而喻。

号称比特币首富的李笑来在一次收费语音课程中提到：他最早关注比特币就是通过刷twiiter刷出来的，讨论的人多新事物两个属性激发了他的兴趣。
古典老师在《跃迁——成为高手的技术》中强调：“在我看来，现在我们获取的知识绝大多数都是二三四手信息，因为很多人已经失去鉴别一手信息的能力。这也是我们认知效率低下的原因”。

扩展思考：

对于一些新技术优先关注英文材料可能比国内的论坛、博客等能提前很多掌握新知。
Elasticsearch的学习也是推荐优先关注官方英文文档，优先使用 Google ，discuss.elastic.co, stackoverflow 而不是某度。

2、怎么泄露的？

通稿里面的写法是“因 Elasticsearch 集群错误配置，成人视频网站 CAM4 发生重大数据泄露事件”。

真实原因是什么呢？

我查证了国外的其他报道，汇集如下（为了保证一手资料的重要性，这里保留了英文）。

“Leaving their production server publicly exposed without any password,” says Safety Detectives researcher Anurag Sen, whose team discovered the leak, “it’s really dangerous to the users and to the company.”

安全侦探的研究人员Anurag Sen（他的团队发现了泄漏）说：“将生产服务器公开暴露，没有任何密码，这对用户和公司都是非常危险的。”。

The mistake CAM4 made is also not unique. ElasticSearch server goofs have been the cause of countless high-profile data leaks. What typically happens: They’re intended for internal use only, but someone makes a configuration error that leaves it online with no password protection.

通常会发生的情况：它们仅供内部使用，但是有人犯了配置错误，使它联机时没有密码保护。

The server in question was a log aggregation server from a bunch of different sources, but server was considered non-confidential。

有问题的服务器是来自许多不同来源的日志聚合服务器，但该服务器被认为是非机密的。

https://www.wired.com/story/cam4-adult-cam-data-leak-7tb/

关于上条信息的准确性，上twiiter求证了一下，的确Anurag Sen所有推文都和安全有关。

一句话概括可能的泄露原因：在公网上公开了 Elasticsearch 的端口，没有加任何安全防护措施。

3、一行脚本，上TB数据没有了

无独有偶，近期 QQ 群里有球友提供信息说，Elasticsearch 5.1.1 公开暴露到互联网被矿机脚本注入，TB 级数据丢失。

经交流得知，也是关闭防火墙公网暴露端口惹的祸！

4、公网开放端口，别人是怎么知道的？

关闭防火墙公网开放端口，就相当于你把藏满钱的保险柜放到了家里，但是保险柜没有上锁，且你家里大门也是打开的。

理论上，你不说没人会知道。但是，如果“小偷”挨家挨户翻，你的保险柜中钱丢失的概率极大。

黑客或者安全爱好者常用的“伎俩”就是端口扫描。

4.1 第一步：穷举公网IP地址

理论上 IPV4 的所有公网 IP 是可以穷举的，具备大学基础网络知识就能搞定，举例如下：

A 类地址范围：1.0.0.0—126.0.0.0
B 类地址范围：128.0.0.0—191.255.0.0
C 类地址范围：192.0.0.0—223.255.255.0
D 类地址范围：224.0.0.0—239.255.255.255
E 类地址范围：240.0.0.0—255.255.255.254

去掉内网私有地址网段：

10.0.0.0—10.255.255.255、
172.16.0.0—172.31.255.255、
192.168.0.0—192.168.255.255。

4.2 第二步：扫描常用端口

结合NMap等扫描工具扫描常用端口，如：9200、5601、9300、5000、9000等。结合请求的返回是否包含："tagline" : "You Know, for Search"”就能初步扫描出公网中裸奔的 Elasticsearch 集群。

穷举方式是很笨，但几乎没有漏网之鱼！

在线的端口扫描工具也有很多，如下：

这也说明了：未加防护措施，一旦没扫描到，几乎不用脚本注入，来几个常用删除操作，对业务都可能是致命的影响！

这里也只是示例，黑客会有更高级的窥探和获取数据的方式。

5、Elasticsearch如何安全加固？

之前的博文中都有提及，再啰嗦几句。

5.1 不对外开放端口、不公网裸奔

默认开启的9200端口（ES）、5601端口（kibana）、9000端口（cerebro）、5000端口(ElasticHQ）等ELK stack相关端口不对外公布。
尽量内网环境运行，不公网裸奔。
如果要映射开放端口，要限定好指定IP访问，用完后关闭端口映射。

5.2 升级高版本Elasticsearch，使用X-pack基础安全功能

Elasticsearch7.1 & 6.8 版本之后，X-pack基础安全功能免费。这意味着：

Space、角色、用户基础功能免费，Elasticsearch、kibana访问都可以设置上复杂的用户名和密码。
集群之间Tls加密通信免费。
互联网访问可以由Http升级为Https。

5.3 设置nginx反向代理服务器，并设置http basic认证来实现elasticsearch的登录认证

Elasticsearch6.8及7.1 之前的版本适用。

5.4 Elasticsearch 集群禁用批量删除索引

批量删除操作类似“rm -rf ”删库跑路操作，若ES集群没有备份，后果不堪设想。

禁用批量删除不止是对外，对内也能起到防护作用。

对一些人来说，能够用单个命令来删除所有数据可能会导致可怕的后果。

如何避免意外的大量删除？

实践方案1：你可以在你的 elasticsearch.yml 做如下配置：

代码语言：javascript复制

action.destructive_requires_name: true

实践方案2：

代码语言：javascript复制

PUT /_cluster/settings
{
    "persistent" : {
       "action.destructive_requires_name":true
    }
}

验证：

代码语言：javascript复制

DELETE kibana_*

报错如下，也就是说不能批量删除索引了！

代码语言：javascript复制

{
  "error": {
    "root_cause": [
      {
        "type": "illegal_argument_exception",
        "reason": "Wildcard expressions or all indices are not allowed"
      }
    ],
    "type": "illegal_argument_exception",
    "reason": "Wildcard expressions or all indices are not allowed"
  },
  "status": 400
}