в любой маршрутизатор Cisco встроены:

• прозрачный межсетевой экран Cisco IOS Firewall;
• средство построения VPN (IPSec или SSL) Cisco IOS VPN;
• прозрачная система предотвращения атак (Intrusion Prevention System) Cisco IOS IPS.

Помимо этих хорошо известных механизмов существует и множество других не менее важных и полезных функций, делающих из обычного маршрутизатора полноценное защитное устройство, ориентированное на защиту небольших и средних офисов. Аналогичный тезис применим и к коммутаторам.

C чего начинается администрирование маршрутизатора

Администрирование функций безопасности нужно для защиты сети (внешней и внутренней) от несанкционированной активности. А значит, прежде чем начинать копаться в настройках оборудования, необходимо понять, что и от чего ты защищаешь. Начинай с политики безопасности, которая должна:

• описывать, какие ресурсы, кому, когда и как можно использовать;
• описывать все информационные потоки в защищаемой сети;
• не забывать о защите самих средств обеспечения информационной безопасности;
• быть технически реализуемой;
• быть последовательной;
• быть глобальной и применимой ко всей сети, а не к отдельным ее сегментам;
• четко описывать роли и ответственность всех заинтересованных лиц;
• быть гибкой к постоянно изменяющимся технологиям и бизнес-процессам;
• быть понятной;
• включать в себя не только задачи отражения угроз, но и процессы расследования и реагирования на атаки.

И еще грамотная политика безопасности не должна диктовать бизнесу, как ему работать — все должно быть с точностью наоборот. При этом политика не должна зависеть от используемых средств защиты. Сегодня это может быть маршрутизатор Cisco 871W, завтра маршрутизатор Cisco ISR 3845, а послезавтра многофункциональное защитное устройство «все в одном» Cisco ASA 5550. Грамотная политика будет без изменений «работать» для любого из этих устройств. Более того, если требования по защите не очень специфичны, то эта же политика может быть использована и для других производителей средств защиты.

Принципы безопасности маршрутизаторов Cisco

Маршрутизатор может быть логически разделен на 4 функциональных компонента, отвечающих за решение своих задач:

1. Data Plane – уровень данных, через который проходит весь сетевой трафик.
2. Control Plane – уровень построения и обновления таблиц маршрутизации.
3. Management Plane – уровень управления маршрутизатором (SSH, SNMP, syslog и т.д.)
4. Service Plane – уровень обеспечения качества сервиса и уровня обслуживания.

Очевидно, что механизмы защиты маршрутизаторов должны быть применены ко всем этим уровням без исключения. Причем защита уровней управления и контроля зачастую является даже более важной, чем безопасность уровня данных. Списки контроля доступа (Access Control List, ACL), однонаправленная проверка передачи по обратному маршруту (Unicast Reverse Path Forwarding, uRPF), ограничение полосы пропускания (Committed Access Rate, CAR) и так далее очень важны, но позволяют ограничить только определенные типы трафика. А вот недооценка вопросов самозащиты самого маршрутизатора может повлечь за собой печальные последствия – захват и компрометация всего устройства, локальное или дистанционное изменение таблиц маршрутизации, перехват трафика, реализация атак «отказ в обслуживании» (Denial of Service, DoS) и т.п.

AutoSecure

Несколько лет назад по Интернету ходил анекдот: «Чем отличается Windows 95 от Windows 98? Тем, что в Windows 95 не используется 95% возможностей, а в Windows 98 не используется 98% возможностей». Отчасти это так. Производители, чтобы удовлетворить как можно больше запросов со стороны своих заказчиков, оснащают свои продукты очень большим количеством функций, которые зачастую висят «мертвым» грузом и у многих попросту не используются (многие ли используют асимметричную маршрутизацию?). Хорошо, если эти функции просто не мешают. Но что делать, если они становятся каналом проникновения злоумышленников?

При администрировании операционных систем существует правило – «отключить все, что не нужно для выполнения поставленных задач». Аналогичное правило применимо и к сетевому оборудованию. Вручную отключать десятки неиспользуемых механизмов – дело неблагодарное (можно что-то и забыть). Поэтому в маршрутизаторах Cisco, начиная с версии IOS 12.3, появился механизм AutoSecure, который:

• запрещает потенциально опасные глобальные сервисы (Finger, Packet assembler and disassembler, TCP/UDP Small Services, Bootp Server, HTTP Server, CDP, NTP, Source Routing…);
• запрещает потенциально опасные сервисы по интерфейсам (ICMP, Proxy-Arp, Broadcast, MOP, ICMP Unreachable, ICMP Reply);
• включает расширенные механизмы защиты (шифрование паролей, настройка баннеров, взаимодействие с серверами аутентификации, антиспуфинг, Cisco Express Forwarding, блокирование зарезервированных адресов IANA, установка маршрута по умолчанию NULL 0, CBAC, Netflow…);
• обеспечивает защиту самого маршрутизатора (SSH и SCP, настройка паролей и учетных записей, блокирование SNMP…);
• включает регистрацию событий безопасности.

Cisco AutoSecure может функционировать в двух режимах — интерактивном и автоматическом. В первом случае администратор отвечает на вопросы о своей собственной сети, а во втором – настройка осуществляется автоматически, в соответствие с параметрами по умолчанию. Причем включить Cisco AutoSecure можно всего одной командой: Router# auto secure.

По окончании работы сервиса на экран выводится список всех сделанных настроек, и администратор должен разрешить все сделанные изменения. Проверка может быть осуществлена двумя путями – с помощью Security Device Manager (SDM) и команды IOS EXEC, которая показывает настройки, сделанные после AutoSecure. Наиболее интересен именно первый путь (функция Security Audit), так как он позволяет в удобном виде получить ответ на вопрос: «Какие из существующих механизмов защиты включены, а какие нет?».

Расширения IOS Login

Начиная с версии IOS 12.2(25)S, маршрутизаторы Cisco могут существенно усложнить жизнь злоумышленникам, желающим получить несанкционированный доступ к сетевому оборудованию. Одна из распространенных атак, позволяющих получить такой доступ, — подбор пароля. Для этого используются различные утилиты, к примеру, THC-Hydra или Brutus. Самый простой путь блокировать эту атаку – увеличить время задержки между попытками ввода логина и пароля. Сделать это можно тремя путями: через уже описанную функцию AutoSecure, или с помощью специальных команд – login delay и login block-for. Эти команды можно использовать и в паре.

Router(config)# login block-for 100 attempts 5 within 50

Router(config)# login quiet-mode access-class myacl

Router(config)# login delay 10

Router(config)# login on-failure log

Router(config)# login on-success log

Первая команда должна вводиться до использования любых других команд login. Она на 100 секунд блокирует любые попытки подключения к устройству, если в течение 50-ти секунд было осуществлено 5 неудачных регистраций на маршрутизаторе. Если есть адреса, которые не должны быть блокированы (например, административные), то они описываются командой login quiet-mode access-class. Команда login delay определяет время задержки перед разрешением повторной регистрации. Если ее не указать, то автоматическая задержка будет осуществлена по команде login block-for на 1 секунду. Последние 2 команды включают регистрацию успешных и неудачных попыток подключения к маршрутизатору.

Проверить настройки подсистемы регистрации можно путем использования команды show login. А команда show login failures показывает все неудачные попытки подключения к устройству.

Защита уровня контроля

Почти все архитектуры уязвимы к атакам «отказ в обслуживании». При атаке на сетевое оборудование это несет серьезную опасность, так как выведение его из строя приводит к неработоспособности всей сети. Необходимо оградить процессор маршрутизатора от обработки вредоносного трафика и, начиная с версии IOS 12.2, такая возможность появилась и стала носить название Control Plane Policing. С ее помощью можно:

• классифицировать и ограничить каждый класс трафика, поступающий на обработку в уровень контроля;
• обеспечить механизм раннего отбрасывания пакетов, направленных на закрытые или иные TCP/UDP-порты;
• обеспечить защиту от протокольного флудинга;
• обеспечить QoS для пакетов, направленных на уровень контроля;
• обеспечить надежность, защищенность и доступность.

Для реализации данного механизма необходимо пройти 4 обязательных и 2 опциональных шага:

1. Задать критерии для классификации пакетов.
2. Определить политики сервиса.
3. Перейти в режим настройки.
4. Применить политики.
5. Настроить политики фильтрации портов (для раннего отбрасывания пакетов).
6. Настроить политики пороговых значений (защита от протокольного флудинга).

Для реализации первой задачи необходимо использовать 2 команды: задающую имя класса трафика (class-map) и описывающую критерии для данного трафика (match). Параметр match-any говорит о том, что хотя бы один критерий классификации должен встретиться в трафике (использование параметра match-all требует обнаружения всех критериев):

Router(config)# class-map match-any control-plane-class

Router(config-cmap)# match access-group name cpp-icmp-acl

Для определения политики необходимо выполнить 3 команды: задающую имя политики (policy-map), класс (class) и определяющую политику (police):

Router(config)# policy-map control-plane-policy

Router(config-pmap)# class control-place-class

Router(config-pmap-c)# police rate 50000 pps conform-action transmit exceed-action drop

Применение политики осуществляется в 2 задачи – связывание политики с субинтерфейсом (control-plane) и указание имени используемой политики:

Router(config)# control-plane host

Router(config-cp)# service-policy input control-plane-policy

Для оставшихся 2-х опциональных задач необходимо использование команды class-map type, схожей по синтаксису с командами, описанными выше. Фильтрация портов и пороговых значений описывается следующим образом:

Router(config)# class-map type port-filter match-all pf-class

Router(config-cmap)# match closed-ports

Router(config-cmap)# exit

Router(config)# policy-map type port-filter cppr-pf-policy

Router(config-pmap)# class pf-class

Router(config-pmap-c)# drop

Router(config-pmap-c)# end

Router(config)# control-plane host

Router(config)# service-policy input cppr-pf-policy

Router(config)# class-map type queue-threshold qt-snmp-class

Router(config-cmap)# match protocol snmp

Router(config-cmap)# class-map type queue-threshold qt-telnet-class

Router(config-cmap)# match protocol telnet

Router(config-cmap)# class-map type queue-threshold qt-other-class

Router(config-cmap)# match host-protocols

Router(config-cmap)# exit

Router(config)# policy-map type queue-threshold qt-policy

Router(config-pmap)# class qt-snmp-class

Router(config-pmap-c)# queue-limit 50

Router(config-pmap-c)# class qt-telnet-class

Router(config-pmap-c)# queue-limit 50

Router(config-pmap-c)# class qt-other-class

Router(config-pmap-c)# queue-limit 150

Router(config-pmap-c)# end

Проверить настройки подсистемы регистрации можно путем использования команды show policy map control-plane.

Защита уровня управления

Механизм Control Plane Policing (CoPP) позволяет защитить маршрутизатор от обработки вредоносного трафика и не дать ему попасть в защищаемую сеть. Однако все равно остается проблема защиты самого устройства от несанкционированного доступа. Эту задачу решает механизм Management Plane Policing (MPP), который позволяет описать один или несколько интерфейсов маршрутизатора как управляющие, что, в свою очередь, блокирует любые попытки управления с «неуправляющих» интерфейсов. Иными словами, ты ограничиваешь доступ по протоколам FTP, HTTP, HTTPS, SSH, Telnet, SNMP и TFTP. Это, конечно, можно было бы реализовать и с помощью списков контроля доступа (ACL), но в этом случае снижается производительность и масштабируемость маршрутизатора, вынужденного тратить ресурсы на обработку ACL. Настройка данного механизма осуществляется достаточно просто:

Router(config)# control-plane host

Router(config-cp-host)# management-interface FastEthernet 0/0 allow ssh snmp

Первая команда включает режим конфигурации, а вторая - задает его настройки. После параметра allow можешь указать протоколы, которые разрешаются на данном интерфейсе (в приведенном примере только SSH и SNMP).

Проверить наличие и настройки управляющих интерфейсов можно командой Router# show management-interface.

CPU и Memory Thresholding Notification

Очень часто признаком атаки «отказ в обслуживании» или другой вредоносной активности является перегрузка центрального процессора или нехватка памяти, вызванные наличием какого-нибудь процесса, «забирающего» все ресурсы «под себя». Механизм контроля аналогичных действий есть в маршрутизаторах Cisco: в CPU и Memory Threshholding Notification.

В первом случае можешь сигнализировать, когда загрузка процессора превышает максимально заданную или падает ниже минимально заданной границы. Делается это следующим образом:

Router(config)# snmp-server enable traps cpu threshold

Router(config)# snmp-server host 192.168.0.0 traps public cpu

Router(config)# process cpu threshold type total rising 80 interval 5 falling 20 interval 5

Первая команда разрешает посылать уведомления о нарушении, связанном с загрузкой процессора. Вторая описывает адрес, на который посылается SNMP Trap. Третья команда устанавливает пороговые значения: верхняя граница – 80% и нижняя граница – 20% (5 – это интервал запроса значения загрузки CPU).

Задание уведомления о критическом превышении доступной памяти выполняется аналогичным образом. При этом ты видишь генерацию сигнала тревоги, когда в маршрутизаторе остается меньше 20 Кб свободной процессорной памяти или памяти ввода/вывода.

Router(config)# memory free low-watermark processor 20000

или

Router(config)# memory free low-watermark io 20000

С сигнализацией о нехватке памяти связан механизм выделения определенного объема памяти под критичные задачи (например, под регистрацию событий). Это позволяет быть уверенным, что важная операция все равно будет произведена даже при условии нехватки памяти. При этом резервируемая память не должна превышать 25% от всего объема доступной памяти.

Router(config)# memory reserve critical 1000

IOS Software Image Verification

Регулярно на различных форумах всплывает тема встраивания «чужого» кода в Cisco IOS, и какая это огромная угроза всему Интернет. Но с самого начала целостность кода, загружаемого на маршрутизатор, можно проверять – достаточно сравнить контрольную сумму MD5 имиджа IOS, установленного на устройство, с суммой, показанной на сайте cisco.com. Однако не многие пользователи делали это, ссылаясь на сложность и длительность процедуры. Чтобы облегчить такую «непростую» задачу, у пользователей в версии 12.0(26)S появилась команда verify, которую можно и удобно использовать в трех случаях:

1. Глобальная и автоматическая проверка целостности имиджа (после любой попытки копирования или перезагрузки).

Router(config)# file verify auto

2. Проверка целостности имиджа после копирования из какого-либо источника.

Router(config)# copy /verify tftp://10.1.1.1/jdoe/c7200-js-mz disk0:

3. Проверка целостности имиджа после перезагрузки устройства.

Router# reload /verify

Flexible Packet Matching

Многие слышали о том, что в маршрутизаторы Cisco встроена система предотвращения атак Cisco IOS IPS. Но очень мало кто слышал о Flexible Packet Matching, которая позволяет описывать и обнаруживать любые интересующие события, например, атаки, для которых еще никто не написал сигнатуры. Делается это с помощью XML, который позволяет описать любые поля заголовка пакета и тела данных любого протокола. Для наиболее распространенных из них существуют специальные файлы описания заголовка протокола – Protocol Header Definition File, PHDF.

фрагмент PHDF файла для протокола IP

<phdf>

<version>1</version>

<protocol name="ip" description="Definition-for-the-IP-protocol">

<field name="version" description="IP-version">

<offset type="fixed-offset" units="bits">0</offset>

<length type="fixed" units="bits">4</length>

</field>

<field name="ihl" description="IP-Header-Length">

<offset type="fixed-offset" units="bits">4</offset>

<length type="fixed" units="bits">4</length>

</field>

<field name="tos" description="IP-Type-of-Service">

<offset type="fixed-offset" units="bits">8</offset>

<length units="bits" type="fixed">8</length>

</field>

…

<headerlength type="fixed" value="20"></headerlength>

<constraint field="version" value="4" operator="eq"></constraint>

<constraint field="ihl" value="5" operator="eq"></constraint>

</protocol>

</phdf>

Описать же любую атаку с помощью FPM становится совсем нетрудно (если понимать критерии для этой атаки).

классический SYN Flood

! Загружаем файлы описания заголовков IP и TCP

Router(config)# load protocol flash:ip.phdf

Router(config)# load protocol flash:tcp.phdf

! В классе stack определяем последовательность заголовков

Router(config)# class-map type stack match-all ip_tcp

Router(config-cmap)# description "match TCP over IP packets"

Router(config-cmap)# match field ip protocol eq 0x6 next tcp

! Определяем критерии для атаки SYN Flood

Router(config)# class-map type access-control match-all tcpsynflood

Router(config-cmap) # description "match on tcp syn packets from source address 10.10.10.3"

Router(config-cmap)# match field ip source-addr eq 10.10.10.3

Router(config-cmap)# match field tcp control bits eq 2 mask 0x3D

! Определяем действие для данного трафика (блокирование), а потом применяем данную политику (!) к нужному интерфейсу

Router(config)# policy-map type access-control fpm_tcp_syn_policy

Router(config-pmap)# description "policy for TCP SYN flood attacks"

Router(config-pmap)# class tcpsynflood

Router(config-pmap-c)# drop

Router(config)# policy-map type access-control fpm_policy

Router(config-pmap)# description "drop tcp syn packets from source address 10.10.10.3"

Router(config-pmap)# class ip_tcp

Router(config-pmap-c)# service-policy fpm_tcp_syn_policy

Router(config)# interface GigabitEthernet 0/1

Router(config-if)# service-policy type access-control input fpm_policy

Advanced Application Inspection and Control

Решения Cisco давно вышли из определения, данного в любом компьютерном словаре термину «маршрутизатор». Например, когда говорят о контроле доступа к защищаемым ресурсам (внешним или внутренним), то обычно первое, что приходит в голову – списки контроля доступа (Access Control List, ACL), существующие в любом маршрутизаторе. Однако, как только заговаривают о контроле прикладного трафика (например, блокировании Instant Messaging или P2P), то все начинают смотреть в сторону отдельных устройств. А ведь в маршрутизаторах Cisco есть и такие функции защиты. И это не только описанный выше Flexible Packet Matching или известный не первый год механизм Network-Based Application Recognition (NBAR). Для контроля того же прикладного трафика можно использовать команду ip inspect.

фрагмент конфигурации для дополнительной проверки популярных протоколов на соответствие политике безопасности

ip inspect name my-ios-fw http

ip inspect name my-ios-fw https

ip inspect name my-ios-fw esmtp

ip inspect name my-ios-fw pop3

ip inspect name my-ios-fw imap3

ip inspect name my-ios-fw dns

ip inspect name my-ios-fw ftp

ip inspect name my-ios-fw ntp

ip inspect name my-ios-fw icmp

Для не столь популярных протоколов ситуация сильно не меняется – надо добавить всего одну команду:

ip port-map user-vnc port tcp 5900

ip inspect name my-ios-fw user-vnc

После этого можно применить данные правила к нужному интерфейсу маршрутизатора:

interface fastethernet 0/1

ip inspect my-ios-fw in

А для инспекции разрешенного трафика, внутри которого может скрываться трафик запрещенный (именно так часто инкапсулируется Instant Messaging или P2P), достаточно использовать команды:

appfw policy-name abuse-control

application http

port-misuse default action reset alarm

ip inspect name my-ios-fw appfw abuse-control

IP Source Tracker

Итак, есть достаточное количество механизмов обнаружения и отражения атак и другой подозрительной активности. Что теперь делать, когда пришел сигнал о попытке несанкционированного доступа? Сидеть, сложа руки, – не совсем правильно :). Надо быстро отследить источник атаки и собрать доказательства его вредоносной деятельности, чтобы разобраться самому или передать дело в руки правоохранительных органов. Особенно важно сделать это при подмене адреса, когда ты не знаешь, с какого интерфейса маршрутизатора пришел вредоносный трафик, и куда двигаться в дальнейшем расследовании. Для решения этой задачи можно использовать механизмы маршрутизаторов Cisco IOS: ACL, NetFlow, uRPF и т.д. Но наиболее эффективный способ — задействование специальной функции IP Source Tracker. Фрагмент конфигурации будет выглядеть следующим образом:

Router(config)# ip source-track 192.168.1.1

Эта команда позволяет отслеживать трафик, получаемый с адреса 192.168.1.1. Посмотреть статистику по данному адресу можно командой show ip source-track.

Финал

Выше было кратко описано 10 механизмов защиты маршрутизаторов Cisco... Это много или мало? Для статьи – безусловно, немало. Для понимания всей мощи защитных механизмов оборудования Cisco – капля в море. Всего в маршрутизаторах Cisco существует свыше сотни различных механизмов, которые позволяют обнаруживать, отражать и расследовать различные нарушения политики безопасности. Зачастую достаточно просто настроить существующий функционал, чтобы покрыть все потребности небольшого офиса в защите. А если добавить сюда возможность маршрутизаторов Cisco ISR выполнять функции беспроводной точки доступа, коммутатора начального уровня, телефонной станции и так далее, то становится ясно, что для эффективного и надежного подключения небольшой сети к Интернет достаточно всего одного устройства.

Взято из Спецвыпуск: Хакер, номер #068, стр. 068-062-1