Следуя аксиомам безопасности, будем считать, что любой узел в сети является потенциальной целью. Поэтому хорошо бы знать, какие потенциально уязвимые места есть у этих самых узлов. Рассмотрим маршрутизатор cisco. Сразу же возникнет возражения: их много, сервисы поддерживаемые – разные и вообще, трудно свалить в одну кучу CRS-1 и древний 1600. Однако, я не ставлю своей целью охватить всё, но кое какие общие вещи опишу.
Итак, первое что надо запомнить, что маршрутизатор по умолчанию не блокирует на интерфейсе никакой нормальный трафик (фреймы с неправильной контрольной суммой не счёт). Однако, часть пакетов, при более глубоком рассмотрении (процессором) маршрутизатор таки признает ненужными, например:
1. Пакеты с TTL =0 или меньше
2. Пакеты, которые неизвестно куда отправить (сеть назначения пакета не присутствует в таблице маршрутизации и нет никакого явного правила отправки пакета (PBR))
3. Пакеты, относящиеся к служебным протоколам (например, протоколам маршрутизации), которые не запущены на маршрутизаторе.
Эти уничтоженные пакеты могут сыграть злую шутку: если такого трафика будет много, то он может существенно загрузить процессор маршрутизатора.
Далее, кроме транзитного трафика, маршрутизатор обрабатывает некоторый служебный трафик (направленный на него самого). Часто по умолчанию (или незнанию) на маршрутизаторе запущены ненужные для работы протоколы. Они опасны тем, что маршрутизатор обрабатывает пакеты этого протокола. И можно устроить, например, DoS атаку, узнать удалённо сведенья, не предназначенные для распространения или исследовать топологию сети. К таким протоколам относятся
1. TFTP (маршрутизатор может выступать сервером TFTP).
2. BOOTP (может раздавать бездисковым станциям их файлы настройки)
3. DHCP (Маршрутизатор может выступать сервером и клиентом)
4. TCP Small Servers (TCP Echo, Finger и др.)
5. UDP Small Servers (UDP Echo, Discard и др.)
6. CDP (Cisco Discovery Protocol)
7. NTP (Network Time Protocol. Маршрутизатор может выступать сервером и клиентом)
8. DNS (Включен по умолчанию броадкастовый поиск ДНС серверов в сегменте)
9. PAD (Packet Accembler/Disaccembler)
10. SNMP (Часто сконфигурированы дефолтные community)
Как правило, если данные протоколы не нужны, их лучше отключить.
1. no tftp-server
2. no ip bootp server (старая команда no service bootp)
3. no ip dhcp pool (no service dhcp)
4. no service tcp-small-servers
5. no service udp-small-servers
6. no cdp run (глобально), no cdp enable (на конкретном интерфейсе). Не стоит выключать этот протокол, если к интерфейсу подключен cisco ip phone, т.к. именно по этому протоколу происходит автоопределение подключенного устройства (данная рекомендация больше характерна для коммутаторов, но всё же)
7. no ntp master, no ntp server
8. no ip domain-lookup. Помните, что часто DNS на маршрутизаторе нужен, так что отключать надо не всегда
9. no service pad
10. no snmp-server community {public|private}
Однако, даже если выключить эти и другие служебные протоколы (например, http, https, ssh), пакеты этих протоколов, приходящие на интерфейс маршрутизатора, попадут в мозг и только там будут откинуты. Т.е. даже выключив все, можно попробовать нагрузить процессор маршрутизатора отбрасыванием мусора.
Хотелось бы научиться отбрасывать такие пакеты, не нагружая мозг. Также, часто возникает задача ограничить нагрузку служебным трафиком на процессор. Например, указав максимальное количество служебных пакетов (всего или по отдельным протоколам) в очереди или количество служебных пакетов в секунду.
Эти задачи решаются при помощи специального режима
сontrol-plane host
Чтобы воспользоваться этой технологией можно создать специальные классы трафика
class-map type?
access-control access-control specific class-map
control Configure a control policy class-map
inspect Configure CBAC Class Map
logging Class map for control-plane packet logging
port-filter Class map for port filter
queue-threshold Class map for queue threshold
stack class-map for protocol header stack specification
Создать специальную политику (Policy-map type )
policy-map type?
access-control access-control specific policy-map
control Configure a control policy policy-map
inspect Configure CBAC Policy Map
logging Control-plane packet logging
port-filter Control-plane tcp/udp port filtering
queue-threshold Control-plane protocol queue limiting
И применить её в этом режиме:
control-plane host
service-policy type?
logging Control-plane packet logging
port-filter Control-plane tcp/udp port filtering
queue-threshold Control-plane protocol queue limiting
Ограничение же нагрузки на мозг служебными пакетами организуется похоже, только для этого достаточно описать обычный класс трафика, обычную политику, где в качестве действия указать ограничение словом police
police rate [units] pps
Разберем примеры:
1. Ограничим количество телнетовских пакетов от всех сетей, кроме хоста 10.1.1.100, до 100 пакетов в секунду
Для этого напишем список доступа
ip access-list extended TELNET
deny tcp host 10.1.1.100 any eq 23
permit tcp any any eq 23
Далее, создадим класс трафика
class-map TELNET
match access-group TELNET
Опишем политику
policy-map TELNET
class TELNET
police rate 100 pps
И повесим политику в control-plane
control-plane host
service-policy input TELNET
2. Заблокируем пакеты, направленные на порты приложений, не используемые маршрутизатором
Создадим специальный класс трафика
class-map type port-filter PORTS
match closed-ports
Опишем специальную политику
policy-map type port-filter PORTS
class PORTS
drop
И повесим политику в control-plane
control-plane host
service-policy type port-filter input PORTS
Чтобы защитить management-plane, т.е. управление маршрутизатором надо помнить следующие моменты:
1. По возможности надо использовать безопасные протоколы управления: ssh, https. Для этого надо выработать ключевую пару RSA, указать правила аутентификации и включить поддержку https (ip http secure-server)
2. Даже при использовании безопасных протоколов управления, а особенно при невозможности их использования, надо ограничивать административный доступ снаружи и изнутри при помощи списков доступа, примененных на интерфейсах, терминальных линиях (line vty) или в режиме control-plane host
3. Желательно применять сложные пароли, минимальной длиной 8 символов и содержащие цифры, буквы разного регистра и символы. А чтобы какой-нибудь юный администратор маршрутизатора не нарушил это правило создания паролей, есть команда
security passwords min-length [длина]
4. Пароли в конфиге лучше иметь захешированными. Тогда не будет возможности подглядеть пароль. Для этого применяйте не слово “password”, но слово “secret”
Примеры:
username admin secret {пароль}
enable secret {пароль}
5. Не забывайте о порте AUX. Это практически та же консоль и имеющий доступ к железу сможет подключиться, используя AUX, к командной строке. Если пароля на AUX не будет, то подключившийся сможет попасть как минимум в непривилегированный режим.
6. У многих маршрутизаторов есть функция защиты от подбора паролей. Можно блокировать пользователя после N неправильно введенных паролей, а можно после нескольких попыток вставлять задержку.
Пример:
security authentication failure rate [попытки] [log]
После N неправильных паролей (по умолчанию – 10) будет вставлена 15 секундная задержка. Слово log позволяет логгировать такие события.
7. Помните, что при использовании протокола SNMP желательно использовать 3 версию протокола с аутентификацией и шифрованием. При использовании более ранних, практически ничем не защищённых версий, строго следите за тем, что принятые по умолчанию community отключены.
8. В сетях с большим количеством устройств имеет смысл выделять так называемую сеть для управления (OOB, Out-of-Band management). Это отдельный сегмент сети, не имеющий пересечений с сетью передачи данных. До недавних пор маршрутизатор мог быть помещен в OOB только посредством консольного сервера, но в новых IOS вы можете административно задать интерфейс, с которого можно настраивать маршрутизатор и только с него. Делается это всё в том же режиме control-plane host явным указанием интерфейса и разрешенных протоколов
Пример:
control-plane host
management-interface f0/0 allow ssh snmp
Защита протоколов маршрутизации
Защита динамических протоколов маршрутизации тоже является весьма важной темой, т.к. если злоумышленнику удастся повредить таблицу маршрутизации, нужные пакеты просто будут уничтожены или пойдут «не туда». Поэтому очень рекомендую при работе с динамическими протоколами маршрутизации использовать аутентификацию обновлений, желательно MD5 суммой (хэшем). Такую технологию поддерживают почти все протоколы: BGP, OSPF, RIPv2, EIGRP. Часть протоколов поддерживает также и аутентификацию clear text (просто ключом), но т.к. ключ передается в самом пакете обновления, назвать такой механизм защищённым язык не поворачивается.
Для настройки аутентификации по MD5 как правило надо:
1. Описать одинаковый ключ на всех маршрутизаторах, работающих по одному протоколу (или на конкретном интерфейсе, в конкретной зоне)
2. Настроить метод защиты (без защиты, clear text, MD5)
3. Включить механизм
Пример: протокол OSPF
Ro(config-if)# ip ospf authentication message-digest
Ro(config-if)# ip ospf message-digest-key 1234 md5 cisco
Где 1234 – номер ключа, а от слова «cisco» будет вычислен md5 хэш.
Итак, первое что надо запомнить, что маршрутизатор по умолчанию не блокирует на интерфейсе никакой нормальный трафик (фреймы с неправильной контрольной суммой не счёт). Однако, часть пакетов, при более глубоком рассмотрении (процессором) маршрутизатор таки признает ненужными, например:
1. Пакеты с TTL =0 или меньше
2. Пакеты, которые неизвестно куда отправить (сеть назначения пакета не присутствует в таблице маршрутизации и нет никакого явного правила отправки пакета (PBR))
3. Пакеты, относящиеся к служебным протоколам (например, протоколам маршрутизации), которые не запущены на маршрутизаторе.
Эти уничтоженные пакеты могут сыграть злую шутку: если такого трафика будет много, то он может существенно загрузить процессор маршрутизатора.
Далее, кроме транзитного трафика, маршрутизатор обрабатывает некоторый служебный трафик (направленный на него самого). Часто по умолчанию (или незнанию) на маршрутизаторе запущены ненужные для работы протоколы. Они опасны тем, что маршрутизатор обрабатывает пакеты этого протокола. И можно устроить, например, DoS атаку, узнать удалённо сведенья, не предназначенные для распространения или исследовать топологию сети. К таким протоколам относятся
1. TFTP (маршрутизатор может выступать сервером TFTP).
2. BOOTP (может раздавать бездисковым станциям их файлы настройки)
3. DHCP (Маршрутизатор может выступать сервером и клиентом)
4. TCP Small Servers (TCP Echo, Finger и др.)
5. UDP Small Servers (UDP Echo, Discard и др.)
6. CDP (Cisco Discovery Protocol)
7. NTP (Network Time Protocol. Маршрутизатор может выступать сервером и клиентом)
8. DNS (Включен по умолчанию броадкастовый поиск ДНС серверов в сегменте)
9. PAD (Packet Accembler/Disaccembler)
10. SNMP (Часто сконфигурированы дефолтные community)
Как правило, если данные протоколы не нужны, их лучше отключить.
1. no tftp-server
2. no ip bootp server (старая команда no service bootp)
3. no ip dhcp pool (no service dhcp)
4. no service tcp-small-servers
5. no service udp-small-servers
6. no cdp run (глобально), no cdp enable (на конкретном интерфейсе). Не стоит выключать этот протокол, если к интерфейсу подключен cisco ip phone, т.к. именно по этому протоколу происходит автоопределение подключенного устройства (данная рекомендация больше характерна для коммутаторов, но всё же)
7. no ntp master, no ntp server
8. no ip domain-lookup. Помните, что часто DNS на маршрутизаторе нужен, так что отключать надо не всегда
9. no service pad
10. no snmp-server community {public|private}
Однако, даже если выключить эти и другие служебные протоколы (например, http, https, ssh), пакеты этих протоколов, приходящие на интерфейс маршрутизатора, попадут в мозг и только там будут откинуты. Т.е. даже выключив все, можно попробовать нагрузить процессор маршрутизатора отбрасыванием мусора.
Хотелось бы научиться отбрасывать такие пакеты, не нагружая мозг. Также, часто возникает задача ограничить нагрузку служебным трафиком на процессор. Например, указав максимальное количество служебных пакетов (всего или по отдельным протоколам) в очереди или количество служебных пакетов в секунду.
Эти задачи решаются при помощи специального режима
сontrol-plane host
Чтобы воспользоваться этой технологией можно создать специальные классы трафика
class-map type?
access-control access-control specific class-map
control Configure a control policy class-map
inspect Configure CBAC Class Map
logging Class map for control-plane packet logging
port-filter Class map for port filter
queue-threshold Class map for queue threshold
stack class-map for protocol header stack specification
Создать специальную политику (Policy-map type )
policy-map type?
access-control access-control specific policy-map
control Configure a control policy policy-map
inspect Configure CBAC Policy Map
logging Control-plane packet logging
port-filter Control-plane tcp/udp port filtering
queue-threshold Control-plane protocol queue limiting
И применить её в этом режиме:
control-plane host
service-policy type?
logging Control-plane packet logging
port-filter Control-plane tcp/udp port filtering
queue-threshold Control-plane protocol queue limiting
Ограничение же нагрузки на мозг служебными пакетами организуется похоже, только для этого достаточно описать обычный класс трафика, обычную политику, где в качестве действия указать ограничение словом police
police rate [units] pps
Разберем примеры:
1. Ограничим количество телнетовских пакетов от всех сетей, кроме хоста 10.1.1.100, до 100 пакетов в секунду
Для этого напишем список доступа
ip access-list extended TELNET
deny tcp host 10.1.1.100 any eq 23
permit tcp any any eq 23
Далее, создадим класс трафика
class-map TELNET
match access-group TELNET
Опишем политику
policy-map TELNET
class TELNET
police rate 100 pps
И повесим политику в control-plane
control-plane host
service-policy input TELNET
2. Заблокируем пакеты, направленные на порты приложений, не используемые маршрутизатором
Создадим специальный класс трафика
class-map type port-filter PORTS
match closed-ports
Опишем специальную политику
policy-map type port-filter PORTS
class PORTS
drop
И повесим политику в control-plane
control-plane host
service-policy type port-filter input PORTS
Чтобы защитить management-plane, т.е. управление маршрутизатором надо помнить следующие моменты:
1. По возможности надо использовать безопасные протоколы управления: ssh, https. Для этого надо выработать ключевую пару RSA, указать правила аутентификации и включить поддержку https (ip http secure-server)
2. Даже при использовании безопасных протоколов управления, а особенно при невозможности их использования, надо ограничивать административный доступ снаружи и изнутри при помощи списков доступа, примененных на интерфейсах, терминальных линиях (line vty) или в режиме control-plane host
3. Желательно применять сложные пароли, минимальной длиной 8 символов и содержащие цифры, буквы разного регистра и символы. А чтобы какой-нибудь юный администратор маршрутизатора не нарушил это правило создания паролей, есть команда
security passwords min-length [длина]
4. Пароли в конфиге лучше иметь захешированными. Тогда не будет возможности подглядеть пароль. Для этого применяйте не слово “password”, но слово “secret”
Примеры:
username admin secret {пароль}
enable secret {пароль}
5. Не забывайте о порте AUX. Это практически та же консоль и имеющий доступ к железу сможет подключиться, используя AUX, к командной строке. Если пароля на AUX не будет, то подключившийся сможет попасть как минимум в непривилегированный режим.
6. У многих маршрутизаторов есть функция защиты от подбора паролей. Можно блокировать пользователя после N неправильно введенных паролей, а можно после нескольких попыток вставлять задержку.
Пример:
security authentication failure rate [попытки] [log]
После N неправильных паролей (по умолчанию – 10) будет вставлена 15 секундная задержка. Слово log позволяет логгировать такие события.
7. Помните, что при использовании протокола SNMP желательно использовать 3 версию протокола с аутентификацией и шифрованием. При использовании более ранних, практически ничем не защищённых версий, строго следите за тем, что принятые по умолчанию community отключены.
8. В сетях с большим количеством устройств имеет смысл выделять так называемую сеть для управления (OOB, Out-of-Band management). Это отдельный сегмент сети, не имеющий пересечений с сетью передачи данных. До недавних пор маршрутизатор мог быть помещен в OOB только посредством консольного сервера, но в новых IOS вы можете административно задать интерфейс, с которого можно настраивать маршрутизатор и только с него. Делается это всё в том же режиме control-plane host явным указанием интерфейса и разрешенных протоколов
Пример:
control-plane host
management-interface f0/0 allow ssh snmp
Защита протоколов маршрутизации
Защита динамических протоколов маршрутизации тоже является весьма важной темой, т.к. если злоумышленнику удастся повредить таблицу маршрутизации, нужные пакеты просто будут уничтожены или пойдут «не туда». Поэтому очень рекомендую при работе с динамическими протоколами маршрутизации использовать аутентификацию обновлений, желательно MD5 суммой (хэшем). Такую технологию поддерживают почти все протоколы: BGP, OSPF, RIPv2, EIGRP. Часть протоколов поддерживает также и аутентификацию clear text (просто ключом), но т.к. ключ передается в самом пакете обновления, назвать такой механизм защищённым язык не поворачивается.
Для настройки аутентификации по MD5 как правило надо:
1. Описать одинаковый ключ на всех маршрутизаторах, работающих по одному протоколу (или на конкретном интерфейсе, в конкретной зоне)
2. Настроить метод защиты (без защиты, clear text, MD5)
3. Включить механизм
Пример: протокол OSPF
Ro(config-if)# ip ospf authentication message-digest
Ro(config-if)# ip ospf message-digest-key 1234 md5 cisco
Где 1234 – номер ключа, а от слова «cisco» будет вычислен md5 хэш.
