基于云平臺的網絡安全試驗管理系統

賈坤鵬，王曉鋒，劉淵

（1.江南大學物聯網工程學院，無錫214122；2.江南大學數字媒體學院，無錫214122）

0 引言

近年來，隨著互聯網的蓬勃發展，“互聯網+”已經延伸到生產生活的各個方面，但與此同時網絡與信息安全面臨嚴峻的挑戰[1]。網絡空間是一個多維、跨域、大尺度的空間，體系復雜多樣。為了應對日益嚴苛的網絡安全挑戰，有必要進行專業的網絡安全人才的培養。然而，由于在真實的網絡環境中進行網絡安全試驗成本高，且可能會造成嚴重的后果，甚至導致網絡癱瘓[1]。因此，網絡安全試驗大多在放在獨立的網絡環境中，進行攻防演練，新技術的驗證[2]。

由于OpenStack[3]平臺的開源性，大量的開發者涌入到社區開發中來，推動了OpenStack技術的發展。OpenStack采用模塊化設計，各模塊之間通過Rabbit-MQ消息隊列進行交互，降低了系統耦合性，提高了系統的響應速度和穩定性。OpenStack通過不同模塊間的協同合作，根據用戶需求實現對基礎設施資源即計算、存儲、網絡資源的彈性分配。OpenStack支持KVM、Docker、Xen、LXC 等多種虛擬化方式，被廣泛運用于云平臺的構建[4,7,12]。

但是，由于試驗環境創建、配置的復雜性，試驗人員浪費了大量時間。試驗拓撲規模有限，試驗效果不是很直觀且不支持實時查看[4,7]。如何快速、有效、方便地進行網絡安全試驗成為當前研究的熱點話題。我們基于OpenStack云平臺，調用jTopo開源網絡拓撲編輯器，通過圖元拖拽生成試驗場景。試驗人員可基于該場景進行快速部署，部署完成以后可在該場景中進行各類典型網絡安全試驗驗證，并通過Zabbix實現了虛擬機狀態的分布式監控。重點研究了試驗場景可視化展示與操作、自動部署與釋放、分布式虛擬機狀態監控等問題。

1 相關工作

目前，基于云平臺的網絡安全試驗平臺引起了廣泛的關注，相關開發者給出了不同的解決方案。文獻[4]基于云平臺和虛擬化技術，搭建了OpenStack平臺，并在平臺上基于Glance組件創建了多個攻防試驗主機模板，基于該模板實現了不同功能主機的快速創建。主機創建好以后，可進行DoS攻擊、端口掃描測試、遠程控制攻擊等常見網絡安全試驗。然而，試驗過程中虛擬機狀態無法進行實時監控，試驗場景也過于單薄。

文獻[7]采用B/S架構，在平臺上集成了VMware虛擬機技術，通過定制和分發試驗模板的方式，完成攻防試驗的自動配置和快速恢復。實現了用戶的管理，不同角色用戶具有對應的權限。教師可以對學生的試驗結果進行評分。但是，VMware對虛擬網絡的支持并不好，只支持VLAN方式組網，拓撲規模受限，不能進行大規模的網絡仿真試驗，并不能達到理想效果。

文獻[8]基于OpenStack平臺，設計并實現了云平臺資源監控系統，并通過Libvirt中間層提供的API對平臺上虛擬機的關鍵資源數據進行采集存儲，并進行可視化展示。然而由于其可視化展示曲線不能實時查看，用戶無法實時關注當前虛擬機的狀態，且不支持分布式部署，不能自動發現服務器上的虛擬機。

文獻[12]收集了目前主流脆弱操作系統，建立了兩種鏡像庫，設計了符合真實場景的網絡架構，進行網絡攻防。并基于OpenStack的Dashboard實現鏡像的管理，虛擬機的創建等功能。利用經典的LAMP架構，提供相關信息滲透工具的下載。并且建立了知識體系庫，方便用戶對相關知識進行了解。然而，繁雜的試驗場景，復雜的操作步驟，可能讓用戶也無從下手，無法獨立進行試驗從而進行網絡安全知識的學習。

針對上述問題，本文基于OpenStack云平臺，采用前后端分離的設計方法，前端融合jTopo、Bootstrap-table、jQquery等框架，實現了拓撲的生成與管理功能。后端接口采用RESTFUL風格的API，分別實現了場景部署、釋放、刪除等功能。并基于Zabbix實現了分布式虛擬機狀態監控，有效解決了試驗場景創建以及虛擬機狀態實時監控等問題。

2 基于云平臺的網絡安全試驗管理系統體系架構

2.1 基于云平臺的網絡安全試驗管理系統體系架構

如圖1所示，基于云平臺的網絡安全試驗管理系統，搭建了一臺控制節點、一臺網絡節點以及三臺計算節點的Mitaka版本的OpenStack云平臺，每臺節點均安裝了NTP服務進行時鐘同步。實現了試驗場景可視化展示與操作，試驗場景自動部署與釋放以及分布式虛擬機狀態監控等關鍵技術。

圖1 系統體系架構

其中，控制節點的jTopo組件負責試驗場景的拖拽生成，Bootstrap-table表格組件用于試驗場景的渲染以及管理，Zabbix-server組件用來收集網絡節點中的Zabbix-proxy發來的各計算節點中Zabbix-agent監控的虛擬機的狀態信息。各計算節點中的Zabbix-agent通過調用KVM提供的Libvirt虛擬機管理工具，獲取虛擬機的CPU、內存、網卡信息，并調用Zabbix-web組件進行前端展示。

用戶可通過拖拽生成場景文件或自行上傳場景文件，可在前端選擇所需場景文件進行試驗環境的自動部署與釋放。本文通過在KVM虛擬機中搭載Quagga路由軟件，實現了動態路由的配置[14]，依托內核命令實現了鏈路帶寬、時延的設置[15]，從而提高了試驗場景的逼真性。此外，通過修改內核參數，提高了虛擬機創建速度，縮短了試驗場景的創建時間。試驗場景部署好以后，用戶可進行各類網絡安全試驗，試驗過程中各虛擬機的狀態信息可實時監控，并支持虛擬機的自動發現功能。

2.2 關鍵技術分析

2.2.1 試驗場景可視化展示與操作

本文通過jTopo開源網絡拓撲編輯器融合jQuery前端框架，實現了試驗拓撲可視化生成。通過Boot-strap-table表格插件異步調用存儲在MySQL數據庫中的試驗場景信息，并對其中的關鍵信息進行可視化展示。采用前后端分離的設計模式，用戶在前臺的各種操作通過AJAX調用后端的REST API接口，進行數據交互。下對其做簡要描述。

（1）試驗拓撲可視化生成：jTopo網絡拓撲編輯器基于 HTML5，提供了 Stage、Scene、Node、Container，相對于當下其他圖形開發軟件具備兼容性高、接口設計簡單、傳輸效率高等特點[5]。然而其Node屬性只有text、visible、dragable 等信息，并沒有 image、flavor、port等網絡信息，需要對其默認屬性進行添加。jQuery是一款優秀的JavaScript框架，操作輕巧便捷，功能強大。

本文使用jQuery調用HTML5原生的drag、drop方法實現圖元的拖動。通過jTopo Stage的frames屬性，定義了畫布的重畫頻率為1000/frams，所以我們拖動圖元到畫布以后會通過ondragstart（）方法傳遞底圖以及必要參數到Canvas并刷新界面，更新圖元信息從而實現拖拽效果。

圖2 試驗拓撲可視化

如圖2所示，jQuery通過監聽鼠標移動事件，將節點拖拽到Canvas畫布，Canvas獲取節點信息，調用JTopo.Node（）方法初始化節點，并通過serializedProperties（）方法設置自定義屬性。節點之間通過連線表示連接關系，鼠標單擊節點設置節點信息，即部署該節點使用鏡像的image值、節點規格大小flavor值、該節點的網卡信息等。用戶可基于拖拽生成的場景進行導出，導出文件包含上述關鍵信息，可基于該文件進行部署。

（2）試驗場景可視化管理：Bootstrap-table是一款基于Bootstrap的jQuery插件，具備扁平化、輕量級的特點，因其與Bootstrap其它標簽無縫結合，被專門用來顯示數據表格。使用該插件應首先在網頁中需引入JavaScript腳本以及CSS樣式文件，然后在HTML中聲明表格對象，最終通過JavaScript腳本完成表格數據初始化，用戶也可根據個人需求通過bootstrapTable方法實現分頁、排序、導出、查找等功能。

然而由于靜態腳本的局限性，用戶對表格數據的修改無法及時反饋到數據庫中，這就嚴重影響了時效性與直觀性。

圖3 Bootstrap-table數據交互

如圖3所示，本系統通過PHP腳本實時查詢數據庫中的試驗信息表中的關鍵信息，并封裝成JSON格式反饋到Bootstrap-table框架，最終渲染前端用戶界面，實現表格的異步更新。

表1為試驗信息表，用戶testuser需設置試驗編號id、試驗名稱testname信息，并通過testinfo字段描述試驗，可添加試驗的注意事項、操作方法、預期結果等信息。testfile字段存儲試驗場景文件名，真實文件存儲在topology目錄下。

用戶基于試驗場景的各種操作需要傳遞場景文件名稱到后臺程序，本文通過對表格deploy、edit列設置了 formatter屬性，調用 function（value,row,index）方法，獲取當前列的row.testname值，并通過AJAX傳遞給后端RESTFUL API接口，實現了前后端的分離，大大降低了系統的耦合性。

表1 試驗信息表

2.2.2 試驗場景自動部署與釋放

用戶在前端界面發起試驗部署或釋放請求后，通過AJAX傳遞場景文件名到控制節點，根據參數的不同分別執行deploy（）、delete（）方法，最終完成試驗環境的構建與釋放。

針對OpenStack部署生成的虛擬機無法支持動態路由，無法設置鏈路參數[3]問題進行了優化。并根據Nova體系架構進行了分析，對創建虛擬機過程中涉及到的組件，及其消息傳遞經過的RabbitMQ消息隊列中關鍵參數，進行了調優，從而提高了虛擬機創建、刪除速度，實現了試驗環境的快速復現。

（1）試驗場景自動部署：如圖4所示，前端界面在收到用戶對某個場景文件的創建請求后，發送異步消息到控制節點服務器，控制節點首先解析XML配置文件，并下發虛擬機鏡像到對應計算節點。

圖4 試驗場景自動部署

本文采用層次結構分明且語法靈活簡單的XML標簽來存儲網絡、主機節點、路由器節點的配置信息，并劃分為多層。第1層為根元素，表明該文檔作用。第2層分別定義了NetworkInfo、InstanceInfo、RouterInfo、用來存儲網絡、路由器、主機信息。如表2所示NetworkInfo的第3層定義了name、IP信息。

表2 NeworkInfo標簽子元素定義

InstanceInfo 第 3 層定義了 name、image、flavor、networkname、delay、bandwith、az等信息，如表 3 所示。

RouterInfo相對于InstanceInfo增加了BGP配置信息，如表4所示。

表3 InstanceInfo標簽子元素定義

表4 NeworkInfo標簽子元素定義

配置解析后，Neutron組件根據NetworkInfo值調用neutron.create_network（）方法創建虛擬網絡，Nova組件調用nova.servers.create（）方法創建虛擬機。

然而，由于Neutron組件提供的qrouter軟件不支持動態路由，且無法轉發非直連網絡的流量[3]，這嚴重制約了試驗場景的規模。本文通過在虛擬機中搭載Quagga路由軟件，設置系統ip_forward值為1開啟路由轉發，啟動zebra服務，進入路由器配置模式后，便可像配置實體路由器一樣進行RIP、OSPF、BGP協議配置[14]。

而為了實現路由協議的自動化部署，只需將zebra服務設置為開機自啟動，并將網絡配置信息寫入配置文件，采用sshpass方式由控制節點注入計算節點中的虛擬機即可。

此外，由于OpenStack平臺不支持鏈路性能參數的仿真[3]，所以本文采用文獻[15]提出的方法，在接收到鏈路參數時進行帶寬、時延的仿真。

在進行大規模場景創建時，如何提高創建虛擬機速度成為當前研究的熱點話題。如圖5所示，Nova各組件都與RabbitMQ消息隊列有交互，其中nova-conductor組件和MySQL直接交互。因此，RabbitMQ消息隊列以及nova-conductor組件的性能成為制約創建速度的瓶頸。

本文首先修改系統文件描述符的最大值，然后通過改rabbitmq-server文件中LimitNOFILE值，來提高RabbitMQ最大連接數。并修改nova.conf文件中conductor字段中的worker值用來提升nova-conductor對應的worker數目。這樣，在創建大規模場景時，消息隊列的壓力得以緩解，虛擬機創建速度顯著提高。

（2）試驗場景自動釋放：如圖7所示，系統收到釋放請求后，首先刪除網絡信息，接著刪除主機信息，最終完成整個試驗場景的刪除。

圖5 Nova架構

圖6 試驗場景自動釋放

2.2.3 分布式虛擬機狀態監控

為加強對試驗效果的分析，需要對試驗過程中各虛擬機的關鍵資源信息進行監控。由于OpenStack自帶的監控組件Ceilometer功能還不夠完善，只關注采集未進行存儲，當數據量增大時，Ceilometer性能會大幅下降甚至會導致服務崩潰[7]。Zabbix網絡監控系統采用分布式部署，并將所有歷史數據、趨勢和配置信息存儲導數據庫中，所有邏輯運算都在服務端執行，對被監控對象性能影響很小[10]。本文通過Libvirt虛擬機管理軟件獲取計算節點中虛擬機的關鍵信息[8]，然后傳輸到Zabbix中，Zabbix添加自定義參數后并通過Zabbixweb進行可視化展示。當虛擬機數目增多時，通過Zabbix的自動發現功能[11]，自動發現被監控計算節點中新加入的虛擬機。

如圖7所示，zabbix符合C/S架構，包含服務端zabbix server，客戶端 zabbix agent，以及代理端 zabbix proxy三部分組成[11]。本文控制節點中的zabbix server負責與三臺計算節中的zabbix agent進行交互、觸發器計算、發送告警通知，并進行數據存儲。webserver負責圖形化展示，并直接與用戶進行交互；網絡節點的zabbix proxy用于分擔計算節點的負載，定時向控制節點提交數據。

圖7 zabbix架構

然而，zabbix監控項中僅有被監控的計算節點宿主機信息，不含計算節點機中創建的虛擬機的信息。需添加自定義監控項[11]，對虛擬機中的CPU、磁盤、網絡等信息進行監控。雖然OpenStack的Hypervisor支持多種虛擬化方式[3]，但由于OpenStack是基于KVM開發的，對KVM親和性比較好。所以，我們可通過KVM提供的Libvirt工具對虛擬機的數據進行采集。

如圖8所示，Libvirt通過虛擬機管理器，對虛擬機進行管理，支持對各種虛擬機監控程序，提供了一個應用編程接口（API）庫，并集成了對多種編程語言的綁定[12]。我們首先通過命令“libvirt.open（"qemu:///system"）”建立連接，然后通過虛擬機UUID獲取到相關信息并通過zabbix_send發送給zabbix-server。

圖8 Libvirt架構

（1）CPU使用率：Libvirt無法直接獲得CPU利用率，但可以通過 domain.info（）[4]獲得當前時刻 cputime_start，以及數秒后的cputime_end，然后通過domain.info（）[3]獲得 CPU 核數，cputime_diff= 監控結束時間-監控開始時間，最終通過如公式1計算：

（2）內存使用率：調用memoryStats（）函數獲取內存用量和未用量，通過公式2計算：

（3）網卡流量：通過調用interfaceStats（）函數獲取該網卡的rx_bytes（接收字節數）、以及tx_bytes（發送字節數）參數。

（4）磁盤 I/O：通過調用 blockStatsFlags（）函數獲取磁盤的rd_bytes（讀取字節數）、以及wr_bytes（寫入字節數）。

在獲取到這些參數后，我們首先需要對Zabbix服務端配置文件進行修改，設置UnsafeUserParameters=1表示允許用戶自定義參數。其中自定義參數格式如下 ：UserParameter=kvm.domain.cpu_util[*]，/etc/zabbix/zabbix-kvm.py--item cpu--uuid$1，并添加自動發現規則kvm.domain.discover，自動發現計算節點中新增的虛擬機。

3 試驗驗證與分析

3.1 試驗環境

搭建OpenStack集群，由一臺控制節點、一臺網絡節點、三臺計算節點組成?？刂乒濣c處理器為Intel Xeon E5-2620 v2*4、內存64GB、硬盤1TB；網絡節點處理器為 Intel Xeon E5-2609 v2*4、內存32GB、硬盤1TB；計算節點1：處理器為Intel Xeon E5-2620 v3*2、內存64GB、硬盤 512MB；計算節點2：處理器為Intel Xeon E5-2620 v3*2、內存 32GB、硬盤 512MB；計算節點 3：處理器為Intel Xeon E5-2620 v2*4、內存128GB、硬盤1TB；服務器均為DELL R760服務器，操作系統為CentOS 7.5版本，OpenStack為Mitaka版本。

3.2 試驗場景驗證

3.2.1 典型網絡安全試驗

用戶可選擇拖拽生成場景文件，或者自行上傳場景文件到場景管理界面進行網絡安全試驗。以NMAP端口掃描、DoS攻擊等典型網絡安全試驗為例，進行試驗平臺的驗證。如圖9所示，用戶首先選中左側菜單相應圖標，拖放到右側畫布中，Canvas畫布根據圖元信息進行Node初始化。然后，選中Node節點，在右側信息欄設置Node信息并更新。最后，導出場景文件到topology目錄。

圖9 拓撲編輯

表5 場景信息

如圖9所示，拖拽兩臺主機節點到畫布，并采用封裝了 Nmap、Hping3、tcpdump等軟件的 CentOS鏡像，場景信息如表5所示。導出場景文件并上傳到場景管理界面。

本文設置Bootstrap-table的striped屬性進行隔行變色展示，設置sortable屬性允許排序，設置search屬性進行搜索，設置pagination屬性進行分頁展示，并設置url=load_data.php，從數據庫實時加載數據。

圖10 場景管理

load_data.php通過mysqli_connect（）方法連接數據庫，通過mysqli_fetch_assoc（）查詢 task表，并拼接成JSON格式傳送到Bootstrap-table進行渲染。

如圖10所示，用戶可選擇對應場景文件進行部署、查看、編輯、刪除等操作。接下來對NMAP端口掃描試驗進行自動部署?？刂乒濣c收到部署請求后，下發鏡像到計算節點，計算節點調用Nova相關方法完成網絡network10的創建，兩個host節點的部署。部署完成以后，我們可通過ping命令進行驗證。在完成驗證以后，我們可在該場景中進行Nmap試驗以及DoS攻擊等典型網絡安全試驗。

host1通過Nmap命令，對host2上敏感端口進行掃描，結果如圖11所示，可發現host2上開設了多個敏感端口。

圖11 NMAP結果

虛擬機創建完成以后，zabbix會自動檢測，并添加cpu%、memory%、磁盤讀寫、網卡流量等監控項?？稍趜abbix監控頁面依次點擊監測中->最新數據->kvm監控項查看對應數據，并查看數據動態曲線。

本文在host2上使用命令對CPU進行加壓，如圖12所示，發現短時間內CPU使用率飆升至接近100%，這表明我們的狀態監控數據真實有效。

為進一步對Zabbix監控的其他指標進行測試，通過hping3工具在host上對host2進行DoS攻擊。首先，通過Netperf測量host2的帶寬，共測試5組數據取平均值可得其帶寬接近800MB。

然后，在host1上執行hping3-c 5000-d 60000-S-w 64-p 80--flood host2命令，對host2進行DoS攻擊。如圖13所示，在1分鐘左右的上升以后，host2網卡流量最終接近800MB，帶寬幾乎被占滿。

圖12 CPU壓力測試

圖13 host2網卡流量

3.2.2 LDDoS試驗

LDDoS攻擊通過簡單、粗暴的網絡攻擊，占用系統過多的服務資源，對線上環境造成了嚴重影響。文獻[18]重點研究了LDDoS場景的攻擊場景配置以及采集與分析，并進行了多組試驗進行驗證。

用戶可通過拖拽生成如圖14所示的場景，包括3臺路由器以及6臺主機。導出場景文件后，然后上傳到場景管理界面進行部署。

圖14 場景拓撲

自動部署程序會依次進行網絡、主機的創建。然后，進行路由協議、鏈路特性的設置。選擇net_1網絡中3臺主機為攻擊主機、net_3網絡中3臺主機為目標主機，并根據文獻[18]設計的策略，進行LDDoS攻擊。文獻[18]采用手動統計R1與R3產生的Update報文的形式來對試驗效果進行評估，本文可直接對虛擬機中的關鍵數據進行監控，實時觀測虛擬機狀態。文獻[18]設計的基于CAIDA AS Rank拓撲以及大規模網絡拓撲均可上傳到場景管理界面進行場景部署，

4 結語

本文基于OpenStack云平臺，融合了jTopo網絡拓撲編輯器以及BooStrap-table表格框架進行前端展示，采用前后端分離的設計模式，實現了試驗場景的一鍵部署與釋放。并通過Zabbix實現了對虛擬機的自動發現以及關鍵狀態信息的分布式監控。用戶可通過本平臺，快速進行各類網絡安全試驗，試驗過程中可對指定虛擬機狀態進行實時監控。大大提升了試驗人員的工作效率，完美解決了傳統網絡安全試驗平臺的可用性、時效性差等問題，值得加以推廣。