基于OpenStack 云平臺(tái)的Docker 容器安全監(jiān)測(cè)方法研究*

崔 軻，燕 瑋，劉子健，張慕榕，賈星威，許鳳凱

(華北計(jì)算機(jī)系統(tǒng)工程研究所，北京100083)

0 引言

隨著虛擬化技術(shù)的興起，Docker 容器技術(shù)憑借自身資源占用低、不易受環(huán)境因素影響等特點(diǎn)被各大企業(yè)廣泛使用。 例如京東、天貓等電商企業(yè)在大型銷(xiāo)售活動(dòng)中均采用Docker 作為關(guān)鍵業(yè)務(wù)的支撐，招行、浦發(fā)和法國(guó)興業(yè)等國(guó)內(nèi)外銀行通過(guò)Docker 搭建容器及服務(wù)的金融云架構(gòu)平臺(tái)，為千萬(wàn)級(jí)用戶提供個(gè)人理財(cái)、快速交付等服務(wù)。 但是，在容器技術(shù)被各大企業(yè)廣泛使用的同時(shí)，容器逃逸、資源非法占用、容器 DoS 攻擊等安全問(wèn)題也愈演愈烈，容器本身及其運(yùn)行環(huán)境的安全問(wèn)題亟待解決。目前針對(duì)容器安全監(jiān)測(cè)的方法很多，例如Zabbix、Scout 插件等，但是，Zabbix 脫離集中數(shù)據(jù)存儲(chǔ)且復(fù)雜度較高，Scout監(jiān)控起來(lái)要收取大量的費(fèi)用，并且存在監(jiān)控不全面，易產(chǎn)生監(jiān)控黑洞等問(wèn)題，因此，針對(duì)容器安全監(jiān)測(cè)問(wèn)題，本文提出了一種新型的安全監(jiān)測(cè)方法，該方法可對(duì)容器的整個(gè)生命周期進(jìn)行監(jiān)控，并且對(duì)容器遭受逃逸和DoS 攻擊等可以進(jìn)行有效監(jiān)測(cè)[1]。

1 理論基礎(chǔ)

1.1 輕量級(jí)容器引擎

輕量級(jí)容器引擎是一款自動(dòng)化的管理系統(tǒng)，主要包括鏡像、鏡像倉(cāng)庫(kù)和容器三個(gè)部分[2]。 其中鏡像是用來(lái)構(gòu)建容器的基礎(chǔ)，鏡像倉(cāng)庫(kù)是用來(lái)存儲(chǔ)鏡像和分發(fā)鏡像，容器是由鏡像生成的，是鏡像運(yùn)行的實(shí)際表現(xiàn)。

輕量級(jí)容器引擎可對(duì)少量的Docker 容器進(jìn)行創(chuàng)建、刪除和管理。 針對(duì)構(gòu)建的 Docker 容器網(wǎng)絡(luò)集群進(jìn)行統(tǒng)一視圖管理則需要通過(guò)專(zhuān)用的容器管理平臺(tái)。

1.2 容器管理平臺(tái)

目前主流的容器管理平臺(tái)有Kubernetes、Open-Stack 等。 Kubernetes 和 OpenStack 這兩種平臺(tái)目前都十分受到廣大用戶的青睞，但是，去年12 月份，Kubernetes 宣布自 v1.20 起放棄對(duì) Docker 容器的支持，這將導(dǎo)致使用Kubernetes 的大量用戶將轉(zhuǎn)向應(yīng)用 OpenStack 進(jìn)行 Docker 容器的管理[3-4]。

OpenStack 是一個(gè)開(kāi)源的云計(jì)算容器管理平臺(tái)，內(nèi)部的核心組件有 Nova、Neutron 和 Heat 等，其中，Nova 通過(guò) Nova Docker driver 可以實(shí) 現(xiàn)對(duì) Docker 容器的管理；Neutron 對(duì)容器提供虛擬網(wǎng)絡(luò)；Heat 可對(duì)云平臺(tái)上的Docker 容器進(jìn)行大規(guī)模創(chuàng)建、修改和刪除[5-6]。

1.3 安全風(fēng)險(xiǎn)分析

Docker 容器常見(jiàn)的安全風(fēng)險(xiǎn)問(wèn)題有用戶非法提權(quán)、DoS 攻擊等。 例如 Linux 內(nèi) 核在 3.16 以前的 版本存在內(nèi)核溢出的漏洞，導(dǎo)致宿主機(jī)和Docker 容器崩潰；國(guó)外某公司通過(guò)上傳包含釣魚(yú)程序的鏡像來(lái)獲取用戶信息等[7-8]。 為保證基于 OpenStack 云管理平臺(tái)構(gòu)建的Docker 容器集群安全運(yùn)行，本文從內(nèi)核、Docker 鏡像和網(wǎng)絡(luò)等方面對(duì)Docker 容器面臨的安全風(fēng)險(xiǎn)進(jìn)行分析[9]。

內(nèi)核安全風(fēng)險(xiǎn)：namespace 命名空間保證各容器進(jìn)程存在于不同的運(yùn)行空間。 cgroups 保證各容器占用的資源彼此獨(dú)立。 但是，由于容器共享物理機(jī)內(nèi)核，惡意用戶將以此為攻擊點(diǎn)對(duì)容器發(fā)起內(nèi)核攻擊[10-12]。

Docker 鏡像安全風(fēng)險(xiǎn)：Docker 鏡像大多數(shù)來(lái)自于鏡像倉(cāng)庫(kù)，倉(cāng)庫(kù)中存在用來(lái)釣魚(yú)的惡意鏡像，這些鏡像一旦被用戶下載使用，將會(huì)對(duì)整個(gè)項(xiàng)目產(chǎn)生致命的危害[13]。

網(wǎng)絡(luò)安全風(fēng)險(xiǎn)：Docker 容器網(wǎng)絡(luò)默認(rèn)使用bridge網(wǎng)絡(luò)模式，攻擊者可以利用物理機(jī)的內(nèi)網(wǎng)發(fā)起ARP欺騙、網(wǎng)絡(luò)嗅探和廣播風(fēng)暴等攻擊[14]。

針對(duì)以上安全風(fēng)險(xiǎn)，本文從以下兩方面來(lái)保障容器的安全運(yùn)行：

(1)安全加固策略

主要針對(duì)內(nèi)核、鏡像、網(wǎng)絡(luò)、容器等方面進(jìn)行安全加固。 ①內(nèi)核：及時(shí)更新物理機(jī)內(nèi)核，采用SELinux、AppArmor 或 GRSEC 控制文件訪問(wèn)權(quán)限[15]。 ②鏡像：采用官方認(rèn)證過(guò)的鏡像文件，并且不定期對(duì)鏡像文件進(jìn)行掃檢。 ③容器：禁止在容器內(nèi)開(kāi)啟遠(yuǎn)程調(diào)用接口，避免以特權(quán)模式啟動(dòng)容器[16]。

(2)專(zhuān)用安全組件

主要針對(duì)威脅發(fā)現(xiàn)與處置、安全掃描、安全監(jiān)測(cè)方面進(jìn)行安全加固。 ①威脅發(fā)現(xiàn)與處置類(lèi)：部署入侵防御工具對(duì)容器的攻擊性行為進(jìn)行中斷和禁止。②安全掃描類(lèi)：利用掃描工具對(duì)容器內(nèi)的漏洞、木馬、病毒和惡意軟件等進(jìn)行掃描分析。 ③安全監(jiān)測(cè)類(lèi)：利用監(jiān)測(cè)組件對(duì)容器整個(gè)生命周期的數(shù)據(jù)進(jìn)行安全監(jiān)測(cè)。 因此在容器遭受DoS 攻擊、容器逃逸以及容器自身資源異常預(yù)測(cè)方面可以通過(guò)實(shí)時(shí)監(jiān)控，對(duì)數(shù)據(jù)進(jìn)行分析和預(yù)測(cè)從而保證容器的安全運(yùn)行。

2 安全監(jiān)測(cè)方法

針對(duì) OpenStack 云平臺(tái)上 Docker 容器集群的安全運(yùn)行，本文采用prometheus+influxdb+cadvisor 架構(gòu)，通過(guò)采集代理將容器中當(dāng)前的數(shù)據(jù)進(jìn)行篩選和聚合分類(lèi)，結(jié)合用戶制定的規(guī)則庫(kù)對(duì)該數(shù)據(jù)進(jìn)行匹配，若匹配成功則觸發(fā)報(bào)警機(jī)制并分級(jí)響應(yīng)顯示給用戶查看，若匹配失敗則不做任何處理。其次，由于采集的是以時(shí)間序列為主的數(shù)據(jù)，因此，本文進(jìn)一步選取Logistic-ARMA 時(shí)間序列預(yù)警模型對(duì)該類(lèi)數(shù)據(jù)進(jìn)行分析和處理，獲得容器數(shù)據(jù)在時(shí)間維度上的關(guān)聯(lián)性，從而預(yù)測(cè)容器在未來(lái)一段時(shí)間內(nèi)的資源使用情況，最終實(shí)現(xiàn)對(duì)容器的資源進(jìn)行實(shí)時(shí)預(yù)測(cè)和監(jiān)測(cè)。 再結(jié)合目前較為流行且準(zhǔn)確率較高的BERT 序列標(biāo)注算法，對(duì)用戶手動(dòng)輸入的文本進(jìn)行文本標(biāo)注，進(jìn)行安全特征庫(kù)的更新[17-18]。 該監(jiān)測(cè)方法由五部分組成，分別為數(shù)據(jù)獲取、數(shù)據(jù)預(yù)處理、數(shù)據(jù)監(jiān)測(cè)、數(shù)據(jù)處置和監(jiān)測(cè)管理，原理圖如圖1 所示。

圖1 基于云平臺(tái)容器的安全監(jiān)測(cè)方法原理

(1)數(shù)據(jù)獲取

數(shù)據(jù)獲取中存在數(shù)據(jù)采集和數(shù)據(jù)收集，數(shù)據(jù)采集主要通過(guò)服務(wù)端對(duì)云平臺(tái)上的數(shù)據(jù)進(jìn)行拉取，數(shù)據(jù)收集利用監(jiān)控代理數(shù)據(jù)進(jìn)行收集，保存在數(shù)據(jù)庫(kù)中，以此獲得容器信息及運(yùn)行狀態(tài)。

(2)數(shù)據(jù)預(yù)處理

主要對(duì)數(shù)據(jù)進(jìn)行預(yù)處理操作，包括缺失值、異常值剔除等，通過(guò)數(shù)據(jù)篩選器對(duì)數(shù)據(jù)進(jìn)行篩選，作為數(shù)據(jù)監(jiān)測(cè)部分的數(shù)據(jù)輸入。

(3)數(shù)據(jù)監(jiān)測(cè)

數(shù)據(jù)監(jiān)測(cè)部分由容器安全數(shù)據(jù)監(jiān)測(cè)和威脅態(tài)勢(shì)感知算法模型組成。 預(yù)處理后的數(shù)據(jù)同時(shí)流入安全數(shù)據(jù)監(jiān)測(cè)和威脅態(tài)勢(shì)感知中，在安全數(shù)據(jù)監(jiān)測(cè)中將預(yù)處理后的數(shù)據(jù)與自定義的報(bào)警規(guī)則進(jìn)行匹配，若匹配成功則觸發(fā)報(bào)警機(jī)制，并且進(jìn)行分級(jí)響應(yīng)，以供管理員采取應(yīng)急響應(yīng)措施。 在威脅態(tài)勢(shì)感知中，利用數(shù)據(jù)挖掘、文本分析和流量分析技術(shù)，將處理后的數(shù)據(jù)經(jīng)過(guò)Logistic-ARMA 預(yù)警模型進(jìn)行數(shù)據(jù)趨勢(shì)感知，通過(guò)對(duì)系統(tǒng)日志的分析和處理，獲得容器數(shù)據(jù)在時(shí)間維度上的關(guān)聯(lián)性，從而預(yù)測(cè)容器在未來(lái)一段時(shí)間內(nèi)的資源使用情況，最終實(shí)現(xiàn)對(duì)容器的資源進(jìn)行實(shí)時(shí)預(yù)測(cè)和監(jiān)測(cè)。 在告警規(guī)則中，用戶可以通過(guò)輸入預(yù)警文本，預(yù)警文本通過(guò)BERT 序列模型標(biāo)注出關(guān)鍵字，從而實(shí)現(xiàn)對(duì)報(bào)警規(guī)則的動(dòng)態(tài)更新。 數(shù)據(jù)監(jiān)測(cè)部分的所有數(shù)據(jù)都將流入數(shù)據(jù)處置和監(jiān)測(cè)管理部分。

(4)數(shù)據(jù)處置

數(shù)據(jù)存儲(chǔ)主要對(duì)安全分析部分產(chǎn)生的數(shù)據(jù)以及整個(gè)系統(tǒng)日志中的數(shù)據(jù)進(jìn)行存儲(chǔ)，利用數(shù)據(jù)庫(kù)對(duì)容器數(shù)據(jù)進(jìn)行持久化存儲(chǔ)，這樣有利于歷史的回溯，防止采集到的數(shù)據(jù)發(fā)生丟失現(xiàn)象。

(5)監(jiān)測(cè)管理

監(jiān)測(cè)管理主要采用了數(shù)據(jù)可視化工具庫(kù)實(shí)現(xiàn)，立體地對(duì)安全威脅態(tài)勢(shì)進(jìn)行綜合展示以及對(duì)基于云平臺(tái)上運(yùn)行的容器狀態(tài)進(jìn)行可視化，以供管理員查看各個(gè)容器的安全狀態(tài)，包括運(yùn)行容器的基本信息、報(bào)警信息、資源預(yù)測(cè)、用戶狀態(tài)跟蹤和各個(gè)進(jìn)程狀態(tài)信息等，實(shí)現(xiàn)從攻擊預(yù)警、攻擊識(shí)別到分析取證的綜合能力。

安全監(jiān)測(cè)方法流程如圖2 所示。 啟動(dòng)服務(wù)后，接收監(jiān)控服務(wù)器請(qǐng)求，監(jiān)控代理開(kāi)始采集主機(jī)上運(yùn)行容器的信息，并將信息發(fā)送給數(shù)據(jù)庫(kù)進(jìn)行保存，服務(wù)端從數(shù)據(jù)庫(kù)中拉取數(shù)據(jù)并將數(shù)據(jù)傳入到數(shù)據(jù)預(yù)處理模塊，數(shù)據(jù)預(yù)處理模塊對(duì)數(shù)據(jù)進(jìn)行缺失值、異常值剔除并將主機(jī)和容器指標(biāo)之外的無(wú)用特征去除，將處理后的數(shù)據(jù)通過(guò)數(shù)據(jù)篩選器篩選出可用特征信息，之后一方面?zhèn)魅雸?bào)警規(guī)則中，與報(bào)警規(guī)則進(jìn)行匹配查看是否為異常數(shù)據(jù)，另外一方面?zhèn)魅隠ogistic-ARMA 模型中進(jìn)行訓(xùn)練預(yù)測(cè)，并實(shí)時(shí)將預(yù)測(cè)的數(shù)據(jù)與報(bào)警規(guī)則進(jìn)行匹配。 在該階段產(chǎn)生的數(shù)據(jù)均將傳入到數(shù)據(jù)庫(kù)和可視化界面，進(jìn)行數(shù)據(jù)的保存與顯示。

圖2 安全監(jiān)測(cè)方法流程圖

3 實(shí)驗(yàn)分析

本文采用實(shí)驗(yàn)室搭建的私有云平臺(tái)環(huán)境，將其中一臺(tái)計(jì)算節(jié)點(diǎn)服務(wù)器作為Docker 容器集群管理節(jié)點(diǎn)，并在 OpenStack 云平臺(tái)上創(chuàng)建 1 000 個(gè) Docker容器組成輕量級(jí)容器集群網(wǎng)絡(luò)，Docker 容器采用Alpine 基礎(chǔ)鏡像，并在該基礎(chǔ)鏡像上部署了探針、SSH 等服務(wù)，將其中一臺(tái) Docker 作為測(cè)試機(jī)，一臺(tái)作為攻擊機(jī)，一臺(tái)作為監(jiān)測(cè)終端進(jìn)行攻擊實(shí)驗(yàn)，攻擊機(jī)網(wǎng)段為：192.168.100.0/24， 測(cè)試終端網(wǎng)段為：192.168.100.0/24，Docker 集 群 網(wǎng) 段 為 ：172.16.0.0/16，并且在測(cè)試機(jī)上裝有探針去實(shí)時(shí)采集數(shù)據(jù)。 在OpenStack 各個(gè)計(jì)算節(jié)點(diǎn)上部署Docker 服務(wù)和各個(gè)功能模塊后，進(jìn)入監(jiān)控界面，如圖 3 所示。

圖3 容器集群整體狀態(tài)監(jiān)控圖

3.1 容器逃逸監(jiān)測(cè)

對(duì)1 000 個(gè)Docker 容器通過(guò)監(jiān)測(cè)其進(jìn)程名字空間測(cè)試容器逃逸，如圖4 所示，從監(jiān)測(cè)管理圖上可以直觀看到指定容器內(nèi)所有進(jìn)程的Namespace 狀態(tài)的實(shí)時(shí)監(jiān)測(cè)值，橫軸對(duì)應(yīng)采集時(shí)間序列，縱軸對(duì)應(yīng)進(jìn)程的 Namespace 狀態(tài)值。 正常行為的名字空間狀態(tài)值(Nsid)為 1。

圖4 容器內(nèi)進(jìn)程N(yùn)amespace 狀態(tài)監(jiān)控圖

在容器內(nèi)發(fā)起逃逸攻擊后，通過(guò)監(jiān)測(cè)管理中的進(jìn)程管理可以成功監(jiān)測(cè)出逃逸行為，圖5 所示為容器內(nèi)各進(jìn)程的最新Namespace 狀態(tài)值，可以看到Pid為 6464 的進(jìn)程屬于容器值為 9 時(shí)觸發(fā)觸發(fā)器，隨后發(fā)出報(bào)警。

圖5 容器逃逸監(jiān)測(cè)圖

3.2 DoS 攻擊監(jiān)控效果

在沒(méi)有合理劃分容器使用內(nèi)存的情況下，惡意用戶通過(guò)無(wú)限制申請(qǐng)內(nèi)存可造成容器運(yùn)行緩慢，甚至造成宿主機(jī)內(nèi)存耗盡發(fā)生宕機(jī)。 通過(guò)在名字為dockermon 容器內(nèi)運(yùn)行不斷申請(qǐng)動(dòng)態(tài)內(nèi)存的進(jìn)程，發(fā)起資源耗盡型拒絕服務(wù)攻擊，該容器的CPU 監(jiān)控實(shí)時(shí)狀態(tài)如圖6 所示，橫軸為時(shí)間序列，縱軸為實(shí)時(shí) CPU 時(shí)間片值。 可以看到 2:21:15PM 時(shí)刻 CPU使用驟然上升，并超過(guò)觸發(fā)器設(shè)置的閾值。

圖6 容器 CPU 使用量監(jiān)控圖

3.3 威脅預(yù)警功能測(cè)試

將大量的訓(xùn)練集和測(cè)試集數(shù)據(jù)流入Logistic-ARMA 預(yù)警模型中進(jìn)行訓(xùn)練，預(yù)警功能用于在應(yīng)用數(shù)據(jù)出現(xiàn)異常時(shí)，或數(shù)據(jù)即將發(fā)生異常時(shí)，根據(jù)用戶自定義編寫(xiě)的容器觸發(fā)報(bào)警規(guī)則向用戶發(fā)送警報(bào)，并且對(duì)攻擊類(lèi)型進(jìn)行有效判別。 實(shí)驗(yàn)結(jié)果如表1所示，本次實(shí)驗(yàn)共分為 8 組，其中有 3 組 DoS 攻擊，3 組容器逃逸，2 組正常操作，結(jié)果表明有 7 組預(yù)判正確，1 組預(yù)判失敗，該方法威脅預(yù)測(cè)準(zhǔn)確率可達(dá)85%。 其中判斷錯(cuò)誤的一組是由于網(wǎng)絡(luò)使用的帶寬接近設(shè)計(jì)的閾值，在應(yīng)用預(yù)警模型的時(shí)候進(jìn)行了誤判處理。 因此，后續(xù)可對(duì)該模型添加 SVM 機(jī)制進(jìn)行準(zhǔn)確率的提升。

表1 威脅預(yù)判記錄

4 結(jié)論

本文以目前較流行的OpenStack 云平臺(tái)為基礎(chǔ)，提出了基于OpenStack 云平臺(tái)的Docker 容器引擎安全監(jiān)測(cè)方法，并且利用BERT 序列標(biāo)注和Logistic-ARMA預(yù)警模型對(duì)容器資源進(jìn)行威脅態(tài)勢(shì)感知，一旦當(dāng)容器遭到了DoS 攻擊或者容器逃逸時(shí)，該方法能對(duì)其進(jìn)行有效識(shí)別并且進(jìn)行顯示。 當(dāng)容器在一段時(shí)間內(nèi)資源使用率過(guò)高或者負(fù)載率過(guò)高的時(shí)候，該方法能對(duì)其進(jìn)行未來(lái)一段時(shí)間內(nèi)的資源預(yù)測(cè)，一旦預(yù)測(cè)資源會(huì)超出瓶頸時(shí)，立即觸發(fā)報(bào)警功能，有利于管理人員及時(shí)進(jìn)行維護(hù)，從而滿足企業(yè)對(duì)于Docker 容器引擎的監(jiān)控，彌補(bǔ)了Docker 容器監(jiān)控在此方面的不足。