Инциденты с prefix hijacking случаются регулярно, когда трафик массово отправляется не тем путем, которым должен. Некоторые из них, может, и связаны со злым умыслом, но большинство случайны и происходят по вине невнимательных админов. Сегодня я расскажу, как провайдеры могут предотвратить их или свести к минимуму, а заодно и как самому не стать их виновником.
В примерах настроек я использую стек протоколов FreeRangeRouting. Пользователям BIRD или OpenBGPD придется действовать по аналогии.
В этой статье предполагается, что у тебя уже есть опыт работы с FRR, Quagga или Cisco IOS и базовые знания о Border Gateway Protocol (BGP).
Протокол маршрутизации BGP сам по себе не содержит никакой информации о том, кому принадлежит та или иная сеть. Анонсировать чужие префиксы при этом вполне обычная практика — небольшие сети анонсируют свои сети транзитным провайдерам с развитой сетью, а те уже анонсируют их всем остальным. Кроме того, на точках обмена трафиком активно используются так называемые сервера маршрутов (route servers), которые позволяют получать маршруты ко всем сетям участников точки сразу, без настройки отдельной сессии с каждым из них.
BGP намеренно спроектирован так, чтобы можно было фильтровать и модифицировать маршруты произвольным образом без нарушения работы самого протокола. OSPF, к примеру, принципиально не позволяет даже фильтровать входящие маршруты: поскольку каждый маршрутизатор OSPF строит и поддерживает полную карту соединений в сети, отказ одного маршрутизатора запоминать часть сети может нарушить ее связь со всеми остальными. Протоколы с отслеживанием состояния каналов (link-state) вроде OSPF прекрасно подходят для внутренней маршрутизации, где на выбор пути влияют только технические соображения: длина пути и его пропускная способность.
Поскольку интернет — объединение независимых сетей, в силу вступают экономические и политические факторы. Самый короткий путь не всегда самый выгодный. Из-за этого реализации BGP вынужденно позволяют такие виды фильтрации и модификации анонсов, которые неприемлемы в других протоколах.
Отсутствие аутентификации открывает большой простор для случайных ошибок и намеренных злоупотреблений. Давай разбираться, как их избежать.
Прежде чем рассматривать механизмы защиты от чужих ошибок, давай рассмотрим, как не стать виновником инцидента самому.
Случайная утечка одного префикса встречается крайне редко, в большинстве случаев утекает вся таблица маршрутов. Эта ситуация весьма неприятна для всех участников. Инициатор ненамеренно становится транзитным провайдером для жертв и берет на себя расходы по передаче их трафика. Если сеть не готова к возросшей нагрузке, такой инцидент способен положить и сеть инициатора, и сети жертв.
Неопытные админы, которые до этого работали с единственным подключением к провайдеру, часто забывают про фильтры.
Предположим, есть вот такой конфиг:
router bgp 64496 network 192.0.2.0/24 neighbor 203.0.113.10 remote-as 64500 neighbor 203.0.113.10 description AwfulTransit
Диапазон номеров автономных систем 64496–64511 зарезервирован для примеров и документации в RFC5398. Он не совпадает с диапазоном для частного использования (64512–65534). Разница такая же, как между диапазоном адресов IPv4 для частного использования из RFC1918 и сетями 192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24 (TEST-NET-[123]).
Сети и номера AS из частных диапазонов выделены для того, чтобы внутренние ресурсы организаций не конфликтовали в публичном интернете, а зарезервированные для документации — чтобы бездумное применение примеров из статей не конфликтовало с реальными сетями.
Мы анонсируем провайдеру сеть 192.0.2.0/24. Провайдер анонсирует нам все маршруты интернета. В этой ситуации никакие фильтры не нужны, потому что ни один протокол маршрутизации не анонсирует полученные от соседа маршруты обратно ему же. Это базовый механизм предотвращения петель маршрутизации.
В то же время все протоколы, включая BGP, анонсируют все маршруты всем остальным соседям, если не указано обратное. Чем больше связность сети и число альтернативных маршрутов к каждой сети, тем она надежнее. Если, конечно, все участники могут и согласны пропускать через себя этот трафик — а клиенты провайдеров не готовы и не согласны.
Предположим, что ты добавил подключение ко второму провайдеру:
router bgp 64496 neighbor 203.0.113.20 remote-as 64510
С такими настройками твой маршрутизатор начнет анонсировать маршруты одного провайдера другому.
Чтобы этого не произошло, нужно явно указать, что анонсировать.
Если у тебя всего один маршрутизатор BGP и все маршруты приходят из какого-то внутреннего протокола или опций network
, проще всего отфильтровать по пустому AS path. Номер автономной системы добавляется в путь маршрута не в момент его зарождения, а в момент анонса, поэтому у локально порожденных маршрутов он пустой. Пустой строке соответствует регулярное выражение ^$
.
bgp as-path access-list LocalOnly permit ^$ ! route-map LocalOnly permit 10 match as-path LocalOnly !
Если у тебя есть свои клиенты или маршруты по иной причине приходят опять же из BGP, то придется фильтровать явно, с помощью prefix-list
.
На практике в случае с клиентом и провайдером при утечке таблицы провайдер автоматически отключит сессию клиента или проигнорирует лишние маршруты. Успешный захват префиксов обычно происходит между равноправными сетями: транзитными провайдерами или участниками точки обмена трафиков.
Как провайдеры это предотвращают? Самая простая и неспецифичная мера защиты — опция maximum-prefix
.
Материалы из последних выпусков становятся доступны по отдельности только через два месяца после публикации. Чтобы продолжить чтение, необходимо стать участником сообщества «Xakep.ru».
Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», увеличит личную накопительную скидку и позволит накапливать профессиональный рейтинг Xakep Score! Подробнее
1 год7690 р. |
1 месяц720 р. |
Я уже участник «Xakep.ru»
Читайте также
Последние новости