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 CEF—exception. Этот интерфейс получает весь трафик, который 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 closed—ports а автоматическом режиме детектирует все открытые порты в системе и остальные помечает как «закрытые». Посмотреть какие порты у Вас на данный момент открыты можно командой show control—plane 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Прим.: можно применить всего одну политику типа queue—threshold, но внутри нее можно создавать применять различные параметры для разных классов трафика. Также, внутри классовой карты указанного типа можно задать команду match host—protocols для выбора всех 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
Метки: cef, CPPr
Опубликовано: Безопасность cisco , Маршрутизаторы и коммутаторы
Почитал, очень хорошая статья!Когда готовился к CCNPSec до конца не смог разобраться — это хорошее подспорье. Спасибо.
class-default в policy-map POLICY_CEF-EX описывает весь не ip-траффик?
class-default — описывает просто class-default, т.е. все то, что явно не описано 🙂
А почему в данном контексте это «не IP» — ибо далее эта карта применяется на control-plane cex-exception интерфейс
Тут ещё надо учесть, что с match closed-ports есть подводные камни. Например, невозможность детектировать GET VPN (udp 848). То есть надо специально исключать этот порт в правиле, иначе просто сессия не установится.
Так что надо быть осторожным! =)