RTBH (Remote Triggered Black Hole) — это приём DDoS mitigation, когда вы через BGP просите апстрим перестать доставлять трафик к атакуемому IP. Практически это означает: провайдер (или его ближайший узел) начинает «гасить» весь трафик к адресу, не давая ему забивать ваш порт, канал и оборудование.
Ключевая идея проста: вы не фильтруете DDoS на сервере, вы делаете так, чтобы трафик до вас вообще не доехал. Цена тоже очевидна: вместе с атакой пропадает и легитимный трафик к этому IP. Поэтому RTBH — инструмент аварийного реагирования, а не постоянная «оптимизация».
В большинстве схем RTBH «включается» не отдельной магией, а стандартным BGP: вы анонсируете максимально специфичный префикс (/32 для IPv4 или /128 для IPv6) и добавляете BGP community, по которой апстрим понимает: «этот маршрут нужно отправить в blackhole».
Термины: communities, blackhole, RTBH, upstream и anycast
BGP communities — «теги» (часто 32-битные значения вида ASN:NN), которые передаются вместе с маршрутом. Провайдеры используют их в политиках маршрутизации: управление localpref, ограничение распространения, выбор пирингов, blackhole и т. д.
Blackhole — маршрут «в никуда». В сети провайдера (или на вашем маршрутизаторе) для такого префикса задают принудительный discard/drop: пакет принимается, но дальше не пересылается.
RTBH — «удалённо триггеримый blackhole». Удалённо — потому что триггером выступает BGP-анонс/метка, а не ручная правка ACL на каждом пограничном устройстве. Триггеримый — потому что включается и выключается быстро.
Upstream — ваш провайдер/апстрим, через которого вы выходите в Интернет. Для RTBH критично, чтобы апстрим поддерживал вашу схему триггера (community, отдельный BGP-сосед, специальный next-hop и т. п.).
Anycast — одна и та же IP-адресация объявляется из нескольких точек. В RTBH anycast добавляет нюанс: один «blackhole-анонс» может «убить» сервис сразу во всех POP, либо (в удачном дизайне и при поддержке апстрима) помочь локально «отрезать» проблемный регион.
Как работает RTBH: что именно происходит в маршрутизации
Представим сервис на IP 203.0.113.10. Началась объёмная атака: входящий порт забит, балансировщик или firewall на пределе, легитимные клиенты не проходят. Быстрых вариантов обычно два: пытаться фильтровать «у себя» или попросить апстрим не везти трафик на адрес.
- Фильтрация на своей стороне (nftables/iptables, WAF, rate limit, scrubbing) часто запаздывает: узкое место уже на канале.
- RTBH: сказать апстриму «не доставляй трафик к этому IP» и тем самым разгрузить канал.
Типовая схема выглядит так:
- У вас есть BGP-сессия с апстримом (напрямую или через ваш пограничный маршрутизатор).
- Вы анонсируете адрес жертвы как максимально специфичный префикс:
/32для IPv4 или/128для IPv6. - Вы добавляете согласованную community «blackhole».
- Апстрим принимает маршрут, распознаёт community и применяет политику: next-hop на null-интерфейс или отправка в таблицу/VRF, где всё дропается.
Важный момент: в BGP «побеждает» наиболее специфичный маршрут. Если ваш апстрим увидел 203.0.113.10/32, то он станет предпочтительнее вашего агрегата (например, 203.0.113.0/24), и трафик к 203.0.113.10 поедет в «чёрную дыру».
RTBH даёт максимум эффекта, когда drop происходит как можно ближе к краю сети апстрима. Если «гасить» трафик только у себя, ваш порт всё равно будет забит.
Варианты RTBH: где именно находится «чёрная дыра»
1) Provider RTBH (самый распространённый)
Вы отдаёте апстриму маршрут с community, а апстрим дропает трафик в своей сети. Где именно — зависит от реализации: только на PE у вашей точки подключения, по всей AS, либо в отдельных регионах.
Плюсы: простота, скорость, минимальные требования к вашему железу. Минусы: вы зависите от политики апстрима и от того, как именно он трактует communities.
2) Customer RTBH (blackhole на вашем роутере)
Вы сами ставите маршрут в null0 внутри своей сети. Это может помочь при «внутреннем» мусорном трафике или на стыках между сегментами, но против классического DDoS «с Интернета» часто бесполезно: внешний канал уже забит до вашего дропа.
3) Selective blackhole и почему RTBH обычно не про селективность
Классический RTBH — это blackhole по destination (по адресу назначения). Он не умеет «дропать только плохих, пропуская хороших». Для селективности используют другие инструменты (например, BGP FlowSpec или scrubbing), а RTBH оставляют как аварийную «красную кнопку».
Зачем нужны BGP communities и почему без договорённости с апстримом ничего не взлетит
BGP community сама по себе ничего не «чинит» и не «ломает»: это атрибут маршрута. Смысл появляется только тогда, когда у апстрима есть политика вида «если community равна X — отправить префикс в blackhole».
Что обязательно выяснить до внедрения:
- какая именно community используется для blackhole и в каком формате;
- какие префиксы разрешено «гасить» (обычно только принадлежащие вам, и часто только
/32//128); - какие ограничения стоят на стороне апстрима: prefix-list, max-prefix, требования IRR/RPKI;
- где будет происходить drop (локально, по всей AS, по регионам);
- есть ли автоматизация, SLA по реакции, особенности для IPv6.
RTBH в реальном DDoS mitigation: когда применять, а когда лучше не надо
RTBH хорошо подходит, когда:
- атака насыщает канал (volume-based), и «узкое место» уже на порту/линке;
- цель атаки — конкретный IP или небольшой набор IP, который можно временно «выключить»;
- у вас есть план обхода: запасной IP, другой endpoint, резервный POP, быстрый перенос сервиса.
RTBH часто плохая идея, когда:
- на одном IP сидит критичный вход без резервов (вы сами себе устроите outage);
- атака распределена по пулу адресов или удар идёт по логике приложения, а не по одному IP;
- у вас anycast, но нет чёткой стратегии, как ограничить действие blackhole (есть риск «погасить» всё глобально).
RTBH и anycast: три типовых сценария и подводные камни
Сценарий A: anycast-сервис, один IP объявлен из многих POP
Если включить RTBH для anycast IP через апстрим, эффект зависит от области действия blackhole. В худшем случае blackhole-маршрут окажется предпочтительным для значимой части сети, и трафик начнёт падать даже там, где сервис в других POP был бы жив.
Что обычно помогает на уровне дизайна: разделять «обычные» объявления и «blackhole» по разным политикам/соседям, а также использовать community, которые действуют локально (например, только в конкретном регионе) — если апстрим это поддерживает.
Сценарий B: anycast как способ распределить атаку
Anycast сам по себе может быть элементом защиты: атака «размазывается» по точкам присутствия. В таком подходе RTBH применяют только как крайний шаг: когда конкретный POP не выдерживает, или нужно «отрезать» часть мира.
Сценарий C: unicast-сервис и резервный anycast «заглушечный» IP
Рабочий паттерн для части сервисов: основной unicast адрес обслуживает приложение, а отдельный anycast адрес в аварии быстро отдаёт минимальную страницу (например, 503 или статус). Тогда RTBH применяется точечно к unicast-адресу, а anycast остаётся живым как «страница выживания».
Если вы на своей стороне «приземляете» атаку на узле и режете её в firewall, полезно иметь готовый план, как именно ограничивать входящий поток. См. практику по связке SYNPROXY и nftables в статье SYNPROXY + nftables: защита от SYN-flood на VDS — как дополнительная ступень до RTBH.
Как выглядит триггер RTBH в конфигурации: примеры на FRR и BIRD
Ниже — практические примеры. В реальности точное значение community и правила приёма/анонса вам диктует апстрим. Главная цель примеров — показать, как зафиксировать три вещи: разрешённые адреса, разрешённую длину (/32//128) и установку community только для RTBH.
Вариант 1: FRR (vtysh), анонс /32 с community и жёстким фильтром
# Предположим, ваш апстрим ждёт community 65535:666 для blackhole.
# Сначала жёстко ограничиваем, что именно мы вообще можем анонсировать как RTBH.
ip prefix-list RTBH-V4 seq 10 permit 203.0.113.10/32
route-map RTBH-OUT permit 10
match ip address prefix-list RTBH-V4
set community 65535:666 additive
router bgp 65001
neighbor 192.0.2.1 remote-as 65000
address-family ipv4 unicast
neighbor 192.0.2.1 route-map RTBH-OUT out
network 203.0.113.10/32
exit-address-familyВариант 2: BIRD 2, статический маршрут и экспорт с community
# Идея та же: добавляем /32 как статический и экспортируем только его, помечая community.
# Важно: экспорт-фильтр должен запрещать всё лишнее.
define RTBH_COMM = (65535, 666);
protocol static rtbh_v4 {
route 203.0.113.10/32 blackhole;
}
filter rtbh_export_v4 {
if net = 203.0.113.10/32 then {
bgp_community.add(RTBH_COMM);
accept;
}
reject;
}
protocol bgp upstream_v4 {
local as 65001;
neighbor 192.0.2.1 as 65000;
ipv4 {
export filter rtbh_export_v4;
import none;
};
}Безопасность и защита от ошибок: правила эксплуатации RTBH
RTBH опасен не самим фактом использования, а отсутствием ограничителей. Ошибка в автоматизации или человеческий фактор легко превращают mitigation в self-inflicted outage.
Минимальный набор защитных мер
- Жёсткий prefix-list у вас и у апстрима: разрешены только ваши адреса.
- Ограничение длины префикса: для RTBH разрешать только
/32(IPv4) и/128(IPv6). max-prefixна BGP-сессии: чтобы не «залить» тысячи blackhole-маршрутов из-за бага.- Раздельная политика: отдельный route-map/filter под RTBH, чтобы случайно не пометить боевые маршруты community blackhole.
- Логи и алерты: каждый RTBH-анонс — отдельное событие мониторинга (и хорошо бы с авто-таймаутом).
Автоматизация: таймеры и «самооткат»
Практика, которая реально спасает: делать RTBH временным. Включили на 10–30 минут, затем автоматом сняли, если не было подтверждения инженера. Так вы снижаете риск «забыть» про blackhole на часы.
Что проверить с апстримом перед внедрением: чеклист
- Какая community используется для blackhole и не перезаписывается ли она на вашей стороне.
- Где именно будет происходить drop (на PE, по всей AS, только в регионе).
- Поддерживается ли IPv6 RTBH и какая минимальная/максимальная длина префикса.
- Есть ли лимиты на число одновременных RTBH маршрутов и какие значения
max-prefixрекомендуются. - Как быстро применяется политика (обычно секунды, но зависит от фильтров и архитектуры).
- Как апстрим обрабатывает anycast, и не сломает ли RTBH глобальный сервис.
- Требования к IRR/RPKI и к тому, что именно апстрим считает «вашими» префиксами.
Типовые ошибки RTBH и как их избежать
Ошибка 1: «Погасили» не тот префикс
Самый опасный сценарий — если из-за неверных фильтров в blackhole улетает агрегат (например, /24). Итог — падают десятки сервисов. Лечение: запрет на всё кроме /32//128, отдельная политика для RTBH и обязательный review изменений.
Ошибка 2: RTBH включили, но атака не ушла
Обычно причины такие:
- апстрим не принимает ваш
/32//128(фильтры, RPKI, лимиты, несоответствие «вашим» адресам); - community не та или «теряется» из-за вашей политики на экспорт;
- drop реализован слишком близко к вам, и входящий порт продолжает забиваться.
Правильная профилактика — «учебная тревога» на тестовом IP: заранее проверить, что маршрут принимается, и замерить, как меняется входящий трафик.
Ошибка 3: забыли снять blackhole
Если процесс ручной, это вопрос времени. Добавляйте авто-таймаут и мониторинг «есть ли у нас активные RTBH-маршруты».
RTBH vs другие методы: где границы применения
RTBH выигрывает в скорости и простоте, но не решает задачу «очистить и доставить» легитимный трафик. В зрелой защите обычно есть несколько ступеней:
- L7: кеширование, WAF, rate limit;
- L4: лимиты, SYN cookies, балансировка;
- сетевая очистка у провайдера (scrubbing) и/или селективные политики;
- RTBH как крайний рубеж, чтобы быстро сохранить инфраструктуру и канал.
Практический итог: план внедрения RTBH без сюрпризов
- Согласовать с upstream схему RTBH: community, префиксы, область действия, ограничения.
- Внедрить фильтры: только ваши префиксы, только
/32//128, разумныйmax-prefix. - Выделить отдельную политику (а лучше отдельную сессию) под RTBH, чтобы не было случайной маркировки обычных маршрутов.
- Подготовить runbook: кто включает, как подтверждается, как снимается, какие метрики проверяются.
- Провести тест на небоевом IP и зафиксировать ожидаемое поведение (включая время сходимости).
- Продумать «жизнь после blackhole»: запасные IP, быстрый перенос сервиса, anycast-стратегия (если есть), уведомления.
RTBH — не панацея, но это один из самых быстрых и предсказуемых способов остановить разрушительный поток, когда счёт идёт на минуты. А BGP communities — тот рычаг, который делает эту кнопку управляемой, если заранее договориться с апстримом и поставить правильные ограничители.
