卫生路由对于确保互联网安全至关重要。MANRS 通过鼓励组织遵守一套最佳实践和指南来帮助缓解最常见的路由威胁，并在四个计划中提出了具体行动： 网络运营商、 互联网交换点、 CDN 和云提供商以及 设备供应商。
在这篇文章中，我们将重点关注网络运营商的 行动 ——协调、全球信息、反欺骗和过滤——以及我们如何开发一种首创的开源工具来自动验证 MANRS 合规性。
遵守 MANRS 的挑战
遵守每项行动都需要收集信息或验证网络政策。
尽管网络运营商可以使用多种网络配置验证器来实现此目的（例如 Batfish、 Bagpipe、 BGPVerif），但它们各自都面临着挑战，例如：
依靠模拟或正式证明，采用可能与实际供应商实现不同的路由协议模型。
理解和使用起来很复杂。
不是完整的产品或作为早期原型存在，因此缺乏特定要求，例如实施所有 BGP RFC。
此外，这些工具都不是专门为 MANRS 验证而设计的，这进一步增加了实现合规性的复杂程度。
为了应对这些挑战，我们开发了路由安全工具 (ROSE-T)，这是第一个用于自动验证 MANRS 合规性的开源工具。该项目旨在标准化和加快 MANRS 的采用，使网络运营商最终能够测试其配置，而无需依赖手动且容易出错的程序。
ROSE-T 遵循“不信任任何人”的方法。也就是说， 它可以在本地运行以执行自我评估，而无需依赖第三方服务。请记住，ROSE-T 处于开发的早期阶段，目前，它只能验证单个路由器配置的合规性。
它是如何工作的？
假设我们要验证以下网络中自治系统 A（AS A）的合规性。
图 1 — 我们将在本文中用来解释 ROSE-T 的示例网络。
为实现这一目标，ROSE-T 执行以下五个步骤（图 2）。
图 2——ROSE-T 验证 MANRS 合规性的主要步骤。
步骤 1 — 收集
第一步是验证与候选网络相关的静态信息。
候选者提供其 AS 编号 (ASN)，我们可以从中获取 Internet 路由注册表 (IRR) 条目并解析 (mp-)import 和 (mp-)export 对象。我们还从路由收集器转储最新的完整 RIB，并通过检查 AS_PATH 属性中的第一个 ASN 来过滤由候选者发起的路由。
利用这两条信息，我们可以验证“在野外”向中转方公布的网络集（即来自 RIB 转储）是否等于 IRR 条目中定义的网络集，反之亦然（图 3）。ROSE-T 的当前版本仅专注于检查中转方，但我们计划在未来的项目迭代中将验证扩展到所有对等连接。
图 3 — 我们将 IRR 条目的信息与“在野外”宣布的信息（从 RIB 转储中提取）相结合，以验证候选人是否符合全局信息检查。
第 2 步 — 解析
此时，候选者提供其特定于供应商的配置（例如， Cisco IOS-XR）。但是，为了让管道的其余部分能够轻松处理它，我们需要将其转换为不可知格式。
目前，ROSE-T 利用 Batfish 的解析器来实现这一点，因为它理解大多数供应商语法并将它们转换为统一格式（图 4）。然而，在开发过程中，我们注意到 Batfish 目前缺少一些功能，最重要的是它不支持 IPv6。因此，我们使用 Batfish 输出作为基线，并使用我们实现的另一个自定义解析器提取缺失的信息。我们计划在未来编写自己的综合解析器。
图 4 — 我们结合使用 Batfish 和自定义解析器将供应商配置转换为不可知的网络表示。
步骤 3 — 分析
上一步的结果是一个以不可知格式保存基本信息的数据结构。但是，它缺乏有关不同 AS 之间网络关系的知识。为了建立这些关系，我们再次依赖 IRR 条目（图 5），该条目在此阶段确保包含准确信息，并已成功通过 收集 步骤。
图 5 — 我们使用候选的 IRR 条目（已在“收集”步骤中验证）来了解网络中的邻居关系。
我们添加一个虚拟网关（图 6，“Internet”）到：
将网络中的所有提供商互连。
自上而下传播默认路由。
拥有一个 AS，我们可以在其中插入 Internet 上的假设主机。
最后，我们再次使用 RIB 转储，并为每个 AS 定义由每个 AS 发起的前缀。ROSE-T 还支持多跳对等，但本例中未显示。
图 6 — 我们公布从 RIB 转储中提取的由每个 AS 发起的前缀（IPv4 和 IPv6）。
“Internet”AS 传播默认路由。
第 4 步 — 模拟
此时，我们已掌握了将中间表示转换为可运行网络场景的所有信息。与以前的工具不同，我们依靠仿真，这使得运行实际的软件实现并实现尽可能与真实网络行为相似的网络成为可能。
我们使用基于容器的开源网络模拟器Kathará来运行模拟 。每个 AS 都用一个路由器表示，我们根据中间表示中包含的信息为其生成配置（图 7）。
对于除候选路由器之外的所有路由器，我们使用 FRRouting 作为路由套件。对于候选路由器，我们使用从输入配置派生的特定供应商容器。目前，ROSE-T 支持 Cisco IOS-XR 和 Juniper JunOS，但我们正在努力将支持扩展到其他供应商的套件。
图 7 — 我们使用 Kathará 语法将中间表示转换为可运行的网络场景。
我们还在仿真中插入了两台将在下一步使用的客户端机器 - 一台在候选 AS 中，一台在“Internet”AS 中（图 8）。
图 8——用于执行反欺骗和过滤检查的最小模拟网络。
第 5 步 — 验证
等待BGP收敛后，我们可以进行反欺骗和过滤验证。
我们从反欺骗开始，该操作在网络中的每个提供商上执行（下图中的绿色路由器）。首先，我们在提供商 AS 内插入一台客户端机器。然后，我们为网络中的每个客户端分配 IPv4 / IPv6 地址（图 9）。分配过程中有两个主要挑战：
从我们掌握的信息中选择正确通告并且相互可达的子网。
选择一个有效的随机 IP 子网，分配给将充当恶意子网的“Internet”主机。此类子网不得与网络中公布的其他前缀重叠。
图 9 — 网络已准备好对 AS B 执行反欺骗检查。
图中，每个客户端都分配有一个 IPv4 地址。“Internet”客户端充当恶意主机（欺骗数据包的来源）。
此时，我们执行实际检查。我们在“Internet”主机接口上放置一个 tcpdump 来嗅探数据包。使用 Scapy，我们从候选客户端主机制作一个 ICMP 数据包。该数据包以欺骗 IP 作为源，以提供程序客户端 IP 作为目标。发送数据包时可能出现两种情况：
它从候选路由器转发到提供商。在这种情况下，我们检查“Internet”客户端是否收到数据包。如果是，则配置不合规。
候选路由器正确阻止了欺骗数据包。如果是这样，则数据包不会被“Internet”客户端接收，并且配置符合要求。
作为双重检查，我们验证合法数据包是否从提供商客户端正确转发/接收（图 10）。
图 10 — 左侧，候选 AS A 未对发往提供商 AS B 的欺骗数据包实施正确的过滤，因此数据包到达恶意主机。
在这种情况下，配置无效。右侧，候选 AS A 过滤掉发往提供商 AS B 的欺骗数据包。因此，它符合反欺骗检查。针对 IPv6 重复此过程。
对每个客户执行过滤检查（图 11，绿色路由器）。首先，我们选择客户向候选人宣布的恶意子网。至于反欺骗检查，我们选择一个有效的随机 IP 子网，该子网不得与网络中宣布的其他前缀重叠。接下来，我们等待 BGP 公告传播，此时恶意前缀为：
从候选者传播到提供商。在这种情况下，我们检查每个提供商上的 FRRouting 控制平面，以验证是否已收到公告。如果是，则意味着配置不合规；
经过候选过滤，如果是，则表示配置符合要求。
图 11 — 左侧，候选 AS A 未实施对错误客户公告的正确过滤。
在这种情况下，配置无效。右侧，候选者过滤掉虚假公告。因此，它符合过滤检查。对 IPv6 重复此过程。
接下来是什么？
我们目前正在致力于将验证从单个路由器扩展到多个路由器，同时考虑 iBGP 对等。
接下来我们计划将验证扩展到另外两个计划（互联网交换点和CDN/云提供商）。
未来，ROSE-T 可以扩展用于其他用途，例如验证 RPKI 部署或自治系统提供商授权 ( ASPA ) 验证，或者可以发布证书以提供特定网络符合 MANRS 的有形证据。
本站全部资讯来源于实验室原创、合作机构投稿及网友汇集投稿，仅代表个人观点，不作为任何依据，转载联系作者并注明出处：https://www.lvsky.net/146.html
评论