Кратко

  • Well-known community BLACKHOLE — рекомендательный запрос отбросить трафик к помеченному префиксу. Получатель решает локально и должен иметь соглашение на конкретной сессии, подтверждение права соседа на покрывающий префикс и явную политику.
  • Destination RTBH принимает более специфичный маршрут и разрешает его в discard/null. Атака перестаёт занимать узкий канал, но легитимные пакеты к тому же адресу исчезают вместе с ней.
  • Доказательство соединяет исходный UPDATE, авторизацию префикса, решение по инциденту, ROV, import policy, локализацию, RIB, FIB, счётчики, пакеты, withdrawal и восстановление. Established подтверждает только жизнь сессии.

Отключить один адрес, чтобы спасти канал

Рассмотрим синтетический случай. Клиент транзита получает объёмную атаку на 203.0.113.19. Access link заполняется до того, как фильтр на стороне клиента может помочь. Клиент анонсирует провайдеру 203.0.113.19/32 с BLACKHOLE. На этой BGP-сессии услуга была согласована заранее, а провайдер знает, что клиент вправе анонсировать 203.0.113.0/24.

Провайдер принимает /32, удерживает его в своём домене и программирует discard на входных маршрутизаторах. Атака больше не пересекает ограниченный канал. Легитимный трафик к хосту тоже. Остальные адреса /24 остаются доступны. Цель не спасли — её пожертвовали ради соседних сервисов и общей ёмкости.

Позже автоматика отправляет 203.0.113.91/32, адрес здорового сервиса в том же агрегате. Peer, покрытие и community верны. Если проверять только их, формально допустимый запрос исполняет ошибочное намерение. Сессия остаётся зелёной, а второй сервис перестаёт видеть пакеты.

Сценарий не выдается за реальный инцидент. Он показывает настоящую границу: право анонсировать внутри блока не доказывает, что уполномоченный человек решил сейчас пожертвовать именно этим хостом.

Общий смысл не создаёт глобальную команду

IANA зарегистрировала BLACKHOLE как 0xFFFF029A, обычно записываемый 65535:666. RFC 7999 определяет его как well-known, advisory и transitive BGP community для destination blackholing. Единое значение уменьшает число операторских кодов и ошибок интеграции.

Однако принять и выполнить или проигнорировать — выбор каждого оператора. В двусторонних отношениях сети должны договориться до использования. Без явной конфигурации устройство не должно отбрасывать трафик только потому, что узнало число.

Стандарт не делает отправителя администратором forwarding plane получателя. Отправитель прикладывает просьбу. Получатель сопоставляет session, prefix и local policy. Сеть может понимать community и не предлагать сервис; collector может сохранять атрибут без влияния на пакеты.

Так выглядит Minimum Initial Specification Хэн Лу на практике. Общий слой узок: стабильный код и значение запроса. Допуск клиента, коммерческие условия, регионы, устройства и срок остаются локальными. Localized Future Decision разрешает принять или отказать без центрального статуса. Voluntary Adoption требует работающей реализации: документ и запись IANA сами по себе не отбрасывают пакеты.

Когда лучший маршрут означает отсутствие доставки

RFC 5635 описывает маршрут к null/discard interface. BGP policy заставляет более специфичный префикс разрешаться через этот next hop. Пакеты погибают у ingress, не расходуя пропускную способность до клиента.

Маршрут может быть корректным, выбранным и находиться в Loc-RIB, хотя его назначение — недоставка. Наличие в Loc-RIB не доказывает обычную достижимость и не доказывает само отбрасывание без FIB и разрешения next hop на каждой группе входных устройств.

Цена механизма ясна: destination RTBH уничтожает атакующий и законный трафик к цели вместе. Выигрыш — ограничение collateral damage. Отчёт должен отдельно показывать защищённую ёмкость и доступность принесённого в жертву сервиса. Снижение загрузки канала может одновременно быть успешной защитой сети и полной потерей услуги.

Слово «mitigated» обязано называть объект. Для backbone результат успешен; для клиента — нет.

Два замка RFC и третий вне BGP

В двусторонней связи RFC 7999 разрешает honour BLACKHOLE только если префикс покрыт таким же или менее специфичным префиксом, который сосед вправе анонсировать. Кроме того, получатель должен был согласиться исполнять community именно на этой сессии.

Первый замок не даёт клиенту обнулить чужие адреса. Второй не позволяет любому peering случайно стать каналом отключения. Они задают пространство и отношение.

Они не подтверждают полное incident intent. Ошибочный /32 остаётся внутри правильного /24. Учётная запись может быть скомпрометирована, старый запрос — повторён после атаки. UPDATE не несёт универсально проверяемую запись о согласовавшем, сервисе, причине, сроке и владельце withdrawal.

Третий замок строится в операционной системе: requester identity, incident ID, точный prefix, сервис, обоснование, scope, время одобрения, expiry и withdrawal owner. Запись связывают с peer, AFI/SAFI и версией policy, обработавшей маршрут.

Префикс-фильтр отвечает: может ли клиент анонсировать в этом пространстве? Журнал инцидента: хотел ли уполномоченный сейчас отключить эту цель? Ручное разрешение без детерминированного фильтра допускает опечатку; фильтр без контекста даёт автоматике постоянное право выключения всего блока.

Точность host route требует контролируемого исключения

RFC 7999 советует максимально специфичный префикс, обычно /32 для IPv4 и /128 для IPv6. Это уменьшает число затронутых адресов. Но обычная Internet policy часто отбрасывает маршруты длиннее /24 и /48.

Междоменный RTBH открывает преднамеренное исключение: принимает host route клиента для локального discard и не выпускает его как обычную глобальную достижимость. Исключение ограничивают точные агрегаты клиента, разрешённая длина, session, community, region и local action.

Специфичность не гарантирует правильный адрес. Один IP может держать DNS, аутентификацию или управление. Blackhole /24 иногда оправдан масштабной атакой, но жертвует множеством сервисов. Prefix length — решение о blast radius.

Нужны также лимиты одновременности, времени и protected endpoints. Один разрушительный маршрут может быть опаснее тысяч обычных. Стандартный maximum-prefix этого не понимает.

Удержать разрушительный more-specific внутри полномочий

RFC 7999 рекомендует добавить NO_ADVERTISE, NO_EXPORT или подобный контроль. RFC 1997 различает их: NO_ADVERTISE запрещает передачу любому peer, NO_EXPORT разрешает внутреннее распространение, но не выход из AS или confederation.

Провайдеру может понадобиться распространение на все ingress или только в регионы атаки. Ограничение должно повторять реальный execution graph. Слишком узкое не защищает нужный link; слишком широкое выпускает more-specific.

Leak опасен даже там, где BLACKHOLE игнорируют: longest-prefix match способен притянуть трафик. Там, где его исполняют, домен discard растёт. Поэтому RFC 5635 рекомендует egress prefix filters.

Текущая документация FRRouting говорит, что при получении BLACKHOLE автоматически добавляется NO_ADVERTISE. Это свидетельство поведения FRR, не всех vendors и releases. Другая платформа требует явной policy; правило замены communities может стереть защиту.

Доказательство — Adj-RIB-Out после policy для каждого класса соседей. Конфигурация показывает намерение, outbound view — что устройство готово отправить.

Аутентифицированный канал не аутентифицирует намерение

BLACKHOLE передаётся в классическом COMMUNITIES attribute, который RFC 1997 разрешает менять по локальной policy. RFC 7999 предупреждает: BGP специально не предотвращает добавление, удаление и изменение community, а BGPsec не решает эту целостность. Несанкционированное добавление создаёт denial of reachability.

Защита session снижает подмену peer, но не доказывает правильность цели. RPKI проверяет другую связь: prefix, origin AS и maxLength. Он не подписывает community или просьбу о discard.

Легитимный blackhole /32 может быть RPKI Invalid, если ROA разрешает только /24. RFC 7999 требует не блокировать правильные сигналы по ошибке. Но исключить все помеченные маршруты из ROV опасно: изменяемый атрибут станет bypass. Расширение каждой ROA до /32 или /128 увеличит множество more-specific, способных стать Valid.

Индивидуальный Internet-Draft 2022 года предлагал подписанную RPKI Discard Origin Authorization. Он истёк и не имеет формального статуса IETF. Это подтверждение пробела, а не действующий стандартный контроль.

Сегодня доверие составное: peer identity, точный prefix filter, объяснимый ROV, community, incident approval, local scope и наблюдаемая FIB. Ни одна галочка не поглощает остальные.

Не смешивать четыре разных инструмента

Destination RTBH отбрасывает всё к цели. Source-based RTBH сочетает discard route с uRPF, чтобы source lookup не прошёл на выбранных ingress. RFC 5635 требует другую community и обычно советует подавать source triggers из локальных attack-management systems, а не принимать от внешних peers.

FlowSpec распространяет правила match/action в другой NLRI; RFC 7999 исключает BLACKHOLE для неё. Sinkhole перенаправляет трафик для наблюдения. Scrubbing пытается сохранить легитимные пакеты. Destination blackhole ничего не классифицирует и не чистит — он удаляет.

Incident record должен называть механизм и ожидаемый результат. Если цель — сохранить сервис online, destination RTBH является последним средством защиты ёмкости, а не доказательством непрерывности.

Доказать путь от UPDATE до отсутствия пакета

До включения фиксируют customer, exact session, AFI/SAFI, aggregates, lengths, community, protected exclusions, regions, ROV rule, max lifetime и withdrawal owner.

Для каждого trigger сохраняют:

  1. raw UPDATE, время, peer, AS_PATH, origin, next hop и communities;
  2. точное совпадение авторизационного фильтра и источник;
  3. ROV state и применённое правило;
  4. import term, ограничения и изменение next hop;
  5. Adj-RIB-In, Loc-RIB selection и причину;
  6. FIB каждой ingress class с discard resolution;
  7. drop counters с устройством, интерфейсом, семантикой и baseline;
  8. packets до и после границы;
  9. Adj-RIB-Out соседей, которые не должны видеть маршрут;
  10. withdrawal, удаление FIB, возврат обычного маршрута и service probes.

UPDATE доказывает вход, policy — решение, RIB — выбор, FIB — исполняемую команду, packets — результат. Выход доказывает ограничение, восстановление — завершение полномочия.

Один флаг «blackhole active» не различает невыбранный маршрут, неразрешённый next hop, частично запрограммированную сеть или stale discard после withdrawal. RFC 7999 советует долго хранить UPDATEs; аудит дополнительно хранит policy, FIB, counters и approval.

Canary для жертвы и для возвращения

Безопасный canary prefix проходит каждую session class, address family, region, platform и release. Тест принимает разрешённый случай и отклоняет чужой prefix, неверную session и запрещённую length. Он проверяет containment, FIB, counters, ограниченный packet effect и восстановление после withdrawal.

Пауза нужна при отсутствии live incident, protected endpoint, необъяснимом ROV, пропаже containment, неожиданном eBGP export, разной FIB, отсутствии expiry или withdrawal owner. Rollback — при потере неверного сервиса, росте scope, leak, ущербе вне prefix или невозможности реконструировать действие.

Withdrawal начинает откат, но не завершает. Discard удаляется из каждой FIB, обычная route возвращается, probes показывают доставку, link остаётся контролируемым. Forwarding можно вернуть; ответственность нельзя восстановить после исчезновения доказательств.

Источники