Аутентификация и хранение учетных записей
Аутентификация RADIUS
Последовательность пакетов
Пользователь предоставляет NAS аутентификационную информацию, после этого NAS использует протокол RADIUS для аутентификации данного пользователя. Эта аутентификационная информация может предоставляться в виде настраиваемого приглашения для входа, когда от пользователя требуется ввести имя и пароль. Либо может использовать такой протокол, как РРР, в котором существуют аутентификационные пакеты для пересылки данной информации.
После того, как NAS получил эту информацию, он может выполнить аутентификацию пользователя на сервере RADIUS. Для того чтобы сделать это, NAS создает запрос Access-Request, содержащий в качестве атрибутов имя пользователя, пароль, идентификатор и тип порта NAS, к которому пользователь хочет получить доступ. Если присутствует пароль, то используется метод его скрытия, основанный на алгоритме хэширования MD5.
Рис. 12.10. Пересылка аутентификационных данных пользователя по туннелю между NAS и противоположной стороной туннеля
Атрибуты RADIUS используются для передачи аутентификационной и авторизационной информации и деталей конфигурирования.
Некоторые атрибуты могут быть включены в сообщение несколько раз. Результат такого включения зависит от атрибута.
Если есть несколько атрибутов одного и того же типа, то прокси-серверы не должны изменять их упорядоченность. Порядок атрибутов разных типов прокси-серверами может быть изменен. Поведение RADIUS-сервера и клиента никак не зависит от упорядоченности атрибутов разных типов. Не требуется, чтобы атрибуты одного и того же типа были расположены рядом друг с другом.
Access-Request передается по сети серверу RADIUS. Если в течение определенного времени ответ не получен, то запрос повторяется. Клиент может также направить запросы к альтернативному серверу или нескольким серверам в случае, если первичный сервер выключен или не доступен. Альтернативный сервер может использоваться либо после определенного числа неудачных попыток обращения к первичному серверу, либо по круговому алгоритму.
После получения запроса сервер RADIUS выполняет аутентификацию NAS. Запрос от NAS, с которым сервер RADIUS не имеет разделяемого секрета, молча, т.е. без уведомления противоположной стороны, отбрасывается.
Если NAS аутентифицирован, RADIUS-сервер ищет в базе данных пользователей имя, указанное в запросе. Запись пользователя в базе данных содержит список требований, которые должны быть выполнены, чтобы пользователю можно было разрешить доступ. Это всегда включает проверку пароля, но можно также определить дополнительные параметры, которые проверяются перед тем, как пользователю будет разрешен доступ.
Сервер RADIUS может сделать запросы к другим серверам, чтобы обработать данный запрос. В этом случае он является прокси и действует как клиент по отношению к другому серверу RADIUS.
Если в запросе Access-Request есть какие-либо атрибуты Proxy-State, они должны быть скопированы без каких-либо изменений и в том же порядке в пакет ответа. Остальные атрибуты могут быть расположены до, после и даже между Proxy-State атрибутами.
Если какое-либо из условий не выполнено, сервер RADIUS посылает Access-Reject ответ, который говорит о том, что аутентификация не выполнена и запрос пользователя на вход отвергается. Сервер может также включить в Access-Reject текстовое сообщение, которое будет показано пользователю. Никаких других атрибутов, за исключением Proxy-State, в Access-Reject не передается.
Рис. 12.13. Пример сообщения Access-Reject при отсутствии у пользователя или NAS требуемых аутентификационных данных
Если все условия выполнены, и RADIUS-серверу требуется получить дополнительные ответы от пользователя, RADIUS-сервер посылает Access-Challenge ответ. Он может включить текстовое сообщение, которое будет показано пользователю, и может включать атрибут State.
Если NAS получил Access-Challenge и поддерживает Запрос / Ответ, он может показать текстовое сообщение, если оно есть, и затем выдать приглашение пользователю для ввода ответа. Затем клиент передает свой исходный Access-Request с новым ID запроса и с атрибутом User-Password и атрибутом State из Access-Challenge, если они были там указаны.
В ответе не может быть больше одного экземпляра атрибута State. На это сообщение сервер может ответить новым Access-Request, указав в нем либо Access-Request, либо Access-Reject, либо другой Access-Challenge.
Если все условия выполнены, в ответ Access-Request помещается список конфигурационных значений. Эти значения включают тип сервиса (например, SLIP, PPP, Login User) и все необходимые значения для получения требуемого сервиса. Для SLIP и РРР это может включать такие значения, как IP-адрес, маска подсети, MTU, алгоритм сжатия и идентификаторы требуемых фильтров пакетов. Могут быть также указаны требуемый протокол и хост.
Вызов / Ответ
При аутентификации Вызов/Ответ (Challenge/Response) пользователь получает заранее неизвестное число запросов, на которые он должен дать ответ. Для создания корректного ответа пользователь должен иметь либо специальные устройства, такие как смарт-карты, либо ПО, которое создает ответ. Если у пользователя нет соответствующего устройства или в ПО не установлено корректное значение секрета, пользователь считается неавторизованным.
Пакет Access-Challenge обычно содержит Reply-Message, которое показывается пользователю, например, числовое значение, которое никогда не повторяется.
Затем пользователь вводит это случайное число в смарт-карту или программу, которая вычисляет ответ. Пользователь вводит этот ответ, и NAS пересылает его на сервер RADIUS во втором Access-Request. Если ответ правильный, сервер RADIUS возвращает Access-Request, в противном случае возвращает Access-Reject.
Пример:
NAS посылает пакет Access-Request к серверу RADIUS с атрибутами NAS-Identifier, NAS-Port, User-Name, User-Password (который может быть фиксированной строкой типа "challenge" и игнорироваться). Сервер посылает обратно пакет Access-Challenge с атрибутами State, Reply-Message и строкой "Challenge 12345678, введите ваш ответ", которую NAS показывает пользователю. NAS выдает приглашение пользователю для ответа и посылает полученный ответ в новом пакете Access-Request к серверу (с новым ID), содержащий атрибуты NAS-Identifier, NAS-Port, User-Name, User-Password. В этом случае ответ, который только что ввел пользователь, защищен. Этот ответ содержит тот же самый атрибут State, который был указан в Access-Challenge. После этого сервер присылает обратно либо пакет Access-Request, либо пакет Access-Reject.
Интероперабельность с РАР и СНАР
При использовании РАР NAS получает РАР ID и пароль и посылает их в пакете Access-Request в качестве атрибутов User-Name и User-Password. NAS может включить атрибуты Service-Type = Framed-User и Framed-Protocol=PPP в качестве подсказки серверу RADIUS, что используется РРР-сервис.
При использовании СНАР NAS создает случайный вызов (желательно 16 октетов) и посылает его пользователю, который возвращает СНАР-ответ вместе с атрибутами CHAP ID и СНАР Username. Затем NAS посылает пакет Access-Request к серверу RADIUS со значением СНАР Username в атрибуте User-Name и со значением СНАР ID и СНАР-ответом в атрибуте CHAP-Password. Случайный вызов либо может быть включен в атрибут CHAP-Challenge, либо, если его длина больше 16 октетов, он может быть помещен в поле Request Authenticator в пакете Access-Request. NAS может включить атрибуты Service-Type = Framed-User и Framed-Protocol = PPP в качестве подсказки серверу RADIUS, что используется РРР-сервис.
Если сервер RADIUS не может выполнить необходимую проверку, он возвращает Access-Reject. Например, при использовании СНАР требуется, чтобы пароль пользователя был доступен серверу в незашифрованном виде для того, чтобы он мог хэшировать его вместе с вызовом и сравнить с тем, что получил в качестве СНАР-ответа. Если пароль не доступен серверу RADIUS в незашифрованном виде, то он посылает клиенту Access-Reject.
Использование прокси-сервера
При использовании RADIUS-прокси один RADIUS-сервер получает запрос на аутентификацию (или аккаунтинг) от RADIUS-клиента (такого как NAS), перенаправляет запрос к удаленному RADIUS-серверу, получает ответ от него и посылает этот ответ клиенту, возможно с изменениями, от-ражающими локальную административную политику. RADIUS-прокси чаще всего используется при роуминге. В этом случае для предоставления доступа несколько административных единиц должны аутентифицировать пользователей друг друга.
NAS посылает свой запрос на доступ к перенаправляющему серверу, который перенаправляет этот запрос на удаленный сервер. Удаленный сервер присылает ответ (Access-Request, Access-Reject или Access-Challenge) обратно перенаправляющему серверу, который посылает его к NAS. Атрибут User-Name может содержать идентификатор сетевого доступа (например, userID, переданный клиентом при РРР-аутентификации). Выбор сервера, которому следует перенаправить запрос, основывается на аутентификационной области (realm). Аутентификационная область может быть частью области идентификатора сетевого доступа ("области имени"). Выбор сервера, которому пересылается запрос, может быть основан и на каком-то другом критерии.
RADIUS-сервер может функционировать и как перенаправляющий сервер для одних областей, и как удаленный сервер для других областей. Один перенаправляющий сервер может перенаправлять запросы любому числу удаленных серверов. Один удаленный сервер может получать пере-направления от любого числа серверов и может выполнять аутентифика-цию для любого числа областей. Один перенаправляющий сервер может выполнять перенаправление другому перенаправляющему серверу, создавая тем самым цепочку прокси. При этом следует стараться избегать создания циклов.
Следующий сценарий иллюстрирует взаимодействие между RADIUS-прокси, NAS и удаленным RADIUS-сервером:
- NAS посылает запрос на доступ перенаправляющему серверу.
- Перенаправляющий сервер отправляет запрос на доступ к удаленному серверу.
- Удаленный сервер присылает сообщения Access-Request, Access-Reject или Access-Challenge обратно перенаправляющему серверу. В нашем случае предположим, что посылается Access-Request.
- Перенаправляющий сервер посылает сообщение Access-Request к NAS.
Перенаправляющий сервер должен рассматривать все атрибуты Proxy-State в пакете как неструктурированные данные. Его действия не должны зависеть от содержимого Proxy-State атрибутов, которые были добавлены предыдущими серверами.
Если в запросе, полученном от клиента, существуют какие-либо атрибуты Proxy-State , перенаправляющий сервер должен включить эти атрибуты Proxy-State в ответ клиенту. Перенаправляющий сервер может как включать, так и не включать Proxy-State атрибуты в запрос доступа при перенаправлении запроса. Если перенаправляющий сервер не включил Proxy-State атрибуты в перенаправленный запрос доступа, он должен присоединить их к ответу перед тем, как посылать ответ обратно клиенту.
Рассмотрим каждый шаг более детально.
- NAS посылает свой запрос на доступ перенаправляющему серверу. Перенаправляющий сервер проверяет User-Password, если он есть, используя общий секрет с NAS. Если в пакете присутствует атрибут CHAP-Password и нет атрибута CHAP-Challenge, перенаправляющий сервер не должен изменять атрибут Request-Authenticator или должен копировать его в атрибут CHAP-Challenge. Перенаправляющий сервер может добавить в пакет не более одного атрибута Proxy-State. Если он добавляет атрибут Proxy-State, то он должен быть добавлен после всех остальных атрибутов Proxy-State, которые уже есть в пакете. Перенаправляющий сервер не изменяет последовательность атрибутов одного и того же типа, включая атрибуты Proxy-State.
- Перенаправляющий сервер обеспечивает конфиденциальность User-Password, если он присутствует. Для защиты от replay-атак используется секрет, который он разделяет с удаленным сервером. Перенаправляющий сервер может добавить значение Identifier, после чего перенаправляет запрос на доступ к удаленному серверу.
- Удаленный сервер (если он является конечным получателем) проверяет пользователя, используя User-Password, CHAP-Password или какой-либо другой метод, и возвращает обрат-но перенаправляющему серверу ответ Access-Request, Access-Reject или Access-Challenge. Предположим, что посылается Access-Request. Удаленный сервер должен копировать, не модифицируя, все атрибуты Proxy-State (и только их) из запроса на доступ в пакет ответа.
- Перенаправляющий сервер проверяет аутентификатор в ответе, используя секрет, который он разделяет с удаленным сервером, и молча отбрасывает пакет, если он не проходит проверку. Если пакет успешно проходит проверку, то перенаправ-ляющий сервер удаляет последний атрибут Proxy-State (если он был присоединен), обеспечивает целостность аутентификатора ответа, используя секрет, который он разделяет с NAS, и посылает Access-Request к NAS.
Перенаправляющему серверу может понадобиться изменить атрибуты для реализации локальной политики. Но при этом перенаправляющий сервер не должен изменять имеющиеся в пакете атрибуты Proxy-State, State или Class.
Производители перенаправляющих серверов определяют значения, которые они готовы принимать в качестве значения атрибута Service-Type. Это может повлиять на передачу значения Service-Type от NAS в проксируемом пакете Access-Request. Могут также существовать механизмы, которые блокируют определенные типы сервисов.
Причина использования UDP
Часто возникает вопрос, почему в качестве транспорта сообщений RADIUS используется UDP, а не ТСР. UDP был выбран исключительно по техническим причинам.
Существуют определенные проблемы, в результате которых UDP становится более предпочтительным транспортным протоколом. RADIUS является протоколом, основанным на транзакциях, который обладает следующими характеристиками:
- Если запрос к первичному аутентификационному серверу выполняется со сбоем, должен быть сделан запрос к вторичному серверу. Для выполнения этого требования копия запроса должна храниться в стеке протоколов выше транспортного уровня, чтобы иметь возможность выполнить альтернативную передачу. Это также означает, что требуется таймер повторной передачи.
- Требования к задержкам по времени для данного протокола существенно отличаются от тех, которые обеспечиваются в протоколе ТСР.
С одной стороны RADIUS не требует сверх точного определения потерянных данных. Пользователь может подождать несколько секунд для завершения аутентификации, поэтому по-стоянные повторные передачи, которые имеют место в ТСР, не требуются.
С другой стороны пользователя нельзя заставлять ждать завершения аутентификации несколько минут. Следовательно, надежная доставка ТСР-данных в течение двух минут не нужна. Быстрее использовать альтернативный сервер, который может предоставить доступ.
- Протокол не поддерживает состояния, поэтому естественнее использовать UDP.
И клиент, и сервер могут завершить соединение, любая из сторон может выполнить перезапуск всей системы. При этом обычно не возникает проблем, связанных с необходимостью определения потерянного соединения, которые имеют место в протоколе ТСР. Код может быть просто написан с учетом обработки аномальных событий. В самом протоколе UDP полностью отсутствует какая-либо специальная обработка при потере соединения. И клиент, и сервер могут использовать данное UDP-соединение только один раз.
- Использование UDP упрощает реализацию сервера.
В ранних реализациях RADIUS сервер состоял из единственной нити. Это означало, что одновременно мог получаться, обрабатываться и возвращаться единственный запрос. Это за-медляло обработку в тех случаях, когда используемым механизмам безопасности требовалось много времени. Также могла переполниться очередь запросов на сервер, если сотням людей ежеминутно требовалась аутентификация. Очевидным решением этой проблемы является реализация сервера с использованием нескольких нитей. Сделать это значительно проще, используя UDP. Каждый процесс обрабатывал отдельный запрос и отвечал клиенту NAS простым UDP-пакетом.
Это не является панацеей от всех бед. При использовании UDP на прикладном уровне требуется помнить о проблемах, которые автоматически решаются в ТСР, например управлением таймерами повторных передач.
Использование повторных передач
Если RADIUS-сервер и альтернативный RADIUS-сервер разделяют общий секрет, то можно переслать пакет альтернативному RADIUS-серверу с тем же самым ID и аутентификатором запроса, так как содержимое атрибутов не изменилось. Если необходимо использовать новый аутентификатор запроса при отправке запроса альтернативному серверу, это можно сделать.
Если сервер изменил содержимое атрибута User-Password (или любого другого атрибута), то он должен создать новый аутентификатор запроса и, следовательно, новый ID.
Если NAS повторяет запрос к тому же самому серверу, и атрибуты не изменились, следует использовать тот же самый аутентификатор запроса, ID и порт источника. Если какой-либо атрибут изменился, необходимо использовать новые аутентификатор запроса и ID.
NAS может использовать один и тот же ID для всех серверов или может для каждого сервера использовать отдельный ID.
Проверка жизнеспособности сервера
Некоторые производителя посылают тестовые запросы для проверки жизнеспособности сервера. Это не самая лучшая практика, так как увели-чивается трафик и уменьшается масштабируемость, без предоставления при этом никакой дополнительной информации. Так как запрос RADIUS содержится в единственной дейтаграмме, можно вместо этого просто выполнить команду ping.
Для мониторинга RADIUS-сервера следует использовать протокол SNMP.