# План внедрения: outbound-фильтр BGP (устранение утечки 10.0.0.0/8)

**Дата:** 2026-09-10

## Проблема

В PROD (окружение `site-cloud`) FRR реэкспортировал входящий маршрут `10.0.0.0/8` обратно соседям. Причина: ни у одного BGP-соседа не было outbound-фильтра — `no bgp ebgp-requires-policy` отключает защитный механизм FRR, а единственный существующий route-map (`RM-PREPEND-OUT`, только на резервном канале) фильтрации не делал (`permit 10` без `match`). Роутеры многодомны в 2 разных внешних AS без изоляции — любой маршрут в BGP-таблице реэкспортировался всем eBGP-соседям (классический непреднамеренный transit/route-leak).

## Решение

`frr.conf.j2` (общий для всех окружений, включая площадку A — та же уязвимость структурно применима и там):
- `ip prefix-list PL-ANYCAST-OUT permit <anycast_prefix>`.
- `route-map RM-OUT` (filter-only) и `route-map RM-OUT-PREPEND` (filter + prepend, рендерится только если есть соседи с `prepend: true`) — оба матчат `PL-ANYCAST-OUT`, оба заканчиваются явным `deny 20`.
- `neighbor ... route-map out` теперь навешан на **всех** соседей без исключения: `RM-OUT-PREPEND` для `prepend: true`, `RM-OUT` для остальных.
- `no bgp ebgp-requires-policy` сознательно **не убран** — иначе FRR перестанет принимать вообще все inbound-маршруты без явной inbound-policy (отдельная задача, не входит в текущий фикс).

Golden-файлы площадки A (`frr/a{1,2,3}/frr.conf`) обновлены под новый рендер — это намеренное изменение (тот же класс уязвимости актуален и для Docker-лабы), а не регресс.

## Definition of done

- `render-check.sh` (площадка A) — совпадает с обновлёнными golden-файлами.
- `render-check-cloud.sh` — фильтр применён на всех 4 узлах, prepend — только на резервных соседях, `RM-OUT`/`RM-OUT-PREPEND` синтаксически корректны.
- README и summary обновлены.