Радиус в центре
Протокол RADIUS часто используется в различных сетевых устройствах (маршрутизаторы, модемные стойки, коммутаторы и т.д.) для аутентификации пользователей. Основной причиной этого является то, что сетевые устройства имеют обычно очень ограниченные аппаратные ресурсы и не могут хранить в памяти информацию о большом числе пользователей.
Протокол RADIUS обеспечивает централизованное управление пользователями, что очень важно в целом ряде случаев. Например, интернетпровайдеры могут иметь десятки и даже сотни тысяч пользователей, и разместить такой объем информации в памяти любого сетевого устройства просто невозможно. При этом число пользователей может постоянно варьироваться в течение суток, дня или часа. Именно поэтому необходимо иметь централизованную базу данных, где хранится информация обо всех пользователях. Следует отметить, что протокол RADIUS поддерживается практически всеми производителями сетевого оборудования, в то время как другие протоколы аутентификации удаленных пользователей не получили массовой поддержки со стороны производителей.
Протокол RADIUS также имеет встроенные механизмы защиты от целого ряда сетевых атак, включая использование сетевых сниферов для получения паролей пользователей. Основными соперниками RADIUS на поле удаленной аутентификации являются протоколы TACACS+ и LDAP. Протокол LDAP изначально не имеет никаких средств защиты от снифинга паролей, и хотя в протоколе TACACS+ (в отличие от RADIUS) шифруется весь трафик, а не только пользовательские пароли, он также не лишен ряда слабых сторон.
Формат RADIUS*сообщения
Структура сообщения протокола RADIUS представлена на рис.(RFC 2138), а значения и расшифровка поля Сode – в таблице под рисунком.
Поле Identifier длиной один байт устанавливается RADIUS-клиентом в ответ на запрос RADIUS-сервера. Поле атрибутов содержит имя пользователя и пароль и также позволяет передавать дополнительные данные о клиенте от RADIUS-сервера сетевым устройствам, к которым непосредственно подключены пользователи.
А теперь поговорим об основных режимах функционирования протокола RADIUS: о запросе доступа (Access-Request), в котором передается пароль и имя пользователя, после чего он сопровождается передачей сообщений разрешения или отказа в доступе (Access-Accept, Access-Reject). Далее для удобства будем называть стороны, участвующие в процессе аутентификации, "клиент" и "сервер". Сервер содержит базу данных пользователей и проводит их аутентификацию.
Для прохождения аутентификации на сервере клиент создает запрос доступа (Access-Request) и передает его RADIUS-серверу, поле атрибутов данного сообщения должно включать как минимум имя пользователя и пароль. Поле идентификации запроса доступа также создается клиентом. Этот процесс не регламентируется в самом протоколе RADIUS, но обычно поле реализуется как простой счетчик, который увеличивается на 1 при каждом новом запросе. Запрос доступа содержит 16-байтное поле запроса аутентификатора (Request Authenticator), которое генерируется случайным образом. Данное сообщение в целом не защищено, шифруются только поля атрибутов, содержащие имя пользователя и пароль. Для этого клиент и сервер имеют общий секрет. Общий секрет совместно с полем запроса аутентификатора используется для вычисления 16-байтного значения (с помощью хэш-функции MD5), которое затем благодаря логидиняется с паролем пользователя.
После получения сообщения запроса доступа RADIUS-сервер проверяет, обладает ли он общим секретом с клиентом, и если нет, то сообщение просто сбрасывается без уведомления клиента. Поскольку сервер также обладает общим секретом с клиентом, он может вычислить незашифрованное имя и пароль клиента (через процедуру, обратную описанной выше). Затем имя и пароль сверяются с пользовательской базой данных.
В случае успешной проверки имени и пароля пользователя сервер создает сообщение разрешения доступа и передает его пользователю, в обратном случае он получает сообщение об отказе в доступе. Оба сообщения имеют одинаковые номера идентификаторов, равные номеру идентификатора в запросе доступа клиента.Поле ответа аутентификатора (Response Authenticator) вычисляется с помощью применения хэш-функции MD5 над полями запроса аутентификатора и полями пакета разрешения доступа.
Добавляем пользователей в Active Directory
Когда клиент получает сообщение-ответ от сервера, он проверяет, отсылал ли ранее запрос с номером идентификатора, который указан в сообщении, и если нет, то оно просто сбрасывается. Далее клиент декодирует поле ответа аутентификатора с помощью процедуры, обратной вышеописанной, и сравнивает полученный результат с полем аутентификатора в поле запроса. Это гарантирует взаимную проверку клиента и сервера и делает практически невозможными хакерские атаки, основанные на подмене сервера.
А теперь стоит подробнее рассказать о практической реализации схемы сетевой аутентификации 802.1X.
