Обзор #

РАДИУС or Служба удаленного подключения по телефонной линии пользователя это сетевой протокол, обеспечивающий централизованное управление аутентификацией, авторизацией и учетом пользователей и устройств. Он широко используется интернет-провайдерами и предприятиями для управления доступом к Интернету, местным службам, беспроводным сетям через точки доступа Wi-Fi и т. Д.

Протокол RADIUS реализован на уровне приложений с архитектурой клиент-сервер, которая может использовать TCP или UDP в качестве транспортного уровня и обмениваться данными с пользовательской базой данных, такой как Active Directory, Служба LDAP or Система учета Linux, Наиболее популярными решениями RADIUS являются FreeRadius или Microsoft NPS Radius Server.

RADIUS Протокол обмена сообщениями #

Обмен сообщениями протокола основан на запросе клиента и способе ответа сервера, как показано ниже.

1. Клиент отправляет Access-Request на сервер для каждого пользователя или устройства для аутентификации на порт сервера TCP / UDP 1812 (старые версии сервера будут использовать 1645 для проверки подлинности).
2. Сервер отвечает в соответствии с политикой Access-Accept если аутентификация разрешена, Access-Reject если доступ не разрешен или Access-Challenge если серверу требуется дополнительная информация для определения доступа (например, вторая проверка: PIN-код, пароль, сертификат и т. д.)

При желании, клиент и сервер могут обмениваться сообщениями учета, например, Accounting-Request и Accounting-Response для того, чтобы поддерживать уникальный идентификатор сеанса.

3. Клиент отправляет Accounting-Request на сервер через порт TCP / UDP 1813 для управления учетными сессиями (старые версии сервера будут использовать 1646 для проверки подлинности).
4. Сервер отвечает с Accounting-Response сообщение для подтверждения нового сеанса.

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

Балансировка нагрузки RADIUS и среда высокой доступности #

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

RELIANOID будет распределять сообщения протокола RADIUS между всеми серверами RADIUS, независимо от того, находятся ли они на разных или локальных сайтах. В следующих разделах мы объясняем конфигурацию такого типа сред, расширенные проверки работоспособности служб RADIUS и проблемы безопасности этого протокола.

Конфигурация виртуальной службы RADIUS #

Природа протокола RADIUS основана на пакетах UDP, поэтому конфигурация надежной среды RADIUS строится с LSLB ферма с L4xNAT профиль на слое 4, порты 1812 и 1813тип протокола UDP и предпочтительный ДТА для того, чтобы иметь прозрачность и получить IP-адрес клиента на стороне сервера (хотя NAT должно работать отлично, а также).

В Услугипостоянство не требуется по умолчанию, если не требуется некоторая привязка между сервером клиентского радиуса.

Если RADIUS используется через TCP вместо UDP, его можно изменить в поле типа протокола. Это может быть установлено также BCE протоколы, позволяющие одновременно использовать TCP и UDP с одного и того же виртуального IP.

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

Конфигурация расширенной проверки работоспособности RADIUS #

Расширенная проверка включена в RELIANOID с именем check_radius в папке по умолчанию / USR / местные / zenloadbalancer / приложение / libexec /.

Справка этой команды может быть перечислена:

root@noid5# /usr/local/zenloadbalancer/app/libexec/check_radius --help Проверяет, принимает ли сервер RADIUS соединения. Использование: check_radius -H хост -F файл_конфигурации -u имя пользователя -p пароль [-P порт] [-t тайм-аут] [-r повторы] [-e ожидать] [-n nas-id] [-N nas-ip-адрес ] Опции: -h, --help Распечатать экран подробной справки -V, --version Распечатать информацию о версии --extra-opts=[section][@file] Считать параметры из ini-файла. См. https://www.monitoring-plugins.org/doc/extra-opts.html для использования и примеров. -H, --hostname=ADDRESS Имя хоста, IP-адрес или сокет unix (должен быть абсолютным путем) -P, --port=INTEGER Номер порта (по умолчанию: 1645) -u, --username=STRING Пользователь, которому нужно аутентификация -p, --password=STRING Пароль для аутентификации (РИСК БЕЗОПАСНОСТИ) -n, --nas-id=STRING Идентификатор NAS -N, --nas-ip-address=STRING IP-адрес NAS -F, --filename= STRING Файл конфигурации -e, --expect=STRING Ожидаемая строка ответа от сервера -r, --retries=INTEGER Количество повторов неудачного соединения -t, --timeout=INTEGER Секунды до истечения времени соединения (по умолчанию: 10) Этот плагин проверяет сервер RADIUS, принимает ли он соединения. При вызове должен быть указан сервер для тестирования, а также имя пользователя и пароль. Также может присутствовать файл конфигурации. Формат файла конфигурации описан в исходниках библиотеки radiusclient. Параметр пароля представляет собой существенную проблему безопасности, поскольку пароль можно определить путем внимательного просмотра командной строки в списке процессов. Этот риск усугубляется тем, что плагин обычно запускается через регулярные и предсказуемые промежутки времени. Убедитесь, что используемый пароль не разрешает доступ к конфиденциальным системным ресурсам.

Во-первых, давайте проверим, правильно ли он работает, выполнив следующий пример команды (пожалуйста, используйте свои собственные параметры конфигурации клиента радиуса из RELIANOID):

root@noid5# cd /usr/local/zenloadbalancer/app/libexec/ root@noid5# ./check_radius -H -П -у -п -Ф

Тест будет проводиться с RELIANOID устройство к одному определенному серверу RADIUS с фиктивной проверкой пользователя и, при необходимости, файлом конфигурации клиента для определенных параметров клиента. Давайте проверим команду, а затем, когда мы получим OK с сервера и тому FAILURE когда он не работает, мы можем настроить расширенную проверку работоспособности в Услуги раздел нашего только что созданного виртуального сервиса.

Не забывайте использовать ВЕДУЩИЙ токен при настройке расширенных проверок работоспособности в RELIANOID как указано ниже.

check_radius -H HOST -P 1812 -u johndoe -p johnspass -F /etc/radius_client.cfg

Смотрите ниже Услуги Конфигурация раздела.

Параметры безопасности RADIUS #

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

Развертывания RADIUS прошли IPsec or Internet Protocol Security были широко распространены, но этот вариант имеет некоторые трудности, поскольку уровень приложений не знает о политиках безопасности, поскольку они неявно заложены на сетевом уровне. Чтобы использовать этот подход с RELIANOID требуется некоторая ручная настройка, поскольку она еще не интегрирована.

Спецификация DTLS or Безопасность дейтаграммы на транспортном уровне позволяет обеспечивать шифрование, отслеживать и контролировать политики безопасности такого трафика.

Другим вариантом будет RADIUS более TLS это обеспечивает возможности TCP надежности и упорядоченного транспортного уровня.

Для такого рода подходов IANA создал официальную запись для RadSec (RADIUS Безопасность) использовать UDP 2083 порт для RADIUS / TLS Реализации.

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

Кроме того, с RELIANOID, службы RADIUS можно защитить с помощью модуля IPDS от вредоносных пакетов и хостов, DoS-атак, попыток перебора и многого другого.

Возможности RADIUS Proxy #

Если несколько серверов RADIUS развернуты на разных сайтах, было бы интересно перенаправить клиентское соединение на сайт, который управляет их данными аутентификации, авторизации и учета. В настоящее время, RELIANOID не поддерживает возможности прокси-сервера RADIUS, но его планируется включить в ближайшее время. С нетерпением ждите последних событий!

Наслаждайтесь своими высокодоступными и масштабируемыми услугами доступа к сети!