Коллектив авторов - Защита от хакеров корпоративных сетей

К счастью, есть альтернатива. Используйте уже готовые средства! Среда Cygwin, доступная по адресу www.cygwin.com, является удивительно законченной и полезной UNIX-подобной средой, которая может быть развернута непосредственно в Windows. В эту среду был перенесен пакет OpenSSH. Таким образом, все описанные в этой главе способы могут быть использованы в программной среде Microsoft. Для получения доступа к упомянутым возможностям существуют два основных способа:

• установка полной среды Cygwin. При недостатке времени эта процедура включает в себя запуск инсталляционной программы www.cygwin.com/setup.exe, выбор номера пакета и согласие пользователя на установку одной из зеркальных версий. При этом следует иметь в виду следующее. Хотя в составе Cygwin предусмотрена превосходная реализация стандартной команды rxvt операционной системы UNIX для работы с окружением окна, тем не менее по умолчанию она не работает. Это легко исправить при помощи щелчка правой кнопки мыши на рабочем столе, выбора пунктов меню New, затем Shortcut и после этого ввода необычно длинного пути, приведенного ниже:

c:\cygwin\bin\rxvt.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.

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

Основной способ получения доступа: аутентификация при помощи пароля

«Вначале была командная строка». Основной сутью протокола SSH является то, что командная строка удаленной машины всегда была и будет. Ее синтаксис прост:

dan@OTHERSHOE ~

# ssh user@host

$ ssh dan@10.0.1.11

dan@10.0.1.11”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-серверу в общем случае выглядят следующим образом:

effugas@OTHERSHOE ~

$ ssh effugas@10.0.1.11

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.

effugas@10.0.1.11’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:

Читать дальше