Безопасное сетевое взаимодействие (часть 3)

Метод аутентификации на основе адреса хоста: hostbased

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

Клиент запрашивает данную форму аутентификации, посылая сообщение, аналогично UNIX способам аутентификации rhosts и hosts.equiv. Отличие от этих способов аутентификации состоит в том, что идентификация хоста клиента выполняется более строго.

Данный метод выполняется следующим образом: клиент посылает подпись, созданную закрытым ключом хоста клиента, которую сервер проверяет с помощью открытого ключа хоста клиента.

SSH_MSG_USERAUTH_REQUEST
имя пользователя
сервис
"hostbased"
алгоритм открытого ключа для ключа хоста
открытый ключ хоста и сертификаты для 
    клиента хоста
имя хоста клиента (FQDN; US-ASCII)
имя пользователя клиента на удаленном хосте
подпись

Имена алгоритмов открытого ключа определены в спецификации транспортного уровня. "Открытый ключ хоста клиента" может включать сертификаты.

Подпись закрытым ключом хоста клиента выполняется для следующих данных:

• Идентификатор сессии;
• Пакет, содержащий информацию, без подписи.

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

Рекомендуется предусмотреть возможность выполнения сервером дополнительных проверок того, что сетевой адрес, полученный из внешней, неизвестной сети, соответствует данному имени хоста клиента.

Обсуждение проблем безопасности

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

Сервер после повторных неуспешных аутентификаций может перейти в состояние sleep, это затруднит подбор пароля.

Если транспортный уровень не обеспечивает шифрование, методы аутентификации, которые имеют доступ к секретным данным, должны быть недоступны. Если защита с помощью МАС не обеспечивается, запросы на изменение данных аутентификации (например, изменение пароля) должны быть недоступны, для того, чтобы избежать атак, связанных с модификацией текста.

Разрешается использовать несколько аутентификационных методов с различными характеристиками безопасности. Локальная политика сервера определяет, какие методы (или комбинации методов) будут применяться для конкретного пользователя. Результирующая аутентификация не сильнее, чем допустимая самая слабая комбинация методов.

Протокол соединения

Рассмотрим протокол соединения SSH. Он обеспечивает интерактивные входные сессии, удаленное выполнение команд, перенаправление ТСР/IP-соединений и перенаправление Х11-соединений. Все эти каналы мультиплексируются в единственный зашифрованный туннель. Протокол соединения SSH разработан для выполнения выше транспортного уровня SSH и протоколов аутентификации пользователя. Данный сервис называется ssh-connection.

Общие запросы

Существует несколько типов запросов, которые воздействуют на удаленный конец "глобально", независимо от канала. Примером является запрос на начало ТСР/IP, перенаправляемого на определенный порт. Все подобные запросы используют следующий формат.

SSH_MSG_GLOBAL_REQUEST
имя запроса (ограничено US-ASCII)
ждать ответа
. . .	данные, специфичные для запроса

Получатель будет отвечать на данное сообщение SSH_MSG_REQUEST_SUCCESS, SSH_MSG_REQUEST_FAILURE или некоторым специфичным для запроса сообщением, если "ждать ответа" есть TRUE.

SSH_MSG_REQUEST_SUCCESS

Если получатель не распознает или не поддерживает запрос, он просто отвечает:

SSH_MSG_REQUEST_FAILURE