Протоколы RADIUS и TACACS+: сравнение и принципы функционирования
Вся статья делится на две глобальные части: Первые часть написана в
1999 году, и содержат информацию по протоколам и их реализациям на тот
период с небольшими модификациями, сделанными недавно. Вторая часть
свежая и содержит информацию о конкретных реализациях RADIUS модулей,
входящего в комплект системы LANBilling, которых на сегодняшний день 2
- активный и пассивный.
Для начала необходимо определиться, что это за протоколы, для чего они
нужны (кто не знает). Все, кто знает, о чём пойдет речь, могут смело
пропустить несколько следующих абзацев.
Данные протоколы используются для обмена информацией между Network
Access Server'ом (NAS) и 3A (Authentication, Authorization,
Accounting) сервером. Далее NAS я часто буду назвать клиентом,
поскольку NAS является клиентом по отношению к 3A-серверу. Собственно,
в общем случае у 3А-сервера несколько клиентов. Пользователем по
тексту я буду называть нечто, запрашивающее доступ к некому ресурсу у
клиента. Не понятно?
Поясню на рисунке: http://lanbilling.ru/images/radius/user_client_3a.gif
Для начала необходимо определиться с понятиями, я их постараюсь
объяснить попонятнее (как когда-то объяснили мне), без всяких там
"формул" и т.д, а на обыкновенном человеческом языке.
Аутентификация (Authentication) - процесс проверки имени пользователя
и пароля. Жизненный пример: приходит в охраняемое здание некий Вася и
показывает охране свой паспорт - вот он я, вот паспорт, вот фотография
на паспорте. Все сходится ?
Авторизация (Authorization) - процесс проверки пользователя на предмет
возможности использования какого-либо ресурса. Ну то есть: ты конечно
Вася и паспорт с фотографией у тебя в порядке, да вот только вот в
этот кабинет тебе вход разрешен, а вот в этот - нет.
Эккаунтинг (Accounting) - процесс учета используемого сервиса: вошел
наш Вася в какую-то комнату - сделал заметку в книге учета (вошел Вася
в такое-то время), вышел - опять оставил пометку (Вася вышел в
такое-то время).
Итак вернемся к рисунку: на этом рисунке Вася является пользователем,
охрана - NAS (клиентом к 3A-серверу), а сам 3А-сервер - это некое
хранилище информации о всех пользователях (кто есть кто и сколько чего
кому разрешено). На практике обычно это выглядит так:
1. Пользователь Mokromax дозванивается до своего провайдера услуг
(как правило, NAS'ы фирмы CISCO или Lucent) и вводит свой пароль.
2. В этот момент NAS формирует и посылает запрос аутентификации к
3A-серверу, далее ожидает ответа.
3. 3А-сервер получает запрос, лезет в какое-либо хранилище данных
(хранилищем может быть все, что угодно - Oracle, MS SQL, MySQL,
просто таблица или другое хранилище) и проверяет имя пользователя
и пароль.
4. 3A-сервер формирует и посылается ответ NAS'у.
5. NAS принимает ответ и пропускает пользователя (устанавливает с ним
связь) или нет (разрывает соединение).
Пункты 2-5 как раз и являются процессом аутентификации. Давайте
предположим, что пользователь прошел аутентификацию успешно.
6. Пользователь Mokromax хочет попользоваться услугой доступа к
Интернету.
7. В этот момент NAS формирует и посылает запрос авторизации к
3A-серверу, далее ожидает ответа.
8. 3А-сервер получает запрос, опять лезет в какое-либо хранилище
данных и проверяет возможность пользователя пользоваться данным
ресурсом, а также устанавливает количество сервиса, которое
доступно пользователю (Mokromax может пользоваться Интернетом еще
33 минуты).
9. 3A-сервер формирует и посылается ответ NAS'у.
10. NAS подключает пользователя к ресурсу (к Интеренту) и запускает
таймер (через 33 минуты пользователь будет принудительно
отключен).
Пункты 7-10 являются процессом авторизации.
11. В момент начала пользования ресурсом 3A-сервер информируется
NAS'ом об этом.
12. 3A-сервер подтверждает прием данной учетной информации.
13. В момент окончания пользования ресурсом 3A-сервер также
информируется NAS'ом об этом. При этом NAS указывает количество
потребленного сервиса.
14. 3А-сервер предпринимает какие-либо действия связанные с учетом
потребленного сервиса (Mokromax пользовался Интернетом 16 минут,
остаток: 33-16=17 минут).
15. 3A-сервер подтверждает прием данной учетной информации.
Пункты 11-15 являются процессом эккаунтинга.
Причем возможна настройка клиентов, при которых они не будут отсылать
пакеты о начале пользования сервисом или ресурсом - иногда это бывает
удобно. Так вот, как я говорил раньше, описываемые ниже протоколы
используются для обмена информацией NAS и 3А-сервером. Чем же эти
протоколы так хороши?
Прежде всего, эти протоколы предоставляют возможность шифрования
(пароля в случае с RADIUS'ом или всего пакета в случае с TACACS+),
надежной передачи информации (квитирование), а так же оптимизированы
для передачи именно 3A-информации.
RADIUS (Remote Authentication Dial In User Service)
Полное описание данного протокола находиться в RFC-2138 и RFC-2139
которые можно найти [31]здесь (http://www.ietf.org). Это протокол (в
отличие от TACACS+) был разработан независимой группой разработчиков
(на данный момент протокол не модифицируется) и поэтому получил
широкое распространение у сторонних разработчиков. Как правило, все
производители программных и аппаратных клиентов поддерживают данный
протокол. Кратко о протоколе можно сказать следующее: использует в
своей основе протокол UDP (а поэтому относительно быстр), процесс
авторизации происходит в контексте процесса аутентификации (т.е.
авторизация как таковая отсутствует), реализация RADIUS-сервера
ориентирована на однопроцессное обслуживание клиентов (хотя возможно и
многопроцессное - вопрос до сих пор открытый), поддерживает довольно
ограниченное число типов аутентификации (Clear text и CHAP), имеет
среднюю степень защищености.
TACACS+
Данный протокол является разработкой фирмы Cisco Systems и его
реализация периодически модифицируется. Данный протокол является новым
витком развития более ранних версий протоколов TACACS и XTACACS: хоть
в официальных выпусках и говорится, что всего-то повышена безопасность
протокола, но реально весь протокол технически был переписан заново
(осталась разве только идеология), поэтому не путайте между собой эти
протоколы (в повседневной жизни и в описаниях очень часто оконечный
"+" опускают, откуда и появляется неразбериха; более старый протокол
TACACS практически никто сейчас не использует, поэтому если вы видите
ссылку на протокол TACACS скорее всего кто-то проигнорировал "+" и
речь идет о TACACS+). Протокол основан на использовании протокола TCP,
поэтому потенциально медленнее RADIUS'а (все-таки установление TCP
соединения довольно накладная операция), но за то позволяет вести
мультипроцессную обработку запросов (в каждый момент времени могут
обслуживаться несколько пользователей). Степень защищености - высокая
(зашифровано все тело пакета).
А теперь хотелось бы поподробнее сравнить возможности обоих
протоколов.
Безопасность: Шифруется пароль Шифруется все тело пакета
Поддерживаемые типы
аутентификации: Clear text (ASCII,PAP) Clear text (ASCII, PAP)
CHAP CHAP, ARAP
Возможность перенаправления
запроса: Есть Нет
Базовый протокол
RADIUS базируется на протоколе UDP (пакетная передача данных, без
гарантии передачи пакета). Отсюда сразу вытекает тот факт, что
RADIUS-клиент на любой запрос должен дожидаться ответа от сервера в
течении некоторого времени (timeout'а) и при в случае отсутствии оного
перепослать пакет еще раз. Собственно TACACS+ клиент тоже должен
дожидаться всегда ответа от сервера, да вот только гарантией передачи
пакета он не озабочен. Зато у TACACS+ имеет место другой момент: для
обработки какого-либо запроса TACACS+ сервер и клиент должны
установить TCP-соединение (даже если весь процесс будет состоять из
посылки и приема 2-ух небольших пакетов !), а с точки зрения времени
это довольно накладный процесс (кстати именно поэтому TACACS+ по
определению относительно медленен). На основе приведенного примера,
можно сразу сказать, что RADIUS будет более эффективен в сетях, где
процент потерянных пакетов менее 5-10 %; в других сетях лучше
использовать TACACS+.
Поддерживаемые сервисы
Протокол RADIUS не поддерживает авторизацию. То есть RADIUS есть смысл
использовать только там, где заранее известно какой сервис
предоставляет конкретный RADIUS-клиент. У TACACS+ заложена поддержка
авторизации, да вот только количество авторизуемых сервисов тоже
довольно ограничено в текущей версии (правда есть возможность
расширения): "slip", "ppp", "arap", "shell", "tty-daemon",
"connection", "system" и "firewall". То есть вот как получается: для
доступа к какому-либо сервису RADIUS обрабатывает один запрос
(аутентификацию - запрос, ответ), а TACACS+ - два (аутентификацию и
авторизацию), но при этом при использовании TACACS+ есть возможность
получить доступ к другому сервису.
Безопасность
Здесь первым делом надо отметить, что в данной концепции
ПОДРАЗУМЕВАЕТСЯ, что 3А-сервис доверяет клиенту, иначе все выкладки не
имеют смысла. Следовательно, при написании любого 3A-сервера (будь то
TACACS+ или RADIUS) нужно учитывать и проверять каждый приходящий
запрос на состоятельность (то есть каждый 3А сервер должен иметь в
своем распоряжении таблицу IP-адресов известных клиентов). И в
TACACS+, и в RADIUS протоколе есть такое понятие как разделяемый
секрет (shared secret): это последовательность символов (обычно
печатных) произвольной длины, которая используются и клиентом и
сервером для шифрования пакетов или паролей. Следовательно, в данную
таблицу добавляются еще разделяемые секреты для каждого состоятельного
клиента.
Протокол TACACS+ не допускает наличия брэндмауэра между клиентом и
сервером в принципе. Дело все в том, что найти соответствующий
разделяемый секрет для обработки пришедшего запроса можно только по
IP-адресу клиента, а при работе через брэндмауер запрос будет
приходить всегда с IP брэндмэура. RADIUS - другое дело. Там IP адрес
клиента содержится еще и в самом пакете, поэтому какой адрес
использовать 3А серверу (реальный или внутрипакетный) для поиска
разделяемого секрета решать вам, но возможность работы через
брэндмауэр есть.
Теперь насчет шифрования: в RADIUS'е шифруется только Clear Text
пароли, весь остальной пакет остается "открытым" (с точки зрения
безопасности даже имя пользователя является очень важным параметром).
В TACACS+ открытым является только заголовок пакета (не несущий
никакой ценной информации), а все тело зашифровано. Но у TACACS+, как
мне кажется, так же есть одна небольшая "дырочка". Состоит она в
следующем: TACACS+ поддерживает авторизацию, называемую в документации
outbound (т.е. внешняя), то есть само решение аутентифицировать
пользователя или нет, принимает клиент. При этом TACACS+ сервер должен
прислать клиенту пароль (в том числе есть возможность запроса у
сервера Clear Text пароля), а клиент будет сравнивать этот пароль с
введенным пользователем. Вот и получается , что если выполняются
следующие условия:
1. TACACS+ сервер поддерживает эту опцию
2. TACACS+ сервер не проверяет исходящие адрес приходящих запросов (а
даже если и проверяет, IP адреса могут быть поддельными)
3. Серьезный хакер (в оригинале кулхацкер) пронюхал разделяемый
секрет (что возможно, поскольку он лежит в открытом виде и на
сервере и на клиенте)
4. Тот же серьезный хакер пронюхал некоторое кол-во имен
пользователей (что в принципе не сложно)
То, этот самый недобросовестный взломщик может элементарно узнать
пароли из TACACS+ сервера. Как с этим бороться пусть каждый решает сам
(я советую просто не поддерживать данный тип авторизации, поскольку
такая возможность по определению является небезопасной - отдавать
пароли из базы "наружу" !).
Поддерживаемые типы аутентификации
В этом смысле TACACS+ поддерживает на один тип больше RADIUS'а. Ну с
Clear Text аутентификацией все ясно - пароль он и есть пароль, а CHAP
и ARAP? Кто не понимает идеи этих типов аутентификации объясню: идея в
том, что бы Clear Text пароль ни в каком виде никогда не передавался
бы через сеть. А именно: при аутентификации пользователя клиент
посылает пользовательской машине некий Challenge (произвольная
случайная последовательность символов), пользователь вводит пароль и с
этим Challengе'ем пользовательская машина производит некие шифрующий
действия используя введенный пароль (как правило это обыкновенное
шифрование по алгоритму MD5 - RFC-1321). Получается Response. Этот
Response отправляется назад клиенту, а клиент все в совокупности
(Challenge и Response) отправляет на аутентификацию 3A-серверу. Тот
(так же имея на своей стороне пользовательский пароль) производит те
же самые действия с Challeng'ем и сравнивает свой Response с
полученным от клиента: сходиться - пользователь аутентифицирован, нет
- извиняйте. Таким образом, Clear Text пароль знают только сам
пользователь и 3А-сервер и пароль открытым текстом не "ходит" через
сеть и не может быть взломан.
Возможность перенаправления запроса
В TACACS+ такая возможность просто отсутствует. RADIUS-протокол же
имеет такую возможность: RADIUS-сервер должен уметь перенаправлять
запрос к другому RADIUS-серверу. Если вдуматься возможность очень
полезная: предположим, что мы продаем Интернет или услуги телефонной
связи через Интернет (VoIP) и наша единая система имеет представителей
в регионах. Купил Петя у нас карточку в городе Саратове и поехал с ней
в город Тулу (где так же есть наши представители). Хочет он в Туле
воспользоваться нашим сервисом и набирает номер, а потом свое имя и
пароль (если это доступ к Интернет) или просто несколько цифр кода
(если это VoIP). Местный Тулький RADIUS-сервер смотрит на введенные
значения и понимает: - "пользователь-то наш, да вот только я о нем
ничего не знаю, спрошу как я у того кто знает" - и перенаправляет
запрос к Саратовскому RADIUS-серверу. Тот аутентифицирует нашего Петю,
ну и далее обратный путь пакета и поведение Тульского сервера понятно.
Таким образом RADIUS позволяет проектировать гибкую распределенную
систему.
LANBilling RADIUS модуль : особенности
В терминах системы LANBilling RADIUS модуль является сетевым агентом,
отвечающим за сбор статистики об использовании IP услуг. Однако помимо
функций сбора статистики модуль выполняет функции контроля доступа
dialup клиентов к услуге. В этом основное отличие RADIUS модуля от
остальных агентов LANBilling. Так же есть усеченная версия модуля,
которая не предоставляет контроля доступа, а занимается только сбором
статистики о трафике клиентов по объему и времени.
Принимая во внимание понятия, освещенные в начале статьи, LANBilling
RADIUS модуль является 3А - сервером для любых NAS ов (Network Access
Server), поддерживающих протокол RADIUS. Тестирование модуля
проводилось на трех 3А клиентах - Cisco 3640, Lucent MAX 6000 и на
программном NAS (PPPD), осуществляющем работу по протоколу PPP с
модемами, подключенными к маршрутизатору, на базе
Linux/FreeBSD/Solaris.
Фактически RADIUS модуль повторяет схему взаимодействия, изложенную в
начале статьи. Однако, специфика системы накладывает ряд особенностей
на алгоритм работы модуля. В частности на этапе вычисления таймаута
dialup пользователя для 3A клиента происходит оценка возможности
использования скидок данным пользователем по присвоенному тарифу.
Иными словами, в момент аутентификации пользователя таймаут
вычисляется уже с учетом того, что в случае непрерывного "сидения" на
линии пользователя он в определенные моменты будет использовать услугу
с учетом льгот указанных в настройке скидок для присвоенного ему
тарифа. Модуль способен работать с несколькими 3А клиентами.
Для каждого из них требуется задать IP адрес, с которого будет
работать NAS. А также разделяемый секрет (shared secret) который будет
использоваться модулем для аутентификации NASов, во избежание
обработки запросов на аутентификацию от "незнакомых" клиентов. Ниже
приведен пример конфигурирования сетевого агента типа RADIUS.
Vova
