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

авторов Коллектив

Тем не менее это поучительная проблема. X-Windows является протоколом, который соединяет выполняющиеся в одном месте программы для отображения их результатов в другом. Для этого нужно создать канал отображения образов на экран дисплея и в ответ получить координаты траектории движения мышки или коды нажатых клавиш.

Что произойдет, если сервер был скомпрометирован?

Неожиданно способность отслеживать нажатие клавиш может быть сведена к достижению совершенно другой цели – контролю активности удаленного клиента. Он вводит пароль? Перехвачено. Выводит символ? Запомнено. Помните, что по туннелю, если рассматривать его как элегантно зашифрованное и удостоверенное соединение, может быть передана важная информация. И вот еще. Безопасность туннеля не может быть выше безопасности его начальной и конечной точек.

Возможное решение состояло в отключении возможности продвижения данных X-приложений по умолчанию. В настоящее время в OpenSSH реализована

команда ssh – X user@host, которая делает это при условии реализации точно такой же возможности на сервере. (Нет, это еще не законченное решение. В случае возникновения у клиента необходимости отправки X-трафика скомпрометированный сервер все еще может попытаться эксплуатировать клиента с нарушением установленных режимов работы. Но на некотором этапе проблема превращается в проблему собственно X-трафика, и в большинстве сессий протокол SSH ничего не может с этим поделать. Большинство сессий может быть сделано безопасными простым отключением опции по умолчанию. Гораздо более безопасным решением является пересылка X-трафика при помощи программного обеспечения VNC (Virtual Network Computing – виртуальная сетевая обработка данных), что во многих сравнительно медленных сетевых топологических схемах устанавливается быстрее, проще, а работает гораздо стабильнее. Подробнее об этом можно узнать по адресу www.tightvnc.org.).

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

Качество: «Насколько безболезненно обслуживание системы?»

Среди главных вопросов, на которые нужно ответить при исследовании качества системы, являются следующие:

• можно ли реализовать задуманное;

• будет ли устойчив полученный результат;

• будет ли реализация достаточно быстра?

Есть несколько простых вещей, про которые читатель может подумать, что они очевидны. Некоторые базовые концепции выглядят настолько естественными, что никто даже и подумал бы предположить что-либо другое. Можно полагать, что к ним принадлежит идея удобства и простоты использования системы. Если система непригодна, то никому и в голову не придет использовать ее. Читатель может подумать, что словосочетание «непригодно для использования» означает систему, которая охотно поделится конфиденциальной информацией с первым встречным, но на самом деле это не так. В последнее время появилось слишком много систем, которые таковыми в буквальном смысле не являются, но из-за их чрезмерной сложности их нельзя модернизировать, подделать, использовать в своих целях, адаптировать к нуждам конкретного сайта или сделать с ними еще что-нибудь, поэтому все силы уходят на то, чтобы они вообще заработали. Такие системы не приветствуются даже в области обеспечения безопасности. Те, кто боится сломать их, избегают вносить в них исправления. (На многие, очень многие сервера не устанавливаются патчи, латающие дыры в системе безопасности сервера, только потому, что получила распространение очень простая логика, согласно которой исправленный сервер злоумышленник может и не атаковать, а обновляющий сервер патч наверняка содержит ошибки.) Поэтому на самом деле основные вопросы к любой системе туннелирования состоят в следующем: «Можно ли, приложив разумные усилия, сначала установить систему, а затем поддерживать ее силами обслуживающего персонала? Насколько надежна настройка системы? Каков риск простоя системы во время ее использования после проведенной модернизации?»

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

Проектирование сквозных систем туннелирования

Можно реализовать различные варианты туннелей. Изучение способов шифрования межсетевого интерфейса свидетельствует о стремлении сосредоточиться на методологии туннелирования, подлежащей реализации. Простое правило утверждает: «Когда это возможно, туннели должны удовлетворять требованию сквозной безопасности». Нужно создать такие условия, чтобы только клиент и сервер были в состоянии получить доступ к передающемуся по туннелю трафику и расшифровать его. Хотя межсетевые экраны, маршрутизаторы и даже другие серверы могут быть включены в процесс передачи зашифрованного потока данных, только начальная и конечная точки туннеля должны обладать возможностью

стать полноправными участниками обмена данными по туннелю. Конечно, всегда есть возможность обратиться к конечным точкам туннеля с запросом предоставления доступа к части доступной им сети. Это предпочтительнее выполнения на них сервисов, хотя и выходит за рамки компетенции туннеля. Проехав по туннелю под Ла-Маншем из Англии во Францию, далее можно свободно путешествовать по Испании или Германии. В чем проблема? Ведь уже можно гарантировать, что после пересечения Ла-Манша путешественник в море не утонет!

Сквозное туннелирование безукоризненно выполняет следующие три функции:

• устанавливает правильный маршрут от клиента к серверу;

• самостоятельно выполняет процедуру аутентификации и шифрует передаваемые по новому маршруту данные;

• переадресует (перенаправляет) сервисы (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.