你的數據安全麼？Hadoop再曝安全漏洞| 黑客利用Hadoop Yarn資源管理系統未受權訪問漏洞進行攻擊

摘要： 4月30日，阿里雲發現，俄羅斯黑客利用Hadoop Yarn資源管理系統REST API未受權訪問漏洞進行攻擊。 Hadoop是一款由Apache基金會推出的分佈式系統框架，它經過著名的 MapReduce 算法進行分佈式處理，Yarn是Hadoop集羣的資源管理系統。

4月30日，阿里雲發現，俄羅斯黑客利用Hadoop Yarn資源管理系統REST API未受權訪問漏洞進行攻擊。

Hadoop是一款由Apache基金會推出的分佈式系統框架，它經過著名的 MapReduce 算法進行分佈式處理，Yarn是Hadoop集羣的資源管理系統。

這次事件主要因Hadoop YARN 資源管理系統配置不當，致使能夠未經受權進行訪問，從而被攻擊者惡意利用。攻擊者無需認證便可經過REST API部署任務來執行任意指令，最終徹底控制服務器。

利用方式還原及趨勢判斷

一、經過對比分析，阿里雲安全專家觀察到，與以前Redis、CouchDB事件相比，Hadoop做爲一個分佈式計算應用程序框架，讓其更容易被「攻陷」，由於：

• Hadoop種類和功能繁多，各類組件安全問題，可能會帶來更大的攻擊面；

• 針對某一個薄弱點的攻擊，可能經過該框架分佈式的特性，迅速擴散到全部節點。

二、灰黑產的入侵變現的手段，正在從入侵利用雲上普通主機資源挖礦獲利（Web服務器、數據庫服務器等），轉向攻擊專用算力應用，以竊取更大的算力進行挖礦獲利轉變（如Hadoop等分佈式計算平臺）。從本次樣本的分析來看，利用專用算力應用來攻擊變現的方式，還處在早期的測試階段；隨着加密貨幣的進一步繁榮，該類型的攻擊風險將會愈發凸顯。

總的來講，灰黑產對經濟利益的渴求，推進着這個行業的變遷升級。隨着加密貨幣市場熱度的攀升，入侵挖礦的灰色產業，也會隨之擴大；挖礦這種最有效變現手段對算力不斷擴大的需求，必然引導灰黑產的攻擊目標逐步轉向更高算力的產品和服務。

所以，阿里雲安全專家建議，不管是SaaS化服務的算力產品提供商，仍是算力的最終使用者，都應該更加的關注安全問題，只有在發展本身的業務的同時切實增強安全水平，才能保障業務長期健康穩定的發展。

安全建議

針對此類大規模攻擊，阿里雲平臺已可默認攔截，下降漏洞對用戶的直接影響；

若是企業但願完全解決Hadoop安全漏洞，推薦企業使用阿里雲MaxCompute （8年以上「零」安全漏洞）存儲、加工企業數據；

阿里雲數加MaxCompute（原名ODPS）設計之初就是面向多租戶，確保租戶的數據安全是MaxCompute的必備功能之一。在MaxCompute系統的安全設計和實現上，MaxCompute的工程師們會遵循一些通過實踐檢驗的安全設計原則（如Saltzer-Schroeder原則）。在經常使用密碼算法及安全協議的設計和實現上，也會遵循業界相關標準（如PKCS-及FIPS-系列標準），並堅持最佳安全實踐。

這裏從以下幾個方面來解刨一下MaxCompute的安全特性，讓關心MaxCompute數據安全的讀者有一個基本的瞭解。更多產品信息請訪問https://www.aliyun.com/product/odps 。

1. API認證

認證是一個服務的安全入口。MaxCompute認證採用業界標準的API認證協議來實現，如HmacSHA1。MaxCompute還提供HTTP和HTTPS兩種的EndPoint以知足用戶對認證安全的不一樣要求。HTTP EndPoint是明文傳輸，那麼HmacSHA1認證只能保證消息請求的真實性(Authenticity)和完整性(Integrity)，適合於對數據安全不太敏感的用戶。HTTPS EndPoint則能提供更多的安全性，好比信道加密，抗重放攻擊等。適合於對數據安全比較敏感的用戶。

2. 訪問控制

當你建立項目空間後，你就是項目空間的owner。一個項目空間只有一個owner，只有owner對項目空間有徹底控制權限。你能夠上傳/下載數據、提交SQL進行數據處理。在沒有你的受權的狀況下，任何其餘用戶都無權訪問你的項目空間。 注意，MaxCompute平臺並無超級管理員的角色，因此MaxCompute的開發、測試、運維同窗都是沒有權限看到用戶數據的。有人會問了，經過MaxCompute背後的運維管理控制檯也不能訪問用戶數據嗎？的確不能。運維同窗只有在得到內部受權以後，能夠經過該控制檯來執行一些運維管理類操做，好比中止一個有惡意行爲的用戶做業，但該控制檯沒有操做用戶數據的權限。

MaxCompute產品面向的是企業級用戶，因此提供了豐富的項目空間內的用戶管理及受權功能，有興趣的同窗能夠參考MaxCompute用戶手冊中的相關章節。MaxCompute訪問控制粒度很是精細，好比你能夠受權一個用戶只能讀某個table的部分columns，而且能夠要求該用戶只能在某個時間範圍內、並且必須從指定的某些IP地址來進行訪問。換句話說，一個企業主能夠作到只容許其員工在公司內、在正常上班時間才能訪問數據，下班回家就不容許訪問了。

3. 數據流控制

MaxCompute設計之初就是要知足數據分享（或數據交換）的場景。因此，只要有受權，用戶就能夠很是方便的進行跨項目空間的數據訪問。好比，在得到相應的訪問權限以後，項目空間A中的做業能夠直接處理項目空間B中的數據，而沒必要事先將數據從項目空間B中複製到項目空間A。

數據保護有兩層含義，一是防止未受權的數據訪問；二是防止得到受權的用戶濫用數據。不少商用系統並不提供後一種數據安全保證。但在MaxCompute平臺上，用戶的這種擔心比較明顯：用戶但願能確保對本身的數據擁有控制權，而一旦受權他人讀取，他人就可能會作複製數據，那麼就至關於失去了對數據的控制權。

MaxCompute經過支持數據流控制來防止跨項目空間的數據複製。若是你想確保項目空間中的全部數據都不容許流出去，那麼你能夠打開項目空間的數據流控設置。你還能夠設置項目空間的數據保護策略，以限制哪些數據能夠流出到哪些項目空間。

4. 用戶做業的隔離運行

MaxCompute支持用戶提交各類類型的做業（如SQL/XLib/MR）。爲了確保不一樣用戶做業在運行時互不干擾，MaxCompute將用戶做業的Worker進程運行在飛天 Container沙箱中。若是用戶做業含有Java代碼（好比UDF），那麼飛天Container沙箱中的Worker進程啓動JVM時，還會設置嚴格的Java 沙箱策略以限制UDF的運行時權限。

5. 做業運行時使用最小權限

最小權限原則是系統安全和容錯設計的一個基本指導原則，即讓每一個任務在運行時使用恰好知足須要（很少也很多）的權限來執行。

MaxCompute的做業運行過程通常是這樣：用戶提交的SQL/XLib/MR做業會被調度到某一計算集羣上運行，運行時每一個做業通常對應一組並行跑的Worker進程，Worker進程通常會從數據集羣上讀數據、處理完成後最終會將數據寫回到數據集羣。舉個例子來理解MaxCompute是如何遵循最小權限原則的。咱們假設用戶Alice被受權讀訪問一個項目空間下t1和t2兩個table數據，但她提交的某個SQL只須要讀t1的數據。在MaxCompute中，這個SQL對應的Worker進程在運行時就只能讀t1對應的底層數據文件，而不會有更多的數據訪問權限。

MaxCompute最小權限是依賴於底層的飛天分佈式操做系統提供的Kerberos認證和Capability訪問控制來實現的。Kerberos認證用於解決飛天底層服務模塊之間的身份認證，Capability則用於解決底層服務模塊之間的訪問控制技術。這與上層MaxCompute所提供的認證和訪問控制是徹底正交的安全機制，對MaxCompute用戶是徹底透明的。

6. 數據訪問審計

MaxCompute還提供精準的、細粒度的數據訪問操做記錄，並會長期保存。MaxCompute平臺體系所依賴的功能服務模塊很是之多，咱們能夠把它稱之爲底層服務棧。對於數據操做記錄來講，MaxCompute會收集服務棧上的全部操做記錄，從上層table/column級別的數據訪問日誌，一直到底層分佈式文件系統上的數據操做日誌。最底層分佈式文件系統上處理的每一次數據訪問請求，也都能追溯到是最上層的哪一個項目空間中的哪一個用戶的哪一個做業發起的數據訪問。

有了服務棧上的各層操做審計以後，即便是內部攻擊者（工程師或滲透到內部系統中的黑客）想從內部（繞過MaxCompute服務）直接訪問底層分佈式文件系統上的用戶數據的話，也必定是能夠從操做日誌中被發現的。因此，經過數據訪問審計，用戶就能夠準確的知道他在MaxCompute上的數據是否存在未受權的數據訪問。

7. 風險控制

除了不一樣層面的防護機制以外，MaxCompute產品還會提供一套安全監控系統，用於監控用戶做業及用戶數據的安全活動，如AccessKey濫用，項目空間安全配置不當，用戶代碼運行時觸犯安全策略，以及用戶數據是否遭受異常訪問等。

安全攻擊防不勝防，因此MaxCompute會經過安全監控手段來及時發現問題，一旦發現安全問題則會啓動相應的處理流程，儘量將用戶損失降到最低。

結語：雖然沒有絕對的安全，但安全性在MaxCompute產品設計和實現中享有最高優先級。MaxCompute團隊已經匯聚了多領域的安全專家，以保障用戶數據安全。同時，咱們歡迎更多安全專家的加入，共同加強MaxCompute的數據安全。

原文連接