随着IPv6网络的部署与应用日益广泛，它所蕴涵的安全问题也值得引起重视。隐蔽信道是一种利用合法协议进行隐蔽数据传输的通信信道，IPv6协议也可以成为隐蔽信道的载体。在研究了最新协议标准下的IPv6隐蔽信道的构建方法，并在实际环境中测试了各种构建方式的可用性后，提出了一种构建IPv6隐蔽信道的具体实现方案，该方案能够有效利用IPv6协议中的扩展头部选项和字段来进行隐蔽的数据传输。
0 引 言
1 研究现状
2 IPv6协议隐蔽传输信道构建方式
2.1 IPv6协议头部中的隐蔽信道
2.2 IPv6扩展头部中的隐蔽信道
2.2.1 逐跳选项头部和目标选项头部中的隐蔽信道
2.2.2 路由头部中的隐蔽信道
2.2.3 分段头部中的隐蔽信道
2.3 隐蔽信道的可用性测试
3 基于IPv6协议的隐蔽信道实现
3.1 隐蔽信道架构
3.2 隐蔽信道协议及实现方式
3.3 隐蔽信道测试
4 结 语
IPv6协议作为取代IPv4协议的新一代网络通信协议，其主要作用是解决IPv4地址资源枯竭的问题。在目前IPv4地址资源日趋耗尽的情况下，拥有更大地址空间范围的IPv6协议势必会逐渐取代IPv4协议，成为主流的网络层通信协议。在这种背景下，IPv6环境下的安全问题也对网络安全提出了新的挑战。隐蔽信道是一种违背系统安全策略的以秘密的形式传送信息的通信通道，它一般利用网络通信的合法数据报文作为载体，对要传输的数据进行编码、嵌入等操作，进行隐秘数据的传输。隐蔽信道会被攻击者利用来绕过流量监测或安全审计等措施，对网络与信息系统造成破坏，如被用在木马或僵尸网络等恶意程序中，来绕过防火墙等安全设备的审查。攻击者一般利用合法的网络协议作为载体来构建隐蔽信道，IPv6协议同样可以成为隐蔽信道的载体，在IPv6协议部署与应用日益广泛的情况下，研究基于IPv6的隐蔽信道对网络安全具有重要意义。隐蔽信道可以被分为存储型隐蔽信道与时间型隐蔽信道，存储型隐蔽信道利用协议中的字段值作为传输载体，而时间型隐蔽信道利用协议报文的传送间隔等时间特性作为传输载体，本文针对基于IPv6协议构建的存储型隐蔽信道进行研究。
IPv6协议标准公布后，一些研究人员对基于IPv6协议的隐蔽信道进行了研究，虽然IPv6协议标准在制定时已经将安全因素考虑在内，但是仍然不能避免对协议的某些字段定义不够严格、对某些字段的定义仍然留有保留位，或规定对字段未定义值默认采取忽略措施等，这都为隐蔽信道的构建提供了良好的载体。
Lucena等人通过对IPv6协议报文标准进行分析，针对IPv6协议固定头部以及六种扩展头部中的字段中存在的保留位等特征，共提出了22种构建隐蔽信道的方式；杨智丹等人分析了IPv6协议标准中的不完善之处，针对保留字段、转发时被节点忽略的字段、定义不完整字段和非关键字段等可隐匿信息的字段提出了共5类19种隐蔽信道的构建方式；郭浩然等人针对IPv6协议固定头部提出了基于数据包操作和基于比特变换的两种隐蔽信道，并基于比特变换的方式以Hop-Limit字段为载体详细阐述了构建隐蔽信道的方式；Mavani等人利用IPv6协议扩展头部中的目标选项头部来构建隐蔽信道，并提出了针对该隐蔽信道的检测方法；Mazurczyk等人则抓取了实际网络中的流量，通过统计IPv6协议中被用来构建隐蔽信道的字段取值分布，和测试安全设备对隐蔽信道的检测情况，分析实际场景中更加隐蔽与实用的信道构建方式。IPv6协议标准自提出以来处在不断的更新迭代之中，上述研究成果部分公布较早，其所参考的IPv6协议标准文档在如今已被更新的标准文档所取代，如在分析IPv6协议头部时被许多文档所参考的文档RFC 2460已被更新的RFC 8200所取代，所以对于隐蔽信道的某些构建方式应该被重新评估。此外，部分研究仅针对隐蔽信道构建方式提出了想法与理论，而缺乏具体的应用实现与在实际环境中的测试，对于基于IPv6协议的隐蔽信道在实际环境中构建与应用情况也值得研究与探讨。IPv6协议数据报文由协议头部、可选的多个扩展头部和上层协议数据组成，由于协议的定义存在不严密的地方，协议头部和扩展头部中的某些字段都能够成为构建隐蔽信道的载体。IPv6协议头部的长度固定为40字节，其最新定义位于RFC 8200中，结构定义如图1所示。
根据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。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协议。经过在Ubuntu 20.04操作系统上测试，默认情况下只有在RFC 8200中定义的四种扩展头部可以被系统识别，对于其他的扩展头部，操作系统将丢弃数据报文并回复错误类型为“未识别的头部类型”的ICMP报文。所以针对扩展头部中构建隐蔽信道的研究将只在逐跳选项头部、目标选项头部、路由头部和分段头部中进行。2.2.1 逐跳选项头部和目标选项头部中的隐蔽信道逐跳选项头部和目标选项头部拥有相同的协议格式，并且它们都携带若干个长度可变的选项，所携带选项的格式定义统一如图2所示，其中选项类型与选项长度字段的长度均为8个比特，选项数据的内容根据不同选项而不同，选型长度字段的值即为选项数据的长度。
选项类型字段的前三位比特具有单独定义，其中前两位比特说明了如果IPv6节点不识别该选项时应采取的措施，若前两位比特设置为00，则表示措施为跳过该选项并继续处理后续数据。后五位比特则用来标识不同选项，而目前未被占用的选项数值的比特范围为10010~11101，所以可以利用此特性来构造不存在的选项并将传输数据填入选项的数据部分来构造隐蔽通道。此外，为了满足某些选项的位置偏移的需求，标准还定义了Pad1与PadN选项来进行数据填充。Pad1选项为固定的一个字节0x00；PadN选项则符合上述的选项格式，选项类型值为1，通过定义不同的选项长度值来指定选项数据字段的长度，选项数据字段的取值按标准要求应该全部设置为0，但选项数据字段的值可能被中继节点忽略，所以可被用来填充非0数据构造隐蔽信道。过去的研究提出利用类型0的路由头部来构建隐蔽信道，类型0的路由头部结构如图3所示。一种隐蔽信道的构建方式是利用32比特的保留字段来构建隐蔽信道，二是当段剩余（SegLeft）的值为0时，同针对未知类型的路由头部的处理方式一样，该头部不会被处理，则该头部的保留地址以及剩余的地址字段都可以用来存储信息。
但是类型0路由头部由于会被攻击者利用发起拒绝服务攻击，所以在RFC 5095中规定被弃用，文档规定对于该类型的路由头部处理方式与未知类型路由头部一样，即若段剩余字段不为0，则数据包被丢弃，若段剩余字段为0，则跳过并继续处理下一头部。所以理论上来讲，对于路由类型为0的头部来说，上述的第二种隐蔽信道构建方式仍然可用。分段头部用于对过长的IPv6数据包进行分段传输，以满足传输链路的最大传输单元（Maximum Transmission Unit，MTU）要求，与IPv4协议不同的是，分片的操作都是由发送报文的源节点完成的。分段头部的结构定义如图4所示，其中分段偏移长度为13比特，表示当前数据报文中的数据在完整数据中的偏移位置；1比特标志位M表示该分段报文后是否还有后续分段，0表示该报文为最后一个分段报文，1表示还有后续分段报文；分段标识则用来区分不同组的分段报文，同一组的分段报文的分段标识应该相同，而不同组的分段标识则互不相同。
标准规定当一个分段内包含完整的数据，即分段偏移的值与标志M的值均为0时，该数据报文被接受并被当作一个已经重组完成的报文处理，后续具有相同的分段标识的数据包则被另外重新处理。所以利用此特性，可以构造只有一个分段的分段报文，并利用其中共10比特的保留字段以及32比特的分段标识来传输数据，构建隐蔽信道。上文所述的隐蔽信道的构建方式基本上是根据标准文档中的描述进行分析提出的，但是在实际环境中上述方式是否能够按照预期方式传递信息还未可知，隐蔽信道的可用性还有待测试。本文针对隐蔽信道的可用性在以下两个方面进行测试：是否影响上层协议正常工作、数据报文是否可达目标。按照各种隐蔽信道的构建方式，利用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的报文。在报文可达目标的测试中，除了利用逐跳选项头部构建的隐蔽信道数据报文被丢弃、不能抵达目标外，其他均可以抵达目标。
上文讨论并验证了在实际环境中可以真正用来构建隐蔽信道的方式，其中目标选项头部中的未知选项这一载体相对来说具有更大的带宽，并且还具有长度可变这一灵活性，所以本文基于此构建方式实现了一种基于IPv6协议的隐蔽信道。
隐蔽信道的架构如图5所示，隐蔽信道程序将TCP客户端与TCP服务之间的TCP通信数据流与IPv6隐蔽信道传输数据流进行转换，从而完成了一种“透明代理”的模式。隐蔽信道客户端程序与隐蔽信道服务端程序分别位于两个不同的网络内，提供了TCP数据流与IPv6隐蔽信道传输数据流之间的互相转换功能。隐蔽信道程序接收来自客户端或服务端的TCP数据，并将TCP数据转换为隐蔽信道数据报文发送至对端程序，对端程序接收到报文之后进行解析并转换成TCP数据流并转发。
由于隐蔽信道可能会同时承载来自多个客户端的TCP连接，因此在隐蔽信道传输的数据流中需要区分不同的TCP数据流，所以除了实际传输的数据部分，隐蔽信道协议中还需要包括控制部分来区分TCP数据流。基于目标选项头部中选项的规定格式，隐蔽信道传输协议的格式定义如图6所示。
由前文所述的选项格式，选项类型长度为1字节，并且前两位比特需要为00，使得中继节点忽略未知选项，所以在未使用的选项类型中设置21作为控制字段选项类型，22作为数据字段选项类型。控制字段选项长度固定为7字节，其中前4字节用来存储发起请求的客户端的源地址，随后2字节用来存储源端口，最后一个标志字节用来标识数据包的类型。隐蔽信道可能同时承载来自多个客户端的TCP会话，为了区分不同的客户端，采用源地址与源端口作为会话Id，会话Id在实现中与Socket关联，每一个隐蔽信道数据包都会携带该信息以使隐蔽信道程序在数据转发时区分不同的TCP会话连接。标志字节的可能取值为0~2，其中0表示该报文为数据传输报文，需要继续解析数据选项读取传输数据并转发。而取值为1、2时，不会携带数据，标志字节值为1表示新建连接，在客户端新建连接时发送，此时隐蔽信道程序会新建TCP连接并缓存Socket；标志字节为2表示关闭该方向TCP连接，在服务或客户端关闭连接时发送，双向连接都被关闭后，缓存的Socket将被清除。数据选项的选项长度字段值不固定，根据数据长度确定，此处定义为x，但是由于选项长度字段只有1字节，因此x小于或等于255，更长的数据需要进行分包。此外，由于标准规定IPv6扩展头部的长度需要为8字节的整数倍，因此在最后还要按需添加Pad1或PadN选项来满足长度偏移需求。隐蔽信道数据包的IPv6上层负载协议可以根据实际情况设置，本文设置为ICMPv6 Echo Reply类型报文。利用Python的Scapy库编码实现隐蔽信道，实验环境如图7所示，对隐蔽信道的实际测试在两台机器之间进行，两台机器的操作系统分别为Ubuntu 20.04和Windows 10 Build 1909，两台机器通过IPv6网络直接连接。
其中，Ubuntu机器内安装有入侵检测系统Snort（版本2.9.16.1），使用的检测规则为对应版本注册规则。使用netcat程序利用在两台机器之间架设的IPv6隐蔽信道对一个大小为5MB的文件进行传输测试。传输完成用时81s，隐蔽信道的传输速率为63kb/s。观察Snort程序的日志，也并未产生相关的报警，说明隐蔽信道具有良好的隐蔽性。
本文基于新的标准文档研究了利用IPv6协议构建隐蔽信道的方式，并对提出的隐蔽信道构建方式进行了具体的测试，说明了其在实际环境中的适用性。此外，本文还基于目标选项头部中的未知选项这一载体提出并实现了一种应用IPv6隐蔽信道构建的数据传输通道，能够在实际环境中良好运行。
本文所提出的隐蔽信道构建方式可能仍然覆盖不够完整，可以继续深入挖掘协议标准提出新的隐蔽信道构建方式，如新标准还定义了路由扩展头部的2、3、4几种新的路由类型，其中也含有保留字段；所提出的隐蔽信道代理也仍然存在不足，在数据传输中的机密性与完整性要求等方面仍然可以提升，可以作为后续工作的方向。
引用本文：赵序琦，孙亮，王轶骏，等. 基于IPv6协议的隐蔽信道构建方法研究[J].通信技术，2021，54（1）：158-163.
