Теоретические основы и архитектура

Уроки об изоляции VPN и защите плоскости управления отвечают на вопрос "что закрыть", а здесь разбираются четыре механизма, которые это закрывают на периметре оператора. Режим распространения TTL определяет, увидит ли клиент в traceroute адреса P-маршрутизаторов, и как ICMP time-exceeded добирается до источника через LSP. uRPF (RFC 3704, BCP 84) отбрасывает пакеты с поддельным адресом источника: строгий режим подходит клиентам, свободный - стыкам с несколькими провайдерами, а default-маршрут легко делает проверку бессмысленной. GTSM (RFC 5082) принимает только пакеты с TTL 255 от непосредственного соседа и отсекает удалённую атаку на сессии eBGP и LDP. Наконец, аутентификация: TCP-AO (RFC 5925) вместо слабого MD5, HMAC-ключи для OSPF и IS-IS, пароли LDP, а также ротация ключей без разрыва сессий и типичные ловушки с часами и сроками действия. Урок предполагает, что вы уже прошли разделы об изоляции VPN, CoPP и фильтрации BGP и хотите довести защиту до уровня эксплуатации.

TTL в MPLS: два режима и их цена

Метка MPLS несёт собственный 8-битный TTL, и при добавлении метки ingress выбирает его значение. В режиме uniform (RFC 3443) TTL метки копируется из IP, на каждом хопе уменьшается, а на выходе копируется обратно (с проверкой, что значение не растёт): ядро видно в traceroute, а клиент получает единый счётчик. В режиме pipe (на Cisco no mpls ip propagate-ttl, на Junos no-propagate-ttl, на Huawei undo ttl propagate) метка получает TTL 255, IP TTL не уменьшается в ядре, а на выходе уменьшается лишь на 1 хоп; ядро для клиента невидимо. Это скрывает адресацию P-маршрутизаторов (меньше целей для атак и сканирования, адреса ядра не утекают в трассировки), но усложняет диагностику у клиента: traceroute показывает PE1 и PE2 как соседей. На Cisco вариант forwarded скрывает только транзитный трафик, а локально порождённый трафик оператора остаётся в режиме uniform, поэтому traceroute с самого PE по-прежнему показывает ядро.

Следствия для диагностики. Когда TTL метки истекает на P, тот строит ICMP time-exceeded, но маршрута в приватное адресное пространство клиента у P нет: сообщение отправляется дальше по тому же LSP, доходит до egress PE, а уже оттуда возвращается источнику (RFC 3032, ICMP tunneling). Поэтому RTT всех хопов внутри ядра равны RTT до egress, и по задержкам хопов нельзя искать проблемный участок. Если ядро видно, traceroute с поддержкой RFC 4950 дополнительно показывает стек меток из расширения ICMP, а вместе с ним и метки VPN: в обычной эксплуатации нужно решить, готовы ли вы показывать их клиентам. Для внутренней диагностики оператору есть LSP ping/traceroute (RFC 8029), который работает независимо от режима TTL. При петле маршрутизации в pipe-режиме пакет с TTL метки 255 циркулирует до 255 хопов, поэтому защиту от петель обеспечивают протоколы, а не TTL.

uRPF: строгий, свободный, допустимые пути

Reverse Path Forwarding (RFC 3704, BCP 84) проверяет адрес источника пакета на входе. Строгий режим: лучший маршрут к источнику должен вести через интерфейс, с которого пакет пришёл. Это подходит для клиентских интерфейсов с симметричной маршрутизацией. Свободный режим (Cisco reachable-via any, Junos mode loose): в FIB достаточно любого маршрута к источнику, значит отсекаются только адреса без маршрута (bogons, неанонсированные пространства). Допустимые пути (feasible path, RFC 3704 раздел 2.4): проверка допускает любой маршрут к источнику из RIB, даже не лучший; это подходит для multihoming, когда трафик клиента может прийти и по резервному линку (на Junos - forwarding-table unicast-reverse-path feasible-paths). Практический выбор: клиенты с одним линком - строгий; клиенты с несколькими линками и BGP - feasible или свободный плюс ACL; стыки с провайдерами и IXP - свободный плюс ACL по bogon-префиксам (RFC 6890).

Ловушки. Default-маршрут: если в FIB есть 0.0.0.0/0, любой адрес источника имеет "маршрут", и свободный режим пропускает всё. Поэтому по умолчанию default в проверке не учитывается (Cisco allow-default включает его намеренно, на Huawei allow-default-route), и там, где default на клиенте нужен, он делает проверку бесполезной: на таких интерфейсах строгий режим работает только тогда, когда default указывает не на этот интерфейс. Асимметрия: если трафик клиента уходит по одному линку, а возвращается по другому, строгий режим дропает законный трафик. ECMP: при нескольких равных путях строгий режим должен принимать любой из них (платформы различаются). VRF: проверка идёт по FIB этого VRF, поэтому для клиентского интерфейса в VRF важно, чтобы маршруты клиента были в его VRF, а импортированные маршруты других VRF не расширяли допустимое множество. Счётчики: считайте отброшенные пакеты по интерфейсам, иначе вы не увидите, что проверка рвёт легитимный трафик.

GTSM (RFC 5082)

Generalized TTL Security Mechanism использует тот факт, что TTL уменьшается на каждом маршрутизаторе. Отправитель шлёт пакеты с TTL 255, приёмник принимает их, только если TTL не меньше 255 минус число допустимых хопов плюс 1: при hops 1 принимается лишь 255, то есть пакет от непосредственного соседа. Атакующий в другой сети не может отправить пакет, который придёт с TTL 255. Проверка выполняется до разбора TCP, и поэтому дешевле криптографии: пакеты вне диапазона дропаются раньше, чем потратят ресурсы ЦП (в идеале аппаратно). Область применения: eBGP между напрямую подключёнными узлами (Cisco neighbor ... ttl-security hops 1, Huawei valid-ttl-hops), LDP (RFC 6720), OSPF и другие протоколы на связности в один хоп. Ограничения: GTSM несовместим с ebgp-multihop (используется одно из двух), не защищает от злоумышленника на самом линке (общий сегмент, IXP), не работает через туннели и MPLS с уменьшением TTL, а при eBGP через loopback требует hops по числу хопов. Это защита от удалённых атак, а не замена аутентификации.