BGP威胁再现：尼日利亚的一家ISP意外劫持了互联网

栏目: 服务器 · 发布时间: 5年前

内容简介：74分钟里，流向谷歌和Cloudflare服务的流量绕经俄罗斯并进入中国的GFW防火墙系统。2018年11月12日，尼日利亚一家小型互联网服务提供商SP在更新其网络基础设施时犯了个错误，将全球最大科技公司谷歌的流量切断了74分钟，凸显出互联网架构中的一个关键漏洞。

74分钟里，流向谷歌和Cloudflare服务的流量绕经俄罗斯并进入中国的GFW防火墙系统。

2018年11月12日，尼日利亚一家小型互联网服务提供商SP在更新其网络基础设施时犯了个错误，将全球最大科技公司谷歌的流量切断了74分钟，凸显出互联网架构中的一个关键漏洞。

为理解该事件发生的原理，我们需要了解互联网路由的工作机制。假设用户在浏览器中输入网址 Hypothetical.Domain.com 并按下回车键，用户的计算机便创建了一个Web请求，并将该请求发送至 Hypothtetical.Domain.com 服务器。这些服务器放置的位置可能与用户不在同一个国家和地区。因此，用户的互联网服务提供商 (ISP) 必须确定怎样将用户的Web浏览器请求通过互联网路由至正确的服务器。为维护自身路由表，ISP和互联网骨干公司采用了名为边界网关协议 (BGP) 的一套机制。

BGP是一个动态路由协议，能够在变化发生时自动更新路由表。互联网上任意两个节点之间往往不是直接连接的，A点到B点之间的连接通常有多条路径可供选择。BGP的任务就是确定到达任意给定目的网络的最佳（最短）路径，并据此对路由器做出更新。该路径会随路由器的掉线和上线而变更。BGP自动处理所有这些路由器变动情况。

互联网由大量自治系统 (AS) 组成，目前准确的AS数量为63,954个。每一个AS都由互联网编号分配机构 (IANA) 分配一个自治系统号 (ASN) 。ISP至少拥有1个ASN，通常都有多个。谷歌这样的大公司一般都维护有自身的边界路由基础设施和自有ASN。

自制系统与相邻的对等节点 (peer) 形成连接，通过这些连接将自身所知路由（所谓的“网络前缀”）广而告之。邻居节点继续向其他邻居转发路由通告，以便在互联网骨干网上传播这些路由。最终，通过这些路由通告，位于北美的ISP能够了解到通向澳洲某台Web服务器的路由。

起点：尼日利亚互联网交换中心

于是，2018年11月12日究竟发生了什么呢？所有的一切都源于名为尼日利亚互联网交换中心 (IXPN) 的一家机构。互联网交换中心 (IXP) 很常见，尤其是在发展中国家。这些机构为地区性ISP互联提供中心位置，使他们能以较低的带宽消耗共享数据。如果没有IXP，地区性ISP就可能无法直接互联。这意味着地区性ISP之间的流量有可能绕远路，甚至先出个国再绕回来。

IXP也能作为连接远程公司和服务的单点连接点。IXPN事件中，谷歌与合作的尼日利亚ISP维持有对等连接，允许从他们的网络直接连向谷歌的服务。谷歌向其尼日利亚ISP对等节点声明自身网络前缀(路由)，类似于帮他们构建了一条直达高速公路，不需要再绕道欧洲的乡间小路。

这些对等连接协议和路由通告通常只为ISP及其客户的利益而设，所以他们会采用路由过滤器来防止前缀通告意外跑出自身网络范围。如果没有设置路由过滤器，使用BGP的ISP路由器就会继续向互联网上其他邻居传播路由，有可能改变通往谷歌的全球互联网流量路由方式。

下一站：中国

2018年11月12日国际标准时间21:13，尼日利亚 MainOne Cable 公司正在对其路由基础设施进行常规维护。维护过程中，该公司不小心错误配置了路由过滤器，导致212个谷歌前缀和数个Cloudflare前缀被通告给了其他BGP邻居。

作为MainOne的BGP对等节点，中国电信接受了该路由通告，并将之传递给了自己的邻居节点。俄罗斯Transtelecom电信公司也接受了该路由通告并继续传向自己的其他对等节点。截至目前，该路由通告已在互联网上蔓延，很多自制系统都开始接受了。

74分钟里，全球通往谷歌和Cloudflare服务的绝大多数流量都流经俄罗斯、中国，再到尼日利亚的MainOne。Cloudflare很快发现了该问题，并更新了其路由拓扑以进行缓解。但试图访问谷歌服务的很多用户却因为其连接了通向了中国的GFW而遭拦截。其他用户即便能够访问谷歌服务，也因为连接被路由到尼日利亚绕了一圈，而遭受了异乎寻常的延迟等待。

为什么这个问题不可小视？因为该事件凸显出互联网架构中的一个关键漏洞。BGP依赖信任系统。对等节点默认邻居节点通告的是准确的路由。一旦某个邻居开始通告不属于自己的网络前缀，连接拦截和中间人攻击便成为了可能。尼日利亚一家小小的ISP一不小心配错了路由过滤器，都能中断通往IT巨头的网络流量。一场恶意的协同BGP劫持能造成什么影响，大家可以自行想象。

不过，解决办法还是有的。资源公钥基础设施 (RPKI) 采用加密签名来验证BGP路由通告，就像网站采用证书验证一样。路由来源验证 (ROV) 能够确认网络前缀通告来自实际的拥有者。但不幸的是，所有通告的网络前缀中仅有13%采用RPKI，且只有不到1%的自治系统会验证路由通告。如果互联网服务提供商和其他互联网骨干网参与者还不尽快开始采纳这些标准，那下一场BGP劫持就不会是个意外而可能是更糟糕的情况了。