Доступ к коммутатору ProCurve

Материал из Xgu.ru

Перейти к: навигация, поиск
stub.png
Данная страница находится в разработке.
Эта страница ещё не закончена. Информация, представленная здесь, может оказаться неполной или неверной.

Если вы считаете, что её стоило бы доработать как можно быстрее, пожалуйста, скажите об этом.

Автор: Наташа Самойленко

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

Содержание

[править] Базовые настройки доступа к коммутатору

Основная страница: ProCurve Switch

Для того чтобы можно было управлять коммутатором не только заходя на консоль, но и удаленно, необходимо настроить на нем IP-адрес.

По умолчанию, на коммутаторах ProCurve указано получение IP-адреса по DHCP, но он может быть назначен и административно.

На коммутаторах ProCurve, после назначения IP-адреса, к коммутатору есть доступ:

  • к CLI — Telnet,
  • к веб-интерфейсу — HTTP.

[править] Management Interface Wizard

Management Interface Wizard — инструмент, который позволяет настроить такие функции на коммутаторе:

  • настроить локальные пароли,
  • ограничить доступ SNMP,
  • включить/выключить Telnet
  • включить/выключить SSH
  • включить/выключить удаленное веб-управление
  • настроить доступ к веб-интерфейсу только с использованием SSL
  • включить/выключить USB autorun
  • настроить таймауты для сессий SSH/Telnet

Management Interface Wizard позволяет в интерактивном режиме настроить все перечисленные функции.

Доступен Management Interface Wizard из CLI и веб-интерфейса в новых версиях ОС коммутаторов (начиная с K.14.09).

setup mgmt-interfaces

[править] Авторизованные менеджеры (authorized IP managers)

Базовые настройки по защите доступа к коммутатору предполагают как минимум настройку паролей для уровня manager и operator.

Функция авторизованные менеджеры позволяет добавить еще один критерий — указание IP-адресов с которых разрешен доступ к коммутатору. До запроса пароля на доступ с правами operator или manager, будет учитываться с какого IP-адреса осуществляется доступ к коммутатору. Доступ будет разрешен только с IP-адресов указанных в команде ip authorized-managers.

Ограничения касаются:

  • доступа к коммутатору с помощью Telnet, SSH
  • доступа к коммутатору с помощью HTTP, HTTPS
  • взаимодействия с коммутатором по протоколу SNMP
  • передачи файлов (конфигурационных и ОС) по TFTP

Icon-caution.gif

Проверка IP-адреса осуществляется до проверки имени пользователя и пароля.

Создать запись в списке авторизованных менеджеров:

switch(config)# ip authorized-managers <ip address> [mask] 
[access <manager | operator> access-method <all | ssh | telnet | web | snmp | tftp>]

Правила работы команды ip authorized-managers:

  • По умолчанию применяется маска 255.255.255.255 (указывает на хост), разрешен доступ по всем протоколам и уровень доступа — manager.
  • Коммутатор использует значение IP-адреса и маску для того чтобы определить разрешен ли доступ к его управляющему интерфейсу с этого компьютера.
  • В списке авторизованных менеджеров можно создать 100 правил, независимо от того будут эти правила указывать на хост или на подсеть.
  • До настройки хотя бы одного правила ip authorized-managers доступ к коммутатору разрешен с любых IP-адресов (если не настроены дополнительные ограничения). После настройки первого правила доступ разрешен только с указанного адреса и запрещён со всех других адресов.
  • Правила применяются только для новых сессий. Текущие сессии к коммутатору сохраняются, даже если они инициированы с адресов, которым, после настройки ip authorized-managers, запрещено подключаться.
  • Если используется функция management VLAN, то доступ будет разрешен только из него.

Удаление правила из списка:

switch(config)# no ip authorized-managers <ip address>

Просмотр существующих правил:

switch# show ip authorized-managers

[править] Настройка SSH

Большинство коммутаторов ProCurve поддерживают SSHv1 и SSHv2, но некоторые модели, такие как 8200zl, 5400zl, 3500yl и 6200yl, поддерживают только SSHv2.

Генерация пары ключей для SSH (хранится во flash):

switch(config)# crypto key generate ssh

Включение SSH:

switch(config)# ip ssh

Просмотр открытого ключа коммутатора:

switch(config)# show crypto host-public-key

Удаление ключа (автоматически отключает SSH):

switch(config)# crypto key zeroize ssh

Просмотр настроек SSH и активных сессий (ssh и telnet сессии можно посмотреть выполнив команду show telnet):

switch(config)# show ip ssh

[править] Настройка аутентификации клиента

SSH требует аутентификации сервера, но аутентификация клиента не обязательно должна выполняться.

Варианты аутентификации клиента:

  • Клиент аутентифицируется с помощью пароля (локально, RADIUS, TACACS+);
  • Клиент аутентифицируется с помощью открытого ключа, который должен храниться на коммутаторе.

По умолчанию аутентификация осуществляется локально, при этом доступны два пользователя - manager (полный доступ) и operator (просмотр статистики и тому подобное). Имя пользователя по умолчанию (если не указывать) - пустое, в этом случае при входе имя не указывается, а пользователь определяется по паролю.

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

# сначала удаляем, если что-то было (стирание предварительно назначенных имён)
SW(config)# no password operator
SW(config)# no password manager

# имя admin - для оператора
# БЕЗ имени - для менеджера (здешний рут)
SW(config)# password operator user-name admin
# пользовательский пароль и подтверждение
SW(config)# password manager
# админский пароль и подтверждение

После чего: логин «admin» + польз. пароль – непривилегированный доступ (>), команда enable + пароль рута – привилегированный доступ (#)


[править] Настройка аутентификации клиента с помощью пароля

Настройка аутентификации клиента с помощью пароля на RADIUS-сервере (подробнее об опциях команды и настройках RADIUS-сервера в разделе Централизованная аутентификация для доступа к коммутатору):

switch(config)# aaa authentication ssh enable radius none

[править] Настройка аутентификации клиента с помощью открытого ключа

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

  1. Сгенерировать пару открытый/закрытый ключ на SSH-клиенте;
  2. Скопировать открытый ключ клиента в текстовый файл;
  3. Выложить файл на TFTP-сервер;
  4. Скачать файл с TFTP-сервера на коммутатор;
  5. Настроить аутентификации по открытому ключу.

Копирование файла с TFTP-сервера на коммутатор:

switch# copy tftp pub-key-file <ip-address> <filename> [manager | operator [append]]

Параметры команды:

  • <ip-address> — адрес TFTP-сервера
  • <filename> — имя файла на TFTP-сервере, в котором хранится один или более открытых ключей клиентов;
  • [manager | operator] — уровень доступа с которым ассоциирован открытый ключ клиента. По умолчанию — operator;
  • [append] — позволяет добавлять открытый ключ клиента к уже существующим ключам, если опция не указана, то файл с ключами перезаписывается.

Icon-caution.gif

Уровень привилегий manager или operator, который ставится в соответствие открытому ключу клиента, контролирует то, какой доступ получит клиент предоставивший это ключ.

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

Пример копирования файла:

switch# copy tftp pub-key-file 192.168.1.1 mykey.txt operator

На коммутаторе может храниться 10 открытых ключей клиентов.

Просмотр существующих открытых ключей клиентов:

switch(config)# show crypto client-pub-key [manager | operator] [entry-list] [babble | fingerprint]

Удаление существующих открытых ключей клиентов из flash-памяти коммутатора:

switch(config)# clear crypto client-pub-key [manager | operator] [entry-list]

Icon-caution.gif

При сбросе настроек коммутатора открытые ключи коммутатора и клиентов сохраняются, так как они хранятся во flash-памяти.

Настройка аутентификации по открытому ключу:

switch(config)# aaa authentication ssh login public-key none

[править] Настройка SSL

Принципы работы протокола и другие примеры его использования описаны на странице SSL.

Порядок настройки доступа к коммутатору с использованием протокола SSL:

  1. Создать пару ключей открытый/закрытый
  2. Установить сертификат:
    • Самоподписанный сертификат
      Необходимо только сгенерировать его и он автоматически установится
    • Сертификат подписанный центром сертификатов:
      1. Создать запрос на получение сертификата
      2. Отправить запрос центру сертификатов для подписи
      3. Установить цифровой сертификат подписанный центром сертификатов
  3. Включить SSL на коммутаторе

Создание пары ключей для SSL:

switch(config)# crypto key generate cert 1024

Удаление пары ключей SSL:

switch(config)# crypto key zeroize cert

[править] Генерация самоподписанного сертификата

Генерация самоподписанного сертификата:

switch(config)# crypto host-cert generate self-signed

При генерации самоподписанного сертификата необходимо ввести такие параметры:

  • Valid start date — дата, с которой сертификат будет использоваться
  • Valid end date — до какой даты сертификат будет использоваться, рекомендуется устанавливать срок действия сертификата год
  • Common name — IP-адрес или доменное имя коммутатора.
  • Organization — название компании, в которой работает коммутатор
  • Organizational unit — название отдела/департамента, в котором используется коммутатор
  • City or location — название города, в котором используется коммутатор
  • State name — название штата, провинции, области, в которой используется коммутатор
  • Country code — код страны, в которой используется коммутатор

Просмотр цифрового сертификата:

switch(config)# show crypto host-cert

Включение SSL на коммутаторе:

switch(config)# web-management ssl

Отключение HTTP:

switch(config)# no web-management plaintext

Настройка web-аутентификации:

switch(config)# aaa authentication web enable radius none

[править] Безопасный управляющий VLAN (secure management VLAN)

Безопасный управляющий VLAN (secure management VLAN) — функция коммутатора, позволяющая выделить специальный VLAN для управления коммутаторами.

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

  • Коммутатор может получать управляющий трафик (HTTP, HTTPS, SSH, telnet, SNMP) только на IP-адрес в безопасном управляющем VLAN;
  • Доступ к коммутатору возможен только с компьютера находящегося в сети безопасного управляющего VLAN;
  • Компьютеры, находящиеся в безопасном управляющем VLAN могут передавать трафик в другие VLAN.

Icon-caution.gif

После создания безопасного управляющего VLAN, к нему применяется скрытый ACL, который запрещает прохождение трафика из других VLAN.

Подготовка к назначению VLAN безопасным управляющим:

  1. Создать новый VLAN (например, VID=2);
  2. Проверить, что порты коммутатора не назначены в этот VLAN 2;
  3. Назначить IP-адрес в VLAN 2 из сети выделенной для управления устройствами;
  4. Назначить uplink порты в VLAN 2 (если к коммутатору подключен компьютер, с которого будет происходить управление коммутаторами, то назначить порт к которому подключен компьютер в VLAN 2).

При подготовке к назначению VLAN безопасным управляющим будут отличия при работе с коммутаторами 2го и 3го уровней.

На коммутаторе 2 уровня необходимо:

  • Удалить IP-адреса из всех VLAN, кроме безопасного управляющего.

На коммутаторе 3 уровня необходимо:

  • Назначить IP-адреса пользовательским VLAN, так как это было бы и без безопасного управляющего VLAN.

Назначение VLAN 2 безопасным управляющим VLAN:

switch(config)# management-vlan 2

[править] Использование безопасного управляющего VLAN

  • Только статический, port-based VLAN может быть безопасным управляющим VLAN;
  • Безопасный управляющий VLAN не подерживает IGMP;
  • Если на коммутаторе созданы более чем 25 VLAN, то после настройки безопасного управляющего VLAN коммутатор надо перегрузить;
  • Если безопасный управляющий VLAN настроен на коммутаторе, порты которого находятся в mesh, то все порты в mesh будут принадлежать этому VLAN;
  • На коммутаторе может быть создан только один безопасный управляющий VLAN;
  • Если при настройке безопасного управляющего VLAN, порты через которые сейчас идет подключение к коммутатору, будут исключены, то это не повлияет на текущую сессию, но применится к любой новой;
  • При настройке Spanning Tree Protocol необходимо обратить внимание на то, что STP может заблокировать порты, которые были в безопасном управляющем VLAN и доступ к коммутатору будет заблокирован.

[править] Централизованная аутентификация, авторизация и учет при доступе к коммутатору

Подготовка к использованию централизованной аутентификации при доступе к коммутатору:

  1. Определить для каких методов доступа к коммутатору будет использоваться RADIUS-сервер: консоль, telnet, SSH, web;
  2. IP-адрес RADIUS-сервера;
  3. Shared secret — для шифрования сообщений между коммутатором и RADIUS-сервером;
  4. (опционально) Номера UDP портов, которые будут использоваться для аутентификации и учета (по умолчанию используются порты 1812 — для аутентификации, 1813 — для учета);
  5. (опционально) Параметры RADIUS-сервера. Например, количество попыток аутентификации;
  6. Имя пользователей и пароли для доступа к коммутатору;
  7. Уровень привелегий для каждого пользователя — manager или operator.

[править] Настройка RADIUS-сервера

На RADIUS-сервере необходимо:

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

[править] Настройка коммутатора

Настройка аутентификации:

switch(config)# aaa authentication <console | telnet | ssh | web> 
<login | enable> <radius | tacacs | local> [local | none]

Методы доступа:

  • console
  • telnet
  • ssh
  • web (аутентификация доступна не на всех моделях коммутаторов)

Уровень привилегий:

  • login — для operator
  • enable — для manager

Основной метод аутентификации:

  • radius
  • tacacs
  • local

Вторичный метод аутентификации (будет использоваться, если основной метод не доступен):

  • local
  • none

Icon-caution.gif

По умолчанию вторичный метод аутентификации для всех методов доступа, кроме консоли — none, а для консоли — local.

Указание RADIUS-сервера и shared secret:

switch(config)# radius-server host <ip-address> key <key-string>

Параметры команды:

  • ip-address — IP-адрес RADIUS-сервера, который коммутатор будет использовать для аутентификации. Может быть указано три RADIUS-сервера.
  • key-string — shared secret, ключ шифрования, который используется для шифрования пакетов между RADIUS-сервером и коммутатором. Должен быть указан на RADIUS-сервере.

Просмотр информации о настройках аутентификации:

switch(config)# show authentication

По умолчанию, коммутатор предоставляет администратору, который прошел аутентификацию доступ к коммутатору уровня operator. Если администратор должен работать с привилегиями manager, то ему необходимо будет повторно проходить процедуру аутентификации.

Коммутатор может получать информацию об уровне доступа от RADIUS-сервера. Тогда на RADIUS-сервере, в поле Service-Type, надо указывать какому пользователю, какой уровень доступа разрешен.

Значения поля Service-Type на RADIUS-сервере:

  • Administrative — Manager
  • NAS-Prompt — Operator

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

switch(config)# aaa authentication login privilege-mode

Icon-caution.gif

Если в поле Service-Type для администратора указано другое значение, то коммутатор запретит доступ этому администратору.

[править] Авторизация команд

Кроме аутентификации администраторов и разграничения уровня доступа на manager и operator, есть возможность задавать перечень команд, которые администратор может выполнять на коммутаторе.

Эти команды задаются как vendor-specific attribute для каждого авторизованного администратора на RADIUS-сервере.

ProCurve присвоен Vendor Code 11.

На RADIUS-сервере перечень команд и то разрешены они или нет указывается с помощью двух VSA:

  • Command String — перечень запрещенных или разрешенных комманд;
  • Command Exception — указывает разрешены или запрещены команды.

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

Для того чтобы использовать авторизацию, надо обязательно настроить аутентификацию.

Включение авторизации команд:

switch(config)# aaa authorization commands radius

[править] Учет (accounting)

Виды учётной информации, которая может отправляться на RADIUS-сервер:

  • Network — записывается информация о клиентах, которые подключаются к коммутатору по 802.1X;
  • Exec — информация о подключениях к коммутатору по SSH, telnet, console;
  • System — информация о перезагрузке, сбросе коммутатора, включение/выключение учёта на коммутаторе;
  • Command — информация о авторизованных командах, которые выполнил администратор, у которого в соответствие логину поставлен список авторизованных команд.

Включение учёта команд на коммутаторе:

switch(config)# aaa accounting commands stop-only radius

Просмотр информации о включенных методах учёта, статус учёта:

switch(config)# show accounting 

Суммарная статистика учёта:

switch(config)# show radius accounting 

Суммарная информация о текущих сессиях учёта:

switch(config)# show accounting sessions