Suicide
06.04.2020, 20:43
В результате ошибочного BGP-анонса более 8800 чужих сетевых префиксов оказались (https://www.manrs.org/2020/04/not-just-another-bgp-hijack/) перенаправлены (https://blog.qrator.net/ru/deal-route-leaks_70/) через сеть Ростелекома, что привело к кратковременному коллапсу маршрутизации, нарушению связности сетей и проблемам с доступом к некоторым сервисам по всему миру. Проблема охватила (https://map.internetintel.oracle.com/api/leak_prefixes/20764_12389_1585768500.pfxs) более 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 (https://ru.wikipedia.org/wiki/Tier-1-%D0%BE%D0%BF%D0%B5%D1%80%D0%B0%D1%82%D0%BE%D1%80%D 1%8B)). Сервисы (https://bgpmon.net/) мониторинга (https://radar.qrator.net/) BGP оперативно уведомили Ростелеком о проблеме, поэтому инцидент продолжался около 10 минут (по другим данным (https://blog.qrator.net/en/how-you-deal-route-leaks_69/) последствия наблюдались около часа).
Это не первый инцидент, связанный с ошибкой на стороне Ростелекома. В 2017 году в течение 5-7 минут через Ростелеком были перенаправлены (https://www.opennet.ru/opennews/art.shtml?num=46469) сети крупнейших банков и финансовых сервисов, включая Visa и MasterCard. Судя по всему, в обоих инцидентах источником проблемы послужили (https://twitter.com/atoonk/status/1246852111586848768) работы, связанные с управлением трафиком, например, утечка маршрутов могла возникнуть при организации внутреннего мониторинга, приоритизации или зеркалирования проходящего через Ростелеком трафика определённых сервисов и CDN (в связи с ростом нагрузки на сеть из-за массовой работы на дому в конце марта обсуждался (https://www.kommersant.ru/doc/4308991) вопрос понижения приоритета для трафика зарубежных сервисов в пользу отечественных ресурсов). Например, несколько лет назад предпринятая в Пакистане попытка заворачивания (https://www.defcon.org/images/defcon-16/dc16-presentations/defcon-16-pilosov-kapela.pdf) подсетей YouTube на null-интерфейс привела к появлению этих подсетей в BGP анонсах и стеканию всего трафика YouTube в Пакистан.
https://www.opennet.ru/opennews/pics_base/0_1586161001.jpg (https://twitter.com/bgpmon/status/1246842916502302723)
Интересно, что за день до инцидента с Ростелекомом мелким провайдером "Новая Реальность" (AS50048) из г. Шумерля (https://ru.wikipedia.org/wiki/%D0%A8%D1%83%D0%BC%D0%B5%D1%80%D0%BB%D1%8F) через Транстелеком было анонсировано (https://blog.qrator.net/en/serious-times-serious-leaks_68/) 2658 префиксов, затрагивающих Orange, Akamai, Ростелеком и сети ещё более 300 компаний. Утечка маршрутов привела к возникновению нескольких волн перенаправлений трафика, продолжительностью несколько минут. На пике проблема охватывала до 13.5 млн IP-адресов. Заметного глобального сбоя удалось избежать благодаря применению в Транстелекоме органичений маршрутов для каждого клиента.
Подобные инциденты возникают в глобальной Сети регулярно (https://bgpmon.net/) и будут продолжаться, пока повсеместно не будут внедрены методы авторизации (https://www.opennet.ru/opennews/art.shtml?num=47303) BGP-анонсов на основе RPKI (BGP Origin Validation), разрешающие приём анонсов только от владельцев сети. Без применения авторизации любой оператор может анонсировать подсеть с фиктивными сведениями о длине маршрута и инициировать транзит через себя части трафика от других систем, не применяющих фильтрацию анонсов.
При этом, в рассматриваемом инциденте проверка с использованем RPKI-репозитория RIPE оказалась бесполезной (https://www.ripe.net/ripe/mail/archives/routing-wg/2020-April/004083.html). По стечению обстоятельств за три часа до утечки BGP-маршрута в Ростелекоме в процессе обновления программного обеспечения RIPE было случайно удалено (https://www.ripe.net/support/service-announcements/accidental-roa-deletion) 4100 ROA-записей (RPKI Route Origin Authorisation). База была восстановлена только 2 апреля и всё это время для клиентов RIPE проверка находилась в неработоспособном виде (проблема не затронула RPKI-репозитории других регистраторов). Сегодня у RIPE возникли новые проблемы и репозиторий RPKI в течение 7 часов был недоступен (https://www.ripe.net/support/service-announcements/rsync-rpki-repository-downtime).
В качестве решения для блокирования утечек также можно применять фильтрацию на основе реестра IRR (https://en.wikipedia.org/wiki/Internet_Routing_Registry) (Internet Routing Registry), который определяет автономные системы через которые допустима маршрутизация заданных префиксов. При взаимодействии с небольшими операторами для снижения последствий ошибок персонала можно ограничить максимально допустимое число принимаемых префиксов для сеансов EBGP (настройка maximum-prefix).
В большинстве случаев инциденты являются следствием случайных ошибок персонала, но в последнее время встречаются и целевые атаки, в ходе которых злоумышленники путём компрометации инфраструктуры провайдеров организуют (https://www.opennet.ru/opennews/art.shtml?num=48679) перенаправление (https://www.opennet.ru/opennews/art.shtml?num=48494) и перехват (https://www.opennet.ru/opennews/art.shtml?num=48889) трафика для подмены (https://www.opennet.ru/opennews/art.shtml?num=38489) конкретных сайтов через организацию MiTM-атаки для замены ответов DNS. Для усложнения получения TLS-сертификатов при проведении подобных атак удостоверяющий центр Let's Encrypt недавно перешёл (https://www.opennet.ru/opennews/art.shtml?num=52419) к многопозиционной проверке доменов с использованием разных подсетей. Для обхода данной проверки атакующему потребуется одновременно добиться перенаправления маршрутов для нескольких автономных систем провайдеров с разными аплинками, что значительно сложнее, чем перенаправление единичного маршрута.
06.04.2020
https://www.opennet.ru/opennews/art.shtml?num=52680
Ошибочный анонс был произведён Ростелекомом (AS12389) 1 апреля в 22:28 (MSK), затем был подхвачен провайдером Rascom (AS20764) и далее по цепочке распространился в Cogent (AS174) и Level3 (AS3356), поле чего охватил почти всех интернет-провайдеров первого уровня (Tier-1 (https://ru.wikipedia.org/wiki/Tier-1-%D0%BE%D0%BF%D0%B5%D1%80%D0%B0%D1%82%D0%BE%D1%80%D 1%8B)). Сервисы (https://bgpmon.net/) мониторинга (https://radar.qrator.net/) BGP оперативно уведомили Ростелеком о проблеме, поэтому инцидент продолжался около 10 минут (по другим данным (https://blog.qrator.net/en/how-you-deal-route-leaks_69/) последствия наблюдались около часа).
Это не первый инцидент, связанный с ошибкой на стороне Ростелекома. В 2017 году в течение 5-7 минут через Ростелеком были перенаправлены (https://www.opennet.ru/opennews/art.shtml?num=46469) сети крупнейших банков и финансовых сервисов, включая Visa и MasterCard. Судя по всему, в обоих инцидентах источником проблемы послужили (https://twitter.com/atoonk/status/1246852111586848768) работы, связанные с управлением трафиком, например, утечка маршрутов могла возникнуть при организации внутреннего мониторинга, приоритизации или зеркалирования проходящего через Ростелеком трафика определённых сервисов и CDN (в связи с ростом нагрузки на сеть из-за массовой работы на дому в конце марта обсуждался (https://www.kommersant.ru/doc/4308991) вопрос понижения приоритета для трафика зарубежных сервисов в пользу отечественных ресурсов). Например, несколько лет назад предпринятая в Пакистане попытка заворачивания (https://www.defcon.org/images/defcon-16/dc16-presentations/defcon-16-pilosov-kapela.pdf) подсетей YouTube на null-интерфейс привела к появлению этих подсетей в BGP анонсах и стеканию всего трафика YouTube в Пакистан.
https://www.opennet.ru/opennews/pics_base/0_1586161001.jpg (https://twitter.com/bgpmon/status/1246842916502302723)
Интересно, что за день до инцидента с Ростелекомом мелким провайдером "Новая Реальность" (AS50048) из г. Шумерля (https://ru.wikipedia.org/wiki/%D0%A8%D1%83%D0%BC%D0%B5%D1%80%D0%BB%D1%8F) через Транстелеком было анонсировано (https://blog.qrator.net/en/serious-times-serious-leaks_68/) 2658 префиксов, затрагивающих Orange, Akamai, Ростелеком и сети ещё более 300 компаний. Утечка маршрутов привела к возникновению нескольких волн перенаправлений трафика, продолжительностью несколько минут. На пике проблема охватывала до 13.5 млн IP-адресов. Заметного глобального сбоя удалось избежать благодаря применению в Транстелекоме органичений маршрутов для каждого клиента.
Подобные инциденты возникают в глобальной Сети регулярно (https://bgpmon.net/) и будут продолжаться, пока повсеместно не будут внедрены методы авторизации (https://www.opennet.ru/opennews/art.shtml?num=47303) BGP-анонсов на основе RPKI (BGP Origin Validation), разрешающие приём анонсов только от владельцев сети. Без применения авторизации любой оператор может анонсировать подсеть с фиктивными сведениями о длине маршрута и инициировать транзит через себя части трафика от других систем, не применяющих фильтрацию анонсов.
При этом, в рассматриваемом инциденте проверка с использованем RPKI-репозитория RIPE оказалась бесполезной (https://www.ripe.net/ripe/mail/archives/routing-wg/2020-April/004083.html). По стечению обстоятельств за три часа до утечки BGP-маршрута в Ростелекоме в процессе обновления программного обеспечения RIPE было случайно удалено (https://www.ripe.net/support/service-announcements/accidental-roa-deletion) 4100 ROA-записей (RPKI Route Origin Authorisation). База была восстановлена только 2 апреля и всё это время для клиентов RIPE проверка находилась в неработоспособном виде (проблема не затронула RPKI-репозитории других регистраторов). Сегодня у RIPE возникли новые проблемы и репозиторий RPKI в течение 7 часов был недоступен (https://www.ripe.net/support/service-announcements/rsync-rpki-repository-downtime).
В качестве решения для блокирования утечек также можно применять фильтрацию на основе реестра IRR (https://en.wikipedia.org/wiki/Internet_Routing_Registry) (Internet Routing Registry), который определяет автономные системы через которые допустима маршрутизация заданных префиксов. При взаимодействии с небольшими операторами для снижения последствий ошибок персонала можно ограничить максимально допустимое число принимаемых префиксов для сеансов EBGP (настройка maximum-prefix).
В большинстве случаев инциденты являются следствием случайных ошибок персонала, но в последнее время встречаются и целевые атаки, в ходе которых злоумышленники путём компрометации инфраструктуры провайдеров организуют (https://www.opennet.ru/opennews/art.shtml?num=48679) перенаправление (https://www.opennet.ru/opennews/art.shtml?num=48494) и перехват (https://www.opennet.ru/opennews/art.shtml?num=48889) трафика для подмены (https://www.opennet.ru/opennews/art.shtml?num=38489) конкретных сайтов через организацию MiTM-атаки для замены ответов DNS. Для усложнения получения TLS-сертификатов при проведении подобных атак удостоверяющий центр Let's Encrypt недавно перешёл (https://www.opennet.ru/opennews/art.shtml?num=52419) к многопозиционной проверке доменов с использованием разных подсетей. Для обхода данной проверки атакующему потребуется одновременно добиться перенаправления маршрутов для нескольких автономных систем провайдеров с разными аплинками, что значительно сложнее, чем перенаправление единичного маршрута.
06.04.2020
https://www.opennet.ru/opennews/art.shtml?num=52680