风险剖析：IPv6扩展报头带来的安全隐患

　　IPv6数据包的结构可以让这个下一代网络协议在可预见的未来实现几乎无限的可扩展性。然而，经验表明，这种灵活性是要付出代价的，这个代价就包括安全隐患。在本文中IPv6安全专家Fernando Gont探讨了IPv6扩展报头带来的安全风险以及降低这种风险的方法。

　　当涉及到可扩展性时，IPv4数据包结构有两个主要的限制。

　　首先，IPv4有着有限的选项空间(至多40字节)，这种数据包结构限制了IPv4可部署的扩展的数量和类型。其次，所有IPv4选项(无论是针对路由器还是主机)共享相同的“容器”，这意味着转发IPv4数据包的每个路由器都必须处理所有IPv4选项，以防其中一个选项必须要由IPv4路由器处理。

　　相比之下，IPv6数据包结构则明显不同。对于可扩展性，IPv6选项通过IPv6“扩展报头”来传递，而不是在强制IPv6报头(具有固定大小)。IPv6扩展报头被插入在强制IPv6报头和上层协议报头之间，下图显示了IPv6数据包的结构，包括两个扩展报头。

　　从这个图来看，IPv6数据包遵循“菊花链”的结构，其中每个IPv6扩展报头指定了紧跟的报头类型(通过“Next Header”字段)，并且每个扩展报头指定了自己的长度(或者具有相关的固定长度)。因此，通过从强制IPv6报头开始，并且每次跟随一个扩展报头，整个IPv6报头链可以传输到上层协议报头。下表列出了一些最常见类型的IPv6扩展报头(来自IANA协议编号注册机构)相应的Next Header值：

　　基于将对选项进行处理的节点类型，它们被传递在不同类型的IPv6扩展报头。例如，预计将由到目标沿路径的所有节点处理的选项会放在逐跳选项扩展报头中。而仅由目标节点处理的选项则包含在目的选项扩展报头中。其他扩展报头可能有不同的用途。例如，路由报头用来影响数据包如何转发到目标节点，而分段报头则被用于分段/重组机制。

　　有些扩展报头必须遵循特定顺序。例如，如果有逐跳选项报头，它必须是强制IPv6报头之后的第一个扩展报头。这个概念很简单；在IPv6报头链中，将由到目标沿路径的所有节点处理的扩展报头必须先于仅由目标节点处理的扩展报头。因此，IPv6路由器并不需要处理IPv6报头链中所有报头，而是停止在最后一个扩展报头–其中包含需由IPv6路由器处理的选项。

　　此外，由于逐跳选项报头仅包含必须由数据包传送路径所有节点处理的选项，路由器将不会浪费资源来处理不必要的选项。

　　在IPv6中，所有分段相关的报头字段已经从强制IPv6报头中删除，并移动到(可选)“分段报头”。从概念上讲，原始(或“未分段”)数据包总是在发送节点构建，并只有在那时(如果需要)会进行分段。下图展示了原始IPv6数据包的概念结构：

　　原始数据包由“不可分段部分”和“可分段部分”组成。不可分段部分包括IPv6报头以及必须由到目标节点沿路径所有节点处理的扩展报头，即到路由报头的所有报头(如果存在，也包括路由报头)，或者逐跳选项报头(如果存在)，或者没有扩展报头。而不可分段部分则由其余数据包部分组成；即只能由最终目标节点处理的所有IPv6扩展报头，还有上层报头和数据。不可分段部分将存在于所有产生的片段中，而可分段部分将被分割为多个片段。因此，每个片段是通过“串联”原始数据包的不可分段部分(具有一个分段报头)和一块可分段部分来构建。下图展示了基于上面描述的逻辑数据包如何分割成多个IPv6片段：

　　寻找上层协议信息

　　在IP数据包执行简单访问控制列表(ACL)所需的每个路由器或中间体都必须能够找到上层协议报头，该报头通常包括源和目的地端口号。IPv4的数据包结构让节点可以很容易找到上层协议报头：通过从IPv4报头跳过在IPv4“互联网报头长度”字段所指示的字节数，处理节点可以简单地“跳过”选项空间。

　　然而，在IPv6的情况下，并没有寻找上层协议报头的“线索”。因此，寻找上层协议报头的唯一方法是在强制IPv6报头开始，处理/紧跟IPv6报头链中的每个扩展报头，直到发现最后一个报头。

　　应当指出的是，这个过程曾经更为复杂：IPv6报头链本身可以是分段的，扩展报头和上层协议报头被分成多个片段。因此，无状态设备(即在检查前未执行分段重组的设备)不太可能获取上层协议信息。例如，下面的数据包以前被认为是有效的：

　　幸运的是，2014年年初发布的RFC 7112已经宣布这些数据包为非法，因此最新的部署并不需要担心它们(可以丢弃它们)。

　　IPv6扩展报头的安全隐患

　　IPv6扩展报头的安全隐患通常分为下面几种：

　　· 安全控制规避

　　· 由于处理要求而创造拒绝服务条件

　　· 因为部署错误而创造拒绝服务条件

　　· 每个扩展报头特定的问题

　　正如上文所述，在IPv6数据包中寻找上层协议报头被证明是一项艰巨的任务。更糟糕的是，有些中间体和安全设备希望上层协议报头紧跟强制IPv6报头，因此，当使用IPv6扩展报头时，无法找到或者识别上层协议。例如，这些安全设备或中间体无法认识到下面的数据包是TCP端，这仅仅是因为使用了目的选项扩展报头：

　　这样的原因在于，上述设备不会处理整个IPv6报头链来寻找上层报头，而是假设强制IPv6报头的“下一报头”字段描述/指示了上层协议类型。因此，上述图表中的数据包被认为是“目的选项”数据包，而不是TCP段。

　　如果安全设备采用这种(存在问题的)逻辑，并且已经被配置为执行“默认允许”政策(即允许所有数据包，除非它们符合指定的规则之一)，它们可能将受到规避攻击。这种攻击的简单变体是，数据包采用多个IPv6扩展报头，或者一个大的扩展报头来在多个部署中触发不同的问题。有些部署会限制它们处理的扩展报头的数量，或者对于它们可以检查的关于“多少字节进入IPv6数据包”有着特定的限制。这样的情况可以从下面的图中反映出来：

　　执行一种或两种限制并采用“默认允许”政策的部署也容易受到规避攻击。而某些极端情况数据包处理的模糊性则代表着规避安全控制的另一种可能。

　　通过隐藏上层协议类型(正如上文所述)或者隐藏应用数据流，IPv6分段还可以被利用来执行规避攻击。在过去的几年中，我们发现很多部署容易受到这些规避技术的攻击。例如，RFC 7113在RA-Guard事件中描述了这个问题，相同的技术还可以用于绕过某些IPv6防火墙。此外，有些数据包处理方式的不一致可能导致安全控制规避，正如思科公司的Panos Kampanakis和研究人员Antonios Atlasis所指出的。

　　IPv6扩展报头可能对设备处理产生负面的性能影响。虽然这可能似乎不像一个安全问题，但这也需要慎重考虑。例如，IPv6路由器部署通常处理在软件(而不是硬件)中包含逐跳选项扩展报头的数据包，其他IPv6路由器部署则处理在软件中部署IPv6扩展报头(当它们被配置为执行ACL时)的数据包。这意味着，除非有适当的缓解措施(例如数据包过滤/或对采用扩展报头的数据包的限速)，攻击者可能会通过简单地发送大量采用IPv6扩展报头的IPv6流量来执行拒绝服务(DoS)攻击。

　　虽然IPv6协议本身(以及很多部署)已经存在很多年，最近在很多部署中发现了IPv6扩展报头处理过程中的漏洞问题。发现这些漏洞的可能原因在于，大多数扩展报头并没有真正部署在现实世界的流量中，从而很少使用相应的代码。出于这个原因，在有些部署中发现IPv6扩展报头的处理中仍然存在漏洞并不令人惊讶。

　　最后，除了IPv6扩展报头的一般安全隐患外，每个扩展报头类型往往都有着自己特定的安全问题。例如，安全研究人员在2007年报道如何使用路由报头Type 0(现在已经过时)来执行DoS攻击。另一个具有安全隐患的扩展报头是Fragment Header，它用于IPv6的分段/重组功能。虽然分段/重组机制的很多安全隐患在IPv4领域已经很有名，但现在很多相关问题已经悄悄潜入IPv6部署，从DoS攻击到信息泄露或规避攻击(详情请参与笔者最近对可预测片段标识值的IETF草案和Antonios Atlasis在2012年欧洲黑帽大会的展示)。

　　结论

　　很多(如果不是大多数)源自IPv6扩展报头的安全问题往往与如何部署相应的支持有关：从有漏洞的代码，到在软件(而不是硬件)中处理扩展报头的设备。有些部署可能提供缓解技术，例如对采用IPv6扩展报头的数据包进行限速(在创造DoS条件之前丢弃多余的流量)。在其他情况下，管理员可能没有其他选择，只能过滤相应的流量。显然这是值得关注的领域，随着IPv6网络部署工作继续推进，企业网络安全专业人士必须密切关注。