王 鵑，劉世輝，文 茹，洪 智 ，王 江 ，樊成陽 ，張浩喆

1.軟件工程國家重點實驗室，武漢 430072

2.空天信息安全與可信計算教育部重點實驗室，武漢 430072

3.武漢大學 計算機學院，武漢 430072

4.清華大學 計算機科學與技術系，北京 100084

1 引言

伴隨著以云計算、大數(shù)據(jù)為代表的新型業(yè)務的發(fā)展，傳統(tǒng)網(wǎng)絡難以滿足其提出的靈活資源需求，主要是因為傳統(tǒng)網(wǎng)絡早已變得過于復雜且只能處于靜態(tài)的運行模式。所以，亟需一種全新的網(wǎng)絡架構來實現(xiàn)網(wǎng)絡的靈活管理，由此SDN[1]應運而生。軟件定義網(wǎng)絡SDN（Software Defined Network）是由美國斯坦福大學Clean Slate研究組提出的一種新型網(wǎng)絡創(chuàng)新架構，可通過軟件編程的形式定義和控制網(wǎng)絡，其本質(zhì)特點是控制平面和數(shù)據(jù)平面的分離以及開放的可編程性，使得網(wǎng)絡管理變得更加簡單、靈活，被認為是網(wǎng)絡領域的一場革命。

OpenFlow[2]是目前SDN的主流協(xié)議，其定義了SDN控制器和交換機之間的通信標準。通過網(wǎng)絡控制平面和數(shù)據(jù)平面的分離實現(xiàn)網(wǎng)絡的靈活控制，控制層利用OpenFlow協(xié)議向交換機下發(fā)相應指令，從而對整個網(wǎng)絡實現(xiàn)集中控制。目前，基于OpenFlow的SDN設備已經(jīng)在實際中得到了一定規(guī)模的部署。

然而，隨著SDN的發(fā)展和應用，基于OpenFlow的SDN網(wǎng)絡也面臨著很多新的安全挑戰(zhàn)[3-12]。其中一個重要的威脅是OpenFlow協(xié)議的無狀態(tài)性使得在SDN網(wǎng)絡中無法實現(xiàn)更細粒度的訪問控制。目前SDN的防火墻應用模塊并不完善，其功能只是簡單進行包過濾，僅僅對網(wǎng)絡流量中首個數(shù)據(jù)包進行安全處理，實現(xiàn)了簡單的訪問控制，但是這種簡單的控制，對于整個網(wǎng)絡的安全防護是遠遠不夠的。

如果網(wǎng)絡管理員想要實現(xiàn)基于狀態(tài)的細粒度訪問控制，例如外網(wǎng)不能與內(nèi)網(wǎng)進行直接連接操作，但是內(nèi)網(wǎng)可以請求獲得外網(wǎng)的數(shù)據(jù)。對于現(xiàn)有的SDN控制器[13]的防火墻功能是無法滿足以上功能要求的。此外，現(xiàn)有的架構中，SDN控制器是集中控制中心，無論是包過濾防火墻還是狀態(tài)檢測防火墻[14]均應被部署在控制器中。但是，當主機或者網(wǎng)絡設備發(fā)送數(shù)據(jù)包時，除第一個數(shù)據(jù)包會被控制器檢測外，只有當前流的第一個包會被控制器檢測，對于其他數(shù)據(jù)包，控制器是無法直接進行決策的。如果把每個數(shù)據(jù)包都送給控制器進行檢測，又會給控制器帶來極大的性能開銷。因此，如何實現(xiàn)有狀態(tài)的細粒度訪問控制是當前SDN網(wǎng)絡面臨的一個重要挑戰(zhàn)。

針對這一問題，從SDN架構特點出發(fā)，通過在SDN交換機中增加狀態(tài)表和狀態(tài)轉(zhuǎn)換表以及在控制器中添加狀態(tài)表，設計并實現(xiàn)了一種基于OpenFlow的SDN狀態(tài)檢測防火墻系統(tǒng)。本文主要貢獻有以下幾點。

（1）SDN防火墻大多為傳統(tǒng)的包過濾防火墻，缺少狀態(tài)檢測功能，而本文通過交換機和控制器協(xié)同工作的方式實現(xiàn)對全局網(wǎng)絡通信狀態(tài)的檢測。這種設計方案相對高效且不違背SDN架構設計的宗旨和初衷，在保證控制器的集中化控制特性不受影響的基礎下，在控制器和交換機之間使用較小的通信量實現(xiàn)了控制器對全局網(wǎng)絡通信狀態(tài)的獲取和控制。

（2）實現(xiàn)了基于狀態(tài)的數(shù)據(jù)流轉(zhuǎn)發(fā)?，F(xiàn)有OpenFlow流表是無狀態(tài)的，因為無法完成對網(wǎng)絡通信狀態(tài)進行檢測的功能，帶來了很多安全威脅，如無法實現(xiàn)細粒度訪問控制、防御DDos攻擊困難等。本文對OpenFlow協(xié)議中定義的流表的基本結(jié)構進行了修改，添加了相關狀態(tài)項，使得數(shù)據(jù)流轉(zhuǎn)發(fā)不再與狀態(tài)無關，完成了對狀態(tài)表的維護與更新的功能。同時，管理員可以基于狀態(tài)表定義規(guī)則，實現(xiàn)細粒度的訪問控制。

（3）性能分析表明，相對于傳統(tǒng)的基于包過濾的防火墻，本文提出的基于狀態(tài)的防火墻綜合性能更優(yōu)。

2 相關工作及分析

目前，SDN防火墻方面的相關工作有：

Shin等人提出了一個OpenFlow安全應用開發(fā)框架FRESCO[7]，它是對NOX[15]控制器進行的二次開發(fā)，在對NOX內(nèi)核進行安全加固的基礎上，對外提供遺留網(wǎng)絡安全系統(tǒng)的接口，保證平臺的最大兼容性。FRESCO包含16個基本模塊，每個基本模塊都有5個接口：輸入、輸出、事件、參數(shù)和操作，其最大亮點為基本模塊可以通過這5個接口組合成復雜的安全應用模塊，實現(xiàn)許多通用網(wǎng)絡安全平臺和功能，從而替代防火墻、IDS和流量管理工具。

Porras等人提出一種加固的控制平面操作系統(tǒng)FortNOX[16]。通過擴展開源的NOX操作系統(tǒng)的Send_OpenFlow_Command模塊，增加策略沖突消解功能。來自不同應用的策略設定不同的安全等級，如來自安全應用（如防火墻、入侵檢測、入侵防御）、可信應用等提供安全服務的應用策略具有最高優(yōu)先級；控制層操作系統(tǒng)的本地應用策略具有中等優(yōu)先級；其他提供業(yè)務的應用被分配最低優(yōu)先級。擴展后的FT_Send_OpenFlow Command匯集所有應用策略，通過驗證應用策略攜帶的數(shù)字簽名，對策略進行源認證，檢查是否存在策略沖突，并根據(jù)優(yōu)先級決定策略沖突發(fā)生時的動作。

其中與所做的工作最相關的是由Sethi等人提出的模型檢測控制器[17]，其提出了學習型交換機和一個簡單狀態(tài)防火墻的概念。該防火墻通過兩個交換機協(xié)同工作，實現(xiàn)了阻止外網(wǎng)和內(nèi)網(wǎng)主動通信的功能。但是該方案側(cè)重于網(wǎng)絡狀態(tài)的描述，并沒有給出有效的防火墻狀態(tài)檢測機制和系統(tǒng)。在此基礎上，提出了一種基于OpenFlow的SDN狀態(tài)檢測防火墻。

3 基于OpenFlow的SDN狀態(tài)檢測防火墻系統(tǒng)

SDN狀態(tài)檢測防火墻系統(tǒng)旨在為SDN網(wǎng)絡構建基于狀態(tài)的細粒度訪問控制機制。通過對開源SDN控制器Floodlight原有的包過濾防火墻進行功能擴展，在交換機中截獲數(shù)據(jù)包并抽出與應用層狀態(tài)有關的信息，將其中重要信息發(fā)送給控制器，并以此為依據(jù)決定數(shù)據(jù)的轉(zhuǎn)發(fā)，從而實現(xiàn)基于狀態(tài)的訪問控制，同時具有較好的適應性、擴展性及較低的開銷。

3.1 系統(tǒng)框架

為了實現(xiàn)狀態(tài)防火墻的功能，同時滿足控制器的集中控制，方便網(wǎng)絡管理員統(tǒng)籌管理和操作，本文提出了如圖1所示系統(tǒng)架構，其中包括以下5個模塊。

（1）Key Extractor模塊：交換機中包頭信息提取模塊，提取數(shù)據(jù)包頭部中的關鍵信息。

（2）State Table-SW模塊：狀態(tài)表的建立和更新模塊，該模塊的功能為在交換機中建立連接狀態(tài)表，同時將連接狀態(tài)表同步更新到控制器中，而該狀態(tài)表的更新由變換流表通過set_state指令控制。

（3）Shifted Flow模塊：變換流表（Shifted Flow Table）建立和更新模塊，控制器下發(fā)指令在交換機中建立變換流表，負責狀態(tài)轉(zhuǎn)換過程以及數(shù)據(jù)包轉(zhuǎn)發(fā)操作。

圖1 系統(tǒng)框架圖

（4）Checking Legitimacy模塊：合法性檢測模塊，負責判斷到達交換機的數(shù)據(jù)包屬于哪一次連接。

（5）State Table-C模塊：控制器端的命令下發(fā)、狀態(tài)表的同步模塊，在控制器中建立連接狀態(tài)表，并與交換機中的狀態(tài)表保持同步，同時當收到交換機發(fā)送Packet_In消息時，該模塊通過將包頭信息、狀態(tài)信息和連接狀態(tài)表或者防火墻規(guī)則集進行對比，分配相應狀態(tài)，同時下發(fā)變換流表到交換機中。

前4個模塊是在交換機中添加相應的功能實現(xiàn)的，用于數(shù)據(jù)包匹配。State Table-C模塊在控制器中實現(xiàn)，用于判斷連接的合法性。State Table-C模塊需要利用控制器提供的的核心服務（OpenFlow Core Service）與交換機通信，通過控制器內(nèi)部提供的Firewall模塊查詢查詢防火墻規(guī)則判斷數(shù)據(jù)包是否合法。

3.2 系統(tǒng)關鍵技術

本系統(tǒng)涉及的關鍵技術主要包括：連接狀態(tài)表的建立，變換流表管理以及狀態(tài)表的更新管理。

3.2.1 連接狀態(tài)表的建立

本系統(tǒng)定義了STATE_IN和OFP_STATE＿MOD兩種消息結(jié)構完成控制器和交換機中連接狀態(tài)表的同步操作。當交換機中的狀態(tài)表發(fā)生狀態(tài)更新時，其將會向控制器發(fā)送一個STATE_IN消息，通知控制器對相應狀態(tài)記錄進行更新；而當控制器中的狀態(tài)表發(fā)生狀態(tài)更新時，控制器會向交換機發(fā)送一個OFP_STATE＿MOD消息，命令交換機對相應狀態(tài)記錄進行更新。

針對本系統(tǒng)所要解決的實際問題，連接狀態(tài)表由四元組組成（Match Field，State，Timeout，Packet_count），其中Match Field包括數(shù)據(jù)包的IP（源地址和目的地址，但是只針對連接狀態(tài)，在匹配連接狀態(tài)表時不進行區(qū)分）和協(xié)議類型（包括TCP/UDP，ICMP等等）；State表示連接狀態(tài)；Timeout表示連接的超時時間；Packet_count表示通過的數(shù)據(jù)包數(shù)目。

3.2.2 變換流表管理

為了實現(xiàn)連接狀態(tài)表的更新、維護以及管理，本系統(tǒng)對OpenFlow流表進行了相應的修改，添加了狀態(tài)屬性（State）以及下一狀態(tài)屬性（Next_State），并且重新定義了數(shù)據(jù)包和流表項匹配的過程。匹配的結(jié)果不僅依賴于數(shù)據(jù)包包頭的信息，同時取決于數(shù)據(jù)包的狀態(tài)。當匹配成功時，將會執(zhí)行OFPIT_SET_STATE指令，該指令將變換流表中相應記錄中的下一個狀態(tài)值（Next_State）賦值給狀態(tài)表中的狀態(tài)屬性值；同時按照ACTION指令處理該數(shù)據(jù)包；若匹配不成功則交換機將會向控制器發(fā)送包含數(shù)據(jù)包包頭和狀態(tài)信息的Packet_in消息，控制器返回Flow_mod消息作為回應，向交換機中添加流表。

3.2.3 狀態(tài)更新管理

本系統(tǒng)的另一個關鍵技術是狀態(tài)的更新管理，即當一個數(shù)據(jù)包經(jīng)過交換機時，交換機將會做哪些操作。

（1）狀態(tài)查詢，將數(shù)據(jù)包包頭信息作為查詢關鍵字（如源IP地址）對連接狀態(tài)表進行查詢，如果沒有相關查詢記錄，則在狀態(tài)表中添加該記錄，并將其狀態(tài)置為DEFAULT。

（2）變換流表實現(xiàn)狀態(tài)轉(zhuǎn)換，當數(shù)據(jù)包和狀態(tài)連接表匹配成功后，將在數(shù)據(jù)包包頭中添加狀態(tài)信息；該狀態(tài)信息也會作為匹配項和表換流表進行匹配，如果匹配成功，則將包頭中的下一狀態(tài)信息寫回連接狀態(tài)表，對狀態(tài)表進行更新，同時根據(jù)流表中ACTION表項對數(shù)據(jù)包進行處理操作。

（3）狀態(tài)更新，包含添加、刪除和修改，一般會通過OFPIT_SET_STATE指令完成狀態(tài)更新，有些情況下會使用State_mod。

4 系統(tǒng)實現(xiàn)流程

4.1 具體流程

在網(wǎng)絡中，大部分數(shù)據(jù)傳輸是基于面向連接的TCP協(xié)議，并且一旦控制了連接建立的過程，就認為整個通信過程是可信的。在本系統(tǒng)中，TCP的數(shù)據(jù)包處理流程較為典型，且具有代表性，因此本文將以TCP數(shù)據(jù)包狀態(tài)檢測流程為重點進行設計和實現(xiàn)。

TCP數(shù)據(jù)包狀態(tài)檢測模塊的主要工作是創(chuàng)建一個TCP連接狀態(tài)表。具體流程如圖2所示：

（1）當數(shù)據(jù)包到達交換機后，交換機的關鍵信息提取模塊啟動，并和交換機中的狀態(tài)表（state table）進行匹配操作。

（2）如果沒有匹配成功，則在狀態(tài)表中添加該記錄，將狀態(tài)置為DEFAULT，并通知控制器進行相應的狀態(tài)表更新轉(zhuǎn)向（4）。

（3）如果匹配成功，則將狀態(tài)信息寫入數(shù)據(jù)包包頭。

（4）與交換機中的變換流表進行匹配，如果匹配失敗，沒有找到對應流表信息，那么則判斷該數(shù)據(jù)包是否為SYN數(shù)據(jù)包。

（5）如果為SYN數(shù)據(jù)包，說明為新連接的建立，則與控制器中防火墻模塊的規(guī)則集進行匹配，匹配成功后，向交換機中發(fā)送Flow_mod消息，在變換流表中，添加記錄，動作為forward，分配下一個狀態(tài)標志，交換機收到后，立即執(zhí)行SET_STATE操作，即更新連接狀態(tài)表（包括控制器中的連接狀態(tài)表（State Table-C，和交換機中的連接狀態(tài)表（State Table-SW），兩者通過State_mod實現(xiàn)同步），進行合法性檢測后，轉(zhuǎn)發(fā)該數(shù)據(jù)包。

（6）如果不是SYN 數(shù)據(jù)包，說明可能是原有連接的一部分，不需要規(guī)則匹配，直接查詢控制器連接狀態(tài)表，如果存在，則下發(fā)Flow_mod消息，向交換機中變換流表添加記錄，動作為forward，并分配下一個狀態(tài)標志；交換機收到后，立即執(zhí)行SET_STATE操作，即更新連接狀態(tài)表（包括控制器中的連接狀態(tài)表（State Table-C，和交換機中的連接狀態(tài)表（State Table-SW），兩者通過State_mod實現(xiàn)同步），進行合法性檢測后，轉(zhuǎn)發(fā)該數(shù)據(jù)包。

（7）如果數(shù)據(jù)包可與交換機中狀態(tài)表（state Table-SW）和變換流表（Shifted Flow Table）都匹配，則數(shù)據(jù)包包頭信息不發(fā)給控制器，直接由交換機處理。

圖2 數(shù)據(jù)包處理流程圖

在建立TCP連接三次握手過程中，第一個SYN數(shù)據(jù)包會和控制器中的防火墻規(guī)則進行匹配，保證該連接不違反防火墻規(guī)則。如果違反防火墻規(guī)則，那么狀態(tài)表中不會有該連接的記錄；否則，可以根據(jù)狀態(tài)表和交換流表處理后面的數(shù)據(jù)包。這就保證了TCP通信不會違反防火墻規(guī)則。對于UDP數(shù)據(jù)包的處理過程與之類似，因為狀態(tài)表中會保留一個虛擬的UDP連接。由此流程可以得出，在通信過程中大部分數(shù)據(jù)可以繞過復雜的規(guī)則庫匹配過程，而有狀態(tài)檢查取而代之，這是一個簡潔高效的處理過程，從而提高了防火墻的性能。

這里，將每一次Client和Server之間連接的三次握手過程，作為一個“實體”的生成過程。這只是一個臨時過程，連接成功，則防火墻生成一個完整實體；連接失敗，則釋放本次連接占用的資源。對于這類實體的狀態(tài)（記錄連接的狀態(tài)，如：雙方連接序號、已確認數(shù)據(jù)、半連接狀態(tài)等信息），是隨著通信的進行而不斷更新的。實體狀態(tài)分為兩類——確認狀態(tài)和臨時狀態(tài)。收到數(shù)據(jù)時，實體先進入臨時狀態(tài)，收到接收端確認信息后再將臨時狀態(tài)修正為確認狀態(tài)，這樣可以避免實體狀態(tài)與通信雙方不同步的問題，其中系統(tǒng)狀態(tài)轉(zhuǎn)換如圖3所示。S0、S1和S2是臨時狀態(tài)分別代表三次握手中的發(fā)送SYN數(shù)據(jù)包、接收SYN+ACK數(shù)據(jù)包和發(fā)送ACK數(shù)據(jù)包三個狀態(tài)。S3是確認態(tài)，表示連接已經(jīng)建立成功。S4是終止狀態(tài)，防火墻釋放連接占用的資源。

圖3 系統(tǒng)TCP狀態(tài)轉(zhuǎn)換圖

4.2 具體問題分析

包過濾防火墻可以允許或阻止內(nèi)網(wǎng)和外網(wǎng)的通信。但是無法滿足這種要求：允許內(nèi)網(wǎng)向外網(wǎng)發(fā)送連接請求，外網(wǎng)無法向內(nèi)網(wǎng)發(fā)送連接請求。這樣可以更好地保護內(nèi)網(wǎng)，防止攻擊者嗅探、掃描等。這里用基于上述SDN狀態(tài)檢測防火墻，舉例如何解決這個問題（這里為了完全展示各個模塊的功能，在連接狀態(tài)表和變換流表中均不包含相關的記錄信息）。由內(nèi)網(wǎng)h1（192.168.0.1）可以主動與外網(wǎng)h2（202.114.1.1）建立連接，而外網(wǎng)的h2不能主動與內(nèi)網(wǎng)發(fā)起連接。首先，在防火墻中定義規(guī)則如表1所示。

表1 狀態(tài)防火墻規(guī)則定義

當h1發(fā)送連接請求時，SYN包到達交換機后，交換機中的關鍵信息提取模塊啟動提取其包頭信息，并和交換機中的連接狀態(tài)表進行匹配操作，顯然此時交換機中沒有相關記錄，那么在狀態(tài)表中添加相關記錄，如表2所示。

表2 State Table-SW記錄

同時，將狀態(tài)信息寫入SYN數(shù)據(jù)包的包頭，并與交換流表進行匹配。在變換流表中沒有找到相關記錄，則將關鍵信息發(fā)送到控制器，控制器判斷其為SYN請求包后，將其與防火墻規(guī)則進行匹配，并得到允許連接結(jié)果，則控制器便會向交換機發(fā)送Flow_mod消息，在變換流表中添加新記錄，如表3所示。

表3 Shifed Flow Table記錄

此后，交換機需要對數(shù)據(jù)包包頭進行合法性檢測，檢測通過后通過SET_STATE操作將狀態(tài)表（State Table-SW）相關記錄的STATE值被置為交換流表中Next_state的值，并將信息同步至控制器的狀態(tài)表（State Table-C）。

通過以上操作，外網(wǎng)主機h2成功接收到h1發(fā)送的連接請求，并返回一個SYN+ACK數(shù)據(jù)包。當該數(shù)據(jù)包到達交換機后，成功匹配到狀態(tài)表中相關記錄，將狀態(tài)值SEND_SYN寫入數(shù)據(jù)包包頭中后，與交換流表進行匹配操作，顯然匹配失?。ㄗ儞Q流表中，沒有STATE域為SEND_SYN項）。再次將數(shù)據(jù)包包頭信息發(fā)送至控制器，并與控制器的狀態(tài)表（State Table-C）成功匹配后，控制器便向交換機發(fā)送Flow_mod消息，從而在變換流表中添加新記錄，如表4所示，并將Next_State的值寫入交換機狀態(tài)表中，同步到控制器中。

表4 更新后變換流表

進行合法性檢測后，數(shù)據(jù)包被發(fā)到了內(nèi)網(wǎng)h1主機，內(nèi)網(wǎng)h1即回復一個ACK的數(shù)據(jù)包，與以上步驟相同，變換流表的更新，和狀態(tài)表更新如表5、表6所示。

表5 變換流表更新

表6 狀態(tài)表更新

同時，當控制器狀態(tài)表的STATE的值為ESTABLISHED時，則立即向交換機中變換流表中添加以下流表信息，如表7所示。

表7 連接建立后變換流表狀態(tài)

當連接建立后，內(nèi)網(wǎng)h1可以和h2進行正常通信而不會遭到阻斷。一旦交換機接收到相關連接中有RST或者FIN標志的信息，控制器會便刪掉狀態(tài)表（包括State Table-SW和State Table-C）中的連接記錄，同時刪除變換流表中的相關項。

反過來，當外網(wǎng)h2向內(nèi)網(wǎng)h1發(fā)送連接請求后，連接請求的SYN包包頭同樣會被送到控制器，根據(jù)防火墻規(guī)則，h2到h1的包不允許通過，因此，該SYN包會被Drop，連接無法建立。

管理員可以根據(jù)需要靈活制定防火墻策略。例如，允許外網(wǎng)的某一個主機對內(nèi)網(wǎng)的主機發(fā)起連接，禁止內(nèi)網(wǎng)主機對外網(wǎng)發(fā)起連接但仍可以對外網(wǎng)提供服務等。利用SDN狀態(tài)防火墻，管理員可以實現(xiàn)更加細粒度的訪問控制。在包過濾防火墻中要實現(xiàn)這樣的功能，管理員可能會配置以下防火墻規(guī)則，見表8。

表8 包過濾防火墻規(guī)則

表面上看，從h1發(fā)送的連接建立請求可以通過防火墻到達h2，從h2發(fā)送的連接建立請求卻不能到達h1。實際上當存在這樣的防火墻規(guī)則時，會發(fā)現(xiàn)主機h1和h2是無法完成TCP通信的。因為TCP通信是雙向的，防火墻規(guī)則拒絕了h2返回的SYN+ACK數(shù)據(jù)包，連接無法建立。如果將表8中的第二條防火墻規(guī)則改為ALLOW，h2就可以向h1發(fā)送建立連接的請求了，但是這顯然不符合要求。包過濾防火墻在處理這樣的問題是矛盾的，因為它將一次連接的多個數(shù)據(jù)包隔離開考慮，沒有考慮到數(shù)據(jù)包的狀態(tài)。這樣的訪問控制是簡單而粗糙的，管理員無法實現(xiàn)更加細粒度的訪問控制，例如本例。

狀態(tài)檢測防火墻可以在允許內(nèi)網(wǎng)主機和外網(wǎng)正常通信的情況下，阻止外網(wǎng)向內(nèi)網(wǎng)發(fā)送連接請求。因此，外網(wǎng)的SYN數(shù)據(jù)包都會被防火墻拒絕，可以非常容易地防御SYN洪泛攻擊。

5 系統(tǒng)測試與性能分析

5.1 訪問控制功能測試

本系統(tǒng)部署在Floodlight和Open vSwitch中，測試環(huán)境配置如表9所示。

本次測試使用如圖4所示的網(wǎng)絡拓撲結(jié)構，其中包括3臺交換機（S1、S2、S3）和4臺主機（VM1、VM2、VM3、VM4）。

表9 測試環(huán)境

圖4 網(wǎng)絡拓撲

設置VM1的IP地址為192.168.0.1，設定VM3的IP地址為202.114.1.1。在Floodlight防火墻模塊中添加如表10規(guī)則。

表10 防火墻規(guī)則

在防火墻規(guī)則的基礎上通過在交換機中添加連接狀態(tài)表、包含數(shù)據(jù)包狀態(tài)信息的變換流表以及在控制器中同步更新連接狀態(tài)表，實現(xiàn)細粒度的基于OpenFlow的SDN狀態(tài)防火墻。在建立連接時根據(jù)防火墻規(guī)則以及狀態(tài)表允許符合規(guī)則的連接通過，并按照不同狀態(tài)情況記錄在狀態(tài)表中，進一步在生成相應的變換流表項，一旦連接建立成功后，后續(xù)的數(shù)據(jù)包只要符合狀態(tài)表，就可以通過。

在測試中分別進行VM1向VM3發(fā)起TCP連接以及VM3向VM1發(fā)起TCP連接操作，實現(xiàn)了VM1可以訪問VM3的同時使得外網(wǎng)不受信任主機不能訪問主機VM1。從而為整個SDN網(wǎng)絡提供了更加細粒度的訪問控制，使得訪問授權與數(shù)據(jù)包狀態(tài)信息相關，也使得內(nèi)外網(wǎng)連接更加安全。

5.2 系統(tǒng)性能分析

5.2.1 數(shù)據(jù)包傳輸延時

基于Open vSwitch和虛擬VM構建了測試網(wǎng)絡拓撲，如圖4所示。在SDN架構下，基于包過濾和基于狀態(tài)檢測兩種防火墻傳輸延遲對比情況如圖5所示。

圖5 傳輸延時測試

可以得出隨著數(shù)據(jù)量的增加，狀態(tài)檢測防火墻的傳輸延遲逐漸低于包過濾防火墻。

測試結(jié)果顯示隨著數(shù)據(jù)量的增加，狀態(tài)檢測防火墻的傳輸延遲逐漸低于包過濾防火墻。在SDN架構下，基于狀態(tài)檢測的防火墻比基于包過濾的防火墻的傳輸延時要短，數(shù)據(jù)量越大，優(yōu)勢越明顯。起始時，由于交換機中的狀態(tài)流表尚未建立，數(shù)據(jù)包需要發(fā)送給控制器中的防火墻模塊進行比對，因此狀態(tài)防火墻性能和包過濾防火墻并無太大差別。但隨著數(shù)據(jù)量的增加，在交換機中建立狀態(tài)流表后，后續(xù)的流量檢測可以基于交換機中的流表規(guī)則進行，而無需再發(fā)送給控制器進行復雜的規(guī)則庫匹配。因此，數(shù)據(jù)量越大，本文中設計的狀態(tài)防火墻性能反而相比Floodlight中包含的包過濾防火墻性能更高些。因為Floodlight中包含的包過濾防火墻所有過濾規(guī)則都在控制端，未在交換機中建立過濾策略。

5.2.2 TCP建立連接速度

同時，在SDN架構下，進行了基于包過濾的和基于狀態(tài)檢測的防火墻建立連接的速度對比。分別以建立100～900次TCP連接所花費的總時間來對比兩個防火墻性能，具體測試情況如圖6所示。

圖6 TCP建立連接速度測試

由圖6可知，在建立連接時的速度上總體基于狀態(tài)檢測的防火墻要比基于包過濾的防火墻要慢一點，這是因為基于狀態(tài)的防火墻在連接建立初期需要進行狀態(tài)建立與同步等各種操作。當連接次數(shù)較少時，由于每次連接的時間是毫秒級，因此差別不明顯。連接次數(shù)越多，整體上狀態(tài)防火墻速度要慢些。在個別點測試的結(jié)果是相同的，這主要是由于網(wǎng)速不太穩(wěn)定，并且二者速度差別不顯著造成的。

在SDN架構下，通過對比兩種防火墻的數(shù)據(jù)包延遲和建立連接的速度可以得出，基于狀態(tài)檢測的防火墻系統(tǒng)延時更短，不過在建立連接時速度稍慢，但綜合而言，建立連接的時間在整個數(shù)據(jù)傳輸中所占比例較少。因此綜上所述，基于狀態(tài)的防火墻系統(tǒng)總體性能上要優(yōu)于比基于包過濾的防火墻系統(tǒng)。

6 結(jié)束語

針對目前SDN防火墻難以實現(xiàn)基于狀態(tài)的細粒度訪問控制問題，本文設計和實現(xiàn)了一種基于OpenFlow的SDN狀態(tài)檢測的防火墻系統(tǒng)，提出了對于OpenFlow流表和協(xié)議修改與設計方法，以及連接狀態(tài)表與變換流表的關鍵技術及實現(xiàn)流程。在Floodlight開源控制器和Open vSwitch開源交換機環(huán)境下實現(xiàn)了該系統(tǒng)。通過對OpenFlow流表結(jié)構與協(xié)議的修改以及在交換機中添加狀態(tài)檢測模塊，使得系統(tǒng)可檢測數(shù)據(jù)包的狀態(tài)，從而使網(wǎng)絡管理員可以通過定義規(guī)則實現(xiàn)基于狀態(tài)的細粒度的訪問控制功能。最后，對系統(tǒng)進行了功能和性能評估，結(jié)果表明系統(tǒng)可以實現(xiàn)現(xiàn)有SDN防火墻不具有的狀態(tài)檢測功能，并且具有較低的開銷。