Фильтрация BGP перестала быть опциональной практикой. В 2026 году это обязательное требование для любой сети, подключенной к интернету. Без правильной фильтрации ваша инфраструктура становится уязвимой для случайных утечек маршрутов и целенаправленных атак по перехвату трафика. Это руководство предоставляет готовые конфигурации для базовой защиты и детальную инструкцию по внедрению современных систем валидации на основе RPKI.
Вы получите рабочие примеры фильтров для разных вендоров, научитесь настраивать RPKI-валидатор и автоматизировать поддержку правил через IRR. Эти меры напрямую влияют на стабильность работы ваших сервисов и защищают бизнес от финансовых и репутационных потерь.
Зачем нужна фильтрация BGP: Риски и последствия игнорирования
BGP работает на доверии между автономными системами. По умолчанию маршрутизатор принимает и распространяет любые анонсы от соседей. Это фундаментальная уязвимость протокола. Ошибочная конфигурация на одном устройстве может вызвать глобальный сбой.
В 2008 году пакистанский провайдер пытался заблокировать YouTube внутри своей страны, анонсировав более специфичный маршрут к префиксам видеохостинга. Из-за отсутствия фильтрации на границе этот анонс распространился по всему миру. Трафик к YouTube перенаправлялся в Пакистан и терялся, вызывая многочасовой простой сервиса. Подобные инциденты повторялись с AS7007 в 1997 году, с российским провайдером в 2017-м, затрагивая работу Amazon, Cloudflare и других крупных платформ.
Финансовые последствия таких инцидентов измеряются сотнями тысяч долларов упущенной выгоды и затратами на восстановление. Репутационные потери еще значительнее. Клиенты теряют доверие к компании, чья сеть стала источником проблемы. В 2026 году угрозы эволюционировали. Базовых фильтров по префиксам уже недостаточно. Злоумышленники используют методы, обходящие простые проверки, что делает внедрение криптографической валидации через RPKI критически важным.
Базовые инструменты фильтрации: Готовые конфигурации prefix-list, as-path-list и route-map
Это основа, которую нужно внедрить немедленно. Приведенные ниже конфигурации блокируют наиболее распространенные ошибочные и злонамеренные анонсы.
Prefix-list: Фильтрация по префиксам сети
Prefix-list определяет, какие IP-префиксы разрешены или запрещены. Следующие списки должны применяться на всех входящих BGP-сессиях.
Актуальный список запрещенных (bogon) префиксов на 2026 год:
0.0.0.0/0- default-route (запрещен на приеме от провайдеров/пиров).- Частные пространства RFC 1918:
10.0.0.0/8,172.16.0.0/12,192.168.0.0/16. - Пространства для документирования (TEST-NET):
192.0.2.0/24,198.51.100.0/24,203.0.113.0/24. - Зарезервированные IANA:
240.0.0.0/4(заброшенное класс E). - Мультикаст-префиксы:
224.0.0.0/4. - Префиксы длиннее /24 (для IPv4) или /48 (для IPv6) от провайдеров транзитного уровня.
Пример для Cisco IOS XE (входящая фильтрация):
ip prefix-list BOGON-v4 seq 5 deny 0.0.0.0/0 le 32
ip prefix-list BOGON-v4 seq 10 deny 10.0.0.0/8 le 32
ip prefix-list BOGON-v4 seq 15 deny 172.16.0.0/12 le 32
ip prefix-list BOGON-v4 seq 20 deny 192.168.0.0/16 le 32
ip prefix-list BOGON-v4 seq 25 deny 192.0.2.0/24 le 32
ip prefix-list BOGON-v4 seq 30 deny 224.0.0.0/4 le 32
ip prefix-list BOGON-v4 seq 35 deny 240.0.0.0/4 le 32
ip prefix-list BOGON-v4 seq 40 permit 0.0.0.0/0 ge 8 le 24
Примените этот prefix-list к входящим сессиям с провайдерами с помощью route-map.
As-path-list: Контроль пути AS
As-path-list фильтрует маршруты на основе последовательности автономных систем в атрибуте AS_PATH. Ключевые задачи: не принимать маршруты, где ваш AS уже присутствует в пути (loop), и блокировать транзит через частные AS.
Готовые регулярные выражения:
^.*_64512_|_64513_|_64514_|_65000_|_65100_.*$- Блокировка путей, содержащих частные AS номера (64512-65534). Частные AS не должны появляться в глобальной таблице маршрутизации.^.*_YOUR_AS_NUMBER_.*$- Блокировка маршрутов, где ваш собственный AS номер уже есть в пути. Это предотвращает маршрутные петли.^$- Пустой AS_PATH (маршруты, анонсированные внутри вашей AS, например, через iBGP). Обычно разрешены.^_PROVIDER_AS_$- Разрешить только маршруты, идущие напрямую от вашего провайдера (путь состоит только из его AS). Полезно для клиентских подключений.
Пример для Juniper JunOS:
policy-options {
as-path-group BAD_AS_PATHS {
as-path p1 "^.*(64512|64513|65000).*$";
as-path p2 "^.*_YOUR_AS_12345_.*$";
}
policy-statement FILTER-IN {
term REJECT-BAD-AS-PATH {
from as-path-group BAD_AS_PATHS;
then reject;
}
term ACCEPT-OTHER {
then accept;
}
}
}
Route-map: Сборка логики фильтрации
Route-map связывает prefix-list, as-path-list и другие условия в единую последовательность принятия решений. Логика должна быть детерминированной.
Типичная структура route-map для входящего трафика (Cisco):
route-map RM-CLIENT-IN deny 10
match ip address prefix-list BOGON-v4
!
route-map RM-CLIENT-IN deny 20
match as-path 100 # AS-path-list с частными AS
!
route-map RM-CLIENT-IN permit 30
match ip address prefix-list CUSTOMER-PREFIXES # Только префиксы клиента
!
route-map RM-CLIENT-IN deny 40 # Явный запрет всего остального
Примените route-map к соседству:
router bgp 12345
neighbor 192.0.2.1 route-map RM-CLIENT-IN in
Для разных сценариев (прием от транзитного провайдера, пиринг, анонс клиентам) логика route-map будет отличаться. Например, на исходящих сессиях к клиентам вы должны анонсировать только свои собственные префиксы и строго запрещать default-route. Подробные сценарии рассмотрены в разделе про практическую настройку BGP для мультихостинга.
Современный стандарт: Внедрение RPKI (ROV) для валидации прав на анонсы
RPKI (Resource Public Key Infrastructure) решает фундаментальную проблему BGP: отсутствие криптографической проверки прав на анонс префикса. Владелец IP-адресного блока создает криптографическую подпись (Route Origin Authorization, ROA), которая указывает, какая автономная система имеет право анонсировать его префиксы. Маршрутизаторы, подключенные к RPKI-валидатору, могут проверять соответствие полученных анонсов этим подписям и присваивать маршрутам атрибут validity: valid, not-found или invalid.
Внедрение RPKI Origin Validation (ROV) - это поэтапный процесс.
Пошаговая настройка RPKI-валидатора (Routinator)
Routinator - это эталонная реализация RPKI-валидатора от NLnet Labs. Установка на Ubuntu/Debian:
# 1. Установка
sudo apt update
sudo apt install routinator
# 2. Инициализация репозитория доверия (Trust Anchor Locator)
sudo routinator init
# 3. Запуск валидации (первый запуск загружает все данные, это может занять время)
sudo routinator -v server --rtr 192.0.2.100:3323 --http 192.0.2.100:9556
Настройте systemd-сервис для автозапуска. Файл /etc/systemd/system/routinator.service:
[Unit]
Description=Routinator RPKI Validator
After=network.target
[Service]
ExecStart=/usr/bin/routinator server --rtr 192.0.2.100:3323
Restart=always
User=routinator
[Install]
WantedBy=multi-user.target
Проверьте работу, запросив данные через HTTP-интерфейс: curl http://192.0.2.100:9556/api/v1/validity/AS12345/192.0.2.0/24 или просмотрев логи journalctl -u routinator.
Интеграция RPKI с BGP на оборудовании Cisco и Juniper
После запуска валидатора нужно настроить маршрутизатор на подключение к нему по протоколу RTR (RPKI-to-Router).
Для Cisco IOS XR:
rpki server 192.0.2.100
port 3323
refresh time 30
response-time 10
shutdown
!
no shutdown
!
router bgp 12345
rpki origin-as validation enable
!
neighbor 203.0.113.1
remote-as 65432
address-family ipv4 unicast
rpki origin-as validation signal enable
!
!
!Создайте policy, которая отклоняет маршруты с состоянием invalid:
route-policy RPKI-VALIDATION
if validation-state is invalid then
drop
else
pass
endif
end-policy
router bgp 12345
neighbor 203.0.113.1 address-family ipv4 unicast
route-policy RPKI-VALIDATION in
!
!Для Juniper JunOS:
routing-options {
validation {
group RPKI-GROUP {
session 192.0.2.100 {
port 3323;
local-address 192.0.2.254;
}
}
}
}
policy-options {
policy-statement RPKI-FILTER {
term REJECT-INVALID {
from {
protocol bgp;
validation-database invalid;
}
then reject;
}
term ACCEPT-OTHER {
then accept;
}
}
}
protocols bgp {
group EXTERNAL {
import RPKI-FILTER;
neighbor 203.0.113.1 { ... }
}
}После настройки проверьте состояние сессии: на Cisco командой show rpki server, на Juniper - show validation session. Маршруты с атрибутом invalid будут отклоняться.
Автоматизация и расширение: Работа с IRR и генерация фильтров через bgpq3
IRR (Internet Routing Registry) - это распределенная база данных, где сети публикуют информацию о своих префиксах и политиках маршрутизации. Хотя данные в IRR не криптографически проверены, как в RPKI, они широко используются для автоматической генерации фильтров.
Утилита bgpq3 обращается к IRR и генерирует конфигурационные списки на основе зарегистрированных объектов (aut-num, route-set).
Установка и базовое использование:
# Установка на Ubuntu/Debian
sudo apt install bgpq3
# Генерация prefix-list для AS12345
bgpq3 -l "PREFIX-AS12345" -3 AS12345
# Генерация as-path-list, разрешающей транзит только через AS12345 и AS65432
bgpq3 -j -l "AS-PATH-TRANSIT" -3 "^((12345|65432)_)*$"
Создайте простой скрипт для cron, который будет обновлять конфигурацию и загружать её на маршрутизатор. Пример скрипта для Mikrotik RouterOS (использует SSH):
#!/bin/bash
# Генерация списка адресов для Mikrotik
bgpq3 -m 24 -l "IRR-AS12345" -3 AS12345 > /tmp/irr-list.rsc
# Добавление заголовка для RouterOS
echo "/ip firewall address-list remove [find list=IRR-AS12345]" > /tmp/update.rsc
echo "/ip firewall address-list" >> /tmp/update.rsc
cat /tmp/irr-list.rsc | sed 's/^ip prefix-list IRR-AS12345 permit //' | while read line; do
echo ":do { add address=$line list=IRR-AS12345 } on-error={}" >> /tmp/update.rsc
done
# Загрузка на маршрутизатор
ssh admin@192.0.2.1 "< /tmp/update.rsc"Этот подход позволяет поддерживать фильтры актуальными при изменении пула IP-адресов у клиента или партнера.
Практические сценарии для разных типов сетей
Логика фильтрации зависит от вашей роли в интернете. Вот сводные рекомендации.
1. Для транзитного провайдера:
- Входящая фильтрация от клиентов: Принимайте только те префиксы, которые принадлежат клиенту (проверяется по IRR или договору). Строго запрещайте default-route и bogon-префиксы. Внедрите RPKI с политикой reject-invalid.
- Исходящая фильтрация к клиентам: Анонсируйте только полную таблицу маршрутов или default-route, согласно договору. Никогда не транзитируйте трафик между клиентами без явного соглашения.
2. Для сети на пиринговой точке (IXP):
- Входящая фильтрация от пиров: Принимайте только глобально маршрутизируемые префиксы (не bogon). Можно использовать максимальную длину префикса /24 для IPv4. RPKI рекомендуется.
- Исходящая фильтрация к пирам: Анонсируйте только свои собственные префиксы. Используйте as-path-list, чтобы гарантировать, что ваш AS является единственным в пути (
^12345$).
3. Для корпоративной сети с мультихостингом:
- Входящая фильтрация от провайдеров: Применяйте strict RPKI (reject-invalid). Фильтруйте bogon-префиксы и префиксы длиннее /24. Это защитит ваши внутренние маршрутизаторы от переполнения таблиц.
- Исходящая фильтрация к провайдерам: Анонсируйте только свои корпоративные префиксы. Используйте as-path prepend и local-preference для управления исходящим трафиком, как описано в руководстве по multi-homing на Linux.
Диагностика, мониторинг и поддержание актуальности
Настройка фильтров - это не разовое действие. Систему нужно контролировать и периодически обновлять.
Ключевые команды для диагностики:
- Cisco:
show bgp ipv4 unicast neighbors 203.0.113.1 advertised-routes- что мы анонсируем соседу.show bgp ipv4 unicast neighbors 203.0.113.1 routes- что мы получили от соседа.show bgp ipv4 unicast 192.0.2.0/24- просмотр атрибутов конкретного маршрута, включая validation-state. - Juniper:
show route receive-protocol bgp 203.0.113.1- полученные маршруты.show route advertising-protocol bgp 203.0.113.1- анонсируемые маршруты.show route validation state invalid- список невалидных маршрутов. - Mikrotik:
/routing bgp advertisements printи/routing bgp peer print stats.
Мониторинг состояния RPKI: Настройте проверку доступности RTR-сессии. Простой скрипт для Prometheus может использовать snmp_exporter или напрямую опрашивать маршрутизатор. Критически важно настраивать алерты на сброс RPKI-сессии или на появление в таблице маршрутизации записей с состоянием invalid.
Для комплексного мониторинга BGP-сессий, утечек и доступности префиксов используйте специализированные решения, описанные в статье про мониторинг BGP и настройку алертинга в Prometheus.
График поддержания актуальности:
- Ежедневно: Проверка алертов от системы мониторинга.
- Еженедельно: Аудит логов на предмет отклоненных маршрутов (invalid RPKI, blocked by prefix-list).
- Ежеквартально: Ревизия и обновление bogon-списков (они меняются редко, но меняются). Проверка и обновление скриптов, генерирующих фильтры из IRR. Аудит ROA в RPKI для собственных префиксов.
Фильтрация BGP - это непрерывный процесс. Начните с внедрения готовых базовых конфигураций из этого руководства, затем перейдите к настройке RPKI. Автоматизируйте рутинные задачи с помощью IRR и скриптов. Это инвестиция в стабильность и безопасность вашей сетевой инфраструктуры, которая окупится предотвращением даже одного серьезного инцидента.
Для глубокого понимания принципов работы сетевых протоколов, лежащих в основе BGP и фильтрации, изучите полное руководство по протоколам маршрутизации BGP и OSPF. А для защиты всей инфраструктуры на уровне приложений ознакомьтесь с современными методами защиты от DDoS-атак.
Помните, что надежная инфраструктура начинается с правильных инструментов. Для развертывания и тестирования конфигураций из этой статьи вам может потребоваться облачная платформа, например, Timeweb Cloud, которая предоставляет гибкие виртуальные серверы и сети. А для автоматизации создания технического контента и документации рассмотрите сервисы вроде Lidbiz или агрегаторы ИИ-моделей, такие как AiTunnel.