В этой главе обсуждаются следующие темы:

• Основные требования к системам туннелирования

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

• Сезам, откройся: аутентификация

• Переадресация команд: применение переадресации команд для непосредственного выполнения скриптов и каналов

• Переадресация портов: доступ к ресурсам удаленных сетей

• Когда-то в Риме: пересекая непокорную сеть

• На полпути: что теперь?

Резюме

• Конспект

Часто задаваемые вопросы

Введение

Or « Where Are We Going, and Why Am I in This Handbasket? »
«Behold the beast, for which I have turned back;
Do thou protect me from her, famous Sage,
For she doth make my veins and pulses tremble».
«Thee it behoves to take another road»,
Responded he, when he beheld me weeping,
«If from this savage place thou wouldst escape;
Because this beast, at which thou criest out Suffers not any one to pass her way,
But so doth harass him, that she destroys him...»
DanteVs. Inferno. Canto I, as Dante meets Virgil (trans. Henry Wadsworth Longfellow)

Или «Куда мы идем, и почему я здесь оказался?»

«Созерцай чудовище, из-за которого я повернул обратно;

Ты защитишь меня от него, известный Мудрец,

Из-за него дрожат мои жилы и пульс».

«Тебе следовало бы выбрать другой путь, -

Ответил он, созерцая мой плач, -

Ты должен уйти из этого дикого места;

Потому что здесь чудовище, которого ты не переносишь,

Не позволяй никому попадаться ему на пути,

Потому что это нарушит его покой и он убьет смельчака...»

Данте. «Ад», Песнь 1. Как Данте встретил Вирджилия (транскрипция Генри Вадсворта Лонгфеллоу (Henry Wadsworth Longfellow))

«Зри: вот он, зверь, пред кем я отступил;

Спаси меня, мудрец, в беде толикой -Я весь дрожу, и стынет кровь средь жил».

«Ты должен в путь идти другой, великий, -Он отвечал, мой плач прискорбный зря, -Чтоб избежать из сей пустыни дикой.

Сей лютый зверь, враждой ко всем горя,

На сей стезе - идущему преграда;

Ввек не отстал, души не у моря».

Данте Алигьери. «Божественная комедия» / Пер. с итал. М.: Просвещение, 1988 В компьютерных науках всегда соблюдается универсальное правило, которое утверждает, что не существует полностью масштабируемых решений. Другими словами, это означает, что если процесс с самого начала был предназначен для работы на небольших системах, то, не внося в него каких-либо изменений, его нельзя применить на большой системе, и наоборот. Системы управления базами данных, спроектированные для обработки нескольких десятков тысяч записей, оказываются бесполезными при необходимости обработать миллион записей. Текстовый процессор, предназначенный для обработки больших текстов, эквивалентных многостраничным книгам, становится неуправляемым и чересчур странным при его использовании для обработки электронной почты. Перечисленное - не просто артефакты искусства программирования (или его отсутствия). Это неизбежное следствие общего подхода к проектированию систем программирования, основанного на предположениях относительно области их будущего применения и тесно связанных с ними допущений, закладываемых при проектировании подобных систем. Лучшие конструктивные решения основаны на достаточно гибких предположениях, позволяющих сохранять работоспособность систем в самых различных, невероятных условиях. Но в любом случае это всего лишь предположения. На долю протоколов TCP/IP выпал необыкновенный успех. Еще в конце 1990-х годов коммуникационных протоколов было больше. Но в результате конкурентной борьбы остальные протоколы были вытеснены. Не всегда это оценивается как катастрофа. Операционная система Windows 95 хотя и не по умолчанию, но достаточно хорошо поддерживала протоколы TCP/IP. Другими словами, в этой операционной системе протоколы TCP/IP в качестве основных протоколов по умолчанию не устанавливались. Во время ее создания в мире сетей доминировали протоколы IPX компании Novell и NetBIOS компаний Microsoft и IBM. Уже через каких-то три года ни один из этих протоколов в операционных системах по умолчанию не устанавливался. Операционная система Windows 98 по умолчанию поддерживает протоколы TCP/IP, отражая потребности обслуживаемых сетей.

Набор протоколов TCP/IP стал главным в операционных системах компании Microsoft только благодаря решению компании сохранить за собой лидирующие позиции в области поддержки сетей. В то время такой выбор казался довольно естественным и очевидным. Возможно, что кто-то доверился широкому распространению протоколов TCP/IP среди серверов UNIX, которые можно встретить повсюду в корпорациях и университетах. Или, может быть, так произошло благодаря наблюдавшемуся в то время экспоненциальному развитию Всемирной паутины (собранию гипертекстовых и иных документов, доступных по всему миру через сеть Интернет), основанной на стеке протоколов TCP/IP. Так или иначе, но оба ответа игнорируют главный вопрос, который лежит в основе сложившегося положения дел: «Почему?» Почему протоколы TCP/IP наиболее часто устанавливают на

UNIX-серверах? Могут ли другие протоколы быть использованы в сети? Короче говоря, почему именно TCP/IP?

Конечно, успеху стека протоколов TCP/IP способствовало много факторов (в особенности следует отметить их практически свободное распространение и успешную реализацию BSD). Но, вне всякого сомнения, наиболее важную роль в организации сетей на их основе сыграло то, что можно сформулировать как «глобальный замысел, локальная маршрутизация».

Протокол NetBIOS не предусматривает концепции внешнего мира, непосредственно окружающего локальную сеть читателя. Для обработки данных других сетей в протоколе IPX предусмотрена возможность работы с сетями, отличающимися от локальной сети пользователя. Но при этом требовалось, чтобы каждый клиент заблаговременно находил и определял полный маршрут к адресату. Напротив, при использовании протокола TCP/IP каждому хосту достаточно лишь знать ближайшую очередную машину, входящую в полный путь пересылки данных. При этом предполагается, что все наиболее существенные действия по пересылке данных сеть выполнит сама. Если TCP/IP можно сравнить с общеизвестной почтовой службой отправки писем адресату, то протокол IPX является эквивалентом почтовой службы, которая требует обязательного указания почтальону маршрута движения к адресату. Кроме того, протокол IPX недостаточно хорошо масштабируется.

Следует сказать, что до появления протоколов TCP/IP при построении разумно больших масштабируемых систем часто использовались различные решения, которые позволяли создать иллюзию легкого доступа к серверу и его близости к отправителю, хотя на самом деле он мог быть расположен далеко и где угодно. К таким системам обращались через так называемые туннели. Этим термином обозначалось специально организованное соединение, особенность которого заключалась в его прохождении через обычно непокорную и труднопроходимую сетевую среду. При этом вход и выход туннеля оказывались в различных местах. Системы туннелирования нетривиальны, их трудно реализовать. В основном это двухточечные линии передачи данных, которые предотвращают утечку данных где-нибудь посередине между отправителем и получателем данных. Их пропускная способность может изменяться в широких пределах, но в действительности она меньше, чем можно было бы ожидать в отсутствие каких-либо экранов или преград вдоль линии передачи.

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

Интернет, математической моделью которого является сильно связанный граф, требует к себе все большего внимания. Выяснилось, что в Интернете трудно обеспечить безопасность циркулирующих в нем данных. В этом смысле Интернет - источник неприятностей. Средства защиты данных, реализацию и использование которых могли позволить себе локальные сети и которые поэтому представляли ограниченный интерес, неожиданно оказались востребованными в глобальных сетях. Востребованные средства защиты данных стали чем-то вроде рискованного вложения капитала, подкармливающего царящее в мире сетей безумие. Ряд присущих протоколам TCP/IP элегантных решений, как, например, способы инициализации сессий, гибкие возможности выбора портов, концепция доверия к администраторам сети, по предположению присутствующая в любых хостах, непосредственно подключенных к сети, начали понемногу разваливаться. Существенно была ослаблена концепция глобальной адресации в результате широкого распространения идеи сетевой трансляции адресов NAT (Network Address Translation), которая скрывает произвольное число внутренних клиентов, располагаемых за сервером / межсетевым экраном сетевого уровня. Сетевую трансляцию адресов NAT можно рассматривать как реакцию на возникшую потребность в эффективном подключении и устранении пустой траты времени на бюрократические проволочки во время получения доступа к пространству ГР-адресов.

И неожиданно опять всплыли старые проблемы взаимосвязей и соединений отдельных хостов. Как всегда, старые проблемы извлекли на свет их старые решения. В результате была повторно рождена идея туннелирования.

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

Основные требования к системам туннелирования

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

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

Инструментарий и ловушки Инкапсуляция против интеграции

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

Дальше будет рассказано о недостатках инкапсуляции, которыми могут воспользоваться злоумышленники. Но они ничто по сравнению с запутанной историей развития интеграции. Никто не поверит производителю, если он создаст свой собственный алгоритм шифрования (даже если это будет алгоритм шифрования с 4096-битным ключом). Точно так же вызовет оправданное недоверие производитель, который спроектирует свою собственную замену протоколу защищенных сокетов SSL. Разумный подход заключается в том, что большей части программного обеспечения нельзя доверять управление паролями. Основанные на здравом смысле проверки, преследующие цель не допустить проникновения Троянских коней в систему, в основном относятся к общим вопросам обеспечения безопасности, а не к проектированию систем коммуникации, которые надежно защищены от проникновения в них злоумышленника.

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

Описанные в данной главе системы объединяют методы, пригодные для инкапсуляции произвольного содержимого.

Конфиденциальность: «Куда уходит мой трафик?»

Основополагающими вопросами сохранения тайны коммуникаций, другими словами, их конфиденциальности, являются следующие:

• может ли еще кто-либо контролировать мой трафик внутри туннеля? Ответ на этот вопрос предполагает наличие доступа по чтению к передаваемым по туннелю данным, который может быть получен при предоставлении кому-либо возможности расшифровать передаваемые данные;

• может ли еще кто-либо модифицировать трафик внутри туннеля или скрытно получить к нему доступ? Это не что иное, как получение доступа по записи к передаваемым по туннелю данным, который в основном может быть получен при помощи выполнения процедуры аутентификации (удостоверения подлинности).

Сохранение тайны коммуникаций лежит в основе проектирования любого безопасного туннеля передачи данных. До известной степени, не зная участников, которые передают данные по туннелю, пользователь не знает, ни куда по туннелю отправляются данные, ни как они были получены ранее. Труднейшие проблемы проектирования систем туннелирования связаны с достижением крупномасштабного уровня безопасности «многие ко многим» («п-к-п»). Этого не удастся достичь до тех пор, пока системе не станут полностью доверять, считая ее безопасным решением, потому что это единственное, что сможет убедить людей начать ее использовать.

Трассируемость: «Через какую сеть можно передавать данные?»

В основе идеи трассируемости лежат следующие главные вопросы:

• насколько хорошо туннель соответствует ограниченным возможностям маршрутизации пакетов через сеть пользователя? Другими словами, в какой степени характеристики пакетов способствуют их прохождению через сеть пользователя;

• насколько естественно выглядит имитация необходимых функциональных возможностей сети? Ответ на этот вопрос зависит от возможности использования маскирующего шума для слияния с окружающей сетевой средой.

Для туннелирования будет очень кстати следующая аналогия. Допустим, что сеть эквивалентна мягкому грунту, и предпринимается попытка прокопать под горой туннель, чтобы перебраться с одной ее стороны на другую. Трассируемость обычно относится к решению вопроса о том, можно ли вообще определить траекторию туннеля. В конкретном случае это означает возможность нахождения такого маршрута передачи информации, который не нарушал бы каких-либо ограничений на тип разрешенного к передаче потока данных. Например, многие межсетевые экраны разрешают передачу Web-трафика и в небольших количествах еще чего-то. Юмор мира сетей состоит в том, что громадная пропускная способность межсетевых экранов для HTTP-трафика приводит к тому, что весь поток данных может быть инкапсулирован в трафике этого протокола.

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

Рассмотрим разницу между трафиками, инкапсулированными в протоколы HTTP и HTTPS. По большому счету, протокол HTTPS является протоколом HTTP, заключенным внутри протокола SSL. Другими словами, протокол HTTPS - защищенный вариант протокола HTTP. Передаваемый с помощью протоколов HTTP и HTTPS поток данных пройдет через большинство сетей. Если пользователь пожелает, то туннель протокола HTTP станет для него прозрачным и открытым для исследования. Напротив, для туннеля протокола HTTPS это невозможно. При организации туннеля с помощью протокола HTTPS нет необходимости в фактическом выполнении протокола HTTP, а благодаря использованию SSL туннель получается практически непроницаемым для любознательного администратора. Поэтому по туннелю можно передать все, что угодно. У пользователя нет способа узнать, что именно передается по туннелю, до тех пор, пока у него не появится возможность проверить его состояние.

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

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

Удобство: «Какие усилия могут потребоваться для инсталляции программ и их выполнения?»

Основополагающим для определения возможности инсталляции программ и их выполнения является ответ на следующие два вопроса:

• что нужно установить на стороне клиента, который хотел бы принять участие в передаче данных по туннелю?

• что нужно установить на стороне сервера, который хотел бы принять участие в передаче данных по туннелю?

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

Обновление клиента может оказаться более удобным и выгодным, потому что в этом случае исправления локализуются в нужном месте: тот, кто наиболее нуждается в дополнительных возможностях, зачастую больше заинтересован в обновлении своих программ. Напротив, обновление сервера отделено от пользователя и вынуждает его делать работу, которая принесет пользу другим. (Нельзя также проигнорировать и тот факт, что в общем случае обновление устойчиво работающих серверов не является хорошим способом исправления чего-то, что не может привести к отказу работы большого числа пользователей.)

Другие системы туннелирования извлекают преимущества из уже размещенных на стороне клиентов программ, обеспечивая для них поддержку сервера. Обычно этот поход позволяет предоставить новые возможности туннелирования гораздо большему числу клиентов, попутно позволяя администратору существенно повысить безопасность всей системы при помощи простых настроек. Например, автоматически перенаправить весь трафик HTTP через шлюз протокола HTTPS или вынудить использующих радиоканал клиентов обращаться к туннелю через протокол РРТР (Point-to-Point Tunneling Protocol -протокол двухточечного туннеля. Новая сетевая технология, которая поддерживает многопротокольные виртуальные частные сети (VPN), позволяя удаленным пользователям безопасно обращаться к корпоративным сетям с помощью коммутируемого соединения, предоставляемого провайдером Интернет или с помощью прямого подключения к

Интернету), который является стандартом в операционных системах клиентов.

А наиболее мощные и наименее удобные решения туннелирования требуют инсталляции специального программного обеспечения на сервере и клиенте одновременно. Следует подчеркнуть, что используемое здесь слово специальное подразумевает изящное решение для достижения невозможного. Иногда невозможно достигнуть определенных результатов без одновременного распространения «цены» решения туннелирования на клиента и сервер.

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

Гибкость: «Какие еще существуют варианты использования туннеля?»

Основополагающими вопросами, на которые следует ответить при рассмотрении этого требования, являются следующие:

• что может передаваться по анализируемому туннелю;

• следует ли ожидать неприятностей от чрезмерно большой пропускной способности туннеля?

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

Многие системы просто инкапсулируют битовый поток данных в криптоуровень независимо от того, сделаны они с помощью подручных средств наспех или это профессионально выполненная работа. Протокол TCP, являющийся системой надежного обмена данными между хостами, обращается к необходимому ему программному обеспечению через интерфейс сокетов. Создается ощущение, что протокол защищенных сокетов SSL с самого начала предназначался как более удобная замена стандартных сокетов, но всякого рода несовместимости помешали осуществлению этой затеи. (Также создается впечатление, что в конечном счете SSL собирается стать «функциональным решателем проблем», то есть системой, которая будет автоматически преобразовывать все обращения к сокетам в вызовы протокола SSL.)

При проектировании систем туннелирования может быть использован протокол SSH. Наибольшую производительность систем туннелирования можно достичь при переадресации (forwarding) TCP-сессий. Реализация протокола SSH предусматривает поддержку очень широкого диапазона передаваемых данных, начиная от трафика протокола TCP и заканчивая командами командного процессора для Х-приложений, которые могут быть выданы чрезвычайно гибким способом, настраиваемого по мере необходимости. Подобная гибкость делает протокол SSH весьма привлекательным для многих решений туннелирования, хотя и не бесплатно.

Остроумное замечание. Отличающиеся высокой гибкостью решения туннелирования могут страдать от излишней пропускной способности. Сказанное известно как проблема «излишней пропускной способности». Другими словами, если установка туннеля преследовала какую-то цель, то не может ли одна из сторон туннеля воспользоваться соединением для получения больших прав доступа, чем ей доверяют на самом деле?

Несмотря на то что протокол X-Windows на платформе UNIX несколько неуклюж, он является разумной архитектурой графических приложений, используемой для многооконного отображения графики и текста. Одним из его самых больших достоинств является сетевая прозрачность. Окно приложения не обязательно должно быть отображено на компьютере, на котором оно было запущено. Идея заключается в том, что медленные и недорогие аппаратные средства для работы пользователей могут быть развернуты в сети где угодно. Для пользователя это не важно. Но каждое из выполняющихся на них приложений будет «казаться» быстрым, потому что на самом деле приложения выполняются на очень быстром и дорогом сервере, расположенном вдали от любопытных глаз. (Подобные решения годятся для автоматизации задач бизнеса, потому что намного проще получить высокую прибыль на большом сервере, чем на небольших настольных компьютерах. Совсем недавно это своеобразное «вращение карусели» с различным успехом было повторено в Web-сетях, сетевых компьютерах Java и, конечно, в архитектуре. NET.)

Одними из наиболее больших проблем существующих версий X-Windows являются отсутствие в них средств шифрования и, что еще хуже, сложность использования предлагаемых ими средств аутентификации, которые не обеспечивают нужной безопасности (в конце концов, они сводятся к простой проверке способности ответить). Тату Ялонен (Tatu Ylonen) в своем пакете, развивающем возможности прекрасного пакета Secure Shell (SSH), для повышения гибкости безопасной организации сети включил в него очень элегантное решение продвижения данных Х-приложений (приложений, работающих по протоколу X-Windows) к месту использования (X-Forwarding). Туннелирование Х-трафика по виртуальному отображению туннеля через протокол SSH - сложная и в конечном счете бесполезная процедура управления переменными DISPLAY. Аргументы xhost/xauth были заменены простым вводом ssh user@host и запуском Х-приложения при помощи командного процессора. Защита - это прекрасно, но давайте скажем откровенно: «Вопреки ожиданиям только это и сработало!»

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

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

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

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

Возможное решение состояло в отключении возможности продвижения данных Х-приложений по умолчанию. В настоящее время в OpenSSH реализована команда ssh - X user@host, которая делает это при условии реализации точно такой же возможности на сервере. (Нет, это еще не законченное решение. В случае возникновения у клиента необходимости отправки Х-трафика скомпрометированный сервер все еще может попытаться эксплуатировать клиента с нарушением установленных режимов работы. Но на некотором этапе проблема превращается в проблему собственно Х-трафика, и в большинстве сессий протокол SSH ничего не может с этим поделать. Большинство сессий может быть сделано безопасными простым отключением опции по умолчанию. Гораздо более безопасным решением является пересылка Х-трафика при помощи программного обеспечения 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 и серии приложений г*. Пакет OpenSSH - невероятно гибкая реализация одного из трех пользующихся доверием протоколов обмена информацией (другими двумя являются протоколы SSL и IPSec).

Конфиденциальность. OpenSSH - один из оплотов обеспечения безопасности из класса программ с открытыми исходными текстами. Зачастую это единственная доступная точка входа в некоторые наиболее параноидные сети, окружающие нас. Заложенная в первой версии протокола SSH идея доверия после нескольких лет интенсивного анализа была тщательно изучена. OpenSSH является законченной реализацией протокола SSH2 с полностью открытым кодом и занимает уникальную позицию как единственно надежный путь миграции от SSH1 к SSH2 (эта возможность первоначальными создателями протокола SSH была безнадежно испорчена). Все перечисленное сделало OpenSSH стандартом реализации SSH в Интернете. В таблице 13.1 приведены типы криптографии и криптографические алгоритмы, поддерживаемые OpenSSH.

Таблица 13.1.

Типы криптографии и криптографические алгоритмы, поддерживаемые OpenSSH

Тип криптографии Поддерживаемые криптографические

алгоритмы
Симметричная криптография
3DES, AES. Blowfish. ARCFOUR (RC4)
(групповое шифрование}

Асимметричная криптография
RSA DSA
(обмен ключами}


Тип криптографии Поддерживаемые криптографические

алгоритмы
Аутентификация асимметричный ключ пользователя
{клиента серверу} асимметричный ключ хоста

пароль

Трассируемость. Весь трафик уплотнен в единое исходящее ТСР-соединение. Большинство сетей позволяет передавать через них исходящий трафик по протоколу SSH (через двадцать второй порт протокола TCP - 22/ТСР). Функциональные возможности опции ProxyCommand предоставляют удобный интерфейс для маскировки трафика и применяемых редиректоров (редиректор (redirector) - сетевое программное обеспечение, эмулирующее доступ прикладных программ к удаленной файловой системе так, как будто это локальная), как, например, редиректор протокола SOCKS или инкапсулятор трафика по протоколу HTTP.

Удобство. В большинстве современных систем UNIX серверный и клиентский код инсталлируется по умолчанию. Пакет OpenSSH переносится на большое число платформ, включая Win32.

Гибкость. Способность пакета OpenSSH к бесшовной, цельной инкапсуляции широкого диапазона передаваемых данных (см. табл. 13.2) означает, что следует предпринять дополнительные меры предосторожности для предотвращения доступа к запрещенным ресурсам со стороны клиентов, которым доверяют лишь частично. Запретный плод всегда сладок. Одним из главных недостатков пакета OpenSSH является его неспособность к внутреннему преобразованию одного контекста инкапсуляции к другому. Это означает отсутствие возможности непосредственного подключения вывода команды через сетевой порт.

_Таблица 13.2. Типы инкапсуляции в пакете Орегон_

Тип инкапсуляции Возможное использование
Командная оболочка UNIX Интерактивное удаленное администрирование
Команда FORWARDING Удаленная запись на CD. автоматическое

создание резервных копий, управление

кластерами
Статическая переадресация Однохостовые сетевые сервисы, как, напри
TCP-порта мер, IRC, Mail, VNC и (очень) ограниченный

Web-трафик
Тип инкапсуляции Возможное использование
Динамическая переадре Многохостовые и многопортовые сетевые
сация ТСР-порта сервисы, как, например, Web-серфинг (Web surfing), системы соединения полноправных узлов P2P и системы передачи речевой информации при помощи протокола 1Р
Продвижение данных Удаленный доступ к графическим
Х-приложений приложениям UNIX

Качество. В целом пакет 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.0р2 или более ранней. В перечисленных пакетах реализация 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 “A]”.

SSH-1.99-OpenSSH_3.0.1pl

Другим важным замечанием является то, что 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 -si 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. Обе программы компактны, быстры, наделены хорошими функциональными возможностями, а стиль их написания производит приятное впечатление.

Генерация пакета: поиск следующего «прыжка». | Защита от хакеров корпоративных сетей | Сезам, откройся: аутентификация


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



Новости за месяц

  • Август
    2019
  • Пн
  • Вт
  • Ср
  • Чт
  • Пт
  • Сб
  • Вс