Есть ли жизнь после Cisco ISE? Распаковка и тест-драйв российского NAC от Eltex в сетевой лаборатории

NAC-системы долгое время ассоциировались с “монстрами” вроде Cisco ISE или Aruba ClearPass. Но что, если собрать российский NAC из модулей «Медведь», «Лиса» и «Заяц», поставить их на страже сети и попробовать закрыть те же сценарии?

Привет, Хабр! С решениями NAC наша команда работает больше 19 лет. Последние годы особенно интересны: российский сегмент NAC заметно вырос, новые продукты появляются регулярно, а интерес со стороны заказчиков подталкивает нас на постоянный анализ рынка. 

Эта статья — часть цикла о NAC-решениях, которые мы разбираем в нашей сетевой лаборатории. На этот раз в фокусе Eltex NAICE — новичок в области контроля доступа, но далеко не новичок в мире сетей.  Разберёмся, как он устроен, какие задачи реально закрывает и насколько уверенно чувствует себя на фоне более привычных NAC-систем. 

Итак, NAICE

Произносишь название продукта и сразу всплывают флешбеки из прошлого, из курса по сетевой безопасности Cisco от CBT-Nuggets, где Кит Баркер напевал ISE-ISE-Baby. NAICE.. ISE.. С неймингом производитель не прогадал, цепляет, немного заставляет понастольгировать.

Забыли о прошлом, идем разбираться с нашим новичком. Архитектурно система представляет собой набор docker контейнеров, каждый контейнер отвечает за свой модуль: RADIUS, TACACS+, веб-сервер и так далее. Каждый модуль проименован в честь животных севера, чтобы не запутаться выполняющих свою роль: 

• Медведь (Ursus) является центральным модулем, управляющим всеми сущностями системы, схемой БД через внутренний API. 

• Чайка (Larus) — WEB-GUI для администраторов. 

• Баран (Ovis) уперто стоит как вкопанный и раздает access-accept/reject-ы на приходящие запросы. 

• Лиса (Vulpus) выполняет профилирование на базе собранной информации, в том числе по DHCP-пробам, отобрав их у собравшего эти пробы Зайца. 

• Заяц (Lepus) — коллектор DHCP-проб. 

В качестве базы данных используется СУБД PostgreSQL.

Пока я писал эту статью вышла первая мажорная версия NAICE 1.0 и минорная 1.1, так что на ходу приходилось что-то переписывать — некоторые моменты были изменены в лучшую сторону. Приятно видеть развитие продукта, а не выпуск новых версий просто для галочки. И сразу отмечу, обновление системы происходит с помощью одной команды, новые образы автоматически подтягиваются из публичного репозитория, очень удобно.

Первые шаги

С выходом версии 1.0 появилась возможность инсталляции системы с помощью OVA-образа. Будем откровенными, такой подход куда более дружелюбен к администратору системы и здорово упрощает жизнь при внедрении решения для интегратора. До этого приходилось устанавливать систему с помощью Ansible-плейбуков, благо в документации все расписано максимально подробно.

Итак, образ загружен, запускаем виртуалку. Вводим в консоли eltex/eltex и начинаем настройку системы. Тут нас встречает псевдографический интерфейс, дающий настроить базовые серверные параметры: IP-адрес, таймзону, DNS, NTP и прочее. Настраиваем, нажимаем <Finish>, ждем запуска всех контейнеров и вуаля, NAC-система Eltex NAICE развернута. Открываем браузер и стучимся по 443 порту на наш IP.

Помимо основного веб-интерфейса системы появилась консоль управления самого ПО NAICE с помощью отдельного веб-интерфейса, доступного по порту 8000. Пока не приступили к настройке системы посмотрим, что там под капотом у самого сервера. 

В основной вкладке видим базовую телеметрию виртуальной машины. Есть возможность открыть bash-терминал, иногда полезно, если нет прямого доступа к серверу по SSH. Далее по меню на вкладке Docker можно посмотреть какие контейнеры запущены, при необходимости есть возможность их перезапустить. В секции Eltex есть вкладки, где можно настроить сервер лицензирования, выполнить импорт/экспорт конфигурации сервера, а также собрать логи для техподдержки в случае возникновения проблем. Далее секция NAICE. Во вкладке Backup есть возможность экспорта/импорта БД системы. Во вкладке Certification видим настройки TLS сертификатов, используемых для PEAP/TLS аутентификации, а также для гостевого портала и веб-интерфейса системы. Тут я немного разочаровался, что нет возможности сделать CSR-запрос сразу в интерфейсе системы. Придется по старинке расчехлять openssl. Сразу сгенерировал сертификат для сервера, чтобы потом к этому не возвращаться и применил его для EAP-аутентификации и WEB, чтобы браузер не ругался. Последняя вкладка Configuration, внутри — настройки планировщика по удалению бэкапов БД, время жизни сессий TACACS+, сессий администраторов системы и еще пара других параметров. По итогу: в целом удобно, не надо лезть в консоль, чтобы сделать резервную копию БД или рестартануть контейнер. Некоторые настройки самой системы, например, работа с сертификатами, пока вынесены в этот интерфейс, хотя логичнее их разместить в основном интерфейсе. Это временное решение производителя, позже настройки будут перенесены в основной интерфейс. 

Собираем стенд

Приступим к самому интересному: тесты функционала системы. Перейдем непосредственно в сам веб-интерфейс системы. При входе в нас встречает дашборд со статистикой по подключениям. Пока здесь нечего смотреть, сперва настроим наш стенд. Мне показалось логичным в первую очередь собрать небольшую Eltex-моновендорную лабу из минимального набора — коммутатор доступа и Wi-Fi контроллер с точкой доступа. Схема простейшая, на ней посмотрим, как отработает заявленный функционал RADIUS/TACACS+.

Базовая настройка.

Первым делом добавим наше сетевое оборудование в качестве устройств-NAS. Перейдем на вкладку “Администрирование” -> “Сетевые ресурсы”. Добавляем наши коммутатор MES2410-08DP и контроллер WLC-15. Указываем имя, модель, один из предустановленных в системе профилей (в нашем случае Eltex MES и Eltex WLC), ip-адрес, описание. Далее выбираем группу и локацию, этими абстракциями мы будем пользоваться в политиках доступа. Вводим ключ для RADIUS и TACACS+ ии.. поле для ввода ключа TACACS+ неактивно. Подсказка говорит “Не поддерживается выбранным профилем”. Оказалось, что по умолчанию в каждом профиле устройств TACACS+ выключен. Переходим в настройки профилей и включаем протокол. Далее возвращаемся в настройки устройств прописываем ключ для TACACS+ и сохраняем.

Посмотрим настройки профилей устройств повнимательнее. Помимо включения/выключения протоколов RADIUS/TACACS+ нам доступны настройки атрибутов для определения типа аутентификации (802.1x или MAB), настройка атрибутов для работы MAB и протокола PAP или EAP_MD5. Также доступны настройки атрибутов для динамического назначения VLAN и ACL, настройки CoA и атрибутов для перенаправления клиента на гостевой портал. Кажется, что есть все, что нужно — будем проверять как все работает на практике.

Теперь настроим в качестве внешнего источника учетных записей наш лабораторный каталог Active Directory. Перейдем на вкладку “Администрирование” -> “Управление идентификацией” и добавим источник. В настройках доступен выбор схемы каталога, есть предустановленная схема для AD. Вводим имя домена, далее имя и пароль компьютера, с помощью которого система будет подключаться к AD в ходе авторизации пользователей. Тут важный момент, компьютер должен быть заранее создан администратором AD. Считаю, что этот момент может быть доработан, в системах NAC других производителей компьютер создается автоматически. Далее вводим логин и пароль учетной записи, с помощью которой система будет искать пользователей каталога с помощью LDAP. Вводим FQDN домена — полное имя и порт LDAP. Начиная с версии 1.1 появилась возможность включить поддержку LDAPS. Проверяем связь с сервером, в результате теста видим успешное LDAP подключение. Нажимаем <Далее> и выбираем группы для наших будущих политик. Последний этап — выбор атрибутов, пока это пропустим. Сохраняем настройки.

RADIUS.

В общих чертах подход к настройкам политик доступа максимально понятен, все необходимые параметры находятся рядом. Процесс настройки получается последовательным и быстрым. Во вкладке “Политики” -> “Элементы” настраиваем:

1. Профили авторизации — результат авторизации клиента.

2. Набор разрешенных протоколов — на данный момент это PAP, MSCHAPv2, EAP-PEAP и EAP-TLS, а также MAB.

3. Условия — по сути конструктор для создания составных условий, используемых в политиках аутентификации и авторизации.

4. Словари — наборы IETF атрибутов, например, словарь стандартных RADIUS-атрибутов, а также словари RADIUS известных вендоров.

Не будем подробно останавливаться на каждом шаге настройки. Создадим необходимые для тестов профили авторизации с разными атрибутами (VLAN, ACL) и включим необходимые протоколы — будем тестировать MAB, PEAP и TLS.

Переходим непосредственно к настройке наборов политики. Кто успел поработать с Cisco ISE узнают знакомый интерфейс, и я считаю это плюсом. Политики группируются на нескольких уровнях. Самый верхний уровень — набор политик, он же Policy Set. Попадая под подходящее условие сессии будут обрабатываться в соответствии с более низкоуровневыми условиями. Также для каждого набора политик задается конкретный набор доступных протоколов. Внутри каждого набора политик создаются отдельно политики аутентификации и авторизации. На этапе аутентификации каждой клиентской сессии выбирается подходящая политика в соответствии с подходящим условием и применяется конкретная цепочка идентификации, т.е. порядок проверки источников аутентификации. Далее на этапе авторизации в зависимости от настроенных условий применяются конкретные профили (результаты) авторизации, настроенные ранее. Например, пользователи из условной группы AD_Contractors получат ограниченный доступ в сеть с помощью примененного на сессию ACL и попадут в свой VLAN_Contractors.

На отдельной вкладке “Профилирование” есть возможность настроить политики профилирования клиентских подключений по различным параметрам. Благодаря этим политикам клиенту может быть назначен определенный профиль, например Windows PC или Eltex IP Phone. На данный момент профили могут быть назначены на основании всего двух механизмов — определения вендора по OUI MAC-адреса и информации из копии DHCP-пакетов. Надеемся на увеличение этого списка и появления профилирования по CDP/LLDP, SNMP, NMAP, User-Agent.

Приступим к настройке. Сперва заранее настроим политики профилирования для наших клиентов. Это будут точки доступа, Windows ПК, смартфон и “зловредное устройство” Linux ПК. Не будем останавливаться на деталях, политики настраиваются интуитивно просто. Чтобы корректно заполнить атрибуты в качестве  условий для профилирования прослушиваю DHCP пакеты Wireshark-ом. Также в эндпоинтах в разделе “Пробы” можно увидеть данные, полученные с помощью профилирования. 

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

Далее настроим два Policy Set-а, отдельно под MAB и 802.1X. В качестве условия для входа в набор политик используем фильтр по механизму аутентификации — Wireless/Wired MAB и Wireless/Wired 802.1X соответственно.

В наборе MAB настроим mac-аутентификацию точек доступа. В сети уже есть точка, на порту коммутатора настроен механизм mac-аутентификации и уже видны неуспешные попытки авторизации. Добавляем мак точки в локальную группу “AP” и заодно настраиваем политику профилирования на основе данных из DHCP-пакетов. В правилах авторизации указываем проверку на вхождение в группу “AP” и успешное профилирование на основе DHCP. Результатом авторизации настроим динамическое применение VLAN для точек доступа. Переподключаем точку и радуемся нашему первому access-accept. На сессию применился корректный VLAN, точка доступа в сети и зарегистрирована на контроллере.

Так как у нас настроено профилирование для точек доступа, попробуем проверить, пустит ли в сеть нашего “зловреда”. Подменим мак-адрес точки доступа и подключимся в порт коммутатора. Проверяем логи — access-reject, в сеть не пустило, механизм профилирования отработал.

Теперь настроим PEAP аутентификацию по учетным записям AD. У меня заготовлен ПК, заведенный в домен и создан пользователь user0, состоящий в группе XXX-Users. В наборе политик DOT1X в качестве условий авторизации будем использовать проверку на вхождение пользователя в корректную группу AD, а также проверку на успешный результат профилирования. Пробуем подключиться к сети с помощью смартфона по Wi-Fi и ПК через порт коммутатора. Успех, радуемся access-accept-ам. ПК и телефон попали в свой VLAN, но с помощью примененного на сессию ACL получили ограниченный доступ в сеть — есть Интернет, и доступны пара локальных адресов — все остальное заблокировано.

Усложняем задачу, настроим аутентификацию по TLS-сертификатам. На доменном ПК уже установлены пользовательский и машинные сертификаты, а также добавлен сертификат нашего CA в качестве доверенного корневого. Авторизацию будем проходить по уже созданным для PEAP условиям, а аутентификацию пройдем с использованием настроенной цепочки идентификации, в которой указано, какой атрибут сертификата использовать в качестве имени пользователя (Common Name).

Подключаем ПК к сети, радуемся очередным access-accept-ам.

TACACS+.

Протестируем функционал аутентификации и авторизации администраторов на сетевом оборудовании с помощью протокола TACACS+. Во вкладке “Контроль сетевых устройств” -> “Элементы политик” -> “Наборы команд TACACS+” заранее настроим тестовый набор команд “show run”, в котором разрешим только выполнение команды show running-config. В домене создадим 2 группы пользователей — Administrators и Operators. Админам дадим полный доступ, а операторам позволим пользоваться только командой show run.

Во вкладке “Контроль сетевых устройств” -> “Политики сетевых устройств” расширим дефолтный набор политик. В качестве источника аутентификации указываем наш домен, в правилах авторизации создаем правила для проверки вхождения пользователя в группу Administrators или Operators.

Подключаемся к коммутатору с помощью учетки admin0, пробуем show run и conf t — работает, в логах есть успешная аутентификация и видны введенные команды. Теперь подключаемся с помощью учетки operator0, пробуем show run — работает, conf t — команда не проходит авторизацию, как и было задумано. Из логов авторизации сразу понятно, какая команда прошла, а какая нет.

Итого: мы проверили MAB, PEAP, TLS, профилирование и TACACS+, в общем базовый функционал, закрывающий большую часть потребностей наших заказчиков. Стенд не разбираем, еще пригодится для будущих тестов. Пришло время посмотреть на картину целиком.

Что по итогу

Можно смело сказать, что текущая версия NAICE успешно закрывает базовые сценарии NAC (802.1X c EAP-TLS/PEAP, MAB, CoA, гостевой доступ, динамические VLAN/ACL, TACACS+), но по некоторым пунктам остаётся функциональный зазор до «бенчмарков» (Cisco ISE и Aruba ClearPass) и ряда отечественных решений: расширенная поддержка EAP протоколов, глубокое профилирование, posture/MDM-интеграции. 

Новый функционал добавляется буквально на глазах и минорные апдейты выходят регулярно, так что продолжаем следить за развитием продукта. В следующих статьях проверим уже расширенные возможности решения по мере появления нового функционала. Ждем реализации Posture (дополнительные проверки конечных устройств), модели BYOD — интересно будет посмотреть на механизм онбординга личных устройств.