Защита от хакеров корпоративных сетей
Шрифт:
Таблица 13.1.
Типы криптографии и криптографические алгоритмы, поддерживаемые OpenSSH
Трассируемость. Весь трафик уплотнен в единое исходящее TCP-соединение. Большинство сетей позволяет передавать через них исходящий трафик по протоколу SSH (через двадцать второй порт протокола TCP – 22/TCP). Функциональные возможности опции ProxyCommand предоставляют удобный интерфейс для маскировки трафика и применяемых редиректоров (редиректор (redirector) – сетевое программное обеспечение, эмулирующее доступ прикладных программ к удаленной файловой системе так, как будто это локальная), как, например, редиректор протокола SOCKS или инкапсулятор трафика по протоколу HTTP.
Удобство. В большинстве современных систем UNIX серверный и клиентский код инсталлируется по умолчанию. Пакет OpenSSH переносится на большое число платформ, включая Win32.
Гибкость. Способность пакета OpenSSH к бесшовной, цельной инкапсуляции широкого диапазона передаваемых данных (см. табл. 13.2) означает, что следует предпринять дополнительные меры предосторожности для предотвращения доступа к запрещенным ресурсам со стороны клиентов, которым доверяют лишь частично. Запретный плод всегда сладок. Одним из главных недостатков пакета OpenSSH является его неспособность к внутреннему
Качество. В целом пакет OpenSSH относится к классу работающих систем. Как правило, для обращения к нему используется довольно простой синтаксис, но при попытке воспользоваться сетевой переадресацией порта обнаруживается тенденция чрезмерного усложнения использования новых возможностей пакета, появившихся при переходе к современным платформам. Для некоторых платформ проблемой является их быстродействие, хотя по умолчанию для успешной работы OpenSSH достаточно обеспечения ими уровня 0,1 MB/с. Появление процессов зомби может оказаться следствием некоторых проблем с переадресацией команд. OpenSSH – это проект высочайшего обеспечения безопасности, истоки которого можно найти в оригинальной реализации Тату Юлоненом (Tatu Ylonen) протокола SSH, впоследствии расширенной Тео де Раадтом (Theo De Raadt), Маркусом Фридлом (Markus Friedl), Дамином Миллером (Damien Miller) и Беном «Морингом» Линдстоном (Ben «Mouring» Lindstrom). Он постоянно развивается с трудно объяснимой одержимостью.
Установка OpenSSHОписание полной процедуры установки OpenSSH выходит за рамки этой главы. Хорошее руководство по инсталляции OpenSSH в среде Linux можно найти по адресу www.helpdesk.umd.edu/linux/security/ssh_install.shtml. Установка OpenSSH в Windows чуть сложнее. Документацию превосходной среды UNIX-On-Windows Cygwin можно получить по адресуТот, кто просто ищет работоспособный демон, который позволяет работать с OpenSSH, может обратиться по адресу www.networksimplicity.com/openssh/ для загрузки превосходной реализации SSHD компании Network Simplicity.
Обратите внимание на важное предупреждение по поводу версий. В состав всех современных дистрибутивов UNIX включены демоны SSH, устанавливаемые по умолчанию. В их число входит и OSX компании Apple Macintosh. К несчастью, вызывает беспокойство номер версий демонов SSH. Прежде всего это касается SSH версии 1.2.27, OpenSSH версии 2.2.0p2 или более ранней. В перечисленных пакетах реализация SSH1 очень уязвима к компрометации удаленным суперпользователем. Поэтому они должны быть обновлены как можно быстрее. Если нет возможности обновить демон самой последней версией обновления, доступной по адресу www.openssh.com (или даже официальной версией SSH2 от ssh.com), то безопасный способ компоновки пакета OpenSSH, поддерживающей SSH1 и SSH2, состоит в редактировании файлов /etc/sshd_config и замены Protocol 2,1 на Protocol 2. (Подобные действия могут привести к побочному эффекту, который проявляется в полном отключении внутренней поддержки SSH1. В этом кроется источник проблем для клиентов старших версий.) В рассмотренной ситуации занавес секретности также не обеспечивает необходимой защиты. К тому же номер версии любого SSH-сервера можно легко удаленно запросить так, как это показано ниже:effugas@OTHERSHOE ~
$ 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:\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.
Рис. 13.1. Использование OpenSSH на платформе Win32 при помощи Cygwin и rxvt
Как было сказано, известны различные альтернативы реализации SSH. Одной из них является программа MindTerm, другой – программа PuTTY Программа MindTerm Матса
Сезам, откройся: аутентификация
Первым шагом для получения доступа к удаленной системе при работе в 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:
effugas@OTHERSHOE ~
$ ssh-keygen
Generating public/private rsa1 key pair.
Enter file in which to save the key (/home/effugas/.ssh/
identity):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/effugas/.ssh/
identity.
Your public key has been saved in /home/effugas/.ssh/
identity.pub.
The key fingerprint is:
c7:d9:12:f8:b4:7b:f2:94:2c:87:43:14:5a:cf:11:1d
effugas@OTHERSHOE
effugas@OTHERSHOE ~
$ ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/home/effugas/.ssh/
id_dsa):
Enter passphrase (empty for no passphrase): <ENTER>
Enter same passphrase again: <ENTER>
Your identification has been saved in /home/effugas/.ssh/
id_dsa.
Your public key has been saved in /home/effugas/.ssh/
id_dsa.pub.
The key fingerprint is:
e0:e2:a7:1b:02:ad:5b:0a:7f:f8:9c:d1:f8:3b:97:bd
effugas@OTHERSHOEЗатем наступает время второго шага: следует проинформировать сервер о необходимости проверить подключенных клиентов на предмет обладания ими личного ключа (.ssh/identity для SSH1, ssh/id_dsa для SSH2). Такая проверка заключается в посылке серверу его общедоступного элемента, который затем добавляется в файл домашней директории пользователя. Домашняя директория пользователя задается самим пользователем:.ssh/authorized_keys для SSH1 и. ssh/authorized_keys2 для SSH2. На самом деле не существует элегантного способа реализовать в протоколе SSH то, что было сказано. Это самая слабая сторона комплекса инструментальных средств, а вполне возможно, что и самого протокола непосредственно. Для преодоления данного недостатка Уильям Стеарнс (William Stearns) проделал в этом направлении очень большую работу. Его скрипт, посвященный этой проблеме, находится по адресу www.stearns.org/ssh-keyinstall/ssh-keyinstall-0.1.3.tar.gz. Реализованные в нем вещи аморальны, и он даже не пытается скрывать это. Приведенный ниже пример, используя недавно загруженные ключи пользователя, устраняет необходимость в идентификации пароля. Попутно появляется дополнительное преимущество, которое заключается в отсутствии необходимости использовать какие-либо дополнительные приложения (отметим, что от читателя потребуется ввести пароль):