CoPP и management plane

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

Защита control plane (Control Plane Policing, CoPP; набор мер описан в RFC 6192) - один из рубежей защиты маршрутизатора. CPU отвечает за протоколы (BGP, OSPF/IS-IS, LDP, BFD) и управление (SSH, SNMP). Любой пакет, адресованный самому маршрутизатору, а также пакеты с TTL=1, ARP/glean и ICMP-ответы уходят на CPU по каналу ограниченной ёмкости (punt). Поток в десятки тысяч пакетов в секунду на loopback способен задержать keepalive BGP, hello LDP и пакеты BFD, и сессии упадут по таймеру. CoPP полисит трафик к CPU по классам (на большинстве платформ это делается в аппаратуре; в RouterOS подобные правила выполняет сам CPU): 1. ROUTING (BGP, IGP, LDP, BFD): щедрый полисер, потому что потеря hello ведёт к потере сессии. 2. MGMT (SSH, SNMP, NTP, TACACS+): только из сети управления, средний полисер. 3. ICMP: низкий полисер, но не drop целиком, иначе ломается PMTUD. 4. DEFAULT: всё остальное, минимальный полисер или drop. CoPP ограничивает, сколько трафика дойдёт до CPU, но не заменяет ACL (кто вправе говорить с устройством), аутентификацию протоколов, GTSM и uRPF: меры дополняют друг друга. VRF клиента от этой угрозы не защищает: адрес PE-CE интерфейса доступен клиенту.

Три плоскости и путь punt

Транзитные пакеты обрабатываются в ASIC/NPU (data plane), протоколы маршрутизации и сигнализации живут на CPU маршрутизатора (control plane), а SSH, SNMP, NTP, TACACS+ и syslog относятся к management plane. Любой пакет, адресованный самому маршрутизатору (адрес loopback, интерфейса или multicast 224.0.0.2/5/6), а также пакеты с TTL=1, IP options, ARP/glean и ICMP-ответы, отправляется на CPU по внутреннему каналу ограниченной ёмкости (punt path). Этот канал и сам процессор - общий ресурс: поток в несколько десятков тысяч пакетов в секунду на loopback PE способен задержать keepalive BGP, hello LDP и пакеты BFD, после чего сессии падают по таймеру, и поток ложится на сеть каскадом. Клиент в VRF тоже достаёт до CPU: адрес PE-CE интерфейса в его VRF отвечает на ping и принимает TCP, поэтому изоляция VRF от этой угрозы не защищает.

Эшелонированная защита (RFC 6192)

RFC 6192 описывает набор независимых мер: фильтрация на границе (инфраструктурные ACL), фильтр приёма на самом маршрутизаторе (Cisco rACL, Junos фильтр на lo0), ограничение скорости по классам (CoPP), защита конкретных протоколов (аутентификация, GTSM, max-prefix) и мониторинг. Меры дополняют друг друга: ACL решает, кто вообще имеет право говорить с устройством, CoPP ограничивает, сколько он может сказать, а аутентификация проверяет, что говорит тот, кто нужно. Ни одна мера не заменяет остальные.

Классы CoPP и стартовые политики

Числа в таблице намеренно не приведены: стартовые значения подбираются по базовому профилю платформы (на 1-2 недели ставят exceed-action transmit, смотрят счётчики exceeded, затем включают drop).

Как составлять ACL для классов

Классификация идёт по адресу и порту обоих направлений: BGP-сессия, инициированная нашей стороной, возвращается пакетами с source-портом 179, а сессия, инициированная соседом, - пакетами с destination-портом 179. ACL, в которых описана только одна сторона, работают, пока таблица маршрутов не меняется, а после рестарта сессии пакеты ответов падают в class-default и сессия не может переустановить таблицу. Для IS-IS IP-ACL бесполезен: IS-IS идёт на уровне L2 (CLNP), и защищают его отдельными средствами платформы. IP-ACL в CoPP только классифицирует: permit означает "в этот класс", а не "разрешить", deny - "в другой класс".

Где CoPP применяется

• Cisco IOS-XE: MQC-политика на control-plane (aggregate); есть подразделы control-plane host для пакетов, адресованных самому устройству, control-plane transit и control-plane cef-exception. Полисер задают через police cir/police rate, а счётчики смотрят в show policy-map control-plane.
• Huawei VRP: cpu-defend policy с CAR по типам пакетов (car packet-type), белыми и чёрными списками на ACL; политику применяют глобально или к конкретной плате.
• Juniper Junos: фильтр firewall family inet filter на вход lo0.0 (фильтр применяется ко всему, что идёт на RE), плюс встроенный DDoS protection (ddos-protection) с полисерами на каждый протокол. Фильтр lo0 с терминами accept для нужных протоколов и замыкающим discard - стандартная схема защиты RE.
• MikroTik RouterOS: /ip/firewall/filter в цепочке input с адрес-листами и limit=; специального CoPP-механизма нет, а правила выполняются на CPU, поэтому ставят их в /ip/firewall/raw для раннего drop.

Management plane: SSH, VTY, AAA, SNMPv3

• SSH-only: SSHv2, ключ RSA от 2048 бит, Telnet и HTTP отключены, на линиях transport input ssh, таймаут exec-timeout, ограничение числа попыток входа.
• ACL на VTY: access-class с vrf-also разрешает вход только с сети управления. Это второй рубеж после CoPP: CoPP ограничивает скорость, ACL VTY - источник.
• AAA/TACACS+: аутентификация, авторизация по привилегиям и построчный accounting команд на TACACS+ (RFC 8907) с резервом local, чтобы потеря сервера не заперла инженера вне устройства. Секрет сервера хранят в закрытом виде, консольная линия получает собственный метод. RouterOS не умеет TACACS+, только RADIUS.
• SNMPv3: уровень authPriv (SHA и AES), пользователь привязан к группе и ограниченному view, источники фильтруются ACL. Community v1/v2c отключаются: строка передаётся открытым текстом.

Связь с TTL, uRPF и GTSM

TTL propagation (no mpls ip propagate-ttl) прячет ядро от traceroute, GTSM (RFC 5082) отбрасывает сессионные пакеты BGP с TTL ниже порога, uRPF (RFC 3704) режет пакеты с поддельным источником. Эти механизмы дополняют CoPP, но настраиваются отдельно и разобраны в лабораторной работе по hardening PE.

Как проверять

Сначала счётчики классов (conformed и exceeded) и попадания ACL, затем нагрузка: с недоверенного источника запускают поток на loopback и убеждаются, что exceeded растёт в DEFAULT/ICMP, а BGP/LDP/BFD остаются Established, и CPU не вырос. Каждое изменение ACL сопровождают проверкой, что сессия соседей подтверждается после clear с soft reset, а не только в состоянии покоя.

Схема архитектуры и топология