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

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

未必。

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

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

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

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

1. 提權(quán)攻擊

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

2. 漏洞

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

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

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

4. 特權(quán)用戶

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

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

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

5. 特權(quán)容器

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

6. 拒絕服務(wù)

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

7. CPU耗盡

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

8. 內(nèi)存耗盡

Docker提供 -memory 運(yùn)行時(shí)選項(xiàng)，可以限制每個(gè)容器可用的最大內(nèi)存。

9. ULIMITS

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

10. 橫向移動(dòng)

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

總結(jié)

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

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

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

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

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

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