《SDN技術及應用》課件-第7章

第7章SDN應用編程案例7.1基于SDN的ARP代理服務器7.2基于SDN的防DDOS網(wǎng)絡攻擊7.3基于OpenDaylightRESTAPI的應用與開發(fā)7.4小結復習思考題

本章給出了三個SDN應用編程案例，分別是

（1）基于SDN的ARP代理服務器；

（2）基于SDN的防DDOS網(wǎng)絡攻擊；

（3）基于OpenDaylight的RESTAPI的應用與開發(fā)。

在SDN中，用戶可以通過下發(fā)流表的方式改變特定類型數(shù)據(jù)包的接收目標主機，然后通過接收目標主機上的接收程序捕獲相應的數(shù)據(jù)幀并進行分析，從而產(chǎn)生一種新的網(wǎng)絡應用。

例如，ARP代理服務器就是通過集中捕獲ARP請求數(shù)據(jù)幀，記錄不同IP地址對應的MAC地址，并構造ARP響應包發(fā)送給請求主機的方式實現(xiàn)ARP代理服務器的功能。類似地，基于SDN的防DDOS網(wǎng)絡攻擊也是將可能存在攻擊的數(shù)據(jù)包轉到“清洗服務器”上進行特征檢測，對可疑的數(shù)據(jù)包不進行轉發(fā)，正常的數(shù)據(jù)包則被轉發(fā)到目標服務器上?；贠penDaylight的RESTAPI的應用與開發(fā)則是采用Java語言編程的方式，通過調用OpenDaylight提供的RESTAPI實現(xiàn)流表的提取和下發(fā)操作，充分展示了SDN可編程的特點。

7.1基于SDN的ARP代理服務器

地址解析協(xié)議（AddressResolutionProtocol,ARP）是根據(jù)IP地址獲取MAC地址（物理地址）的一個數(shù)據(jù)鏈路層協(xié)議。PC主機發(fā)送信息時，將包含目標IP地址的ARP請求廣播到網(wǎng)絡上的所有主機，并接收返回消息，從而獲得目標主機的MAC地址。收到返回消息后，將該IP地址和MAC地址存入本機ARP緩存中并保留一定時間，下次請求時直接查詢ARP緩存以節(jié)約資源。

地址解析協(xié)議是建立在網(wǎng)絡中各個主機互相信任的基礎上的，網(wǎng)絡中的主機可以自主發(fā)送ARP應答消息，其他主機收到應答報文時不會檢測該報文的真實性就會將其記入本機ARP緩存。

ARP協(xié)議的處理機制存在兩個問題：其一是可能造成網(wǎng)絡的不安全。例如，攻擊者可以向某一主機發(fā)送偽ARP應答報文，使其發(fā)送的信息到達錯誤的主機，或無法到達預期的主機，或者直接刪除，從而構成了一個ARP欺騙。其二是ARP請求包以廣播的方式發(fā)送給網(wǎng)絡上所有的主機，這無疑會占用一定的網(wǎng)絡資源。

因此，在一些關鍵的網(wǎng)絡中，可能采取ARP代理服務器而非ARP廣播方式。例如，在電力系統(tǒng)的網(wǎng)絡中，通常禁止使用ARP廣播。所謂ARP代理服務器，就是由中間設備代替其他主機響應ARP請求，實際上就是一臺專門用于接收所有ARP請求、并根據(jù)本地存儲的MAC地址和IP地址的對應關〖HJ*5/9〗系數(shù)據(jù)庫生成ARP響應數(shù)據(jù)包的軟件。這樣既可以避免ARP造成的網(wǎng)絡不安全的問題，又能節(jié)省網(wǎng)絡帶寬資源。

此外，在一些大型的服務器上每天都會收到成千上萬臺終端的ARP請求，每當服務器接收到相應的ARP請求時，必然要對其進行應答，這無疑會占用服務器的一定資源。同時，ARP請求會產(chǎn)生一定的網(wǎng)絡廣播，占據(jù)一部分的網(wǎng)絡帶寬，在有環(huán)的網(wǎng)絡中還會產(chǎn)生網(wǎng)絡廣播風暴，有網(wǎng)絡癱瘓的風險。因此，將ARP的應答功能從服務器中剝離出來是十分必要的。

在傳統(tǒng)網(wǎng)絡中，ARP代理服務器通常設置在路由器上。例如，主機PC1（00）和主機PC2（00）雖然屬于不同的廣播域，但它們處于同一網(wǎng)段中，所以當PC1向PC2發(fā)出ARP請求廣播包，請求獲得PC2的MAC地址時，由于路由器不會轉發(fā)廣播包，因此ARP請求只能到達路由器，不能到達PC2。而當在路由器上啟用ARP代理后，路由器會查看ARP請求，發(fā)現(xiàn)IP地址00屬于它連接的另一個網(wǎng)絡，因此路由器就會用自己的接口MAC地址代替PC2的MAC地址，向PC1發(fā)送了一個ARP應答。

PC1收到ARP應答后，會認為路由器的MAC地址就是PC2的MAC地址，不會感知到ARP代理的存在。這種路由器上的ARP實際上并不是專為解決ARP所帶來兩個問題，而是專注于網(wǎng)絡的透明傳輸。ARP代理服務器的設計思路是設置一臺專門的主機用于接收所有的ARP請求，這就要求交換機可以識別ARP請求數(shù)據(jù)包，并將該數(shù)據(jù)包以單播的方式發(fā)送給ARP代理服務器，代理服務器解析接收到的數(shù)據(jù)包，根據(jù)所請求的IP地址查找本地數(shù)據(jù)庫，找到對應MAC地址，再封裝成ARP響應包發(fā)送給請求者。

傳統(tǒng)的交換機由于無法直接進行編程，所以除非廠商自己，其他用戶很難在普通的交換機上實現(xiàn)上述識別ARP請求并進行轉發(fā)到特定主機的功能。但在SDN交換機上由于流表可以由用戶自己設定，因而利用SDN技術可以輕松實現(xiàn)識別ARP請求并進行轉發(fā)到特定主機的功能。

7.1.1基于SDN的ARP代理服務器實現(xiàn)原理

本節(jié)中ARP代理服務器是利用SDN技術實現(xiàn)的，遠端PC的ARP請求包通過SDN交換機時，SDN交換機應用流表將該數(shù)據(jù)包轉發(fā)到ARP代理服務器，ARP代理服務器捕獲該數(shù)據(jù)包并進行ARP代答，具體實現(xiàn)流程如圖7-1所示。終端主機數(shù)據(jù)包通過入端口進入SDN交換機，在SDN交換機上配置相應的流表，該流表設置為：判斷進入的數(shù)據(jù)包是否為ARP請求包，動作設置為出端口到代理服務器所連接的物理端口上。

代理服務器收到該數(shù)據(jù)包，分析幀結構的目的IP地址，并從本地數(shù)據(jù)庫中得到該IP地址對應的MAC地址，將該IP地址和MAC地址作為源IP地址和源MAC地址，將ARP請求中的源IP地址和源MAC作為目的IP地址和目的MAC地址封裝成ARP響應數(shù)據(jù)幀，以單播方式發(fā)送到網(wǎng)絡上，從而完成ARP代理功能。另外，為了保證本地保存的IP地址和MAC地址對應關系的正確性，每收到一個ARP請求，均要將源IP地址和源MAC地址與本地保存的數(shù)據(jù)進行比對，如果不一致將更新本地數(shù)據(jù)庫，如果不存在則在本地數(shù)據(jù)庫中記錄該IP地址和MAC地址的對應關系。本節(jié)中的ARP代理服務器程序采用C語言編寫，應用原始套接字編程技術實現(xiàn)，在7.1.3節(jié)中將對ARP代理服務器的源碼進行詳細分析。

SDN交換機上的流表可以通過SDN控制器OpenDaylight（ODL）設置，或者直接通過OpenvSwitch交換機上的流表設置命令完成，也可以通過調用ODL提供的RESTAPI接口直接在ARP代理服務器程序中設置。

圖7-1ARP代理服務器實現(xiàn)流程圖

7.1.2基于SDN的ARP代理服務器網(wǎng)絡設置

實驗中用到的主要設備有：安裝有OpenDaylightBeryllium版本的控制器一臺、OpenvSwitch2.5.0版本的交換機一臺、終端PC機三臺。終端PC機的配置信息如表7－1所示，網(wǎng)絡拓撲圖如圖7-2所示。

圖7-2ARP代理服務器網(wǎng)絡拓撲圖

本節(jié)中通過主機PC1pingPC2來驗證和測試ARP代理服務器軟件的正確性。如果ARP代理服務器未啟動，則PC1不能ping通PC2，反之則能ping通。這個結果說明ARP代理服務器確實起到了代理ARP響應的作用。實驗的主要步驟如下：

（1）在ODL控制器端啟動OpenDaylight控制器。

（2）在PC2上查詢ARP緩沖表，并刪除PC2的MAC地址以確保使用ping命令時能夠首先發(fā)出的是ARP請求包。查看本機ARP緩沖表的命令為arp，刪除命令為arp－d主機名，如圖7-3所示。

圖7-3查看ARP緩沖表以及刪除MAC地址

（3）在SDN交換機端上使用ovs-ofctladd-flow命令添加如下流表：

Ovs-ofctladd-flowbr0priority=152,arp,arp_op=1,actions=output:4

其中各參數(shù)含義如下：

①br0：表示本例SDN交換機中設置的網(wǎng)橋。

②priority=152：表示流表的優(yōu)先級，一般設置的值大于100。根據(jù)OpenFlow1.3協(xié)議規(guī)定，在同一標號的流表中，優(yōu)先級越高的流表項被越先選中進行條件匹配。

③arp,arp_op=1：表示匹配的數(shù)據(jù)包為ARP請求包，arp_op=1表示的是ARP類型，即請求包。

④actions=output:4：表示流表動作是將匹配到的數(shù)據(jù)包發(fā)到SDN交換機的物理端口4，也就是轉發(fā)給ARP代理服務器所在的終端PC3。

（4）查看流表，驗證流表是否設置成功（見圖7-4）。

圖7-4查看SDN交換機的所有流表

（5）在PC1上執(zhí)行pingPC2的命令。由于PC1現(xiàn)在不知道PC2的MAC地址，所以此次ping命令將首先發(fā)送的是ARP請求包，但是由于流表項的作用，使得發(fā)送的ARP包轉給了PC3，所以發(fā)現(xiàn)ping不通，但是匹配的流表項有數(shù)據(jù)包增加，證明流表生效，如圖7-5和7-6所示。

圖7-5在未啟動ARP代理服務器的情況下PC1pingPC2圖7-6SDN交換機上流表項統(tǒng)計數(shù)據(jù)包數(shù)量增加

（6）在PC3上啟動ARP代理服務器程序，該服務器代理程序為arp_proxy。在啟動代理服務器程序之前需要將本地網(wǎng)卡設置為混雜模式，該命令如下：

$#sudo

ifconfigeth0promisc

運行代理程序的命令為

$#./arp_proxy

（7）在PC1上再次pingPC2，這時發(fā)現(xiàn)PC1可以ping通PC2，說明ARP代理服務器已經(jīng)發(fā)出了ARP響應。查看PC1的本地ARP緩沖表，可以看到PC2的MAC地址，同時，在PC3上也能看到。這說明PC3上的ARP代理服務器已經(jīng)收到PC1發(fā)送的ARP請求包，并成功發(fā)送ARP響應（如圖7-7、圖7-8、圖7-9所示）。

圖7-7在啟動ARP代理服務器的情況下PC1pingPC2圖7-8在啟動ARP代理服務器的情況下查看PC1的ARP緩沖表圖7-9在PC3上ARP代理服務器的運行情況

7.1.3ARP代理服務器的源碼分析

ARP代理服務器程序需要接收數(shù)據(jù)鏈路層的幀，這里采用原始套接字技術來實現(xiàn)收、發(fā)底層數(shù)據(jù)幀的功能。獲取數(shù)據(jù)鏈路層幀的另一種方法是采用PCAP開發(fā)包，該開發(fā)庫給抓包程序提供了一個高層次的接口，網(wǎng)絡上的所有數(shù)據(jù)包，甚至是那些發(fā)送給其他主機的數(shù)據(jù)包，通過這種機制都可以捕獲。本例中的ARP代理服務器采用C語言編程，邏輯結構簡單。為了簡化對ARP代理服務器的編程，這里忽略了對本地數(shù)據(jù)存儲的訪問與更新，僅專注于ARP請求包的接收和分析，以及ARP應答包的封裝和發(fā)送。

除main函數(shù)外，程序由三個函數(shù)組成。其中，arp_request_recv函數(shù)完成ARP請求包的接收和分析；arp_response_send函數(shù)完成ARP應答包的封裝和發(fā)送；print_arp_request函數(shù)主要負責打印接收到的ARP請求包。

ARP協(xié)議的幀格式如圖7-10所示，分為以太網(wǎng)首部和ARP協(xié)議字段兩部分，其中，以太網(wǎng)首部共12字節(jié)長（目的MAC和源MAC各占6字節(jié)）。ARP協(xié)議字段部分又分為ARP首部和ARP數(shù)據(jù)部分。ARP首部包括幀類型（2字節(jié)）、硬件類型（2字節(jié)）、協(xié)議類型（2字節(jié)）、硬件地址長度（1字節(jié)）、協(xié)議地址長度（1字節(jié)）和操作類型（2字節(jié)）。ARP數(shù)據(jù)部分包括發(fā)送者MAC地址（6字節(jié)）、發(fā)送者IP地址（4字節(jié)）、目的MAC地址（6字節(jié)）和目的IP地址（4字節(jié)）。

圖7-10ARP協(xié)議幀格式

以太網(wǎng)首部定義如下（C語言）：

typedefstructehhdr

{

unsignedchareh_dst[6];/*destinationethernetaddrress*/

unsignedchareh_src[6];/*sourceethernetaddresss*/

unsignedshorteh_type;/*ethernetpachettype*/

}EHHDR,*PEHHDR;

以太網(wǎng)arp字段定義如下：

typedefstructarphdr

{

unsignedshortarp_hrd;/*formatofhardwareaddress*/

unsignedshortarp_pro;/*formatofprotocoladdress*/

unsignedchararp_hln;/*lengthofhardwareaddress*/

unsignedchararp_pln;/*lengthofprotocoladdress*/

unsignedshortarp_op;/*ARP/RARPoperation*/

unsignedchararp_sha［6］;/*senderhardwareaddress*/

unsignedlongarp_spa;/*senderprotocoladdress*/

unsignedchararp_tha［6］;/*targethardwareaddress*/

unsignedlongarp_tpa;/*targetprotocoladdress*/

}ARPHDR,*PARPHDR;

定義整個arp報文包，總長度為42字節(jié)：

typedefstructarpPacket

{

EHHDRehhdr;

ARPHDRarphdr;

}ARPPACKET,*PARPPACKET;

程序中需要包含下列頭文件以及宏定義如下：

#include<stdio.h>

#include<string.h>

#include<unistd.h>

#include<stdlib.h>

#include<sys/ioctl.h>

#include<sys/socket.h>

#include<arpa/inet.h>

#include<netinet/in.h>

#include<netinet/if_ether.h>

#include<net/ethernet.h>

#include<net/if_arp.h>

#include<net/if.h>

#include<netpacket/packet.h>

#defineETHER_HEADER_LENsizeof(structether_header)/*以太網(wǎng)幀首部長度*/

#defineETHER_ARP_LENsizeof(structether_arp)/*整個arp結構長度*/

#defineETHER_ARP_PACKET_LENETHER_HEADER_LEN+ETHER_ARP_LEN

#defineIP_ADDR_LEN4/*IP地址長度*/

chararp_mac1［6］={0x00,0x1c,0x25,0xc1,0xe1,0x0f};∥01mac

chararp_mac2［6］={0x74,0x27,0xea,0x23,0xbd,0x52};∥02mac

函數(shù)arp_request_recv代碼如下：

voidarp_request_recv(ints)

{

structether_arp*arp_request;

intretlen;

charbuf[ETHER_ARP_PACKET_LEN]={0};

該函數(shù)一直不斷地接收數(shù)據(jù)幀，一旦接收到相關的數(shù)據(jù)幀，則判斷是否為ARP請求ARPOP_REQUEST。如果是，則打印接收到的ARP請求數(shù)據(jù)幀的源IP地址、源MAC地址以及目的IP地址，接下來調用arp_response_send函數(shù)發(fā)送ARP應答包。

7.2基于SDN的防DDOS網(wǎng)絡攻擊

在當前的網(wǎng)絡環(huán)境中DDOS攻擊已經(jīng)非常普遍，而且攻擊的流量在幾秒鐘之內可以達到幾個Gb/s或者更大。在傳統(tǒng)網(wǎng)絡中要防御這些攻擊比較困難，而SDN可以為最復雜的環(huán)境提供更高級的網(wǎng)絡監(jiān)控功能，控制器和交換機能夠分辨各種數(shù)據(jù)包的屬性，從而能夠對進入應用服務器的流量進行必要的“清洗”，實現(xiàn)對惡意訪問數(shù)據(jù)的攔截。

7.2.1DDOS防御實現(xiàn)原理

近年來，分布式拒絕服務（DistributedDenialOfService，DDOS）攻擊不斷在因特網(wǎng)上出現(xiàn)，并在應用過程中漸漸得到完善，在Unix或WindowsNT操作系統(tǒng)上已有一系列比較成熟的軟件產(chǎn)品，如Trinoo、TFN、TFN2K、STACHELDRATH等，其核心內容及攻擊思路都是類似的。要了解DDOS的原理，首先要知道拒絕服務攻擊（DOS）的含義，DOS是指攻擊者利用大量的數(shù)據(jù)“淹沒”目標主機，耗盡目標主機的可用資源直至主機系統(tǒng)崩潰，最終導致目標主機無法為正常用戶提供服務（例如Web頁面服務）。

早期的拒絕服務攻擊主要是針對處理能力比較弱的單機，如個人PC，或是窄帶寬連接的網(wǎng)站，對擁有高帶寬連接、高性能設備的服務器則影響不大，這主要是因為早期的DOS攻擊者往往是單兵作戰(zhàn)，很難在短時間內單獨制造出大量的攻擊數(shù)據(jù)。但在1999年底，伴隨著DDOS的出現(xiàn)，這種高性能服務器高枕無憂的局面就再也不存在了。DDOS攻擊是指攻擊者借助于客戶/服務器技術，將多個計算機聯(lián)合起來作為攻擊平臺，對一個或多個目標發(fā)動攻擊，從而成倍地提高拒絕服務攻擊的數(shù)量。在這種借助于數(shù)百、甚至數(shù)千臺被植入攻擊守護進程的攻擊主機同時發(fā)起的集團作戰(zhàn)行為中，網(wǎng)絡服務提供商所面對的破壞力是空前巨大的。

圖7-11是典型的DDOS網(wǎng)絡攻擊示意圖，攻擊者利用一些軟件植入手段將攻擊程序植入到連接在互聯(lián)網(wǎng)上的主機上，被植入攻擊程序的電腦通常被稱為“肉雞”，即被木馬軟件控制的傀儡計算機，然后攻擊者利用這些“肉雞”發(fā)送大量的攻擊報文給服務器，從而造成服務器服務質量下降或系統(tǒng)嚴重癱瘓。

圖7-11DDOS網(wǎng)絡攻擊示意圖

DDOS攻擊的形式很多，主要的或使用頻繁的攻擊方式有：TCPSYNFlood攻擊、TCPACKFlood攻擊、UDPFlood攻擊、ICMPFlood攻擊、ConnectionFlood攻擊、HTTPGet攻擊、UDPDNSQueryFlood攻擊等。其中，TCPSYNFlood攻擊是當前網(wǎng)絡上最為常見的DDOS攻擊，也是最為經(jīng)典的拒絕服務攻擊。由于TCPSYNFlood攻擊的普遍性，因此，本節(jié)主要研究基于SDN對SYNTCPFlood攻擊的防護。

正常的TCP連接需要用到如圖7-12所示的三次握手，當客戶端發(fā)送一個帶SYN標志的TCP報文到服務器（第一次握手）時，服務器進程應回應客戶端ACK報文（第二次握手），這個報文同時帶有ACK標志和SYN標志，表示對剛才客戶端SYN報文的回應，同時也表示服務器發(fā)送SYN報文給客戶端，詢問客戶端是否準備好進行TCP通信。最后客戶端再次發(fā)送一個ACK報文給服務器（第三次握手），這時表明TCP連接成功。

圖7-12TCP建立連接的三次握手

如圖7-13所示，TCPSYNFlood攻擊利用了上述TCP連接協(xié)議實現(xiàn)上的一個缺陷。攻擊者通過向網(wǎng)絡服務器發(fā)送大量的偽造源IP地址的SYN報文，服務器進程在發(fā)出SYN+ACK應答報文后，由于第一次握手中服務器收到的SYN報文源地址是偽造的，因此服務器不可能再接收到客戶端的ACK報文，即第三次握手無法完成。在此情況下，服務器進程一般會重發(fā)SYN+ACK給客戶端，并等待一段時間后再丟棄這個未完成的連接，這就可能造成目標服務器中的半開連接隊列被占滿。

通常一臺服務器可用的TCP連接數(shù)是有限的，如果惡意攻擊者快速連續(xù)地發(fā)送此類連接請求，則服務器可用的TCP連接隊列可能很快就會阻塞，因而導致系統(tǒng)可用資源以及網(wǎng)絡可用帶寬急劇下降，結果無法向普通用戶提供正常的網(wǎng)絡服務。TCPSYNFlood攻擊最早出現(xiàn)在1996年，至今仍然出現(xiàn)在現(xiàn)實網(wǎng)絡環(huán)境中，很多操作系統(tǒng)和防火墻、路由器都無法有效地防御這種攻擊，并且由于SYN報文的源IP地址是偽造的，事后追查起來也相當困難。

圖7-13TCPSYNFlood攻擊示意圖

傳統(tǒng)的TCPSYNFlood防御技術通常有兩種，第一種是盡量縮短SYN超時等待時間。由于TCPSYNFlood攻擊的效果取決于服務器上保持的SYN半連接數(shù)，即這些無效連接占用服務器資源的多少和時長，這些半連接數(shù)應等于SYN攻擊的頻度乘以SYN的超時等待時間，所以通過縮短從接收到SYN報文到確定這個報文無效并丟棄該連接的時間，可以成倍地降低服務器的負荷。但過低的SYN超時等待時間的設置可能會影響客戶的正常訪問，即普通用戶由于無法連接TCP服務器而不能與服務器進行通信。第二種方法是設置SYNCookie，就是給每一個請求連接的IP地址分配一個Cookie，如果短時間內連續(xù)接收到某個IP的重復SYN報文，就認為是受到了攻擊，那么以后從這個IP地址來的報文一概丟棄。

本節(jié)中TCPSYNFlood的防御思路基本上與上述第二種方式相似，主要利用SDN流表配置實現(xiàn)對所有來訪數(shù)據(jù)報文進行“清洗”，其原理是將發(fā)往目標服務器的TCPSYN數(shù)據(jù)包通過SDN交換機轉發(fā)到另一臺代理服務器（簡稱“清洗服務器”）上，然后由該服務器對SDN交換機轉發(fā)來的數(shù)據(jù)包進行清洗，如果發(fā)現(xiàn)可能是TCPSYNFlood數(shù)據(jù)攻擊報文，則丟棄該報文，否則將清洗后的正常數(shù)據(jù)包發(fā)往目標服務器，從而實現(xiàn)對SYNFlood攻擊的防御功能。

本節(jié)中的DDOS防御服務器模塊沒有直接在控制器上開發(fā)（內嵌在控制器中），而是使用獨立的服務器來完成入侵檢測功能，這樣做的好處是可以避免對開源控制器源代碼結構的理解，缺點是不能很方便地利用控制器所提供的網(wǎng)絡基本服務功能。例如，不能直接利用控制器接收的pack_in報文進行報文檢測，需要自己編寫接收數(shù)據(jù)幀的程序。與直接在控制器上開發(fā)的DDOS防御模塊相比，本方案的優(yōu)點是可以減輕控制器的負擔，和控制器之間的交集比較少，理解起來相對容易。此外，也可以通過RESTAPI調用SDN控制器提供的底層網(wǎng)絡服務功能，充分利用SDN可編程的特點。

基于SDN的TCPSYNFlood防御實現(xiàn)流程如圖7-14所示，數(shù)據(jù)包進入SDN交換機匹配對應的流表，如果是TCPSYN報文，則將該報文的目的MAC地址和IP地址修改為“清洗”服務器的MAC地址和IP地址，“清洗”服務器收到該報文后將記錄該報文的源IP地址和接收時間。由于網(wǎng)絡中存在很多主機，為此需要建立一張關于網(wǎng)絡中所有主機的記錄表，該表中的記錄是有時間限制的，在記錄被加入該表一定時間后將被刪除。這張記錄表定義了單位時間內對應主機的違規(guī)次數(shù)（閾值），也就是主機的“誠信度”。

比如，主機A在100毫秒內發(fā)送了6次（閾值）TCPSYN數(shù)據(jù)包，則可以認為是一次“違規(guī)”記錄。閾值、時間片長度等參數(shù)是可以動態(tài)調整和設置的。“誠信度”表的建立、管理以及相關參數(shù)的確立是一個復雜的過程，為了降低DDOS防御代碼實現(xiàn)的難度和便于理解，我們只是簡單地記錄主機發(fā)送連續(xù)TCPSYN報文的數(shù)量。一旦某個主機連續(xù)發(fā)送的TCPSYN數(shù)據(jù)報文達到某個閾值，則認為該主機可能發(fā)起TCPSYNFlood攻擊，該主機的TCPSYN數(shù)據(jù)包將被丟棄而不會被發(fā)往目標服務器；否則就認為是正常的TCPSYN報文，該報文被轉發(fā)給目標服務器。

圖7-14SYNFlood防御功能實現(xiàn)流程

7.2.2基于SDN的DDOS防御網(wǎng)絡配置

本節(jié)中網(wǎng)絡拓撲結構如圖7-15所示，主要設備有SDN控制器、安裝有OpenvSwitch2.5.0版本的SDN交換機一臺，PC2為攻擊計算機，用于發(fā)送TCPSYN數(shù)據(jù)包（使用hping3工具進行模擬發(fā)送SYN數(shù)據(jù)包），PC2的IP地址為02。PC1為被攻擊的目標服務器，IP地址為01。PC3為“清洗”服務器，用于檢測和過濾TCPSYNFlood攻擊的數(shù)據(jù)包，IP地址為03。

圖7-5基于SDN的DDOS防御網(wǎng)路拓撲圖

下面將展示通過OpenDaylight控制器的Web界面部署流表的過程，網(wǎng)絡配置或實戰(zhàn)過程如下：

（1）直接在交換機上添加流表，實現(xiàn)對PC2的TCPSYN數(shù)據(jù)包的轉發(fā)，如圖7－16所示。第一條流表的作用是將過濾好的數(shù)據(jù)包轉發(fā)給服務器PC1,第二條流表的作用是將PC2的數(shù)據(jù)包轉發(fā)給DDOS的清洗服務器PC3。TCP的flag標志位數(shù)值設置如下所示：

0:fin1:syn2:rst3:psh4:ack

5:urg6:ece7:cwr8:ns

圖7-16在交換機上增加流表

設置流表匹配類型為tcp_flags=0x2，即為TCPSYN數(shù)據(jù)包。圖7-17所示為交換機成功設置后顯示的流表信息。

圖7-17交換機上顯示已配置成功的流表

（2）在PC3上編譯并運行DDOS清洗服務器軟件。運行該軟件之前應確保網(wǎng)卡已被設置為混雜模式，具體代碼見7.2.3節(jié)。

（3）在PC2中使用hping3工具進行SYNFlood攻擊PC1（01），如圖7-18所示。

圖7-18模擬SYNFlood攻擊

命令中的具體參數(shù)解釋如下：

①-c10000：發(fā)送數(shù)據(jù)包的數(shù)量為10000個；

②-d120：發(fā)送到目標機器每個數(shù)據(jù)包的大小為120B；

③-S：只發(fā)送SYN數(shù)據(jù)包；

④-w64：TCP窗口大小為64；

⑤-p8080：攻擊的目的端口為8080；

⑥--faster：每秒發(fā)送100個數(shù)據(jù)包；

⑦01：為PC1的IP地址，即被攻擊目標服務器的IP地址。

7.2.3基于SDN的DDOS防御源碼分析

本節(jié)中的源碼是在7.1.3中源碼的基礎上改進的，函數(shù)ip_frame_recv代替了函數(shù)arp_request_recv，該函數(shù)一直不斷地接收源主機數(shù)據(jù)幀并打印接收到的數(shù)據(jù)幀的源IP地址、源MAC地址以及目的IP地址。注意，該程序只能接收到源主機發(fā)送的TCPSYN。接下來調用ip_ddos_proc函數(shù)處理接收到的TCPSYN數(shù)據(jù)報文，如果在短時間內（200毫秒）接收到的TCPSYN的數(shù)量大于6則函數(shù)返回，即該數(shù)據(jù)包不會被轉發(fā)給目標服務器，否則將該IP包轉發(fā)到目的服務器的端口eth0上。

函數(shù)ip_frame_recv代碼如下：

函數(shù)ip_ddos_proc代碼如下。其中，syncnt用于記錄源主機連續(xù)接收的TCPSYN報文的數(shù)量。當syncnt等于0時，獲得計時器開始時間，每接收到一個TCPSYN報文則syncnt加1，當計時時間超過200毫秒時，將syncnt置0。

7.2.4基于SDN的DDOS防御實驗數(shù)據(jù)分析

在PC3上用Wireshark工具捕獲的SYN數(shù)據(jù)包如圖7-19所示。可以看出，SYN=1,ACK=0，說明該數(shù)據(jù)包為SYN請求包。

圖7-19

TCPSYN數(shù)據(jù)包內容

從PC3的程序運行結果（如圖7-20所示）可以看出，運行結果沒有“sendto()OK!!!”，表明數(shù)據(jù)包沒有被轉發(fā)。

圖7-20防DDOS攻擊程序運行結果

流表攻擊前后的變化如圖7-21所示。由下發(fā)的兩條流表的數(shù)據(jù)包前后變化可以看出，PC1發(fā)出的SYNflood攻擊數(shù)據(jù)包進入到PC3上，PC3通過程序對數(shù)據(jù)包進行過濾，將非SYNFlood攻擊的數(shù)據(jù)包發(fā)送給交換機。

圖7-21流表變化

本實驗主要實現(xiàn)對SYNFlood攻擊的防護。首先由PC2模擬發(fā)送SYNFlood攻擊，攻擊對象為PC1服務器。當PC2發(fā)送數(shù)據(jù)包到OpenvSwitch交換機上時，交換機下發(fā)流表將數(shù)據(jù)包轉給PC3代理服務器，在PC3上運行C語言編寫的數(shù)據(jù)包過濾程序，將非SYNFlood攻擊的數(shù)據(jù)包發(fā)送給交換機，按照數(shù)據(jù)包的首部進行正常的數(shù)據(jù)轉發(fā)，從而有效地實現(xiàn)對SYNFlood攻擊的防護。

7.3基于OpenDaylightRESTAPI的應用與開發(fā)

本節(jié)主要是通過OpenDaylightRESTAPI在Java應用程序中進行流表操作，通過本節(jié)的實際應用將進一步體會SDN可編程的特點。

7.3.1OpenDaylightRESTAPI簡介

從根本上說，REST是一種軟件架構風格，REST可以有效地降低網(wǎng)絡應用開發(fā)的復雜性，同時提高系統(tǒng)的可伸縮性。OpenDaylightRESTAPI是使用OpenDaylight進行上層應用開發(fā)的一種極為簡單的開發(fā)方式，開發(fā)者可以直接對OpenDaylightRESTAPI進行遠程調用，而忽略OpenDaylight實現(xiàn)的底層細節(jié)，通過調用APl進行功能的創(chuàng)新與開發(fā)，使得OpenDaylight的開發(fā)更為簡單和快速。

OpenDaylightRESTCONF是最具代表性的一種OpenDaylightRESTAPI。RESTCONF是基于HTTP（HyperTextTransferProtocol）協(xié)議的，OpenDaylightRESTCONF提供RESTAPI可以操作基于Yang模型的數(shù)據(jù)和調用基于Yang模型的RPC（RemoteProcedureCallProtocol），一般將XML或者JSON作為HTTP的傳送載體。

JSON（JavaScriptObjectNotation）類似于XML，用于數(shù)據(jù)交換和傳輸，是一種輕量級的數(shù)據(jù)交換格式。JSON代碼簡潔明了，可讀性高，易于閱讀和編寫，同時也易于機器解析和生成。JSON的結構非常簡單，它只有對象和數(shù)組兩種結構，通過這兩種結構可以表示各種復雜的結構。

JSON中的對象表示為“{}”括起來的內容，通用的數(shù)據(jù)結構為{KEY1：VALUE1，KEY2：VALUE2，...}，采用鍵值對的形式。在面向對象的語言中，KEY為對象的屬性，VALUE為對應的屬性值。JSON中的數(shù)組表示為“［］”括起來的內容，例如，數(shù)據(jù)結構可以是［"flow"，"table"，"group"，...］，取值方式和所有語言一樣，使用索引獲取，字段值的類型可以是數(shù)字、字符串、數(shù)組、對象等。

常用的幾種HTTP請求是GET、POST、PUT和DELETE，其中，GET是向特定的資源發(fā)出請求，它是默認的HTTP請求方法。在日常使用中，通常使用GET來對指定資源請求數(shù)據(jù)，獲取相關的信息，在SDN中可以用于獲取統(tǒng)計信息或者具體的流表信息。POST也是HTTP請求中常用的一種，它是用來提交數(shù)據(jù)的，一般來說，使用POST提交的數(shù)據(jù)的位置在HTTP請求的正文里，其目的在于提交數(shù)據(jù)并用于服務器端的存儲，而不允許用戶過多地更改相應數(shù)據(jù)。PUT和POST的作用類似，PUT是對已有的數(shù)據(jù)進行修改，向指定的URI傳送更新資源，而POST是提交不存在的數(shù)據(jù)。顧名思義，DELETE就是通過HTTP請求刪除指定的URL上的資源，在SDN中可以進行刪除指定的流表等操作。

7.3.2使用Postman調用RESTCONF接口進行流表操作

Postman是Chrome瀏覽器中一個非常有名的插件，Postman一般用于調試網(wǎng)頁程序，它可以發(fā)送幾乎所有類型的HTTP請求，如POST、GET、DELECT、PUT等。開發(fā)人員調試一個網(wǎng)頁是否正常運行，并不是簡簡單單地調試網(wǎng)頁的HTML、CSS、腳本等信息是否正常運行，而是調試用戶的大部分數(shù)據(jù)能否通過HTTP請求來與服務器進行交互。Postman插件就充當著這種交互方式的“橋梁”，它可以利用Chrome插件的形式把各種模擬用戶HTTP請求的數(shù)據(jù)發(fā)送到服務器，以便開發(fā)人員能夠及時地作出正確的響應。

采用編程語言（例如Java）調用RESTAPI最難判斷的是發(fā)送給控制器的數(shù)據(jù)及格式（JSON格式）書寫是否正確，通?？梢韵扔媚承┕ぞ邔⑦@些數(shù)據(jù)調試正確，然后再拷貝到程序中使用，這樣可以更高效地開發(fā)網(wǎng)絡應用程序。為此我們先觀察一下如何在Postman中下發(fā)JSON格式的流表數(shù)據(jù)，這種流表操作的方式實際上是對OpenDaylightRESTAPI的應用，與其他方式的流表管理相比較，Postman管理流表具有簡單、方便等特點。

接下來在控制器端使用Chrome瀏覽器的Postman插件進行相關配置（URL填寫、流表的JSON格式書寫、RESTCONF接口認證等），進行獲取并查看流表、刪除流表、下發(fā)流表等操作，具體操作過程如下。由于Postman插件支持多種格式，如JSON、XML、HTML等，下面以JSON為例進行流表操作。

1.準備工作

（1）在Chrome瀏覽器安裝Postman插件。

（2）啟動控制器上的OpenDaylight，并安裝好需要的插件（如odl－restconfig－all插件）。

（3）啟動OpenvSwitch交換機，并將交換機連接到控制器上，使得OpenDaylight的Web管理界面能夠看到這臺OpenvSwitch交換機，并記住交換機的DPID。每臺交換機的DPID可能不同，本節(jié)中交換機的DPID為OpenFlow:619144302644。

2.對Postman進行配置

（1）由于調用服務器端的REST接口需要授權，因此要在Postman設置授權，如圖7-22所示，在Authorization中的Type選擇BasicAuth，在Username和Password中填入admin。

（2）指定Postman的數(shù)據(jù)交換的內容類型，這里使用的是JSON。在Headers中的Content－Type填入application/json，如圖7-23所示。

圖7-22

Postman設置授權圖7-23

Postman設置內容類型

3.GET請求顯示流表

（1）確定要查看的流表（使用YangUI工具下發(fā)完成一條流表），確保通過查看命令可以看到如圖7-24中所下發(fā)的流表。

圖7-24交換機中的流表

（2）在Postman中HTTP請求選擇GET，其中URL地址為

http://:8181/restconf/config/opendaylightinventory:nodes/node/openflow:619144302644/table/0

點擊Send獲取流表內容，流表內容為JSON格式（如圖7-25所示）。

圖7-25

Postman獲取流表

4.DELETE刪除流表