Radius

Всеволод Стахов

Протокол radius (Remote Authentication Dial In User Service) служит для аутентификации dial-up пользователей. Обычно radius используется маршрутизаторами Cisco для организации модемных линий, но возможны и варианты связки radius и pppd. В дальнейшем любого клиента radius я буду называть NAS (network access server – сервер, предоставляющий доступ в сеть). Если кто интересуется, чем же таким примечателен radius, то отвечу: данный протокол, с моей точки зрения, является логическим продолжением традиций tacacs-сервера, но он поддерживает больше возможностей и организован намного лучше. Особенно мне понравилась возможность проверки различных NAS по ключу и IP-адресу. Огорчает только относительная молодость протокола, отсутствие качественной документации по бесплатным серверам, отсутствие поддержки протокола старыми NAS. Последний пункт меня особенно опечалил: мои любимые коммутаторы Cisco Catalyst, что прекрасно работали с tacacs-сервером, наотрез отказались от работы с radius. Но в последних моделях Cisco и многие другие производители NAS поддерживают этот протокол.

Для начала определюсь с терминологией:

n  AV-пара – пара атрибут=значение.

n  Авторизация – процесс проверки AV-пар пользователя. В ходе авторизации могут также устанавливаться определённые AV-пары (для сервера freeradius), смысл авторизации заключается в проверке достаточности информации, предоставленной пользователем, для того чтобы пользователь мог пройти аутентификацию.

n  Аутентификация – процесс опроса внешних источников данных radius-сервером для сравнения AV-пар, предоставленных пользователем, и пар, хранящихся во внешнем источнике; выбор метода аутентификации определяется AV-парой Auth-Type.

n  Аккаунтинг (или учёт) – процесс посылки на radius-сервер пакетов NAS, которые содержат информацию о текущем соединении (время, количество переданного трафика и т. д.), на основании этой информации скрипты счетчиков или биллинговой системы могут выполнять различные действия по ограничению доступа пользователей на NAS.

Из серверов, доступных в сети, я выбрал freeradius (http://www.freeradius.org) – новая версия популярного cistron radius, который особенно меня порадовал тем, что он содержит значительное количество модулей аутентификации (например, sql, ldap, unix-passwd, samba-passwd) и стандартный (обладающий меньшими возможностями) radiusd-livingston (ftp://ftp.livingston.com/pub/le/radius/radius21.tar.Z). Эти два сервера распространяются бесплатно, и их компиляция не вызывает затруднений:

$./configure

$make

#make install

Теперь самое время рассказать поподробнее о самом протоколе radius.

Сервер radius использует протокол UDP для работы. Стандартно radius-сервер прослушивает 1812 порт. Для аккаунтинга используется другой порт – 1813 (radius-acct).

Рассмотрим, как отреагирует NAS при поступлении запроса пользователя на аутентификацию:

n  пользователь пытается пройти аутентификацию на NAS;

n  NAS смотрит в первый попавшийся radius-сервер и посылает пакет для установки связи (запрос на доступ);

n  если ответ не получен в течение определённого тайм-аута, то NAS либо опрашивает radius-сервер ещё раз, либо ищет альтернативный сервер;

n  radius-сервер смотрит IP-адрес NAS и проверяет ключ симметричного шифрования, если IP-адрес и ключ соответствуют тому, что написано в конфигурационном файле, то связь продолжается, иначе клиенту посылается пакет Invalid Key. Проверка осуществляется генерацией и шифрацией случайной строки. Затем данные, передаваемые между клиентом и сервером radius, шифруются этим ключом;

n  сервер radius проверяет пароль пользователя (по сети передается md5-хеш пароля), помимо пароля сервер может также проверить IP-адрес и порт NAS, если эти данные неверны, то сервер посылает NAS пакет «Доступ запрещён», содержащий код ошибки и иногда её текстовое описание, отображаемое для пользователя;

n  если же данные пользователя верны, то сервер посылает NAS пакет «Доступ разрешён», содержащий данные о сервисе (PPP, SLIP, login) и некоторые его специфические параметры, например, IP-адрес, номер подсети, MTU для PPP-сервиса в виде пар параметр=значение (AV-пар).

После краткого теоретического отступления перейду к описанию настройки серверов. Для начала сразу же определюсь: я не ставлю своей целью рассказать о каждой опции и возможности, я просто описываю, как оно работает у меня. Настройки livingston и freeradius сильно различаются, поэтому рассматривать их я буду по отдельности. Radiusd-livingston является более ранним сервером и проще в настройке, чем freeradius, поэтому о нем – в первую очередь.

Конфигурация сервера хранится в каталоге /etc/raddb (или в $PREFIX/etc/raddb) и представляет собой несколько файлов, отвечающих за работу отдельных механизмов сервера:

n  clients – определения NAS (ключ и IP-адрес) для проверки подлинности клиента;

n  users – файл, описывающий dial-in пользователей;

n  proxy – настройки перенаправления запросов клиентов другим radius-серверам, если аутентификация на данном прошла неудачно (возможность роуминга или распределения пользователей);

n  dictionary – словарь определений AV-пар для работы с клиентом.

Далее я приведу примеры конфигурационных файлов с комментариями:

clients:

# В данном файле находится список клиентов (NAS), которые  могут проходить аутентификацию. Клиент проходит проверку

# имени и ключа. Файл имеет соответствующую структуру: поле имени и поле ключа:

# Имя клиента           Ключ

#---------------- -------------------

NAS1                    123456789cba

NAS2:call               987654321abc

proxy:

# В этом файле описываются radius-серверы, на которые данный может перенаправлять запросы NAS. Такое поведение,

# например, полезно для организации роуминга. Представим ситуацию: существует 2 провайдера А и Б, они хотят, чтобы

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

# прописывается radius-сервер второго провайдера, на который будет осуществляться перенаправление. Наличие ключей

# позволяет защитить сервера доступа от подмены данных. Рассматриваемый файл содержит четыре поля: имя сервера,

# ключ доступа к серверу (на удалённом сервере необходимо внести запись в clients, соответствующую серверу,

# осуществившему перенаправление), область действия сервера (т.е. каких клиентов следует перенаправлять на данный

# сервер, определяется именем клиента после знака @, на пример, user@test.ru), необязательные опции и номера портов.

# Доступные опции выглядят следующим образом: old – удаление области действия и состояния прокси из заголовка

# сообщения от NAS, secure – возможность пересылки запросов на доступ с привилегиями администратора, ipass –

# использование протокола ipass (непереводимое слово).

rad.test.ru      somekey             test.ru

radius.ru.net    papakeyyer   com.net        1645 1646 secure

users:

# Это основной файл, где хранятся данные о пользователях. Описание идёт так: вначале без отступа имя пользователя,

# затем, отступая на табуляцию, идут AV-пары (первой парой идёт пароль). AV-пары должны описываться в файле

# словаря dictionary. Существует также специальный пользователь по умолчанию, который имеет специальное имя

# DEFAULT. Обычно пользователь по умолчанию применяется, когда описания пользователей находятся не в данном файле,

# а в /etc/passwd, но об этом я расскажу далее. Для начала приведу несколько примеров описания пользователей

# (для получения полного списка AV-пар смотрите файл словаря). Ещё учтите, что имя пользователя может иметь максимум 8

# символов в длину, пароль в принципе до 254 символов, но я часто слышал про ограничение в 31 символ (честно говоря,

# представить себе не могу, когда может понадобиться пароль длиннее 31 символа!)

user1      Password = "testing", Expiration = "Dec 24 1995"

    Service-Type = Framed-User,

    Framed-Protocol = PPP,

    Framed-IP-Address = 255.255.255.254,

    Framed-Routing = None,

    Filter-Id = "std.ppp",

    Framed-MTU = 1500,

    Framed-Compression = Van-Jacobson-TCP-IP

user2      Password = "moretest"

    Service-Type = Login-User,

    Login-IP-Host = 192.168.2.7,

    Login-Service = PortMaster

user3      Password = "callme"

    Service-Type = Callback-Login-User,

    Login-IP-Host = timeshare1,

    Login-Service = PortMaster,

    Callback-Number = "1231234"

# В конце файла может быть описание пользователя по умолчанию DEFAULT. В данном случае используется аутентификация

# через пароли в /etc/passwd, для этого применяется директива Auth-Type = System. Значение префикса или суффикса

# для имени пользователя означает, что производится поиск данного префикса или суффикса, а остальная часть имени

# используется непосредственно как имя пользователя. Это удобно для добавления различных типов доступа для пользователя

# в зависимости от префикса или суффикса. Рассмотрим пример:

# Для пользователей, начинающихся с буквы P (Pusername) используется сервис PPP

DEFAULT    Auth-Type = System, Prefix = "P"

    Service-Type = Framed-User,

    Framed-Protocol = PPP,

    Framed-IP-Address = 255.255.255.254,

    Framed-MTU = 1500

# Для префикса S - SLIP

DEFAULT    Auth-Type = System, Prefix = "S"

    Service-Type = Framed-User,

    Framed-Protocol = SLIP,

    Framed-IP-Address = 255.255.255.254,

    Framed-Compression = None

# Компрессия трафика - префикс C

DEFAULT    Auth-Type = System, Prefix = "C"

    Service-Type = Framed-User,

    Framed-Protocol = SLIP,

    Framed-IP-Address = 255.255.255.254,

    Framed-Compression = Van-Jacobson-TCP-IP

# Здесь используется суффикс %ppp, сигнализирущий использование протокола PPP

DEFAULT    Auth-Type = System, Suffix = "%ppp"

    Service-Type = Framed-User,

    Framed-Protocol = PPP,

    Framed-IP-Address = 255.255.255.254,

    Framed-MTU = 1500

# Для пользователя, не соответствующего другим определениям, запускаем протокол PPP

DEFAULT    Auth-Type = System, Framed-Protocol = PPP

    Service-Type = Framed-User,

    Framed-Protocol = PPP,

    Framed-IP-Address = 255.255.255.254,

    Framed-MTU = 1500

dictionary:

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

# пример только основных AV: ATTRIBUTE имя_атрибута число_соответствующее_атрибуту тип_атрибута. Число для

# атрибута используется как синоним текста, можно написать Password="text", что идентично 2="text". Тип атрибута

# может принимать следующие значения:

#   string – строка длиной от 0 до 253 символов;

#   ipaddr – IP-адрес, 4 байта в сетевом порядке;

#   integer – 32-х битное целое в интеловском порядке байт;

#   date – 32-х битное число, означающее текущую дату и время;

ATTRIBUTE  User-Name           1      string

ATTRIBUTE  Password            2      string

ATTRIBUTE  Framed-IP-Address   8      ipaddr

ATTRIBUTE  Expiration          21     date

# Описания значений: VALUE имя_значения имя_атрибута номер. Эти описания обычно служат для установления соответствия

# строка-номер. Так, например, значение протокола имеет числовой вид, но для упрощения составления файла

# конфигурации некоторым числам сопоставлены числовые константы (можно привести аналогию #define MACRO 1 в си):

VALUE      Service-Type        Login-User          1

VALUE      Service-Type        Framed-User         2

VALUE      Service-Type        Callback-Login-User 3

VALUE      Service-Type        Callback-Framed-User       4

VALUE      Service-Type        Outbound-User       5

VALUE      Service-Type        Administrative-User 6

VALUE      Framed-Protocol     PPP                 1

VALUE      Framed-Protocol     SLIP                2

VALUE      Framed-Protocol     ARAP                3

VALUE      Login-Service       Telnet              0

VALUE      Login-Service       Rlogin              1

VALUE      Login-Service       TCP-Clear           2

VALUE      Login-Service       PortMaster          3

Для проверки работы radius-сервера используется специальная программа -rad_test, но о ней я расскажу далее при описании сервера freeradius (в livingston она точно такая же).

Сервер freeradius отличается исключительной функциональностью. Он может работать с SQL-серверами (в настоящее время поддерживаются mysql, postgresql, oracle), LDAP-сервером, содержит в себе достаточно много AV-словарей, отличается комплексной настройкой, поддерживает дополнительные модули, имеет веб-интерфейс для настройки и несколько весьма полезных скриптов. Конфигурация freeradius несколько похожа на настройку livingston, поэтому я буду рассказывать преимущественно о работе аутентификации пользователей radius через mysql.

Общие настройки сервера размещаются в файле radiusd.conf. Я приведу здесь несколько опций, показавшихся мне полезными:

radiusd.conf

# Общая схема файлов конфигурации freeradius позволяет использовать специальную директиву $INCLUDE для включения

# конфигурационных файлов в данный (формат .conf)

$INCLUDE  ${confdir}/proxy.conf

$INCLUDE  ${confdir}/clients.conf

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

# было поменьше. Если же использовать аутентификацию mysql, то выбор nobody:nobody, на мой взгляд, является самым

# наилучшим.

user = nobody

group = nobody

# Максимальное время обработки запроса (в секундах), по истечении которого клиенту будет послан пакет, сигнализирующий

# разрыв соединения.

max_request_time = 30

# Максимальное количество соединений для данного сервера получается умножением числа NAS в сети на 256. Например,

# для 4 клиентов, значение будет 4*256=1024

max_requests = 1024

# Заносить  в лог данные о полном имени пользователя

log_stripped_names = yes

# Заносить ли в лог информацию о запросах на аутентификацию

log_auth = no

# Заносить ли в лог данные о переданных паролях (неправильных и правильных соответственно)

log_auth_badpass = yes

log_auth_goodpass = no

# Приводить ли к нижнему регистру все имена пользователей и пароли (весьма полезно для некоторых пользователей).

# Возможные значения: no – чувствительные к регистру пароль/имя, before – вначале приводим к нижнему регистру,

# потом проводим аутентификацию, after – вначале проверяем аутентификацию как есть, если не получилось, то приводим

# к нижнему регистру и повторяем попытку.

lower_user = no

lower_pass = no

# Убираем пробелы из имени пользователя и пароля. Полезно для имён и паролей, содержащих пробелы. Возможные

# значения аналогичны предыдущему случаю.

nospace_user = no

nospace_pass = no

# Весьма полезные параметры модуля безопасности сервера:

security {

    # Максимальное число AV-пар в пакете. Если число пар больше, то пакет не обрабатывается. Если указать

    # данный параметр равным нулю, то будут обрабатываться любые пакеты.

    max_attributes = 200

    # Пакет отказа доступа может быть отправлен с некоторой задержкой (в секундах). Такое поведение предотвращает

    # применение DoS-атаки. Если же указать значение, равное нулю, то отказ будет посылаться без задержки.

    reject_delay = 1

    # Посылать ответ на запрос NAS о статусе сервера. Такое поведение не описано в rfc, поэтому по умолчанию – no

    # (как написано в комментариях, «может пригодиться для некоторых особых NAS»)

    status_server = no

}

# Обрабатывать перенаправление запросов. Если перенаправление отключено, то необходимо отключить файл proxy.conf, дабы

# избежать ошибок конфигурации (закомментировать директиву $INCLUDE ${confdir}/proxy.conf).

proxy_requests  = yes

# Далее следуют описания многочисленных модулей freeradius, позволяющие настроить, к примеру, методы шифрации паролей

# или работу различных аутентификационных протоколов (PAP, CHAP, MS-CHAP), но описывать здесь всё я не намерен: думаю,

# что в примерах все и так очень подробно обьяснено и разобраться не составит труда.

Настройка клиентов производится в файле clients.conf:

clients.conf

# В данном файле описываются клиенты aka NAS. Формат файла напоминает файл настройки tacacs+. Вначале идёт определение

# клиента: client имя_или_ip_адрес, затем идёт список AV-пар для данного клиента, заключённый в фигурные скобки. Приведу

# несколько примеров:

client 127.0.0.1 {

    # Пароль для идентификации клиента и обмена с ним данными. Данным ключом также осуществляется проверка

    # неизменности передаваемых пакетов (подпись).

    secret       = some_strange_secret

    # Краткое имя для клиента.

    shortname    = localhost

    # Следующие три поля необязательны, но они полезны для работы скрипта checkrad.pl (проверка  работы процессов

    # сервера)

    # Поле типа NAS может принимать следующие значения: Хотя зачем это нужно, я так и не понял.

    #      cisco

    #      computone

    #      livingston

    #      max40xx

    #      multitech

    #      netserver

    #      pathras

    #      patton

    #      portslave

    #      tc

    #      usrhiper

    #      other

    nastype     = other # localhost обычно не является NAS

    # Две следующие строчки зарезервированы на будущее. Вообще-то они должны использоваться для проверки

    # имени пользователя и пароля для данного NAS

#   login       = !root

#   password    = someadminpas

}

client some.test.ru {

    secret       = some_host_secret

    shortname    = somenas

}

# Также можно определять пароль для всех клиентов некоторой подсети (чем меньше подсеть, тем лучше, а  вообще, на мой взгляд,

# это не есть хорошо из соображений безопасности)

client 192.168.0.0/24 {

    secret       = a_very_long_passwd

    shortname    = private-network

}

Далее я кратко остановлюсь на особенностях настройки файла proxy.conf. В отличие от сервера livingston во freeradius опять же используется собственный конфигурационный формат. Из нововведений особенно бросается в глаза новая директива – realm, определяющая область перенаправления. Дабы не быть голословным опять же приведу несложный пример:

proxy.conf

# Данный файл состоит из двух разделов: описание настроек самого прокси-сервера и описание областей перенаправления.

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

# определения области realm. Она выглядит следующим образом: realm имя_области. Имя области должно являться именем

# домена, который этой областью описывается. Если вместо имени области употребляется слово DEFAULT, то в данную

# область будут перенаправляться запросы, не соответствующие ни одному параметру. Поясню это на примерах:

realm isp2.ru {

# Тип сервера

    type        = radius

# Сервер radius для аутентификации

    authhost    = radius.isp2.com:1645

# Сервер radius для аутентификации (обычно другой порт)

    accthost    = radius.isp2.com:1646

# Секрет для связи

    secret      = our_concurents_key

# Не убирать суффикс или префикс области из имени пользователя

    nostrip

}

# Если перенаправить запрос на данный сервер не удалось, то происходит выборка другого сервера для данной области

# или сервера по умолчанию. Также существует специальная область NULL для клиентов, которые не определили область

# действия, например, просто user (сравните user@isp2.ru)

realm NULL {

    type         = radius

    authhost     = radius.test.ru

    accthost     = radius.test.ru

    secret       = our_secret_key

}

# Ну а для тех пользователей, чья область не определена, используется сервер по умолчанию:

realm DEFAULT {

    type         = radius

    authhost     = radius.test.ru

    accthost     = radius.test.ru

    secret       = our_secret_key

}

# Учтите: в двух последних примерах при перенаправлении запроса к вторичным серверам radius из имени пользователя

# вырезается имя области, т.к. не определена опция nostrip.

Теперь для любопытствующих кратко опишу назначение остальных конфигурационных файлов freeradius:

n  acct_users – содержит установки учёта (аккаунтинга). Обычно используется для задания начальных и конечных скриптов для пользователя и областей репликации (см. пример). В скрипты можно передавать специальные переменные:

n  %a         Protocol (SLIP/PPP)

n  %c         Callback-Number

n  %d         request day (DD)

n  %f          Framed IP address

n  %i          Calling Station ID

n  %l          request timestamp

n  %m        request month (MM)

n  %n         NAS IP address

n  %p         Port number

n  %s         Speed (PW_CONNECT_INFO)

n  %t          request in ctime format

n  %u         User name

n  %A        radacct_dir

n  %C        clientname

n  %D        request date (YYYYMMDD)

n  %H        request hour

n  %L         radlog_dir

n  %M       MTU

n  %R        radius_dir

n  %S         request timestamp in SQL format

n  %T         request timestamp in database format

n  %U        Stripped User name

n  %V        Request-Authenticator (Verified/None)

n  %Y        request year (YYYY)

 Пример:

DEFAULT Acct-Status-Type == Start

 Exec-Program = "/path/to/exec/acct/start %U"

DEFAULT Acct-Status-Type == Stop

Exec-Program = "/path/to/exec/acct/stop %U %n %a"

n  attrs – информация об AV-парах по умолчанию для каждой области действия.

n  clients.conf – настройки NAS.

n  dictionary – данные об известных AV-парах.

n  hints – информация о суффиксах и префиксах имён пользователей.

    Пример:

# Здесь директива Strip-User-Name определяет, удалять ли префикс или суффикс из имени

DEFAULT Suffix = ".ppp", Strip-User-Name = Yes

Hint = "PPP",

Service-Type = Framed-User,

Framed-Protocol = PPP

DEFAULT Prefix = "P", Strip-User-Name = Yes

Hint = "PPP",

Service-Type = Framed-User,

Framed-Protocol = PPP

n  proxy.conf – информация об областях.

n  sql.conf – настройки работы с mysql (к этому файлу я еще вернусь).

n  users – а вот этот файл очень важен для последующего изложения, он описывает пользователей. Описание пользователей аналогично livingston-radius:

user    Auth-Type := Local, User-Password == "testing"

Service-Type = Framed-User,

Framed-Protocol = PPP,

Framed-IP-Address = 172.16.3.33,

Framed-IP-Netmask = 255.255.255.0,

Framed-Routing = Broadcast-Listen,

Framed-MTU = 1500,

Framed-Compression = Van-Jacobsen-TCP-IP

    но есть и отличие: использование специальных операторов присваивания и сравнения (в linvingston был только один «=»). Приведу список «новых» операторов:

Атрибут посылается NAS, его значение равно Value:

«Attribute = Value»

Если данный атрибут не определён, то он принимает указанное значение:

«Attribute := Value»

Используется только для проверки значения атрибута:

«Attribute == Value»

Добавление нового значения атрибуту:

Различные операции сравнения:

«Attribute += Value»

«Attribute != Value»

«Attribute > Value»

«Attribute >= Value»

«Attribute < Value»

«Attribute <= Value»

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

«Attribute =~ Expression»

«Attribute !~ Expression»

Проверка, содержит ли запрос данный атрибут, значение не играет роли:

«Attribute =* Value»

«Attribute !* Value»

Однако если вы намереваетесь работать с большим числом пользователей, то файл users не подойдет (он целиком помещается в память). В качестве альтернативы можно взять сервера LDAP или MySQL (PostgreSQL, Oracle). LDAP, на мой взгляд, несколько практичнее, но я прекрасно понимаю, что MySQL распространён намного больше, поэтому о его использовании я и поведу речь.

Для начала устанавливаем mysql (этот процесс я не описываю). Обязательно устанавливаем (если работаем с пакетами) пакет mysql-dev. После этого перекомпилируем radius (configure скрипт сам обнаружит mysql и включит в makefile нужный модуль). После этого создаём базу в mysql:

$mysql -uroot -proot_passwd

mysql> create database radius

После этого выполняем mysql-сценарий для создания таблиц в базе. Для этого заходим в каталог модуля mysql:

$cd {PATH_TO_RADIUS_SRC}/src/modules/rlm_sql/drivers rlm_sql_mysql

и передаём mysql-сценарий:

$mysql -uroot -proot_passwd radius < db_mysql.sql

База состоит из 5-и таблиц:

n  Usergroup – данные о группах пользователей, например:

mysql> select * from usergroup;

2 rows in set (0.00 sec)

n  Radcheck – AV-пары для проверки пользователя (обычно пароль), например:

2 rows in set (0.02 sec)

n  Radgroupcheck – проверка атрибутов для группы (не знаю, зачем это нужно).

n  Radreply – таблица, содержащая AV-пары, передающиеся клиенту сервером при прохождении аутентификации, например:

mysql> select * from radreply;

6 rows in set (0.01 sec)

n  Radgroupreply – AV-пары, содержащиеся в ответе сервера для данной группы, например:

mysql> select * from radgroupreply;