由于错误的 BGP 公告，超过 8800 个外国网络前缀 通过 Rostelecom 网络，导致短期路由崩溃、网络连接中断以及世界各地某些服务的访问问题。 问题 主要互联网公司和内容交付网络拥有的 200 多个自治系统，包括 Akamai、Cloudflare、Digital Ocean、Amazon AWS、Hetzner、Level3、Facebook、阿里巴巴和 Linode。
该错误公告由 Rostelecom (AS12389) 于 1 月 22 日 28:20764 (MSK) 发布，随后由提供商 Rascom (AS174) 发现，并沿着链条进一步传播到 Cogent (AS3) 和 Level3356 (ASXNUMX) ，其领域几乎覆盖了所有互联网提供商一级（). BGP及时向Rostelecom通报了该问题，因此该事件持续了大约10分钟（根据 观察效果约一个小时）。
这并不是 Rostelecom 方面第一次出现错误。 2017 年，通过 Rostelecom 5-7 分钟内 最大的银行和金融服务网络，包括 Visa 和 MasterCard。 在这两起事件中，问题的根源似乎都是 与流量管理相关的工作，例如，在为某些服务和 CDN 组织内部监控、优先级或镜像经过 Rostelecom 的流量时，可能会发生路由泄漏（由于年底大量在家工作导致网络负载增加）行进 降低外国服务流量优先级以支持国内资源的问题）。 例如，几年前在巴基斯坦进行了一次尝试 空接口上的 YouTube 子网导致这些子网出现在 BGP 公告中以及所有 YouTube 流量流向巴基斯坦。
有趣的是，在 Rostelecom 事件发生的前一天，来自该市的小型提供商“New Reality”（AS50048）。 通过 Transtelecom 是 2658 个前缀影响 Orange、Akamai、Rostelecom 以及 300 多家公司的网络。 路由泄漏导致了几波持续几分钟的流量重定向。 在高峰期，该问题影响了多达 13.5 万个 IP 地址。 由于 Transtelecom 对每个客户使用路线限制，避免了明显的全球中断。
类似事件在网上也时有发生 并将持续下去，直至在各地实施 基于 RPKI（BGP 起源验证）的 BGP 公告，仅允许接收来自网络所有者的公告。 在未经授权的情况下，任何运营商都可以使用有关路由长度的虚构信息来通告子网，并启动来自不应用通告过滤的其他系统的部分流量通过其自身进行传输。
与此同时，在所考虑的事件中，使用 RIPE RPKI 存储库进行的检查结果是 。 巧合的是，在Rostelecom BGP路由泄露的前三个小时，在更新RIPE软件的过程中， 4100 ROA 记录（RPKI 路由始发地授权）。 数据库直到 2 月 7 日才恢复，并且一直以来对 RIPE 客户端的检查都无法进行（该问题并未影响其他注册商的 RPKI 存储库）。 今天 RIPE XNUMX 小时内有新问题和 RPKI 存储库 .
基于注册表的过滤也可以用作阻止泄漏的解决方案 （互联网路由注册），它定义了允许指定前缀路由的自治系统。 与小型运营商交互时，为了减少人为错误的影响，您可以限制 EBGP 会话可接受的前缀的最大数量（最大前缀设置）。
在大多数情况下，事件是由于意外的人员错误造成的，但最近也出现了有针对性的攻击，攻击者破坏了提供商的基础设施 и 流量为 通过组织 MiTM 攻击来替换特定站点的 DNS 响应。
为了让在此类攻击期间获取 TLS 证书变得更加困难，Let's Encrypt 证书颁发机构 使用不同子网进行多位置域检查。 为了绕过此检查，攻击者需要同时为具有不同上行链路的提供商的多个自治系统实现路由重定向，这比重定向单个路由要困难得多。
来源： opennet.ru