Docker容器日志恢復技術(shù)研究

◆鄭袁平 賀嘉 胡舉 尹澤華 武衢

Docker容器日志恢復技術(shù)研究

◆鄭袁平 賀嘉 胡舉 尹澤華 武衢

（中國移動通信集團湖南有限公司 湖南 410000）

隨著容器技術(shù)的興起，Docker 容器作為事實上的容器標準也得到了越來越多的關(guān)注。容器給用戶帶來便利的同時也帶來了安全上的隱患，例如容器中被植入惡意代碼或利用容器攻擊主機操作系統(tǒng)。目前涉及容器的研究大多有關(guān)如何利用、拓展容器以及容器的漏洞分析，針對 Docker 容器的取證研究比較少，為了彌補這方面的缺失，本文以 Docker 日志為突破口，在詳細介紹了 local、json-file、syslog 和 journald 日志記錄驅(qū)動的對應(yīng)的日志格式同時，也根據(jù)已有的文件恢復方法提出了 Docker 容器日志恢復建議。

Docker；日志；文件恢復；取證

1 介紹

隨著近年來互聯(lián)網(wǎng)的高速發(fā)展，云計算得到越來越廣泛的應(yīng)用；而 Docker 容器技術(shù)的出現(xiàn)則掀起了云計算的又一輪熱潮。 Docker 是一個用于開發(fā)、部署和運行應(yīng)用程序的開放平臺，能夠?qū)?yīng)用程序與基礎(chǔ)架構(gòu)分開，從而實現(xiàn)快速交付軟件。容器（Container）作為Docker 中分發(fā)和測試應(yīng)用程序的單元，為 Docker 提供了在松散隔離的環(huán)境中打包和運行應(yīng)用程序的支持。

由于目前尚未出現(xiàn)成熟的 Docker 取證技術(shù)[1-3]，而日志中通常包含有大量的敏感信息可供取證但又極易被損壞，因此本文嘗試以 Dokcer 容器日志為突破點，對現(xiàn)有的日志恢復技術(shù)進行歸納總結(jié)。

2 Docker現(xiàn)有安全隱患

Combe等人認為 Docker 的安全主要依賴于3個因素：由 Docker 守護進程管理的用戶空間級的進程隔離、操作系統(tǒng)內(nèi)核對于這種隔離的強制執(zhí)行和網(wǎng)絡(luò)操作的安全性。

根據(jù)以上三個因素，攻擊者可分為兩類：直接和間接。直接攻擊者會采用嗅探、阻塞、注入或修改網(wǎng)絡(luò)和系統(tǒng)通信等手段，直接針對運行中的機器，并破壞其中的系統(tǒng)組件：

（1）生產(chǎn)中的容器。例如，對于使用面向 Internet 容器服務(wù)的容器，攻擊者可以先在相關(guān)容器上獲得 root 權(quán)限，然后進一步對位于同一主機操作系統(tǒng)上的容器進行拒絕服務(wù)（DoS）攻擊。

（2）生產(chǎn)中的主機操作系統(tǒng)。例如，在上面的例子中，攻擊者還可以通過已獲得 root 權(quán)限的容器訪問關(guān)鍵的主機操作系統(tǒng)文件，即發(fā)起容器逃逸攻擊。

（3）生產(chǎn)中的 Docker 守護進程。例如，攻擊者在獲得訪問主機操作系統(tǒng)文件的權(quán)限后，可以修改默認的安全參數(shù)，從而在該主機上啟動新的 Docker 容器。

（4）生產(chǎn)網(wǎng)絡(luò)。攻擊者可以通過修改主機操作系統(tǒng)的相關(guān)配置文件，從而實現(xiàn)重定向網(wǎng)絡(luò)流量等操作。

間接攻擊者的目標與直接攻擊者相同，不過間接攻擊者是利用 Docker 的生態(tài)系統(tǒng)（例如代碼和鏡像庫）來進入生產(chǎn)環(huán)境中。

綜上，用戶在日常使用 Docker 的過程中面臨了許多威脅。為了能在被攻擊時及時發(fā)現(xiàn)異常和在被攻擊后及時定位異常，無論是用戶還是取證人員都需要充分利用容器日志中的信息。

3 Docker日志介紹

日志是 Docker 容器日常運行和積累的海量數(shù)據(jù)中最有價值的數(shù)據(jù)之一。默認情況下，對于每一個存在的 Docker 容器都會生成相應(yīng)的日志文件。 Docker 引擎是 Docker 中用于構(gòu)建和容器化應(yīng)用程序的核心組件，它向外提供命令行接口（CLI）客戶端，然后根據(jù)接收到的命令調(diào)用相應(yīng)的 Dokcer API。Docker 守護進程負責監(jiān)聽 Docker API 請求并管理容器和網(wǎng)絡(luò)等 Docker 對象。容器由 Docker Daemon 創(chuàng)建和運行，并且根據(jù)已有的配置，將指定的信息重定向到標準輸出（stdout）和標準錯誤（stderr）兩個輸出流中。例如，官方的nginx 鏡像便在文件 /var/log/nginx/access.log 和文件 /dev/stdout 之間建立了一條軟連接，并且在文件 /var/log/nginx/error.log 和文件 /dev/stderr 之間也建立了一條軟連接，從而覆蓋原有的日志文件并將日志發(fā)送到相關(guān)的特殊文件中。而日志記錄驅(qū)動（logging driver ）則從容器的標準輸出和標準錯誤中收集信息，并在指定位置生成指定格式的日志文件。存放日志的位置可以是在當前主機上，也可以是外部主機、數(shù)據(jù)庫或另一個日志記錄后端，而日志記錄的信息和日志的格式幾乎完全取決于來自容器終端的命令。

Docker 支持多種日志記錄驅(qū)動來幫助用戶從運行的容器和服務(wù)中收集信息。每個 Docker Daemon 都有一個默認的日志記錄驅(qū)動，可通過查看 daemon.json 文件中關(guān)鍵詞 log-driver 對應(yīng)的值得到。gelf、fluentd、awslogs、splunk、etwlogs、gcplogs 和 logentries 日志記錄驅(qū)動主要作為向外部主機傳送日志的選項，local、json-file 和 journald 日志記錄驅(qū)動則只能在本地主機上生成日志，syslog 日志記錄驅(qū)動的日志既可以路由到當前主機上，也可以路由到外部主機。 Docker 日志記錄插件允許用戶擴展和自定義 Docker 的日志記錄功能，并且日志服務(wù)提供商可以實現(xiàn)自己的插件。

本章節(jié)接下來的部分將會以 local、json-file 和 journald 日志記錄驅(qū)動為例，介紹 Docker 日志格式。

3.1 local 日志記錄驅(qū)動

local 日志記錄驅(qū)動捕獲容器的中標準輸出和標準錯誤中的輸出，并將其寫到內(nèi)部存儲當中。日志默認位置為：/var/lib/docker/containers/容器id/local-logs/container.log。每個日志都是由若干日志行組成，日志行可分為3個部分：頭部，日志消息部分和尾部。頭部和尾部都是32位的無符號數(shù)，表示中間日志消息部分的大小；而中間的日志消息部分也包含三個部分：日志來源、時間戳和日志內(nèi)容。磁盤上存儲的日志消息對應(yīng)的數(shù)據(jù)部分經(jīng)過了 Protocal Buffer 編碼。Protocal Buffer 是由Google公司提出的一種高效的數(shù)據(jù)壓縮編碼方式。

3.2 json-file 日志記錄驅(qū)動

json-file是Docker 容器的默認日志記錄驅(qū)動。Docker 捕獲容器的中標準輸出和標準錯誤中的輸出，并使用 JSON 格式寫入文件中。每個日志文件僅包含有關(guān)一個容器的信息。日志默認位置為：/var/lib/docker/containers/容器id/容器id-json.log。

3.3 syslog 日志記錄驅(qū)動

syslog日志記錄驅(qū)動將日志路由到 syslog 服務(wù)器上。值得注意的是 Linux 操作系統(tǒng)自帶 syslog日志系統(tǒng)，因此也可以直接路由到本地主機上。日志格式遵循 RFC 5424 定義。

3.4 journald 日志記錄驅(qū)動

journald日志驅(qū)動程序發(fā)送容器日志到的主機的 system.journald 服務(wù)中。

可通過輸出主機上的 /var/log/message 文件中的內(nèi)容查看日志消息，也可以通過 journalctl 命令、journal API 或者 docker logs 命令查看。

4 日志恢復技術(shù)介紹

4.1 基于文件系統(tǒng)元數(shù)據(jù)的文件恢復方法

為了簡化基于文件系統(tǒng)元數(shù)據(jù)的文件恢復過程，Carrier 建立了一個名為 The SleuthKit（TSK）的開源項目。接著，Garfinkel通過封裝TSK指令來進一步自動化磁盤分析，結(jié)果以XML文件格式存儲并用Python 模塊進行分析。

該方法的優(yōu)勢在于能夠快速提取元數(shù)據(jù)和對應(yīng)磁盤區(qū)域都尚未被覆寫的文件的數(shù)據(jù)。同時，局限性也很明顯：當文件元數(shù)據(jù)不存在或?qū)?yīng)磁盤區(qū)域被覆寫時，則恢復效果不佳。因此，對于那些元數(shù)據(jù)和文件內(nèi)容都還在磁盤上的Docker日志，可以使用基于文件系統(tǒng)元數(shù)據(jù)的文件恢復方式進行恢復。

通常為了保護證物的完整性，取證人員不會直接對磁盤進行操作，而是制作一個磁盤的鏡像文件來進行相應(yīng)的數(shù)據(jù)分析。該模型分為四個主要步驟。第一步是媒體分析，負責從鏡像文件中獲取數(shù)據(jù)。在此過程中數(shù)據(jù)僅被視為字節(jié)序列且不被解釋。第二步是卷分析，通過掃描第一步獲取的數(shù)據(jù)查找卷的結(jié)構(gòu)。卷的類型包括分區(qū)、RAID和卷組的邏輯卷。完整的磁盤可以是一個卷，例如直接在設(shè)備上建立的文件系統(tǒng)。而且，卷可以以任意的多種方式進行組合。第三步是系統(tǒng)分析，在第二步確定卷的結(jié)構(gòu)后，將儲存在每個卷上的數(shù)據(jù)解釋為文件系統(tǒng)。該步驟將收集和恢復檢測到的文件系統(tǒng)中的目錄、文件及其元數(shù)據(jù)。第四步是應(yīng)用程序分析，將數(shù)據(jù)在內(nèi)容級別進行解釋和分析，例如進行文檔的搜索或惡意軟件的詳細分析。

4.2 文件雕復技術(shù)介紹

為了解決元數(shù)據(jù)不可使用時的文件恢復問題，文件雕復技術(shù)應(yīng)運而生。文件雕復是一種在不需要任何與文件匹配的文件系統(tǒng)元數(shù)據(jù)的情況下，僅根據(jù)文件結(jié)構(gòu)和內(nèi)容來恢復文件的取證技術(shù)。

文件雕復同樣基于文件內(nèi)容仍然保留在磁盤上的假設(shè)。文件雕復分模型為三個步驟。第一步是預處理，負責根據(jù)殘余的文件系統(tǒng)元數(shù)據(jù)識別對應(yīng)的簇。第二步是識別，將剩下的沒有對應(yīng)文件系統(tǒng)元數(shù)據(jù)的簇進行分類。第三步是重組，負責將第二步中屬于同一個文件類型的簇進行合并，恢復成對應(yīng)的文件。

5 總結(jié)

Docker 容器為應(yīng)用程序的開發(fā)、測試和使用人員提供了一個輕量級的虛擬化服務(wù)，人們在享受容器帶來的便利的同時，也不得不面對使用容器時可能面臨的安全隱患。而容器日志中包含了大量的寶貴信息，這些信息能夠幫助取證人員還原容器被攻擊或損毀前的狀態(tài)。同時容器日志自身也極易被刪除，因此本文中根據(jù)已有的文件恢復方法，并以不同的日志記錄驅(qū)動下的日志格式為例，提出了一些可行性較高的日志恢復方案，為之后的容器取證工作提供了一些建議。

[1]任蘭芳，莊小君，付俊. Docker 容器安全防護技術(shù)研究[J]. 電信工程技術(shù)與標準化，2020,033（003）：73-78.

[2]李鵬超，周凱. 基于 Docker 容器的電子數(shù)據(jù)取證方法[J]. 吉林大學學報（理學版），2019, 57（06）：1485-1490.

[3]王遠征，肖波，齊凌飛. Docker 取證方法研究[C]//第 32 次全國計算機安全學術(shù)交流會論文集.2017.