趙立農(nóng)，曹 莉，曾藝驍

（中國移動(dòng)通信集團(tuán)重慶有限公司，重慶 401121）

0 引言

Docker一般以集群的方式提供服務(wù)，是大量容器協(xié)作完成的一項(xiàng)任務(wù)，需要快速分發(fā)和啟動(dòng)大量Docker容器。加速Docker鏡像的分發(fā)環(huán)節(jié)意義重大。Docker可以做到更快速的交付和部署，更高效的資源利用，更輕松的遷移和拓展，更簡單的更新管理，因此在開發(fā)和運(yùn)維領(lǐng)域應(yīng)用廣泛。

1 研究背景

1.1 背景分析

當(dāng)今，容器安全相關(guān)方向的研究主要表現(xiàn)在集成結(jié)構(gòu)本身的安全機(jī)制和容器關(guān)聯(lián)主機(jī)相互的安全匹配。然而，容器固有的屬性包括容器、各種運(yùn)行時(shí)庫和其他相關(guān)的開源項(xiàng)目表現(xiàn)出高度自動(dòng)化。在容器自動(dòng)化方面，有效的解決方案是能夠加快代碼開發(fā)和部署環(huán)節(jié)，往往應(yīng)用在各種平臺(tái)、具有不同鏡像提供商的供應(yīng)鏈結(jié)構(gòu)以及第三方系統(tǒng)，能夠有效解決對(duì)數(shù)據(jù)完整性強(qiáng)化和可靠性提升的要求。但是，這可能導(dǎo)致漏洞，即惡意用戶可能會(huì)滲透這些漏洞。資料顯示，某安全研究機(jī)構(gòu)發(fā)布的關(guān)于Docker鏡像安全的報(bào)告約有30%官方倉庫的鏡像存在安全風(fēng)險(xiǎn)，如Shellshock、Heartbleed以及Pooodle等高危漏洞[1]。

目前，虛擬機(jī)鏡像的研究已經(jīng)成熟，包括多播、P2P以及共享存儲(chǔ)等技術(shù)，為Docker鏡像的分發(fā)提供了參考。但是，Docker鏡像具有不同于虛擬機(jī)鏡像的獨(dú)特特征，需要進(jìn)行相應(yīng)的設(shè)計(jì)和優(yōu)化。同時(shí)，數(shù)據(jù)中心網(wǎng)絡(luò)不同于互聯(lián)網(wǎng)。在數(shù)據(jù)中心，網(wǎng)絡(luò)速度快、延遲低，服務(wù)穩(wěn)定，所有節(jié)點(diǎn)目標(biāo)相同。因此，在設(shè)計(jì)Docker鏡像的分發(fā)方法時(shí)，還應(yīng)充分利用數(shù)據(jù)中心的特點(diǎn)。

1.2 研究現(xiàn)狀分析

目前，國內(nèi)外對(duì)云環(huán)境下虛擬機(jī)鏡像安全性的研究相對(duì)較少。這種分離允許管理員將安全修補(bǔ)程序更新到基本級(jí)別（以實(shí)現(xiàn)更新修補(bǔ)程序的目的）。Manu A R等人通過分析和研究基于Docker容器的PaaS云平臺(tái)的相關(guān)安全性，對(duì)比和分析基于Hypervisor和其他容器的PaaS所不同的安全性，提出從滲透測試的多角度和多維度強(qiáng)化容器安全的MST[2]。郭秉楠通過對(duì)PDFDA算法展開研究，設(shè)計(jì)了一套基于虛擬化技術(shù)的網(wǎng)絡(luò)安全服務(wù)功能鏈編排系統(tǒng)[3]。同時(shí)，Amr A M等人通過分析宿主機(jī)的應(yīng)用效果與容器運(yùn)行環(huán)節(jié)中潛在的安全漏洞評(píng)估和差異化比對(duì)[4]，表明Docker容器能夠?qū)崿F(xiàn)的攻擊面相對(duì)于主機(jī)更廣。岑義濤從容器漏洞方向出發(fā)展開研究，總結(jié)了Docker容器哪些方面需要安全加固[5]，如登錄環(huán)節(jié)的相關(guān)信息傳輸、Docker程序的提權(quán)環(huán)節(jié)安全性限制以及出入容器的相關(guān)環(huán)節(jié)流量監(jiān)控防護(hù)。Catuogno L等人研究發(fā)現(xiàn)，與虛擬機(jī)和hypervisor相比，Linux容器在網(wǎng)絡(luò)、磁盤、內(nèi)存管理、啟動(dòng)和編譯速度以及總體處理性能方面顯示出了極大優(yōu)勢。他們質(zhì)疑在Linux容器中運(yùn)行服務(wù)是否比直接在基于主機(jī)的操作系統(tǒng)上運(yùn)行服務(wù)更安全。因此，使用Docker v1.10進(jìn)行了一系列實(shí)驗(yàn)，以評(píng)估在Docker容器中運(yùn)行服務(wù)的主機(jī)的攻擊面，并將其與在本文中描述的Debian-Jessie基本操作系統(tǒng)上運(yùn)行相同服務(wù)的主機(jī)進(jìn)行了比較。漏洞評(píng)估顯示，容器會(huì)給主機(jī)帶來新的攻擊面[6]。

資料研究發(fā)現(xiàn)，關(guān)于Docker容器受到的攻擊往往是較嚴(yán)重、影響范圍廣泛的遠(yuǎn)程訪問帶來的問題，尤其是配置欠合理易引起被遠(yuǎn)程攻擊者侵入并通過改變私鑰進(jìn)而獲得入侵宿主機(jī)的root權(quán)限。Combe T等學(xué)者通過相關(guān)研究，總結(jié)了Docker容器的常有攻擊主要來自于不安全的離線路徑[7]，如本地配置安全問題、安全措施不到位的訪問控制手段和策略以及容器使用功能加載包含漏洞的鏡像。文獻(xiàn)[5]提到了Docker在網(wǎng)絡(luò)方面的常有攻擊點(diǎn)，包括ARP攻擊、容器間的嗅探、IPtable的漏洞利用和對(duì)IPtable的飽和攻擊，同時(shí)統(tǒng)計(jì)了公有云平臺(tái)和私有云平臺(tái)的安全事件，發(fā)現(xiàn)公共使用的云平臺(tái)的安全問題更嚴(yán)重。Chelladhurai J等人針對(duì)拒絕容器服務(wù)攻擊對(duì)Docker容器的主要威脅進(jìn)行研究，提出了關(guān)于Docker在拒絕服務(wù)攻擊行為方面的檢測與防御方案[8]。它主要針對(duì)容器的內(nèi)存資源管理使用，推薦內(nèi)存限制的DoS安全防御策略。實(shí)驗(yàn)表明，該安全策略能夠有效緩解內(nèi)存資源消耗方面的DoS攻擊。但是，相關(guān)研究并沒有有效解決當(dāng)下威脅最大的0day、1day漏洞的安全問題，也沒有研究提出有效手段來防御該類攻擊。

楊文林等人的研究對(duì)象是Docker的關(guān)鍵部件，通過分析Docker容器在文件系統(tǒng)隔離、進(jìn)程及通信隔離、設(shè)備管理及宿主機(jī)資源限制、網(wǎng)絡(luò)隔離和鏡像傳輸4個(gè)方面的脆弱性，針對(duì)性地對(duì)容器進(jìn)行安全增強(qiáng)，提出了部件配置和共享內(nèi)核的先進(jìn)理論[9]，探究了其程序的脆弱點(diǎn)和風(fēng)險(xiǎn)要素，分析相關(guān)的潛在漏洞，模擬威脅點(diǎn)的處理方案和解決措施，構(gòu)建起完整的“能夠高效解決現(xiàn)存漏洞-監(jiān)控安全報(bào)警-控制措施程序錯(cuò)亂”的一套具備防御能力的監(jiān)控報(bào)警機(jī)制措施，形成了防御入侵攻擊行為方案，但研究成果并沒有論證可行性和效率的量化指標(biāo)。李平平通過LKM技術(shù)建立和實(shí)現(xiàn)Docker容器相關(guān)的進(jìn)程對(duì)，使得內(nèi)核資源能夠有效訪問控制機(jī)制結(jié)構(gòu)框架[10]。極致化的體系構(gòu)成能夠從內(nèi)核層建立起容器執(zhí)行進(jìn)程對(duì)宿主機(jī)的有效訪問控制和安全預(yù)防，且實(shí)現(xiàn)內(nèi)核代碼模塊對(duì)容器內(nèi)執(zhí)行程序進(jìn)程的實(shí)時(shí)跟蹤和反饋，進(jìn)一步形成了操作系統(tǒng)層面有效攔截容器內(nèi)進(jìn)程惡意程序?qū)λ拗鳈C(jī)攻擊和潛伏竊取資源的訪問保護(hù)。陳莉君提出了基于LKM研究技術(shù)的一套完整的資源信息隔離措施辦法[11]，建立起能夠有效調(diào)節(jié)程序劫持代碼，借助程序的進(jìn)程環(huán)節(jié)，利用Cgroup信息維護(hù)、修改、讀取相關(guān)的ProcFS文件內(nèi)容，進(jìn)而建立起容器內(nèi)特定區(qū)域信息資源的安全隔離防御。Combe T建議使用更高級(jí)別的抽象研究策略（主要表現(xiàn)在任務(wù)、復(fù)制控制器和遠(yuǎn)程持久存儲(chǔ)方面）以完全消除對(duì)于主機(jī)的依賴，從而促進(jìn)容器實(shí)現(xiàn)更好的隔離[12]。王鵑公開了一個(gè)可信增強(qiáng)的Docker容器[13]，針對(duì)Docker容器目前存在的鏡像被篡改、容器惡意進(jìn)程及非授權(quán)通信問題，利用可信計(jì)算的信任鏈技術(shù)，構(gòu)造了一條從硬件到容器內(nèi)部進(jìn)程和文件的信任鏈，同時(shí)增加了包括進(jìn)程監(jiān)控、文件系統(tǒng)度量以及網(wǎng)絡(luò)監(jiān)控3大功能于一體的安全防護(hù)模塊，從而全方位對(duì)Docker進(jìn)行度量與細(xì)粒度的監(jiān)控，保護(hù)容器及鏡像不被篡改，同時(shí)限制容器網(wǎng)絡(luò)通信行為并監(jiān)控容器內(nèi)部進(jìn)程，極大地提高了Docker容器的安全性。

Dhakate S分析并研究了一種基于Docker容器的、輕量級(jí)的、采用分布式云平臺(tái)的安全監(jiān)控機(jī)制，通過建立起檢測、報(bào)告、監(jiān)控以及報(bào)警等多種功能的整體架構(gòu)，形成一套一體化的整體性云監(jiān)控平臺(tái)系統(tǒng)[14]。Salvatore P站在前瞻性的角度，分析容器監(jiān)控未來和現(xiàn)在面臨的問題和挑戰(zhàn)，主要包括監(jiān)控引擎如何應(yīng)對(duì)容器生命周期的動(dòng)態(tài)和快速變更，錯(cuò)綜復(fù)雜的發(fā)展環(huán)節(jié)中如何能夠?qū)崿F(xiàn)用戶更多的便捷性。因此，提升容器監(jiān)控系統(tǒng)的自動(dòng)化程度，以便能夠用于分布式集群環(huán)境。

2 Docker容器鏡像安全問題

鏡像安全問題主要表現(xiàn)在鏡像校驗(yàn)和訪問控制兩個(gè)方面。

鏡像校驗(yàn)通常是能夠保證鏡像完整性的主要途徑，從而有效避免鏡像程序被篡改破壞。Docker容器的鏡像倉庫里所涉及的全部鏡像都各自對(duì)應(yīng)一個(gè)manifest特點(diǎn)文件，這個(gè)文件主要含有鏡像標(biāo)簽、鏡像所屬命名空間、程序的校驗(yàn)方法、鏡像運(yùn)行需要的信息及其文件程序的簽名信息。執(zhí)行環(huán)節(jié)中，用戶在pull鏡像環(huán)節(jié)往往會(huì)多次自動(dòng)運(yùn)行哈希驗(yàn)證程序。如果通過鏡像的digest來pull鏡像，會(huì)驗(yàn)證manifest的digest與傳入的digest是否一致。在鏡像的環(huán)節(jié)中還會(huì)有manifest中鏡像ID來實(shí)時(shí)獲取鏡像配置文件的更新。鏡像環(huán)節(jié)還能夠借助配置文件內(nèi)容生成digest，最后得出驗(yàn)證是否與鏡像ID一致的結(jié)果。在下載manifest文件能夠鏡像后，主要是依照鏡像文件具體的內(nèi)容逐步計(jì)算和校驗(yàn)“diffID”相關(guān)代碼，并與鏡像配置文件中有關(guān)聯(lián)的diffID進(jìn)行進(jìn)一步的比較驗(yàn)證環(huán)節(jié)。執(zhí)行環(huán)節(jié)的每一步數(shù)據(jù)傳輸過后，往往都要有本地計(jì)算相關(guān)的一些校驗(yàn)環(huán)節(jié)，以及同時(shí)比對(duì)與前一步保存的文件的可靠結(jié)果分析。結(jié)果比對(duì)后，如果驗(yàn)證失敗，能夠警示并伴隨著輸出相關(guān)警告信息，有效提醒鏡像相關(guān)下載環(huán)節(jié)中可能已經(jīng)出現(xiàn)安全問題，如文件損壞或者鏡像內(nèi)容被人為侵入和篡改。

目前，Docker使用一個(gè)中心驗(yàn)證服務(wù)器來完成Docker鏡像倉庫的訪問權(quán)限控制。通過操作每個(gè)Docker對(duì)應(yīng)的客戶端，開展相關(guān)Registry的一系列push/pull操作，得到正版授權(quán)文件official.json文本，獲得registry對(duì)應(yīng)目錄的相關(guān)授權(quán)信息和授權(quán)信息簽名，進(jìn)一步完成在Docker Daemon啟動(dòng)時(shí)的MemoryGraph加載。每次pull文件鏡像時(shí)執(zhí)行MemoryGraph驗(yàn)證授權(quán)信息的時(shí)效性（即是否過期），并且驗(yàn)證信息的匹配性、完整性等，同時(shí)檢查相關(guān)讀寫權(quán)限的安全性。

2.1 Docker容器鏡像安全風(fēng)險(xiǎn)

2.1.1 Docker容器鏡像沒有統(tǒng)一監(jiān)管

除了Docker Hub外，還有大量的第三方鏡像倉庫，如網(wǎng)易163、中國科技大學(xué)、道云以及阿里云等。第三方鏡像倉庫就像一個(gè)混亂的Android應(yīng)用市場，缺乏統(tǒng)一的監(jiān)管，帶來了潛在的安全風(fēng)險(xiǎn)。

2.1.2 鏡像安全漏洞多

相關(guān)研究報(bào)告顯示，Docker中心超過30%的官方鏡像包含高風(fēng)險(xiǎn)漏洞，其中近70%的鏡像包含高風(fēng)險(xiǎn)或中等風(fēng)險(xiǎn)漏洞。

2.1.3 黑客上傳存在木馬病毒的鏡像

如果黑客在制作鏡像時(shí)嵌入特洛伊木馬和后門等惡意軟件，并將惡意鏡像上載到公共倉庫（如Docker中心），則用戶的容器環(huán)境從一開始就不安全。例如，Docker支持gzip、bzip2和XZ這3種壓縮算法，其中Gzip和bzip2使用go標(biāo)準(zhǔn)庫，因此相對(duì)安全。XZ不使用本機(jī)go實(shí)現(xiàn)，且使用由C編寫的XZ utils開源項(xiàng)目，因此存在惡意寫入C程序的可能性。一旦編譯，將導(dǎo)致執(zhí)行任意代碼漏洞。只要存在漏洞，當(dāng)執(zhí)行Docker拉取鏡像時(shí)，整個(gè)系統(tǒng)可能會(huì)被破壞。

2.1.4 直接運(yùn)行未經(jīng)檢查的鏡像

設(shè)計(jì)編程者通常從Docker的官方Docker中心存儲(chǔ)庫下載鏡像，其中一些鏡像來自開發(fā)鏡像中相應(yīng)軟件的官方組織，但大量鏡像來自第三方組織甚至個(gè)人。在應(yīng)用程序的整個(gè)生命周期中，設(shè)計(jì)編程者、測試人員、操作人員和維護(hù)人員會(huì)根據(jù)不同的要求下載和運(yùn)行鏡像，因此在容器運(yùn)行前檢查鏡像非常重要。如果直接運(yùn)行未經(jīng)檢查的鏡像，可能會(huì)給生成環(huán)境帶來安全風(fēng)險(xiǎn)。

2.2 Docker鏡像分析

為了設(shè)計(jì)一個(gè)適合Docker鏡像特征的分布系統(tǒng)，有必要深刻認(rèn)識(shí)鏡像特征和鏡像層的分布。然而，當(dāng)前對(duì)于鏡像特征和鏡像層的分布沒有系統(tǒng)的統(tǒng)計(jì)和研究。為了深入理解Docker鏡像特征，設(shè)計(jì)更符合Docker鏡像特征的分布系統(tǒng)，下面分析Docker鏡像的屬性。

2.2.1 鏡像大小分布

通過收集多方數(shù)據(jù)，大多數(shù)鏡像在100 MB和1 GB之間，鏡像平均大小為386 MB。與虛擬機(jī)鏡像的GB級(jí)別相比，它并不大。但是，隨著Docker技術(shù)的日益普及，以及運(yùn)行Docker容器的群集數(shù)量和規(guī)模不斷增加，應(yīng)用程序可能需要啟動(dòng)數(shù)萬臺(tái)計(jì)算機(jī)進(jìn)行部署。

如果眾多服務(wù)器同時(shí)下載Docker鏡像，將影響Docker鏡像倉庫的工作效率，且在正常情況下不能提供足夠的下載量，進(jìn)而影響整個(gè)集群的工作效率。

2.2.2 鏡像的相似性

Docker鏡像采用分層機(jī)制，因此多個(gè)鏡像層可能公用一個(gè)基礎(chǔ)鏡像層。在所統(tǒng)計(jì)的鏡像中，約35%的鏡像有一個(gè)共同的、大小為125 MB的鏡像層。這些鏡像分別為nginx、registry、redis、mysql、node、postgres、wordpress、elasticsearch、rabbitmq、jenkins以及l(fā)ogstash?？梢钥吹?，具有公共鏡像層的鏡像很常見，鏡像層的大小占整個(gè)鏡像的很大比例。因此，當(dāng)主機(jī)需要下載鏡像時(shí)，在下載其他鏡像時(shí)可能下載了鏡像的一些鏡像層。Docker鏡像的這個(gè)功能更有利于BT協(xié)議下載模式。由于某些計(jì)算機(jī)可能下載了一些鏡像層，因此這些計(jì)算機(jī)可以用作種子服務(wù)器。它可以為沒有鏡像層的其他主機(jī)提供數(shù)據(jù)，進(jìn)一步減輕了倉庫壓力，加快了整個(gè)群集的下載和傳輸速度。

2.3 Docker容器配置安全風(fēng)險(xiǎn)

2.3.1 Docker守護(hù)進(jìn)程配置風(fēng)險(xiǎn)

按照Docker的實(shí)現(xiàn)架構(gòu)，Docker服務(wù)默認(rèn)監(jiān)聽在Unix Socket上，如unix:///var/run/docker.sock。為了實(shí)現(xiàn)集群管理，Docker官方提供了一個(gè)遠(yuǎn)程管理接口的REST API，允許通過TCP遠(yuǎn)程訪問Docker服務(wù)。

例如，在使用Docker Swarm時(shí)，Docker節(jié)點(diǎn)會(huì)開放一個(gè)TCP端口2375綁定在0.0.0.0上。

當(dāng)執(zhí)行一些完全沒有加密程序和沒有任何訪問限制的Docker Remote API服務(wù)的情況下，通常是相當(dāng)危險(xiǎn)的。需要注意默認(rèn)端口連接公開Internet的情況。如果被攻擊者惡意捕獲侵入，攻擊者以此開展一些程序和文件信息數(shù)據(jù)的訪問瀏覽，再破解相關(guān)信息、惡意竊取和篡改，最終將會(huì)引起敏感信息泄露丟失。此外，它存在刪除容器上固有數(shù)據(jù)的風(fēng)險(xiǎn)。例如，惡意攻擊篡改容器主機(jī)上的核心關(guān)鍵敏感信息，捕獲相關(guān)的服務(wù)器根權(quán)限，用來修改主機(jī)文件和敏感信息資源，最后控制主機(jī)服務(wù)器。

2.3.2 Docker其他安全配置風(fēng)險(xiǎn)

通過網(wǎng)絡(luò)、鏡像、容器、倉庫、Docker所依賴的Linux內(nèi)核以及Docker軟件本身總計(jì)6個(gè)方面開展相關(guān)的分析，進(jìn)一步總結(jié)Docker容器存在的安全威脅。

（1）關(guān)于Docker網(wǎng)絡(luò)安全方面的威脅。Docker容器使用網(wǎng)絡(luò)橋接方法進(jìn)行一些連接。需要主機(jī)上創(chuàng)建一個(gè)虛擬橋Dokcer0充當(dāng)開關(guān)。一般來說，虛擬網(wǎng)橋拒絕過濾傳輸帶來的一些數(shù)據(jù)包，所以得出的連接模式往往易受到ARP相關(guān)的欺騙攻擊和MAC相關(guān)的泛洪攻擊，且位于同一主機(jī)中的容器更易關(guān)聯(lián)受感染容器周邊的網(wǎng)絡(luò)攻擊。假如出現(xiàn)Docker run+P命令執(zhí)行相關(guān)外部服務(wù)端口時(shí)，一旦出現(xiàn)操作不當(dāng)，極易導(dǎo)致主機(jī)相關(guān)網(wǎng)卡的各個(gè)暴露端口形成映射，以偵聽和竊取外部連接，最終帶來嚴(yán)重的安全風(fēng)險(xiǎn)。

（2）Docker鏡像安全威脅。在鏡像構(gòu)建程序的建立和執(zhí)行中，設(shè)計(jì)編程者可能會(huì)無意中向鏡像添加敏感信息（包括數(shù)據(jù)庫身份驗(yàn)證密碼），會(huì)給部署在生產(chǎn)環(huán)境中的應(yīng)用程序帶來安全風(fēng)險(xiǎn)。該鏡像很容易被利用傳輸和其他部署使用，同時(shí)會(huì)為病毒后門潛伏的鏡像建立起一些惡意傳輸通道提供便利條件。分析和研究發(fā)現(xiàn)，在鏡像信息的具體構(gòu)建環(huán)節(jié)中，執(zhí)行者使用的主要關(guān)鍵鏡像往往較大。建議使用現(xiàn)有的鏡像操作前，有必要認(rèn)真核對(duì)檢測原有鏡像中的安全問題，尤其是要核查存在的漏洞問題。在鏡像相關(guān)的制作環(huán)節(jié)中，盡力降低對(duì)不相關(guān)的程序和信息依賴庫的使用和引入。在鏡像漏洞相關(guān)方面掃描，雖然存在安全掃描程序軟件（如Docker安全掃描），但是很多軟件往往無法提供有效的解決方案來修復(fù)鏡像漏洞。

（3）Docker容器安全威脅。容器運(yùn)行時(shí)，軟件（如Docker）漏洞可能導(dǎo)致“容器逃逸”等情況的發(fā)生，導(dǎo)致容器被植入木馬病毒，如挖礦程序等。當(dāng)容器以root權(quán)限運(yùn)行時(shí)，容器中的用戶可以獲取主機(jī)的資源；配置容器重新啟動(dòng)策略時(shí)，如果容器重新啟動(dòng)時(shí)間不受限制，頻繁重新啟動(dòng)程序運(yùn)行會(huì)耗盡計(jì)算機(jī)運(yùn)行資源，并會(huì)引起拒絕服務(wù)攻擊；如果將/root/目錄加載到容器中，可能會(huì)導(dǎo)致容器逃逸攻擊。

（4）Docker倉庫安全威脅。為了確保鏡像的傳輸安全性，在守護(hù)進(jìn)程和注冊(cè)表之間的關(guān)聯(lián)程序之間開啟TLS安全管控監(jiān)督機(jī)制。為了監(jiān)督預(yù)防鏡像被篡改問題發(fā)生，需開啟鏡像簽名和驗(yàn)證功能，但是仍然存在一些問題。Docker中心有數(shù)千名設(shè)計(jì)編程者，所有的設(shè)計(jì)編程者都能夠使用他的私鑰對(duì)鏡像進(jìn)行程序電子簽名。但是，這種簽名驗(yàn)證來預(yù)防安全問題的機(jī)制無法從源頭保證設(shè)計(jì)編程者的可信度。Docker中心實(shí)現(xiàn)了用戶升級(jí)鏡像的自動(dòng)生成功能，允許Docker中心跟蹤指定的GitHub或存儲(chǔ)。提交新項(xiàng)目時(shí)，它會(huì)自動(dòng)重建鏡像，并傳遞鏡像部署連接實(shí)際的生產(chǎn)環(huán)境。此環(huán)節(jié)中，依賴項(xiàng)會(huì)自動(dòng)從第三方資源平臺(tái)下載。第三方資源平臺(tái)可能是不安全的鏈接，依賴項(xiàng)可能在傳輸環(huán)節(jié)中被惡意篡改，是Docker的不安全因素。

（5）Linux內(nèi)核支持安全威脅。大量研究人員致力于查找可用于執(zhí)行任意代碼或執(zhí)行本地特權(quán)攻擊的內(nèi)核漏洞。發(fā)現(xiàn)的大量內(nèi)核漏洞是基于與主機(jī)內(nèi)核共享機(jī)制的Docker容器的一大威脅。

（6）Docker軟件安全威脅。實(shí)際上，Docker用戶組不能保證主機(jī)的安全性。在Docker守護(hù)進(jìn)程分析鏡像和Dockerfile文件的環(huán)節(jié)，如果無法很好地篩選這些輸入數(shù)據(jù)，則可能會(huì)出現(xiàn)嚴(yán)重的安全問題。歷史上有一個(gè)嚴(yán)重的事件觸發(fā)漏洞，其構(gòu)造了一個(gè)特殊的Dockerfile壓縮文件，以獲得在編譯時(shí)執(zhí)行任意代碼的權(quán)利。在早期版本中，本地用戶的授權(quán)問題也出現(xiàn)在Docker鏡像中特殊軟鏈接的構(gòu)建中。

3 Docker鏡像安全掃描研究

鏡像文件的生命周期具體如下：

（1）用戶將定制好的鏡像上傳（發(fā)布）到云平臺(tái)的鏡像庫中；

（2）云管理員管理與維護(hù)鏡像庫內(nèi)的鏡像；

（3）鏡像通過克隆復(fù)制一份新的鏡像；

（4）鏡像通過快照保存鏡像的某個(gè)狀態(tài)或通過回滾將鏡像還原到某個(gè)狀態(tài)；

（5）云平臺(tái)分發(fā)鏡像，創(chuàng)建一個(gè)新的虛擬機(jī)，使離線鏡像轉(zhuǎn)為在線狀態(tài)；

（6）虛擬機(jī)在線狀態(tài)通過關(guān)機(jī)銷毀虛擬機(jī)及對(duì)應(yīng)的鏡像（目前大多的云平臺(tái)都使用這種方式）；

（7）刪除鏡像庫內(nèi)的鏡像。

3.1 病毒木馬檢測

通過圖像掃描，可以在鏡像文件中找到網(wǎng)絡(luò)外殼、二進(jìn)制特洛伊木馬以及病毒等惡意文件。每個(gè)容器鏡像由一系列“鏡像層”組成，在解包后需要分析和掃描這些層以查找安全漏洞。從CVE漏洞、木馬病毒、可疑歷史操作以及敏感信息泄露等方面對(duì)鏡像文件進(jìn)行分析，以及它是否是可信鏡像。

當(dāng)云用戶發(fā)布鏡像時(shí)，發(fā)布者將面臨敏感信息被泄露的風(fēng)險(xiǎn)。盡管傳統(tǒng)軟件供應(yīng)商也面臨類似的風(fēng)險(xiǎn)，但鏡像發(fā)布的風(fēng)險(xiǎn)更大，因?yàn)殓R像包含已安裝和配置的應(yīng)用程序，其中配置可能包含危險(xiǎn)的操作，如創(chuàng)建受密碼保護(hù)的用戶帳戶。如果發(fā)布者創(chuàng)建運(yùn)行實(shí)例的應(yīng)用程序的鏡像，她可能會(huì)無意中創(chuàng)建原始不公平的Open文件。除了保護(hù)信息在發(fā)布鏡像時(shí)不被泄露，鏡像發(fā)布者還希望與數(shù)量有限的特定用戶共享鏡像。因此，鏡像庫應(yīng)該為鏡像文件訪問提供某種安全策略。

3.2 軟件漏洞檢測

通過鏡像掃描發(fā)現(xiàn)鏡像文件中的軟件漏洞，并標(biāo)記該漏洞的CVE和cnnvd編號(hào)，提供修復(fù)方案。鏡像檢測的核心是已知的系統(tǒng)CVE檢測。掃描儀獲取鏡像后，將鏡像分離成相應(yīng)的鏡像層和包，然后將這些包與多個(gè)CVE數(shù)據(jù)庫包的名稱和版本進(jìn)行比較，以確定是否存在漏洞。

3.3 歷史行為分析

本文通過鏡像掃描對(duì)鏡像的歷史指揮行為進(jìn)行審計(jì)，發(fā)現(xiàn)了鏡像的危險(xiǎn)操作行為。有證據(jù)表明，如果不管理休眠鏡像，虛擬環(huán)境現(xiàn)階段無法完全具備穩(wěn)定狀態(tài)，根本原因是昆蟲攜帶的鏡像間歇性會(huì)運(yùn)行并感染其他計(jì)算機(jī)，直到檢測并消除。所以，管理員始終都會(huì)伴隨潛在的安全風(fēng)險(xiǎn)問題，也注定會(huì)帶來一些費(fèi)用和成本消耗。

3.4 信息泄露檢測

容器鏡像可能包含數(shù)據(jù)庫密碼、證書密鑰以及敏感環(huán)境變量等，可能會(huì)導(dǎo)致信息泄露。共享虛擬鏡像不可避免地會(huì)帶來安全風(fēng)險(xiǎn)。在共享環(huán)節(jié)，通過差異性的角色和多維度闡述相關(guān)的安全風(fēng)險(xiǎn)漏洞，尤其是鏡像的發(fā)布者和原始鏡像庫存在的安全問題。鏡像使用者從鏡像庫還原鏡像并在計(jì)算服務(wù)器上運(yùn)行鏡像。

3.5 鏡像運(yùn)行安全策略

研究發(fā)現(xiàn)有安全問題的容器鏡像時(shí)，防護(hù)容器可以通過禁止其運(yùn)行來達(dá)到防護(hù)的效果。

4 Docker鏡像安全檢測方法

對(duì)鏡像中的文件進(jìn)行分層提取后，同時(shí)逐層進(jìn)行惡意代碼檢測，主要檢測WebShell和木馬病毒。這里主要采用模糊哈希、yara規(guī)則和機(jī)器學(xué)習(xí)的CNN-Text-Classfication分類算法3種檢測方式。

（1）通過模糊哈希算法來匹配Docker鏡像中的文件內(nèi)容，對(duì)可疑的文件進(jìn)行打分，同時(shí)使用病毒引擎進(jìn)行惡意代碼識(shí)別，還使用CNN-Text-Classfication分類算法對(duì)文件進(jìn)行檢測。3種檢測方法都有相應(yīng)的權(quán)重，最終會(huì)根據(jù)打分結(jié)果判斷文件是否是木馬病毒文件。

（2）通過對(duì)鏡像文件進(jìn)行解包后，從manifest.json中讀取歷史操作信息。將歷史操作信息發(fā)送到掃描器分析層進(jìn)行安全分析，對(duì)可疑歷史操作進(jìn)行標(biāo)注并觸發(fā)報(bào)警。

（3）通過manifest.json讀取layer信息。分析layer信息，提取layer中的文件內(nèi)容，并對(duì)證書格式文件進(jìn)行內(nèi)容匹配，檢測是否存在信息泄露風(fēng)險(xiǎn)。

對(duì)鏡像的證書標(biāo)簽和倉庫來源進(jìn)行可信檢測，以排除從不可信的倉庫或者直接安裝的容器鏡像，具體流程如圖1所示。

圖1 Docker鏡像安全監(jiān)測流程

其他掃描模塊如第三方框架漏洞掃描和開源協(xié)議掃描模塊與WebShell檢測模塊功能類似，因此未體現(xiàn)在流程圖中。

第三方框架漏洞掃描模塊。以java的Web框架漏洞掃描為例，如spring、struts，通過探測java構(gòu)建包war、jar類型的文件中是否存在相關(guān)框架，并識(shí)別出對(duì)應(yīng)版本來對(duì)接漏洞庫判斷漏洞是否存在。

開源協(xié)議掃描模塊。通過檢測鏡像中代碼目錄里的LICENSE文件內(nèi)容，識(shí)別出對(duì)應(yīng)的開源協(xié)議。

5 結(jié)語

云計(jì)算技術(shù)當(dāng)今已經(jīng)取得了普遍應(yīng)用和快速發(fā)展。隨著技術(shù)的不斷提升，云計(jì)算的虛擬化技術(shù)和容器發(fā)展已經(jīng)成為研究重點(diǎn)。容器技術(shù)的興起和推廣應(yīng)用，帶來了基于Docker的云平臺(tái)的快速發(fā)展與應(yīng)用。Docker作為一種容器，由于輕量級(jí)虛擬化、快速簡潔的操作系統(tǒng)功能，已越來越適用于云平臺(tái)。通常Docker以群集的形式提供服務(wù)，需大量的容器配合完成任務(wù)，因此必須快速分發(fā)和啟動(dòng)大量Docker容器，加快Docker鏡像的分布環(huán)節(jié)。

基于Docker鏡像的特點(diǎn)，從多個(gè)角度概述Docker鏡像發(fā)展背景和研究成果，針對(duì)性分析討論了Docker容器鏡像安全問題、Docker鏡像、Docker容器配置安全風(fēng)險(xiǎn)3方面內(nèi)容，并從病毒木馬檢測、軟件漏洞檢測、歷史行為分析、信息泄露檢測以及鏡像運(yùn)行安全策略5方面探究關(guān)于Docker的鏡像安全掃描研究，利用模糊哈希、yara規(guī)則和機(jī)器學(xué)習(xí)的CNN-Text-Classfication分類算法進(jìn)行Docker鏡像安全檢測。