Назад | Перейти на главную страницу

Является ли включение https на маршрутизаторе Cisco значительным риском безопасности?

Я хотел бы использовать Cisco Network Assistant для управления своими маршрутизаторами Cisco (я знаю, что для этого есть другие решения, но пока я решил использовать CNA). Для этого требуется, чтобы служба HTTP или HTTPS работала на управляемых маршрутизаторах. Там, где я работаю, мне уже сказали, что мне, вероятно, не разрешат реализовать это, потому что включение HTTP / HTTPS на маршрутизаторах представляет собой угрозу безопасности.

Но действительно ли это дыра в безопасности, если я включаю HTTPS и меняю номер порта по умолчанию? Я хочу иметь возможность с уверенностью сказать, что это совершенно безопасно. Конечно, ничто не является «полностью» безопасным, и сканер портов может найти любые открытые порты, но служба HTTP, работающая в IOS, не так уж ли взломана?

Наконец, должен ли я задать этот вопрос на форуме безопасности?

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

Здесь у Cisco есть отличное руководство по правильной реализации службы HTTP / HTTPS. (Выборочное включение приложений, использующих HTTP или HTTPS)

Одна потенциальная проблема с HTTPS заключается в том, что ленивые люди (например, я) могут не настроить сертификат Kerberos на устройстве, чтобы гарантировать безопасность подключений к нему. Ваш сертификат должен быть получен из одного из трех источников: коммерческого центра сертификации, такого как Verisign (дорого), настроить собственный центр сертификации с использованием сервера Windows или Linux (не так сложно, но требует много времени), третий вариант - использовать самостоятельный сертификат. подписанный сертификат, как описано здесь:

https://security.stackexchange.com/questions/38589/can-https-server-configured-without-a-server-certificate

Если у вашего устройства нет сертификата, соединения все равно должны быть зашифрованы, что усложняет задачу для обычного пользователя wirehark, но никоим образом не означает «безопасность» в каком-либо значимом смысле. У вас не будет гарантии, что соединения не будут затронуты атакой «человек посередине». кроме того, у вас (или у пользователей в зависимости от ресурса) может возникнуть ложное чувство безопасности, аналогичное наличию антивируса, но не обновлению его.

Я бы сказал, что, хотя изменение порта прослушивания является хорошей базовой мерой предосторожности, как только ваше устройство будет обнаружено при сканировании портов, любой желающий может начать пробовать основные службы, например. HTTP, HTTPS, SSH или SMTP с использованием соответствующего клиента для этой службы и посмотрите, получат ли они какие-либо действительные ответы. Это может быть написано, например, с cURL для HTTP / S, mutt для smtp, ssh ... для SSH. Лучшая защита, если ваши порты прослушивания должны выходить в Интернет, - это держать ОС и службы исправленными и ограничивать доступ только теми IP-адресами или диапазонами, которым вы доверяете, используя ACL (списки контроля доступа).

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

Конечно, вы всегда должны использовать HTTPS поверх HTTP.

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

Каждый открытый порт на вашем устройстве или сервере, безусловно, увеличивает поверхность атаки. Тем не менее, включение HTTPS будет более безопасным, чем включение незашифрованного протокола, такого как Telnet или HTTP.

Вы упомянули об изменении номера порта. Будьте осторожны, вы можете помешать Cisco Network Assistant найти устройство и управлять им. (Позволяет ли CNA указать собственный номер порта?)

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

  1. Используйте для управления только зашифрованные протоколы (HTTPS и SSH).
  2. Порты управления не должны быть открыты для общедоступного Интернета или гостевой сети (например, Wi-Fi для посетителей).
  3. Тайм-аут холостого сеанса для интерфейсов управления. Обратите внимание, что они могут быть настроены отдельно для HTTP, SSH и последовательной консоли, поэтому убедитесь, что у вас есть все ваши базы.
  4. Установите ограничение скорости и временный блокировка учетной записи для смягчения атак методом грубой силы.
  5. Используйте длинные, сложные, уникальные пароли
  6. Учетная запись администратора на коммутаторе не должна быть чем-то «хорошо известным», например admin, administrator, root. (Что-то, что может попытаться использовать автоматический сценарий для взлома.)
  7. Убедитесь, что пароли / таймауты / блокировки также применяются к последовательной консоли. (Я видел много устройств, на которых для последовательной консоли не был введен пароль или время ожидания не истекло. Вы могли подключить последовательный кабель и присоединиться к активному сеансу, который был открыт несколько месяцев назад.)
  8. Следите за тем, чтобы протокол SNMP оставался лазейкой в ​​системе.
  9. Рассмотрим AAA и RADIUS для централизованного управления паролями и разрешениями.
  10. Убедитесь, что ведение журнала настроено для отслеживания того, кто и когда вошел в систему.
  11. Используйте NTP, чтобы правильно указать время и дату в журналах (также важно для действительности сертификата).
  12. Храните журналы где-нибудь, где они не будут очищены, если устройство выйдет из строя / перезагрузится. Войдите в файловую систему или, в идеале, на независимый сервер системного журнала.
  13. Регулярно создавайте резервные копии ваших конфигураций.
  14. Пароли, хранящиеся на устройстве, должны быть зашифрованы с использованием самого надежного доступного шифрования. (Кто-то не сможет получить пароль, если наткнется на ваши резервные копии конфигурации.)
  15. Будьте в курсе бюллетеней по безопасности, которые влияют на ваши устройства, регулярно обновляйте IOS.
  16. Внедрите надлежащие сертификаты HTTPS с помощью собственного внутреннего центра сертификации.
  17. Ограничьте диапазон IP-адресов, который может получить доступ к портам управления (например, только ПК с установленным CNA)
  18. Ограничьте интерфейсы управления определенной VLAN или сетевым портом, недоступным для обычных пользователей.
  19. Если устройством будут управлять несколько человек, рассмотрите возможность использования нескольких учетных записей управления с разными уровнями доступа.