余思陽，楊佑君，李長連（.中訊郵電咨詢設計院有限公司，北京 00048；.中國聯(lián)通軟件研究院，北京 0076）

0 前言

互聯(lián)網(wǎng)技術的快速發(fā)展，運營商4G技術的廣泛使用以及5G技術的快速演進給人們帶來便捷的同時，也使網(wǎng)絡攻擊等違法行為的規(guī)模及數(shù)量迅速增長，分布式拒絕服務攻擊（DDoS）是最主要的威脅之一。其中網(wǎng)絡層SYN Flood和UDP Flood是流量最大的2種攻擊類型，并且SYN Flood 大流量攻擊數(shù)量從2018 年1 月以來顯著增加。

防御DDoS 攻擊的主流技術是流量清洗，其核心是采集流量并分析，傳統(tǒng)基于Linux 內核的流量清洗技術由于較大的網(wǎng)絡開銷和系統(tǒng)資源消耗導致其難以滿足當前需求。針對這一趨勢，本文提出一種基于Intel DPDK 的DDoS 攻擊防御方案，旨在當前Linux 內核流量清洗技術的基礎上，達到更高的流量清洗能力，為DPDK 技術應用領域拓展以及DDoS攻擊防御性能提升提供新的思路。

1 流量清洗技術性能研究

流量清洗系統(tǒng)主要由檢測模塊、清洗模塊和管理模塊組成，主要架構如圖1 所示。首先由檢測模塊進行數(shù)據(jù)包捕獲和識別，并將相應日志上報管理模塊，然后管理模塊根據(jù)清洗策略將相應的清洗命令下發(fā)到清洗模塊設備，清洗模塊收到清洗指令后將流量引流到清洗設備進行清洗，最后將清洗后的正常流量回注到網(wǎng)絡中。其中影響流量清洗系統(tǒng)效率的一個重要因素是檢測模塊的數(shù)據(jù)包捕獲和識別速度。

圖1 流量清洗系統(tǒng)架構

目前主流的數(shù)據(jù)包捕獲方式是基于Libpcap（Packet Capture Library）技術開發(fā)的數(shù)據(jù)包捕獲機制。Libpcap 最初是由勞倫斯伯克利實驗室網(wǎng)絡研究小組的tcpdump開發(fā)人員開發(fā)，是在Unix/Linux平臺中提供的網(wǎng)絡數(shù)據(jù)包捕獲函數(shù)包。其主要工作流程如下：首先設置為混雜模式的網(wǎng)卡根據(jù)配置進行DMA（Direct Memory Access）操作并發(fā)送中斷指令到處理器，處理器被喚醒后調用指令填充讀寫緩沖區(qū)數(shù)據(jù)結構，即復制數(shù)據(jù)到內核緩沖區(qū)，然后在內核協(xié)議棧中進行過濾處理，最后復制數(shù)據(jù)到用戶空間。在這種方式下每個數(shù)據(jù)包都會觸發(fā)1 個中斷和2 次拷貝，并且造成緩沖區(qū)資源和系統(tǒng)資源消耗。所以在大流量攻擊下會導致系統(tǒng)負載過大，造成時延過大、丟包率過高甚至系統(tǒng)癱瘓。

2 Intel DPDK簡介

相比Libpcap，Intel DPDK 出色的數(shù)據(jù)包加速處理性能以及充分的用戶空間靈活性，使其成為更好的解決方案。下面簡要介紹DPDK的原理及實現(xiàn)。

2.1 DPDK架構

Intel DPDK（Data Plane Development Kit）是由英特爾公司開發(fā)的一款數(shù)據(jù)平臺開發(fā)套件，是一個基于x86 平臺用C 語言編寫的用于快速數(shù)據(jù)包處理的函數(shù)庫和驅動的集合。DPDK的基本架構如圖2所示，其中最底層硬件平臺使用網(wǎng)卡接收數(shù)據(jù)包，內核空間的3個模塊分別為KNI、UIO 和EAL。DPDK 利用UIO 模塊將網(wǎng)卡硬件寄存器映射到用戶空間，從而跳過Linux內核網(wǎng)絡協(xié)議棧，在用戶空間直接運行驅動從網(wǎng)卡上讀取數(shù)據(jù)并進行處理。EAL 模塊是DPDK 核心模塊之一，主要進行資源分配及初始化，并為底層資源訪問提供用戶層入口。

圖2 DPDK的基本架構

2.2 DPDK核心技術

DPDK實現(xiàn)快速數(shù)據(jù)包處理主要依賴以下技術。

a）輪詢模式驅動（PMD——Poll Mode Driver）：該驅動不同于Linux 內核的中斷模式驅動，而是收到數(shù)據(jù)包后直接通過DMA 方式傳送到預分配內存并直接處理，避免了中斷上下文切換開銷。

b）用戶態(tài)驅動：用戶態(tài)驅動可減少不必要的內存拷貝和系統(tǒng)調用，基本可在用戶空間實現(xiàn)驅動，并且用戶態(tài)驅動可以根據(jù)不同場景進行更新和優(yōu)化。

c）大頁內存（Hugepage）：對于物理地址轉換虛擬地址，Linux 一般通過查找TLB 表映射，其默認頁大小為4K，而采用2M 或1G 的大頁內存，則TLB 的頁表項會顯著較少，從而極大減少頁表查找頻率，并降低TLB miss開銷。

d）親和性和獨占：利用線程的CPU 親和綁定機制使特定任務被指定在某個特定的核上執(zhí)行，這樣可避免線程在不同核之間頻繁切換而造成的性能損失。

3 基于DPDK的DDoS攻擊防御方案

3.1 方案設計

當前應用需求多為千兆和萬兆網(wǎng)絡中的大容量數(shù)據(jù)通信與高速數(shù)據(jù)包捕獲分析和處理，本方案主要針對當前攻擊流量最大的TCP Flood 和UDP Flood 進行防御，主要工作流程為：首先通過IP 報文協(xié)議號（TCP 為6，UDP 為17）篩選出TCP 包和UDP 包；然后通過報文源端口號區(qū)分不同的UDP 反射放大攻擊類型，例如DNS 反射放大攻擊源端口號為53，NTP 反射放大攻擊源端口號為123；分別實時統(tǒng)計不同類型攻擊的速率，當速率大于設定閾值時丟棄后續(xù)收到的此類型的數(shù)據(jù)包。

使用DPDK 編寫程序的目標是最大化地利用服務器的網(wǎng)絡吞吐與處理能力，確保多個網(wǎng)卡、多個核并行工作，同時不出現(xiàn)資源競爭與沖突，因此借鑒網(wǎng)絡負載均衡的理念，設計了一個軟負載均衡的架構（見圖3），其中劃分了I/O 接收邏輯核、工作者邏輯核與I/O 發(fā)送邏輯核3 個角色，用于接收數(shù)據(jù)包、處理數(shù)據(jù)包、發(fā)送數(shù)據(jù)包，并分別綁定物理核，3 個角色間利用DPDK中的ring緩存隊列進行數(shù)據(jù)交互。

圖3 軟件處理架構設計圖

3.2 方案實現(xiàn)

DPDK 的進程分為控制進程和數(shù)據(jù)進程。控制進程通常與主核綁定，主要接收用戶配置，并傳遞配置到數(shù)據(jù)進程；數(shù)據(jù)進程通常進行數(shù)據(jù)包處理工作。

3.2.1 控制進程

控制進程主要工作流程如圖4 所示，具體實現(xiàn)步驟為：

圖4 控制進程工作流程圖

a）從main 函數(shù)開始執(zhí)行，首先調用rte_eal_init 函數(shù)初始化環(huán)境抽象層EAL，構建DPDK 基礎工作環(huán)境；然后解析輸入?yún)?shù)，獲取分配的網(wǎng)口、核、隊列數(shù)等配置，根據(jù)配置初始化可用端口、大頁內存、發(fā)送隊列和接收隊列，創(chuàng)建LPM 表或HASH 表，用于將目的IP 為不同網(wǎng)段的數(shù)據(jù)包從指定網(wǎng)口發(fā)出。

b）完成環(huán)境配置和初始化后調用rte_eth_dev_start 函數(shù)啟動設備，包括啟動綁定DPDK驅動的網(wǎng)卡。

c）通過rte_eal_mp_remote_launch 在每個lcore 上都啟動main_loop 線程，其中main_loop 函數(shù)為主處理函數(shù)。

3.2.2 數(shù)據(jù)進程

數(shù)據(jù)進程主要步驟如圖5 所示，進程從main_loop函數(shù)開始，進行相關配置初始化后進入主循環(huán)，首先批量接收數(shù)據(jù)包，利用rte_pktmbuf_mtod 獲取以太網(wǎng)頭部，將其地址后移以太網(wǎng)頭部的長度即可獲取數(shù)據(jù)包的ipv4 頭部地址，判斷ipv4 頭部中next_proto_id 字段的值，若為17 則是UDP 包，若為6 則是TCP 包；如果是UDP 包則判斷src_port 的值，以區(qū)分不同類型的UDP 報文攻擊；分別統(tǒng)計不同類型數(shù)據(jù)包數(shù)量并定時計算吞吐量，判斷吞吐量是否大于設定閾值，若大于閾值則認為是攻擊流量，后續(xù)收到此類型數(shù)據(jù)包將不進行轉發(fā)，直接釋放其mbuf；若小于閾值則認為是正常數(shù)據(jù)報文，根據(jù)ipv4 頭部的dst_addr 獲取目的IP 地址，查找LPM 表進行最長前綴匹配得到轉發(fā)出口網(wǎng)口，最后將數(shù)據(jù)包通過對應網(wǎng)口批量轉發(fā)出去。

4 實驗驗證及結果分析

4.1 數(shù)據(jù)源

本實驗采用思博倫公司的網(wǎng)絡數(shù)據(jù)測試儀spi?rent testcenter模擬不同類型的DDoS攻擊流量。

4.2 實驗環(huán)境

實驗環(huán)境為一臺dell服務器，基本配置信息如表1所示。

4.3 實驗方法

根據(jù)上文所述，影響流量清洗的主要因素之一是檢測模塊的數(shù)據(jù)包捕獲與識別性能，故本實驗主要進行數(shù)據(jù)包捕獲識別性能的對比，測試Libpcap 與DPDK在不同攻擊流量與數(shù)據(jù)包長度條件下的處理性能。Libpcap 是Unix/Linux 系統(tǒng)下的用于捕獲網(wǎng)絡數(shù)據(jù)包的函數(shù)庫，是大多數(shù)網(wǎng)絡數(shù)據(jù)包分析軟件的基礎，如tcpdump、snort、Ethereal等。

圖5 數(shù)據(jù)進程工作流程圖

表1 實驗平臺基本配置表

以UDP 包為例，利用流量測試儀發(fā)送不同包長和吞吐率的流量，測試不同條件下二者的性能差異。編寫DPDK 程序實時在控制臺打印數(shù)據(jù)包收發(fā)包數(shù)、吞吐量等信息，方便后續(xù)統(tǒng)計對比。

首先測試DPDK 數(shù)據(jù)包捕獲性能，用spirent test?center 測試儀產(chǎn)生包長為128 B、256 B、1 024 B 的UDP包，分別以1 Gbit/s、8 Gbit/s、10 Gbit/s 速率發(fā)送，測試時延和丟包率；以同樣的方法測試Libpcap數(shù)據(jù)包處理時延和丟包率，然后比較兩者的性能。

4.4 實驗結果

DPDK 與Libpcap 在不同包大小和不同發(fā)送速率情況下的平均時延分別如圖6 和圖7 所示。從圖6 和圖7 可看出隨著數(shù)據(jù)包發(fā)送速率的增大，DPDK 與Lib?pcap 的數(shù)據(jù)包處理時延都顯著增加，DPDK 方式處理數(shù)據(jù)包的時延遠小于Libpcap，有4 個數(shù)量級的差距，具有明顯優(yōu)勢。

圖6 DPDK處理數(shù)據(jù)包時延統(tǒng)計圖

圖7 Libpcap處理數(shù)據(jù)包時延統(tǒng)計圖

DPDK 與Libpcap 的丟包率性能分別如圖8 和圖9所示，兩者的丟包率都隨數(shù)據(jù)包發(fā)送速率增大而增加，其中DPDK 捕獲數(shù)據(jù)包的丟包率非常低，流量為10 Gbit/s時丟包率有增加是由于服務器萬兆網(wǎng)卡本身的性能限制，而Libpcap 捕獲數(shù)據(jù)包的丟包率很高，128 B 小包的丟包率接近90%，因此DPDK 處理數(shù)據(jù)包的可靠性更高。

通過DPDK 與Libpcap 的數(shù)據(jù)包處理性能對比分析，可以看出DPDK具備明顯的優(yōu)勢。

5 結束語

圖8 DPDK處理數(shù)據(jù)包丟包率統(tǒng)計圖

圖9 Libpcap處理數(shù)據(jù)包丟包率統(tǒng)計圖

利用DPDK 快速處理數(shù)據(jù)包的性能優(yōu)勢以及可在用戶空間設計應用程序的特點，本文提出一種基于DPDK 的DDoS攻擊防御技術。同時通過實驗證明DP?DK相比于傳統(tǒng)的Libpcap方案在各項性能指標上都有非常顯著的優(yōu)勢。將DPDK 與更多的流量清洗方法以及DDoS 攻擊防御方法相結合以提高防御效率將是后續(xù)研究的方向。