一行腳本，幾TB的數據沒有了......
前幾天看到《成人網站泄露 108 億數據，內含 50 萬中國用戶 》的文章，因為數據是基于 Elasticsearch 存儲的，出于好奇，查了一些國外的報道，才有了這篇文章的思考。
圖片來自 Pexels
信息滯后及一手資料的重要性
國內首發時間較國際首發時間晚了 5 天。也就是我們看到的鮮活的標題是 5 天后的第二手、第三手數據。
第一手資料的重要性不言而喻：
- 號稱比特幣首富的李笑來在一次收費語音課程中提到：他最早關注比特幣就是通過刷 Twiiter 刷出來的，討論的人多+新事物兩個屬性激發了他的興趣。
- 古典老師在《躍遷——成為高手的技術》中強調：“在我看來，現在我們獲取的知識絕大多數都是二三四手信息，因為很多人已經失去鑒別一手信息的能力。這也是我們認知效率低下的原因”。
擴展思考：
- 對于一些新技術優先關注英文材料可能比國內的論壇、博客等能提前很多掌握新知。
- Elasticsearch的學習也是推薦優先關注官方英文文檔，優先使用 Google，discuss.elastic.co， stackoverflow，而不是某度。
108 億數據怎么泄露的?
通稿里面的寫法是“因 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 的端口，沒有加任何安全防護措施。
一行腳本，上 TB 數據沒有了
無獨有偶，近期 QQ 群里有球友提供信息說，Elasticsearch 5.1.1 公開暴露到互聯網被礦機腳本注入，TB 級數據丟失。
經交流得知，也是關閉防火墻+公網暴露端口惹的禍!
公網開放端口，別人是怎么知道的?
關閉防火墻+公網開放端口，就相當于你把藏滿錢的保險柜放到了家里，但是保險柜沒有上鎖，且你家里大門也是打開的。
理論上，你不說沒人會知道。但是，如果“小偷”挨家挨戶翻，你的保險柜中錢丟失的概率極大。黑客或者安全愛好者常用的“伎倆”就是端口掃描。
第一步：窮舉公網 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
第二步：掃描常用端口
結合 NMap 等掃描工具掃描常用端口，如：9200、5601、9300、5000、9000 等。
結合請求的返回是否包含："tagline" : "You Know，for Search"”就能初步掃描出公網中裸奔的 Elasticsearch 集群。
窮舉方式是很笨，但幾乎沒有漏網之魚!在線的端口掃描工具也有很多，如下：
這也說明了：未加防護措施，一旦沒掃描到，幾乎不用腳本注入，來幾個常用刪除操作，對業務都可能是致命的影響!
這里也只是示例，黑客會有更高級的窺探和獲取數據的方式。
Elasticsearch 如何安全加固?
之前的博文中都有提及，再啰嗦幾句。
①不對外開放端口、不公網裸奔
操作如下：
- 默認開啟的 9200 端口(ES)、5601 端口(Kibana)、9000 端口(cerebro)、5000 端口(ElasticHQ)等 ELK stack 相關端口不對外公布。
- 盡量內網環境運行，不公網裸奔。
- 如果要映射開放端口，要限定好指定 IP 訪問，用完后關閉端口映射。
②升級高版本 Elasticsearch，使用 X-pack 基礎安全功能
Elasticsearch 7.1&6.8 版本之后，X-pack 基礎安全功能免費。
這意味著：
- Space、角色、用戶基礎功能免費，Elasticsearch、Kibana 訪問都可以設置上復雜的用戶名和密碼。
- 集群之間 TLS 加密通信免費。
- 互聯網訪問可以由 HTTP 升級為 HTTPS。
③設置 Nginx 反向代理服務器，并設置 HTTP Basic 認證來實現 Elasticsearch 的登錄認證
Elasticsearch 6.8 及 7.1 之前的版本適用。
④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
- }
⑤定期做好集群的全量和增量快照
結合：Elasticsearch _snapshot 和 restore API 能很好實現備份和恢復功能。確保數據由于誤操作，能第一時間恢復還原數據。
第三方導出工具：elasticdump，esm 等也都可以拿來主義。
⑥Elasticsearch 中保存的數據要做基本的脫敏處理
在涉及客戶安全數據或者一些商業性敏感數據的情況下，在不違反系統規則條件下，對真實數據進行改造并提供測試使用，如身份證號、手機號、卡號、客戶號等個人信息都需要進行數據脫敏。是數據庫安全 技術之一。
數據脫敏方式——通過對敏感信息采用脫敏方式進行匿名化，防止因生產庫中的主要數據，明文顯示在測試系統中，導致數據泄漏問題。
生活中也不乏數據脫敏的例子，比如：火車票上的身份證、電商收貨人電話都會對敏感信息做處理，打上 XXXX。
實際 Elasticsearch 存儲層面涉及較少，更多的是：后端做業務脫敏處理，前端脫敏顯示。
思考
Elastic Stack 近幾年發展迅猛，1.X，2.X，5.X，6.X，7.X，未來 8.X 可期!我們隨著 ES 的快速發展，升級版本、迭代技術，開疆擴土，擴展業務。
的確能體會到 ES 帶來的效率的提升和各種便利，但往往會忽視了最重要的部分——安全!
早期的版本中 X-pack 安全部分都是收費的，使用的慣性也會使得我們忽視安全，而是各種“一把梭”用法至上，業務能跑起來再說。
但是，反思一下：“快了就是慢了”!沒有了安全，所有的業務也無從談起，一旦出現安全分享，可能會造成災難級的后果!以下的溫馨提示，和大家共勉!
作者：銘毅天下
編輯：陶家龍
出處：轉載自微信公眾號銘毅天下
