成人网站泄露 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 是可以穷举的，具备大学基础网络知识就能搞定，举例如下：

1. A 类地址范围：1.0.0.0—126.0.0.0

2. B 类地址范围：128.0.0.0—191.255.0.0

3. C 类地址范围：192.0.0.0—223.255.255.0

4. D 类地址范围：224.0.0.0—239.255.255.255

5. E 类地址范围：240.0.0.0—255.255.255.254

去掉内网私有地址网段：

1. 10.0.0.0—10.255.255.255、

2. 172.16.0.0—172.31.255.255、

3. 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。

推荐：干货 | Elasticsearch7.X X-Pack基础安全实操详解

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

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

推荐：你的 Elasticsearch在裸奔吗？

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

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

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

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

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

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

action.destructive_requires_name: true

实践方案2：

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

验证：

DELETE kibana_*

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

{
  "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
}

5.5 定期做好集群的全量和增量快照

结合：Elasticsearch _snapshot 和 restore API 能很好实现备份和恢复功能。确保数据由于误操作，能第一时间恢复还原数据。

第三方导出工具：elasticdump，esm等也都可以拿来主义。

推荐：干货 | Elasitcsearch7.X集群/索引备份与恢复实战

5.6 Elasticsearch 中保存的数据要做基本的脱敏处理

在涉及客户安全数据或者一些商业性敏感数据的情况下，在不违反系统规则条件下，对真实数据进行改造并提供测试使用，如身份证号、手机号、卡号、客户号等个人信息都需要进行数据脱敏。是数据库安全 技术之一。

数据脱敏方式——通过对敏感信息采用脱敏方式进行匿名化，防止因生产库中的主要数据，明文显示在测试系统中，导致数据泄漏问题。

生活中也不乏数据脱敏的例子，比如：火车票上的身份证、电商收货人电话都会对敏感信息做处理，打上XXXX。

实际Elasticsearch存储层面涉及较少，更多的是：后端做业务脱敏处理，前端脱敏显示。

6、思考

Elastic stack近几年发展迅猛，1.X, 2.X,5.X,6.X,7.X，未来8.X可期！

我们随着ES的快速发展，升级版本、迭代技术，开疆扩土，扩展业务。

的确能体会到ES带来的效率的提升和各种便利，但往往会忽视了最重要的部分——安全！

早期的版本中x-pack安全部分都是收费的，使用的惯性也会使得我们忽视安全，而是各种“一把梭”用法至上，业务能跑起来再说。

但是，反思一下：“快了就是慢了”！没有了安全，所有的业务也无从谈起，一旦出现安全分享，可能会造成灾难级的后果！

以下的温馨提示，和大家共勉！