超出预期范围:一次DDoS缓解措施的泄漏事件
超出预期范围:DDoS Mitigation Leak
Doug Madory
互联网分析主管
2025年4月8日
互联网分析
目录
什么是BGP泄漏?发生了什么?影响行动号召
加入我们的网络
注册以获取来自 Kentik 的最佳内容,包括文章、分析等。
Sign up By completing this form, you agree to our Privacy Policy and Terms of Use. 目录 什么是BGP泄漏?发生了什么?影响行动号召 订阅
概要
在本期“超出预期范围”中,我们将探讨上周由一家 DDoS mitigation 公司造成的 BGP 泄漏事件,该事件影响了全球网络。 我们将查看 BGP 和流量数据中的影响,并讨论 RFC 9234 的 “Only to Customer” BGP Path Attribute 如何能够提供帮助。
去年年底,我们发布了第一期 Beyond Their Intended Scope, 我们的新博客系列旨在揭示可能未引起互联网社区关注但仍值得分析的 BGP 事故。
在本期中,让我们来看看上周二发生的一个 BGP 路由事故,由于一家 DDoS mitigation 供应商的 BGP 泄漏,该事故短暂地中断并错误地将来自世界各地的互联网流量导向了罗马尼亚的布加勒斯特。
路由泄漏仍然经常发生,这可能会让很多人感到惊讶。 今天的不同之处在于,路由卫生已经改进到一定程度,这些泄漏通常仅限于其起源国家或地区,从而限制了中断。 在这种情况下,路由传播没有受到限制,但泄漏的持续时间可能受到了限制。
路由安全状态
加入 Doug Madory,参加 4 月 24 日的深入探讨,了解当前路由安全的状态 - 已取得的进展和尚未完成的工作。
什么是BGP泄漏?
“路由泄漏是将路由通告传播到_超出其预期范围_之外。”
这是 RFC7908 在 2016 年引入的 BGP 路由泄漏的总体定义。 边界网关协议 (BGP) 通过提供一种机制,使自治系统(例如,电信公司、公司、大学等)能够交换有关如何基于其目标 IP 地址转发数据包的信息,从而使互联网能够发挥作用。
在此上下文中,名词“路由”是前缀(IP地址范围)、AS_PATH 和与数据包传递相关的其他相关信息的简写。 当路由的循环范围超过其应有的范围时,流量可能会被错误地引导,甚至中断,这种情况每年都会发生多次。
RFC7908 继续通过枚举六个常见场景来定义 BGP 泄漏的分类,其中一半出现在本文中介绍的两次泄漏中。 在我关于路由泄漏的写作中,我喜欢将它们分为两大类:错误来源和路径错误。 正如我在我的博客文章互联网上最大的 BGP 事件简史中所述,这种区别很有用,因为这两种类型的错误需要不同的缓解策略。
- 当 AS 发起(以其 ASN 作为来源进行通告)对其不具有合法控制权的 IP 地址块的路由的新通告时,从而征求发往这些 IP 地址的流量,则会发生错误来源。
- 当 AS 将其自身作为非法的中间方插入到发往不同目的地的流量的转发路径中时,则会发生 AS 路径错误。
在介绍完这些定义之后,让我们深入了解此特定事件的详细信息。
发生了什么?
从 2025 年 4 月 1 日 07:35 UTC 开始,AS3223 (Voxility) 开始通过其传输提供商 Lumen (AS3356) 泄漏从其对等方获知的路由。 像 Voxility 这样的基于 BGP 的 DDoS mitigation 提供商在互联网路由中发挥着独特的作用,鉴于他们遍布全球的客户群,这可能会使过滤泄漏的路由的努力复杂化。
在任何给定时间,此类网络都可以合法地传输来自不同客户 ASN 的数千条路由。 事实上,根据网络资源 bgp.tools,AS3223 的 AS-SET 扩展到包括 28,720 个不同的 ASN、875,309 个 IPv4 前缀和 632,221 个 IPv6 前缀。 如果被接受到路由器配置中,此 AS-SET 将生成一个长达数百万行的允许列表,涵盖全球路由表中绝大多数 IP 空间。
该事件由我们的朋友在 Qrator 首次报告,涉及泄漏了超过 30,000 条路由,持续了大约 20 分钟,在此期间,它错误地引导并中断了世界各地提供商的流量。
误源还是路径错误?| 路径错误 ---|--- 泄漏了多少条路由?| 31,258(7,381 条被 50 多个 Routeviews 对等方看到) 新的更具体的?| 2(通常被 10 个或更少的 Routeviews 对等方看到)
这是一次规模相当大的泄漏,持续了 20 分钟之久,并影响了许多国家的公司。 由于我们没有看到任何新的更具体的激增(除了 89.238.228.0/24 和 5.154.239.0/24),那么我们可以假设这次泄漏没有涉及路由优化器。 由于这不是来源泄漏(泄漏者发起泄漏的路由)并且几乎没有新的更具体的,因此 RPKI ROV 将无法帮助限制此 BGP 事故的中断。
在以下文章中,我们将更仔细地了解发生了什么、对流量的影响以及可以做些什么来防止将来发生这些类型的事件。
影响
BGP
正如我们上次所做的那样,让我们从单个 BGP 消息级别开始,然后逐步向外扩展。 下面的两条 BGP 消息是从 Routeviews 收集的,显示了从一个 BGP 来源(加利福尼亚研究和教育网络 CENIC (AS2152))的角度来看,泄漏前后的 AS 路径。
从左到右读取突出显示的 AS 路径,我们可以看到此路由通常由澳大利亚的 TPG Telecom (AS7545) 发起,并在通过对等连接 3356:666
在加利福尼亚州圣何塞 3356:2011
到达 Lumen (AS3356) 之前,向 Tata (AS6453) 预置三次,如社区字符串所示。
TIME: 04/01/25 06:00:20
FROM: 137.164.16.84 AS2152
ORIGINATED: 03/28/25 02:00:29
ORIGIN: IGP
ASPATH: **2152 3356 6453 7545 7545 7545 7545**
NEXT_HOP: 137.164.16.84
COMMUNITY: 2152:65493 2152:65497 2152:65499 2152:65511 3356:3 3356:22 3356:86 3356:575 3356:666 3356:903 3356:2011
ANNOUNCE
220.240.123.0/24
但是,在泄漏期间,Lumen 传递给 CENIC 的信息是从泄漏者 (AS3223) 通过布加勒斯特的传输客户连接 3356:123
获知的 3356:2088
。 这样做时,3356 更喜欢来自客户的具有较短 AS 路径的路由。
TIME: 04/01/25 07:36:18.623710
FROM: 137.164.16.84 AS2152
ORIGIN: IGP
ASPATH: **2152 3356 3223 7545**
NEXT_HOP: 137.164.16.84
ATOMIC_AGGREGATE
AGGREGATOR: AS7545 10.20.23.131
COMMUNITY: 2152:65495 2152:65497 2152:65499 2152:65511 3356:2 3356:22 3356:100 3356:123 3356:515 3356:903 3356:2088
ANNOUNCE
220.240.123.0/24
…
(为节省空间而截断)
在下面的第二个示例中,GTT (AS3257) 通常通过其与德国法兰克福 PCCW (AS3491) 的对等关系 3257:54901
接收此 Yahoo (AS10310) 路由。 请注意,此路由由 Yahoo 向 AS3491 和其他传输提供商预置。
TIME: 04/01/25 06:00:01
FROM: 89.149.178.10 AS3257
ORIGINATED: 03/20/25 08:00:33
ORIGIN: IGP
ASPATH: 3257 3491 10310 10310 10310 10310
NEXT_HOP: 89.149.178.10
COMMUNITY: 3257:8059 3257:8927 3257:30275 3257:50001 3257:54900 3257:54901
ANNOUNCE
27.123.34.0/23
在 AS3223 泄漏期间的同一路由的 BGP 通告中,AS3257 选择来自布加勒斯特的对等方 (AS3356) 的较短泄漏路由 3257:54001
。
TIME: 04/01/25 07:36:18.286854
FROM: 89.149.178.10 AS3257
ORIGIN: IGP
ASPATH: 3257 3356 3223 10310
NEXT_HOP: 89.149.178.10
COMMUNITY: 3257:8099 3257:30658 3257:50001 3257:54000 3257:54001
ANNOUNCE
…
27.123.34.0/23
…
这两个示例都涉及不必要的预置,从而导致泄漏传播。
现在,让我们缩小范围,看看这种路由更改在总体上是什么样子。 使用 Kentik 的 BGP 可视化工具(如下所示),我们可以看到互联网在泄漏发生时如何到达 AS10310 的 27.123.34.0/23。
虽然可视化的下半部分显示了经过修剪的球杆式 AS 级图,但上半部分图显示了 BGP 优势点计数所观察到的此路由的 AS10310 上游的 AS。 泄漏的证据在橙色框中标记。
让我们看另一个在下面可视化的示例。
207.180.128.0/24 由 RCN (AS6079) 通告,通常只能被 Routeviews 中大约 50% 的 BGP 来源看到。 通常,传播有限的路由有时被称为“区域路由”,- 仅用于引导世界一部分的流量 - 但尚不清楚这是否解释了这种情况下的有限传播。
像这样的传播有限的路由的问题在于,当有人泄漏这些路由时,由于缺乏竞争(由于传播有限),它们会广泛传播。 这表现为堆叠图中的驼峰,因为 AS3223 暂时显示为对于此路由和具有有限传播的其他泄漏路由,世界上最受欢迎的 AS6079 上游。
由于区域路由通常是不太具体的路由的更具体的路由(用于处理区域外的流量),因此它们往往会吸引大量流量,从而导致流量中断。 出于这个原因,区域路由是有风险的。
流量
Kentik 拥有的最神奇的功能之一是能够获取 BGP 事件并分析其对互联网流量的影响。 使用 Kentik 独特的聚合 NetFlow 数据,我们可以深入了解互联网流量的影响,特别是多少流量被错误地引导与完全丢弃。
在摄取期间,Kentik 使用生成 NetFlow 的路由器的角度,用目标 IP 的 AS 路径注释每个 NetFlow 记录。 这使我们能够进行查询,从而检索使用与泄漏匹配的 AS 路径注释的 NetFlow 记录。
让我们首先看一下通过具有子序列 “3356 3223” 的 AS 路径发送的所有流量,按目标国家/地区划分。 在我们的聚合 NetFlow 中运行该查询会生成以下图表,其中韩国 (40.1%)、越南 (15.5%)、缅甸 (10.5%) 和香港 (5.4%) 是受影响最大的三个目标国家/地区(以比特/秒为单位)。
当我们查看所有发往顶级泄漏路由中包含的 IP 空间的流量时,我们可以了解有多少流量被错误地引导与完全丢弃。 (注意:在这种情况下,我专注于发往大多数 Routeviews 来源看到的顶级 500 个泄漏路由的流量。)
在下图中,来自我们客户网络的流量稳定地流向这些路由。 在泄漏期间,由于其破坏性影响,总体流量下降。 在底部标记处,我们还可以看到发送到 AS 路径中包含泄漏的路由的一小部分流量。 这是被错误地引导但最终到达其目的地的流量部分。
我发现,通常情况下,像这些路由泄漏一样,丢弃或中断的流量量超过了错误引导的流量量。 流量在泄漏期间被丢弃,因为大量意外的流量被定向到未充分配置以处理它的链接。
我们不知道泄漏路径(“3356 3223”)的确切瓶颈在哪里,但很可能某些东西不堪重负,并且数据包无法及时传递到它们需要去的地方。
行动号召
本文分析的 BGP 泄漏可以称为“路径泄漏”或“邻接泄漏”,这意味着错误发生在 AS 路径的中间,而不是开头(最右边的 ASN)。 并且由于没有以有问题的方式错误地_发起_任何路由,因此像 RPKI ROV 这样的基于来源的解决方案将无法提供帮助。
路由卫生工具包中的另一个工具是提出的配置参数 BGP Role,如 RFC 9234 中定义的那样。 它定义了一个可选的、可传递的 BGP Path Attribute,称为 BGP 通告中的“Only to Customer”或 OTC。
它的工作方式如下:AS3223 将接受来自其对等方的使用 OTC 属性标记的路由,向 AS3223 发出信号,指示这些路由应仅发送给其直接客户。 如果 AS3356 以某种方式从其客户 AS3223 收到使用 OTC 属性标记的路由,它将立即知道这些路由已泄漏,并且不会接受它们。
像 RFC 9234 和 ASPA 这样的技术是可以帮助减少不可避免的 BGP 事故造成的中断的机制。
探索更多来自 Kentik 的内容
路由安全状态:进展、挑战和衡量标准 4 月 24 日网络研讨会
Starlink 通过社区网关进入传输市场博客文章
云延迟地图互动工具
Kentik 是为现代基础设施团队提供的网络智能。
获取演示
LinkdIn
Youtube
Twitter
Github
RSS Feed
844-356-3278
平台
- Multi-Cloud Observability
- Network Monitoring System (NMS)
- SD-WAN Monitoring
- Network Security and Compliance
- Synthetic Monitoring
- Peering and Interconnection
- Subscriber Intelligence
- Kentik AI
- Network Telemetry
- Universal Data Explorer
- Observability Data Pipeline
- Integrations
- Kentik Data Engine
解决方案
- Reduce Cloud Spend
- Migrate To and From Any Cloud
- Improve Cloud Performance
- Optimize Enterprise WAN
- Network Performance Monitoring
- Deliver Exceptional Digital Experiences
- Detect and Mitigate DDoS
- Harden Zero-Trust Cloud Network Policy
- Investigate Security Incidents
- Visualize All Cloud and Network Traffic
- Troubleshoot Any Network
- Understand Internet Performance
- Consolidate Legacy Tools
- Optimize Peering and Transit
- [Plan Network Capacity ](https://www.kentik.com/