3月13日，RIPE反滥用工作组
收到了一项建议，将劫持视为违反RIPE政策
的提议 。 如果要约被接受，则通过拦截流量受到攻击的Internet提供商将能够发送特殊请求，以使攻击者获得洁净水。 如果专家组收集到足够的支持证据，那么这种作为BGP拦截源的LIR将被视为入侵者，并且可能会被剥夺LIR的地位。 有一些人
反对这种改变。
在本出版物中，我们想展示一个攻击示例，它不仅怀疑真正的攻击者，而且怀疑整个前缀列表。 此外，这种攻击再次引起了人们对将来拦截此类流量的动机的质疑。
在过去的几年中，媒体仅报道了诸如MOAS（多源自治系统）之类的冲突是BGP拦截。 当两个不同的自治系统在AS_PATH（AS_PATH中的第一个ASN，以下称为起源ASN）中宣布具有相应ASN编号的前缀冲突时，MOAS是一种特殊情况。 但是，我们可以至少命名
3种其他类型的流量拦截，它们使攻击者可以出于各种目的来操纵AS_PATH属性，包括为了规避现代的过滤和监视方法。 众所周知的
Pilosov-Kapela攻击类型是这种拦截的最后一种类型，但意义不大。 这很可能正是我们在过去几周中观察到的攻击。 这样的事件具有可理解的特征并且具有相当严重的后果。
那些正在寻找TL; DR版本的人可以滚动到子标题“ Perfect Attack”。
网络背景
（以便您更好地了解此事件涉及的流程）如果要发送数据包，并且在包含目标IP地址的路由表中有多个前缀，则将路由用于具有最大长度的前缀。 如果在路由表中有一个前缀存在多个不同的路由，则将选择最佳路由（根据选择最佳路径的机制）。
现有的过滤和监视方法尝试通过分析AS_PATH属性来分析路由并做出决策。 路由器可以在通告期间将此属性更改为任何值。 仅在AS_PATH的开头添加所有者ASN（例如原始ASN）就足以绕过当前的源验证机制。 此外，如果存在一条从受攻击的ASN到您的路由，则有可能在您的其他公告中提取并使用此路由的AS_PATH。 最终将仅通过任何针对您制作的公告的AS_PATH验证。
有几个值得注意的限制。 首先，在由较高的提供者过滤前缀的情况下，如果前缀不属于上游配置的客户端锥体，则仍可以过滤路由（即使使用正确的AS_PATH）。 其次，如果创建的路由在错误的方向上发布，则有效的AS_PATH可能无效，从而违反了路由策略。 最后一条-任何前缀违反ROA长度的路由都可以视为无效。
突发事件
几周前，我们收到了一位用户的投诉。 我们看到了带有原始ASN和/ 25前缀的路由，而用户声称他们尚未宣布它们。
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.7.0/25|265466 262761 263444 22356 3491 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.7.128/25|265466 262761 263444 22356 3491 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.18.0/25|265466 262761 263444 6762 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.18.128/25|265466 262761 263444 6762 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.226.0/25|265466 262761 263444 22356 3491 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.226.128/25|265466 262761 263444 22356 3491 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.164.7.0/25|265466 262761 263444 6762 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.164.7.128/25|265466 262761 263444 6762 2914 9121|INCOMPLETE|xxx|0|0||NAG||2019年4月开始的公告示例/ 25前缀在传输中的NTT使其特别可疑。 事件中，LG NTT对这条路线一无所知。 所以是的，某种运算符会为这些前缀创建整个AS_PATH！ 通过在其他路由器上进行测试，您可以突出显示一个特殊的ASN：AS263444。 在使用此自治系统查看其他路线时，我们面临以下情况：
TABLE_DUMP2|1554076800|B|xxx|265466|1.6.36.0/23|265466 262761 263444 52320 9583|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.6.38.0/23|265466 262761 263444 52320 9583|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.23.143.0/25|265466 262761 263444 22356 6762 9498 9730 45528|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.23.143.128/25|265466 262761 263444 22356 6762 9498 9730 45528|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.24.0.0/17|265466 262761 263444 6762 4837|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.24.128.0/17|265466 262761 263444 6762 4837|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.26.0.0/17|265466 262761 263444 6762 4837|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.26.128.0/17|265466 262761 263444 6762 4837|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.64.96.0/20|265466 262761 263444 6762 3491 4760|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.64.112.0/20|265466 262761 263444 6762 3491 4760|IGP|xxx|0|0||NAG||尝试猜测这里出了什么问题似乎有人从路由中获取了前缀，将其分为两部分，并为这两个前缀使用相同的AS_PATH宣布了路由。
TABLE_DUMP2|1554076800|B|xxx|263444|1.6.36.0/23|263444 52320 9583|IGP|xxx|0|0|32:12595 52320:21311 65444:20000|NAG||
TABLE_DUMP2|1554076800|B|xxx|263444|1.6.38.0/23|263444 52320 9583|IGP|xxx|0|0|32:12595 52320:21311 65444:20000|NAG||
TABLE_DUMP2|1554076800|B|xxx|61775|1.6.36.0/23|61775 262761 263444 52320 9583|IGP|xxx|0|0|32:12595 52320:21311 65444:20000|NAG||
TABLE_DUMP2|1554076800|B|xxx|61775|1.6.38.0/23|61775 262761 263444 52320 9583|IGP|xxx|0|0|32:12595 52320:21311 65444:20000|NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.6.36.0/23|265466 262761 263444 52320 9583|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.6.38.0/23|265466 262761 263444 52320 9583|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|28172|1.6.36.0/23|28172 52531 263444 52320 9583|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|28172|1.6.38.0/23|28172 52531 263444 52320 9583|IGP|xxx|0|0||NAG||一对分割前缀中的一对的路由示例立刻出现几个问题。 在实践中有人真的尝试过这种拦截吗？ 有人走过这些路线吗？ 哪些前缀受到影响？
这是我们一系列失败的开始，也是互联网当前健康状况的又一轮令人失望的地方。
失败之路
首先是第一件事。 我们如何确定哪些路由器接受了此类截获的路由，以及哪些流量今天可以重定向？ 我们认为应该以/ 25前缀开头，因为它们“根本不能具有全局分布”。 可以猜到，我们错了。 此指标太吵杂，甚至从Tier-1运营商处也可能出现带有此类前缀的路由。 例如，NTT有大约50个这样的前缀，可以在自己的客户端之间分配。 另一方面，此度量标准不好，因为如果操作员在所有方向上应用
小的前缀过滤，则可以过滤掉此类前缀。 因此，此方法不适用于搜索由于此类事件而导致其流量被重定向的所有运营商。
我们认为的另一个好主意是看
POV 。 特别是在违反相应ROA的maxLength规则的路由上。 因此，我们可以找到此AS可见的具有无效状态的不同源ASN的数量。 但是，存在“小”问题。 该数目（不同来源的ASN的数目）的平均值（中位数和众数）约为150，即使我们过滤掉小的前缀，其平均值也将保持在70以上。这种情况的解释很简单：只有少数运营商已经在使用ROA-过滤器在入口点使用“重置无效路由”策略，因此，在现实世界中出现违反ROA的路由时，它都可以在所有方向传播。
最后两种方法使我们能够找到看到我们事件的操作员（因为事件很大），但总的来说它们并不适用。 好的，但是我们可以找到攻击者吗？ 这种AS_PATH操作的共同特征是什么？ 有几个基本假设：
- 前缀在以前没有出现过；
- 原始ASN（提醒：AS_PATH中的第一个ASN）有效；
- AS_PATH中的最后一个ASN是攻击者的ASN（如果他的邻居在所有传入路由上检查邻居的ASN）；
- 攻击来自一个提供者。
如果所有假设都成立，那么在所有错误的路由上都会显示攻击者的ASN（ASN的来源除外），因此这是“关键”点。 真正的劫机者是AS263444，尽管还有其他人。 即使我们放弃了考虑事故的路线。 怎么了 关键点即使对于正确的路线也可以保持关键。 这可能是由于任何地区的连通性差或我们自身能见度的限制所致。
结果：存在一种检测攻击者的方法，但前提是必须满足上述所有条件，并且仅在拦截足够大以通过监视阈值时才可以。 如果不考虑这些因素中的任何一个，我们能否挑出受此类拦截影响的前缀？ 对于某些运营商，是的。
攻击者创建更特定的路由时，真正的所有者不会宣布这样的前缀。 如果您具有其中所有前缀的动态列表，则可以进行比较并查找失真的更具体的路由。 我们使用BGP会话收集此前缀列表，因为不仅给了操作员当前可见的完整路由列表，而且还提供了他想向全世界宣布的所有前缀的列表。 不幸的是，现在有数十名Radar用户无法正确完成最后一部分。 在不久的将来，我们将通知他们，并尝试解决此问题。 其他所有人都可以立即加入我们的监控系统。
如果我们返回原始事件，那么我们将通过搜索关键点来发现攻击者和分布区域。 令人惊讶的是，AS263444并未将伪造的路线发送给所有客户。 虽然还有一个更奇怪的时刻。
BGP4MP|1554905421|A|xxx|263444|178.248.236.0/24|263444 6762 197068|IGP|xxx|0|0|13106:12832 22356:6453 65444:20000|NAG||
BGP4MP|1554905421|A|xxx|263444|178.248.237.0/24|263444 6762 197068|IGP|xxx|0|0|13106:12832 22356:6453 65444:20000|NAG||尝试拦截我们的地址空间的最新示例当创建更具体的前缀时，将使用专门创建的AS_PATH。 但是，此AS_PATH不能从我们之前的任何路由中获取。 我们甚至都没有与AS6762连接。 我们查看事件中的其他路由：其中一些具有真实的AS_PATH，该AS_PATH较早使用，而其他一些则没有，即使它们看起来像真实的一样。 对AS_PATH的其他更改没有任何实际意义，因为在任何情况下，流量都将重定向到攻击者，但是ASPA或任何其他检查机制都可以过滤AS_PATH为“错误”的路由。 在这里，我们考虑了劫机者的动机。 现在我们没有足够的数据来证明此事件是有计划的攻击。 然而，这是可能的。 让我们尝试想象一个假设的但可能非常真实的情况。
完美攻击
我们有什么？ 假设您是为客户广播路线的公交服务提供商。 如果您的客户有多个网点（多家庭），那么您将只收到他们部分流量。 但是流量越多，您的收入就越多。 因此，如果您开始用相同的AS_PATH宣布相同路由的子网前缀，您将收到它们的其余流量。 结果，剩下的钱。
ROA会在这里帮助吗？ 如果您决定完全放弃使用
maxLength ，也许可以。 另外，非常不希望有带有相交前缀的ROA条目。 对于某些运营商而言，这种限制是不可接受的。
考虑其他路由安全机制，在这种情况下，ASPA也无济于事（因为从有效路由中使用了AS_PATH）。 BGPSec仍然不是最佳选择，因为它的接受率低，并且仍有降级攻击的可能性。
因此，我们为攻击者带来了明显的利益，并且缺乏安全性。 很棒的组合！
我该怎么办？
最明显和最根本的步骤是查看当前的路由策略。 将地址空间分成只想宣布的最小部分（没有交叉点）。 仅为它们签署ROA，而不使用maxLength参数。 在这种情况下，当前的POV可以使您免遭这种攻击。 但是，同样，对于某些运营商而言，由于仅使用更具体的路线，因此这种方法不合理。 ROA和路由对象当前状态的所有问题将在我们的未来材料之一中进行描述。
此外，您可以尝试监视此类拦截。 为此，我们需要有关您的前缀的可靠信息。 因此，如果您与收集器建立BGP会话并向我们提供有关您的Internet可见性的信息，我们可以找到其他事件的分布区域。 对于尚未连接到我们的监控系统的用户-首先，仅包含您的前缀的路由列表就足够了。 如果您与我们进行会话，请检查是否已发送所有路线。 不幸的是，这值得一提，因为某些运算符会忘记一个或两个前缀，从而干扰了我们的搜索方法。 如果一切都正确完成，那么我们将获得有关您前缀的可靠数据，将来这将有助于自动检测并检测您地址空间的此类（和其他）流量拦截类型。
如果您实时发现这种流量拦截现象，可以尝试自己进行应对。 第一种方法是自己声明带有这些更特定前缀的路由。 如果对这些前缀进行新的攻击-请重复。
第二种方法是通过切断通往攻击者的路线来惩罚攻击者和那些他（对于好的路线而言）是关键点的人。 这可以通过将攻击者的ASN添加到您的旧路由的AS_PATH中来完成，从而使它们利用BGP中的内置环路检测机制来避免使用该AS，以
获取自己的利益 。