主持人 > 博客 > 管理 > 一切都很糟糕或者是一种新型的流量拦截

一切都很糟糕或者是一种新型的流量拦截

13 月 XNUMX 日致 RIPE 反滥用工作组 已收到报价 将 BGP 劫持 (hjjack) 视为违反 RIPE 策略。 如果该提案被接受，受到流量拦截攻击的互联网提供商将有机会发送特殊请求来揭露攻击者。 如果审查小组收集到足够的支持证据，作为 BGP 拦截源的 LIR 将被视为入侵者，并可能被剥夺其 LIR 状态。 也出现了一些争论 反对这个 变化。

在本出版物中，我们想要展示一个攻击示例，其中不仅有真正的攻击者，而且还有受影响的前缀的整个列表。 此外，此类攻击再次引发了人们对未来拦截此类流量的动机的质疑。

在过去的几年里，只有像 MOAS（多源自治系统）这样的冲突才被媒体报道为 BGP 拦截。 MOAS是一种特殊情况，两个不同的自治系统通告与AS_PATH中对应的ASN（AS_PATH中的第一个ASN，以下简称源ASN）冲突的前缀。 然而，我们至少可以说出 3 种附加类型 流量拦截，允许攻击者出于各种目的操纵 AS_PATH 属性，包括绕过现代过滤和监控方法。 已知攻击类型 皮洛索瓦-卡佩利 - 此类拦截的最后一种类型，但并不重要。 这很可能正是我们过去几周看到的那种攻击。 这种事件的性质是可以理解的，而且后果也相当严重。

那些寻找 TL;DR 版本的人可以滚动到“完美攻击”副标题。

网络背景

（帮助您更好地了解本次事件所涉及的流程）

如果您要发送数据包，并且路由表中有多个包含目标 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年XNUMX月上旬公告示例

路径中的 NTT /25 前缀使其特别可疑。 事件发生时，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 前缀开始，因为它们“根本无法进行全球分发”。 正如你所猜到的，我们错了。 事实证明，这个指标噪音太大，甚至来自一级运营商的路由也会出现带有此类前缀的路由。 例如，NTT 有大约 1 个这样的前缀，并将其分发给自己的客户。 另一方面，这个指标很糟糕，因为如果操作员使用这样的前缀，则可以过滤掉 过滤小前缀，在各个方向。 因此，该方法不适合查找所有因此类事件而流量被重定向的运营商。

我们认为的另一个好主意是看看 POV。 特别是对于违反相应 ROA 的 maxLength 规则的路由。 通过这种方式，我们可以找到对给定 AS 可见的状态为无效的不同源 ASN 的数量。 然而，有一个“小”问题。 这个数字（不同来源 ASN 的数量）的平均值（中位数和众数）约为 150，即使我们过滤掉小前缀，它仍保持在 70 以上。这种情况有一个非常简单的解释：只有很少有运营商已经在入口点使用带有“重置无效路由”策略的 ROA 过滤器，因此无论现实世界中出现 ROA 违规的路由，它都可以向各个方向传播。

最后两种方法允许我们找到看到我们事件的操作员（因为事件相当大），但一般来说它们不适用。 好吧，但是我们能找到入侵者吗？ AS_PATH 操作的一般特征是什么？ 有几个基本假设：

  • 该前缀以前从未在任何地方见过；
  • Origin 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 通告这些相同路由的子网前缀，您将收到其其余流量。 结果，剩下的钱。

ROA 在这里有帮助吗？ 也许是的，如果您决定完全停止使用它 最长长度。 此外，非常不希望 ROA 记录具有相交的前缀。 对于一些运营商来说，这样的限制是不可接受的。

考虑到其他路由安全机制，ASPA 在这种情况下也无济于事（因为它使用来自有效路由的 AS_PATH）。 由于采用率较低且存在降级攻击的可能性，BGPSec 仍然不是最佳选择。

因此，我们对攻击者来说有明显的好处，但缺乏安全性。 很棒的组合！

我该怎么办？

最明显也是最彻底的步骤是检查您当前的路由策略。 将您的地址空间分成您想要通告的最小块（无重叠）。 仅为他们签署 ROA，而不使用 maxLength 参数。 在这种情况下，您当前的 POV 可以使您免受此类攻击。 然而，同样，对于一些运营商来说，由于专有使用更具体的路线，这种方法并不合理。 ROA 和路线对象当前状态的所有问题将在我们未来的材料之一中进行描述。

另外，您可以尝试监控此类拦截。 为此，我们需要有关您的前缀的可靠信息。 因此，如果您与我们的收集器建立 BGP 会话并向我们提供有关您的互联网可见性的信息，我们就可以找到其他事件的范围。 对于那些尚未连接到我们的监控系统的人来说，首先，仅包含您的前缀的路由列表就足够了。 如果您与我们进行了会话，请检查您的所有路线是否已发送。 不幸的是，这一点值得记住，因为某些运算符忘记了一两个前缀，从而干扰了我们的搜索方法。 如果操作正确，我们将获得有关您的前缀的可靠数据，这些数据将来将帮助我们自动识别和检测您地址空间的这种（和其他）类型的流量拦截。

如果您实时意识到此类流量被拦截，您可以尝试自行抵消。 第一种方法是自己使用这些更具体的前缀来通告路由。 如果这些前缀受到新的攻击，请重复。

第二种方法是通过切断攻击者的路由访问来惩罚攻击者和那些以他为关键点（对于良好路由）的人。 这可以通过将攻击者的 ASN 添加到旧路由的 AS_PATH 中来完成，从而迫使他们使用 BGP 中的内置环路检测机制避开该 AS 为了你好.

来源： habr.com

添加评论