Сквозное туннелирование безукоризненно выполняет следующие три функции:
• устанавливает правильный маршрут от клиента к серверу;
• самостоятельно выполняет процедуру аутентификации и шифрует передаваемые по новому маршруту данные;
• переадресует (перенаправляет) сервисы (forward services) по установленному таким образом соединению.
Перечисленные функции могут быть сведены к единственному шагу, как, например, получение доступа к зашифрованному протоколом SSL Web-сайту путем прохода через проницаемую сеть. Названные три функции могут быть расширены, дополнены и повторно объединены самым различным образом, например для подтверждения подлинности промежуточных хостов (а также подтверждение им своей подлинности) перед разрешением каких-либо попыток аутентификации по пути к конечному адресату. Но эти названные три функции всегда должны быть реализованы, и именно об этом пойдет речь дальше.
Прокладка туннеля с помощью протокола SSH
Из изложенного видно, что разработчики туннеля оставлены наедине с запутанным набором предъявляемых к нему требований. Складывающаяся вокруг этого вопроса ситуация подталкивает их к мысли, что инкапсуляция может оказаться способом, который всех удовлетворит. Что использовать? Протокол IPSec со всей кричащей и расхваливающей рекламой в его адрес настолько сложен для настройки, что даже Брюс Шнейер (Bruce Schneier), признанный мэтр компьютерной защиты и автор книги «Прикладная криптография (Applied Cryptography)», был вынужден заявить: «Несмотря на то что протокол разочаровывает, главная претензия к нему – чрезмерная его сложность. Хотя следует признать, что протокол IPSec является лучшим IP-протоколом обеспечения безопасности, доступным на данный момент». (Мысли автора по этому поводу могут быть выражены следующими словами: «Я предпочел бы изуродовать сам себя, воткнув себе в глаза раскаленный кухонный нож или вилку, чем администрировать сеть с установленным протоколом IPSec». Но это лишь его личное мнение.)
Протокол SSL хорош и пользуется всеобщим доверием. Есть даже реализующие его средства, которые никак нельзя назвать программами с жалкой командной строкой. Прежде всего к ним относится программа Stunnel с приличными функциональными возможностями. Но сам по себе протокол SSL ограничен и не облегчает создание и использование многих из наиболее интересных систем туннелирования, какие только можно себе представить. В конце концов, протокол SSL – это зашифрованный TCP-вариант передачи данных, нечто большее, чем обеспечение безопасного потока битов с прекрасной системой аутентификации. Протокол SSL действует только до следующего хоста, расположенного на маршруте передачи данных. Постепенно, по мере роста числа попыток использовать протокол SSL для инкапсуляции внутри него передаваемых данных, его сложность увеличивается. Более того, стандартная реализация протокола SSL не отвечает требованиям современных передовых технологий обеспечения безопасности. Главным образом это означает то, что скомпрометированный завтра ключ позволит исследовать полученные сегодня данные. Для целей туннелирования это не нужно и является откровенно слабым свойством протокола. Требуется что-то лучшее, чему еще доверяют. Нужен OpenSSH.
Анализ безопасности: OpenSSH 3.02
Пакет OpenSSH – стандарт де-факто в области безопасного удаленного обеспечения сетевого взаимодействия. В этой области он является наиболее известным пакетом. OpenSSH добился признания благодаря превосходному и безопасному замещению сервиса Telnet и серии приложений r*. Пакет OpenSSH – невероятно гибкая реализация одного из трех пользующихся доверием протоколов обмена информацией (другими двумя являются протоколы SSL и IPSec).
Конфиденциальность. OpenSSH – один из оплотов обеспечения безопасности из класса программ с открытыми исходными текстами. Зачастую это единственная доступная точка входа в некоторые наиболее параноидные сети, окружающие нас. Заложенная в первой версии протокола SSH идея доверия после нескольких лет интенсивного анализа была тщательно изучена. OpenSSH является законченной реализацией протокола SSH2 с полностью открытым кодом и занимает уникальную позицию как единственно надежный путь миграции от SSH1 к SSH2 (эта возможность первоначальными создателями протокола SSH была безнадежно испорчена). Все перечисленное сделало OpenSSH стандартом реализации SSH в Интернете. В таблице 13.1 приведены типы криптографии и криптографические алгоритмы, поддерживаемые OpenSSH.
Таблица 13.1.
Типы криптографии и криптографические алгоритмы, поддерживаемые OpenSSH
Трассируемость. Весь трафик уплотнен в единое исходящее TCP-соединение. Большинство сетей позволяет передавать через них исходящий трафик по протоколу SSH (через двадцать второй порт протокола TCP – 22/TCP). Функциональные возможности опции ProxyCommand предоставляют удобный интерфейс для маскировки трафика и применяемых редиректоров (редиректор (redirector) – сетевое программное обеспечение, эмулирующее доступ прикладных программ к удаленной файловой системе так, как будто это локальная), как, например, редиректор протокола SOCKS или инкапсулятор трафика по протоколу HTTP.
Удобство. В большинстве современных систем UNIX серверный и клиентский код инсталлируется по умолчанию. Пакет OpenSSH переносится на большое число платформ, включая Win32.
Гибкость. Способность пакета OpenSSH к бесшовной, цельной инкапсуляции широкого диапазона передаваемых данных (см. табл. 13.2) означает, что следует предпринять дополнительные меры предосторожности для предотвращения доступа к запрещенным ресурсам со стороны клиентов, которым доверяют лишь частично. Запретный плод всегда сладок. Одним из главных недостатков пакета 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 можно получить по адресу http://tech.erdelynet.com/cygwin-sshd.asp. Тот, кто просто ищет работоспособный демон, который позволяет работать с 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-сервера можно легко удаленно запросить так, как это показано ниже:
[email protected] ~
$ telnet 10.0.1.11 22
Trying 10.0.1.11...
Connected to 10.0.1.11.
Escape character is “^]”.
