影響到1.43億客戶記錄的Equifax數(shù)據(jù)泄露事件，現(xiàn)在恐怕無人不知了。Equifax報告稱，攻擊者使用了編號為CVE-2017-5638的Apache Struts漏洞。

Equifax并沒有在容器中運行其脆弱Struts應(yīng)用，但如果他們這么做了呢?容器當(dāng)然更加安全，于是整個糟糕的情況就可以避免掉了，對吧?

未必。

容器固有的基礎(chǔ)設(shè)施即代碼，具有多個安全優(yōu)勢。連續(xù)設(shè)置部署新容器是標(biāo)準(zhǔn)操作，因而部署補丁完善的軟件所面臨的宕機風(fēng)險也就更小。一般都會從干凈的容器開始，所以用不著修復(fù)已經(jīng)被破壞的系統(tǒng)。這也意味著，通常情況下，容器的生命周期比服務(wù)器要短，攻擊者能夠使用駐留后門或繼續(xù)深入網(wǎng)絡(luò)的時間段，也就更短了。

另外，每部署一個新容器都要漏洞利用一次，反復(fù)進行漏洞利用，也會增加被其他安全解決方案發(fā)現(xiàn)的風(fēng)險，比如IDS/IPS或者文件完整性監(jiān)視等。

容器安全優(yōu)勢突出，特別是與主機進程和網(wǎng)絡(luò)的隔離。然而，錯誤配置或疏忽大意，仍然會危及本應(yīng)安全的態(tài)勢。

保護Docker安全，與保障傳統(tǒng)基礎(chǔ)設(shè)施安全，有很多相通之處。不過，面臨的挑戰(zhàn)雖相似，Docker安全也有其獨有的一些困難。

1. 提權(quán)攻擊

Docker安全防御面臨的一個常見威脅，就是提權(quán)攻擊。攻擊者的目標(biāo)是突破容器，獲得Docker主機的訪問權(quán);他們有大把機會這么做。

2. 漏洞

Linux內(nèi)核中的漏洞，比如廣為人知的“臟牛”漏洞，可被用于提權(quán)，從容器染指主機。應(yīng)使用漏洞管理工具，來確保主機及其上容器均打完補丁，沒有漏洞。

3. 文件系統(tǒng)掛載

將主機文件系統(tǒng)掛載到容器，容器便可以寫入主機文件了。如果掛載太過寬泛，或者配置有誤，攻擊者會有大把機會利用各種文件寫入方法來提權(quán)。重要的主機系統(tǒng)目錄絕對不能掛載到容器中。

4. 特權(quán)用戶

由于上述文件系統(tǒng)濫用可能性的存在，可以運行Docker容器的主機用戶，便成了實際上的root用戶。一定不能讓非root用戶來運行Docker容器，或者把他們加入到Docker用戶組里。

Docker Daemon 具有為Docker進程指定用戶名字空間的 -userns 選項。啟用用戶名字空間選項時，容器中的root用戶會被映射成主機上的非特權(quán)用戶。使用非特權(quán)用戶名字空間，是抵御提權(quán)攻擊的重要防御措施。

Docker運行時也提供 -user 選項，可用于以非特權(quán)用戶在容器內(nèi)執(zhí)行命令，而不是以默認的root用戶來執(zhí)行。正如我們這數(shù)十年來習(xí)得的安全操作——沒必要用root用戶的時候就不要用。同樣的邏輯也適用于容器使用。

5. 特權(quán)容器

以Docker的 -privileged 標(biāo)記運行的容器，可以控制設(shè)備，并如上文所述進行基于文件系統(tǒng)的攻擊;此類容器對主機資源的訪問權(quán)，幾乎與主機本身一樣。特權(quán)容器可用于嵌套Docker-in-Docker，但使用該功能時必須極度小心。

6. 拒絕服務(wù)

默認情況下，容器對所使用的資源沒有任何限制。這就很容易導(dǎo)致拒絕服務(wù)的情況。有必要對失控的資源使用采取緩解措施，比如Docker cgroup 功能。

7. CPU耗盡

失控的計算過程，可耗盡主機上所有可用CPU資源。可對每個容器定義 -cpus 或-cpu-quota，以限制該容器可用的最大主機處理器時間。

8. 內(nèi)存耗盡

Docker提供 -memory 運行時選項，可以限制每個容器可用的最大內(nèi)存。

9. ULIMITS

惡意或被入侵容器，可能采用簡單的fork炸彈攻擊，讓主機系統(tǒng)完全無法響應(yīng)。Docker提供了 -ulimit 運行時選項，對每個容器可打開文件及進程的數(shù)量加以限制，讓它們無法搞癱主機。

10. 橫向移動

橫向移動是描述攻擊者在被黑系統(tǒng)間跳轉(zhuǎn)的術(shù)語，用于橫向移動的技術(shù)，同樣適用于容器空間。默認情況下，所有Docker容器都能相互通信。使用Docker的 -icc、-link 和 -iptables 標(biāo)識，你就對容器內(nèi)相互通信有了細粒度控制，可以防止從被黑容器發(fā)起的網(wǎng)絡(luò)攻擊，讓主機和網(wǎng)絡(luò)更加安全。

總結(jié)

本文開頭，我們提出了在容器中運行 Apache Struts 是否能避免1.43億客戶記錄被泄的問題。

文中也提出了多種緩解措施，但我們無法確知哪些方法在我們設(shè)想的場景中被用到。使用容器，采用上述任何配置建議，都有可能阻礙或阻止攻擊者，爭取到更多的發(fā)現(xiàn)時間，或者干脆讓他們放棄攻擊而轉(zhuǎn)向其他更容易得手的目標(biāo)。

文中提到的漏洞，CVE-2017-5638，可使脆弱系統(tǒng)上的Webserver用戶得以執(zhí)行任意指令或運行任意程序。因此，可能的結(jié)果就是，只能以容器中受限Webserver用戶權(quán)限執(zhí)行指令的攻擊者，卻依然對客戶記錄擁有訪問權(quán)。該Webserver用戶必能訪問數(shù)據(jù)，無論存儲在本地，還是需要憑證和權(quán)限從數(shù)據(jù)庫或網(wǎng)絡(luò)中取得。

只有系統(tǒng)從一開始就是最新的，才有可能避免被黑。采用漏洞管理解決方案，比如 Tripwire IP360，有助確定主機及容器中是否存在漏洞。使用Docker的基礎(chǔ)設(shè)施即代碼和連續(xù)部署功能，可以增加部署出補丁完備容器的概率，或者更早發(fā)現(xiàn)攻擊。

很明顯，從一開始就確保系統(tǒng)和應(yīng)用保持更新，是最佳防線。請務(wù)必從最初就考慮到安全，并在安全運維開發(fā)周期的每一階段都嚴格應(yīng)用安全方法。

于是，容器真的是安全救星嗎?可能吧，看你怎么做了。