Защита от хакеров корпоративных сетей
Шрифт:
Вопрос: Достаточно ли протокол SSL защищен от спуфинга? Ответ: Это хороший протокол, надежность которого определяется корректной реализацией (по крайней мере, в настоящее время придерживаются такой точки зрения). Но не здесь кроется опасность. Протокол SSL основан на цепочке заверяющих подписей в соответствии с инфраструктурой открытого ключаРЮ (PublicKey Infrastructure). Если читатель смог бы незаметно вставить собственную копию Netscape в тот момент, когда кто-либо обновляет его в режиме автоматического обновления, то у него появилась бы возможность включить собственный ключ подписи для «VeriSign» и претендовать на то, чтобы стать любым сервером HTTPS в мире. С другой стороны, большому числу международных и главным образом неизвестных компаний доверяют только потому, что «VeriSign» хранит их ключи подписи в безопасности. Сомнительно, что многие заботятся о своей безопасности в той же мере, как «VeriSign» заявляет о безопасности их секретных ключей. Компрометация любого из этих международных провайдеров будет эквивалентна ущербу от компрометации ключа «VeriSign». Тот, кто сможет добиться успеха при фальсификации, может стать кем угодно. Вызывает беспокойство и то, что SSL не может всегда оставаться передовым средством обеспечения безопасности. Компрометация ключа в будущем, которая в настоящее время практически невозможна, немедленно сделает сегодняшний трафик общедоступным завтра. В этом заключается позорная уязвимость, которой нет места в главном стандарте криптографической защиты.
Глава 13 Туннелирование
В этой главе обсуждаются следующие темы:
• Основные требования к системам туннелирования
• Проектирование сквозных систем туннелирования
• Сезам,
• Переадресация команд: применение переадресации команд для непосредственного выполнения скриптов и каналов
• Переадресация портов: доступ к ресурсам удаленных сетей
• Когда-то в Риме: пересекая непокорную сеть
• На полпути: что теперь?
· Резюме
· Конспект
· Часто задаваемые вопросы
Введение
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…»
Dante\'s. 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 можно рассматривать как реакцию на возникшую потребность в эффективном подключении и устранении пустой траты времени на бюрократические проволочки во время получения доступа к пространству IP-адресов.И неожиданно опять всплыли старые проблемы взаимосвязей и соединений отдельных хостов. Как всегда, старые проблемы извлекли на свет их старые решения. В результате была повторно рождена идея туннелирования.
Но теперь это несколько иное решение, отличающееся от использованного ранее. Больше, чем что-либо другое, туннелирование в XXI веке имеет отношение к виртуализации отсутствия соединения при помощи разумного использования криптографии. В своем развитии идея туннелирования совершила нечто, похожее на рабочий ход маятника. Вначале глобальный сетевой доступ был сильно ограничен, затем он был разрешен повсеместно, потом требования к соединениям, обеспечивающим глобальный доступ, были ужесточены, и наконец дыры в системе защиты были залатаны с помощью систем, спроектированных с достаточно хорошим криптографическим обеспечением. Они были разработаны с помощью тех методов, которым авторы надеются научить читателя в этой главе. Эти методы несовершенны, и о них мало говорят. Иногда они построены на малоизвестных принципах, иногда не вполне пристойны и легитимны, но они работают. Задача авторов состоит в описании средств передачи и получения данных. Для этого в главе описано применение протокола SSH и принципа межсетевого шифрования.Основные требования к системам туннелирования
Определение соответствующего метода туннелирования между сетями является проблемой, которая далека от тривиальной. Выбор подходящего решения среди широкого диапазона доступных протоколов, пакетов и возможных настроек может превратиться в чрезвычайно сложную задачу, отпугивающую своей запутанностью. Эта глава преследует цель описать некоторые самые современные механизмы, пригодные для установки соединения в любых сетевых архитектурах. Наравне с этим важно понять, что именно делает выбранное решение туннелирования жизнеспособным. Может быть реализовано неисчислимое число способов. Приведенные в главе подсказки помогут читателю узнать, что так или иначе должно быть реализовано в каждом конкретном случае.
Не стоит строить иллюзий относительно приведенных в главе сведений. Зачастую туннелирование является способом обхода чрезмерно строгого контроля за безопасностью. Не всегда это плохо. Помните, целью существования компании является не обеспечение своей безопасности ради самой безопасности. Обанкротившаяся компания небезопасна, особенно когда она получает доступ к записям пользователя. Но очень трудно возражать против ограничений чужой системы обеспечения безопасности, если собственное решение страдает вызывающими изъянами защиты. При атаке на защищенный межсетевым экраном туннель ключом к необходимым для нее разрешениям (другими словами, к отпущению грехов атакующего) является понимание вопросов обеспечения безопасности межсетевого экрана. Прежде всего вопросов, связанных с адресацией. Их понимание притупляет обвинения в адрес пользователя как единственного ответственного за нанесение системе ущерба. Особенно это касается корпоративной сферы. Далее рассмотрим наиболее важные требования, предъявляемые к проектируемым системам туннелирования.
Инструментарий и ловушки
Инкапсуляция против интеграции
Для обеспечения безопасности соединения между двумя хостами существуют два основных подхода. Первый подход состоит в инкапсуляции незашифрованной линии связи внутри предназначенной для этого системы. Второй – заключается в интеграции (встраивании) криптографической подсистемы в протокол, который приложение предполагает использовать. Обычно к интеграции разработчика подталкивает желание самостоятельно все сделать самому. Вполне возможно, что он так делает для того, чтобы полностью вылизать уже написанный программный код, подгоняя его под специальные требования. Например, достижение межпакетной независимости, общедоступной возможности частичной расшифровки данных или доверительного хранения ключа, когда некоторые участники обмена сохраняют возможность расшифровки трафика, находясь при этом вне рамок сквозного маршрута передачи данных.
Дальше будет рассказано о недостатках инкапсуляции, которыми могут воспользоваться злоумышленники. Но они ничто по сравнению с запутанной историей развития интеграции. Никто не поверит производителю, если он создаст свой собственный алгоритм шифрования (даже если это будет алгоритм шифрования с 4096-битным ключом). Точно так же вызовет оправданное недоверие производитель, который спроектирует свою собственную замену протоколу защищенных сокетов SSL. Разумный подход заключается в том, что большей части программного обеспечения нельзя доверять управление паролями. Основанные на здравом смысле проверки, преследующие цель не допустить проникновения Троянских коней в систему, в основном относятся к общим вопросам обеспечения безопасности, а не к проектированию систем коммуникации, которые надежно защищены от проникновения в них злоумышленника.
Читателю необходимо понять, что проектирование систем безопасности на самом деле сильно отличается от проектирования других систем. В большинстве случаев код пишется для добавления каких-либо возможностей: визуализировать изображение, оживить его, напечатать документ. Напротив, код системы безопасности предназначен для запрещения возможностей: не позволить взломать систему, предотвратить пустую трату бумаги. Все, что предоставляет функциональность, безопасность забирает обратно. В большинстве случаев это касается не пользующихся доверием пользователей, то есть недоверяемых пользователей (untrusted user), но всегда что-то отнимается и от пользующихся доверием пользователей – доверяемых пользователей (trusted user). Точно так же, как многие газеты нашли успешную модель «Китайской стены» между редакционным отделом, который формирует круг читателей, и отделом рекламы, который перепродает сформированный редакционным отделом читательский спрос, протоколы безопасности извлекают выгоду из ограничения в доступе с одновременным расширением предоставляемых ими же возможностей. В рамках инкапсуляции предложено использовать так называемую «песочницу», реализующую механизм обеспечения безопасности подкачанных из сети или полученных по электронной почте программ. Этот механизм предусматривает изоляцию на время выполнения загружаемого кода в ограниченной среде-«песочнице». Иногда эта «песочница» может потребовать большего доверия, чем на самом деле предоставлено участникам обмена, но, по крайней мере, в нее заложен предел доверия, который не может быть превышен.
Описанные в данной главе системы объединяют методы, пригодные для инкапсуляции произвольного содержимого.
Конфиденциальность: «Куда уходит мой трафик?»
Основополагающими вопросами сохранения тайны коммуникаций, другими словами, их конфиденциальности, являются следующие:
• может ли еще кто-либо контролировать мой трафик внутри туннеля? Ответ на этот вопрос предполагает наличие доступа по чтению к передаваемым по туннелю данным, который может быть получен при предоставлении кому-либо возможности расшифровать передаваемые данные;
• может ли еще кто-либо модифицировать трафик внутри туннеля или скрытно получить к нему доступ? Это не что иное, как получение доступа по записи к передаваемым по туннелю данным, который в основном может быть получен при помощи выполнения процедуры аутентификации (удостоверения подлинности).
Сохранение тайны коммуникаций лежит в основе проектирования любого безопасного туннеля передачи данных. До известной степени, не зная участников, которые передают данные по туннелю, пользователь не знает, ни куда по туннелю отправляются данные, ни как они были получены ранее. Труднейшие проблемы проектирования систем туннелирования связаны с достижением крупномасштабного уровня безопасности «многие ко многим» («п-к-п»). Этого не удастся достичь до тех пор, пока системе не станут полностью доверять, считая ее безопасным решением, потому что это единственное, что сможет убедить людей начать ее использовать.