精品国产一级在线观看,国产成人综合久久精品亚洲,免费一级欧美大片在线观看

MongoDB事件之后，再起波瀾

經過在MongoDB各服務器間長達數日的肆虐，一群惡意分子又開始將其劫持矛頭指向ElasticSearch服務器，并要求受害者支付類似的贖金。

第一波針對ElasticSearch服務器所有者的打擊發生于1月12日，其中部分受害者通過ElasticSearch論壇反映了相關情況。

與此前曾經出現的MongDB劫持活動類似，如今新一波指向ElasticSearch集群的惡意入侵再次襲來。目前全球各地的ElasticSearch集群正受到大范圍劫持，其中僅留下一條與贖金要求相關的索引定義，具體如下所示：

根據已經報告的勒索說明，攻擊活動似乎全部源自同一黑客組織，名為P1l4tos。留言中寫明：

如果希望恢復你的數據庫，向以下錢包中發送0.2比特幣：1DAsGY4Kt1a4LCTPMH5vm5PqX32eZmot4r！在比特幣發送完成后，向[email protected]郵箱發送你的服務器IP。

截至撰稿之時，以上列出的比特幣地址僅收到一筆贖金款項。

關于此次ElasticSearch劫持更多細節

已有超過800臺服務器遭受劫持

作為持續關注此前MongoDB攻擊活動的安全研究人員之一，Niall Merrigan已經開始追蹤本輪ElasticSearch攻擊活動。截至本文撰稿時，Merrigan在twitter上的最新報告稱已經有超過800臺服務器遭受劫持。

ElasticSearch是一套基于Java的搜索引擎，主要用于在各類大型Web服務及企業網絡當中進行信息檢索。

據稱，攻擊者利用低強度、易猜出的密碼對暴露在互聯網當中的各ElasticSearch服務器發起入侵。

目前，仍有約35000臺ElasticSearch服務器在線運行

根據Shodan查詢結果顯示，目前仍有約35000個ElasticSearch實例可通過互聯網進行接入。2015年8月，來自BinaryEdge公司的安全專家們發現當時在線運行的ElasticSearch實例僅為8990個，而其時個中包含的信息總量為531199 TB。

安全界早有預警

2015年12月，AlienVault通過實驗發現，攻擊者能夠利用兩項不同的安全漏洞對ElasticSearch服務器進行劫持，并將其添加至僵尸網絡當中。

MongoDB也有相同的境遇，在MongoDB事件發生前，其實業界已經告知很多MongoDB數據庫處于令人不安的開放狀態。2015年12與，Shodan經過調查之后發現當時互聯網上共有至少35,000個可公開訪問，無須身份驗證的MongoDB實例。（悲傷的是，一年多之后，開放式MongoDB數據庫的數量不降反增，估計共有多達99,000個數據庫有被劫持風險。）

技術反思 and“一語成讖”

隨著此前針對MongoDB服務器之攻擊活動的出現，業內人士考慮其需要花費多長時間才會將惡意矛頭指向其它技術方案。

Bleeping Computer的安全觀察員Catalin Cimpanu曾經在2017年1月9日公開表示其擔憂：

我在考慮這些MongoDB劫持者需要多長時間來發現其它互聯網可訪問目標，包括Redis、CouchDB以及ElasticSearch服務器。

問題的答案是三天。

其它可能的潛在攻擊目標還包括Apache CouchDB、Redis以及Memcached，其皆可通過互聯網輕松訪問且在安全水平上甚至不及MongoDB。

Elastic公司官方：正確配置，防止數據丟失

ES的劫持事件發生第二天，2017年1月13日，Elastic公司撰寫了一篇博客“保護您的數據免受勒索攻擊侵擾”。文中表示此次事件對Elastic Cloud的客戶影響甚微，其中安全產品X-Pack 會隨機分配彼此獨立密碼的配合。而對于其他用戶，Elastic公司不建議將ElasticSearch實例暴露在互聯網中；對于已有的非安全且面向互聯網的Elasticsearch，Elastic公司同樣給出了六條建議。

附文章地址為：https://www.elastic.co/blog/protecting-against-attacks-that-hold-your-data-for-ransom。

下面為全文譯文：

上周末，一輪惡意攻擊的大規模來襲導致數千臺開源數據庫中的數據遭遇復制、刪除及勒索性加密等嚴重問題。盡管上述攻擊活動中并未使用任何惡意軟件或者“勒索軟件”，且與產品安全漏洞并無關聯，但最終仍然造成了嚴重的數據丟失甚至數據泄露安全事故。不過好消息是，我們完全可以通過正確配置輕松防止類似攻擊行為造成的數據丟失后果。

因此，讓我們以此為鑒高度關注Elasticsearch實例的安全保護工作，特別是保護那些可通過互聯網加以接入的實例。

選擇使用Elastic Cloud的客戶可以放心，其使用隨機分配的彼此獨立密碼配合X-Pack安全產品對集群加以保護。客戶為這些集群選擇對應的AWS服務區，而集群本身亦被部署在冗余防火墻及代理之后。默認配置提供來自互聯網的加密TLS通信內容，且Elastic每七天對集群數據進行一次備份。

對于其它部署選項，我們強烈建議大家確保那些可能存在安全問題的Elasticsearch實例不會直接暴露在互聯網當中。具體請參閱我們2013年發布的博文。我們還將相關建議以localhost內默認安裝綁定的形式加以實施。盡管如此，面對各類互聯網可訪問實例，我們已經意識到其中存在的安全隱患。

如果大家擁有一套非安全且面向互聯網的Elasticsearch實例，那么我們強烈建議您立即采取以下措施以保護您的數據：

更早的呼聲：不在公共網絡中暴露集群

在ElasticSearch服務器集群收到攻擊的當天，搜索及大數據專家Itamar Syn-Hershko便撰文

“抵抗被洗劫：妥善保護您的Elasticsearch集群”詳細支招怎樣對抗此次劫持，Itamar是以色列的獨立咨詢師，他的公司code972是Elastics公司的合作伙伴。

http://code972.com/blog/2017/01/107-dont-be-ransacked-securing-your-elasticsearch-cluster-properly

Itamar 強烈呼吁：

無論如何，請千萬不要讓您的集群節點暴露在網絡當中。雖然這聽起來像是廢話，但事實上用戶們往往并沒有切實遵循這項最佳實踐。您永遠不應將自己的集群暴露在公共網絡當中。

Itamar 對七條推薦實踐進行了分析，探討確保集群安全的“該”與“不該”作法。以下為其文章的翻譯：

1、啟用HTTP的節點應該僅監聽私有IP

Elasticsearch可通過配置限定其所監聽的IP，而大家可以控制作為其合法監聽對象的本地主機、私有IP、公共IP或者這幾類對象的組合。在現實使用中，我們沒有任何理由yhElasticsearch監聽公共IP或者可公開訪問的DNS名稱。

這項設置被稱為network.bind_host或者簡寫為network.host，而大家應始終將其設定為僅適用于私有IP（在某些例外情況下，亦可加入某些本地主機）。

讓我們再次重申：network.bind_host應當始終被設定為私有網絡接口，而永遠不可被設定為公共IP或者DNS。

這將影響到HTTP訪問與本地Java客戶端訪問。在某些用例中，我們可能需要實現某客戶端節點的公開訪問，具體解決辦法如下。

2、使用代理實現客戶端通信

作為一類常見誤區，人們通常表示“嘿，Elsticsearch屬于REST over HTTP，我們直接通過智能HTML客戶端進行訪問即可。”事實上，這種作法極不可取。

如果大家的單頁面應用需要查詢Elastic并獲取JSON作為顯示內容，那么將通過具備過濾、審計記錄以及最重要的數據密碼保護功能的軟件代理加以實現。

如果不這樣做，那么我們很可能面臨以下三種后果：（1）您將其明確綁定至某公共IP，這種作法非常危險; （2）導致數據面臨意外修改的風險; （3）最糟糕的是，您無法控制誰在對哪些數據進行訪問，而且全部數據皆可供外部查看。而本次出現的Elasticsearch集群劫持事件正是引發了這種情況。

另外，也不要暴露您的文件與索引結構，亦不可對您的瘦客戶端同為其提供數據的數據存儲系統進行耦合。您的客戶端JavaScript絕對不應與Elastic DSL直接通信。

您的客戶端應該與服務器端軟件進行通信，并由后者將全部客戶端請求轉發至Elasticsearch DSL、執行查詢、而后有選擇地將來自Elasticsearch的響應結果返回至客戶端。另外，在對Elasticsearch進行任何訪問之前，您的服務器端應用顯然應驗證用戶登錄憑證，從而確保其身份及授權符合操作數據的相關要求。如若不然，您的集群很可能陷入風險，并直接導致數據為貪婪的攻擊者所獲取。

3、如果可能，將Elasticsearch運行在隔離網絡當中

即使是在您的內部網絡中，也請盡可能將集群隔離于其它系統部分之外。舉例來說，一部分客戶會將其集群部署在AWS之上，我建議大家將此類集群運行在VPC中，而后再為其設置兩個獨立安全組——其一面向整體集群，其二面向其中單一客戶端節點，且該節點僅與要求訪問集群的應用進行共享。

4、不要使用默認端口

再有，請不要使用默認端口——算是我有些多疑吧，但小心一點總是沒錯的。

默認端口的變更方式非常簡單，感興趣的朋友可以點擊此處查看設置過程（英文原文）。

5、在不需要時禁用HTTP

Elasticsearch最好是被部署在服務器組當中，其中每臺服務器充當單一角色——例如主節點、數據節點以及客戶端節點。感興趣的朋友可以點擊此處查看官方說明文檔中的相關內容（英文原文）。

請確保只在您的客戶端節點上啟用HTTP，且僅允許您的應用（來自私有網絡之內）對其加以訪問。在客戶端節點上啟用HTTP亦適用于全部集群通信皆立足 TCP端口（默認為9300）完成的JVM類系統，這是因為：（1）大家仍然需要開放HTTP端點以實現調試與維護; （2）長期運行的Java客戶端也將遷移至HTTP。

感興趣的朋友可以點擊此處了解如何輕松禁用HTTP（英文原文）。

6、保護公共可用的客戶端節點

在某些情況下，客戶端節點需要公共可用以支持Kibana及Kopf等UI。雖然我仍然建議大家將這些節點部署在私有網絡之后并僅允許通過VPN進行連接，但有時候VPN確實不易設置，而最方便快捷的作法無法是將Kibana實例直接部署在公開節點之上——這會同時導致整套集群暴露在互聯網當中。

如果大家能夠利用VPN保護自己的客戶端Kibana、Kopf及其它節點（即借此將其僅綁定至私有IP），那么請務必采取這種方法。

如若不然，大家可以通過引入代理的方式實現保護。作為起點，大家可以點擊此處了解如何利用簡單的示例nginx配置文件建立密碼保護代理以掩護您的客戶端節點。此示例中包含Kibana、Kopf（靜態）與實際Elasticsearch訪問。

大家也可以利用Elastic的Shield或者SearchGuard等插件保護自己的集群并控制一切經由客戶端節點的訪問活動。

如果大家不得不選擇通過公共網絡訪問節點，請確保利用HTTPS對其進行保護，同時禁止一切以明文方式傳輸數據及憑證的作法。再次強調，Shield與SearchGuard等nginx與Elasticsearch插件能夠幫助大家輕松實現這一效果。

7、禁用腳本（2.x之前版本）

在Elasticsearch 2.x之前的版本中，其由于啟用了多種非沙箱語言（mvel、groovy）的動態腳本功能而存在安全隱患。如果大家使用的集群部署有1.x或者0.x版本，請盡快進行升級。或者，至少應當禁用其動態腳本功能。

如果大家使用Elasticsearch 2.x版本，則應變更您的默認腳本語言并移除groovy（此語言不支持沙箱功能，且為默認語言）。

我個人發現，很多集群都是由通過Search API向Elasticsearch發送惡意腳本的方式遭遇入侵的。

在Itamar看來：Elasticsearch目前已經被廣泛應用于從日志記錄到搜索在內的各類敏感文件用例當中。無論如何，存儲在Elasticsearch上的數據實際上相當安全，即很難被惡意人士所竊取。

正因為如此，大家不應自尋煩惱。請確保您的集群深深隱藏在私有網絡當中，且僅接受來自您自有應用的訪問。

禁用各類您不需要的功能，且盡可能隱藏您的設置（例如默認端口）、您的數據結構甚至是您正在使用Elasticsearch這一事實。

最后，我將繼續密切關注這場安全危機的發展情況，并根據事態隨時為大家帶來更多新消息。

如果還有問題，還有大神可以求助嗎？

除了Elastic公司和安全專家Itamar給開出的普適良方，如果你還有問題怎么辦呢？

或許可以求助一位行俠仗義的Hacker， Victor Gevers堪稱一位Hacker道德模范，從1998年起，他負責捉住了5211個安全漏洞。他所在的GDI Foundation公司是一個非盈利組織，公司的使命是讓免費公開的互聯網更安全，這家不足十人的荷蘭公司致力于發掘安全漏洞。

在此前對MongoDB的文章報道中，高效開發運維公眾號的一位技術粉絲bill0 Ng強烈建議對“黑客”和“駭客”兩次進行區分并稱，

黑客hacker：具有開拓者精神的人，勇于實踐；

駭客cracker：搞破壞的人。

兩類任共性是技術高超，但是出發點是不同的。上面所說的 Victor和他的同事們當屬正義的Hacker。而發來勒索信息的P1l4tos自然就是擾得人心惶惶的駭客。

參考資料列表：

Catalin Cimpanu

MongoDB劫持者轉移至ElasticSearch服務器

https://www.bleepingcomputer.com/news/security/mongodb-hijackers-move-on-to-elasticsearch-servers/

Mike Paquette

保護您的數據免受勒索攻擊侵擾

https://www.elastic.co/blog/protecting-against-attacks-that-hold-your-data-for-ransom

Itamar Syn-Hershko

抵抗被洗劫：妥善保護您的Elasticsearch集群

http://code972.com/blog/2017/01/107-dont-be-ransacked-securing-your-elasticsearch-cluster-properly