根据 BinaryEdge 的数据显示，Elasticsearch 数据库于 2020 年 5 月 1 日首次被公开访问，5 月 7 日，安全研究员 Justin Paine 发现该数据库可公开访问。Justin Paine 表示：“这不是未经身份验证就暴露给 Internet 的单个服务器。我找到的主数据库分布在三个 Elasticsearch 节点组成的集群，另外，我还找到了第四个包含相似数据的 Elasticsearch 数据库。”
据了解，该数据库的数据量处于一直不断增长的情况，每 24 小时会添加大约 2 亿行新数据。截至 2020 年 5 月 21 日，数据库中共存储了 8336189132 条记录，数据是 NetFlow 数据和 DNS 查询日志的组合。
奇怪的是，DNS 查询仅记录了 8 天（2020 年 4 月 30 日到 2020 年 5 月 7 日），共捕获了 3376062859 个 DNS 查询日志，每秒记录 2538 个 DNS 事件，但不知出于何种原因，8天之后攻击者突然停止了记录 DNS 查询。
据了解，在整个数据库暴露期间，NetFlow 数据一直在被捕获，泄露的数据中有 50 亿行数据是 NetFlow 数据，以每秒 3200 个事件的速率被记录。
注：NetFlow 是思科公司开发的一种网络协议，用于收集 IP 流量信息和监控网络流量。通过对流量数据的分析，可以建立网络流量和流量的图像。
NetFlow 数据泄露有何影响呢？NetFlow 信息记录了哪个源 IP 将不同类型的流量发送到一个特定的目标 IP，以及传输了多少数据。以下图为例，这是对目标 IP 地址的 HTTPS (TCP 端口 443) 请求，我们对目标 IP 进行反向 DNS 查找，就可以快速识别此人将使用 HTTPS 的网站。
简单来说，通过这些泄露的NetFlow数据，我们可以判断出该 IP 所有者及家人的相关信息，包括拥有多少设备、设备的型号、使用过哪些软件、访问了哪些社交网站等等。
（上图是 DNS 查询获得的数据）
相信很多人也发现了，这次发生泄露的数据库又是 Elasticsearch。由于不少开发人员及其团队在认知上更多地把 Elasticsearch 看成是与 MySQL 同等的存储系统，所以在部署以后并没有太多地关心其访问控制策略和数据安全，而且 Elastisearch 开箱即用的特点也让开发和运维人员放松了对安全的重视，所以 Elasticsearch 数据泄露的比例很高。
如何避免呢？其实这也是个老生常谈的问题了，我们曾多次建议大家采取以下措施：
服务器必须要有防火墙，不能随意对外开放端口；
Elasticsearch 集群的端口包括 TCP 和 HTTP，都不能暴露在公网；
Elasticsearch 集群禁用批量删除索引功能；
Elasticsearch 中保存的数据要做基本的脱敏处理；
加强监控和告警，能够在安全事件发生的第一时间感知并启动紧急预案，将损失降到最低。
另外，由于这次泄露的数据主要是 NetFlow 数据，所以也需要针对此做出措施。ISP 收集 NetFlow 数据是无法避免的，它们会跟踪连接的来源和流量的目的地，但是 DNS 查询日志问题是可以解决的，建议使用 DoH 和 DoT 来保护 DNS 通信。据了解，目前 Mozilla Firefox、谷歌 Chrome、Internet Explorer Edge、Android 都支持 DoH 和 DoT，微软的 Windows 10 也将很快支持。
Google也要放弃C/C++？Chrome 代码库中70%的安全漏洞是内存问题
点个在看少个 bug 👇
