崔 軻,燕 瑋,劉子健,張慕榕,賈星威,許鳳凱
(華北計(jì)算機(jī)系統(tǒng)工程研究所,北京100083)
隨著虛擬化技術(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]。
輕量級(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)。
目前主流的容器管理平臺(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]。
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)行。
針對(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è)方法流程圖
本文采用實(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)控圖
對(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è)圖
在沒(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)控圖
將大量的訓(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ù)判記錄
本文以目前較流行的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)控在此方面的不足。