基于IPv6 協議的隱蔽信道構建方法研究*

趙序琦，孫 亮，王軼駿，薛 質

(1.上海交通大學，上海 200240；2.江蘇省南通市公安局，江蘇 南通 226001)

0 引言

IPv6 協議作為取代IPv4 協議的新一代網絡通信協議，其主要作用是解決IPv4 地址資源枯竭的問題。在目前IPv4 地址資源日趨耗盡的情況下，擁有更大地址空間范圍的IPv6 協議勢必會逐漸取代IPv4 協議，成為主流的網絡層通信協議。在這種背景下，IPv6 環境下的安全問題也對網絡安全提出了新的挑戰。

隱蔽信道是一種違背系統安全策略的以秘密的形式傳送信息的通信通道，它一般利用網絡通信的合法數據報文作為載體，對要傳輸的數據進行編碼、嵌入等操作，進行隱秘數據的傳輸。隱蔽信道會被攻擊者利用來繞過流量監測或安全審計等措施，對網絡與信息系統造成破壞，如被用在木馬或僵尸網絡等惡意程序中，來繞過防火墻等安全設備的審查。攻擊者一般利用合法的網絡協議作為載體來構建隱蔽信道，IPv6 協議同樣可以成為隱蔽信道的載體，在IPv6 協議部署與應用日益廣泛的情況下，研究基于IPv6 的隱蔽信道對網絡安全具有重要意義。

隱蔽信道可以被分為存儲型隱蔽信道與時間型隱蔽信道，存儲型隱蔽信道利用協議中的字段值作為傳輸載體，而時間型隱蔽信道利用協議報文的傳送間隔等時間特性作為傳輸載體，本文針對基于IPv6 協議構建的存儲型隱蔽信道進行研究。

1 研究現狀

IPv6 協議標準公布后，一些研究人員對基于IPv6 協議的隱蔽信道進行了研究，雖然IPv6 協議標準在制定時已經將安全因素考慮在內，但是仍然不能避免對協議的某些字段定義不夠嚴格、對某些字段的定義仍然留有保留位，或規定對字段未定義值默認采取忽略措施等，這都為隱蔽信道的構建提供了良好的載體。

Lucena 等人[1]通過對IPv6 協議報文標準進行分析，針對IPv6 協議固定頭部以及六種擴展頭部中的字段中存在的保留位等特征，共提出了22 種構建隱蔽信道的方式；楊智丹等人[2]分析了IPv6協議標準中的不完善之處，針對保留字段、轉發時被節點忽略的字段、定義不完整字段和非關鍵字段等可隱匿信息的字段提出了共5 類19 種隱蔽信道的構建方式；郭浩然等人[3]針對IPv6 協議固定頭部提出了基于數據包操作和基于比特變換的兩種隱蔽信道，并基于比特變換的方式以Hop-Limit 字段為載體詳細闡述了構建隱蔽信道的方式；Mavani 等人[4]利用IPv6 協議擴展頭部中的目標選項頭部來構建隱蔽信道，并提出了針對該隱蔽信道的檢測方法；Mazurczyk 等人[5]則抓取了實際網絡中的流量，通過統計IPv6 協議中被用來構建隱蔽信道的字段取值分布，和測試安全設備對隱蔽信道的檢測情況，分析實際場景中更加隱蔽與實用的信道構建方式。

IPv6 協議標準自提出以來處在不斷的更新迭代之中，上述研究成果部分公布較早，其所參考的IPv6 協議標準文檔在如今已被更新的標準文檔所取代，如在分析IPv6 協議頭部時被許多文檔所參考的文檔RFC 2460[6]已被更新的RFC 8200[7]所取代，所以對于隱蔽信道的某些構建方式應該被重新評估。此外，部分研究僅針對隱蔽信道構建方式提出了想法與理論，而缺乏具體的應用實現與在實際環境中的測試，對于基于IPv6 協議的隱蔽信道在實際環境中構建與應用情況也值得研究與探討。

2 IPv6 協議隱蔽傳輸信道構建方式

IPv6 協議數據報文由協議頭部、可選的多個擴展頭部和上層協議數據組成，由于協議的定義存在不嚴密的地方，協議頭部和擴展頭部中的某些字段都能夠成為構建隱蔽信道的載體。

2.1 IPv6 協議頭部中的隱蔽信道

IPv6 協議頭部的長度固定為40 字節，其最新定義位于RFC 8200 中，結構定義如圖1 所示。

圖1 IPv6 協議頭部結構

根據RFC 文檔對于字段的功能、取值與相關操作的定義，在IPv6 協議頭部中，可以被用來構建隱蔽信道的字段有：

通信流類別（Traffic Class）：該字段長度為8 比特，它在通信中被用來實現流量控制相關的功能，其中前6 位定義了DSCP（Differentiated Services Codepoint），最后兩位定義了ECN（Explicit Congestion Notification）。該字段的值主要在傳輸過程中被中繼節點所使用，可以被替換用來存儲數據，不過需要注意的是，該字段在傳輸過程中可能被中繼節點修改，收到報文時該字段數據相比發出時可能已被修改，所以傳輸效果可能不穩定。

流標簽（Flow label）：該字段長度為20 比特，它在傳輸中被用來區分不同的傳輸流。該字段的值一般由發送端設置，字段的值的分布應該是隨機均勻的，并且在設置為非零值時在傳輸過程中一般不允許被中繼節點改變，所以可以被替換為隱蔽數據進行傳輸。

載荷長度（Payload Length）：該字段長度為16 比特，它的值為在IPv6 協議頭部后負載部分數據報文的長度，包括擴展報頭與上層協議數據。可以將此字段設置為大于其正常值，并在數據報文最后添加要傳輸的隱蔽數據，以此來構建隱蔽信道。此種隱蔽信道的傳輸速率不固定，由設置的超出正常載荷長度的值確定。

跳限制（Hop Limit）：該字段長度為8 比特，它定義了數據報文在傳輸中的最大跳數，由于報文的傳輸路徑可能不穩定，所以該字段的值在抵達接收節點時不能保證穩定，當使用該字段來進行隱蔽信息的傳輸時，一般不直接將數據存儲在該字段，而是通過一定的規則將0 或1 比特與字段值進行映射，所以該字段構建的隱蔽信道的傳輸速率為1bit/packet。

2.2 IPv6 擴展頭部中的隱蔽信道

IPv6 擴展頭部緊跟在IPv6 固定頭部之后，可以有零或多個，RFC 8200 中定義了4 種擴展頭部，包括逐跳選項頭部（Hop-by-Hop Options header）、目標選項頭部（Destination Options header）、路由頭部（Routing Header）和分段頭部（Fragment Header），此外在其他標準中還定義了封裝安全載荷（Encapsulating Security Payload）、認證頭部（Authentication Header）、移動頭部（Mobility Header）、主機標識協議（Host Identity Protocol）和Shim6 協議[8]。

經過在Ubuntu 20.04 操作系統上測試，默認情況下只有在RFC 8200 中定義的四種擴展頭部可以被系統識別，對于其他的擴展頭部，操作系統將丟棄數據報文并回復錯誤類型為“未識別的頭部類型”的ICMP 報文。所以針對擴展頭部中構建隱蔽信道的研究將只在逐跳選項頭部、目標選項頭部、路由頭部和分段頭部中進行。

2.2.1 逐跳選項頭部和目標選項頭部中的隱蔽信道

逐跳選項頭部和目標選項頭部擁有相同的協議格式，并且它們都攜帶若干個長度可變的選項，所攜帶選項的格式定義統一如圖2 所示，其中選項類型與選項長度字段的長度均為8 個比特，選項數據的內容根據不同選項而不同，選型長度字段的值即為選項數據的長度。

圖2 逐跳選項與目標選項格式

選項類型字段的前三位比特具有單獨定義，其中前兩位比特說明了如果IPv6 節點不識別該選項時應采取的措施，若前兩位比特設置為00，則表示措施為跳過該選項并繼續處理后續數據。后五位比特則用來標識不同選項，而目前未被占用的選項數值的比特范圍為10010～11101，所以可以利用此特性來構造不存在的選項并將傳輸數據填入選項的數據部分來構造隱蔽通道。

此外，為了滿足某些選項的位置偏移的需求，標準還定義了Pad1 與PadN 選項來進行數據填充。Pad1 選項為固定的一個字節0x00；PadN 選項則符合上述的選項格式，選項類型值為1，通過定義不同的選項長度值來指定選項數據字段的長度，選項數據字段的取值按標準要求應該全部設置為0，但選項數據字段的值可能被中繼節點忽略，所以可被用來填充非0 數據構造隱蔽信道。

2.2.2 路由頭部中的隱蔽信道

過去的研究[1]提出利用類型0 的路由頭部來構建隱蔽信道，類型0 的路由頭部結構如圖3 所示。一種隱蔽信道的構建方式是利用32 比特的保留字段來構建隱蔽信道，二是當段剩余（SegLeft）的值為0 時，同針對未知類型的路由頭部的處理方式一樣，該頭部不會被處理，則該頭部的保留地址以及剩余的地址字段都可以用來存儲信息。

圖3 類型0 路由頭部結構

但是類型0 路由頭部由于會被攻擊者利用發起拒絕服務攻擊，所以在RFC 5095 中規定被棄用，文檔規定對于該類型的路由頭部處理方式與未知類型路由頭部一樣，即若段剩余字段不為0，則數據包被丟棄，若段剩余字段為0，則跳過并繼續處理下一頭部。所以理論上來講，對于路由類型為0 的頭部來說，上述的第二種隱蔽信道構建方式仍然可用。

2.2.3 分段頭部中的隱蔽信道

分段頭部用于對過長的IPv6 數據包進行分段傳輸，以滿足傳輸鏈路的最大傳輸單元（Maximum Transmission Unit，MTU）要求，與IPv4協議不同的是，分片的操作都是由發送報文的源節點完成的。

分段頭部的結構定義如圖4 所示，其中分段偏移長度為13 比特，表示當前數據報文中的數據在完整數據中的偏移位置；1 比特標志位M 表示該分段報文后是否還有后續分段，0 表示該報文為最后一個分段報文，1 表示還有后續分段報文；分段標識則用來區分不同組的分段報文，同一組的分段報文的分段標識應該相同，而不同組的分段標識則互不相同。

圖4 分段頭部的結構定義

標準規定當一個分段內包含完整的數據，即分段偏移的值與標志M 的值均為0 時，該數據報文被接受并被當作一個已經重組完成的報文處理，后續具有相同的分段標識的數據包則被另外重新處理。所以利用此特性，可以構造只有一個分段的分段報文，并利用其中共10 比特的保留字段以及32 比特的分段標識來傳輸數據，構建隱蔽信道。

2.3 隱蔽信道的可用性測試

上文所述的隱蔽信道的構建方式基本上是根據標準文檔中的描述進行分析提出的，但是在實際環境中上述方式是否能夠按照預期方式傳遞信息還未可知，隱蔽信道的可用性還有待測試。本文針對隱蔽信道的可用性在以下兩個方面進行測試：是否影響上層協議正常工作、數據報文是否可達目標。

按照各種隱蔽信道的構建方式，利用Python 的Scapy 庫來構造并發送數據包。對于是否影響上層協議正常工作的測試，在本地的LAN 環境下進行測試，選擇兩臺主機分別作為發送機器與接收機器，通過交換機直接連接，在發送機器中設置上層協議載荷為UDP 協議，在接收機器中則監聽對應的UDP 端口，在接收到隱蔽數據的同時查看應用是否能夠收到UDP 數據。本文分別選擇Ubuntu 20.04 和Windows 10 Build 1909 作為接收機器的系統版本進行了測試。對于報文是否可達目標的測試，主要是為了測試中繼路由節點對于隱蔽傳輸數據包是否會采取丟棄處理，本文分別采用位于兩個國家的虛擬主機進行測試，主機通過IPv6 網絡直接連接，中間會經過多個中繼路由節點，通過在接收機器上對網卡報文進行嗅探監聽，觀察發送機器所發送的報文是否到達。

上文提出了基于IPv6 協議構建隱蔽信道的幾種方式，其中基于IPv6 協議固定頭部的隱蔽信道構建方式共有4 種，分別為利用頭部中的4 個字段：通信流類別、流標簽、載荷長度和跳限制。此外，可以用來構建隱蔽信道的擴展頭部有4 個，分別為逐跳選項頭部、目標選項頭部、路由頭部和分段頭部。其中逐跳選項頭部和目標選項頭部的構建方式相同，都各有2 種，可以利用未知選項和PadN 選項來存儲數據；路由頭部通過構造未知路由類型，并設置段剩余字段為0 來構建隱蔽信道；分段頭部則以單個完整分段數據包的方式利用保留字段和分段標識來存儲數據。上述各種構建方法的測試結果如表1 所示。

本文所描述的幾種隱蔽信道構建方式在Windows系統中均能保證上層協議正常工作；而對于Ubuntu系統來說，在逐跳選項頭部與目標選項頭部中利用PadN 選項構建的隱蔽信道無法保證上層協議正常工作，Linux 內核會丟棄PadN 選項中選項數據不為0 的報文。在報文可達目標的測試中，除了利用逐跳選項頭部構建的隱蔽信道數據報文被丟棄、不能抵達目標外，其他均可以抵達目標。

表1 隱蔽信道的可用性測試結果

3 基于IPv6 協議的隱蔽信道實現

上文討論并驗證了在實際環境中可以真正用來構建隱蔽信道的方式，其中目標選項頭部中的未知選項這一載體相對來說具有更大的帶寬，并且還具有長度可變這一靈活性，所以本文基于此構建方式實現了一種基于IPv6 協議的隱蔽信道。

3.1 隱蔽信道架構

隱蔽信道的架構如圖5 所示，隱蔽信道程序將TCP 客戶端與TCP 服務之間的TCP 通信數據流與IPv6 隱蔽信道傳輸數據流進行轉換，從而完成了一種“透明代理”的模式。隱蔽信道客戶端程序與隱蔽信道服務端程序分別位于兩個不同的網絡內，提供了TCP 數據流與IPv6 隱蔽信道傳輸數據流之間的互相轉換功能。隱蔽信道程序接收來自客戶端或服務端的TCP 數據，并將TCP 數據轉換為隱蔽信道數據報文發送至對端程序，對端程序接收到報文之后進行解析并轉換成TCP 數據流并轉發。

圖5 基于IPv6 協議的隱蔽信道架構

3.2 隱蔽信道協議及實現方式

由于隱蔽信道可能會同時承載來自多個客戶端的TCP 連接，因此在隱蔽信道傳輸的數據流中需要區分不同的TCP 數據流，所以除了實際傳輸的數據部分，隱蔽信道協議中還需要包括控制部分來區分TCP 數據流。基于目標選項頭部中選項的規定格式，隱蔽信道傳輸協議的格式定義如圖6 所示。

由前文所述的選項格式，選項類型長度為1 字節，并且前兩位比特需要為00，使得中繼節點忽略未知選項，所以在未使用的選項類型中設置21 作為控制字段選項類型，22 作為數據字段選項類型。

控制字段選項長度固定為7 字節，其中前4 字節用來存儲發起請求的客戶端的源地址，隨后2 字節用來存儲源端口，最后一個標志字節用來標識數據包的類型。

隱蔽信道可能同時承載來自多個客戶端的TCP會話，為了區分不同的客戶端，采用源地址與源端口作為會話Id，會話Id 在實現中與Socket 關聯，每一個隱蔽信道數據包都會攜帶該信息以使隱蔽信道程序在數據轉發時區分不同的TCP 會話連接。

圖6 隱蔽信道傳輸協議

標志字節的可能取值為0～2，其中0 表示該報文為數據傳輸報文，需要繼續解析數據選項讀取傳輸數據并轉發。而取值為1、2 時，不會攜帶數據，標志字節值為1 表示新建連接，在客戶端新建連接時發送，此時隱蔽信道程序會新建TCP 連接并緩存Socket；標志字節為2 表示關閉該方向TCP 連接，在服務或客戶端關閉連接時發送，雙向連接都被關閉后，緩存的Socket 將被清除。

數據選項的選項長度字段值不固定，根據數據長度確定，此處定義為x，但是由于選項長度字段只有1 字節，因此x 小于或等于255，更長的數據需要進行分包。

此外，由于標準規定IPv6 擴展頭部的長度需要為8 字節的整數倍，因此在最后還要按需添加Pad1 或PadN 選項來滿足長度偏移需求。隱蔽信道數據包的IPv6 上層負載協議可以根據實際情況設置，本文設置為ICMPv6 Echo Reply 類型報文。

3.3 隱蔽信道測試

利用Python 的Scapy 庫編碼實現隱蔽信道，實驗環境如圖7 所示，對隱蔽信道的實際測試在兩臺機器之間進行，兩臺機器的操作系統分別為Ubuntu 20.04 和Windows 10 Build 1909，兩臺機器通過IPv6網絡直接連接。

其中，Ubuntu 機器內安裝有入侵檢測系統Snort（版本2.9.16.1），使用的檢測規則為對應版本注冊規則。

使用netcat 程序利用在兩臺機器之間架設的IPv6 隱蔽信道對一個大小為5MB 的文件進行傳輸測試。傳輸完成用時81s，隱蔽信道的傳輸速率為63kb/s。觀察Snort 程序的日志，也并未產生相關的報警，說明隱蔽信道具有良好的隱蔽性。

圖7 實驗環境示意圖

4 結語

本文基于新的標準文檔研究了利用IPv6 協議構建隱蔽信道的方式，并對提出的隱蔽信道構建方式進行了具體的測試，說明了其在實際環境中的適用性。此外，本文還基于目標選項頭部中的未知選項這一載體提出并實現了一種應用IPv6 隱蔽信道構建的數據傳輸通道，能夠在實際環境中良好運行。

本文所提出的隱蔽信道構建方式可能仍然覆蓋不夠完整，可以繼續深入挖掘協議標準提出新的隱蔽信道構建方式，如新標準還定義了路由擴展頭部的2、3、4 幾種新的路由類型，其中也含有保留字段；所提出的隱蔽信道代理也仍然存在不足，在數據傳輸中的機密性與完整性要求等方面仍然可以提升，可以作為后續工作的方向。