previous up next index search
Previous: 6.5 Протокол SSL. Безопасный уровень соединителей    UP: 6 Сетевая безопасность
    Next: 6.7 Безопасность WEB-серверов

6.6 Безопасная оболочка (SSH)

Семенов Ю.А. (ИТЭФ-МФТИ)
Yu. Semenov (ITEP-MIPT)

Администрирование сетей обычно производится с консоли. Это удобный и наиболее безопасный метод. Но время от времени возникают ситуации, когда администратор вынужден выполнять те или иные системные операции с удаленного терминала. Если терминальный обмен не зашифрован, он может быть перехвачен с помощью любой машины (например, используя программу tcpdump или sniffer), подключенной к тому же логическому сегменту или, в более общем случае, к тому же каналу. Именно по этой причине целесообразно выделять почтовый сервер, DNS, сервер новостей и маршрутизаторы в отдельный сетевой сегмент, к которому не подключены “посторонние” машины. Для того чтобы предотвратить перехват сессии авторизации и последующей работы оператора, в Финляндии разработана специальная программа “безопасная оболочка” SSH (Secure Shell). Эта общедоступная программа пригодна для любых удаленных сессий, включая те, которые используют протокол HTTP. SSH использует для шифрования как открытый ключ, так и симметричные схемы. При этом производится аутентификация ЭВМ и формирование коммуникационного канала с шифрованием передаваемых данных. В отличие от SSL здесь не требуется приобретать сертификат сервера или клиента для обеспечения высокой степени безопасности. Благодаря тому, что программа разработана в Европе, пользователь даже за пределами США получает высокий уровень защиты (нет экспортных лицензионных ограничений). SSH заменяет для приложений, где требуется безопасность, такие программы как telnet, rlogin, rsh и rcp. Эта программа для ЭВМ, на которых установлена, шифрует также и сессии X Windows. Привлекательность программы заключается в том, что помимо перечисленных возможностей она применима для шифрования практически любой TCP/IP сессии, например, FTP или HTTP. Это реализуется путем запуска специальной прокси-программы на вашей локальной ЭВМ. Прокси-программа шифрует запрос и организует туннель до нужного сервера. Это позволяет использовать редактор HTML, графический WEB-броузер и другие программные продукты, которые сами по себе не поддерживают криптографической защиты. Шифрованная связь поддерживается с WEB-сервером, который не имеет соответствующего сертификата. В стандартный набор входит и программа безопасного удаленного копирования файлов SCP, заменяющая FTP. SSH по умолчанию использует порт 22.

Для формирования SSH-прокси на удаленном WEB-сервере сначала нужно зарезервировать не используемый порт на локальной машине, например, 5678. После этого следует использовать программу SSH для того, чтобы установить связь, например, с каким-то WEB-сервером. При этом для создания прокси следует применить опцию –L:

SSH –L5678:www.pod.potol.com:80 www.pod.potol.com

Аргумент, следующий после флага опции -L имеет формат:

<локальный порт>:<удаленная ЭВМ>:<удаленный порт>.

Таким образом, мы требуем, чтобы прокси прослушивала локальный порт 5678 и переадресовывала весь обмен в зашифрованном виде в порт 80 узла www.pod.potol.com. После выполнения данной команды следует, например, запустить WEB-броузер на вашей ЭВМ и потребовать установления связи с http://localhost:5678/. Практически будет установлена связь с http://www.pod.potol.com, но весь диалог в этом варианте уже будет зашифрован. По завершении работы с броузером следует выполнить команду logout на удаленной ЭВМ. Общедоступную версию SSH можно найти по адресу: www.cs.hut.fi/ssh. Информацию о коммерческих версиях для Windows и Macintosh можно найти на сервере: www.datafellows.com/f-secure.

В версии OpenSSH была обнаружена уязвимость, которая позволяет повторять попытки подбора пароля практически неограниченное число раз, что сильно понижает надежность системы. Такая уязвимость присуща не всем версиям Linux, но расслабляться не следует. Лишний раз можно напомнить о необходимости использования надежных паролей (см. "How can enterprises stop the OpenSSH vulnerability?", Michael Cobb).


В последнее время остро встала проблема надежной аутентификации пользователей в сети. Здесь приходится найти компромисс между однозначным распознаванием пользователя и требованиями конфиденциальности.

Previous: 6.5 Протокол SSL. Безопасный уровень соединителей    UP: 6 Сетевая безопасность
    Next: 6.7 Безопасность WEB-серверов