mirror of
https://github.com/LCTT/TranslateProject.git
synced 2025-01-07 22:11:09 +08:00
61 lines
7.6 KiB
Markdown
61 lines
7.6 KiB
Markdown
发行版分发者应该禁用 IPv4 映射的 IPv6 地址吗
|
||
=============================================
|
||
|
||
大家都说，互联网向 IPv6 的过渡是件很缓慢的事情。不过在最近几年，可能是由于 IPv4 地址资源的枯竭，IPv6 的使用处于[上升态势][1]。相应的，开发者也有兴趣确保软件能在 IPv4 和 IPv6 下工作。但是，正如近期 OpenBSD 邮件列表的讨论所关注的，一个使得向 IPv6 转换更加轻松的机制设计同时也可能导致网络更不安全——并且 Linux 发行版们的默认配置可能并不安全。
|
||
|
||
### 地址映射
|
||
|
||
IPv6 在很多方面看起来可能很像 IPv4，但它是带有不同地址空间的不同的协议。服务器程序想要接受使用二者之中任意一个协议的连接，必须给两个不同的地址族分别打开一个套接字——IPv4 的 AF_INET 和 IPv6 的 AF_INET6。特别是一个程序希望接受使用任意协议到任意主机接口的连接的话，需要创建一个绑定到全零通配符地址（0.0.0.0）的 AF_INET 套接字和一个绑定到 IPv6 等效地址（写作“::”）的 AF_INET6 套接字。它必须在两个套接字上都监听连接——或者有人会这么认为。
|
||
|
||
多年前，在 [RFC 3493][2]，IETF 指定了一个机制，程序可以使用一个单独的 IPv6 套接字工作在两个协议之上。有了一个启用这个行为的套接字，程序只需要绑定到 :: 来接受使用这两个协议到达所有接口的连接。当创建了一个 IPv4 连接到绑定端口，源地址会像 [RFC 2373][3] 中描述的那样映射到 IPv6。所以，举个例子，一个使用了这个模式的程序会将一个 192.168.1.1 的传入连接看作来自 ::ffff:192.168.1.1（这个混合的写法就是这种地址通常的写法）。程序也能通过相同的映射方法打开一个到 IPv4 地址的连接。
|
||
|
||
RFC 要求这个行为要默认实现，所以大多数系统这么做了。不过也有些例外，OpenBSD 就是其中之一；在那里，希望在两种协议下工作的程序能做的只能是创建两个独立的套接字。但一个在 Linux 中打开两个套接字的程序会遇到麻烦：IPv4 和 IPv6 套接字都会尝试绑定到 IPv4 地址，所以不论是哪个后者都会失败。换句话说，一个绑定到 :: 指定端口的套接字的程序会同时绑定到 IPv6 :: 和 IPv4 0.0.0.0 地址的那个端口上。如果程序之后尝试绑定一个 IPv4 套接字到 0.0.0.0 的相同端口上时，这个操作会失败，因为这个端口已经被绑定了。
|
||
|
||
当然有个办法可以解决这个问题；程序可以调用 setsockopt() 来打开 IPV6_V6ONLY 选项。一个打开两个套接字并且设置了 IPV6_V6ONLY 的程序应该可以在所有的系统间移植。
|
||
|
||
读者们可能对不是每个程序都能正确处理这一问题没那么震惊。事实证明，这些程序的其中之一是网络时间协议（Network Time Protocol）的 [OpenNTPD][4] 实现。Brent Cook 最近给上游 OpenNTPD 源码[提交了一个小补丁][5]，添加了必要的 setsockopt() 调用，它也被提交到了 OpenBSD 中了。尽管那个补丁看起来不大可能被接受，最可能是因为 OpenBSD 式的理由（LCTT 译注：如前文提到的，OpenBSD 并不受这个问题的影响）。
|
||
|
||
### 安全担忧
|
||
|
||
正如上文所提到，OpenBSD 根本不支持 IPv4 映射的 IPv6 套接字。即使一个程序试着通过将 IPV6_V6ONLY 选项设置为 0 显式地启用地址映射，它的作者会感到沮丧，因为这个设置在 OpenBSD 系统中无效。这个决定背后的原因是这个映射带来了一些安全担忧。攻击打开接口的攻击类型有很多种，但它们最后都会回到规定的两个途径到达相同的端口，每个端口都有它自己的控制规则。
|
||
|
||
任何给定的服务器系统可能都设置了防火墙规则，描述端口的允许访问权限。也许还会有适当的机制，比如 TCP wrappers 或一个基于 BPF 的过滤器，或一个网络上的路由可以做连接状态协议过滤。结果可能是导致防火墙保护和潜在的所有类型的混乱连接之间的缺口导致同一 IPv4 地址可以通过两个不同的协议到达。如果地址映射是在网络边界完成的，情况甚至会变得更加复杂；参看[这个 2003 年的 RFC 草案][6]，它描述了如果映射地址在主机之间传送，一些随之而来的其它攻击场景。
|
||
|
||
改变系统和软件合适地处理 IPv4 映射的 IPv6 地址当然可以实现。但那增加了系统的整体复杂度，并且可以确定这个改动没有实际完整实现到它应该实现的范围内。如同 Theo de Raadt [说的][7]：
|
||
|
||
**有时候人们将一个坏主意放进了 RFC。之后他们发现不可能将这个主意扔回垃圾箱了。结果就是概念变得如此复杂，每个人都得在管理和编码方面是个全职专家。**
|
||
|
||
我们也根本不清楚这些全职专家有多少在实际配置使用 IPv4 映射的 IPv6 地址的系统和网络。
|
||
|
||
有人可能会说，尽管 IPv4 映射的 IPv6 地址造成了安全危险，更改一下程序让它关闭部署实现它的系统上的地址映射应该没什么危害。但 Theo 认为不应该这么做，有两个理由。第一个是有许多破损的程序，它们永远不会被修复。但实际的原因是给发行版分发者压力去默认关闭地址映射。正如他说的：“**最终有人会理解这个危害是系统性的，并更改系统默认行为使之‘secure by default’**。”
|
||
|
||
### Linux 上的地址映射
|
||
|
||
在 Linux 系统，地址映射由一个叫做 net.ipv6.bindv6only 的 sysctl 开关控制；它默认设置为 0（启用地址映射）。管理员（或发行版分发者）可以通过将它设置为 1 关闭地址映射，但在部署这样一个系统到生产环境之前最好确认软件都能正常工作。一个快速调查显示没有哪个主要发行版分发者改变这个默认值；Debian 在 2009 年的 “squeeze” 中[改变了这个默认值][9]，但这个改动破坏了足够多的软件包（比如[任何包含 Java 的][10]），[在经过了一定数量的 Debian 式讨论之后][11]，它恢复到了原来的设置。看上去不少程序依赖于默认启用地址映射。
|
||
|
||
OpenBSD 有自由以“secure by default”的名义打破其核心系统之外的东西；Linux 发行版分发者倾向于更难以作出这样的改变。所以那些一般不愿意收到他们用户的不满的发行版分发者，不太可能很快对 bindv6only 的默认设置作出改变。好消息是这个功能作为默认已经很多年了，但很难找到利用的例子。但是，正如我们都知道的，谁都无法保证这样的利用不可能发生。
|
||
|
||
|
||
--------------------------------------------------------------------------------
|
||
|
||
via: https://lwn.net/Articles/688462/
|
||
|
||
作者：[Jonathan Corbet][a]
|
||
译者：[alim0x](https://github.com/alim0x)
|
||
校对：[校对者ID](https://github.com/校对者ID)
|
||
|
||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||
|
||
[a]: https://lwn.net/
|
||
[1]: https://www.google.com/intl/en/ipv6/statistics.html
|
||
[2]: https://tools.ietf.org/html/rfc3493#section-3.7
|
||
[3]: https://tools.ietf.org/html/rfc2373#page-10
|
||
[4]: https://github.com/openntpd-portable/
|
||
[5]: https://lwn.net/Articles/688464/
|
||
[6]: https://tools.ietf.org/html/draft-itojun-v6ops-v4mapped-harmful-02
|
||
[7]: https://lwn.net/Articles/688465/
|
||
[8]: https://lwn.net/Articles/688466/
|
||
[9]: https://lists.debian.org/debian-devel/2009/10/msg00541.html
|
||
[10]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=560056
|
||
[11]: https://lists.debian.org/debian-devel/2010/04/msg00099.html
|