Кратко и по существу.
Как работает BGP
- BGP — протокол маршрутизации между автономными системами (AS), основан на модели path‑vector: маршруты распространяются в виде объявлений (UPDATE), содержащих префикс и атрибуты (в частности AS_PATH, NEXT_HOP, LOCAL_PREF, MED, Communities).
- Соседство устанавливается по TCP-порту $179$; после установления сессии соседи обмениваются таблицами префиксов и обновлениями.
- При выборе маршрута BGP использует последовательность критериев (decision process): сначала чаще всего учитывается LOCAL_PREF (предпочтение у провайдера), затем короче AS_PATH, затем происхождение, MED, предпочитается eBGP к iBGP, далее стоимость до NEXT_HOP и прочие tie‑breaker’ы. (Реализация и порядок могут отличаться у вендоров.)
- Политики (фильтры, маршрутизирующие политики, communities) определяют, какие объявления принимать, отдавать и как модифицировать атрибуты.
Риски BGP‑hijacking
- Подмена происхождения префикса (origin hijack): злоумышленник объявляет чей‑то префикс как свой (подделка ORIGIN/AS), трафик перенаправляется к нему.
- Суперспецифика (subprefix hijack): объявление более специфичного префикса (например $/24$ против $/16$) выигрывает в маршрутизации и перехватывает трафик.
- Утечки маршрутов (route leaks): AS ошибочно распространяет маршруты от провайдера третьей стороны.
- Последствия: перехват/прослушка трафика (MITM), черная дыра (доступность теряется), перенацеливание DDoS, финансовые/бизнес‑утраты, нарушение доверия.
- Известные инциденты: например инциденты в $2008$ и $2018$ годах с массовыми перенаправлениями/простоями.
Технические меры снижения рисков
- RPKI / ROA (Route Origin Validation): создать и поддерживать ROA для своих префиксов; у провайдеров включать валидацию и отвергать/понижать приоритет INVALID‑маршрутов. Учесть ограничения (централизация доверия).
- Prefix filtering у провайдеров/пиров: принимать только префиксы, которые принадлежат клиентам (по контракту/IRR/локальным базам). Ограничивать длину (max‑length) объявляемых префиксов (например не принимать более специфичные, чем ожидалось).
- Политики AS‑PATH filtering и рефлексия по IRR: автоматически строить фильтры из актуальных записей IRR и RPKI.
- Аутентификация BGP-сессий: TCP MD5 или TCP‑AO и механизм GTSM (TTL security) для защиты соседей от подмены/сброса сессий.
- Ограничение количества префиксов (max-prefix) и отслеживание аномалий (rate limits).
- Мониторинг и детекция: подписка на глобальные мониторинговые сервисы (RouteViews, RIPE RIS, BGPmon), собственные алерты на изменения AS_PATH/origin, NetFlow/пакетный мониторинг для аномалий трафика.
- Многоадресность / Anycast / мультихоминг: снижает влияние одного неправильного объявления — можно переключиться на других провайдеров.
- BGPsec (валидация пути): теоретически решает подделку AS_PATH, но сегодня мало распространён и требует совместимости.
Организационные меры
- Оформление прав на ресурсы: актуальные записи в RIR, корректные контактные данные, поддержка IRR и ROA.
- Договоры и соглашения с провайдерами/пирами о фильтрации и оперативном реагировании на инциденты.
- Внедрение и соблюдение Best Current Practices (например MANRS — Mutually Agreed Norms for Routing Security).
- Процедуры on‑boarding/ off‑boarding клиентов: проверка объявляемых префиксов, применение фильтров до развёртывания.
- План реагирования на инциденты: контакты провайдеров, CERT, шаблоны запросов об отмене анонса, playbook для оперативного переключения каналов связи.
- Регулярные аудиты конфигураций и тестирование отказоустойчивости (учения).
Ограничения и баланс
- Никакая отдельная мера не даёт $100\%$ гарантии: RPKI защищает только origin, BGPsec пока не массов; фильтры требуют поддержания актуальности; мониторинг даёт обнаружение, но не мгновенное исправление.
- Оптимальная защита — сочетание технических мер (RPKI, фильтры, аутентификация, мониторинг, мультихоминг) и организационных (процедуры, соглашения, участие в MANRS, поддержка ROA/IRR).
Если нужно, могу коротко перечислить конкретные настройки фильтров и политики для провайдера/клиента.