管理员配置失误：全球路由系统脆弱的一环

BGP（边界网关协议）是互联网事实上的域间路由协议，它是一个去中心化的协议，各个AS（自治系统）通过BGP协议交换路由信息，来保证互联网的路由可达性。

BGP一大缺陷是AS之间传递的路由信息缺乏验证机制，错误的路由信息会导致很多网络异常，最直接的后果就是网络不可达。

早期互联网是由几个主要的核心AS和一些边缘AS构成，各个AS之间相互可信，并没有考虑路由信息真实性验证的问题。

而如今，互联网上已经有近8万个遍布全世界的可路由AS，很难保证每个AS通告的路由信息都是真实的。

一方面，网络管理员由于配置失误可能会导致一些错误的路由信息的产生，进而导致网路故障。另一方面，攻击者可以精心构造一些错误路由让互联网上的流量去往攻击者想要去的地方，这就是BGP劫持。

RPKI和BGPSEC是通过密码学来保证BGP报文的真实性来解决这一问题的，但是RPKI正在缓慢部署，BGPSEC仍处于理论阶段，IETF的SIDR工作组一直在推进相关工作的进行。

在RPKI和BPGSEC尚未完全部署之前，BGP的一些异常事件的检测就变得尤为关键，快速准确的BGP异常检测系统能让管理员及时发现问题，从而减少损失。

BGPwatch是由清华大学网络研究院Dragonlab实验室开发的BGP劫持监测系统。据我们所知，这是国内首个开放的实时BGP异常监测系统。

BGPwatch使用丰富的先验领域知识，结合多种规则筛选出可疑的MOAS事件，同时根据受影响前缀对事件危害程度评级。

系统经过一段时间的正常运行，已经发现了2起中规模劫持事件和大量的小规模劫持事件，通过分析，我们也发现了一些由于配置错误所引发的事件。

通过与其他业界知名路由监测平台（Cisco bgpstream和CAIDA HI3 Observatory）综合比较，BGPwatch在实时性、检测的覆盖率和准确率上具有一定的优势。

一起BGP劫持事件

近期，BGPwatch通告了一起和AS18241（国家电网）有关的劫持事件（图1），持续时间为10分钟左右。（事件URL：BGP Watch (cgtf.net) ）

图1 BGPwatch通告了一起和AS18241有关的劫持事件

警告显示，北京时间2021年11月29日16:31分开始，AS18241（国家电网）的三条前缀：210.77.176.0./24，210.77.177.0/24和210.77.178.0/24被菲律宾AS18214（TELUS-INTERNATIONAL）劫持了3次，持续时间分别是7分8秒、4分47秒和3分25秒。被劫持的前缀托管了一些Web服务（北京电力的官方站点等），所以劫持事件被标记为了high level。

由于持续时间较短，且受害者的AS号码和攻击者的AS号码相似（18241和18214），所以我们认为这应该又是一起管理员的错误配置事件。

因为BGP配置失误导致网络故障早就不是什么新鲜事了，前段时间Facebook就因为一条BGP配置错误命令导致服务中断近6个小时，影响了全世界约20亿用户，股价暴跌6%，引发了公众的广泛关注。为了一探究竟，我们对这起事件展开了深入的调查。

从事件发生前的AS路径，我们发现AS18241有两个上游提供商（图2），分别是AS9814（Beijing FibrLINK Networks，中电飞华）和AS4808（中国联通）。

图2 AS18241有两个上游提供商AS9814和AS4808

事件发生后，有国外的观测点AS202365（omer GOLGELI，土耳其）观测到前缀210.77.178.0/24的源AS从AS18241（国家电网）变成了AS18214（菲律宾TELUS-INTERNATIONAL），而从劫持路径上来看，倒数第二跳是AS9814（中电飞华)，正是AS18241（国家电网）的其中一个上游提供商（图3）。

图3 AS18214劫持路径倒数第二跳是AS9814

通过查询历史路由表，经过分析，国内的AS9814不可能是菲律宾AS18214的上游提供商。所以应该是由于管理员失误把AS18241输成了AS18214。BGP宣告时，IP前缀配置错误的情况比较容易出现，而AS出错相对较少。

一般情况下，BGP会话建立以后AS号是BGP进程自动添加到AS路径上的，而人为操作AS号的情况，要么是在两个AS双方第一次建立BGP会话时，要么是进行ASPP操作（AS Path Prepending）时。

ASPP是指在AS路径前面添加AS号的操作。通常，AS向外宣告一条路由时，只将自己的AS号添加到AS路径上，告诉邻居AS，要去往目的地，下一跳AS是自己。有时，为了降低这条路由在邻居路由表中的优先级，AS可能会添加若干次本地AS号来增加AS路径的长度。

我们猜测可能是第一种情况，即双方在协商建立BGP会话时将AS18241错误弄成了AS18214。因为这条路径上并没有出现重复的AS号，应该不存在手动ASPP操作的情况。于是我们准备发邮件向AS18214和AS9814的管理员询问最近是否在配置新的BGP会话。

通过whois查询，我们找到了AS18214和AS9814的管理员邮箱，但是不幸的是，AS18214和AS9814的注册信息十几年未更新，邮箱地址早已失效，可联系的只有CNNIC。

通过国家电网和中电飞华公司的网站，我们找到了一些可达的邮箱进行了询问，但是目前为止没有得到回复（图4）。

图4 通过邮件询问没有得到回复

深入分析与推测

继续分析该事件的过程中，我们发现事情并非这么简单，并注意到了一条更加可疑的路径。在这条劫持路径中（图5），存在ASPP操作（AS141174在路径中连续出现了多次），而且存在AS141174和AS141171的环路。

图5 该事件的劫持路径中存在ASPP操作

这看起来像是AS141174在进行ASPP操作时管理员错误配置。但是两次错误配置发生在了同一条路由路径当中，这种情况出现的概率微乎其微。

难道这两个错误是同一个人造成的，AS18241错误写成AS18214其实和AS18241（国家电网）与AS9814（中电飞华）无关？

为了弄清楚当时到底发生了什么，我们从RIPE RIS的RRC00（系统的BGP路由输入来源之一）获取了当时所有有关这3条前缀的BGP报文（图6）。

图6 有关AS18241的3条前缀的BGP报文

我们发现，期间所有报文的AS路径中都存在AS141174，而且AS141174还作为源AS出现过。

我们猜测，AS路径中出现的9814和18214以及18241都是AS141174添加上去的。AS141174的管理员在北京时间2021年11月29日16：31分向上游ISP宣告了AS18241（国家电网）的3条前缀，同时还将一些人工构造的路径添加到了AS路径当中，在添加路径时，错误地把141174和18241分别输成了141171和18214，导致BGPwatch检测到了MOAS（多源AS）事件，且没有通过BGPwatch的合法MOAS规则，触发了报警。

从AS路径上来看，AS141174并不是AS18241的直接上游提供商，所以一般情况下，AS141174不应该为AS18214宣告前缀。根据valley-free原则，可以从路径中推断出AS141174是AS9814（中电飞华）的上游提供商（图7）。但是事实上，AS9814的CAIDA排名要比AS141174高，AS141174起源的前缀也非常少，似乎不符合常理。

不过，从AS141174的AS名称来看，它像是一个提供互联网互联服务的AS，考虑到它的前缀数量少，AS141174有可能是香港的一个小型IXP（互联网交换中心）。这样一来，AS3491-AS141174-AS9814-AS18241这条路径才显得合理。

图7 AS9814的上游提供商和客户

通过Looking Glass，我们发现国外很多AS去往AS18241（国家电网）路由平面路径经过AS3491（香港电讯盈科，Tier 1 AS），再经过AS141174，然后进入AS9814，最终到达AS18241（图8）。

图8 国外部分AS去往AS18241的路径

但是traceroute路径中并没有出现过AS141174的IP地址。下图是从国外某个AS的Looking Glass traceroute北京电力的路径。可以发现，AS3491到AS9814中间确实存在一跳，但是却没有响应。如果AS141174是一个IXP，那么该跳对应的是AS9814边界路由器连接IXP的接口（图9）。

图9 从国外某AS的

Looking Glass traceroute北京电力的路径

通过ASRank查询和HE BPG查询，可以得知AS141174是一个香港的AS，AS名称为INTELLGENT-AS-AP，whois信息最后一次修改时间为2020-09-10。该AS有3个上游提供商，拥有3条前缀（图10）。

图10 通过ASRank查询和HE BPG查询AS141174的结果

从历史观测来看，AS141174在2021年8月1日左右发生了一次较大的变化（图11），由原先的一个peer，增加到了5个peer，从AS141174起源的前缀数量也从1条增加到了3条。2021年9月期间也曾作为中转AS出现过。

图11 AS141174在2021年8月1号左右发生了一次较大变化

可以发现AS141174最近动作频发，像是一个正在发展的香港小型IXP，最近管理员的一些误操作导致了产生了一些错误的路由信息。

以上只是我们的一些推测，真正的事实需要联系相关网络管理员。我们已经向以上相关的AS发送了邮件询问情况，但是迄今并没有收到任何回复。

BGP配置错误是一个由来已久的问题，BGPwatch监测到每天都有大量的错误配置事件发生，以及一些中规模的错误配置事件，比如2021年11月9日的AS（25478）IHOME-AS疑似错误配置，劫持了全球30多个国家130多个AS的超过180条前缀约5分钟。

所幸的是大部分的错误配置都能被管理员及时发现，且大部分的错误配置实际上并不会对网络造成很大的影响。但是错误配置会给整个路由系统带来大量不必要的BGP报文，增加路由器的负担。

互联网的历史上也不乏由于错误配置而导致网络大范围瘫痪的事件。从1997年的AS7007事件，到2008年2月23日的巴基斯坦劫持Youtube事件，再到最近2021年的Facebook宕机事件，都是由于管理员在操纵BGP命令时失误而产生的重大网络瘫痪事件。

互联网的互联离不开BGP，没有BGP安全，就没有互联网安全。很难想象，一个诞生于1989年的互联网的核心协议，到如今发展了30多年，依然如此脆弱。而且，可以预见的是，BGP安全还有很长一段路要走。

BGP是一个去中心化的协议，良好的运作依赖于各个AS之间的协商与沟通，以及准确及时的公开信息。不规范的配置、注册信息不及时更新、不上传ROA、缺乏有效BGP异常监测工具、没有统一的全球AS协商平台，都是阻碍BGP安全发展的因素。

来源：DragonLab

责编：项阳

投稿、转载或合作，请联系：[e-mail]

往期推荐

看完了，点个赞呗~