前幾天看到《成人網(wǎng)站泄露 108 億數(shù)據(jù)，內(nèi)含 50 萬中國(guó)用戶 》的文章，因?yàn)閿?shù)據(jù)是基于 Elasticsearch 存儲(chǔ)的，出于好奇，查了一些國(guó)外的報(bào)道，才有了這篇文章的思考。

[[326187]]

圖片來自 Pexels

信息滯后及一手資料的重要性

國(guó)內(nèi)首發(fā)時(shí)間較國(guó)際首發(fā)時(shí)間晚了 5 天。也就是我們看到的鮮活的標(biāo)題是 5 天后的第二手、第三手?jǐn)?shù)據(jù)。

第一手資料的重要性不言而喻：

• 號(hào)稱比特幣首富的李笑來在一次收費(fèi)語音課程中提到：他最早關(guān)注比特幣就是通過刷 Twiiter 刷出來的，討論的人多+新事物兩個(gè)屬性激發(fā)了他的興趣。
• 古典老師在《躍遷——成為高手的技術(shù)》中強(qiáng)調(diào)：“在我看來，現(xiàn)在我們獲取的知識(shí)絕大多數(shù)都是二三四手信息，因?yàn)楹芏嗳艘呀?jīng)失去鑒別一手信息的能力。這也是我們認(rèn)知效率低下的原因”。

擴(kuò)展思考：

• 對(duì)于一些新技術(shù)優(yōu)先關(guān)注英文材料可能比國(guó)內(nèi)的論壇、博客等能提前很多掌握新知。
• Elasticsearch的學(xué)習(xí)也是推薦優(yōu)先關(guān)注官方英文文檔，優(yōu)先使用 Google，discuss.elastic.co， stackoverflow，而不是某度。

108 億數(shù)據(jù)怎么泄露的?

通稿里面的寫法是“因 Elasticsearch 集群錯(cuò)誤配置，成人視頻網(wǎng)站 CAM4 發(fā)生重大數(shù)據(jù)泄露事件”。

真實(shí)原因是什么呢?我查證了國(guó)外的其他報(bào)道，匯集如下(為了保證一手資料的重要性，這里保留了英文)。

“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(他的團(tuán)隊(duì)發(fā)現(xiàn)了泄漏)說：“將生產(chǎn)服務(wù)器公開暴露，沒有任何密碼，這對(duì)用戶和公司都是非常危險(xiǎn)的。”。

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.

通常會(huì)發(fā)生的情況：它們僅供內(nèi)部使用，但是有人犯了配置錯(cuò)誤，使它聯(lián)機(jī)時(shí)沒有密碼保護(hù)。

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

有問題的服務(wù)器是來自許多不同來源的日志聚合服務(wù)器，但該服務(wù)器被認(rèn)為是非機(jī)密的。

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

關(guān)于上條信息的準(zhǔn)確性，上 Twiiter 求證了一下，的確 Anurag Sen 所有推文都和安全有關(guān)。

一句話概括可能的泄露原因：在公網(wǎng)上公開了 Elasticsearch 的端口，沒有加任何安全防護(hù)措施。

一行腳本，上 TB 數(shù)據(jù)沒有了

無獨(dú)有偶，近期 QQ 群里有球友提供信息說，Elasticsearch 5.1.1 公開暴露到互聯(lián)網(wǎng)被礦機(jī)腳本注入，TB 級(jí)數(shù)據(jù)丟失。

經(jīng)交流得知，也是關(guān)閉防火墻+公網(wǎng)暴露端口惹的禍!

公網(wǎng)開放端口，別人是怎么知道的?

關(guān)閉防火墻+公網(wǎng)開放端口，就相當(dāng)于你把藏滿錢的保險(xiǎn)柜放到了家里，但是保險(xiǎn)柜沒有上鎖，且你家里大門也是打開的。

理論上，你不說沒人會(huì)知道。但是，如果“小偷”挨家挨戶翻，你的保險(xiǎn)柜中錢丟失的概率極大。黑客或者安全愛好者常用的“伎倆”就是端口掃描。

第一步：窮舉公網(wǎng) IP 地址

理論上 IPV4 的所有公網(wǎng) IP 是可以窮舉的，具備大學(xué)基礎(chǔ)網(wǎng)絡(luò)知識(shí)就能搞定。

舉例如下：

• 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

去掉內(nèi)網(wǎng)私有地址網(wǎng)段：

• 10.0.0.0—10.255.255.255
• 172.16.0.0—172.31.255.255
• 192.168.0.0—192.168.255.255

第二步：掃描常用端口

結(jié)合 NMap 等掃描工具掃描常用端口，如：9200、5601、9300、5000、9000 等。

結(jié)合請(qǐng)求的返回是否包含："tagline" : "You Know，for Search"”就能初步掃描出公網(wǎng)中裸奔的 Elasticsearch 集群。

窮舉方式是很笨，但幾乎沒有漏網(wǎng)之魚!在線的端口掃描工具也有很多，如下：

這也說明了：未加防護(hù)措施，一旦沒掃描到，幾乎不用腳本注入，來幾個(gè)常用刪除操作，對(duì)業(yè)務(wù)都可能是致命的影響!

這里也只是示例，黑客會(huì)有更高級(jí)的窺探和獲取數(shù)據(jù)的方式。

Elasticsearch 如何安全加固?

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

①不對(duì)外開放端口、不公網(wǎng)裸奔

操作如下：

• 默認(rèn)開啟的 9200 端口(ES)、5601 端口(Kibana)、9000 端口(cerebro)、5000 端口(ElasticHQ)等 ELK stack 相關(guān)端口不對(duì)外公布。
• 盡量?jī)?nèi)網(wǎng)環(huán)境運(yùn)行，不公網(wǎng)裸奔。
• 如果要映射開放端口，要限定好指定 IP 訪問，用完后關(guān)閉端口映射。

②升級(jí)高版本 Elasticsearch，使用 X-pack 基礎(chǔ)安全功能

Elasticsearch 7.1&6.8 版本之后，X-pack 基礎(chǔ)安全功能免費(fèi)。

這意味著：

• Space、角色、用戶基礎(chǔ)功能免費(fèi)，Elasticsearch、Kibana 訪問都可以設(shè)置上復(fù)雜的用戶名和密碼。
• 集群之間 TLS 加密通信免費(fèi)。
• 互聯(lián)網(wǎng)訪問可以由 HTTP 升級(jí)為 HTTPS。

③設(shè)置 Nginx 反向代理服務(wù)器，并設(shè)置 HTTP Basic 認(rèn)證來實(shí)現(xiàn) Elasticsearch 的登錄認(rèn)證

Elasticsearch 6.8 及 7.1 之前的版本適用。

④Elasticsearch 集群禁用批量刪除索引

批量刪除操作類似“rm -rf ”刪庫跑路操作，若 ES 集群沒有備份，后果不堪設(shè)想。

禁用批量刪除不止是對(duì)外，對(duì)內(nèi)也能起到防護(hù)作用。對(duì)一些人來說，能夠用單個(gè)命令來刪除所有數(shù)據(jù)可能會(huì)導(dǎo)致可怕的后果。

如何避免意外的大量刪除?

實(shí)踐方案 1

你可以在你的 elasticsearch.yml 做如下配置：

action.destructive_requires_name: true 

實(shí)踐方案 2

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

驗(yàn)證：

DELETE kibana_* 

報(bào)錯(cuò)如下，也就是說不能批量刪除索引了：

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

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

結(jié)合：Elasticsearch _snapshot 和 restore API 能很好實(shí)現(xiàn)備份和恢復(fù)功能。確保數(shù)據(jù)由于誤操作，能第一時(shí)間恢復(fù)還原數(shù)據(jù)。

第三方導(dǎo)出工具：elasticdump，esm 等也都可以拿來主義。

⑥Elasticsearch 中保存的數(shù)據(jù)要做基本的脫敏處理

在涉及客戶安全數(shù)據(jù)或者一些商業(yè)性敏感數(shù)據(jù)的情況下，在不違反系統(tǒng)規(guī)則條件下，對(duì)真實(shí)數(shù)據(jù)進(jìn)行改造并提供測(cè)試使用，如身份證號(hào)、手機(jī)號(hào)、卡號(hào)、客戶號(hào)等個(gè)人信息都需要進(jìn)行數(shù)據(jù)脫敏。是數(shù)據(jù)庫安全 技術(shù)之一。

數(shù)據(jù)脫敏方式——通過對(duì)敏感信息采用脫敏方式進(jìn)行匿名化，防止因生產(chǎn)庫中的主要數(shù)據(jù)，明文顯示在測(cè)試系統(tǒng)中，導(dǎo)致數(shù)據(jù)泄漏問題。

生活中也不乏數(shù)據(jù)脫敏的例子，比如：火車票上的身份證、電商收貨人電話都會(huì)對(duì)敏感信息做處理，打上 XXXX。

實(shí)際 Elasticsearch 存儲(chǔ)層面涉及較少，更多的是：后端做業(yè)務(wù)脫敏處理，前端脫敏顯示。

思考

Elastic Stack 近幾年發(fā)展迅猛，1.X，2.X，5.X，6.X，7.X，未來 8.X 可期!我們隨著 ES 的快速發(fā)展，升級(jí)版本、迭代技術(shù)，開疆?dāng)U土，擴(kuò)展業(yè)務(wù)。

的確能體會(huì)到 ES 帶來的效率的提升和各種便利，但往往會(huì)忽視了最重要的部分——安全!

早期的版本中 X-pack 安全部分都是收費(fèi)的，使用的慣性也會(huì)使得我們忽視安全，而是各種“一把梭”用法至上，業(yè)務(wù)能跑起來再說。

但是，反思一下：“快了就是慢了”!沒有了安全，所有的業(yè)務(wù)也無從談起，一旦出現(xiàn)安全分享，可能會(huì)造成災(zāi)難級(jí)的后果!以下的溫馨提示，和大家共勉!

作者：銘毅天下

編輯：陶家龍

出處：轉(zhuǎn)載自微信公眾號(hào)銘毅天下