Ключевые слова:aaa, radius, tacacs, (найти похожие документы)
From: Vlad B. Pinzhenin <vlad@lanbilling.ru>
Newsgroups: fido7.ru.unix
Date: Mon, 4 Dec 2000 13:01:37 +0000 (UTC)
Subject: Протоколы RADIUS и TACACS+: сравнение и принципы функционирования
Оригинал статьи: http://lanbilling.ru/radius_tacacs.html
Протоколы 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
соединения довольно накладная операция), но за то позволяет вести
мультипроцессную обработку запросов (в каждый момент времени могут
обслуживаться несколько пользователей). Степень защищености - высокая
(зашифровано все тело пакета).
А теперь хотелось бы поподробнее сравнить возможности обоих
протоколов.
Для начала таблица:
RADIUS TACACS+
Базовый протокол: UDP TCP
Поддерживаемые сервисы: Authentication Authentication
Accounting Authorization
Accounting
Безопасность: Шифруется пароль Шифруется все тело пакета
Поддерживаемые типы
аутентификации: 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.
(с) Сетевые решения, 2003
Максим Мокроусов
Владислав Пинженин
Уважаемые авторы! Я - метролог, а не специалист по сетевым решениям. Мне очень помогла ваша статья,написанная действительно человеческим языком. Буду рад, если вы ответите на вопрос о правовых основах (нормах)использования того или иного протокола на сети. Эти (да и другие) протоколы подлежат сертификации в Минсвязи или есть конкретное решение Минсвязи о допустимости использования протоколов?
С уважением А.Титов
