Кратко и по существу — устройство, уязвимости, реальные случаи и меры.
1) Устройство BGP (основное)
- Роль: BGP — пограничный протокол маршрутизации между автономными системами (AS). Каждый участник объявляет префиксы IPv4/IPv6 и атрибуты маршрута (NEXT_HOP, ORIGIN, AS_PATH, LOCAL_PREF и др.).
- Модель: Path‑vector — маршруты несут последовательность ASN в атрибуте $\text{AS\_PATH}$; решение лучшего пути опирается на набор атрибутов и локальную политику.
- Транспорт: BGP работает поверх TCP, сеанс устанавливается между соседями (peers).
- Нет встроенной глобальной аутентификации объявления префикса/пути (в классическом BGP).
2) Основные уязвимости
- Origin hijack (подмена источника): злоумышленник объявляет чужой префикс как свой (или более‑специфичный префикс), и трафик начинает идти к нему.
- Path hijack / AS‑path spoofing: объявляют ложный $\text{AS\_PATH}$ или создают короткий выгодный путь, обманывая критерии выбора.
- Route leak: легитимный AS ошибочно или злонамеренно пересылает маршруты третьих сторон туда, где их не должно быть (например, провайдер объявляет маршруты клиентам, хотя должен только локально).
- Более‑специфичные префиксы: BGP предпочитает более‑специфичный префикс (longer‑match), поэтому объявление $/24$ покрывающего префикса может перехватить трафик.
- Отсутствие криптоаутентификации пути: классический BGP не проверяет, что ASN в $\text{AS\_PATH}$ действительно имеет право объявлять данный маршрут.
- Человеческие/операционные ошибки: неправильные фильтры, неверные конфигурации, случайные анонсы больших таблиц.
- Централизация доверия (RPKI/ROA) имеет риски: ошибки в RPKI или злоупотребление могут вызвать отказ в обслуживании.
3) Типичные последствия атак/утечек
- Черная дыра (blackholing) — трафик теряется.
- Перехват и анализ (interception/MITM) — трафик проходит через атакующее оборудование.
- Потеря доступности сервисов (локально или глобально).
- Подмена/перехват почты, сессий, вытягивание конфиденциальных данных.
4) Примеры реальных инцидентов
- Классический инцидент $\text{AS7007}$ (1997): ошибочный анонс большого объёма маршрутной информации от оператора привёл к масштабным сбоям в глобальной таблице маршрутов. Это послужило иллюстрацией хрупкости доверительной модели BGP.
- Блокировка/перехват YouTube (2008): национальная попытка блокировки YouTube привела к глобальному анонсу маршрутов, в результате YouTube стал недоступен глобально на некоторое время (операционный BGP‑инцидент).
- China Telecom (примерно $\text{2010}$): AS $\text{AS4134}$ был замечен в анонсе большого числа маршрутов, вследствие чего трафик на множество префиксов оказался маршрутизирован через Китай (временный глобальный перехват/маршрутизация).
- Facebook outage ($\text{2021-10-04}$): внутренние изменения конфигурации привели к массовому отзыву BGP‑анонсов для AS $\text{AS32934}$, что вызвало многочасовый глобальный простой Facebook/Instagram/WhatsApp — пример опасности ошибочной политики объявлений/withdraw.
(примечание: многие реальные инциденты — комбинация ошибок и злоупотреблений; список иллюстративен.)
5) Технические меры (оперативные и долгосрочные)
Немедленные и практические (для провайдеров и сетей):
- Фильтрация по источнику:
- Фильтры на краевых маршрутизаторах: принимать от клиента/пира только те префиксы, которые он должен объявлять (customer‑prefix filtering).
- Ограничение числа объявлений (max‑prefix) для сессий BGP.
- Ограничения на длину префикса:
- Отклонять слишком длинные/необычные префиксы (например, обычно отклонять IPv4 префиксы длиннее $/24$ при соответствующей политике).
- AS_PATH/IRR‑фильтрация:
- Использовать данные IRR (Internet Routing Registry) для построения фильтров и сверять анонсы.
- TCP‑защита BGP‑сессий:
- MD5 или лучше TCP‑AO для защиты от подмены пакетов и неавторизованного установления сессии.
- Мониторинг и оповещение:
- Подключиться к системам мониторинга (Routeviews, RIPE RIS, BGPmon), настроить алерты на неожиданные изменения.
- Политики отказа (scrubbing / blackholing):
- Механизмы DDoS‑blackholing через communities (быстрое отведение трафика при атаке).
Среднесрочные/криптографические:
- RPKI + ROV:
- Выпустить ROA для своих префиксов и настроить валидирующие роутеры на ROV (Route Origin Validation), отвергая (или помечая) невалидные объявления.
- Учесть риски: ошибки в ROA могут привести к отказу в обслуживании, поэтому тестировать политику (пессимистичная/мягкая политика).
- BGPsec (подпись AS_PATH):
- Дает криптографическую защиту AS_PATH; но внедрение затруднено из‑за масштабируемости и совместимости. Планировать как долгосрочную цель.
- Автоматизация и CI/CD для конфигураций:
- Тестирование конфигураций перед развёртыванием, контроль версий, «проверки перед применением».
6) Организационные и кооперативные меры
- Принятие стандартов и best practices:
- Вступление в инициативы типа MANRS (Mutually Agreed Norms for Routing Security) и следование их рекомендациям.
- Публичные политики маршрутизации:
- Публиковать свои правила фильтрации и контактные данные (peeringdb, IRR) — повышает прозрачность и ускоряет реакцию.
- Инцидент‑менеджмент и контакты:
- Поддерживать и актуализировать оперативные контакты с транзитными/пиринговыми партнёрами; участвовать в CSIRT/NETOPS‑рассылках.
- Регулярные учения и аудит:
- Произвести учения по BGP‑инцидентам, аудит конфигураций и фильтров.
- Экономические/регуляторные стимулы:
- Поощрять (или требовать) от крупных провайдеров и дата‑центров наличие RPKI/ROV; рассмотреть регуляторные рамки и SLA для критичных инфраструктур.
- Участие в глобальных системах оповещения:
- Совместные черные/белые списки, репозитории доверия и горячие линии между операторами.
7) Приоритеты внедрения (рекомендации)
- Короткий срок (в первую очередь): customer prefix filtering, max‑prefix, AS‑path/IRR фильтры, мониторинг и алерты, защита BGP TCP-сессий.
- Средний срок: внедрить RPKI/ROA и включить ROV в «спокойном» режиме (маркировка невалидных, затем мягкое отклонение).
- Долгий срок: продвижение BGPsec/криптографической защиты, совершенствование операционных практик в отрасли, законодательные/стимулирующие меры.
8) Ограничения и побочные риски
- RPKI централизует часть управления (злоупотребление или ошибки в ROA могут привести к массовым отказам).
- BGPsec требует изменений оборудования/стека и может увеличить задержку при обработке маршрутов.
- Чрезмерно агрессивная фильтрация IRR без аккуратного управления может блокировать легитимные изменения — нужен баланс и процессы для быстрого исправления.
Вывод: полная безопасность глобальной маршрутизации требует сочетания технических мер (фильтры, RPKI/ROV, мониторинг, защита сессий), организационной кооперации (MANRS, публичные политики, контакты) и постепенного перехода к криптографическим протоколам (BGPsec) с учётом операционных рисков.