Доступ к коммутатору ProCurve
Материал из Xgu.ru
- Автор: Наташа Самойленко
На этой странице описываются настройки различных функций, которые позволяют обеспечить безопасный доступ для управления коммутатором.
Содержание |
[править] Базовые настройки доступа к коммутатору
- Основная страница: 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
Проверка 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
[править] Настройка аутентификации клиента с помощью открытого ключа
Для настройки аутентификации клиента с помощью открытого ключа необходимо:
- Сгенерировать пару открытый/закрытый ключ на SSH-клиенте;
- Скопировать открытый ключ клиента в текстовый файл;
- Выложить файл на TFTP-сервер;
- Скачать файл с TFTP-сервера на коммутатор;
- Настроить аутентификации по открытому ключу.
Копирование файла с TFTP-сервера на коммутатор:
switch# copy tftp pub-key-file <ip-address> <filename> [manager | operator [append]]
Параметры команды:
- <ip-address> — адрес TFTP-сервера
- <filename> — имя файла на TFTP-сервере, в котором хранится один или более открытых ключей клиентов;
- [manager | operator] — уровень доступа с которым ассоциирован открытый ключ клиента. По умолчанию — operator;
- [append] — позволяет добавлять открытый ключ клиента к уже существующим ключам, если опция не указана, то файл с ключами перезаписывается.
Уровень привилегий 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]
При сбросе настроек коммутатора открытые ключи коммутатора и клиентов сохраняются, так как они хранятся во flash-памяти. |
Настройка аутентификации по открытому ключу:
switch(config)# aaa authentication ssh login public-key none
[править] Настройка SSL
Принципы работы протокола и другие примеры его использования описаны на странице SSL.
Порядок настройки доступа к коммутатору с использованием протокола SSL:
- Создать пару ключей открытый/закрытый
- Установить сертификат:
- Самоподписанный сертификат
- Необходимо только сгенерировать его и он автоматически установится
- Сертификат подписанный центром сертификатов:
- Создать запрос на получение сертификата
- Отправить запрос центру сертификатов для подписи
- Установить цифровой сертификат подписанный центром сертификатов
- Самоподписанный сертификат
- Включить 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.
После создания безопасного управляющего VLAN, к нему применяется скрытый ACL, который запрещает прохождение трафика из других VLAN. |
Подготовка к назначению VLAN безопасным управляющим:
- Создать новый VLAN (например, VID=2);
- Проверить, что порты коммутатора не назначены в этот VLAN 2;
- Назначить IP-адрес в VLAN 2 из сети выделенной для управления устройствами;
- Назначить 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 и доступ к коммутатору будет заблокирован.
[править] Централизованная аутентификация, авторизация и учет при доступе к коммутатору
Подготовка к использованию централизованной аутентификации при доступе к коммутатору:
- Определить для каких методов доступа к коммутатору будет использоваться RADIUS-сервер: консоль, telnet, SSH, web;
- IP-адрес RADIUS-сервера;
- Shared secret — для шифрования сообщений между коммутатором и RADIUS-сервером;
- (опционально) Номера UDP портов, которые будут использоваться для аутентификации и учета (по умолчанию используются порты 1812 — для аутентификации, 1813 — для учета);
- (опционально) Параметры RADIUS-сервера. Например, количество попыток аутентификации;
- Имя пользователей и пароли для доступа к коммутатору;
- Уровень привелегий для каждого пользователя — 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
По умолчанию вторичный метод аутентификации для всех методов доступа, кроме консоли — 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
Если в поле 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
ProCurve | ||
---|---|---|
Основы | ProCurve Adaptive Edge | ProCurve ProActive Defense | ProCurve Network Access Control | ProCurve Wireless | |
Программы | ProCurve Manager | ProCurve Identity Driven Manager | ProCurve Network Immunity Manager | ProCurve Mobility Manager | |
Устройства | ProCurve Switch | ProCurve Router | ProCurve ONE Module | ProCurve TMS Module | ProCurve NAC 800 | ProCurve Access Point | ProCurve WESM | |
Настройка | ||
Безопасность | ProCurve Security | Доступ к коммутатору ProCurve | DHCP snooping | Dynamic ARP Protection | IP Source Guard | Port security | Аутентификация при доступе к сети | 802.1X в ProCurve | Web-аутентификация в ProCurve | MAC-аутентификация в ProCurve | |
Канальный уровень | CDP | LLDP | VLAN в ProCurve | GVRP | STP в ProCurve | ProCurve Mesh | Агрегирование каналов | Зеркалирование трафика | QinQ | |
Сетевой уровень | RIP в ProCurve | OSPF в ProCurve | VRRP в ProCurve | XRRP в ProCurve | QoS в ProCurve | Multicast в ProCurve | PIM в ProCurve | |
Разное | Опция 82 DHCP | SNMP в ProCurve |