李鵬超，路 斐，向 勇

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

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

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

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

1.1 容器和鏡像

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

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

1.2 Cgroups控制組技術(shù)

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

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

1.3 Namespace 命名空間

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

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

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

圖1 Docker容器分層

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

圖2 Docker主機(jī)取證流程

4 結(jié)語

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