Базовая безопасность CISCO

Базовая безопасность CISCO — на сетевом устройстве CISCO задан пароль. По факту многие этим и ограничиваются. Что ещё можно сделать чтобы улучшить защиту? В статье рассказаны довольно простые методы, однако не все с ними знакомы.

Ссылка на гайд CCNAS.

Немного теории

Network Foundation Protection (NFP) Framework — интересная концепция, комплексный подход к защите, разработанный CISCO. NFP логически делит устройство на плоскости (planes):

• Плоскость менеджмента (Management Plane) — трафик, который генерирует сетевой администратор, настраивая и мониторя устройство;
• Плоскость управления (Control Plane) — трафик, который предназначен самому устройству;
• Плоскость передачи данных (Data Plane) — пользовательский трафик, который идёт транзитом через устройство.

Теперь подробнее о каждой плоскости и о том, зачем её нужно защищать.

Management Plane

Конфигурация, операционная система, протоколы Telnet, SSH, TFTP, FTP, NTP, AAA, SNMP, Syslog, NetFlow. Зачем защищать? Очевидно, что если есть контроль над устройством с помощью одного из этих протоколов, то можно как минимум получать информацию с устройства о его настройках или событиях, как максимум полностью управлять устройством.

Control Plane

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

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

Data Plane

Основной вид трафика в устройстве. Обрабатывается программно или аппаратно с помощью CISCO Express Forwarding (CEF) при минимальных затратах ресурсов CPU. Здесь нужно защититься от нежелательного трафика в явном виде и также защититься от спуфинга.

Взаимозависимость

Существует взаимозависимость между плоскостями. К примеру, если если сбой в плоскости управления, то устройство не знает как форвардить трафик, соответственно сбой плоскости передачи данных. Другой пример это сбой в плоскости менеджмента, который даёт атакующему контроль над устройством, возможность перенастройки, в результате сбой оставшихся двух плоскостей.

---

Внеполосное управление

Существует 2 варианта трафика между хостом администратора и управляемым устройством:

• Внутриполосное управление. Информация передаётся по пользовательской корпоративной сети вместе с пользовательским трафиком;
• Внеполосное управление (ООВ - Out Of Band). Информация передается по выделенной сети управления, в которой нет пользовательского трафика.

OOB конечно же предпочтительнее и если для внутриполосного управления незащищённые протоколы управления и мониторинга представляют опасность, то для OOB это компромиссное решение.

Изначально OOB рассматривалась как отдельная физическая сеть для целей управления. Может где-то так и реализовано, но это чрезвычайно сложно и дорого. Обычно используют выделенная Management-VLAN растянутая на всю сеть. Интерфейсы управления всех сетевых устройств только в этой VLAN. Хорошая практика, но в случае большой сети также сложно реализуемо.

Подводим итог: лучше всего выделять под управление отдельную подсеть, затем администраторы подсоединяются к этой подсети на рабочем месте или удалённо и уже из неё работают. Доступ к этой подсети ограничивается на FWs. Тогда всех проблем из раздела "Улучшения процесса входа в систему" можно легко избежать.

---

Защита Management Plane

Рассказывать про защиту всех 3 плоскостей не буду, это весьма объёмно и не было такой цели. Цель — простые методы повышения защиты плоскости менеджмента.

Настройка журналирования

Для просмотра событий на устройстве как минимум должен быть включен и настроен сбор логов в буфер устройства:

R1# show logging
...
Console logging: level debugging, 17 messages logged, xml disabled,                  filtering disabled 
Monitor logging: level debugging, 0 messages logged, xml disabled,                  filtering disabled 
Buffer logging:  disabled, xml disabled,                 filtering disabled

Далее, сохраним конфу и посмотрим какое сообщение будет:

R1# wr
Building configuration...
[OK]
R1#
*Jan 8 14:39:02.136: %GRUB-5-CONFIG_WRITING: GRUB configuration is being updated on disk. Please wait...
*Jan 8 14:39:02.950: %GRUB-5-CONFIG_WRITTEN: GRUB configuration was written to disk successfully.

Как видно в примере выше, выборочные действия по конфигурированию устройства имеют уровень 5, поэтому нужно журналировать его (или уровень 6):

R1(config)# logging buffered ?
...
informational Informational messages (severity=6)
notifications Normal but significant conditions (severity=5)

R1(config)# logging buffered informational 
*Jan 8 14:50:02.130: %SYS-5-LOG_CONFIG_CHANGE: Buffer logging: level informational, xml disabled, filtering disabled, size (8192)logging buffered informational

К сожалению логирование фиксирует малую часть команд настройки, а чтобы фиксировались все нужно сконфигурировать аккаунтинг на устройстве и нужен AAA-сервер. По крайней мере, при логировании будут видны важные события: поднялся и упал интерфейс и так далее.

Тут ещё нужно учитывать, что чем больше номер уровня журналирования, тем больше сообщений и тем быстрее заполнится буфер. Буфер записывается циклически, при переполнении старые записи перезаписываются новыми. Буфер организуется в памяти устройства, размер в байтах, значения 16 000 байт должно вполне хватить:

R1(config)# logging buffered
R1(config)# logging buffered 16000
R1(config)# logging buffered notifications

Best practice настраивать отправку сообщений на Syslog сервер и там их парсить (например с помощью Kibana):

R1(config)# logging 10.0.100.5
R1(config)# logging trap notifications

Проверяем:

R1# show run all | include logging
...
 logging buffered 16000 notifications
...
 logging console debugging
 logging monitor debugging
...
 logging on
...
 logging trap notifications
...
 logging facility local7
...

Суммируем: лог настраивается отдельно для консоли, буфера устройства, монитора удалённой сессии и Syslog сервера. Для сервера уровень лога определяет команда logging trap. А logging facility это типа такая метка, чтобы с помощью неё сервер распихивал логи по разным файлам и обработчикам.

Настройка времени

Чтобы у событий лога была правильная метка времени, метка должна быть включена:

R1(config)# service timestamps log datetime msec localtime show-timezone

И время должно быть настроено. Вручную никто не настраивает, особенно когда много устройств, используется сервис NTP. В качестве локального NTP-сервера может быть выбран любой домен-контроллер.

Или же, если сеть без домена, сервис NTP может быть без особого труда развёрнут на произвольном сервере. Статей в нете масса как это сделать. Настройки на устройстве:

R1(config)# ntp server 192.168.1.100
R1(config)# clock timezone MSK 3 0

NTPv3 и более поздней поддерживает механизм аутентификации между сервером и клиентами. Клиенты настроенные без аутентификации всё равно будут получать время с сервера. Отличие в том, что такие клиенты не аутентифицируют этот сервер как защищенный источник. В рамках статьи про базовую безопасность про NTPv3 говорить не будем.

Модели организации удалённого доступа

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

Вариант с вводом только пароля рассматривается как небезопасный. Метод локальной базы сам по себе повышает безопасность, так как для входа на устройство нужно знать связку логин/пароль. По этой причине логин admin лучше не использовать, хотя все привыкли так делать.

Есть ещё методы входа с использованием AAA, рассматривать также не будем. Важно то, что даже при наличии настроенного метода входа с серверным AAA, метод локальной базы должен быть обязательно настроен и используется как резервный в случае отказа/недоступности AAA-сервера.

Защита от физического доступа

Советы от Капитана Очевидность, но не так уж редко данными мерами пренебрегают:

• Серверные шкафы в производственных и межэтажных помещениях должны быть закрыты на ключ, а ключи не должны валяться в свободном доступе на видном месте. Тоже с доступом в серверную комнату;
• Должен быть выставлен пароль на enable:

R1(config)# enable secret Str#ngPA$w0rdd

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

R1(config)# no service password-recovery

Тут подробнее. Режим ROMmon становится недоступным. Если далее при загрузке инициировано прерывание (для Putty Ctrl-Breake), то будет предложено подтвердить действие, после чего конфигурация стирается, сервис восстановления пароля включается и устройство загружается с дефолтной конфигурацией. 

Важный момент: если Flash не содержит работоспособный IOS (повреждён/удалён), тогда что называется приплыли. Если действие прерывания при загрузке не подтверждено, то устройство загружает как обычно и сервис восстановления пароля остаётся выключенным. Зачем всё это нужно? Чтобы не дать доступ к текущей конфигурации.

Повышение безопасности пароля

• По умолчанию минимальная длина пароля – 6 символов. Best practice рекомендуют длину пароля 10 символов. Для увеличения минимальной длины пароля команда:

R1(config)# security passwords min-length 10

• По умолчанию (за исключением пароля enable secret и пароля username .. secret) все пароли хранятся в виде простого текста в файле конфигурации. Кто-то случайно может увидеть эти пароли и запомнить. Для сокрытия всех паролей внутри конфига есть команда:

R1(config)# service password-encryption

• Необходимо исключить из использования команды enable password, username password и line/vty password. Эти команды не используют по умолчанию шифрование и хранятся в конфигурации в виде открытого теста. В лучшем случае будет использовано обратимое подобие шифрования при вводе команды service password-encryption:

Данные команды оставлены в современных версиях IOS лишь для обратной совместимости.

Алгоритмы хеширования пароля

Хеш MD5 больше не считается безопасным для хеширования паролей управления. Если железка новая, IOS 15.3(3)M или новее, то доступны более совершенные алгоритмы хеширования:

Если нужно поставить на новое устройство пароль с другого устройства, то можно посмотреть готовый хеш в конфигурации и использовать его (вместе с соответствующей цифрой):

Алгоритм хеширования выбирается с помощью algorithm-type:

Хеш MD5 — type 5, SHA256 — type 8 и Scrypt — type 9. Если не указывать algorithm-type, будет по умолчанию использован MD5. Алгоритмы хеширования доступны как для команды enable, так и для команды username. Best Practices CISCO для типов паролей.

---

Защита линий подключений

• Самое простое и самое эффективное — это настроить на линиях ACL для доступа только с административного хоста:

R1(config)# ip access-list standard SSH_ADMIN
R1(config-std-nacl)# permit host 192.168.1.11
R1(config-std-nacl)# exit
R1(config)# line vty 0 4
R1(config-line)# access-class SSH_ADMIN in

Сессия с хоста отличного от 192.168.1.11 будет прервана на этапе открытия:

• По умолчанию время завершения сеанса при отсутствии активности 10 минут, рекомендуется его уменьшить:

Команда exec timeout 0 0 или no exec-timeout отключает завершение сеанса при бездействии и иногда удобно ей пользоваться. Например, в лабах. Тут её надо вешать на консоль.

• На неиспользуемых линиях, например порта AUX, ввести команду no exec, она разрешает только исходящие подключения:

R1(config)# line aux 0
R1(config-line)# no exec

• Вот что ещё вычитал в гайде ENCOR:

The console port (cty line) should be provisioned with the transport input none command 
to block reverse Telnet into the console port.

• Ещё есть команда принудительного разрыва соединения, даже если соединение используется:

R1(config-line)# absolute-timeout ?
  <0-10000>  Absolute timeout interval in minutes

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

R1(config-line)# logout-warning ? 
  <0-4294967295>  Warning time in seconds

SSH

Протокол Telnet передаёт инфу (включая пароль) открытым текстом и поэтому от использования данного протокола нужно отказаться на всех сетевых устройствах.

Чтобы была возможность настроить SSH у устройства должна присутствовать поддержка криптографии, которая обеспечивается на уровне прошивки. Указание на возможность использования криптографии для старых прошивок (12.XX) является приставка k9 в названии прошивки:

c2600-advipservicesk9-mz.124-25b.bin

Для новых прошивок криптография есть по умолчанию. Посмотреть на устройстве можно используя команду show version.

Для настройки SSH:

1. Имя устройство должно быть изменено с дефолтного с помощью команды hostname;
2. Должно быть задано имя домена c помощью команды ip domain-name;
3. Нужно сгенерировать ключ для SSH, рекомендуется ключ RSA длиной не менее 1024 bit:

• Настроенная по умолчанию версия SSH это уязвимая 1.99, нужно в явном виде указать версию 2:

R1(config)# ip ssh version 2

• На используемых линиях указать явно, что доступен только защищённый протокол SSH с помощью команды transport input ssh;
• Поскольку, как уже говорилось, команду password на линиях использовать не рекомендуется, применяем локальную базу. Для настройки локальной базы нужно ввести команду username и на линиях указать login local:

R1(config)# username admin1 privilege 15 algorithm-type scrypt secret Str*ngPA$3$
R1(config)# line vty 0 4
R1(config-line)# transport input ssh
R1(config-line)# login local

Команда ip ssh time-out задаёт период, в течении которого пользователь должен ввести реквизиты для входа, по умолчанию 120 секунд, возможность настройки от 1 до 120 секунд. После входа в систему работают уже настройки таймаута для VTY.

Команда ip ssh authentication-retries задаёт количество попыток до ввода правильных реквизитов, по умолчанию 3, возможность настройки от 0 до 5.

Просмотреть текущие подключения SSH команда show ssh, посмотреть общую информацию о SSH команда show ip ssh, посмотреть информацию о ключах команда show crypto key mypubkey rsa.

Кроме всего этого устройства CISCO позволяют устанавливать SSH-соединение с одного устройства на другое. При этом настройка SSH на устройстве, которое инициирует подключение, не требуется:

R1# ssh -l admin1 192.168.1.200

Также следует учитывать количество линий VTY, для маршрутизатора их обычно по умолчанию 5, а для коммутатора 16. Как правильно сказано в комментарии к статье можно включить для маршрутизатора оставшиеся линии, но.. в конфе по умолчанию для маршрутизатора vty 0 4, для коммутатора vty 0 4 и vty 5 15.

Не то чтобы часто, но встречаю примеры настройки, когда человек забыл или не знал, что на коммутаторе линий VTY больше и выполнил настройку SSH только для линий 0 4, а линии 5 15 имеют старую настройку для Telnet с каким-то простым паролем в явном виде. Тогда работает следующий трюк, быстро открываем 5 сессий SSH без ввода реквизитов, просто окна (они прицепятся к линиям 0-4), затем ещё 1 сессию Telnet (линия 5), вводим этот простой пароль и.. удачный логин!

Вряд ли кто-то, кто, допустим, увидел случайно конфигурацию этого коммутатора на мониторе будет так делать (и догадается так сделать), но само по себе такое возможно.

Скрин текста из последней официальной версии CCNA Security:

Улучшения процесса входа в систему

А что делать, если на устройствах настроены уровни привилегий, подключается довольно больше число пользователей для выполнения разных по сути задач? При этом число хостов, с которых происходит подключение тоже большое и настройка списка доступа ACL для линий VTY с указанием IP всех этих хостов скорее неудобство, чем достоинство.

С другой стороны отсутствие списка ACL позволяет подключаться с любого хоста и использовать сколько угодно попыток для входа. Как защититься от атаки? Кроме того, применение сложных и длинных паролей это хорошо, но само по себе также не может предотвратить атаку на взлом/подбор пароля.

Улучшенные возможности входа позволяют достаточно замедлить атаку. Тут есть некоторые ограничения:

• Неприменимо для консольных подключений. Подразумевается, что только авторизованный персонал имеет физический доступ к устройству;
• Работает если используется локальная база, если же доступ к линиям настроен только по паролю, то улучшения процесса входа включить нельзя;
• Чтобы включить улучшения входа в систему сначала нужно ввести команду login block-for:

R1(config)# login block-for секунды1 attempts попытки within секунды2 

— блокирует подключение к системе на промежуток времени секунды1, если в течение промежутка времени секунды2 количество неудачных попыток входа превышает попытки

Команда login block-for обеспечивает защиту как от DoS-атак, так и от попыток взлома пароля и работает 2 режимах:

• Есть неудачные попытки входа, но их количество не превышает порог за указанный промежуток времени, тогда устройство только считает число неудачных попыток входа;
• Порог превышен, тогда "режим тишины", все попытки входа с использованием SSH, Telnet, HTTP, HTTPS блокируются на указанный промежуток времени.

Чтобы обеспечить доступ администратора к устройству на период режима тишины, применяется список ACL с указанием IP адресов административных хостов с помощью команды login quiet-mode access-class.

Как же так? Мы отказались от использования ACL на линиях VTY, стали использовать дополнительные методы для защиты и опять ACL. Получается притянуто за уши и логически несвязно. На самом деле здесь используется небольшое число IP административных хостов, которые гарантированно должны иметь доступ.

Сразу после применения команды login block-for между попытками входа включается задержка в 1 секунду, что уже хорошо. Задержку можно увеличить с помощью команды login delay. Пример конфигурирования:

Чтобы проверить настройки команды login block-for используется команда show login:

Помимо этого команда показывает текущий режим работы (Normal-Mode или Quiet-Mode), время до конца текущего периода наблюдения и количество неудачных попыток входа в текущем периоде наблюдения для Normal-Мode, время до окончания режима тишины для Quiet-Mode.

Неудачные попытки входа

Для генерации Syslog-сообщения об удачных и неудачных попытках входа применяются команды login on-success log и login on-failure log. В конце каждой команды неявно присутствует параметр every login равный 1, который означает, что сообщение будет генерироваться при каждом удачном/неудачном входе. Параметр можно указать в явном виде, диапазон от 1 до 65535.

Данные команды являются частью улучшения входа в в систему и должны вводиться после команды login block-for.

Команда show login failures даёт дополнительную информацию о неудачных попытках входа.

Баннер при входе в систему

Рекомендуется к обязательному применению. Зачем? Если кто-то будет пойман на попытках взлома, то ему будет тяжелее отвертеться. Обычный, рядовой пользователь может случайно открыть сессию к устройству, нужно ему в явном виде указать, что не надо сюда пытаться зайти. Не рекомендуется использовать слова типа Welcome.

Баннер задаётся командой banner motd, начало и конец баннера могут быть отмечены любым символом, главное чтобы он не встречался в тексте баннера (в примере *):

Кроме общего баннера MOTD (Message Of The Day) существуют и другие:

---

Защита конфигурации

Конфигурацию устройств нужно бекапить, на случай поломки устройства. Имея под рукой текущую конфигурацию легко её применить на аналогичное работоспособное устройство.

• Оптимальный вариант при большом количестве устройств — развернуть NOC;
• Промежуточный вариант — использовать rConfig;
• При количестве устройств в пару десятков можно кидать конфиги на внешний TFTP с помощью команды глобальной конфигурации archive. Доступно с версии IOS 12.3. В качестве TFTP сервера удобно использовать tftpd32 service edition, конфигурация на устройстве следующая:

R1(config)# archive
R1(config-archive)# log config
R1(config-archive-log-cfg)# logging enable
R1(config-archive-log-cfg)# hidekeys
R1(config-archive-log-cfg)# path tftp://192.168.1.100/$H-$T.cfg
R1(config-archive)# write-memory

$H-$T.cfg шаблон для файла, где $H – имя устройства, и $T – текущее время. Для просмотра отправленных копий используется команда show archive. Для роутеров нужна дополнительная строчка:

R1(config-archive-log-cfg)# logging persistent reload

Резервные копии будут сохраняться на TFTP сразу после выполнения команды write memory. Те, кому такой вариант не нравится, могут воспользоваться расписанием:

R1(config)# kron policy-list Backup
R1(config-kron-policy)# cli copy running-config tftp://192.168.1.100
R1(config-kron-policy)# exit
R1(config)# kron occurrence Every_day_backup at 11:00 recurring
Clock currently not set it reads 22:29:03 UTC Mon Jan 7 2019
R1(config-kron-occurrence)# policy-list Backup

Как видно из примера также требуется установка точного времени, возвращаемся к вопросу о NTP. Посмотреть задания можно с помощью команды show kron schedule.

• Также помочь может настройка защищенного протокола копирования Secure Copy Protocol (SCP). Сетевое устройство выступает в роли SCP-сервера. Забирать прошивку можно с помощью скрипта, хороший вариант сделать скрипт на Posh и засунуть в Планировщик для обхода устройств по расписанию. SCP работает поверх SSH и требует введения нескольких команд AAA. Прежде чем вводить команду aaa new-model обязательно должен быть настроен локальный пользователь. Предполагается, что это уже сделано и SSH настроен:

При этом возможно копирование как сервера, так и на сервер конечно:

Нужно точно указывать реквизиты, сервис SCP должен быть указан с двоеточием (как scp:), иначе команда воспримет это как обращение к локальному файлу, а Flash может называться flash: или flash0: и так далее.

---

Защита IOS

• Операционная система может быть удалена/повреждена и её тоже нужно защищать. Для этого у CISCO существует функция устойчивой конфигурации. Доступна эта функция не для всех систем, а только где Flash формата PCMCIA, это роутеры. Она обеспечивает сохранение защищенной рабочей копии файла образа IOS и копии файла текущей конфигурации. Эти защищенные файлы не могут быть удалены пользователем и называются первичным загрузочным набором (bootset):

R1(config)# secure boot-image 
R1(config)# secure boot-config

Защищенные файлы не видны из CLI, как будто их и нет. Сохранение файлов только локально, хранение защищённых файлов на вешних источниках не предусмотрено. Используется команда show secure bootset, чтобы просмотреть информацию.

Если используется secure boot-config и при загрузке устройства обнаруживается несоответствие текущего конфига сохранённому, то подгружается сохранённый. Аналогично и для secure boot-image. Чтобы обновить защищённые файлы нужно выполнить команды повторно. Если функция включена, то отключить её можно только через сеанс консоли. Восстановление защищённого образа IOS происходит через режим ROMmon:

rommon 1 > dir flash0:
...имя_защищённого_образа_IOS
rommon 2 > boot flash0:имя_защищённого_образа_IOS

Восстановление защищённого образа конфига:

R1(config)# secure boot-config restore flash:rescue-cfg

---

SNMP

Рекомендуется защищённый SNMPv3, хотя по факту он не так уж и часто используется. Чтобы хоть как-то обезопасить SNMPv2, нужно использовать ACL:

R1(config)# access-list 25 permit 192.168.1.100 
R1(config)# access-list 25 remark SNMP Server
R1(config)# snmp-server community snmp-community RW 25

Это конечно не сделает сообщения между устройством и SNMP-сервером шифрованными, но лучше чем ничего.

---

Отключение лишних сервисов

Относится в первую очередь к граничным маршрутизаторам, то есть тем, которые смотрят в интернет. Сервисы нужно отключать чтобы снизить область возможных DoS-атак, да и ресурсы они тоже потребляют.

Сервисы

В устройствах CISCO множество сервисов, которые включены по умолчанию:

Большую часть этих сервисов рекомендуется отключать:

Глобальные настройки

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

• Service configuration;
• TCP and UDP small services;
• Finger;
• Packet assembler/disassembler (PAD);
• BOOTP;
• DNS resolution;
• HTTP server and Secure HTTP (HTTPS) server;
• CDP;
• LLDP.

R1(config)# no service config
R1(config)# no service udp-small-servers 
R1(config)# no service tcp-small-servers
R1(config)# no service finger
R1(config)# no ip finger
R1(config)# no service pad 
R1(config)# no ip bootp server
R1(config)# no ip domain lookup
R1(config)# no ip http server
R1(config)# no cdp run
R1(config)# no lldp run

На интерфейсах

Необходимо выключать неиспользуемые порты и интерфейсы. На интерфейсах необходимо выключать:

• Maintenance Operation Protocol (MOP);
• Proxy ARP;
• IP-directed broadcast;
• IP redirects/unreachables/mask-reply.

R1(config)# interface GigabitEthernet0/0
R1(config-if)# no mop enabled
R1(config-if)# no ip proxy-arp
R1(config-if)# no ip directed-broadcast
R1(config-if)# no ip redirects
R1(config-if)# no ip inreachables
R1(config-if)# no ip mask-reply

Данные манипуляции легко выполнить с помощью AutoSecure.

---

Функция AutoSecure

Функция есть в IOS начиная с 12.3, она выполняет скрипт для устранения уязвимостей. Обычно AutoSecure используется на новом устройстве, которое предполагается к воду в эксплуатацию. Не рекомендуется её использование на устройствах, которые уже введены в продакшен.

Ну или нужно предварительно сделать бекап конфигурации и скопипастить в блокнот результат работы команды (он выводится на экран перед применением в конфигурацию), чтобы в случае возникновения проблем откатить как было. А лучше всего сначала посмотреть/обкатать выполнение команды на эмуляторе (EVE-NG), как это делаю я. 🙂

Выполняется AutoSecure с помощью команды auto secure и может быть настроена с помощью опций.

Интерактивный или автоматический режим:

• full (опция по умолчанию, полная настройка, интерактивный режим);
• no-interact (автоматически без участия пользователя, полная настройка)

Выполнение только для плоскости менеджмента или для плоскости передачи данных:

• management;
• forwarding.

Для отдельных сервисов:

• ntp;
• login;
• ssh;
• firewall;
• tcp intercept.

Важно обратить внимание, что что команда выполняется из привилегированного режима. Пример результата работы команды auto secure management перед применением в конфигурацию для роутера без подключения к интернету:

This is the configuration generated:

no service finger
no service pad
no service udp-small-servers
no service tcp-small-servers
service password-encryption
service tcp-keepalives-in
service tcp-keepalives-out
no cdp run
no ip bootp server
no ip http server
no ip finger
no ip source-route
no ip gratuitous-arps
no ip identd
banner motd ^CWarning!Secure system!^C
security passwords min-length 6
security authentication failure rate 10 log
enable secret 5 $1$N3Nn$dbNPJyDwTPk3RKc9SnsBk.
enable password 7 00071A1507545A545C
username admin password 7 1511021F07257A767B
aaa new-model
aaa authentication login local_auth local
line console 0
login authentication local_auth
exec-timeout 5 0
transport output telnet
line aux 0
login authentication local_auth
exec-timeout 10 0
transport output telnet
line vty 0 4
login authentication local_auth
transport input telnet
line tty 1
login authentication local_auth
exec-timeout 15 0
login block-for 120 attempts 5 within 60
ip domain-name cisco.local
crypto key generate rsa general-keys modulus 1024
ip ssh time-out 60
ip ssh authentication-retries 2
line vty 0 4
transport input ssh telnet
service timestamps debug datetime msec localtime show-timezone
service timestamps log datetime msec localtime show-timezone
logging facility local2
logging trap debugging
service sequence-numbers
logging console critical
logging buffered
interface GigabitEthernet0/0
no ip redirects
no ip proxy-arp
no ip unreachables
no ip directed-broadcast
no ip mask-reply
no mop enabled
...
— для остальных интерфейсов аналогично
!
end

Очевидно, что результат работы не идеален, как минимум нужно оставить для линий VTY только SSH, убрать все команды содержащие password, но в целом можно пользоваться как начальным шаблоном для ускорения процесса настройки.

Auto secure firewall

Раз уж заговорили про команду auto secure, то нельзя не сказать про результат работы команды auto secure firewall. Хотя файрвол относится к защите Data Plane, но нужно отметить: очень быстро настраивается CBAC-файрволл. Это удобно для тех роутеров, где старая прошивка и нет ZBF-файрволла.

Пример 1

Результат выполнения auto secure firewall, интерфейс GigabitEthernet 0/1 смотрит в интернет:

This is the configuration generated:

ip inspect audit-trail
ip inspect dns-timeout 7
ip inspect tcp idle-time 14400
ip inspect udp idle-time 1800
ip inspect name autosec_inspect ftp timeout 3600
ip inspect name autosec_inspect http timeout 3600
ip inspect name autosec_inspect rcmd timeout 3600
ip inspect name autosec_inspect realaudio timeout 3600
ip inspect name autosec_inspect smtp timeout 3600
ip inspect name autosec_inspect tftp timeout 30
ip inspect name autosec_inspect udp timeout 15
ip inspect name autosec_inspect tcp timeout 3600
ip access-list extended autosec_firewall_acl
permit udp any any eq bootpc
deny ip any any
interface GigabitEthernet0/1
ip inspect autosec_inspect out
ip access-group autosec_firewall_acl in
!
end

Нужно обратить внимание, что весь трафик, который будет инициирован из вне, запрещён на внешнем интерфейсе фильтром ip access-list extended autosec_firewall_acl. Единственный разрешенный трафик bootpc (насколько понимаю, чтобы была возможность авто-получения IP от провайдера для данного интерфейса).

Это никуда не годится. Для нормальной работы фильтр нужно сильно дополнять разрешающими правилами. Что конкретно разрешать зависит от применения роутера. А дырки для обратного трафика файрвол будет пропиливать в этом фильтре динамически.

Пример 2

Разрешить работу IPSec VPN между роутерами R1 (172.16.1.1/30) и R2 (172.16.1.2/30). Чтобы прошла фаза обмена информацией IKE разрешаем порт UDP 500 (правило 1), чтобы проходили шифрованные пакеты ESP разрешаем порт IP 50 (правило 2). Также удобно чтобы роутеры друг друга пинговали (правило 3). Для R1 (для R2 симметрично):

ip access-list extended autosec_firewall_acl
1 permit udp host 172.16.1.2 host 172.16.1.1 eq isakmp
2 permit esp host 172.16.1.2 host 172.16.1.1
3 permit icmp host 172.16.1.2 host 172.16.1.1

Поскольку пакеты ESP не содержат UDP или TCP заголовка, а только зашифрованную нагрузку, то ESP не сможет работать в каких-то конкретных реализациях через каких-то провайдеров. В частности, ESP не умеет работать напрямую через NAT. В этих случаях пакеты ESP надо заворачивать в UDP, который уже гарантированно будет доставлен. Делается это с помощью NAT-Traversal (NAT-T, обход NAT). Фильтр при этом видоизменяется в следующий:

ip access-list extended autosec_firewall_acl
1 permit udp host 172.16.1.2 host 172.16.1.1 eq isakmp
2 permit udp host 172.16.1.2 host 172.16.1.1 eq 4500
3 permit icmp host 172.16.1.2 host 172.16.1.1

---

Infrastructure ACL

Ну и раз заговорили, что граничный роутер, смотрящий в интернет, снаружи нужно защищать ACL, то CISCO называет такой ACL — Infrastructure ACL. В этом ACL в явном виде должны быть пропилены дырки для некоторых сервисов. Варианта тут 2:

1. Infrastructure ACL используется без файрволла, тогда необходимо завершающее правило permit ip any any или весь неразрешённый явно трафик будет заблокирован. Такой ACL состоит в основном из правил deny;
2. Infrastructure ACL используется совместно с файрволлом, тогда завершающее правило permit ip any any не нужно. Такой ACL состоит в основном из правил permit.

Пример Infrastructure ACL от CISCO (вариант 1, из официального гайда к экзамену 300-101 Route):

ip access-list extended INFRASTRUCTURE
!
! BLOCK PACKET FRAGMENTS
deny tcp any any fragments
deny udp any any fragments
deny icmp any any fragments
deny ip any any fragments
!
! ALLOW NECESSARY ROUTING PROTOCOL
! AND NETWORK MANAGMENT TRAFFIC
permit tcp host < external-bgp-peer> host < internal-bgp-peer> eq bgp
permit tcp host < external-bgp-peer> eq bgp host < internal-bgp-peer>
permit tcp < address-of-management-stations> any eq 22
permit tcp < address-of-management-stations> any eq 161
permit icmp < address-of-management-stations> any echo
!
! BLOCK ALL OTHER TRAFFIC DESTINED FOR INTERNAL NETWORK
deny ip any < address-space-of-internal-network>
!
! PERMIT OFF-NET TO OFF-NET TRAFFIC
permit ip any any

! APPLY ACL IN THE INBOUND DIRECTION TO AN INTERFACE
! CONNECTING TO AN EXTERNALNETWORK
interface Serial1/0
ip access-group INFRASTRUCTURE in

Это такая рыба, которую дорабатывать и дорабатывать. Фрагментированные пакеты запрещены, так как это уязвимость. Трафик к внутренним сетевым адресам запрещён, так как работает NAT.

В реалиях всё может быть по-другому. Пример боевого ACL (совместно с CBAC). Насколько он плох или хорош.. люди пользуются:

ip access-list extended WAN_IN
deny tcp object-group brutforcer any established
deny ip object-group brutforcer any
permit esp any any
permit gre object-group cod-external-nets any
permit icmp object-group ping-self any
permit icmp object-group cod-external-nets any
permit icmp any any echo-reply
permit icmp any any port-unreachable
permit icmp any any ttl-exceeded
permit tcp object-group cod-external-nets any eq 22
permit tcp object-group cod-external-nets eq 1723 any established
permit tcp any lt 1024 any gt 1023 established
permit udp any eq domain any gt 1023
permit udp any eq ntp any
permit udp any eq isakmp any eq isakmp
permit udp any eq non500-isakmp any eq non500-isakmp
deny ip object-group drop-nets any
deny udp any any eq netbios-ns
deny udp any any eq netbios-dgm
permit tcp object-group external-srv any established
permit udp object-group external-srv any
remark -- Teamviewer --
permit tcp any eq 5938 any gt 1023 established
remark -- MOS --
permit udp any eq 3478 any
permit udp any eq 87 any
permit udp any eq 5000 any
remark -- Vipnet --
permit udp any eq 55777 any

Широко задействованы группы object-group.

---

Заключение

В задачи статьи не входило рассмотреть все доступные методы защиты, а только простые и легкореализуемые и то очень выборочно. Использование этих методов поможет повысить безопасность сетевых устройств CISCO.