王宇， 李巍， 李舟軍

(北京航空航天大學 計算機學院，北京 100083)

軟件定義網(wǎng)絡(software defined network,SDN)是一種新型架構，在這種網(wǎng)絡架構中，路由器的控制功能被抽離出來. 而路由器通信所需要的各種協(xié)議(比如ARP(address resolution protocol)協(xié)議中MAC(media access control)地址的學習)，都在集中的控制器上進行完成，稱之為SDN控制器.

這種新型架構重新定義了網(wǎng)絡，也提高了網(wǎng)絡中的通信效率，目前這種SDN控制器和路由器之間的交互采用的是OpenFlow協(xié)議.

安全審計的意義在于對目前的系統(tǒng)做出評價、對存在的威脅進行分析，最后進行對整個系統(tǒng)的安全性進行評估，在SDN架構中，這種分析的結果可以放在SDN控制器上集中展示，并且在SDN控制器上進行統(tǒng)一的控制.

在審計系統(tǒng)的標準上，在Zhang[1]運用到了CC國標. 而在審計系統(tǒng)的層級上，Ma[2]分析了多級服務器的審計系統(tǒng)的實現(xiàn)，主要致力于研究多級系統(tǒng)的審計，并且加入了審計智能分析的功能，但SDN的主要架構只有兩層.

在審計技術中，有系統(tǒng)從用戶的操作日志中進行分析，對用戶的操作進行總結性的審核[3]，這項技術在輕量級的路由器審計上并不適用，因為路由器上并沒有太大的內(nèi)存提供給程序進行分析. 同時，在這個基礎上，Lane等[4]也嘗試從系統(tǒng)調用級別上進行操作的攔截，在內(nèi)核上建立一個審計系統(tǒng)，但是在家用路由器上，沒有這種權限.

在系統(tǒng)架構和部署方式上，目前在系統(tǒng)架構上，主要采用C/S[5]，服務器和客戶端模式的比較多，在SDN架構下，控制器對應了C/S架構中的server，而在部署方式上，主要采用集中式的部署方式，例如Estrin等[6]實現(xiàn)的安全審計系統(tǒng)，實行了對于日志的統(tǒng)一處理，在此上面進行審計系統(tǒng)的實施，但這種方式的缺點并沒有達到網(wǎng)絡與審計架構的耦合.

在流量分析上，目前基于流量的分析研究有一種基于信息熵計算的分析方法. 比如在Song等[7]的工作中，就用信息熵檢測了網(wǎng)路流量中的異常，并最終結合了大數(shù)據(jù)的分析方法. 同時，信息熵也可以用來研究具體協(xié)議的異常之處，比如在Chen[8]的工作當中，就將信息熵用來檢測DNS的攻擊.

在呂慧穎等[9]的工作中，提出了一種基于攻擊模擬的網(wǎng)絡安全風險分析方法，這對于審計系統(tǒng)來說應該是個新思路，即從一個攻擊者的角度去模擬，然后提出分析方式，在審計中，也可以如此. 在李明等[10]的工作中，提出了一種基于AHP的網(wǎng)絡化彈藥攻擊決策攻擊方法，這些方法對審計工作有較大的啟示，能夠防御批量安全攻擊事件的審計系統(tǒng)更強大.

在Scott-Hayward等[11]的工作中，對目前的SDN安全性進行了調查，并討論了使用SDN框架導出的安全性增強和框架引入的安全挑戰(zhàn). 在Shin等[12]的工作中，提出了一種新型的基于SDN的攻擊方式，在Kreutz等[13]的工作中，主要針對了SDN的可靠性和安全性進行了研究，并且提出了幾種可能啟用SDN漏洞的威脅載體.

在Han[14]的工作中，提出了一種基于SDN架構下，對SDN中的流量進行分析的攻擊檢測方式，采用了基于信息熵的檢測方法，這種檢測方法主要是針對SDN控制器的，并提出了之后的基于SDN的攻擊檢測主體，將從SDN的單個控制器轉向SDN的一個子網(wǎng).

本文在傳統(tǒng)的C/S審計架構下，提出了一種將審計融合到網(wǎng)絡環(huán)境中，運用SDN特殊架構的審計架構，運用家用路由器向SDN控制器發(fā)送的請求，進行流量分析審計. 基于上述架構，實現(xiàn)了對于流量中(IP,端口)的信息熵計算，并在最終的展示模塊上，預留給了管理員控制和管理的接口，實現(xiàn)了管理和控制.

1 相關技術分析

1.1 網(wǎng)絡嗅探

1.1.1 Libpcap實現(xiàn)框架

為了實現(xiàn)在輕量級的路由器上進行流量分析，本文將從底層的libpcap上進行抓包.

在libpcap中，抓包框架主要通過幾個重要的模塊實現(xiàn)，包括設備查詢模塊、設備讀取模塊、數(shù)據(jù)包過濾模塊、數(shù)據(jù)包捕獲模塊、數(shù)據(jù)包處理模塊.

① 設備查詢模塊，其作用查詢目前設備中可以用來嗅探的設備. ② 設備讀取模塊，其作用是讀取上一步已經(jīng)獲得的設備名稱，并打開，返回一個后續(xù)模塊所需要的會話句柄. ③ 數(shù)據(jù)包過濾模塊，生成嗅探器能夠“讀懂”的BPF代碼，在生成在整個框架中，數(shù)據(jù)包過濾模塊主要作用在后續(xù)的數(shù)據(jù)包獲取模塊上. ④ 數(shù)據(jù)包獲取模塊，網(wǎng)卡的數(shù)據(jù)包進行篩選和獲取. ⑤ 數(shù)據(jù)包處理模塊，數(shù)據(jù)包處理模塊是整個框架靈活性最高的模塊.

1.2 SDN架構及南向協(xié)議

SDN的確切定義目前最具代表性的是ONF組織提出的基于OpenFlow的架構. ONF認為SDN架構分為3個層面：應用層面、網(wǎng)絡控制層面、網(wǎng)絡架構層，其中網(wǎng)絡架構層的通信受到網(wǎng)絡控制層面的控制來進行通信，具體架構如圖 1所示.

圖1 基于OpenFlow的SDN網(wǎng)絡架構Fig.1 SDN network architecture based on OpenFlow

目前主流的通信協(xié)議是Openflow協(xié)議，本文也將針對OpenFlow協(xié)議進行研究.

1.3 OpenFlow協(xié)議標準

1.3.1 OpenFlow協(xié)議

OpenFlow交換機與controller的連接建立和連接建立之后，OpenFlow交換機和controller都會進行通信，相應的通信是OpenFlow協(xié)議的主體，OpenFlow協(xié)議將消息類型劃分了3種，根據(jù)消息的發(fā)出者來進行區(qū)分：controller-to-switch，由控制器controller發(fā)起，主要用來管理和獲取Switch的狀態(tài)；Asynchronous，由Switch發(fā)起，用來告知SDN控制器網(wǎng)絡事件和Switch內(nèi)部的配置變化；Symmetric，無需建立，主要是連接建立之前的Hello、Echo等.

連接建立的整個過程大致有3個階段：①Hello通信階段；②設備信息獲取階段；③通信階段.

通信流程的具體流程如圖2所示.

圖2 OpenFlow交換機與控制器通信流程Fig.2 OpenFlow switch and controller communication process

2 SABIE系統(tǒng)需求分析與設計

2.1 SABIE系統(tǒng)需求分析

整個工具需要的功能設計主要包括對于流量信息的獲取、對于流量信息的分析、對于流量分析結果的最終展示. 流量信息獲取的要求是占用內(nèi)存小，并且流量信息獲取的主要數(shù)據(jù)為IP地址和端口號，滿足最小的數(shù)據(jù)傳輸需求.

2.2 SABIE系統(tǒng)結構

2.2.1 系統(tǒng)部署結構

系統(tǒng)結構主要分為3個部分，即客戶端和服務器和SDN控制器. 系統(tǒng)結構部署圖如圖3.

圖3 系統(tǒng)結構部署圖Fig.3 System structure deployment diagram

2.2.2 SABIE系統(tǒng)模塊功能

系統(tǒng)功能模塊圖如圖4.

圖4 SABIE系統(tǒng)功能模塊圖Fig.4 SABIE system function module diagram

2.2.3 SABIE系統(tǒng)功能時序圖

系統(tǒng)功能時序圖描述了整個系統(tǒng)工作的流程，如圖5所示.

圖5 SABIE系統(tǒng)結構時序圖Fig.5 SABIE system structure timing diagram

2.3 主要工作過程描述

系統(tǒng)的工作前提是路由器需要加入到SDN架構中，并且路由器是支持相應的協(xié)議的.

在服務器上，需要對客戶端到來的信息進行收集，并通過數(shù)據(jù)包封包分析技術進行分析，獲取到所需要的信息，并且在服務器上進行存儲和管理，通過數(shù)據(jù)庫技術來實現(xiàn)存儲和管理，并讀取數(shù)據(jù)庫進行相關的計算，獲得最終的審計結果.

在SDN控制器上，需要對最終的審計信息進行展示，這個展示需要運用到web服務器的實現(xiàn)，通過查看web內(nèi)容，來判斷是否會存在異常的情況. 在發(fā)現(xiàn)異常之后，又會給控制器一個接口，來改變目前系統(tǒng)的運行狀態(tài)，管理者可以通過這種改變來定位目前系統(tǒng)中存在的潛在威脅.

3 SABIE系統(tǒng)功能實現(xiàn)

3.1 數(shù)據(jù)包獲取模塊

數(shù)據(jù)包獲取模塊通過直接調用libpcap函數(shù)進行設計和實現(xiàn).

數(shù)據(jù)包獲取模塊主要分為以下步驟.

① 設備查詢模塊. 設備查詢模塊通過調用libpcap中的pcap_lookupdev函數(shù)進行實現(xiàn).

② 設備讀取模塊.

③ 過濾器設置和應用模塊. 這個模塊主要是為了之后的結果更加簡潔明了而設計的，過濾到那些無關緊要的數(shù)據(jù)包.

④ 數(shù)據(jù)包獲取模塊. 將截獲到的數(shù)據(jù)包通過回調函數(shù)的方式，進一步的進行操作.

其中，過濾器設置主要分為兩部分：首先通過過濾器進行物理的篩選，在客戶端進行. 邏輯篩選的主要邏輯是在服務器上對所需要的信息進行裁剪，在服務器上，對于TCP(transfer control protocol)數(shù)據(jù)包，只需要IP地址、數(shù)據(jù)包長度等信息，并需要對整個數(shù)據(jù)包的數(shù)據(jù)內(nèi)容進行邏輯篩選，篩選出服務器需要的信息，再通過socket進行傳輸，以達到整個系統(tǒng)的實現(xiàn).

數(shù)據(jù)包信息傳輸?shù)牡讓訉崿F(xiàn)采用socket傳輸實現(xiàn).

3.2 數(shù)據(jù)包信息分析處理模塊

3.2.1 數(shù)據(jù)分析模塊

在整個系統(tǒng)中，審計服務器可以接收到來自于客戶端的數(shù)據(jù)包信息，而服務器上需要對數(shù)據(jù)包信息進行分析，需要解決的是什么樣的信息才是整個審計系統(tǒng)需要的.

在TCP報文中，可以獲取到的信息主要有源端口、目的端口，對應的是具體的進程信息，這對之后的信息分析部分的設計會有幫助，主要通過IP地址和端口的序列進行信息的整合.

OpenFlow協(xié)議數(shù)據(jù)報文格式如圖6所示.

圖6 OpenFlow數(shù)據(jù)報文格式Fig.6 OpenFlow data packet format

對應結構體設計見表1.

表1 Struct OFHeaderTab.1 Struct OFHeader

其中，8位版本號指的是OpenFLow協(xié)議版本號，類型指的是OpenFlow協(xié)議中的具體協(xié)議號，消息長度指的是首部和后續(xù)載荷總共的長度，Transaction ID是一個內(nèi)部的標識，用來將request和reply進行匹配而生成的一個字段.

關于類型中，具體指什么類型，如表2.

表2 OpenFlow協(xié)議Type具體含義對照表

Tab.2 OpenFlow protocol Type specific meaning comparison table

0Hello1Error2Echo Request3Echo Reply4Vendor5Features Request6Features Reply7Get Config Request8Get Config Reply9Set Config10Packet Input Notification11Flow Removed Notification12Port Status Notification13Packet Output14Flow Modification15Port Modification16Stats Request17Stats Reply18Barrier Request19Barrier Reply

重點是packet-in報文類型，即報文類型type字段為10的報文，這個報文產(chǎn)生的緣由是在OpenFlow交換機在自己內(nèi)部的流表中找不到對應的流表項則會向SDN控制器發(fā)出packet-in請求，請求SDN中央控制器的指示. 目前的一些DDoS攻擊，已經(jīng)可以通過這種方式，進行針對SDN控制器的DDoS攻擊了，所以在之后的審計信息計算過程中，會加入對這一個分支的具體檢測.

在處理和計算模塊當中，需要對流量的異常與否進行檢測，這個檢測的方法主要是通過計算信息熵來完成.

3.2.2 審計信息處理模塊

具體算法流程如下.

假設目前設定的抓包間隔為T，固定的抓包個數(shù)為W.

① 在獲取完W個數(shù)據(jù)包的信息之后，進入步驟②.

② 記(目的IP，目的端口)為一組數(shù)據(jù)對，以這個數(shù)據(jù)對為標準來區(qū)分所有數(shù)據(jù)，記數(shù)據(jù)對的個數(shù)為N，每一組數(shù)據(jù)對的出現(xiàn)次數(shù)為

μi， 1≤i≤N.

③ 通過μi和W計算出關于(目的IP，目的端口)的信息熵Hα為

(2)

④ 記每個packet-in包中(目的IP)出現(xiàn)的個數(shù)為N2，每一組(目的IP)次數(shù)為θi，1≤i≤N2，通過θi和W計算出關于(目的IP，packet-in消息)的信息熵Hβ為

(3)

Hα和Hβ的主要不同點在于，Hα反映了通過路由器的流量不規(guī)律性是否出現(xiàn)了變化，即它可能會存在DDoS攻擊，而Hβ反映了這種變化的具體針對目標是針對網(wǎng)絡中的主機還是針對的是SDN控制器本身.

信息熵計算完成后，將會運用數(shù)據(jù)庫技術將相應的信息熵和時間段記錄下來，將最終的結果交于SDN控制器，同時，信息熵的展示模塊也將會在SDN控制器上進行，審計服務器端的工作就是獲取和分析信息，并計算出SDN控制器所需要的結果.

3.3 審計信息展示和控制管理模塊

3.3.1 審計信息展示模塊

在得到了信息熵的結果之后，將會通過echarts等開源的項目對最終的審計結果進行展示，具體實現(xiàn)是在最終的web界面中展示目前最新的10個時間段的信息熵計算值，展示方式是通過在網(wǎng)頁中調用echarts API，在echarts中輸入目前的最新10個信息熵計算值，然后在進行顯示，管理者可以從信息熵的變化中看出是否會存在異常.

3.3.2 控制管理模塊

在控制管理模塊中，通過數(shù)據(jù)庫腳本對整個系統(tǒng)的運行進行配置，主要是包括數(shù)據(jù)庫中計算信息熵的時間間隔和路由器上的抓包間隔時間的配置.

SDN控制器的南向協(xié)議中，有比如OpenFlow協(xié)議中的Set Config和ovsdb協(xié)議等功能可以實現(xiàn)SDN控制器對于OpenFlow交換機的配置管理，但是在配置的同時，還需要對OpenFlow交換機中的邏輯結構進行控制，雖然在OpenFlow協(xié)議中有配置，ovsdb協(xié)議可以對Openvswitch中的數(shù)據(jù)庫進行管理，但是在對于OpenFlow交換機上的具體程序的控制是沒有的. 基于這個情況，采用的是OpenFlow交換機主動地去詢問SDN控制器目前的控制邏輯結構.

控制管理模塊是保證了SDN控制器能夠和OpenFlow交換機進行通信的一個模塊，這也體現(xiàn)了整個系統(tǒng)架構的靈活性. 這部分的具體實現(xiàn)是通過更改數(shù)據(jù)庫中event的時間間隔和抓包參數(shù)配置進行管理，管理者在發(fā)現(xiàn)目前的流量中存在異常后，可以通過更改數(shù)據(jù)庫中的event時間間隔更改信息熵計算時間差，通過抓包參數(shù)配置來更改抓包間隔和個數(shù)，來實現(xiàn)最后的管理模塊.

4 系統(tǒng)測試

4.1 實驗環(huán)境

路由器：NETGEAR4300，系統(tǒng)版本：OpenWrt Chaos Calmer 15.05，安裝Openvswitch[2.3.90].

服務器：Ubuntu17.04，安裝mysql[5.7.18].

SDN控制器：與服務器位于同一臺機器，安裝opendaylight，apache，php.

4.2 功能測試

功能測試中將測試每個模塊的功能實現(xiàn)，下面將分模塊進行測試.

由于路由器上部署程序將涉及到嵌入式設備的編譯，需要搭建交叉編譯環(huán)境，技術實現(xiàn)難度太大，將采用監(jiān)聽路由器輸出端口的方式進行測試.

首先是在路由器上，對端口的監(jiān)聽進行配置.

監(jiān)聽端口配置完畢后，進入服務器，打開監(jiān)聽模塊，運行. 在監(jiān)聽PC上運行，分別運行catchpacket和checkchange程序：進入opendaylight，運行控制器，在控制器的node下可以看到OpenFlow交換機，目前的配置是每隔10 min抓取一次數(shù)據(jù)包，所以等待大約2 h，就可以獲得10次信息熵的計算值.

如圖7，查看web界面：可以看到，管理員已經(jīng)可以查看目前的網(wǎng)絡狀態(tài)的信息熵計算.

圖7 查看web界面Fig.7 View web

通過控制功能測試，通過改寫腳本envent.sql中的兩個時間，如圖8，改為10 s.

圖8 修改腳本Fig.8 Modify script

在數(shù)據(jù)庫中查看HaInformation表的計算結果，發(fā)現(xiàn)現(xiàn)在的計算結果間隔為10 s，還需要進行的測試是，信息熵的計算能否真正地反應出網(wǎng)絡流量中的異常. 這個測試主要分為兩個小實驗：用Nmap(the network mapper)進行端口掃描；查看信息熵計算結果. 結果如圖9～11所示.

在Nmap掃描實驗中，前9個正常網(wǎng)絡數(shù)據(jù)都在2～4波動，而第10個數(shù)據(jù)是Nmap掃描時間段的信息熵值，Nmap對每個端口進行掃描時候，會截到大量端口不一樣的包表現(xiàn)在信息熵上，是信息熵的突然增大，如圖9.

圖9 Nmap掃描結果Fig.9 Nmap scan results

圖10 LOIC-DDoS攻擊結果Fig.10 LOIC-DDoS attack results

圖11 程序消耗的字節(jié)數(shù)Fig.11 The number of bytes consumed by the program

在LOIC-DDoS攻擊實驗中，前5個數(shù)據(jù)是正常網(wǎng)絡數(shù)據(jù). 而在LOIC軟件中進行DDoS攻擊，截獲的數(shù)據(jù)包的目的端口幾乎一樣，只有源端口在不停變化. 表現(xiàn)在信息熵上，是信息熵從第6組數(shù)據(jù)信息熵開始迅速變小，7、8、9、10組數(shù)據(jù)由于只能截到一樣的(目的IP，目的端口)，所以計算值為0.

這兩個小實驗說明信息熵的計算在表現(xiàn)異常上很明顯.

4.3 性能測試

性能測試主要分為兩方面，所占帶寬和程序運行所占內(nèi)存.

所占帶寬分析：在程序中，每個報文所截取的字節(jié)是14+20+20=54 B，在客戶端沒有對TCP和IP的報文分支進行分析，所以選擇了最長的TCP報文頭部，加上ethernet和IP報文頭部，總共是54 B.

在數(shù)據(jù)庫中，查詢在運行階段所有到來的報文的總報文數(shù)和總長度如表3，可以得到總共長度，計算總報文數(shù)×54，得到程序消耗字節(jié)數(shù).

表3 程序消耗字節(jié)分析Tab.3 Program consumption byte analysis

可以看出，程序所占帶寬的比例不大. 內(nèi)存查看，通過ps指令分析，可以查看到程序運行的內(nèi)存在8 MB左右.

目前Openwrt嵌入式設備的內(nèi)存大約在16 MB，所以程序理論上是可以運作的.

5 結 論

從傳統(tǒng)C/S架構出發(fā)，提出了一種基于SDN架構的審計系統(tǒng)設計思路. 在這個架構下，保證了路由器的正常運行，審計系統(tǒng)的正常工作，達到了審計路由器中是否存在DDoS攻擊的目的，并且在SDN控制器上加入了可以控制和展示的模塊，使得整個系統(tǒng)可以完整地運行. 并且整個系統(tǒng)對于路由器內(nèi)存的使用僅有8 MB，所用網(wǎng)絡負載2.67%，達到了輕量級的目的. 未來的工作主要有：①研究基于SDN中Flow的檢測和分析方法;②研究基于OpenFlow協(xié)議的控制模塊.