接续《风险剖析：IPv6扩展报头带来的安全隐患（上）》

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网络部署工作继续推进，企业网络安全专业人士必须密切关注。