Research on Security Protection Evasion Mechanism Based on IPv6 Fragment Headers

基于IPv6分片头的安全保护逃逸机制

摘要

IPv6分片头是数据包分片的关键，但可以被利用来逃避安全系统，构成实质性的威胁。

尽管RFC-7112强调了“IPv6分片逃避行为”的含义，但缺乏全面的评估，阻碍了对标准符合性的评估。

同时，现有的IPv6分片逃避行为主要集中在微小/重叠的分片上，忽略了其他IPv6扩展头的组合。

因此，论文提出了一个IPv6分片回避（FragEva6）行为模型，演示了从IPv6报头到FragEva6机制的逐步构建过程。

随后，对17个主流操作系统和4个安全系统的评估显示，最新版本的Windows和Apple操作系统在处理IPv6碎片时符合RFC 7112，而Linux操作系统则表现出部分不符合。

此外，安全系统（Windows Defender 20230503.1、ip6tables 1.8.9、Suricata v6.0.12和Snort v3.1.61.0）表现出的缓解措施不足，使它们容易受到通过操纵IPv6片段报头逃避威胁的影响。

最后，为了说明这些行为的严重性，本研究实现了基于FragEva6机制的链路上主机扫描活动，成功地避开了防火墙并引发了目标响应。。

1. 背景

1.1 IPv6分片首部

IPv6报文中有一个8比特的字段：下一个首部。

在互联网地址编码分配机构（Internet Assigned Numbers Authority，IANA）的Protocol Number
中规定了IPv6分片的字段值为：44，它代表了网络层对数据进行了分片操作。

一个IPv6的分片首部总共8字节，具体结构如下：

下一个首部8位|保留8位|分片偏移13位|保留（Res）2位|M（1位）|标识符（32位）

• 保留字段和Res字段：保留字段和Res都是保留字段，设置为零。
  （同样这里也存在安全问题，因为可以利用这个字段传递信息而不被人关注。）

• 下一个首部：标识分片承载的选项或者上层协议，可以是选项DOH或者协议ICMP，上层协议TCP等等。它是引发安全问题的原因，因为防火墙检测将检查此字段字段以判断报文是否合法。

• M字段：表明该分片是否为原始数据报的最后一个分片。与IPv4一样。
  如果值为1，代表有更多的分片，如果值为0，代表最后一个分片。

• 标识字段：用于标识这些分片属于同一个，方便网络层重新将它们组装起来。

• 分片偏移：以8字节为单位，相当于标识顺序，因为分片可能不按照顺序到达。
  第一个分片offset为0，第二一般是181，因为如果数据包需要分片，那么ip头和分片头48字节加181*8字节刚好1496字节，再多一个就超过MTU的1500字节了。

一个典型的分段操作如下：

1.2 现有FragEva6行为

根据RFC 7112，第一个片段应该包含完整的上层协议的报头。

比如在图2中，它的分片1需要包含整个上层协议的报头。

但是FragEva6违反了这一要求，它将完整的上层报头分散到不同的片段中，例如，它可能出现在Fig2的分片2或3中。

现有关于FragEva6机制的文献主要集中在微小片段逃避和重叠片段逃避行为上。

1.2.1 微小碎片逃避行为

在图1场景中，防火墙拦截来自任何源的ICMPv6 Echo Request报文到主机b。如图3所示，攻击者为了达到目的，将一个1280字节的IPv6报文按照56字节的MTU进行拆分，IPv6报头和分片扩展头占据48字节，因此数据部分只有8字节，导致上层报头链被限制在IPv6报头链的第155个分片。ICMPv6头只能存在于第155个片段中。由于中间防火墙设备仅限于检查第一个分片，只能发现DOH字段，无法识别上层ICMPv6信息，因此产生了利用微小片段的逃避行为。

关于DOH，在IANA的Protocol Nunmer中可以看到这个选项。

Destination Options报头用于承载仅需要由数据包的目的地节点检查的可选信息。
下一个首部同样遵循IANA的Protocol Number。所以DOH更像一个选项，向IPv4中的选项一样，而不是一个上层协议。

1.2.2 重叠分片逃避行为

当攻击者精心构建多个分片数据包共享相同的分片标识时，重叠分片就会出现。由于故意配置错误的片段偏移字段值，这些数据包显示片段之间的字节重叠。在目的主机的重组过程中，后续分片中非法重叠的数据可能会覆盖之前分片中对应的数据。

在图1的场景中，攻击者发送到目标主机的第一个片段包含一个DOH头，而第二个片段包含一个与第一个片段重叠的ICMPv6上层头，如图4所示。在主机接收分片后使用ICMPv6报头将DOH报头覆盖。由于中间防火墙设备只能检测第一个分片报文，无法检测到分片重叠或是否存在ICMPv6上层信息，从而导致规避行为。

1.3 当前工作的局限

目前对IPv6分片规避机制的研究有限，主要集中在不符合rfc标准的分片报文上，如微小分片和重叠分片。

此外，缺乏对这个问题进行实际检查和测试的模型或工具。

为此，本文首次提出了IPv6分片逃避行为的构造模型FragEva6。该模型集成了其他IPv6扩展报头，以扩展现有的FragEva6行为类型。

2. 介绍

IPv6报文下一个首部的引入增强了可扩展性，但同时也产生了许多安全问题。

IPv6下一个首部的分片首部被证明存在漏洞：如重叠碎片和微小碎片，对互联网构成多方面的威胁：拒绝服务（DoS），操作系统（OS）指纹识别和入侵检测系统（IDS）规避等。

微小片段（违反RFC-2460）和重叠片段（违反RFC-5722），这些片段很容易逃避Snort或Suricata等流行的IDS。认识到解决这些基于IPv6片段的威胁的迫切需要，提出了征求意见RFC-7112。

关于RFC-7112

RFC2460的更新，要求所有报头（从IPv6基本报头开始，一直到上层报头（例如TCP等））都出现在第一个片段中。因为防火墙检测第一个分片中的上层协议信息，如果没有上层协议的报头，那么可能造成安全威胁。
RFC-7112旨在解决过长的IPv6报头链的安全问题。攻击者滥用IPv6分片机制将报头链分割成多个片段，通常留下的第一个片段缺乏关键的上层报头信息，如TCP（传输控制协议）或ICMPv6（互联网控制消息协议版本6）报头。安全系统通常只检查第一个分片中的上层信息，使得隐藏在后面数据包中的恶意数据难以检测。这些看似无害的碎片一旦在主机层面重新组装，就可以对目标主机执行DoS等威胁。图1是一个使用IPv6分片机制规避防火墙的示例。本研究提出了IPv6分片逃避行为等问题，具体表示为FragEva6行为。

RFC 7112建议目的主机丢弃这些上层报头信息不完整的IPv6分片，以对抗FragEva6驱动的威胁。

关于RFC-5722

阐述如何处理重叠的分片。

基本IPv6规范中指定的碎片和重组算法允许碎片重叠。

本文档演示了与允许重叠片段相关的安全问题，并更新了IPv6规范以明确禁止重叠片段。

传输需要分段的数据报的IPv6节点不得创建重叠的分段。在重新组装IPv6数据报时，如果确定其一个或多个组成片段是重叠片段，则必须无声地丢弃整个数据报（以及任何组成片段，包括尚未接收到的片段）。

2.2 论文工作

• 扩展FragEva6的行为与机制
• 开发了一组测试套件
• 对操作系统和安全系统进行实验并做了评估
• 利用FragEva6实现主机扫描

3. FragEva6行为的建模与机制

3.1 Frageva6行为的建模与机制

为了阐明分片逃避行为的机制，提出FragEva6行为的模型，如图5所示。

（S1到S4象征着对手通过IPv6扩展头制作行为过程中的4个阶段。
状态之间的箭头表示每个步骤中的特定操作，驱动行为状态的转换。）

起始状态S1由IPv6基本报头组成。

步骤1添加IPv6分片头，也就是将将IPv6报头的下一个首部字段设置为44，过渡到状态S2。

步骤2包含额外的IPv6扩展头，如将分片头中下一个首部字段设置为DOH，达到状态S3。

最后，步骤3追加上层报头，如将分片中的头中的下一个首部字段设置为ICMP，最终达到最终状态S4，包含FragEva6包。

3.1.1 步骤1：添加IPv6分片头

下面两段的意思基本是，分片大小原则上不会影响实验，因为RFC没有规定分片就必须大于等于1280字节。但是，可能不同的安全系统对这个分片大小可能不一样，所以为了严谨性将两者分开。

• 微小分片逃避行为：微小的分片本身没有固有的问题，RFC指南也没有规定IPv6应该如何管理小于1280字节的数据包。但是逃避行为利用了较小的MTU的属性，将出站数据包划分为极小的长度，从而将对防火墙或IDS检测至关重要的上层数据替换为后续的分片。
• 超大分片规避行为：超大分片是指分片长度大于等于1280字节。类似于基于微小片段的逃避的基本原理，IPv6超大片段逃避行为利用IPv6扩展报头的属性在恶意数据包中嵌入大量扩展报头选项（例如，DOH报头包含许多PadN选项），增加数据包长度并触发碎片。这种策略将数据包的上层报头数据重新定位到后续的片段中，从而便于逃避。

3.1.2 步骤2：添加其他IPv6扩展头

下面四种方式都有可能绕过安全机制

• A：不超过2个DOH头的可分割部分
• B：基于IPv6扩展头的重叠分片
• C：包含大量相同类型的扩展头的片段逃避行为
• D：包含多种不同类型扩展头的片段逃避行为
  在步骤2之后，FragEva6行为已经创建了IPv6报头、IPv6分片报头和其他扩展报头。为了实现FragEva6行为，必须通过添加真正的上层报头来完成步骤3。

3.1.3 步骤3：添加上层表头

在IPv6中，“下一个报头”字段用于识别后续扩展报头的类型，攻击者可以利用这种机制来隐藏上层报头的性质，并增加片段逃避行为的复杂性。受RFC 7113的启发，本研究根据第一个片段中上层报头标识符的表现，将分片逃避行为分为两类。

• 已知上层报头协议类型的逃避行为：在这种分片报文中，攻击者可以使用分片报头和其他扩展报头来隐藏上层报头的协议类型（如ICMPv6）。图6中的原始数据包包含完整的IPv6报头链，顶部有一个ICMPv6报头作为上层报头。值得注意的是，第一个片段中的最后一个“下一个报头”字段被赋值为58，表明ICMPv6（一种已知的上层报头协议类型），而ICMPv6报头出现在第二个片段中。
  

• 上层报头协议类型未知的逃避行为：在这样的分片报文中，攻击者隐藏了上层报头的协议类型。导致中间设备无法识别上层报头的类型。图7中的原始数据包包含完整的IPv6报头链，上层报头的协议类型为ICMPv6。第一个片段中的最后一个“下一个报头”字段被赋值为60，表示DOH报头（不是上层报头），而实际的ICMPv6报头出现在第二个片段中。因此，第一个分片没有上层报头的协议类型。
  

3.1.4 测试套件实现

由于缺乏对FragEva6机制的研究和缺乏公开的测试工具，作者创建了一个基于第三节中描述的FragEva6行为模型的测试套件（FragEva6- build）。

表1列出了测试用例。

4. 测试和评估FragEva6行为

4.1 FragEva6行为的测试与评估策略

4.1.1 实验一：主流操作系统的规范性测试

对流行操作系统中的内核协议栈进行了严格的测试，以验证它们是否符合RFC 7112中规定的IPv6分片处理指南。

对于Linux系统的测试可以发现，操作系统对于上层协议unknown的分片都没有防护。

Windows操作系统相对好的多，但是对于较低版本的系统缺乏支持。

4.1.2 实验2：安全防护系统评估和威胁验证

对于在内核级别没有充分执行RFC 7112的操作系统，我们研究了防火墙等安全解决方案，当配置了全面的规则集时，是否可以有效地拦截利用FragEva6机制的恶意尝试，并证实FragEva6威胁的存在。

Linux和一些windows 11之前的系统对RFC标准的遵守程度有限，而苹果的操作系统则完全符合。
因此，本节将评估Windows Defender 20230503.1 （Windows）、ip6tables 1.8.9 （Linux）和顶级支持ipv6的开源IDS: Suricata v6.0.12和Snort v3.1.61.0。

默认的Linux防火墙ip6tables对FragEva6威胁的处理不是最优的，它只拦截那些上层报头中已知协议类型的数据包，而对未知协议类型的数据包失败。

Windows Defender， Windows默认防火墙，成功地阻止了所有测试的威胁。这表明，尽管在Windows 11之前的一些系统对RFC标准的支持较低，但当安全人员配置了适当的规则时，Windows Defender可以有效地防范基于IPv6分片报头的威胁。

Suricata可以有效地检测到所有基于icmpv6的情况，但在TCP方面表现不佳，只能识别A1。这可能源于它对TCP碎片处理不当，阻碍了威胁识别。

Snort无法拦截任何威胁，这表明FragEva6完全逃避了其规则，从而使其无效。

4.1.3 实验三：IDS对FragEva6行为的检测能力

认识到潜在的防火墙漏洞和操作系统在丢弃恶意数据包方面的限制，我们评估了使用其默认规则集的IDS是否能够准确识别并主动阻止使用FragEva6机制制作的潜在威胁数据包。

从实验结果的分析来看，Suricata触发4个警报，Snort触发2个警报。这些警告主要强调IPv6扩展报头使用中的违规行为，例如重复使用DOH报头和RH报头，这违反了标准的RFC一致性或代表非常规的数据包结构。