Коллектив авторов - Защита от хакеров корпоративных сетей
[email protected] ~
$ telnet 10.0.1.11 22
Trying 10.0.1.11...
Connected to 10.0.1.11.
Escape character is “^]”.
SSH-1.99-OpenSSH_3.0.1p1Другим важным замечанием является то, что SSH-серверу необязательно нужны права суперпользователя для реализации большинства своих функциональных возможностей. Любой пользователь может выполнить программу sshd по дополнительному порту и даже подтвердить свое право на выполнение таких действий. Любой пользователь, наделенный обычными правами, может инсталлировать и выполнить клиентскую программу SSH. Это особенно важно в том случае, когда необходимы некоторые новейшие возможности OpenSSH, как, например, опция ProxyCommand, которые необходимы, но недоступны в старших версиях.
...Приоткрывая завесу
OpenSSH под Windows
Для Win32 существует много прекрасных реализаций протокола SSH, включая F-Secure SSH и SecureCRT. Это не очень гибкие реализации протокола SSH, по крайней мере в тех терминах гибкости, которые представляют интерес и которые были обсуждены в этой главе. Названные инструментальные средства относятся к классу больших инструментальных средств, которые предназначены для фальсификации командной оболочки удаленной машины. Большинство из нестандартных способов, описанных в этой главе, основаны на способности инструментария UNIX динамически объединяться друг с другом самым неожиданным способом при помощи простого средства под названием канал (канал (pipe) – одно из средств межпроцессного взаимодействия в многозадачных системах) и переадресации, которые соответствующим образом подготовлены пользователем.
К счастью, есть альтернатива. Используйте уже готовые средства! Среда Cygwin, доступная по адресу www.cygwin.com, является удивительно законченной и полезной UNIX-подобной средой, которая может быть развернута непосредственно в Windows. В эту среду был перенесен пакет OpenSSH. Таким образом, все описанные в этой главе способы могут быть использованы в программной среде Microsoft. Для получения доступа к упомянутым возможностям существуют два основных способа:
• установка полной среды Cygwin. При недостатке времени эта процедура включает в себя запуск инсталляционной программы www.cygwin.com/setup.exe, выбор номера пакета и согласие пользователя на установку одной из зеркальных версий. При этом следует иметь в виду следующее. Хотя в составе Cygwin предусмотрена превосходная реализация стандартной команды rxvt операционной системы UNIX для работы с окружением окна, тем не менее по умолчанию она не работает. Это легко исправить при помощи щелчка правой кнопки мыши на рабочем столе, выбора пунктов меню New, затем Shortcut и после этого ввода необычно длинного пути, приведенного ниже:
c:cygwinbinrxvt.exe –rv –sl 20000 –fn “Courier-12” –e /bin/bash —login –I
(Убедитесь, что в указанный путь внесены исправления, если Cygwin была инсталлирована в другую директорию.) Пусть читатель сам назовет ярлык так, как ему больше всего нравится. Кроме того, он может слегка подстроить свой терминал. Для этого предусмотрен режим негативного видеоизображения командной строки, буфер с реализованной возможностью обратной прокрутки двадцати тысяч строк текста, текстовый шрифт Courier размером 12 пунктов и заданная по умолчанию подсказка bash;
• воспользоваться специально написанной для этой главы программой DoxSSH, которая является миниатюрной копией дистрибутива OpenSSH/Cygwin, Ее можно найти по адресу www.doxparacom/doxssh или на Web-сайте этой книги Syngress Solutions (www.syngress.com/solutions).
Оба решения показаны на рис. 13.1.
...Рис. 13.1. Использование OpenSSH на платформе Win32 при помощи Cygwin и rxvt
Как было сказано, известны различные альтернативы реализации SSH. Одной из них является программа MindTerm, другой – программа PuTTY Программа MindTerm Матса Андерсона (Mats Andersson) доступна по адресу www.appgate.com/mindterm/. MindTerm, возможно, это относится только к приложениям Java, является новаторской законченной реализацией SSH1/SSH2, которая способна безопасным способом загрузить Web-страницу. Программа PuTTY является простой и, безусловно, минимально возможной реализацией терминальной части SSH1/SSH2 для Windows. Ее можно найти по адресу www.chiark.greenend.org.uk/~sgtatham/putty или www.doxparacom/putty. Обе программы компактны, быстры, наделены хорошими функциональными возможностями, a стиль их написания производит приятное впечатление.
Сезам, откройся: аутентификация
Первым шагом для получения доступа к удаленной системе при работе в SSH является подтверждение пользователем своей подлинности при помощи процесса аутентификации. С него начинает свою работу каждый, кто использует SSH.
Основной способ получения доступа: аутентификация при помощи пароля
«Вначале была командная строка». Основной сутью протокола SSH является то, что командная строка удаленной машины всегда была и будет. Ее синтаксис прост:
[email protected] ~
# ssh [email protected]
$ ssh [email protected]
[email protected]”s password:
FreeBSD 4.3-RELEASE (CURRENT-12-2-01) #1: Mon Dec 3
13:44:59 GMT 2001
$Если задать опцию – X, то при выполнении приложения X-Windows автоматически будет создан туннель. Представляет интерес интерфейс обработки паролей SSH. При необходимости задания пароля безразлично, где именно в цепочке команд SSH он будет задан. В любом случае SSH почти всегда сможет его запросить. Это не тривиально, но очень полезно.
Однако паролям присущи свои собственные проблемы. Если хосты A и B совместно используют пароли, то хост A может обмануть пользователя хоста B, и наоборот. В главе 12 были подробно описаны наиболее интересные подробности о слабых сторонах паролей. Таким образом, SSH поддерживает значительно больший механизм аутентификации (подтверждения подлинности) клиента серверу.
Прозрачный способ получения доступа: аутентификация при помощи личного ключа
Системы с асимметричным ключом предлагают мощный способ подтверждения одним хостом своей подлинности большому числу других хостов. Большинство людей может узнать человеческое лицо, но не «надеть» его на себя. Точно так же многие хосты могут распознать личный ключ по его общедоступной части, но самостоятельно воспроизвести его личную, секретную часть они не смогут. SSH генерирует две части личного ключа, которые другие хосты могут распознать: одну – для протокола SSH1, другую – для SSH2.
Аутентификация сервера клиенту Хотя для клиента использование ключевой пары, состоящей из общедоступного и личного ключа, необязательно, сервер все равно обязан предоставить такой ключ, чтобы клиент, однажды доверившись хосту, впоследствии всегда мог его идентифицировать. В этом проявляется отличие от протокола SSL, который предполагает, что клиент доверяет некоторому авторитетному источнику сертификатов, например VeriSign, веря его сертификатам при обмене данными с любым другим хостом. Напротив, протокол SSH допускает риск первого представления хосту, а затем, учитывая этот риск, пытается распространить его на все последующие сессии. При этом становится возможным значительно сократить накладные расходы за счет менее защищенной модели аутентификации сервера по умолчанию. (Это пример одного из многих компромиссов. Неуправляемые системы безопасности не устанавливают, а неразвернутые системы защиты, как правило, ужасно ненадежны.) Первые подключения к SSH-серверу в общем случае выглядят следующим образом:[email protected] ~
$ ssh [email protected]
The authenticity of host ’10.0.1.11 (10.0.1.11)’ can’t be
established.
RSA key fingerprint is
6b:77:c8:4f:e1:ce:ab:cd:30:b2:70:20:2e:64:11:db.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added ’10.0.1.11’ (RSA) to the list of
known hosts.
[email protected]’s password:
FreeBSD 4.3-RELEASE (CURRENT-12-2-01) #1: Mon Dec 3
13:44:59 GMT 2001
$Как известно, ключи Host Key генерируются автоматически после инсталляции SSH-сервера. Часто это сопровождается проблемами из-за чрезмерной молчаливости программ инсталляции. Иногда они перезаписывают или используют не по назначению существующие ключи. В результате при работе клиентов возникают жуткие ошибки, которые указывают на возможность существования кого-то или чего-то, фальсифицирующего сервер. Но обычно это означает всего лишь законную потерю ключа или его разрушение в результате последовательного продвижения пользователей к только им известной цели и получения ими доступа к новым, возможно, фальсифицированным ключам. Это не вполне понятно, но именно так все и происходит. Для систем, которым необходимо обеспечить повышенную безопасность, чрезвычайно важно задуматься над использованием достойных способов безопасного размещения файлов ~/.ssh/known_hosts и ~/.ssh/known_hosts2. Эти файлы содержат список ключей, которые клиенты могут распознать. Большая часть этой главы посвящена обсуждению вопросов размещения названных файлов в произвольных нетрассируемых сетях (disroutable networks). После обнаружения работоспособного в сети читателя способа размещения этих файлов следующая идея проектирования могла бы оказаться плодотворной: каждый клиент обращается к центральному хосту с запросом нового файла, который известен хосту и который пересылает его клиенту. Аутентификация клиента серверу Использование клиентом асимметричных ключей полезно, но необязательно. Двумя главными шагами в этом направлении являются генерация клиентом ключей и последующее информирование об этом сервера, для того чтобы он смог принять сгенерированные ключи. Первый шаг, то есть генерация ключей, инициализируется при использовании команды ssh-keygen для SSH1 и команды ssh-keygen -t dsa для SSH2:
