Витік 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), чого першого рівня (Рівень-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