一種IPv6隧道環境下數據逃逸的防御策略

崔宇

摘 要：隧道技術是IPv4向IPv6過渡階段的重要研究內容，為無IPv6物理接入的用戶提供基于隧道的IPv6接入，使其可提前使用IPv6網絡。為提高隧道網絡的安全性，本文對隧道流量對安全設備的影響進行了研究。指出隧道技術可被攻擊者利用實施針對網絡邊界安全設備的數據逃逸，攻擊網絡內部主機。因此，本文提出了基于隧道分類的防御方法，通過在特定結構中增加外層包頭的相關信息對不同流量進行分類，抵御上述攻擊。實驗表明，該方法具有較好的時間和空間復雜度，對系統負載影響較小。

關鍵詞：IPv6； 安全； 隧道； 數據逃逸

中圖分類號：TP393 文獻標識碼：A 文章編號：2095-2163（2014）02-

A Data Evasion Defending Strategy based on Tunnel Classification

CUI Yu1， TIAN Zhihong1， FANG Binxing1，2

（1 Research Center of Network and Information Security， Harbin Institute of Technology， Harbin 150001， China；2 Beijing University of Posts and Telecommunication， Beijing 100876， China）

ABSTRACT：Tunneling is one of the key researches in the transitioning from IPv4 to IPv6 networks. It provides a feasible method for the end customers to connect to IPv6 Internet even if they have no native IPv6 connections. To improve the security of tunnels， this paper studies the influence of tunnel traffic on the security devices， and points out that tunnels could be exploited by attackers to perform data evasion on the security devices and attack internal hosts. Therefore， this paper proposes a defending strategy based on tunnel classification （TCDS）. By defining external headers in recording structures and comparing from the outermost to innermost headers， TCDS could effectively classify different traffics. Experimental results show， TCDS is with favorable time and space complexity which has little effect on the system load.

KEYWORDS： IPv6； Security； Tunnel； Data Evasion

0 引 言

在IPv4網絡向IPv6網絡升級推進的過程中，隧道技術可給還未部署物理IPv6網絡的主機提供接入IPv6網絡的方法，使其可提前使用IPv6的相關服務，由此即有效推動了IPv6的發展。但是，由于隧道技術使得更多節點暴露在子網外部（比如NAT網絡），如此則導致了在為普通用戶提供IPv6網絡接入的同時，也為攻擊者提供了潛在目標。更進一步，攻擊者可以利用暴露節點作為源起而對整個內部網絡發動攻擊。因此，防御利用隧道技術進行的針對暴露主機的攻擊行為是維護網絡安全和穩定的重要因素。

網絡邊界安全設備通過監聽進出子網的數據流量，檢測是否存在惡意的攻擊行為，維護網絡安全。但是，目前網絡安全設備缺少對利用隧道進行數據逃逸的檢測機制，如snort、wireshark等重要的工具均未能有效檢測隧道的數據逃逸行為，因此研究隧道數據逃逸防御方法具有重要的意義。本文組織結構如下：第一節敘述相關工作；第二節說明隧道數據逃逸的方法；第三節提出對應的防御方法；第四節進行測試；第五節總結全文。

1 相關工作

現有研究文獻中，安全設備對隧道流量的支持主要包含兩個方面：擴展包頭及協議處理和隧道流量過濾。下面將分別展開具體論述。

1.1 擴展包頭及協議處理

文獻[1]提出了利用分片包頭和目的選項包頭進行TCP包頭替換的方法，可使外部主機向內部主機發起主動連接。而防火墻一般只允許網絡內部主機的主動連接、避免內部網絡探測。文獻[2]對防火墻上ICMPv6協議的過濾策略進行了詳細分析，指出與IPv4相比可分為三部分：（1） 與IPv4過濾策略對等；（2） IPv6新增協議的過濾策略；（3）防火墻需響應的ICMPv6選項。文獻[3]指出IPv6允許一個接口配置多個IPv6地址，由此對防火墻或入侵檢測設備而言，基于IP地址的過濾策略不再有效。而采用前綴進行地址過濾時，由于地址的多種自動配置方法的存在，正常地址也將會過濾掉，這就決定了防火墻必須記錄所有地址，顯然對防火墻而言任務量過于巨大。文獻[3]只是提出該問題，而未給出解決方法。文獻[4]指出RFC標準并未對IPv6擴展包頭的使用規則進行嚴格規范，未明確限制擴展包頭出現的順序和次數，如此就導致防火墻在針對IPv6擴展包頭處理流程的設計上存在不確定性。但若支持所有擴展包頭排列組合，在設計上卻存在較大難度。因此該文建議采用最簡單的default-deny策略，將不符合基本規則的數據包直接扔掉。但同時卻也指出，該方法可能會破壞IPv6擴展包頭的諸多功能，因而不能作為長效機制。

1.2隧道流量過濾

文獻[5]指出，目前防火墻主要以IPv4為主，網絡管理員若只對防火墻進行簡單的IPv6升級并不能過濾隧道流量，因為其無法對所有隧道流量進行識別。例如利用3544端口Teredo隧道進行過濾，可阻止Teredo隧道的建立，但對已經建立的Teredo隧道則表現為無效。另外，如果存在多層NAT，當過濾外層NAT時就會引發內層NAT端口誤封，由此影響內層NAT設備的正常運行。文章還討論了對隧道流量進行深度包檢測的問題，指出除了隧道邊界，其它位置的DPI設備均無法檢測出所有的隧道流量，因此就不能實行有效的過濾規則。其它類型的隧道，如tunnel over http采用與http連接相同的80端口，這就使得無法通過簡單的方式進行過濾，而必須檢查所有數據，再通過啟發性的發掘才能確定是隧道數據還是正常的http數據。但這一做法卻可能在相當程度上增加系統處理的時延，而且降低系統吞吐率。文獻[6]指出由于目前大部分防火墻和入侵檢測系統只能處理最外層的過濾、或者獨立進行IPv4和IPv6的過濾，導致隧道數據包可輕易穿過這些防火墻，因此文中利用Linux Netfilter設計并實現了一套隧道流量過濾系統，能夠有效地識別6in4和4in4的隧道流量，進而實現地址級別的過濾。該方法中，IPv4和IPv6仍是獨立運行，并未考慮兩者關聯，比如6to4隧道IPv6包含隧道邊界的IPv4地址，若不經由正確性驗證就容易引發欺騙攻擊。文獻[7]則認為在過渡階段隧道已經大規模使用，且6to4、ISATAP、Teredo等隧道自動配置特點使其得到了廣泛部署，因此對隧道流量進行過濾即具有了切實合理的明確需求。于是就提出了防火墻過濾各種隧道流量的以隧道特征為基礎的過濾方法，包括6in4、6over4、6to4、6rd、Teredo、ISATAP、Tunnel Broker、AYIYA。具體包括外層IPv4地址的過濾，內層IPv6地址的過濾兩種方法。文章同時指出，在過濾IPv6流量的同時，由于主機并不知道其IPv6流量已經過濾，這時需要切換IPv4連接，但這需要一定時間，影響效率。因此作者認為在防火墻過濾隧道流量的同時，也需考慮DNS問題，使主機無法得到AAAA記錄，終端用戶也將隨之不會進行IPv6連接。

2 隧道數據逃逸方法

傳統安全設備只識別最內層IP包頭，忽視外層包頭，因此為隧道提供了數據逃逸的可能性。本節以6to4、Teredo兩種廣泛使用的隧道為例，說明攻擊者利用隧道進行數據逃逸的基本方法。

2.1 6to4隧道

圖1所示為利用6to4隧道進行數據逃逸的基本方法。假設攻擊者具有2.2.2.2的公網IPv4地址，則其可以為自身配置2002：2.2.2.2：：3的6to4隧道地址，由此攻擊者即可以與其它6to4主機進行連接，并進行攻擊。圖1中右側網絡公網IP為1.1.1.1，利用6to4隧道，其內部節點分別配置了2002：1.1.1.1：：1和2002：1.1.1.1：：2的6to4地址。假設攻擊者需要對主機B進行攻擊，則攻擊者可以首先發送數據包1，安全設備將判定數據包1是攻擊者到主機B的數據而進行檢查，但由于該段是正常數據，因此可以正常通過安全設備。其后，根據第二層IPv6包頭，會將該數據包轉發給主機A，并由主機A實現丟棄。攻擊者又一次發送了數據包2，該數據包含有惡意數據。由于數據包1的存在，安全設備會誤認為數據包2為數據包1的重復包，因此不會產生進一步反應。由此，數據包2亦可通過安全設備，并轉發給主機B，如此即形成了針對主機B的攻擊。

圖1 基于6to4隧道的數據逃逸

Fig.1 Data Evasion by 6to4 Tunnel

2.2 Teredo隧道

利用Teredo隧道進行數據逃逸的基本方法可如圖2所示。與6to4方式不同，Teredo使用了UDP協議為第二層包頭。

圖2 基于Teredo隧道的數據逃逸

Fig.2 Data Evasion by Teredo Tunnel

圖2中，目標CA主機處于NAT網絡環境下，而這也是UDP隧道的標準使用環境。在此種環境下，連續的兩個數據包可以采用數據插入或者數據逃逸的方式進行針對安全設備的攻擊，使安全設備無法還原出終端主機接收的惡意數據，從而成功逃避攻擊檢測。偽造數據包的UDP端口在NAT設備對應的UDP端口映射中可能并不存在，故而可直接丟棄。

3 基于隧道分類的防御方法

基于隧道分類防御方法（Tunnel Classification based Defending Strategy， TCDS）的基本思想是將數據包所屬的隧道類型進行存儲，存儲后通過比較區分不同的隧道流量。本節將從數據存儲、分類過程兩個方面對其進行說明。

3.1 TCDS數據存儲

TCDS需要對外層包頭相關信息進行存儲，相關的包頭主要有IPv4、IPv6和UDP三種，首先對三種包頭需要存儲的內容進行分析。為了縮減空間，可以只提取三種包頭的有效信息，及影響流量分類的信息。一般情況下，經典系統中主要使用源和目的IP地址、源和目的端口為區分標識，因此TCDS也提取上述標識為區分標識，如表1所示。

表1 IPv4/IPv6/UDP包頭存儲字段

Tab. 1 Recording Parameters for IPv4/IPv6/UDP Headers

Protocol Parameters Length（B）

IPv4 Source & Destination IPv4 Addresses 8

IPv6 Source & Destination IPv6 Addresses 32

UDP Source & Destination Ports 4

由表1可以看出，經過提取，IPv4、IPv6和UDP包頭分別需要8、32和4字節的存儲空間。下面即具體說明如何將外層包頭信息進行存儲。為保證安全設備的處理速度，選定靜態方式作為存儲方式，存儲格式如圖3所示。其中“TL”表示內存空間實際使用的字節數。“Type”表示該層包頭的形式，可能為IPv4、IPv6或UDP。“S & D”表示與“Type”對應的源和目的IP地址，或源和目的端口信息。

圖 3 TCDS存儲格式

Fig. 3 Format on TCDS Record

理論上，256字節的存儲空間可容納最多7層IPv6包頭、或25層IPv4包頭（通常，UDP包頭最多出現一次，且UDP包頭所需空間僅為2字節）。根據某骨干路由器上一段時間的統計，隧道層數出現的最大數量為4層，因此256字節的空間可足夠容納現網流量中的隧道類型。并且，可視超過7層的隧道流量為異常流量，此時極有可能是出現了攻擊行為。

對于安全設備而言，因為要進行流量還原，就需要進行TCDS存儲的結構主要是能夠進行流量還原的結構，這將包括：

（1） 分片重組結構，典型為fragments數據結構；

（2） TCP流表，典型結構為tcp_stream等。

下面給出外層包頭的存儲算法，如算法1所示。在解析每個外層包頭時，首先讀取TL變量，獲得本包頭的寫入位置，寫入對應類型和對應信息后，更新TL變量，即完成本層包頭的信息記錄。TCDS存儲算法如下：

Input：數據包p，存儲空間指針buffer

Output：存儲后的buffer

（1） procedure Record_TCDS（Pakcet *p， buffer）

（2） TL ← TL of buffer

（3） Typei ← type of this layer in p

（4） if Typei is IPv4 then

（5） write 4 of this layer in p at offset TL

（6） record SIPv4 & DIPv4 at TL + 2

（7） update the length of TL to TL + 8

（8） else if Typei is IPv6 then

（9） write 41 of this layer in p at offset TL

（10） record SIPv6 & DIPv6 at TL + 2

（11） update the length of TL to TL + 32

（12）else if Typei is UDP then

（13） write 17 of this layer in p at offset TL

（14） record Sport & Dport at TL + 2

（15） update the length of TL to TL + 4

（16）else

（17） return

（18）end if

（19）end procedure

3.2 TCDS分類過程

TCDS的比較需要從外層包頭逐層向內層包頭進行，基本運行邏輯如圖4所示。

圖 4 TCDS分類過程

Fig. 4 Process of TCDS Classification

圖4中，系統從最外層包頭進行拆包，分別將外部兩層包頭填入臨時存儲結構tcdstmp。若需進行比較，則與系統中存儲的tcdsrec結構進行比較。相同，即表明是同一個隧道流。TCDS的比較算法如下：

Input：臨時存儲結構tcdstmp，存儲的結構tcdsrec

Output：比較結果

（1） procedure compare_TCDS（tcdstmp， tcdsrec）

（2） TLt ←tcdstmp.TL

（3） TLr ←tcdsrec.TL

（4） if TLt ！= TLr then

（5） return diff

（6） else

（7） if compare（tcdstmp， tcdsrec， TLt） then

（8） return diff

（9） else

（10） return same

（11） end if

（12） end if

（13） end procedure

4 實驗

理論上，安全設備中每個需要進行流量區分的處理流程（如分片重組、TCP還原）均可使用TCDS方法。此時，在相應存儲結構中分別預先定義256字節的存儲空間。設N為安全設備中分片重組和TCP還原涉及結構體的總量，兩者所需內存空間分別為256N字節，空間復雜度均為O（N），線性增長。以Snort為例，默認情況下IP分片和TCP流表分別為8 192和262 144個，則TCDS需要2MB和64MB的存儲空間（Snort最大支持1 048 576個TCP流，則TCDS需要256MB的存儲空間）。因此，TCDS不會對安全系統的內存產生很大負載。

相對于空間復雜度，時間復雜度對安全設備的影響更大，由于TCDS對每個流經的數據包均需進行計算，這就會降低安全設備的處理能力。每個數據包的每層包頭也都需要進行計算、存儲和比較，因此時間復雜度均為O（K），K為隧道層數。下面將通過實驗對TCDS性能進行分析。

實驗在CPU主頻2.4GHz、物理內存16GB的服務器上進行。所用隧道種類從一層IPv4、IPv6到5層IPv4、IPv6，包頭種類交叉的方式也內含其中。每種隧道生成100萬TCP數據包，統計TCDS方法與原始方法相比的用時，進而分析TCDS方法對系統性能的影響。部分實驗結果如表2所示。

表2 TCDS計算時間增加比例（%）

Tab. 2 Time increment in TCDS in percentage

Type TCDS Avg Type TCDS Avg

4 0.48 0.48 6 0.68 0.68

44 0.97 0.49 66 1.82 0.91

444 1.71 0.57 666 3.11 1.04

4444 2.26 0.57 6666 4.26 1.07

44444 2.62 0.52 66666 5.15 1.04

表2所示結果表明，TCDS方法每層最多增加1.07%的計算時間，對系統負載的增加較小。同時隨著隧道層數的增加，處理的時間復雜度將有所增加，主要是由于比較長度增加導致。包頭交叉的情況與表2所示情況類似，限于篇幅，文中并未列出。

5 結束語

本文對利用隧道技術實施的針對安全設備的數據逃逸技術進行了分析，提出了基于隧道分類的防御方法，該方法通過在系統特定結構內存儲相應的外層包頭信息對不同的隧道進行區分，從而抵御隧道模式的數據逃逸。實驗表明，該方法對系統負載影響較小，每層包頭平均不超過1.1%的時間增加。

參考文獻：

[1] KRISHNAN S. Handling of Overlapping IPv6 Fragments. RFC 5722. 2009.

[2] SHARMA V. IPv6 and IPv4 security challenge analysis and best-practice scenario [J]. Advanced of Networking and Applications， 2010， 1（4）：258-269.

[3] VINEETH M V， REJIMOAN R. Evaluating the performance of IPv6 with IPv4 and its Distributed Security Policy[C]//Proceedings of 2013 IEEE Conference on Information and Communication Technologies （ICT 2013）.：59-63.

[4] ALANGAR V， SWAMINATHAN A. IPv6 Security： Issue of Anonymity[J]. International Journal of Engineering and Computer Science ISSN， 2013，2（8） ：2486-2493.

[5] KRISHNAN S， THALER D， HOAGLAND J. Security Concerns with IP Tunneling， RFC6169， 2011， 4.

[6] LEE W-J， HEO S-Y， BYUN T-Y. A secure packet filtering mechanism for tunneling over Internet[C]//Proceeding ICESS '07 Proceedings of the 3rd international conference on Embedded Software and Systems. Daegu， South Korea. 2007， 641-652.

[7] GONT F， LIU W. Security Implications of IPv6 on IPv4 Networks. draft-ietf-opsec-ipv6-mplications-on-ipv4-nets-05，2013.