章思宇，周育玲，劉楚彤

（上海交通大學(xué)，上海 200240）

0 引言

隨著云計算技術(shù)的成熟和普及，越來越多的機構(gòu)開始將傳統(tǒng)數(shù)據(jù)中心的應(yīng)用遷移至云環(huán)境下部署和運行。大型企業(yè)和高校通常會建設(shè)自己的私有云，以確保系統(tǒng)和數(shù)據(jù)安全可控。云環(huán)境下，主機和應(yīng)用服務(wù)仍然面臨操作系統(tǒng)、數(shù)據(jù)庫、Web 應(yīng)用漏洞和弱口令等各類安全風(fēng)險，因此漏洞掃描仍是不可或缺的一項重要工作[1-2]。本文探討云環(huán)境下網(wǎng)絡(luò)結(jié)構(gòu)和用戶使用模式的改變對漏洞掃描帶來的挑戰(zhàn)和機遇，并以O(shè)penStack 為例，利用私有云集中化管理帶來的優(yōu)勢，實現(xiàn)對云主機漏洞的精準和高效檢測。

1 傳統(tǒng)漏洞掃描流程

主機漏洞掃描的過程通?？煞譃椤按婊钚話呙琛薄岸丝趻呙琛薄胺?wù)識別”“漏洞檢測”和“弱口令檢測”5 個階段。

對于需要掃描的大段IP 地址，“存活性掃描”先通過ICMP ping 和最常用的數(shù)十個TCP 端口的掃描，快速判斷各個IP 地址上是否有存活的主機，從而大幅減少需要進行后續(xù)掃描的IP 地址數(shù)量。如果主機不響應(yīng)ICMP ping 報文，且存活性掃描所使用的數(shù)十個最常用端口均未開放，則會被掃描器漏檢，即使其他端口有開放的服務(wù)也不會被檢測。漏洞掃描時也可跳過存活性掃描步驟，對掃描范圍內(nèi)所有IP 地址都進行深入檢測，但會浪費大量時間用于對未接入主機的空閑IP 地址做深入掃描。

“端口掃描”階段對各個IP 地址進行全面端口探查。通常，為了加快掃描速度，只根據(jù)掃描器內(nèi)置的列表檢查常見的數(shù)千個端口，也可要求掃描器對65 535 個TCP 端口全部進行掃描。對于掃描到開放的端口，“服務(wù)識別”階段通過指紋技術(shù)判斷其應(yīng)用層協(xié)議，從而實現(xiàn)對運行在非默認端口上的服務(wù)漏洞和弱口令檢測?！奥┒礄z測”和“弱口令檢測”通常并行進行，前者利用一系列程序腳本檢查開放的端口、服務(wù)是否存在已知漏洞[3]，后者利用掃描器預(yù)置的弱口令字典進行口令暴力猜解。更龐大的弱口令字典可提升弱口令檢測能力，但也相應(yīng)延長了檢測時間。

2 私有云主機漏洞精準掃描

2.1 云環(huán)境網(wǎng)絡(luò)特點

在云環(huán)境下，用戶通常可以自助創(chuàng)建云主機、配置網(wǎng)絡(luò)和防火墻規(guī)則，無需云平臺管理員介入。在OpenStack 及許多其他常用云計算平臺的典型配置下，用戶新創(chuàng)建的云主機默認只接入一個私有網(wǎng)絡(luò)，只能和當前租戶、當前私有網(wǎng)絡(luò)下的其他云主機通信。要允許云主機訪問互聯(lián)網(wǎng)，或?qū)ν馓峁┓?wù)，必須在私有網(wǎng)絡(luò)和公共網(wǎng)絡(luò)之間添加一個路由器，并申請一個公網(wǎng)IP地址（或稱為“浮動IP地址”）關(guān)聯(lián)到云主機或路由器上[4]。

云主機與外界的通信受到“安全組”的保護。安全組由一系列端口白名單規(guī)則構(gòu)成。云平臺默認的安全組規(guī)則通常放行云主機對外的訪問（云主機訪問互聯(lián)網(wǎng)），而對內(nèi)的訪問（外網(wǎng)訪問云主機）只放行ICMP 和SSH（TCP 22 端口）等個別協(xié)議。用戶如需開放如Web、FTP 等其他服務(wù)，需專門添加安全組規(guī)則放行相應(yīng)的TCP/UDP 端口[5]。

相較傳統(tǒng)的數(shù)據(jù)中心網(wǎng)絡(luò)管理模式，云環(huán)境下租戶云主機私有網(wǎng)絡(luò)的隔離，以及必須主動添加公網(wǎng)路由器、公網(wǎng)IP 地址和安全組規(guī)則才能對外提供服務(wù)的設(shè)計，提高了云主機默認情況下的安全性，實現(xiàn)了網(wǎng)絡(luò)的精細化管理。

2.2 活躍地址和端口的精準定位

由于云環(huán)境網(wǎng)絡(luò)隔離和訪問控制的加強，云主機默認暴露的端口數(shù)量大幅減少，尤其大多數(shù)Windows 主機開放的TCP 135、139、445 端口不被云平臺默認安全組放行，使得漏洞掃描對主機存活性判斷變更不夠準確，容易遺漏需要檢測的IP地址。

為了解決這一問題，需要對傳統(tǒng)漏洞掃描流程進行改造，將漏洞掃描系統(tǒng)與云平臺管理系統(tǒng)進行對接，利用云平臺集中管理的網(wǎng)絡(luò)狀態(tài)和配置信息幫助掃描器精準、高效地定位活躍地址和端口。

一方面，調(diào)取云平臺浮動IP 分配信息，以取代漏洞掃描系統(tǒng)的“存活性掃描”功能。以O(shè)penStack 云平臺為例，Neutron 組件管理了云平臺的虛擬網(wǎng)絡(luò)設(shè)施[6]。Neutron 將網(wǎng)絡(luò)配置和狀態(tài)信息保存在MySQL 數(shù)據(jù)庫中，其中floatingips 表存儲了已分配的浮動IP 地址，包括IP 地址（floating_ip_address）、所屬項目（project_id）、關(guān)聯(lián)的設(shè)備端口（fixed_port_id）及當前的狀態(tài)（status）等字段。從該表中取狀態(tài)為“ACTIVE”（活躍）的浮動IP地址直接進入“端口掃描”步驟。

另一方面，分析用戶安全組規(guī)則的設(shè)置，提取通過安全組放行的TCP 端口列表，引導(dǎo)掃描器有針對性地進行端口掃描。OpenStack Neutron 的安全組規(guī)則保存在securitygrouprules 表中，包括所屬的安全組（security_group_id）、方向（direction）、二層協(xié)議（ethertype）、三層協(xié)議（protocol）和端口號范圍（port_range_min、port_range_max）等字段。securitygroupportbindings 表建立了安全組（security_group_id）與設(shè)備端口（port_id）的關(guān)聯(lián)關(guān)系，結(jié)合浮動IP 與設(shè)備端口的關(guān)聯(lián)關(guān)系，可列舉各個浮動IP 上的詳細安全組規(guī)則。多個不同的設(shè)備端口可使用同一個安全組。從securitygrouprules 表中取方向為“ingress”（入方向）和三層協(xié)議為TCP 的安全組規(guī)則，將放行的端口號范圍作為漏洞掃描系統(tǒng)“端口掃描”的目標端口范圍。

2.3 弱口令字典的強化

部分云平臺為用戶提供主機安全管理的增值服務(wù)模塊，用戶可在云主機操作系統(tǒng)內(nèi)安裝管理代理（Agent）實現(xiàn)病毒掃描、入侵檢測以及安全配置基線核查[7]。該模塊可提供一定的漏洞檢測能力，但不能取代通過網(wǎng)絡(luò)的主動漏洞掃描，因為其在主機上的檢查無法充分考慮外部網(wǎng)絡(luò)結(jié)構(gòu)和防護策略，同時支持檢查的應(yīng)用服務(wù)種類也較為有限。

盡管如此，它在主機操作系統(tǒng)內(nèi)部采集的信息如主機名、系統(tǒng)賬號名稱等信息，對引導(dǎo)漏洞掃描系統(tǒng)精準地進行“弱口令檢測”有顯著的意義，尤其是可提高SSH 和Windows 遠程桌面弱口令猜解的速度和成功率。因此，從云平臺主機安全模塊的管理系統(tǒng)中導(dǎo)出進行基線核查時發(fā)現(xiàn)的所有系統(tǒng)賬戶名稱，用于擴充和強化漏洞掃描系統(tǒng)的用戶名字典。

2.4 漏洞通知的自動化

云環(huán)境下用戶可自助申請、釋放浮動IP 地址的特性，使得IP 地址的動態(tài)性明顯增強。浮動IP地址的分配具有隨機性，相鄰的IP 地址可歸屬不同的用戶，同一個用戶獲取的浮動IP 地址則通常又是離散的，同時已釋放的浮動IP 地址可被其他用戶再次獲取使用。

這一特點給漏洞的持續(xù)跟蹤和通知處置帶來困難。為了減少人工查詢、派發(fā)的工作量，還需改造現(xiàn)有的漏洞通知處置系統(tǒng)[8]，使其實時對接浮動IP分配和云平臺用戶數(shù)據(jù)庫，自動將掃描發(fā)現(xiàn)的漏洞分發(fā)、通知到浮動IP 的管理者。

OpenStack Neutron 的floatingips 表記錄了各浮動IP 所屬的項目（project_id），而項目和用戶賬號的管理由OpenStack 的Keystone 組件負責。在Keystone 的數(shù)據(jù)庫中，project 表記錄了項目基本信息，user 表記錄了用戶基本信息，用戶的Email 地址等保存在extra 字段的JSON 字符串中。assignment表建立了用戶與項目的關(guān)系，包括用戶（actor_id）在項目（target_id）里的角色（role_id）。role_id 對應(yīng)的角色名稱保存在role 表中。對于掃描器發(fā)現(xiàn)存在漏洞的浮動IP 地址，找到其所屬的項目，然后通過Keystone 列舉該項目的所有管理和成員用戶（角色名稱為“admin”或“member”），由漏洞通知處置系統(tǒng)自動將漏洞信息發(fā)送至其郵箱。

2.5 掃描流程改造小結(jié)

通過上述工作對傳統(tǒng)漏洞掃描流程的改造，使漏洞掃描系統(tǒng)更適應(yīng)私有云環(huán)境的網(wǎng)絡(luò)特點和使用模式。流程改造和數(shù)據(jù)對接結(jié)構(gòu)總結(jié)如圖1 所示。通過對接OpenStack Neutron 的浮動IP 地址狀態(tài)和安全組規(guī)則信息，替代了傳統(tǒng)漏洞掃描的“存活性掃描”模塊，并為“端口掃描”模塊提供精準的端口范圍以提高掃描效率。利用云平臺主機安全模塊采集的信息擴充“弱口令檢測”所使用的用戶名字典。將Keystone 和Neutron 數(shù)據(jù)庫關(guān)聯(lián)，提供浮動IP 地址的用戶聯(lián)系信息，支撐漏洞通知的自動發(fā)送。

圖1 私有云主機漏洞掃描流程改造

3 效果評估

本文以上海交通大學(xué)建設(shè)運營的jCloud 私有云平臺為例，對上述改造后的漏洞掃描流程進行實驗驗證。jCloud 交大云平臺以O(shè)penStack 為基礎(chǔ)，疊加了一系列增強和擴展功能，其中網(wǎng)絡(luò)和用戶身份仍基于OpenStack Neutron 和Keystone。云平臺提供的主機安全模塊為騰訊天眼云鏡，實驗對接的漏洞掃描系統(tǒng)為綠盟遠程安全評估系統(tǒng)。

3.1 數(shù)據(jù)對接分析

jCloud 交大云平臺上，用戶共創(chuàng)建了超過3 500個云主機，云平臺網(wǎng)絡(luò)共配置有132 個C 的浮動IP地址（共3.37 萬個）可供用戶申請使用。Neutron數(shù)據(jù)庫的floatingips 表中記錄了已分配的3 189 個浮動IP 地址，其中“ACTIVE”狀態(tài)的浮動IP 地址為2 099 個。

Neutron 數(shù)據(jù)庫securitygrouprules 表中存儲了安全組規(guī)則共計87 640 條。通過與活躍狀態(tài)的浮動IP 關(guān)聯(lián)，當前生效的安全組規(guī)則為19 707 條，其中入方向（ingress）的規(guī)則15 586 條。2 099 個浮動IP 地址中，放行ICMP 協(xié)議為1 717 個（81.8%）。通過對規(guī)則的分析和歸并，安全組放行的TCP 端口共計1 355 個，其中放行IP 地址數(shù)量最多的TCP端口列舉如表1 所示。

表1 安全組規(guī)則放行TCP 端口統(tǒng)計

通過上述對接，將傳統(tǒng)掃描流程下需對3.37 萬個IP 地址進行存活性掃描的工作取代，直接為掃描系統(tǒng)提供2 099 個準確的活躍IP 地址目標，地址范圍減小93.7%。端口掃描階段也只需對1 355個安全組放行的TCP 端口進行掃描，相比于掃描全部65 535 端口掃描減少了97.9%的開銷。與漏洞掃描系統(tǒng)內(nèi)置的2 002 個常用端口列表相比，安全組放行的1 355 個端口僅297 個在該列表中，如果只根據(jù)該列表掃描，將遺漏許多云主機開放的端口。此外，主機安全模塊的基線核查數(shù)據(jù)總共提供了108 條系統(tǒng)賬戶名信息，擴充到掃描系統(tǒng)的用戶名字典中。

3.2 漏洞掃描效果分析

利用漏洞掃描系統(tǒng)分別按照傳統(tǒng)掃描流程及改造后掃描流程對云主機進行漏洞掃描，對比掃描耗時和漏洞發(fā)現(xiàn)數(shù)量，結(jié)果總結(jié)如表2 所示。兩種掃描流程總耗時差異不大，均在12 h 左右。值得說明的是，在傳統(tǒng)掃描流程下啟用存活性掃描，且端口掃描范圍是掃描器內(nèi)置的2 002 個常用端口，若不進行存活性掃描且對全部65 535 個TCP 端口進行掃描，耗時將達7 天以上。

在傳統(tǒng)掃描流程下，經(jīng)過存活性掃描，共1 945 個IP 地址被認為存活，小于Neutron 報告的ACTIVE 狀態(tài)的浮動IP 地址數(shù)量2 099 個。經(jīng)過端口掃描，傳統(tǒng)流程共發(fā)現(xiàn)了1 284 個IP 地址上共計3 013 個開放的TCP 端口，而改進后的流程共發(fā)現(xiàn)1 472 個IP 地址上共計3 441 個開放的TCP 端口。可見，改進后流程發(fā)現(xiàn)的開放服務(wù)的主機數(shù)和TCP端口數(shù)分別提高了14.6%和14.2%。此外，改進后流程報告的高危漏洞數(shù)7 854 個也比傳統(tǒng)流程的7 169個增加了9.5%，弱口令檢出數(shù)也從3 個增加到6 個。

實驗結(jié)果顯示，通過掃描流程的改進，系統(tǒng)在相近的時間內(nèi)，可在私有云環(huán)境下發(fā)現(xiàn)更多的開放TCP 服務(wù)端口和高危漏洞，提升了漏洞和弱口令檢測能力。

表2 漏洞掃描效果對比

4 結(jié)語

針對私有云特點對主機漏洞掃描流程進行改造，實現(xiàn)了漏洞掃描系統(tǒng)與OpenStack 云管理系統(tǒng)的對接，充分發(fā)揮了云平臺網(wǎng)絡(luò)資源和安全策略集中管控的優(yōu)勢，并利用浮動IP 地址分配、設(shè)備端口狀態(tài)、安全組規(guī)則以及主機安全基線核查信息，引導(dǎo)漏洞掃描系統(tǒng)精確地進行端口掃描和漏洞、弱口令檢測。實驗結(jié)果顯示，改造后的掃描方法可將TCP 服務(wù)端口發(fā)現(xiàn)數(shù)量和高危漏洞檢出數(shù)量分別提升14%和9.5%。