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

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

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

0 引言

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

1 理論基礎(chǔ)

1.1 輕量級容器引擎

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

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

1.2 容器管理平臺

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

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

1.3 安全風險分析

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

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

Docker 鏡像安全風險：Docker 鏡像大多數(shù)來自于鏡像倉庫，倉庫中存在用來釣魚的惡意鏡像，這些鏡像一旦被用戶下載使用，將會對整個項目產(chǎn)生致命的危害[13]。

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

針對以上安全風險，本文從以下兩方面來保障容器的安全運行：

(1)安全加固策略

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

(2)專用安全組件

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3 實驗分析

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

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

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

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

圖4 容器內(nèi)進程Namespace 狀態(tài)監(jiān)控圖

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

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

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

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

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

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

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

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

4 結(jié)論

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