做字素的网站,wordpress get option,建筑行业网站有哪些,自媒体视频发布平台从各方面来看#xff0c;互联网向 IPv6 的过渡是件很缓慢的事情。不过在最近几年#xff0c;可能是由于 IPv4 地址资源的枯竭#xff0c;IPv6 的使用处于上升态势。相应的#xff0c;开发者也有兴趣确保软件能在 IPv4 和 IPv6 下工作。但是#xff0c;正如近期 OpenBSD 邮…从各方面来看互联网向 IPv6 的过渡是件很缓慢的事情。不过在最近几年可能是由于 IPv4 地址资源的枯竭IPv6 的使用处于上升态势。相应的开发者也有兴趣确保软件能在 IPv4 和 IPv6 下工作。但是正如近期 OpenBSD 邮件列表中的讨论所关注的一个使得向 IPv6 转换更加轻松的机制设计同时也可能导致网络更不安全——并且 Linux 发行版们的默认配置可能并不安全。地址映射IPv6 在很多方面看起来可能很像 IPv4但它是一个不同地址空间的不同的协议。服务器程序想要接受使用二者之中任意一个协议的连接必须给两个不同的地址族分别打开一个套接字——IPv4 的 AF_INET 和 IPv6 的 AF_INET6。特别是一个程序希望在主机上的使用两种地址协议的任意接口都接受连接的话需要创建一个绑定到全零通配符地址(0.0.0.0)的 AF_INET 套接字和一个绑定到 IPv6 等效地址(写作 ::)的 AF_INET6 套接字。它必须在两个套接字上都监听连接——或者有人会这么认为。多年前在 RFC 3493IETF 指定了一个机制程序可以使用一个单独的 IPv6 套接字工作在两个协议之上。有了一个启用这个行为的套接字程序只需要绑定到 :: 地址从而在所有接口上接受使用这两个协议的连接。当创建了一个 IPv4 连接到该绑定端口源地址会像 RFC 2373 中描述的那样映射到 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 实现。Brent Cook 最近给上游 OpenNTPD 源码提交了一个小补丁添加了必要的 setsockopt() 调用它也被提交到了 OpenBSD 中了。不过那个补丁看起来不大可能被接受最可能的原因是因为 OpenBSD 式的理由(LCTT 译注如前文提到的OpenBSD 并不受这个问题的影响)。安全担忧正如上文所提到OpenBSD 根本不支持 IPv4 映射的 IPv6 套接字。即使一个程序试着通过将 IPV6_V6ONLY 选项设置为 0 来显式地启用地址映射它的作者也会感到沮丧因为这个设置在 OpenBSD 系统中无效。这个决定背后的原因是这个映射带来了一些安全隐忧。攻击打开的接口的攻击类型有很多种但它们最后都会回到规定的两个途径到达相同的端口每个端口都有它自己的控制规则。任何给定的服务器系统可能都设置了防火墙规则描述端口的允许访问权限。也许还会有适当的机制比如 TCP wrappers 或一个基于 BPF 的过滤器或一个网络上的路由器可以做连接状态协议过滤。结果可能是导致防火墙保护和潜在的所有类型的混乱连接之间的缺口造成同一 IPv4 地址可以通过两个不同的协议到达。如果地址映射是在网络边界完成的情况甚至会变得更加复杂参看这个 2003 年的 RFC 草案它描述了如果映射地址在主机之间传播一些随之而来的其它攻击场景。改变系统和软件正确地处理 IPv4 映射的 IPv6 地址当然可以实现。但那增加了系统的整体复杂度并且可以确定这个改动没有实际地完整实现到它应该实现的范围内。如同 Theo de Raadt 说的有时候人们将一个糟糕的想法放进了 RFC。之后他们发现这个想法是不可能的就将它丢回垃圾箱了。结果就是概念变得如此复杂每个人都得在管理和编码方面是个全职专家。我们也根本不清楚这些全职专家有多少在实际配置使用 IPv4 映射的 IPv6 地址的系统和网络。有人可能会说尽管 IPv4 映射的 IPv6 地址造成了安全危险更改一下程序让它在实现了地址映射的系统上关闭地址映射应该没什么危害。但 Theo 认为不应该这么做有两个理由。第一个是有许多破旧的程序它们永远不会被修复。而实际的原因是给发行版们施加了压力去默认关闭地址映射。正如他说的“最终有人会理解这个危害是系统性的并更改系统默认行为使之‘secure by default’。”Linux 上的地址映射在 Linux 系统地址映射由一个叫做 net.ipv6.bindv6only 的 sysctl 开关控制它默认设置为 0(启用地址映射)。管理员(或发行版们)可以通过将它设置为 1 来关闭地址映射但在部署这样一个系统到生产环境之前最好确认软件都能正常工作。一个快速调查显示没有哪个主要发行版改变这个默认值Debian 在 2009 年的 “squeeze” 中改变了这个默认值但这个改动破坏了很多的软件包(比如任何包含 Java 的程序)在经过了几次的 Debian 式的讨论之后它恢复到了原来的设置。看上去不少程序依赖于默认启用地址映射。OpenBSD 有以“secure by default”的名义打破其核心系统之外的东西的传统而 Linux 发行版们则更倾向于难以作出这样的改变。所以那些一般不愿意收到他们用户的不满的发行版们不太可能很快对 bindv6only 的默认设置作出改变。好消息是这个功能作为默认已经很多年了但很难找到被利用的例子。但是正如我们都知道的谁都无法保证这样的利用不可能发生。本文由 LCTT 原创编译Linux中国 荣誉推出