基于OpenFlow的SDN狀態(tài)防火墻

王 鵑，劉世輝，文 茹，洪 智 ，王 江 ，樊成陽(yáng) ，張浩喆

1.軟件工程國(guó)家重點(diǎn)實(shí)驗(yàn)室，武漢 430072

2.空天信息安全與可信計(jì)算教育部重點(diǎn)實(shí)驗(yàn)室，武漢 430072

3.武漢大學(xué) 計(jì)算機(jī)學(xué)院，武漢 430072

4.清華大學(xué) 計(jì)算機(jī)科學(xué)與技術(shù)系，北京 100084

1 引言

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

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

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

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

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

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

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

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

2 相關(guān)工作及分析

目前，SDN防火墻方面的相關(guān)工作有：

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

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

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

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

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

3.1 系統(tǒng)框架

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

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

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

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

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

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

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

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

3.2 系統(tǒng)關(guān)鍵技術(shù)

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

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

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

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

3.2.2 變換流表管理

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

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

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

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

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

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

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

4.1 具體流程

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

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

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

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

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

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

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

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

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

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

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

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

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

4.2 具體問題分析

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

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

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

表2 State Table-SW記錄

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

表3 Shifed Flow Table記錄

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

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

表4 更新后變換流表

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

表5 變換流表更新

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

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

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

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

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

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

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

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

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

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

5.1 訪問控制功能測(cè)試

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

本次測(cè)試使用如圖4所示的網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)，其中包括3臺(tái)交換機(jī)（S1、S2、S3）和4臺(tái)主機(jī)（VM1、VM2、VM3、VM4）。

表9 測(cè)試環(huán)境

圖4 網(wǎng)絡(luò)拓?fù)?/p>

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

表10 防火墻規(guī)則

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

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

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

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

基于Open vSwitch和虛擬VM構(gòu)建了測(cè)試網(wǎng)絡(luò)拓?fù)洌鐖D4所示。在SDN架構(gòu)下，基于包過濾和基于狀態(tài)檢測(cè)兩種防火墻傳輸延遲對(duì)比情況如圖5所示。

圖5 傳輸延時(shí)測(cè)試

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

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

5.2.2 TCP建立連接速度

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

圖6 TCP建立連接速度測(cè)試

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

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

6 結(jié)束語(yǔ)

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