Аутентификация удаленных и мобильных пользователей

Изначально концепция RADIUS состояла в обеспечении удаленного доступа через коммутируемое телефонное соединение. Со временем выявились и другие области применения этой технологии. К ним относятся серверы виртуальных частных сетей (Virtual Private Network, VPN) — они в большинстве своем поддерживают Rаdius, — а также точки доступа беспроводных локальных сетей (Wireless LAN, WLAN), и это далеко не все.

Концепция службы идентификации удаленных пользователей подразумевает, что клиент RADIUS — обычно сервер доступа, сервер VPN или точка доступа беспроводной локальной сети — отсылает серверу RADIUS параметры доступа пользователя (в англоязычной документации они часто называются Credentials, т. е. мандат, куда, к примеру, входят его настройки безопасности и права доступа), а также параметры соответствующего соединения. Для этого клиент использует специальный формат, так называемый RADIUS-Message (сообщение RADIUS). В ответ сервер начинает проверку, в ходе которой он аутентифицирует и авторизует запрос клиента RADIUS, а затем пересылает ему ответ — RADIUS-Message-response. После этого клиент передает на сервер RADIUS учетную информацию.

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

Сами по себе сообщения RADIUS передаются в форме пакетов UDP. Причем информация об аутентификации направляется на порт UDP с номером 1812. Некоторые серверы доступа используют, однако, порты 1645 (для сообщений об аутентификации) или, соответственно, 1646 (для учета) — выбор должен определять своим решением администратор. В поле данных пакета UDP (так называемая полезная нагрузка) всегда помещается только одно сообщение RADIUS. Определены следующие типы сообщений:

• Access-Request - "запрос доступа". Запрос клиента RADIUS, с которого начинается собственно аутентификация и авторизация попытки доступа в сеть;
• Access-Accept - "доступ разрешен". С помощью этого ответа на запрос доступа клиенту RADIUS сообщается, что попытка соединения была успешно аутентифицирована и авторизована;
• Access-Reject - "доступ не разрешен". Этот ответ сервера RADIUS означает, что попытка доступа к сети не удалась. Такое возможно в том случае, если пользовательских данных недостаточно для успешной аутентификации или доступ для пользователя не авторизован;
• Access-Challenge - "вызов запроса". Сервер RADIUS передает его в ответ на запрос доступа;
• Accounting-Request - "запрос учета", который клиент RADIUS отсылает для ввода учетной информации после получения разрешения на доступ;
• Accounting-Response - "ответ учета". Таким образом сервер RADIUS реагирует на запрос учета и подтверждает факт обработки запроса учета.

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

Для шифрования пароля пользователя и прочих атрибутов применяются алгоритм хэширования MD5 или симметричный Triple DES. При этом рекомендуется как можно лучше позаботиться о надежности передачи, например, применять сетевой протокол IPSec.

Если же совместная работа IPSec и алгоритма шифрования невозможна, у администратора сети остается еще один способ уменьшения вероятности взлома выполненной реализации RADIUS:

• применение атрибутов аутентификации должно быть обязательным для всех сообщений с запросом доступа;
• в качестве удостоверений запросов необходимо использовать криптологически сильные величины;
• к использованию должны допускаться только трудно угадываемые пользовательские пароли;
• для предотвращения атак с перебором по словарю предпочтителен механизм "учета и блокировки аутентификации";

СИСТЕМА S/KEY (Bellcore)

Эта система базируется на принципе генерации одноразовых паролей, которые обладают большей устойчивостью к пассивному прослушиванию КС, чем традиционные многоразовые пароли.

Пусть имеется односторонняя функция h (то есть функция, вычислить обратную которой за приемлемое время не представляется возможным). Эта функция известна и пользователю, и серверу аутентификации. Пусть имеется секретный ключ K, известный пользователю и серверу аутентификации.

На этапе начального администрирования пользователя функция h применяется к ключу K n раз, полученный результат сохраняется на сервере, сам ключ далее на сервере не хранится (он нужен только один раз для регистрации пользователя). После этого процедура проверки подлинности пользователя выглядит следующим образом:

• сервер присылает на пользовательскую систему число (n-1) и некоторое стартовое значение для функции h;
• пользователь применяет функцию h к секретному ключу K (n-1) раз и отправляет результат по сети на сервер аутентификации;
• сервер применяет функцию h к полученному от пользователя значению и сравнивает результат с ранее сохраненной величиной. В случае совпадения подлинность пользователя считается установленной, сервер запоминает новое значение (присланное пользователем) и уменьшает на единицу счетчик (n).

Поскольку функция h необратима, перехват пароля, равно как и получение доступа к серверу аутентификации, не позволяют узнать секретный ключ K и предсказать следующий одноразовый пароль. Система S/KEY имеет статус Internet-стандарта.

Пароль на сеанс. Другой подход к надежной аутентификации состоит в генерации нового пароля через небольшой промежуток времени (например, каждые 60 секунд), для чего могут использоваться программы или специальные smart-карты, или e-token (с практической точки зрения такие пароли можно считать одноразовыми). Серверу аутентификации должен быть известен алгоритм генерации паролей и ассоциированные с ним параметры; кроме того, часы клиента и сервера должны быть синхронизированы.

Идея одноразового пароля заключается в том, что токен-код рассчитывается при помощи генератора псевдослучайных чисел, поэтому предсказать следующее значение по текущему невозможно. Такой пароль нельзя ввести дважды, и даже если его подглядели из-за плеча — в следующий раз войти в систему с этим паролем не удастся. При первоначальном подключении пользователь вводит имя, PIN-код и цифры с экрана токена. Эти шесть цифр меняются раз в минуту. Вертикальный столбец в левой части жидкокристаллического экрана показывает, сколько времени осталось до генерации очередного пароля.

Процедура аутентификации происходит следующим образом. При попытке зайти на защищенный ресурс запрос перехватывается установленным на нем агентом. Пользователю предлагается ввести свой идентификатор (UID, login). В качестве пароля вводится комбинация из PIN-кода и числа, которое в данный момент отображается в окне токена. Эти данные отсылаются агентом на сервер аутентификации и там проверяются. Генерация токен-кода производится на основании текущего времени (таймер встроен в брелок или карту) и стартового вектора генерации (seed), который был записан в брелок на стадии его производства. PIN-коды зарегистрированных пользователей, а также векторы генерации хранятся в базе сервера аутентификации. Таким образом, зная исходный вектор и текущее значение времени, cервер может восстановить значение токен-кода и, соответственно, пароля. Результаты проверки отсылаются агенту, после чего он принимает решение о допуске.

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

Обмен данными м/д сервером и агентом происходит по специальному системному протоколу, применение которого обеспечивает защиту и гарантирует целостность передаваемых данных. Один токен может содержать до 5 векторов инициализации.

Работа с таким устройством удобна тем, что не требуется физический контакт токена с сервером или любым другим устройством аутентификации. Утерянный ключ всегда можно заблокировать.

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

Защитные механизмы в условиях удаленного доступа

1. Технология аутентификации пользователей Kerberos