antiCisco blogs


блоги по технологиям и оборудованию cisco от инструкторов

Опубликовано 5 Июнь , 2012

CPPr является одной из технологий Cisco IOS для превентивной защиты от сетевых атак, которые направлены непосредственно на сетевое устройство. Control Plane обрабатывает на себе пакеты протоколов маршрутизации и управления, такие как OSPF, BGP, EIGRP, RIP, Telnet, SSH, SNMP. Типичной атакой на control plane является атака типа «выработка ресурсов», т.е. злоумышленник пытается полностью «забить» control plane зловредными пакетами и вызвать отказ в обслуживании для легитимных данных. На большинстве устройств под управлением Cisco IOS Control Plane крутится непосредственно на центральном процессоре (CPU), разделяя его мощность с пакетами, которые обрабатывается по process switching. Поскольку обработкой каждого такого пакета занимается один процессор (да и к тому же не особо мощный), то «забить» его в целом не сложно.

Начиная с IOS 12.3T у циски появилась фича, которая называется Control Plane Policing (CoPP). Она позволяет применить технологию полисинга для пакетов, которые движутся в направлении Control Plane’а. Т.е., по большому счету, CoPP позволяет защитить CPU железки от направленного на нее DoS’а.

Больше того, железки под Cisco IOS понимают CPU как некий виртуальный интерфейс, которые посредством внутренней шины передачи данных соединен непосредственно с маршрутизатором. При этом, все пакеты, которые предназначаются процессору классифицируются на три группы и направляются в соответствующий подинтерфейс этого виртуального интерфейса (получается эдакий 802.1Q транк J). Рассмотрим эти подинтерфейсы:

Control Plane Host. Этот интерфейс получает весь IP трафик (вернее, почти весь), который предназначается любому из интерфейсов маршрутизатора. Примеры протоколов, которые обрабатываются на этом интерфейсе: SSH, EIGRP, iBGP, SNMP. Здесь для защиты применяются такие технологии, как полисинг, фильтрация портов и ограничение длины очереди.

Control Plane Transit. Этот интерфейс предназначен для обработки транзитных IP-пакетов, которые не обрабатываюся CEF’ом. Например это может быть пакет, которые роутится через интерфейс FastEthernet, но для следующего хопа еще не построена ARP-запись, что приводит к незавершенной CEF-adjacency таблице.

Control Plane CEFexception. Этот интерфейс получает весь трафик, который CEF’ом не обрабатывается в принципе. Например: eBGP, OSPF, CDP/LLDP, L2 keepalive’ы,  ARP и все IP-пакеты с TTL=[0, 1].

Вы можете применять технологии ограничения полосы пропускания как на каждый подинтерфейс в отдельности, так и целиком на Control Plane (классический CoPP).

Прим.: не рекомендую комбинировать эти две вещи вместе, поскольку часто наблюдается нестабильное поведение системы

 

Перед тем как пакет попадет в тот или иной подинтерфейс Control Plane, он сначала обрабатывается рядом технологий: входной ACL, uRPF, CoPP. Если на этих этапах пакет не был дропнут, то он попадает во входную очередь соответствующего подинтерфейса Control Plane и далее обрабатывается по SPD (Selective Packet Discard).

Рассмотрим как настроить указанные технологии. Все начинается с создания классовых карт, которые отлавливают трафик на Control Plane. После этого создаются карты политик и применяются на тот или иной интерфейс в Control Plane. Все логично и понятно.

Прим.: вы не можете использовать NBAR для этих целей

 

Поставим следующую задачу:

— необходимо дропать все пакеты, которые «идут» на закрытые порты маршрутизатора (т.е. те, которые не слушаются) перед тем, как пакет достигнет CPU. Сделать исключение для порта TCP/3020 (например, мы используем rotary group 20 на vty).

— для уменьшение широковещательных штормов ограничить полосу для не IP-трафика 200-ми пакетами в секунду

— установить размер входной очереди для HTTP-пакетов в размере 100 и ограничить их скорость входа на отметке 20 пакетов в секунду

— ограничить весь транзитный фрагментированные трафик через маршрутизатора скоростью 1 Мб/с

Начнем с первого пункта. Для этого создадим специальную классовую карту, которая будет отлавливать все закрытые порты. Затем для всего трафика, которые попадет под ее действие применим политику типа «drop» внутри карты политик

class-map type port-filter match-all CLASS_CLOSED-PORTS
 match closed ports
 match not port tcp 3020
 policy-map type port-filter POLICY_CLOSED-PORTS
 class CLASS_CLOSED-PORTS
  drop

Прим.: команда match closedports а автоматическом режиме детектирует все открытые порты в системе и остальные помечает как «закрытые». Посмотреть какие порты у Вас на данный момент открыты можно командой show controlplane host open ports

 

На втором шаге, ограничим полосу для не IP-пакетов

policy-map POLICY_CEF-EX
 class class-default
  police rate 200 pps

Для задания глубины очереди сначала необходимо отловить интересный трафик классовой картой типа queue-threshold, а затем поместить ее в соответствующую ей карту политик

class-map type queue-threshold match-all CLASS_HTTP-QUEUE
 match protocol http
policy-map type queue-threshold POLICY_QUEUE
 class CLASS_HTTP-QUEUE
  queue-limit 200

Прим.: можно применить всего одну политику типа queuethreshold, но внутри нее можно создавать применять различные параметры для разных классов трафика. Также, внутри классовой карты указанного типа можно задать команду match hostprotocols для выбора всех TCP/UDP протоколов, которые «крутятся» на маршрутизаторе

 

Ограничить скорость для HTTP несложно классическим методом

ip access-list extended ACL_HTTP
 permit tcp any any eq 80
class-map CLASS_HTTP
 match access-group name ACL_HTTP
policy-map POLICY_RATE-LIMIT
 class CLASS_HTTP
  police rate 20 pps

И тоже самое применим для фрагментированного трафика (согласно заданию)

ip access-list extended ACL_FRAGMENTED
 permit ip any any fragments
class-map CLASS_FRAGMENTED-PACKETS
 match access-group name ACL_FRAGMENTED
policy-map POLICY_TRANSIT-PACKETS
 class CLASS_FRAGMENTED-PACKETS
  police rate 1000000 pps

Последним шагом является применение созданных политик на интерфейсы. Вы можете использовать команду control-plane {host | cef-exception | transit} для выбора нужного подинтерфейса. Обращаю внимание на то, что Вы не можете сконфигурировать выходной полисинг для любого подинтерфейса Control Plane.

control-plane cef-exception
 service-policy input POLICY_CEF-EX
control-plane transit
 service-policy input POLICY-TRANSIT-PACKETS
control-plane host
 service-policy type queue-limit POLICY_QUEUE
 service-policy type port-filter POLICY_CLOSED-PORTS
 service-policy input POLICY_RATE-LIMIT
 

Метки: ,
Опубликовано: Безопасность cisco , Маршрутизаторы и коммутаторы

 

4 комментария “Защита области контроля (Control Plane Protection, CPPr)”

comment rss - Trackback

  1. Aleks305:

    Почитал, очень хорошая статья!Когда готовился к CCNPSec до конца не смог разобраться — это хорошее подспорье. Спасибо.

  2. Aleks305:

    class-default в policy-map POLICY_CEF-EX описывает весь не ip-траффик?

  3. fantas1st0:

    class-default — описывает просто class-default, т.е. все то, что явно не описано 🙂
    А почему в данном контексте это «не IP» — ибо далее эта карта применяется на control-plane cex-exception интерфейс

  4. self:

    Тут ещё надо учесть, что с match closed-ports есть подводные камни. Например, невозможность детектировать GET VPN (udp 848). То есть надо специально исключать этот порт в правиле, иначе просто сессия не установится.
    Так что надо быть осторожным! =)

» Оставить комментарий

Вы должны войти чтобы прокомментировать.