基于云環(huán)境中Docker容器的取證技術(shù)研究

李鵬超，路 斐，向 勇

(1.重慶警察學(xué)院，重慶401331; 2.重慶市公安局電子物證司法鑒定中心，重慶401331)

云計算是一種分布式計算技術(shù)，因其具有靈活的動態(tài)可擴展性和快速部署能力，在當(dāng)今互聯(lián)網(wǎng)服務(wù)中占據(jù)大量市場份額［1］。資源虛擬化技術(shù)作為云環(huán)境的重要組成部分，在部署基礎(chǔ)設(shè)施服務(wù)時至關(guān)重要［2］。Docker是一種新型可移植虛擬化技術(shù)，能夠提供更靈活快速的部署方案以及基于大型生態(tài)系統(tǒng)的快速軟件開發(fā)能力，已廣泛應(yīng)用在云計算基礎(chǔ)設(shè)施建設(shè)過程中［3］。目前，取證技術(shù)主要聚焦在普通主機或傳統(tǒng)虛擬機環(huán)境，對Docker容器在事件分析和調(diào)查取證中并沒有較為適用的技術(shù)手段，因此，本文擬在對Docker容器架構(gòu)及組件研究的基礎(chǔ)上，探討基于Dcoker環(huán)境的數(shù)據(jù)取證技術(shù)。

1 Docker技術(shù)基礎(chǔ)

Docker技術(shù)解決的核心問題是利用LXC實現(xiàn)類似虛擬機的功能，此技術(shù)可以更加合理的分配和利用軟、硬件資源，為用戶提供更加高性能的虛擬化環(huán)境。Docker是一種用于管理和部署軟件容器的開源軟件［4］，其作為系統(tǒng)中獨立運行環(huán)境，在使用單個公共內(nèi)核時會將進程或進程組彼此隔離開來，這種隔離涉及進程空間的分離、進程間通信機制、網(wǎng)絡(luò)資源使用、文件系統(tǒng)訪問和資源利用和分配等。而Docker容器是基于Linux平臺內(nèi)核的控制組、命名空間和支持不同層的文件系統(tǒng)驅(qū)動程序?qū)崿F(xiàn)了隔離。

1.1 容器和鏡像

容器是一個鏡像在運行時的實例化，而鏡像是包含了創(chuàng)建一組指定特性進程所需要的所有必要數(shù)據(jù)和信息。例如，鏡像包含有應(yīng)用程序使用的端口信息，以及在實例化過程中應(yīng)用到的程序。鏡像除了內(nèi)核使用系統(tǒng)調(diào)用接口和核心設(shè)備外，其它都是完全獨立于主機系統(tǒng)上的實例化實現(xiàn)。在Docker環(huán)境下的所有實體(如容器、鏡像以及網(wǎng)絡(luò)字段)都被一個唯一標(biāo)識符所標(biāo)記稱為ContainerID/IamgeID。然而該標(biāo)識符由不同方式創(chuàng)建而成，IamgeID由部分鏡像內(nèi)容hash生成，而ContainerID是完全隨機生成。

Docker鏡像是由一系列只讀層組成，每一層都能夠為Docker容器提供不同類型的資源，當(dāng)用戶生成一個容器的時候，Docker會自行加載鏡像中包含的所有只讀層，并在最上層加入一個讀寫層，以達(dá)成鏡像實例化容器的目的。這種設(shè)計方式使得Docker可以提高鏡像構(gòu)建效率和資源共享的最大化，節(jié)約部署虛擬環(huán)境的時間和存儲空間。但是Docker容器的數(shù)據(jù)存儲采用的分層技術(shù)，也給已刪除文件的恢復(fù)和取證工作帶來了新的挑戰(zhàn)。

1.2 Cgroups控制組技術(shù)

Cgroups(Control groups)是Linux內(nèi)核提供的一種高效的用戶組管理機制，這種機制可以根據(jù)特定行為把一系列系統(tǒng)任務(wù)及其子任務(wù)整合到按資源劃分等級不同的組內(nèi)，系統(tǒng)按照分組級別的不同，有差別的進行資源管理。容器要實現(xiàn)虛擬化必須進行隔離，以保證資源的獨立性，而Cgroups可以限制、記錄、隔離進程組所使用的物理資源從而為資源的隔離提供基礎(chǔ)保障，因此 Cgruops是構(gòu)建Docker等一系列虛擬化管理工具的基石。Cgroups的主要作用是為不同用戶層面的資源管理提供一個統(tǒng)一化接口以實現(xiàn)從單個進程的資源操控到系統(tǒng)層面的虛擬化。

Cgroups自身可以通過多種方式對資源進行控制，因此在對內(nèi)容做取證分析時，技術(shù)人員需要注意容器可被一個或多個Cgroups關(guān)聯(lián)復(fù)用問題。

1.3 Namespace 命名空間

為了實現(xiàn)在分布式的環(huán)境下進行通信和資源定位，Docker容器會使用另一種機制對系統(tǒng)資源進行隔離即命名空間機制。命名空間是一種隔離系統(tǒng)調(diào)用，其目的是在Linux內(nèi)核中實現(xiàn)輕量級虛線化。在同一個Namespace下的進程可以感知彼此的變化而對同一命名空間以外的進程實現(xiàn)透明，類似于在一個獨立的系統(tǒng)環(huán)境中以此實現(xiàn)獨立和隔離的目的。例如，同一個文件系統(tǒng)裝入點可以在不同的命名空間中使用。因此，Namespace的使用也給進程取證工作帶來新問題。

1.4 分層文件系統(tǒng)

Docker與其他虛擬化技術(shù)一個顯著的區(qū)別是其支持分層文件系統(tǒng)，例如AUFS等分層文件系統(tǒng)［4］。這些文件系統(tǒng)有一個共同的特點是基于文件系統(tǒng)驅(qū)動程序的分層結(jié)構(gòu)，它提供了從不同層構(gòu)建單個文件系統(tǒng)的可能，以便以統(tǒng)一和抽象的方式呈現(xiàn)給進程。如圖1所示。

圖1 Docker容器分層

Docker鏡像由一層或多層文件系統(tǒng)組成，各層可以有不同來源，也可被不同用戶創(chuàng)建。當(dāng)容器被實例化時，創(chuàng)建一個讀寫層，該層被設(shè)置為頂層，容器中的所有寫訪問僅在這一層中執(zhí)行，基礎(chǔ)層作為只讀層保持不變。因此，Docker容器這種分層存儲數(shù)據(jù)的方式給數(shù)據(jù)取證帶來一定的難度，也將成為本文取證技術(shù)研究的重點。

2 基于Docker容器的文件取證研究

Docker容器作為一種輕量級且具有分層結(jié)構(gòu)的虛擬環(huán)境，在取證方法上與傳統(tǒng)主機及虛擬環(huán)境取證存在一定的差異［5］。在Docker主機上進行取證分析時要考慮Docker容器的特殊性及具體細(xì)節(jié)，否則會造成取證內(nèi)容的遺失和不完整。本文對在Docker主機中取證的各方面內(nèi)容進行深入探討，以實現(xiàn)對Docker主機更加全面的取證分析。

2.1 基于分層文件系統(tǒng)的數(shù)據(jù)恢復(fù)及歸屬性分析

Docker容器通過特定的文件系統(tǒng)驅(qū)動程序訪問文件。Docker容器是基于分層文件系統(tǒng)結(jié)構(gòu)實現(xiàn)對文件的管理，在對Docker容器中文件進行取證時，首要考慮分層文件系統(tǒng)對文件的管理方式。在Docker容器中隸屬于不同層的文件具有不同的訪問權(quán)限，因此在對Docker容器中存儲的文件取證分析時要按層分別予以考慮。根據(jù)文件系統(tǒng)分層的原理，Docker鏡像被存儲在一系列的只讀層，當(dāng)開啟一個容器系統(tǒng)會讀取只讀鏡像并添加一個讀寫層在頂部。如果正在運行的容器修改了現(xiàn)有的文件，該文件將被拷貝出底層的只讀層到最頂層的讀寫層，在讀寫層中的舊版本文件隱藏于該文件之下，但并沒有被修改。因此，如果文件在Docker容器中被刪除，則可能存在兩種情況:(1)該文件來源于讀寫層。在這種情況下文件將隨底層文件系統(tǒng)層上的正常操作系統(tǒng)機制一起刪除。(2)該文件來源于鏡像層。在此情況下，會在讀寫層中留下一個被刪除文件的索引，但該文件仍然存在于鏡像層之中。因此，文件存儲的不同位置必須使用不同的方法來進行恢復(fù)。

2.1.1 恢復(fù)讀寫層的被刪除文件方法

根據(jù)Docker容器中分層文件系統(tǒng)的管理機制，根據(jù)系統(tǒng)中讀寫層的特殊性，提出使用“文件雕復(fù)”的方式對已刪除文件進行恢復(fù)。

“文件雕復(fù)”［6］是一種在文件卷、磁盤鏡像或者文件中字符組合(如魔數(shù))中進行線性搜索的方法。此方法在文件的系統(tǒng)元信息［7］不可信任或被損壞時可以恢復(fù)尚未被覆蓋的已分配和被刪除的文件，但碎片文件因其特殊性不可以被完整重建，使用“文件雕復(fù)”技術(shù)恢復(fù)的文件一般都不能完整恢復(fù)其元信息(如文件名，路徑，時間戳或類內(nèi)容)。這一限制使得在Docker環(huán)境下進行取證分析時，會遇到指定刪除文件的歸屬問題。因為，“文件雕復(fù)”技術(shù)能夠?qū)⒉粠в性獢?shù)據(jù)的文件恢復(fù)到特定的容器，但是如何確定區(qū)分文件是否屬于該Docker容器，則需要元數(shù)據(jù)才能確定。本文在結(jié)合分層文件系統(tǒng)特性的基礎(chǔ)上對如何確定已恢復(fù)文件歸屬問題在后文予以分析。

另外，對Overlay2分層文件系統(tǒng)進行分析時發(fā)現(xiàn)，其使用了一個名為MountID的數(shù)據(jù)，經(jīng)過研究發(fā)現(xiàn)可以利用MountID確定已恢復(fù)文件的歸屬問題。因為，容器的MountID在容器的配置文件/../config.v2.json中存儲，且容器對應(yīng)的讀寫層存儲在$MountID中。同時，系統(tǒng)在容器的啟動初始化期間會創(chuàng)建一個/../l$MountID-init目錄，從而允許快速索引所有在相應(yīng)宿主主機上生成的Docker容器的讀寫層。通過檢索這個目錄的方式可以確定讀寫層及保存文件的歸屬。而更深入的文件系統(tǒng)層存儲在/../lower文件中以縮寫的形式降序排列。在對Overlay2分層文件系統(tǒng)進一步分析發(fā)現(xiàn)，還可在/../$ContainerID下進一步取證分析Diff和Merge子文件夾。在Diff文件夾中包含讀寫層中創(chuàng)建且尚未刪除的所有文件。在Merge文件夾包含整個Overlay2文件系統(tǒng)提供的所有文件系統(tǒng)層信息。結(jié)合兩者信息后發(fā)現(xiàn)，當(dāng)文件系統(tǒng)刪除較低層提供的讀寫層中的文件時，系統(tǒng)會分配一個標(biāo)記為Linux字符設(shè)備的ID，從而指示Overlay2忽略此文件以查看全局視圖。因此，在較低層中刪除的所有文件都可以通過命令進行標(biāo)識，然后通過遍歷分層并檢查相應(yīng)文件是否存在以進行檢驗及取證。

2.1.2 恢復(fù)只讀層被刪除文件方法

根據(jù)分層文件系統(tǒng)刪除原理，當(dāng)需要刪除存在于只讀層的文件時，系統(tǒng)將會在讀寫層的相應(yīng)位置建立一個特殊的文件作為刪除標(biāo)記且該文件具有C屬性。就是說刪除操作成功完成之后，并不會造成只讀層存儲的文件發(fā)生任何變化。盡管最終的分層聯(lián)合文件系統(tǒng)中可以看到這種刪除動作造成的結(jié)果，但是在只讀層仍然保留有源文件。所以，這也是分層文件系統(tǒng)所具備的一大優(yōu)點即文件系統(tǒng)的隔離。因此，對在只讀層被修改或刪除的文件只需要在只讀層對源文件進行提取和分析既可。

2.1.3 恢復(fù)已刪除文件歸屬性分析

在Docker環(huán)境下進行取證分析時不但要考慮如何將分屬于不同層次的已刪除文件進行恢復(fù)，同時要思考恢復(fù)的文件歸屬于某個容器的問題。解決文件歸屬問題必須依賴于文件的元數(shù)據(jù)。元數(shù)據(jù)就是關(guān)于文件歸屬于容器某一層的額外信息，它不僅能夠讓Docker容器獲取運行和構(gòu)建時的信息，還可以對文件的歸屬進行確定。在Docker的只讀層和讀寫層存儲的文件均包含元數(shù)據(jù)。但利用“文件雕復(fù)”還原的文件通常缺少此類信息因而不可能進行有效的文件位置確定。只有當(dāng)文件本身能夠提供有關(guān)自身的上下文信息時才可與相應(yīng)的容器或?qū)蛹夁M行關(guān)聯(lián)。要解決文件的來源問題，一種可行解決方案是利用排除法，首先排除所有由文件雕刻恢復(fù)的以文件分配表形式存儲在文件系統(tǒng)中的文件，然后排除所有可以用文件系統(tǒng)自帶的還原機制進行恢復(fù)的文件，最后確定其余文件所屬容器。此外，還可以通過檢查剩余的先前未知的已雕刻文件信息以確定數(shù)據(jù)塊屬于哪個容器。例如Ext文件系統(tǒng)分配的新文件恰好和目標(biāo)文件在同一父目錄同一屬主下，那么就可以提供粗略的上下文信息。但是由于這些信息的不確定性，在取證調(diào)查過程中只能作為一種思路或參考。

在Docker容器中還可以利用恢復(fù)后的文件路徑中包括的容器/鏡像ID確定目標(biāo)文件所屬容器，已達(dá)到在取證分析時確定文件歸屬目的。

確定文件歸屬的前提是需知道一個鏡像被哪些容器通過讀寫層使用。通過系統(tǒng)運行時信息和特定的配置文件，可以實現(xiàn)文件和容器之間的關(guān)聯(lián)。文件和容器之間的關(guān)聯(lián)是可能通過運行時信息和特定配置文件予以確定的。此外，確定文件是否來源于容器或鏡像，此信息與在運行時分析文件的可見性有一定關(guān)系。根據(jù)現(xiàn)有Docker容器ID的確認(rèn)方法［8］，假設(shè)已經(jīng)從容器中恢復(fù)了已刪除的文件，文件的完整原始路徑成為已知。以AUFS分層文件系統(tǒng)為例，在AUFS文件系統(tǒng)中容器的文件存儲在/var/lib/docker/aufs路徑下，考慮到已經(jīng)恢復(fù)的文件可能來自不同的層，各自層可以在AufsID下發(fā)現(xiàn)/var/lib/docker/aufs/layers/$AufsID。所以，需要先從恢復(fù)路徑中提取AufsID。若要更進一步推斷涉及該AufsID的所有容器，則 ContainerID和/var/liib/Docker/image/aufs/layerdb文件都應(yīng)掛載在$ContainerID/mountID且是可讀的，通過匹配該文件中存儲的ID和aufsid，如果匹配上，最初包含文件的容器就能夠識別出來。

同樣，如果可以識別出相應(yīng)的Inode，就可以直接從包含原始文件的底層的目錄中提取相應(yīng)關(guān)聯(lián)信息。

2.2 Docker容器的命名空間在取證中的作用

Docker容器所實現(xiàn)的隔離性主要來自內(nèi)核的命名空間，因此，Linux內(nèi)核中不同類型的命名空間會對取證分析產(chǎn)生不同的影響。由于UTS命名空間［8］允許配置特定于容器的時區(qū)，所以在容器的實時取證分析時必須考慮潛在的時間差異性。例如在分層文件系統(tǒng)中修改文件時始終使用主機系統(tǒng)的時間，并在運行時動態(tài)調(diào)整每個容器的時間戳。

在對PID命名空間［9］進行取證分析時，需要考慮主機上的進程和一個容器中的進程接收相同的進程PID問題。主機上的PID具有唯一性且與容器內(nèi)的PID相同，在將PID應(yīng)用于取證分析時，可以通過獲取主機上PID的方式，確定容器中的進程歸屬。與PID命名空間類似，用戶命名空間允許將用戶UID或組GID從一個容器映射到主機上的另一個UID或GID。例如，一個進程可以在具有UID0的容器內(nèi)運行，但主機上的相應(yīng)進程卻使用歸屬于另一個容器的UID2運行。就像在PID命名空間中一樣，如果日志文件中包含UID會在分析時帶來些挑戰(zhàn)，因為這種情況系統(tǒng)可能需要通過修改/etc/subuid和/etc/subgid文件的方式實現(xiàn)將容器的UID/GID指派給主機的UID/GID，在對Docker容器的進程取證時應(yīng)予以認(rèn)真考慮。

3 基于Docker容器的取證流程分析

基于單個Docker容器取證分析的流程如下。

(1)利用Docker info命令提取Docker容器的基本信息如，ContainerID，Images數(shù)以及Server Version和分層文件系統(tǒng)類型等信息。

(2)對Images和Container中存儲的文件進行調(diào)查取證。如果存儲在其中的文件信息被刪除，還要結(jié)合上文中提出的分層文件系統(tǒng)數(shù)據(jù)恢復(fù)技術(shù)和方法，對存儲在不同層級中的文件進行恢復(fù)。

(3)對容器的數(shù)據(jù)卷［10］進行取證分析。如果在調(diào)查Image和Docker的文件系統(tǒng)后，發(fā)現(xiàn)文件不被保存的文件系統(tǒng)中，則需要對Docker容器創(chuàng)建的文件的數(shù)據(jù)卷進行調(diào)查取證。這樣的數(shù)據(jù)卷保存有Docker容器間共享的數(shù)據(jù)，而且數(shù)據(jù)本身與Docker的刪除與否無關(guān)，會一直保存有Imagie或文件系統(tǒng)中不存儲的內(nèi)容。因此，需要另外的提取和分析。

(4)對Docker容器的文件日志進行取證分析。必須分析日志以了解容器運行痕跡。容器可以通過配置時的“－－log－driver”選項［11］來記錄在運行期間輸出的數(shù)據(jù)。如果沒有單獨的選項，則可以使用json-file日志驅(qū)動程序［12］，在這種情況下，可以通過“dockerlogs容器名稱”查看特定容器的日志內(nèi)容［13］。Docker主機的取證流程如圖2所示。

圖2 Docker主機取證流程

4 結(jié)語

對Docker的基本技術(shù)進行分析和探討，著重闡述與物理主機和傳統(tǒng)虛擬化技術(shù)相比在對Docker環(huán)境下做取證和事件分析時需要考慮的情況，并分析了使用Docker容器時其分層文件系統(tǒng)以及命名空間對已刪除文件分析和取證的影響，最終，制定了基于單個Docker主機的取證流程。