私有云環境下主機安全漏洞高效檢測*

章思宇，周育玲，劉楚彤

（上海交通大學，上海 200240）

0 引言

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

1 傳統漏洞掃描流程

主機漏洞掃描的過程通常可分為“存活性掃描”“端口掃描”“服務識別”“漏洞檢測”和“弱口令檢測”5 個階段。

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

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

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

2.1 云環境網絡特點

在云環境下，用戶通?？梢宰灾鷦摻ㄔ浦鳈C、配置網絡和防火墻規則，無需云平臺管理員介入。在OpenStack 及許多其他常用云計算平臺的典型配置下，用戶新創建的云主機默認只接入一個私有網絡，只能和當前租戶、當前私有網絡下的其他云主機通信。要允許云主機訪問互聯網，或對外提供服務，必須在私有網絡和公共網絡之間添加一個路由器，并申請一個公網IP地址（或稱為“浮動IP地址”）關聯到云主機或路由器上[4]。

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

相較傳統的數據中心網絡管理模式，云環境下租戶云主機私有網絡的隔離，以及必須主動添加公網路由器、公網IP 地址和安全組規則才能對外提供服務的設計，提高了云主機默認情況下的安全性，實現了網絡的精細化管理。

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

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

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

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

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

2.3 弱口令字典的強化

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

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

2.4 漏洞通知的自動化

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

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

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

2.5 掃描流程改造小結

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

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

3 效果評估

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

3.1 數據對接分析

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

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

表1 安全組規則放行TCP 端口統計

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

3.2 漏洞掃描效果分析

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

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

實驗結果顯示，通過掃描流程的改進，系統在相近的時間內，可在私有云環境下發現更多的開放TCP 服務端口和高危漏洞，提升了漏洞和弱口令檢測能力。

表2 漏洞掃描效果對比

4 結語

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