基于OpenFlow的SDN狀態防火墻

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

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

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

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

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

1 引言

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

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

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

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

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

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

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

（3）性能分析表明，相對于傳統的基于包過濾的防火墻，本文提出的基于狀態的防火墻綜合性能更優。

2 相關工作及分析

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

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

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

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

3 基于OpenFlow的SDN狀態檢測防火墻系統

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

3.1 系統框架

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

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

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

（3）Shifted Flow模塊：變換流表（Shifted Flow Table）建立和更新模塊，控制器下發指令在交換機中建立變換流表，負責狀態轉換過程以及數據包轉發操作。

圖1 系統框架圖

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

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

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

3.2 系統關鍵技術

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

3.2.1 連接狀態表的建立

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

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

3.2.2 變換流表管理

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

3.2.3 狀態更新管理

本系統的另一個關鍵技術是狀態的更新管理，即當一個數據包經過交換機時，交換機將會做哪些操作。

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

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

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

4 系統實現流程

4.1 具體流程

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

TCP數據包狀態檢測模塊的主要工作是創建一個TCP連接狀態表。具體流程如圖2所示：

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

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

（3）如果匹配成功，則將狀態信息寫入數據包包頭。

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

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

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

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

圖2 數據包處理流程圖

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

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

圖3 系統TCP狀態轉換圖

4.2 具體問題分析

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

表1 狀態防火墻規則定義

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

表2 State Table-SW記錄

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

表3 Shifed Flow Table記錄

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

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

表4 更新后變換流表

進行合法性檢測后，數據包被發到了內網h1主機，內網h1即回復一個ACK的數據包，與以上步驟相同，變換流表的更新，和狀態表更新如表5、表6所示。

表5 變換流表更新

表6 狀態表更新

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

表7 連接建立后變換流表狀態

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

反過來，當外網h2向內網h1發送連接請求后，連接請求的SYN包包頭同樣會被送到控制器，根據防火墻規則，h2到h1的包不允許通過，因此，該SYN包會被Drop，連接無法建立。

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

表8 包過濾防火墻規則

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

狀態檢測防火墻可以在允許內網主機和外網正常通信的情況下，阻止外網向內網發送連接請求。因此，外網的SYN數據包都會被防火墻拒絕，可以非常容易地防御SYN洪泛攻擊。

5 系統測試與性能分析

5.1 訪問控制功能測試

本系統部署在Floodlight和Open vSwitch中，測試環境配置如表9所示。

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

表9 測試環境

圖4 網絡拓撲

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

表10 防火墻規則

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

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

5.2 系統性能分析

5.2.1 數據包傳輸延時

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

圖5 傳輸延時測試

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

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

5.2.2 TCP建立連接速度

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

圖6 TCP建立連接速度測試

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

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

6 結束語

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