Теоретические основы и архитектура
Лабораторная работа: комплексный аудит и харденинг (Hardening) пограничных маршрутизаторов PE и ядра MPLS по практикам NSA и Cisco SAFE. 1. Управление распространением TTL (RFC 3443): в режиме uniform (по умолчанию у Cisco) TTL IP копируется в метку, и клиентский traceroute видит все транзитные P-маршрутизаторы. Команда no mpls ip propagate-ttl включает режим pipe: TTL метки инициализируется значением 255, TTL IP в ядре не уменьшается, и клиент видит ядро как один переход между PE; вариант forwarded скрывает ядро только для транзитного трафика клиентов, оставляя инженеру трассировку с самого PE. Это лишь затрудняет разведку и не является защитой P-маршрутизаторов: настоящая защита - у клиента нет маршрута к инфраструктурным адресам (VRF), а CoPP и ACL не отвечают ему. 2. Фильтрация портов управления: отключение Telnet и HTTP, SSHv2 с ключами и таймаутами, ACL на VTY, управление через OOB-интерфейс или выделенный VRF MGMT. 3. Защита сессий BGP: аутентификация TCP MD5 или TCP-AO (RFC 5925) и GTSM (Generalized TTL Security Mechanism, RFC 5082): обе стороны шлют TTL 255, а для непосредственно подключённого пира ttl-security hops 1 принимает только TTL 254-255. GTSM защищает от атак издалека, но не от злоумышленника в том же сегменте, несовместим с ebgp-multihop и включается одновременно на обеих сторонах. Дополняет их uRPF (RFC 3704) на клиентских интерфейсах.
TTL в MPLS: uniform и pipe (RFC 3443)
При наложении метки ingress PE выбирает, как связать TTL заголовка IP с TTL метки. В режиме uniform TTL IP копируется в метку, каждый LSR уменьшает TTL метки, а на выходе значение копируется обратно (с учётом минимального): клиентский traceroute видит каждый P-маршрутизатор. В режиме pipe (и short pipe) TTL метки инициализируется фиксированным значением (255), TTL IP внутри пакета не уменьшается в ядре, поэтому клиент видит ядро как один переход между PE. Cisco по умолчанию работает в uniform; no mpls ip propagate-ttl включает pipe для всего, forwarded ограничивает режим транзитным трафиком клиентов, а local оставляет propagate для трафика, порождённого самим PE. Практичный выбор - forwarded: клиент ядро не видит, а инженер с PE по-прежнему трассирует через ядро. Junos использует no-propagate-ttl на уровне protocols mpls; в VRP режимом управляют команды ttl propagate в представлении mpls.
Побочные эффекты: ICMP-ошибки, созданные внутри ядра (например, для PMTUD), P-маршрутизатор не может отправить клиенту напрямую, поэтому они туннелируются вдоль LSP до egress PE (RFC 3032, раздел 2.3.2), а диагностика ядра переносится на ping mpls/traceroute mpls. Скрытие адресов P - это лишь затруднение разведки, а не защита: настоящая защита - клиент не должен иметь маршрута к инфраструктурным адресам (VRF), а CoPP и ACL не должны отвечать ему.
GTSM (RFC 5082): защита eBGP по TTL
Генератор пакетов вне непосредственной связности не может отправить пакет с TTL 255 так, чтобы он дошёл с TTL 255: каждый маршрутизатор уменьшает TTL. GTSM использует это: оба соседа отправляют BGP-сегменты с TTL 255, а получатель принимает только пакеты с TTL не ниже порога. Для непосредственно подключённого пира корректное значение - 255; Cisco ttl-security hops N принимает TTL от 255 - N, так что hops 1 пропускает 254-255 (и запас на один транзитный маршрутизатор). Механизм несовместим с ebgp-multihop и защищает только от атак издалека: злоумышленник в том же сегменте обходит его, поэтому GTSM сочетают с аутентификацией. Включать GTSM нужно на обеих сторонах: сторона без GTSM отправляет TTL 1, и сторона с GTSM отбрасывает такие сегменты, а сессия не поднимается.
Аутентификация сессии: MD5 и TCP-AO
Опция TCP MD5 (RFC 2385) - это дайджест MD5 поверх сегмента и общего секрета: слабая хеш-функция, нет смены ключа без разрыва, нет выбора алгоритма. TCP-AO (RFC 5925; алгоритмы HMAC-SHA-1-96 и AES-128-CMAC-96 по RFC 5926) использует опцию 29, идентификаторы ключей (KeyID и RNextKeyID) для плавной смены, ключи трафика, выводимые из мастер-ключа для каждого соединения, и защищает TCP-опции. Ни один из механизмов не шифрует данные. Поддержка зависит от платформы: IOS-XE и Junos имеют TCP-AO в современных релизах, RouterOS умеет только MD5, а Huawei предлагает свои варианты (в том числе keychain). Секрет должен быть случайным и длинным, одинаковым на обеих сторонах; при несовпадении сегменты молча отбрасываются, и на Cisco в логе появляется %TCP-6-BADAUTH (это же полезный признак подбора).
uRPF (RFC 3704, BCP 84)
Unicast Reverse Path Forwarding проверяет, что источник пакета достижим через интерфейс, на который пакет пришёл. Strict режим (Cisco ip verify unicast source reachable-via rx, Junos rpf-check, Huawei ip urpf strict, RouterOS rp-filter=strict) подходит для единственного PE-CE канала клиента. Loose режим проверяет только наличие маршрута и подходит для пиринга и multihoming; он не защищает от подделки адресов, существующих в таблице. Асимметрия трафика ломает strict, поэтому при multihoming используют feasible-режим либо loose. Проверка идёт по FIB VRF, поэтому для клиента A подмена адреса 10.255.0.2 из его VRF будет отброшена, если маршрута к ней через этот интерфейс нет.
Отключение лишнего
Поверхность атаки уменьшают отключением неиспользуемых сервисов: HTTP/HTTPS без необходимости, Telnet, CDP/LLDP на клиентских интерфейсах, proxy-ARP, ICMP redirects, IP source-routing, small servers, ip unreachables на внешних интерфейсах. Управление переводят в отдельный VRF или out-of-band сеть, SSH с ключами и таймаутами, login block-for против перебора, синхронизируют время по аутентифицированному NTP и ведут журнал. На клиентских интерфейсах MPLS отсутствует вовсе (см. урок про изоляцию VPN).
Атаки и проверки
| Атака | Механизм защиты | Ожидаемая реакция | Где смотреть |
|---|---|---|---|
| traceroute из VRF клиента | no propagate-ttl | в пути только PE и клиентские адреса | traceroute с CE |
| SYN/RST на TCP 179 с неправильным TTL | GTSM | пакет отброшен, сессия не затронута | счётчики GTSM/CoPP, show bgp neighbor |
| сессия с чужим ключом | MD5/TCP-AO | сессия не поднимается | лог BADAUTH, состояние Idle/Active |
| ping-flood на PE-CE адрес | CoPP | растёт exceeded, BGP не падает | счётчики класса ICMP/default |
| подмена источника | uRPF strict | пакеты отброшены на входе | счётчик verification drops |
| вход Telnet/SSH не из NOC | ACL VTY, CoPP | соединение отклонено | show access-lists, лог |
Безопасное внедрение
Hardening ломает сессии, если ошибиться на одной из сторон. Поэтому изменения вносят с откатом: Cisco reload in 10, Junos commit confirmed 5, RouterOS Safe Mode; GTSM и пароль меняют одновременно на обеих сторонах в окно работ, а no mpls ip propagate-ttl проверяют traceroute от клиента и с самого PE. Каждая мера проверяется атакой, а не только show running-config: если контрмера не оставляет счётчика или лога, она, скорее всего, не работает.
Схема архитектуры и топология
+-----------+ Customer Traceroute Packet (TTL=1) +-----------+
| CE-1 | ------------------------------------------------> | PE-1 |
| (Customer | Hidden Core: mpls ip propagate-ttl = disabled | (Ingress |
| Network) | <================================================ | Hardening|
+-----------+ Core P-routers invisible in traceroute +-----------+Схема прохождения трафика и стек меток
MPLS TTL Propagation vs Pipe Hardening:
1. Uniform model (Cisco default): the IP TTL is copied into the MPLS TTL
and every core hop decrements it.
Result: a customer traceroute shows all internal P router addresses
(reconnaissance help for an attacker).
2. Pipe model ('no mpls ip propagate-ttl'; 'forwarded' limits it to
customer transit traffic):
- The MPLS TTL is initialized to 255 at the ingress PE.
- Core P routers decrement only the MPLS TTL; the IP TTL is not
decremented in the core.
- A customer traceroute shows the ingress and egress PE only, so the core
addresses are hidden.
3. This only makes reconnaissance harder. Real protection: no customer
route to infrastructure addresses (VRF), CoPP and ACLs that do not
answer, uRPF on customer links.
4. Verify with traceroute from the CE and from the PE itself.