Утечка BGP-маршрута в Ростелекоме привела к нарушению связности крупнейших сетей

В результате ошибочного BGP-анонса более 8800 чужих сетевых префиксов оказались перенаправлены через сеть Ростелекома, что привело к кратковременному коллапсу маршрутизации, нарушению связности сетей и проблемам с доступом к некоторым сервисам по всему миру. Проблема охватила более 200 автономных систем, принадлежащих крупным интернет-компаниям и сетям доставки контента, включая Akamai, Cloudflare, Digital Ocean, Amazon AWS, Hetzner, Level3, Facebook, Alibaba и Linode.

Ошибочный анонс был произведён Ростелекомом (AS12389) 1 апреля в 22:28 (MSK), затем был подхвачен провайдером Rascom (AS20764) и далее по цепочке распространился в Cogent (AS174) и Level3 (AS3356), поле чего охватил почти всех интернет-провайдеров первого уровня (Tier-1). Сервисы мониторинга BGP оперативно уведомили Ростелеком о проблеме, поэтому инцидент продолжался около 10 минут (по другим данным последствия наблюдались около часа).

Это не первый инцидент, связанный с ошибкой на стороне Ростелекома. В 2017 году в течение 5-7 минут через Ростелеком были перенаправлены сети крупнейших банков и финансовых сервисов, включая Visa и MasterCard. Судя по всему, в обоих инцидентах источником проблемы послужили работы, связанные с управлением трафиком, например, утечка маршрутов могла возникнуть при организации внутреннего мониторинга, приоритизации или зеркалирования проходящего через Ростелеком трафика определённых сервисов и CDN (в связи с ростом нагрузки на сеть из-за массовой работы на дому в конце марта обсуждался вопрос понижения приоритета для трафика зарубежных сервисов в пользу отечественных ресурсов). Например, несколько лет назад предпринятая в Пакистане попытка заворачивания подсетей YouTube на null-интерфейс привела к появлению этих подсетей в BGP анонсах и стеканию всего трафика YouTube в Пакистан.

Интересно, что за день до инцидента с Ростелекомом мелким провайдером «Новая Реальность» (AS50048) из г. Шумерля через Транстелеком было анонсировано 2658 префиксов, затрагивающих Orange, Akamai, Ростелеком и сети ещё более 300 компаний. Утечка маршрутов привела к возникновению нескольких волн перенаправлений трафика, продолжительностью несколько минут. На пике проблема охватывала до 13.5 млн IP-адресов. Заметного глобального сбоя удалось избежать благодаря применению в Транстелекоме органичений маршрутов для каждого клиента.

Подобные инциденты возникают в глобальной Сети регулярно и будут продолжаться, пока повсеместно не будут внедрены методы авторизации BGP-анонсов на основе RPKI (BGP Origin Validation), разрешающие приём анонсов только от владельцев сети. Без применения авторизации любой оператор может анонсировать подсеть с фиктивными сведениями о длине маршрута и инициировать транзит через себя части трафика от других систем, не применяющих фильтрацию анонсов.

При этом, в рассматриваемом инциденте проверка с использованем RPKI-репозитория RIPE оказалась бесполезной. По стечению обстоятельств за три часа до утечки BGP-маршрута в Ростелекоме в процессе обновления программного обеспечения RIPE было случайно удалено 4100 ROA-записей (RPKI Route Origin Authorisation). База была восстановлена только 2 апреля и всё это время для клиентов RIPE проверка находилась в неработоспособном виде (проблема не затронула RPKI-репозитории других регистраторов). Сегодня у RIPE возникли новые проблемы и репозиторий RPKI в течение 7 часов был недоступен.

В качестве решения для блокирования утечек также можно применять фильтрацию на основе реестра IRR (Internet Routing Registry), который определяет автономные системы через которые допустима маршрутизация заданных префиксов. При взаимодействии с небольшими операторами для снижения последствий ошибок персонала можно ограничить максимально допустимое число принимаемых префиксов для сеансов EBGP (настройка maximum-prefix).

В большинстве случаев инциденты являются следствием случайных ошибок персонала, но в последнее время встречаются и целевые атаки, в ходе которых злоумышленники путём компрометации инфраструктуры провайдеров организуют перенаправление и перехват трафика для подмены конкретных сайтов через организацию MiTM-атаки для замены ответов DNS.
Для усложнения получения TLS-сертификатов при проведении подобных атак удостоверяющий центр Let’s Encrypt недавно перешёл к многопозиционной проверке доменов с использованием разных подсетей. Для обхода данной проверки атакующему потребуется одновременно добиться перенаправления маршрутов для нескольких автономных систем провайдеров с разными аплинками, что значительно сложнее, чем перенаправление единичного маршрута.

Источник: opennet.ru