影響到1.43億客戶記錄的Equifax數據泄露事件，現在恐怕無人不知了。Equifax報告稱，攻擊者使用了編號為CVE-2017-5638的Apache Struts漏洞。
Equifax并沒有在容器中運行其脆弱Struts應用，但如果他們這么做了呢？容器當然更加安全，于是整個糟糕的情況就可以避免掉了，對吧？
未必。
容器固有的基礎設施即代碼，具有多個安全優勢。連續設置部署新容器是標準操作，因而部署補丁完善的軟件所面臨的宕機風險也就更小。一般都會從干凈的容器開始，所以用不著修復已經被破壞的系統。這也意味著，通常情況下，容器的生命周期比服務器要短，攻擊者能夠使用駐留后門或繼續深入網絡的時間段，也就更短了。
另外，每部署一個新容器都要漏洞利用一次，反復進行漏洞利用，也會增加被其他安全解決方案發現的風險，比如IDS/IPS或者文件完整性監視等。
容器安全優勢突出，特別是與主機進程和網絡的隔離。然而，錯誤配置或疏忽大意，仍然會危及本應安全的態勢。
保護Docker安全，與保障傳統基礎設施安全，有很多相通之處。不過，面臨的挑戰雖相似，Docker安全也有其獨有的一些困難。
1. 提權攻擊
Docker安全防御面臨的一個常見威脅，就是提權攻擊。攻擊者的目標是突破容器，獲得Docker主機的訪問權；他們有大把機會這么做。
2. 漏洞
Linux內核中的漏洞，比如廣為人知的“臟牛”漏洞，可被用于提權，從容器染指主機。應使用漏洞管理工具，來確保主機及其上容器均打完補丁，沒有漏洞。
3. 文件系統掛載
將主機文件系統掛載到容器，容器便可以寫入主機文件了。如果掛載太過寬泛，或者配置有誤，攻擊者會有大把機會利用各種文件寫入方法來提權。重要的主機系統目錄絕對不能掛載到容器中。
4. 特權用戶
由于上述文件系統濫用可能性的存在，可以運行Docker容器的主機用戶，便成了實際上的root用戶。一定不能讓非root用戶來運行Docker容器，或者把他們加入到Docker用戶組里。
Docker Daemon 具有為Docker進程指定用戶名字空間的 -userns 選項。啟用用戶名字空間選項時，容器中的root用戶會被映射成主機上的非特權用戶。使用非特權用戶名字空間，是抵御提權攻擊的重要防御措施。
Docker運行時也提供 -user 選項，可用于以非特權用戶在容器內執行命令，而不是以默認的root用戶來執行。正如我們這數十年來習得的安全操作——沒必要用root用戶的時候就不要用。同樣的邏輯也適用于容器使用。
5. 特權容器
以Docker的 -privileged 標記運行的容器，可以控制設備，并如上文所述進行基于文件系統的攻擊；此類容器對主機資源的訪問權，幾乎與主機本身一樣。特權容器可用于嵌套Docker-in-Docker，但使用該功能時必須極度小心。
6. 拒絕服務
默認情況下，容器對所使用的資源沒有任何限制。這就很容易導致拒絕服務的情況。有必要對失控的資源使用采取緩解措施，比如Docker cgroup 功能。
7. CPU耗盡
失控的計算過程，可耗盡主機上所有可用CPU資源。可對每個容器定義 -cpus 或-cpu-quota，以限制該容器可用的最大主機處理器時間。
8. 內存耗盡
Docker提供 -memory 運行時選項，可以限制每個容器可用的最大內存。
9. ULIMITS
惡意或被入侵容器，可能采用簡單的fork炸彈攻擊，讓主機系統完全無法響應。Docker提供了 -ulimit 運行時選項，對每個容器可打開文件及進程的數量加以限制，讓它們無法搞癱主機。
10. 橫向移動
橫向移動是描述攻擊者在被黑系統間跳轉的術語，用于橫向移動的技術，同樣適用于容器空間。默認情況下，所有Docker容器都能相互通信。使用Docker的 -icc、-link 和 -iptables 標識，你就對容器內相互通信有了細粒度控制，可以防止從被黑容器發起的網絡攻擊，讓主機和網絡更加安全。
總結
本文開頭，我們提出了在容器中運行 Apache Struts 是否能避免1.43億客戶記錄被泄的問題。
文中也提出了多種緩解措施，但我們無法確知哪些方法在我們設想的場景中被用到。使用容器，采用上述任何配置建議，都有可能阻礙或阻止攻擊者，爭取到更多的發現時間，或者干脆讓他們放棄攻擊而轉向其他更容易得手的目標。
文中提到的漏洞，CVE-2017-5638，可使脆弱系統上的Webserver用戶得以執行任意指令或運行任意程序。因此，可能的結果就是，只能以容器中受限Webserver用戶權限執行指令的攻擊者，卻依然對客戶記錄擁有訪問權。該Webserver用戶必能訪問數據，無論存儲在本地，還是需要憑證和權限從數據庫或網絡中取得。
只有系統從一開始就是最新的，才有可能避免被黑。采用漏洞管理解決方案，比如 Tripwire IP360，有助確定主機及容器中是否存在漏洞。使用Docker的基礎設施即代碼和連續部署功能，可以增加部署出補丁完備容器的概率，或者更早發現攻擊。
很明顯，從一開始就確保系統和應用保持更新，是最佳防線。請務必從最初就考慮到安全，并在安全運維開發周期的每一階段都嚴格應用安全方法。
于是，容器真的是安全救星嗎？可能吧，看你怎么做了。
京公網安備 11010502049343號