16 июня 2026 года история с Telegram в Индии дала свежий повод вспомнить BGP. Индийские власти временно ограничили доступ к мессенджеру перед пересдачей NEET-UG, а Павел Дуров заявил, что запрет ударил по более чем 150 млн обычных пользователей и не остановил утечки экзаменационных материалов. Уже 17 июня Дуров обвинил Reliance в том, что оператор мешает доступу к Telegram для пользователей за пределами Индии через BGP hijacking. Это пока публичное обвинение, а не независимое техническое расследование, но сам термин выбран точно: BGP позволяет сломать доступ к сервису не через уязвимость в приложении, а через маршруты, по которым к нему идет трафик.
BGP-хакерство обычно называют перехватом или искажением междоменной маршрутизации. Злоумышленник, ошибочно настроенный оператор или скомпрометированная сеть объявляют чужой IP-префикс, подмешивают неверный путь или передают маршрут туда, куда владелец сети не планировал отдавать трафик. Для пользователя картина простая: Telegram, DNS-сервис, почта, биржа или API внезапно недоступны, отвечают с задержкой или идут через подозрительную автономную систему. Для сетевика причина лежит глубже, в глобальной таблице BGP.
Как BGP решает, куда отправлять трафик
Интернет состоит из автономных систем. У каждой AS есть номер. Например, AS15169 относится к Google, AS13335 к Cloudflare. Автономная система сообщает соседям: я умею доставлять трафик к такому-то IP-префиксу. Соседи передают объявление дальше, добавляя свои номера в AS_PATH. Так сеть узнает, через какую цепочку операторов можно дойти до диапазона адресов.
Prefix: 203.0.113.0/24
Origin AS: 64500
AS_PATH: 64496 64497 64500
Next hop: 198.51.100.1Внутри одного и того же префикса BGP выбирает лучший путь по политике сети. На решение влияют local preference, длина AS_PATH, origin code, MED, eBGP или iBGP, стоимость до next hop и настройки конкретного оператора. Но атакующий не управляет local preference в чужой сети напрямую. На практике он чаще играет на двух вещах: более специфичном префиксе и слабых фильтрах у соседей.
Здесь важно не смешивать два разных этапа. BGP выбирает лучший путь для конкретного префикса, а таблица пересылки потом ищет наиболее точное совпадение адреса по правилу longest prefix match. Поэтому маршрут к 203.0.113.0/24 не «побеждает» 203.0.112.0/23 как конкурентный BGP-путь. Эти записи могут мирно сосуществовать в таблице, но пакет к адресу из 203.0.113.0/24 пойдет по более точной записи.
Классический prefix hijack выглядит так. Владелец объявляет 203.0.113.0/24 из AS64500. Чужая сеть AS64599 начинает объявлять тот же префикс. Часть интернета принимает новый маршрут и отправляет трафик к AS64599. Subprefix hijack опаснее: злоумышленник объявляет более точные 203.0.113.0/25 и 203.0.113.128/25. Если такие маршруты не отфильтруют, часть сетей выберет более специфичные записи при пересылке.
| Сценарий | Что происходит | Чем опасно |
|---|---|---|
| Prefix hijack | Чужой AS объявляет чужой префикс того же размера | Трафик уходит к неверному оператору |
| Subprefix hijack | Чужой AS объявляет более точную часть чужого диапазона | Longest prefix match уводит пакеты на подставной путь |
| Route leak | AS передает маршрут за пределы согласованной политики | Трафик идет через сеть, которая не должна быть транзитом |
| AS_PATH spoofing | В маршрут попадает неправдоподобная или поддельная AS-цепочка | Соседи могут принять путь, который нарушает реальные отношения сетей |
| Blackhole leak | Маршрут для фильтрации DDoS уходит шире нужного | Легитимный трафик исчезает вместе с вредным |
Hijack, route leak и ошибка оператора
Перехват префикса похож на подмену владельца. Route leak тоньше. RFC 7908 описывает route leak как распространение маршрутов за пределы предполагаемой области политики. Например, небольшая AS подключена к двум провайдерам. От первого она получает маршруты, а затем по ошибке экспортирует их второму. Второй провайдер принимает путь, считает его пригодным и отправляет через маленькую сеть трафик, к которому она не готова.
Поэтому выражение «BGP-хакерство» полезно для заголовка, но внутри темы нужно говорить точнее. Часть инцидентов вызывает не злой умысел, а кривой экспорт, забытый prefix-list, автоматизация без проверки, неверный route-map или слабый контроль на границе сети. Для жертвы разница не всегда видна. Сайт все равно недоступен, DNS отвечает странно, пользователи из одних стран жалуются, а из других работают нормально.
Хороший пример, атака на Amazon Route 53 и MyEtherWallet в апреле 2018 года. По разбору Internet Society, eNET (AS10297) начал объявлять более специфичные /24 из пространства Amazon Route 53, включая 205.251.192.0/24. DNS-запросы к MyEtherWallet у части пользователей попали на подставной сервер, а злоумышленники похитили Ethereum на сумму около 150 тыс. долларов. TLS мог остановить жертву, но пользователи, которые проигнорировали предупреждение о сертификате, все равно отдали данные фишинговому сайту.
Этот кейс хорошо показывает границы защиты на уровне приложения. HTTPS снижает ценность сетевого перехвата, потому что атакующий не может просто прочитать содержимое соединения. Но BGP-инцидент все равно бьет по DNS, доступности, метаданным, старым протоколам, ошибкам в проверке сертификатов и пользовательским привычкам. Если человек нажимает «продолжить» на предупреждении браузера, криптография уже не спасает.
RPKI закрывает origin, но не весь путь
Главный массовый механизм защиты от подмены origin AS, RPKI. Владелец IP-ресурса создает ROA, где указывает, какой AS имеет право объявлять префикс и какую максимальную длину префикса можно использовать. Валидатор получает криптографически проверенные данные и передает маршрутизатору результат. Маршрут получает один из трех статусов: Valid, Invalid или NotFound.
if rpki_state == INVALID:
reject
elif prefix not in customer_prefix_list:
reject
elif first_as != expected_customer_as:
reject
else:
acceptRPKI не нужно описывать как полное лекарство. Механизм отвечает на вопрос: имеет ли этот AS право объявлять этот префикс. RPKI не доказывает, что весь AS_PATH правдивый, что маршрут не утек от провайдера к провайдеру через клиента и что пакеты физически прошли именно по заявленной цепочке. Для route leak одного origin validation мало.
Типичная ошибка владельца сети, слишком широкий maxLength. Если компания реально объявляет только /22, но разрешает в ROA до /24, она расширяет набор допустимых более специфичных маршрутов. Иногда так делают сознательно для traffic engineering. Проблема начинается, когда широкое значение ставят «на всякий случай» и потом забывают. Для IPv4 большинство глобальных операторов фильтруют префиксы длиннее /24, но внутри допустимого диапазона лишний maxLength все равно добавляет риск.
Вторая ошибка, защищать вход и забывать выход. Провайдер может фильтровать чужие странные маршруты, но сам утечь клиентские или пиринговые маршруты наружу. Хорошая BGP-политика всегда симметрична: что принимаем, кому экспортируем, какой первый AS ожидаем, сколько префиксов разрешаем, какие communities уважаем и что делаем при превышении лимита.
Третья ошибка, считать мониторинг защитой. Алерт полезен, но алерт приходит после события. Защита начинается раньше: ROA для рабочих префиксов, reject invalid там, где сеть готова к такой политике, IRR-объекты без мусора, входные и выходные фильтры, max-prefix limit для соседей, внешний мониторинг через RIPE RIS, RouteViews, BGPStream, bgp.tools, Cloudflare Radar или собственные коллекторы.
# Примеры для стенда, синтаксис зависит от версии и платформы
routinator vrps --output csv | grep 203.0.113.0
vtysh -c "show bgp ipv4 unicast 203.0.113.0/24"
vtysh -c "show rpki prefix 203.0.113.0/24"Что идет после RPKI
Главная дыра после RPKI, проверка пути. BGPsec решает именно эту задачу на уровне стандарта RFC 8205: каждая AS подписывает propagation BGP UPDATE, а получатель получает криптографическую уверенность в AS-пути. На бумаге подход логичный. В реальной глобальной сети BGPsec разворачивается крайне ограниченно, потому что требует поддержки у соседей, добавляет вычислительную нагрузку, усложняет операции и плохо ложится на инерцию существующего интернета.
Более практичная повестка 2026 года, ASPA. Autonomous System Provider Authorization позволяет AS объявить в RPKI список своих авторизованных провайдеров. Проверяющая сторона может сопоставить AS_PATH с отношениями customer-provider и заметить route leak или простую манипуляцию путем. RIPE NCC уже описывает ASPA как emerging standard, который помогает предотвращать route leaks и частично улучшает path security. Но ASPA пока нельзя подавать как зрелый глобальный стандарт: это раннее внедрение, а не новая «кнопка безопасности» для всего интернета.
Есть и операционные меры. MANRS задает нормы для операторов: фильтровать маршруты, поддерживать контактные данные, публиковать routing policy и не выпускать spoofed-трафик. Peerlock работает грубее, но часто полезен у крупных операторов: сеть заранее фильтрует маршруты, где защищаемая AS внезапно появляется в неправдоподобном месте AS_PATH. В будущем ASPA должна сделать часть таких ручных договоренностей менее кустарной, но ближайшие годы сети все равно будут жить в смешанной модели: RPKI, фильтры, MANRS, Peerlock, ASPA, мониторинг и человеческая дисциплина.
Для владельца AS практический минимум выглядит скучно, но именно он снижает риск:
- создать ROA для всех рабочих IPv4 и IPv6-префиксов;
- не ставить
maxLengthшире реальной схемы анонсов; - отбрасывать или понижать RPKI Invalid на границе сети;
- проверять первый AS клиента и список его разрешенных префиксов;
- фильтровать экспорт отдельно для upstream, peer и customer;
- включить max-prefix limit и аварийные процедуры при всплеске маршрутов;
- следить за новым origin AS, subprefix, резким AS_PATH и странной географией задержек.
BGP-хакерство всегда означает атаку?
Нет. Многие BGP-инциденты происходят из-за ошибки оператора, неверного route-map, слабого фильтра или автоматизации без проверки. Для пользователя результат похож на атаку, но причина может быть обычной сетевой аварией.
Почему subprefix hijack так опасен?
При пересылке маршрутизатор ищет наиболее точное совпадение адреса. Если легитимная сеть объявляет /23, а атакующий объявляет часть этого диапазона как /24, пакет к адресам внутри /24 может уйти по более специфичной записи.
RPKI полностью решает проблему?
Нет. RPKI хорошо проверяет origin AS, но не подтверждает весь AS_PATH и не закрывает route leak полностью. Для полноценной защиты нужны фильтры, корректный экспорт, мониторинг, операционные нормы и новые механизмы вроде ASPA.
Может ли BGP-перехват прочитать HTTPS-трафик?
Сам BGP-перехват не расшифровывает HTTPS. Но атакующий может ломать доступность, подменять DNS-ответы, собирать метаданные и рассчитывать на ошибки в проверке сертификатов или действия пользователя, который проигнорирует предупреждение браузера.
Что проверять при подозрении на BGP-инцидент?
Смотрите origin AS, появление более специфичных префиксов, резкую смену AS_PATH, региональные жалобы, задержки через неожиданные страны и расхождение между внутренним мониторингом и внешними BGP-коллекторами.
BGP не стал безопасным сам по себе, потому что интернет слишком велик, стар и неоднороден для простой замены протокола. Но владелец сети может резко сократить риск: подписать префиксы через RPKI, убрать лишний maxLength, фильтровать клиентов, не выпускать чужие маршруты наружу, подключить мониторинг и следить за ASPA. Главная мысль проста: BGP-хакерство редко начинается с красивого эксплойта. Чаще достаточно одного маршрута, которому соседние сети поверили без проверки.
