4月24日,据华盛顿邮报和美联社报道,隶属于美国国防部的一个部门Defense Digital Service(简称 DDS),过去三个月,以注册在佛罗里达的 Global Resource Systems LLC 公司(GRS有限公司)名义,使用 BGP(边界网关协议) 向全球路由表宣告了属于美国国防部的地址段。所谓宣告地址,便是让这些地址可以在互联网上直接访问。
既然这些地址属于美国国防部,那他们开个公司在互联网上发布这些地址有什么问题呢?
对遵循网络协议,正常分配内网地址的网络没有影响。然而,使用公网地址的内部网络可能会遇到两个问题:
1. 这种做法,破坏了互联网运行的规则,可能造成内网不能正常访问互联网服务。
2. 配置不完善不安全的网络,会将本来仅限内部的数据包发送到互联网上去。
我们先来探讨一下为什么会出现在内网使用公网地址的现象。
大部分读者都知道国家最近两年在大力推进IPv6,目的是从根本上解决我国 IPv4 地址短缺的情况。IPv4 地址短缺是全世界面对的共同问题,而且不仅仅是互联网上 “公网” IPv4 地址短缺,各个NAT 机制后面的 “私网” IPv4 地址也存在严重的地址短缺,这种现象在大中型网络中更为明显。
下列地址在一月之前只是分配给了美国国防部,并没有使用BGP 向全球宣告。
这些地址范围,包括:
6.0.0.0 - 6.255.255.255
7.0.0.0 - 7.255.255.255
11.0.0.0 - 11.255.255.255
21.0.0.0 - 21.255.255.255
22.0.0.0 - 22.255.255.255
26.0.0.0 - 26.255.255.255
28.0.0.0 - 28.255.255.255
29.0.0.0 - 29.255.255.255
30.0.0.0 - 30.255.255.255
33.0.0.0 - 33.255.255.255
55.0.0.0 - 55.255.255.255
214.0.0.0 - 214.255.255.255
215.0.0.0 - 215.255.255.255
如果你管理一个大中型网络,且内部使用了上述地址,请立即在网络边界阻断对这些地址的访问,详细步骤见后文。
RFC 1918 规定了三个组织内部可以使用的私网地址段分别是:
10.0.0.0 - 10.255.255.255
172.16.0.0 - 172.31.255.255
192.168.0.0 - 192.168.255.255
其中最大 “私网” 地址段10.0.0.0 - 10.255.255.255,是大中型网络的首选。
第一段是 10 不变,第四段一般用于标识一个网络内的主机地址,第二第三段用于标识不同的部门或地理位置,所以第二段第三段合起来确定一个/24 的方便识别的子网。
这样的网络理论上最多承载 2^16 =65536 个子网,现实中的分配则相当粗旷,为了便于人类识别,往往为某个功能块分配几十个 /24 的子网,形如 10.20.20.0/24,10.200.20.0/24。组织结构稍微复杂一点或者经常变动,地址很快就不够分配了。
这时就会有很多网络工程师提出使用 1,2,3,4,5,6,7,8,9,11,20,30,40,50……等等开头看起来特殊的 IP 地址在内网使用。
这就是为什么有些网络内部会出现这些奇怪的地址。
现象1:内网不能正常访问互联网服务
上述地址在互联网上使用 BGP 宣告之前,看起来是没有问题的。然而一旦这些地址开始在互联网上使用或出售继而开始通过BGP 宣告,很快这些地址就会开始承载各种互联网服务。
然而此时,组织内网络配置了这些本应属于公网地址的子网,用户渐渐会发现有一些网站打不开。这是因为数据包在流经内部网络路由器时,受路由条目的影响,在到达互联网出口之前,就被转发到内网对应网段,而这些网段往往是没有用户需要访问的服务的。
最经典的例子莫过于Cloudflare 在 2018 年开始使用 1.1.1.1 提供 DNS 服务,结果发现很多用户无法访问,除了一些运营商的配置问题外,很多网络设备操作系统或默认配置中存在包含1.1.1.1的路由。
现象2:仅限内部的数据包发送到互联网
上述情况仅限于内网对应地址在互联网上提供了业务的情况,而美国国防部在互联网上发布自己的地址,那些地址并没有提供互联网服务,会有什么样的影响呢?
许多配置失误的网络,在同时满足以下几个条件时,本应属于内部的数据包会到达美国国防部控制的GRS 网络:
1. 使用了不属于自己的地址段(此例中是美国军方地址)
2. 内部网络路由表中并没有对应的条目
3. 边界网络设备上并未配置对应的 ACL 或安全策略阻断这些地址
4. 默认路由指向互联网接口,且能访问互联网
5. 上游运营商没有对这些地址做特殊处理
眼尖的读者一定发现了,会有本来目的地在私有网络内的数据包到达美国国防部控制的网络,这存在严重的信息安全风险。
GRS 可以分析进入他们网络的所有数据包:
1. 针对 TCP 会话,可以构建服务器响应客户端握手,进而获得泄漏出来的敏感数据;
2. UDP 是无连接协议,客户端发送敏感数据不需要事先与服务器端握手建立连接;
3. 统计单个原地址发来数据包的目的地址和端口,可以构建该地址对应内网的服务器和端口列表。
根据公开信息,中国一些公有云、私有云和运营商内网中,存在不同程度的使用一些已经分配给国外政府、军队、公司的公网地址。可以想到,内网使用公网地址的模式长期运行,由于误配置造成的敏感数据流向互联网是必然发生的,目前也正在发生。
对于已经在内网开始使用公网地址的网络,网络管理员应该如何补救呢?
1. 检查自己网络的路由表,找出既不属于 RFC1918、RFC3927、RFC6598 定义的地址范围,也不属于互联网运营商或 CNNIC、APNIC 等区域 NIC 分配给自己的公网地址。
2. 如果存在上述地址,补救方案要分为两种情况:
a. 与上级ISP使用BGP互联。在运行BGP的互联网边界路由器上,使用 route-map 等路由策略工具,在与ISP路由器相关的BGP配置中,双向过滤掉上述地址。同时使用黑洞路由在边界设备上将目的地是上述地址的数据包丢弃。
b. 与ISP之间并无BGP关系,只是ISP的终端客户。在边界路由器或防火墙上,配置ACL、安全策略或黑洞路由,在边界设备上将目的地是上述地址的数据包丢弃。
3. 在实施补救方案后,针对内部使用公网地址的情况,选择一个彻底修复的方案:
a. 迁移内部应用到 IPv6,完全避免使用 IPv4 地址。注意IPv6的地址应该是正常渠道申请获得的。如果完全不需要访问互联网,可以使用IPv6 ULA地址段,即fc00::/7 的后半段地址 fd00::/8,使用方法参见 RFC4193。
b. 无法迁移到IPv6或预计使用时间不会超过5~10年的应用,制定IP重新分配规划,过渡期使用NAT帮助平滑过渡。
4. 未来网络地址规划要考虑以下几点:
a. 不要盗用已经分配给他人的 IP 地址
b. 新建网络首选 IPv6 单栈结构
c. 无论 IPv4 还是 IPv6 都应该在二进制边界划分地址段
d. 明确内部地址范围,在网络边界配置安全策略,防止地址伪造和数据泄露
(IANA IPv4 Special-Purpose Address Registry)
(IANA IPv6 Special-Purpose Address Registry)
结语:
IP地址的规划短则影响数年,长则影响数十年。20世纪90年代初的地址分配,在2021年给互联网造成了巨大了影响。然而当时没有人能预计到互联网如此迅猛发展,IPv4地址成为了稀缺资源。
抱着侥幸心理使用他人拥有的地址,破坏了互联网运行的规则,一方面随着当年IPv4地址的转让出售,会形成未来互联互通的障碍,另一方面对自身造成了极大的信息安全风险。
关于 2020 年 6 月份有关美国国防部要出售这些IPv4 地址块的消息及后续:
处理掉IPv4 地址众议院修正案包含一项规定(第1088条)。
这将要求美国国防部在十年时间陆续出售一些IPv4 地址块。
参议院法案中没有类似规定。
众议院退却。
出处:
https://www.congress.gov/congressional-report/116th-congress/house-report/333/1
参考链接:
1.华盛顿邮报报道(订阅用户可用)
https://www.washingtonpost.com/technology/2021/04/24/pentagon-internet-address-mystery/
2.美联社报道 “The big Pentagon internet mystery now partially solved”:
https://apnews.com/article/technology-business-government-and-politics-b26ab809d1e9fdb53314f56299399949
3.NANOG(北美网络工程师讨论组)邮件列表:
https://mailman.nanog.org/pipermail/nanog/2021-March/thread.html#212569
4.给美国国防部的A类地址(维基百科):
https://en.wikipedia.org/wiki/List_of_assigned_/8_IPv4_address_blocks#List_of_
assigned_/8_blocks_to_the_United_States_Department_of_Defense
5.目前GRS在全球路由表中宣告的地址段:
https://bgp.he.net/AS8003#_prefixes
6.Cloudflare 博客《全球修复 1.1.1.1 的可达性》(英文):
https://blog.cloudflare.com/fixing-reachability-to-1-1-1-1-globally/
7.IANA已分配的IPv4地址:
https://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xhtml
8.IPv4 特殊地址:
https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml
9.IPv6 特殊地址:
https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml
10.RFC1918:规定了 10.0.0.0/8,172.16.0.0/12,192.168.0.0/16 三个地址段
11.RFC3927:规定了 IPv4链路本地地址段 169.254.0.0/16
12.RFC6598:规定了 CGNAT使用的 100.64.0.0/10 地址段
13.RFC4193:本地唯一 IPv6 单播地址(英文)
https://tools.ietf.org/html/rfc4193
作者简介:
宋崟川,现就职于 Red Hat。持有微软 Azure 解决方案专家认证,微软 MCSE 核心基础设施认证,红帽系统管理员认证,甲骨文 Solaris 11 系统管理员认证。对中西方信息化基础设施有深入了解和丰富实战经验,尤其对高校信息化发展有独到见解。
特别声明:本站注明稿件来源为其他媒体的文/图等稿件均为转载稿,本站转载出于非商业性的教育和科研之目的,并不意味着赞同其观点或证实其内容的真实性。如转载稿涉及版权等问题,请作者在两周内速来电或来函联系。