Настройка RADIUS на B4COM 41хх в связке с Cisco ISE
Недавно на проекте нам пришлось настраивать RADIUS на B4COM, а чуть ранее в чате как-то писали, что мало инструкций от вендора, ну вот я решил немного помочь всем.
Предупреждаю, статья обзорная и предназначена больше для инженеров начального уровня. Поэтому, если вы эксперт по радиусу, то вам наверное будет скучно, хотя может тоже найдёте что-то интересное для себя.
Зачем нам Radius?
Собственно задача следующая, у нас есть коммутатор и мы не хотим чтобы на него ходили всякие разные непонятные люди, а хотим полноценно контролировать доступ и ограничивать права. Делать это с помощью локальных учетных записей неудобно, поэтому придумали такой хороший протокол как RADIUS, а ещё его собрата - TACACS+, про который возможно напишу в отдельной статье.
Идея простая, есть коммутатор, при подключении к нему, он запрашивает логин и пароль, которые затем отправляет для проверки на RADIUS сервер, а тот в свою очередь может иметь локальные записи, или быть подключен к домену и проверить их через LDAP, ну или какие-то ещё варианты. Проверяет присланную пару и отвечает в сторону коммутатора, можно ли дать доступ этому пользователю или нет.
картинка для наглядности
При передаче данных, внутри пакета RADIUS, вкладываются так называемые атрибуты, каждый из которых отвечает за тот или иной параметр. То есть, если коммутатор хочет рассказать о себе RADIUS серверу, к примеру передать свой IP, то он для этого может использовать атрибут №4 и вложить туда нужный IP адрес. Ну а сервер уже в свою очередь получит такой пакет, посмотрит внутрь и увидит содержимое.
Случайный пример radius request из гугла, внутри которого мы видим целый набор разных атрибутов
Большая часть атрибутов заранее описана и, можно сказать, является well-known. Найти их можно вот тут: IANA RADIUS Types.
Отдельно стоит рассказать про атрибут №26, который называется Vendor-Specific (VSA). Он используется для передачи данных, специфичных для конкретного вендора. Этот атрибут включает идентификатор вендора (Vendor-Id) и произвольные данные, определяемые производителем оборудования. Вот ссылка на RFC.
Например, у вас есть коммутатор Cisco, и вы хотите, чтобы при логине уровень привилегий также управлялся с Radius-сервера. Для этого нужно передать какое-то числовое значение на коммутатор. Пусть это будет максимальный уровень доступа — 15. Получается, что после аутентификации необходимо передать на коммутатор с Radius-сервера параметр 15. Этот параметр будет вложен в уникальный атрибут Cisco-AVPair, который, в свою очередь, будет вложен в тот самый атрибут №26. В качестве Vendor-ID будет подставлена “девятка”, что означает Cisco.
Примерно так это будет выглядеть: Type: 26 (Vendor-Specific) Length: 12 Vendor-Id: 9 (Cisco) Vendor-Data: [Cisco-AVPair: “shell:priv-lvl=15”]
Почему мы поставили “девятку”? Потому что это фиксированное уникальное значение для конкретного вендора. Полный список таких значений можно найти вот тут: IANA Enterprise Numbers.
На самом деле, с помощью RADIUS таким образом можно делать много всякого, и не только контролировать доступ на сами устройства, а ещё управлять доступом в саму сеть. Можно по специфическим параметрам назначать пользователям нужные права, IP адреса, разделять зоны безопасности и многое другое. Для этого уже используется дополнительный механизм, называемый 802.1x. Более детально расписывать тут не буду, в интернете на самом деле полно информации, к примеру вот хорошая статья на Wiki, и ещё лучше на xgu.ru.
Думаю достаточно вступления и справки, перейдём к самой задаче.
Наш кейс.
Как многие из вас знают, у B4COM есть 3 основных девайса, которые представлены на рынке коммутаторов, CS4148 и CS4132, а также CS4164, но с точки зрения начинка и софта - все эти модели равнозначны. Поэтому конфигурация будет одинаковая.
Настройка на коммутаторе.
На самой коробке, RADIUS настраивается следующим образом:
!
radius-server login host 10.0.0.1 vrf management seq-num 1 key КЛЮЧ
radius-server login host 10.0.0.2 vrf management seq-num 2 key КЛЮЧ
!
aaa local authentication attempts max-fail 5
aaa local authentication unlock-timeout 10
aaa group server radius RADIUS vrf management
server 10.0.0.1
server 10.0.0.2
aaa authentication login default vrf management group radius
aaa accounting default vrf management local
aaa authentication login console local
!
Собственно ничего особенного. Создаёте пару хостов, с ключами, которые дальше привязываются к группе серверов, под названием RADIUS, которая в свою очередь назначается на ААА.
Настройка на Cisco ISE.
После этого, необходимо настроить RADIUS сервер. У нас в кейсе это был Cisco ISE, ну собственно наверное самая распространённая вариация.
Из интересного, в отличии от привычной Cisco, B4COM 41xx не поддерживает атрибут №26, но поддерживает классический, определенный стандартом атрибут №136. Собственно его и будем использовать.
Первым шагом, пойдём в настройки словаря и преднастроим атрибуты.
Policy - Dictionaries - System - Radius - IETF
Дальше в списке слева, нужно найти наш атрибут №136 и перенастроить. Он будет именоваться как “undefined-136”. Кликаем и меняем на указанные на скриншоте параметры.
Обратите внимание, что я добавил в список Allowed Values значение Network Admin, которая равняется 15. Назвать можно как угодно, но Value будет использовать для передачи на коммутатор, т.е. 15 = максимальный уровень.
Не забываем сохранить и идём дальше.
Следующим шагом будет настройка профиля авторизации.
Policy - Policy Elements - Results - Authorization Profiles - Add.
Указываем имя и обязательно в меню Advanced Attributes Settings находим преднастроенные ранее параметры - Radius - Management-Privilege-Level и назначаем Value - Network Admin
Жмём сохранить и го дальше.
Т.к. мы хотим разделять устройства по вендору и/или моделям, то стоит добавить профиль: Administration - Network Resources - Network Device Profiles - Add
Нам тут нужна только галочка напротив RADIUS, остальное неинтересно.
Следующим шагом, добавляем наше устройство:
Administration - Network Resources - Network Device - Add
Указываем IP, и настраиваем ключ для RADIUS, который до этого указывали на коммутаторе.
Остаётся заключительный этап, собрать всё воедино и проверить.
Для этого идём в Policy - Policy Sets - “+”
Важно в меню conditions выбрать те параметры, по которым мы будем идентифицировать нашу сессию, я использую предварительно настроенный профиль - B4COM-4K.
Сохраняем и переходим вовнутрь для настройки самой политики
Обратите внимание на первую вкладку Authentication Policy - у меня она в состоянии “по умолчанию” и будет использовать все Identity Source, в том числе и LDAP, который был заранее преднастроен, описывать это тут не буду.
Во вкладке Autorization Policy выбираем наш профиль и сохраняем.
На этом настройка готова и мы можем проверять работоспособность всей конструкции.
Результат.
Заходим на коммутатор, он нас попросит ввести логин и пароль. Так как я использую в качестве источника данных AD, то логин и пароль соответственно будут доменные.
Консоль доступна и если ввести sh users, то мы увидим, что аутентифицированы под своей доменной учетной записью с максимальным уровнем доступа.
Дополнительно идём на ISE и смотрим нашу сессию там: Operations - RADIUS - Live Logs.
Как видите, сессия в активном состоянии, а все параметры соответствуют нашим настройкам.
Вывод. Как вы понимаете, с помощью данного мануала, необязательно настраивать B4COM, хоть команды и описаны тут для него, но это малая из деталей и никакой сложности не представляет, плюс я постарался максимально детально объяснить логику и поведение самого протокола в связке с Cisco ISE, как раз для того, чтобы вы смогли конкретно в вашем случае настроить любое другое оборудование.