Представьте, что кто-то объявил всему интернету, будто дорога к вашему серверу теперь проходит через чужую сеть. Уведомление выглядит правдоподобно, маршрутизаторы принимают новые сведения, и часть пользователей внезапно попадает совсем не туда, куда собиралась. Никакого взлома сервера, кражи DNS-пароля или заражения компьютера для такого перенаправления может не потребоваться.
Так работают некоторые атаки на BGP (Border Gateway Protocol), протокол, с помощью которого автономные системы обмениваются маршрутам
и между сетями. Если злоумышленнику удаётся распространить ложный маршрут, интернет-трафик может уйти через постороннюю инфраструктуру, исчезнуть в сетевой «чёрной дыре» или попасть на подставной сервер.
Проблема не ограничивается действиями атакующих. Неправильная настройка одного маршрутизатора способна разослать чужие маршруты тысячам сетей. Причём для пользователя преднамеренная атака и обычная ошибка оператора часто выглядят одинаково. Сайт недоступен, соединение обрывается, а привычный путь пакетов изменился.
Защищаться от подобных инцидентов научились значительно лучше. RPKI и проверка происхождения маршрутов ROV позволяют отбрасывать многие недостоверные объявления. Механизмы ASPA и BGP Roles помогают бороться с утечками маршрутов. Но универсальной защиты пока нет, а некоторые атаки проходят даже при корректно работающей криптографической проверке.
Начать проверку можно без собственной автономной системы. Например, публичный интерфейс RIPEstat позволяет узнать, соответствует ли конкретное объявление опубликованным разрешениям RPKI.
curl -sS "https://stat.ripe.net/data/rpki-validation/data.json?resource=3333&prefix=193.0.0.0/21" | jq '.data | {status, description}'Команда проверяет пару «номер автономной системы и IP-префикс» по данным валидатора RIPE NCC. В ответе появится статус проверки. Результат отражает состояние доступных валидатору данных на момент запроса, а не гарантирует, что маршрут действительно проходит через указанную сеть.
Примеры конфигурации предназначены для собственных автономных систем, учебных стендов и сетей, на администрирование которых получено разрешение. Проверять чужие объявления по открытым данным можно без вмешательства в маршрутизацию. Публиковать экспериментальные маршруты в глобальный BGP нельзя без согласования с оператором и владельцем адресного пространства.
Почему BGP позволяет перехватывать маршруты
BGP создавался как протокол обмена информацией между самостоятельными сетями. У каждой автономной системы есть номер ASN, собственные правила маршрутизации и соседние сети, с которыми установлены BGP-сессии.
Когда оператор сообщает соседям, что через его сеть доступен определённый диапазон адресов, сообщение передаётся дальше в соответствии с политикой других участников. Вместе с IP-префиксом распространяются атрибуты маршрута, включая AS_PATH, последовательность автономных систем, через которые прошло объявление.
Историческая слабость BGP заключается в отсутствии встроенной криптографической проверки права объявлять конкретные IP-адреса и достоверности всей цепочки AS_PATH. Установленное соседство подтверждает наличие BGP-сессии с определённым участником, но само по себе не доказывает законность каждого полученного маршрута.
Современные сети давно не обязаны безоговорочно принимать объявления соседей. Операторы применяют фильтры, ограничения, RPKI и дополнительные политики. Тем не менее ошибки в настройках и неполная проверка маршрутов оставляют возможности для атак.
BGP Hijacking и подмена IP-префиксов
BGP Hijacking называют несанкционированное распространение маршрута к чужому адресному пространству. Часто атакующий пытается выдать свою автономную систему за источник маршрута либо подделывает AS_PATH, чтобы объявление выглядело легитимным.
Рассмотрим условный пример. Компания использует автономную систему AS64500 и адресный диапазон 203.0.113.0/24. Другая сеть AS64599 начинает распространять объявление к тому же диапазону.
Законный маршрут
203.0.113.0/24
Origin AS64500
Чужой маршрут
203.0.113.0/24
Origin AS64599Если часть интернета примет чужое объявление и предпочтёт соответствующий путь, трафик к 203.0.113.0/24 начнёт поступать в AS64599. При объявлении одинаковых по длине префиксов исход зависит от локальной политики BGP и атрибутов маршрутов. Поэтому одинаковая подмена не обязательно действует на весь интернет.
Более опасный вариант связан с объявлением более специфичного префикса. Например, владелец публикует маршрут 203.0.112.0/23, а посторонняя сеть объявляет 203.0.113.0/24.
Законный маршрут
203.0.112.0/23 → AS64500
Поддельный маршрут
203.0.113.0/24 → AS64599При пересылке пакетов маршрутизатор выбирает наиболее специфичное совпадение, известное как Longest Prefix Match. Поэтому принятый маршрут /24 будет использоваться для соответствующих адресов вместо более общего /23, даже если маршрут /23 имеет предпочтительные атрибуты BGP.
Сначала маршрутизатор должен принять объявление и признать путь пригодным. Фильтры, RPKI и ограничения на длину префиксов способны остановить подмену ещё до установки маршрута.
В публичном IPv4-интернете префиксы длиннее /24 многие операторы отбрасывают. Для IPv6 распространённой границей глобальных анонсов служит /48. Такие ограничения уменьшают возможности атаки, но не устраняют риск подмены более специфичных маршрутов в пределах разрешённых размеров.
Route Leak и нарушение отношений между сетями
BGP Route Leak отличается от перехвата происхождения маршрута. Автономная система может распространять совершенно настоящий маршрут, но передавать сведения тем соседям, которым по принятой политике передавать маршрут нельзя.
Обычный пример связан с небольшой сетью, подключённой к двум провайдерам. Клиент получает от первого провайдера маршруты интернета и по ошибке начинает экспортировать полученные объявления второму.
AS65001
Провайдер A
|
| Маршруты интернета
v
AS65010
Клиент
|
| Ошибочный экспорт
v
AS65002
Провайдер BВ результате второй провайдер может выбрать путь через сеть клиента. Небольшая инфраструктура внезапно становится транзитной для трафика, который никогда не должна была обслуживать.
Последствия зависят от того, сколько сетей примут ошибочное объявление. Иногда маршруты просто становятся длиннее. Иногда возникают задержки, перегрузки, потери пакетов и недоступность крупных сервисов.
ROV в типичном случае не распознаёт подобную утечку. Исходная автономная система остаётся законным источником IP-префикса, а проверка RPKI не устанавливает, имел ли промежуточный участник право передавать маршрут конкретному соседу.
Проверка AS_PATH на наличие собственной автономной системы помогает предотвращать простые петли маршрутизации, но не гарантирует соблюдение коммерческих и технических отношений между операторами.
Что может получить атакующий
Перенаправление BGP-маршрута само по себе не означает, что злоумышленник сможет прочитать содержимое защищённого HTTPS-соединения. Шифрование TLS продолжает защищать данные, если клиент корректно проверяет сертификат, а атакующий не получил возможность выдать действительный сертификат или скомпрометировать доверенную сторону.
Однако последствия перехвата выходят далеко за пределы обычного отказа в обслуживании. Чужой маршрут может позволить атакующему наблюдать сетевые метаданные и незашифрованный трафик, организовать отказ в обслуживании, перенаправить отдельные протоколы на подставные системы или вмешаться в проверки владения доменом. При определённых условиях BGP Hijacking превращается в полноценную атаку посредника, известную как Man-in-the-Middle.
При этом атакующему не всегда требуется длительно контролировать маршрут. Иногда достаточно короткого интервала, чтобы нарушить работу сервиса или пройти автоматическую проверку, которая полагается на доступность определённого IP-адреса.
Реальные случаи, когда BGP подвёл интернет
История междоменной маршрутизации показывает, насколько по-разному могут развиваться инциденты. Ошибка фильтра превращает небольшую сеть в нежелательный транзит, компрометация учётной записи нарушает работу RPKI, а целенаправленная подмена маршрута позволяет атаковать цепочку поставки программного обеспечения.
MyEtherWallet, 2018 год. Перехват DNS через чужие маршруты
В апреле 2018 года атакующие использовали BGP-перехват маршрутов к части инфраструктуры Amazon Route 53. Целью стали DNS-запросы, связанные с криптовалютным кошельком MyEtherWallet.
Подменённый маршрут направлял часть DNS-трафика к посторонней инфраструктуре. Поддельный DNS-сервер отвечал неправильными адресами и перенаправлял пользователей на мошенническую страницу.
Посетители могли увидеть предупреждение о проблеме с TLS-сертификатом. Пользователи, проигнорировавшие предупреждение и передавшие секретные данные поддельному сайту, рисковали потерять криптовалюту.
Инцидент продемонстрировал опасное сочетание BGP Hijacking, подмены DNS и социальной инженерии. Маршрутизация обеспечивала доставку запросов к атакующему, а дальнейший успех зависел от поведения пользователей и защиты прикладного протокола.
Google, 2018 год. Ошибка отправила маршруты через другие страны
12 ноября 2018 года интернет-провайдер MainOne из Нигерии допустил ошибку в фильтрах BGP во время работ на сети. В глобальную маршрутизацию попали маршруты, связанные с инфраструктурой Google.
Некоторые пути к сервисам Google начали проходить через China Telecom и другие транзитные сети, включая оператора из России. Инцидент продолжался около 74 минут и вызвал проблемы с доступностью сервисов.
Первые сообщения выглядели тревожно из-за необычной географии маршрутов, однако MainOne признала ошибку конфигурации. Подтверждений преднамеренной атаки представлено не было.
Случай хорошо показывает, почему нельзя автоматически считать всякое отклонение AS_PATH доказательством кибератаки. Одна и та же техническая аномалия может возникнуть из-за взлома, ошибочной политики экспорта или неудачного обновления конфигурации.
Verizon и Cloudflare, 2019 год. Ошибка одной сети затронула тысячи маршрутов
24 июня 2019 года неправильное распространение BGP-маршрутов через несколько автономных систем и транзитного провайдера Verizon вызвало масштабный сбой.
В цепочке участвовали DQE Communications, клиентская сеть Allegheny Technologies и Verizon. Дополнительную роль сыграло решение для оптимизации BGP-маршрутов, связанное с Noction.
В интернет попали более специфичные маршруты, которые не должны были распространяться таким образом. Часть трафика направилась через инфраструктуру, не рассчитанную на подобную нагрузку.
Cloudflare сообщала, что в худший момент потеряла около 15% глобального трафика. Пострадали и другие сервисы, включая ресурсы Amazon и Linode.
Проблема состояла не в подмене исходной автономной системы для каждого затронутого префикса, а в неправильном распространении маршрутов. Подобную аварию нельзя исправить одной только проверкой ROA.
Orange España, 2024 год. Атака на управление RPKI
3 января 2024 года Orange España столкнулась с крупным нарушением связи после компрометации учётной записи в системе управления интернет-ресурсами RIPE NCC.
Злоумышленник воспользовался скомпрометированными учётными данными и изменил RPKI-настройки оператора. В результате часть законных маршрутов Orange получила статус RPKI Invalid.
Операторы, отбрасывавшие такие объявления, перестали использовать соответствующие маршруты. Механизм защиты от поддельных анонсов фактически усилил последствия компрометации административного доступа.
Случай Orange показывает отдельный риск. Криптографическая проверка маршрутов полезна лишь при условии, что злоумышленник не контролирует систему, выпускающую подписанные разрешения.
Virtualizor, 2026 год. BGP-перехват превратился в атаку на обновления
С 28 по 30 августа 2026 года злоумышленники перенаправляли трафик к диапазону 162.55.80.0/24, который использовался системами Softaculous и Virtualizor в инфраструктуре Hetzner.
По опубликованному разбору инцидента, незаконный анонс появился через AS62390 и передавался через AS6204. В AS_PATH при этом сохранялся AS24940, принадлежащий Hetzner, в качестве предполагаемого источника маршрута.
Законный маршрут Hetzner охватывал более крупный диапазон 162.55.0.0/16. Поддельный /24 был специфичнее, поэтому сети, которые принимали объявление, направляли трафик по ложному пути.
Дальше произошло самое неприятное. Атакующие получили действительный TLS-сертификат для доменов Softaculous, поскольку автоматическая проверка владения доменом также проходила через перехваченную маршрутизацию. Пользователи не обязательно видели предупреждения о сертификате.
Злоумышленникам удалось доставить вредоносное обновление небольшому числу установок Virtualizor. Разработчик подтвердил инцидент, после чего начал подписывать программные пакеты и ответы API.
Ещё интереснее поведение RPKI. В момент атаки разрешение ROA для диапазона Hetzner допускало анонсы вплоть до /24, а поддельный AS_PATH содержал легитимную AS24940 как Origin AS. Проверка происхождения могла присвоить ложному объявлению статус Valid.
После расследования Hetzner ужесточила ROA для затронутого диапазона, ограничив разрешённую длину префикса. Появилась также информация о публикации ASPA для AS24940.
Случай Virtualizor разрушает распространённый миф. Даже наличие RPKI Valid не доказывает, что весь AS_PATH подлинный. ROV подтверждает соответствие объявления разрешённому источнику, но не удостоверяет каждое промежуточное звено.
RPKI, ROA, ROV и другие механизмы защиты BGP
Сетевая безопасность не сводится к одному расширению BGP. Разные технологии проверяют разные свойства маршрута. Одни контролируют право объявлять IP-префикс, другие ограничивают передачу маршрутов между клиентами и провайдерами, третьи пытаются подтвердить подлинность AS_PATH.
RPKI и ROA. Кто имеет право объявлять адреса
RPKI (Resource Public Key Infrastructure) представляет собой инфраструктуру сертификатов для интернет-ресурсов. С помощью цифровых подписей владелец адресного пространства может публиковать проверяемые сведения о том, какие автономные системы вправе объявлять его IP-префиксы.
Основной объект для проверки происхождения маршрутов называется ROA (Route Origin Authorization). В нём указываются IP-префикс, разрешённая автономная система и максимальная длина объявляемого префикса.
Например, владелец 203.0.113.0/24 разрешает объявлять диапазон только AS64500.
ROA
Prefix 203.0.113.0/24
Origin AS 64500
MaxLength 24Если другая автономная система объявит тот же /24 под собственным номером, проверка обнаружит несоответствие. Однако само существование ROA ещё не блокирует маршрут. Блокировку выполняют маршрутизаторы операторов, которые используют данные RPKI в своей политике маршрутизации.
ROV (Route Origin Validation) сопоставляет полученное BGP-объявление с проверенными разрешениями RPKI.
| Статус ROV | Что означает | Типичное действие |
|---|---|---|
| Valid | Есть разрешение для данного источника и длины префикса | Допустить дальнейшую обработку маршрута |
| Invalid | Есть покрывающее разрешение, но ASN или длина префикса ему противоречат | Отклонить объявление |
| NotFound | Подходящего проверенного разрешения нет | Обычно принимать с остальными фильтрами |
Статус NotFound не равнозначен доказанной атаке. Отсутствие ROA означает недостаток криптографических сведений, а не автоматическое признание маршрута незаконным. Массовое отклонение всех NotFound способно нарушить доступность законных сетей.
Статус Invalid тоже требует внимательного расследования. Ошибочная настройка ROA, просроченный переход на другую AS или забытый маршрут резервного провайдера могут превратить собственный законный анонс в Invalid.
Почему maxLength имеет значение
Самая опасная ошибка при создании ROA часто выглядит совершенно безобидно. Владелец разрешает AS объявлять диапазон /16, но указывает максимальную длину /24 на случай будущего дробления сети.
Широкое разрешение
Prefix 203.0.0.0/16
Origin AS 64500
MaxLength 24Подобная запись разрешает AS64500 объявлять не только исходный /16, но и многочисленные более специфичные префиксы внутри диапазона, вплоть до /24.
Если атакующий подделает AS_PATH так, чтобы в качестве источника выглядела AS64500, незаявленный ранее более специфичный маршрут может пройти ROV.
Поэтому RFC 9319 рекомендует по возможности использовать минимальные ROA и избегать неоправданно широкого maxLength. Если оператор действительно объявляет /16 и несколько отдельных /24, разумнее явно разрешить необходимые префиксы, чем автоматически позволить объявлять все возможные /24.
Когда maxLength отсутствует, разрешённая максимальная длина совпадает с длиной указанного префикса.
Слишком строгая настройка тоже создаёт проблемы. Если при DDoS-атаке сеть планирует передавать более специфичные маршруты через другого оператора, необходимые разрешения следует подготовить заранее и согласовать с реальной схемой защиты. Простое расширение maxLength на весь диапазон увеличивает поверхность атаки.
ASPA. Проверяем отношения между автономными системами
ROV отвечает на вопрос о происхождении префикса. Для борьбы с утечками маршрутов нужна информация об отношениях между сетями.
ASPA (Autonomous System Provider Authorization) позволяет автономной системе публиковать криптографически подписанный список разрешённых транзитных провайдеров.
Предположим, AS64510 указала AS64520 в качестве своего провайдера. Получатель BGP-объявления может использовать такие сведения, чтобы оценить, соответствует ли AS_PATH заявленным отношениям «клиент-провайдер».
ASPA
Customer AS 64510
Provider AS 64520Проверка учитывает направление маршрута и не сводится к поиску каждой пары ASN в одном плоском списке. Отсутствие сведений о какой-либо AS также не обязательно означает нарушение. Результат проверки может оставаться неопределённым.
ASPA помогает выявлять некоторые утечки и манипуляции AS_PATH, которые невозможно обнаружить обычной ROV. Но технология не измеряет реальный путь пакетов и не удостоверяет физическую топологию сети.
К октябрю 2026 года профиль ASPA и процедуры проверки AS_PATH оставались рабочими проектами IETF. При этом практическое внедрение уже началось. APNIC запустил поддержку публикации ASPA в июле 2026 года, а FRRouting добавил функции проверки при наличии соответствующей поддержки библиотеки RTR.
Более подробно принципы и ограничения технологии разобраны в материале SecurityLab об ASPA и утечках маршрутов.
BGP Roles и OTC. Запрещаем неправильную передачу маршрутов
Ещё один способ бороться с Route Leak описан в RFC 9234. Механизм BGP Roles позволяет соседним маршрутизаторам согласовать свои отношения при установлении eBGP-сессии.
Стороны могут определить роли Provider, Customer, Peer, Route Server и Route Server Client. Для корректных отношений используются согласованные пары, например Provider и Customer.
Вместе с ролями применяется атрибут OTC (Only to Customer). Он помогает не допустить передачу определённых маршрутов провайдерам или равноправным соседям после того, как маршрут уже получен из направления, допускающего дальнейшую передачу только клиентам.
По сути, механизм формализует знакомое операторское правило. Маршрут, полученный от одного транзитного провайдера, нельзя без специальной договорённости экспортировать другому транзитному провайдеру как собственное предложение транзита.
RFC 9234 полезен именно для предотвращения неправильного экспорта. Но защита зависит от поддержки механизма оборудованием и корректной настройки ролей. Сложные коммерческие отношения между AS иногда не укладываются в одну стандартную роль.
BGPsec. Почему не подписать весь маршрут
BGPsec, определённый RFC 8205, предусматривает криптографическую защиту информации о распространении маршрута между автономными системами. В отличие от обычной ROV, механизм предназначен для подтверждения последовательности передачи объявления поддерживающими BGPsec участниками.
На бумаге идея выглядит естественно. Каждый маршрутизатор добавляет защищённые сведения, а следующий проверяет криптографическую цепочку.
Практическое внедрение намного сложнее. Требуются поддержка на маршрутизаторах, инфраструктура ключей, вычислительные ресурсы для подписей и проверок, а также согласованные действия нескольких операторов на пути объявления.
Частичное внедрение снижает эффект, поскольку обычные участки BGP не получают тех же гарантий. Кроме того, криптографически достоверный маршрут не обязательно соответствует правильной коммерческой политике его распространения.
Поэтому BGPsec нельзя рассматривать как широко внедрённую универсальную замену обычному BGP. Для большинства операторов практический приоритет пока принадлежит фильтрации, RPKI ROV, контролю экспортных политик и постепенно развивающимся механизмам проверки AS_PATH.
Как проверить маршруты и защитить собственную автономную систему
Защита BGP начинается с инвентаризации адресов, автономных систем и разрешённых отношений с провайдерами. Без точных сведений о собственной сети даже самый современный валидатор не исправит ошибочную политику.
Настраиваем RPKI ROV в FRRouting
FRRouting поддерживает получение данных RPKI от специальных валидаторов по протоколу RTR. Валидатор проверяет криптографические объекты RPKI и предоставляет маршрутизатору подготовленные сведения о разрешённых сочетаниях префиксов и ASN.
В качестве локального валидатора можно использовать Routinator, Fort или другую совместимую программу. Обычно валидаторы размещают внутри собственной защищённой инфраструктуры, а маршрутизаторы подключаются к ним по внутренней сети.
Для FRRouting может потребоваться дополнительный пакет frr-rpki-rtrlib и подключение модуля RPKI. Например, в поддерживаемых пакетных сборках Linux необходимо проверить параметр bgpd_options в файле /etc/frr/daemons.
bgpd_options=" -A 127.0.0.1 -M rpki"Сохраняйте другие параметры запуска, которые уже присутствуют в конфигурации. После изменения требуется перезапуск соответствующего демона по процедуре, принятой в вашей системе.
Следующий пример показывает фрагмент настройки для лабораторного маршрутизатора FRRouting. Предполагается, что RTR-валидатор уже работает на 10.10.0.10, а eBGP-сосед использует адрес 192.0.2.1.
configure terminal
rpki
rpki cache tcp 10.10.0.10 3323 preference 1
exit
route-map ROV-IN deny 10
match rpki invalid
route-map ROV-IN permit 20
router bgp 64512
neighbor 192.0.2.1 remote-as 64513
address-family ipv4 unicast
neighbor 192.0.2.1 soft-reconfiguration inbound
neighbor 192.0.2.1 route-map ROV-IN in
exit-address-family
endПолитика отклоняет маршруты с результатом Invalid и разрешает остальные объявления, включая Valid и NotFound. Такой фильтр не заменяет проверку префиксов, AS_PATH и остальных ограничений на сессии. Для полноценной конфигурации нужны также корректные экспортные политики.
Параметр soft-reconfiguration inbound позволяет FRRouting повторно обработать ранее полученные маршруты при изменении сведений RPKI. Функция расходует дополнительную память, поэтому на крупных таблицах маршрутизации её применение нужно учитывать при расчёте ресурсов.
Простой RTR через TCP не предоставляет встроенного шифрования или проверки подлинности транспортного соединения. Поэтому доступ к валидатору следует ограничивать доверенной управляющей сетью. Для других схем подключения нужно выбирать совместимый защищённый транспорт.
Проверяем состояние подключений и загруженные данные.
vtysh -c "show rpki cache-connection"
vtysh -c "show rpki prefix-table"
vtysh -c "show bgp ipv4 unicast summary"В выводе должны появиться активное соединение с валидатором и набор разрешений для префиксов. Если RPKI-модуль не загружен, команды могут отсутствовать.
Далее можно проверить результат ROV для конкретного маршрута.
vtysh -c "show bgp ipv4 unicast 203.0.113.0/24"
vtysh -c "show bgp ipv4 unicast 203.0.113.0/24 rpki invalid"В учебной лаборатории результат зависит от опубликованных тестовых разрешений и полученных маршрутов. Адреса 192.0.2.0/24, 198.51.100.0/24 и 203.0.113.0/24 зарезервированы для документации и не предназначены для глобальных анонсов.
Настройка FRRouting не означает автоматического включения ROV на каждом BGP-соседе. Нужно убедиться, что политика действительно привязана к нужным сессиям, а недопустимые маршруты не устанавливаются в таблицу.
Отдельный нюанс связан с потерей связи с валидатором. Поведение RPKI при недоступном RTR зависит от реализации и настроенной политики. В FRRouting предусмотрена обработка маршрутов без проверки происхождения после установленного периода недоступности кэша. Для критичных сетей полезно иметь несколько независимых валидаторов и заранее проверить поведение при отказе.
Синтаксис команд, параметры запуска и поддержка ASPA зависят от версии и сборки FRRouting. Перед переносом примера в производственную сеть сопоставьте команды с документацией FRRouting.
Мониторинг анонсов через RIPE RIS и BGPStream
Маршруты могут измениться вне вашей сети. Даже идеально настроенный собственный маршрутизатор не показывает, какие объявления видят пользователи через других операторов.
Поэтому сетевым администраторам нужны внешние точки наблюдения.
RIPE RIS (Routing Information Service) собирает BGP-информацию от маршрутизаторов и участников сети из разных регионов. Сервис RIPEstat позволяет исследовать историю префиксов, изменения AS_PATH и появление новых источников маршрутов.
Для оперативного наблюдения предназначен RIS Live, который передаёт BGP-сообщения в реальном времени через WebSocket API.
Система BGPStream от CAIDA предоставляет инструменты обработки исторических и потоковых BGP-данных, включая сведения RIPE RIS и Route Views.
Например, следующий фрагмент Python использует библиотеку pybgpstream для изучения объявлений префикса, фигурировавшего в инциденте с Virtualizor.
import pybgpstream
stream = pybgpstream.BGPStream(
from_time="2026-08-28 20:45:00 UTC",
until_time="2026-08-28 21:30:00 UTC",
projects=["ris"],
record_type="updates",
filter="prefix exact 162.55.80.0/24"
)
for elem in stream:
if elem.type == "A":
print(
elem.time,
elem.peer_asn,
elem.fields.get("as-path")
)Скрипт выводит наблюдавшиеся BGP-объявления, номера AS соседей коллектора и соответствующие AS_PATH. Для запуска нужна установленная библиотека PyBGPStream с необходимыми системными зависимостями и доступом к архивам BGP.
Полученные данные позволяют искать новые источники анонсов и необычные изменения пути. Но одна точка наблюдения может не увидеть локальный инцидент, а отсутствие объявления в RIS не доказывает, что нигде в интернете такого маршрута нет.
Также два инструмента, использующие один и тот же коллектор RIPE RIS, не дают полностью независимых подтверждений. При серьёзном расследовании полезно сравнивать данные из разных коллекторов и операторских сетей.
Для оперативного контроля следует отслеживать не только появление нового Origin AS, но и изменения более специфичных префиксов, неожиданные транзитные AS, массовые отзывы маршрутов и аномалии видимости в разных регионах.
Практический чек-лист защиты AS
- Проверьте собственные анонсы. Составьте полный список IPv4- и IPv6-префиксов, разрешённых Origin AS, провайдеров, точек обмена трафиком и допустимых резервных схем.
- Опубликуйте корректные ROA. Разрешайте только необходимые сочетания IP-префиксов и ASN. Избегайте чрезмерно широкого maxLength. Учитывайте резервных операторов и аварийные сценарии.
- Включите ROV. Настройте проверку на внешних BGP-сессиях, сначала измерьте последствия, затем отклоняйте Invalid. Не считайте NotFound автоматическим признаком атаки.
- Фильтруйте входящие и исходящие маршруты. Используйте Prefix Lists, AS_PATH-фильтры и Route Maps. При работе с клиентами разрешайте только согласованные маршруты и их законные клиентские префиксы.
- Ограничьте количество объявлений. Настройте разумные пороги max-prefix, защиту управляющей плоскости и контроль BGP-соседств. Применяйте ограничения отдельно для IPv4 и IPv6.
- Проверяйте отношения с соседями. Используйте BGP Roles и OTC там, где оборудование и топология позволяют. Для ASPA оцените поддержку выпуска объектов, RTR и проверки AS_PATH.
- Защитите административный доступ. Включите многофакторную аутентификацию для порталов RIR, ограничьте права сотрудников, храните резервные способы восстановления и отслеживайте изменения ROA.
- Наблюдайте за маршрутами извне. Подключите мониторинг RIPE RIS, BGPStream или специализированные системы оповещения. Реагируйте на новые Origin AS, неожиданные /24 и /48, а также изменения транзитных путей.
- Подготовьте процедуру реагирования. Заранее определите контакты NOC, провайдеров и регистратора, порядок отзыва неверных маршрутов, проверки ROA и согласованного изменения анонсов.
- Не доверяйте только сетевой защите. Подписывайте программные обновления, проверяйте подписи независимо от TLS, защищайте DNS и не используйте доступность IP-адреса как единственное доказательство доверия.
Дополнительную основу для операторских политик даёт RFC 8212, который определяет безопасное поведение eBGP при отсутствии явно настроенных политик импорта и экспорта. Принцип простой. Маршрутизатор не должен автоматически принимать и распространять всё подряд только потому, что BGP-сессия успешно установлена.
При настройке фильтров нельзя бездумно запрещать собственные префиксы на всех входящих сессиях. Для сетей с несколькими провайдерами и резервированием существуют ситуации, когда законный маршрут к собственным или клиентским адресам может приходить извне. Проверяйте подобные исключения до включения жёстких правил.
Частые вопросы об атаках на BGP
Можно ли перехватить BGP-маршрут без доступа к маршрутизатору жертвы?
Да. Злоумышленник может воздействовать на маршрутизацию через чужую или скомпрометированную автономную систему, распространяя ложные объявления. Успех зависит от того, примут ли другие участники BGP такой маршрут. Доступ к оборудованию жертвы не обязателен.
Помогает ли HTTPS защититься от BGP Hijacking?
HTTPS защищает содержимое соединения при корректной проверке TLS-сертификатов, но не препятствует перенаправлению пакетов. BGP-перехват способен нарушить доступность сайта. При дополнительных слабостях в проверке домена или доверенной инфраструктуре атакующий может получить возможность подменить сервис без привычных предупреждений браузера.
Может ли маршрут со статусом RPKI Valid быть поддельным?
Да. ROV проверяет допустимость Origin AS и длины префикса, но не подтверждает подлинность всей последовательности AS_PATH. Атакующий может подделать Origin AS или воспользоваться слишком широким разрешением ROA. Именно такую проблему продемонстрировал BGP-перехват, связанный с Virtualizor в августе 2026 года.
Нужно ли создавать ROA для адресов, которые сейчас не анонсируются?
Обычно рекомендуется минимальный набор разрешений, соответствующий реальным объявлениям. Для заранее предусмотренных резервных маршрутов и схем защиты могут потребоваться дополнительные ROA. Такие исключения следует документировать и регулярно проверять, чтобы не оставлять злоумышленникам лишние возможности для подделки источника.
Почему нельзя просто отклонять все маршруты без ROA?
Отсутствие ROA не означает, что маршрут незаконен. Многие сети могут иметь допустимые объявления без соответствующих данных RPKI. Массовое отклонение NotFound приведёт к потере связности с частью легитимных направлений. На практике обычно отклоняют Invalid, а NotFound обрабатывают по остальным правилам маршрутизации.
Может ли ASPA полностью заменить RPKI ROA?
Нет. ROA и ASPA решают разные задачи. ROA подтверждает право автономной системы объявлять IP-префикс. ASPA помогает проверить допустимость отношений между автономными системами в AS_PATH. Максимальный эффект достигается при совместном применении механизмов и традиционных BGP-фильтров.
Может ли обычный пользователь обнаружить BGP-перехват?
Пользователь может заметить необычную недоступность сервиса, задержки или изменение маршрута, но подобные признаки не доказывают BGP-атаку. Проверить публичные объявления можно через RIPEstat и Looking Glass операторов. Для уверенных выводов нужны данные нескольких сетей, история AS_PATH и сопоставление с разрешениями владельца адресного пространства.
Что делать, если обнаружен чужой анонс собственного префикса?
Сохраните время появления маршрута, IP-префикс, Origin AS, AS_PATH и сведения внешних коллекторов. Проверьте собственные ROA и изменения конфигурации. Затем свяжитесь с непосредственными провайдерами и операторами, распространяющими подозрительное объявление. Изменения маршрутов и возможную защитную деагрегацию согласовывайте с провайдерами, чтобы не создать дополнительную аварию.
Вывод. Безопасность BGP начинается не с покупки специализированной системы защиты, а с правильной политики маршрутизации. Оператор должен точно знать, какие префиксы вправе объявлять его автономная система, кому можно передавать полученные маршруты и что видят внешние сети.
Первым делом имеет смысл проверить опубликованные ROA, убрать неоправданно широкие maxLength, включить отклонение RPKI Invalid и ограничить экспорт маршрутов. Следующий шаг состоит в независимом мониторинге BGP и проверке поддержки BGP Roles, OTC и ASPA.
Даже полный набор сетевых механизмов не гарантирует защиту от всех вариантов перехвата. ROV не подтверждает всю цепочку AS_PATH, ASPA не удостоверяет физический путь трафика, а BGPsec требует широкой совместимости между операторами. Поэтому приложениям по-прежнему необходимы собственные криптографические проверки, особенно при получении обновлений и выполнении критичных операций.
История Virtualizor показала, насколько дорого может обойтись доверие к маршруту, который формально проходит RPKI. Подписанное разрешение подтверждает определённое свойство объявления, но не превращает любую выбранную интернетом дорогу в безопасную.
