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

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

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

Вопрос: Есть ли хорошие решения противодействия спуфингу?

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

Вопрос: Какие инструментальные средства спуфинга доступны? Ответ: Большинство инструментальных средств спуфинга относятся к сфере сетевых средств. Например, в главе 11 рассказано об использовании инструментальных средств, которые могут как фальсифицировать, так и перехватывать (похищать) сессии, решая задачи активного спуфинга. Другие инструментальные средства спуфинга предназначены для работы с DNS, IP, SMTP и многим другим.

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

программы Despoof, разработанной печально известным Simple Nomad, основан на следующем простом предположении: нападающий не знает числа сетевых «прыжков» (ближайших маршрутизаторов, находящихся на расстоянии одного «прыжка»), которые нужно совершить хосту для передачи пакета адресату. Поскольку в большинстве случаев маршрутизация в Интернете симметрична, то число «прыжков» к выбранному хосту дает адекватную оценку числа «прыжков», необходимых для ответного сообщения. (Ошибочно полагать, что при простом прозванивании хоста утилитой ping и контроле числа вычитаний единицы из значения счетчика предписанного времени жизни пакета TTL во время обратного путешествия пакета будет получено верное значение числа «прыжков» до хоста адресата. На самом деле будет возвращено число «прыжков», далекое от истинного значения.) Вот что интересно. Злоумышленник не сможет проверить сеть между хостом читателя и фальсифицируемым им узлом. Сравнивая число «прыжков» во время путешествия тестирующего пакета с установленным числом фактически сделанных «прыжков», можно определить, что пакет передавался от отправителя до адресата по неправильному маршруту, и поэтому вполне возможно, что он фальсифицирован. Число «прыжков» во время путешествия тестирующего пакета можно определить по значению ORIGINAL_TTL-TTL_OF_PACKET, которое обычно равно двум в степени некоторого смещения минус число между единицей и двенадцатью. Достаточно интересно, что таким образом можно что-то узнать о фальсификаторе, потому что число пройденных «прыжков» характеризует его сетевой путь. Конечно, фальсификатор вполне может фальсифицировать исходную величину счетчика предписанного времени жизни пакета TTL, для того чтобы защитить себя от такого сетевого мониторинга. Но пока злоумышленник не знает о возможности подобных действий, он так делать и не будет. Если не будут выполнены какие-либо отвлекающие действия, то можно определить, что злоумышленный трафик начинается с середины маршрута, как будто это сетевая атака. Конечно, это вопрос выбора рисков читателя. Программу Despoof можно найти по адресуЭто действительно интересное инструментальное средство.

Вопрос: Каким образом атакующий сможет перенаправить сетевой трафик так, чтобы он казался пришедшим от других хостов? Ответ: Простейшие и наиболее эффективные способы захвата хоста одной и той же физической подсети описаны в главе 11. Изредка возможно похищение сетевого трафика вне подсети при помощи компрометации промежуточных маршрутизаторов, но наиболее часто это осуществляется с помощью DNS-серверов. Дэвид Уелевич (David Uelevich), основатель Everydns.Net, пишет: «Когда ищется запись домена на сервере имен, то это обычно сервер имен клиентской сети, который осуществляет поиск и по очереди возвращает ответ клиенту. Проблема с «отравлением» DNS возникает в случае, когда сервер имен клиентов воспринимает неверную информацию от удаленного сервера, который либо преднамеренно, либо случайно бездумно раздает коды возврата, изменяющие поведение клиентов сервера имен». Помните, IP-адреса обычно не указывают непосредственно на адресата. (Действительно, в протоколе IPV6 почти невозможно непосредственно указать адресата. Длина адресов в протоколе IPV6 почти в 4 раза длиннее IP-адреса в протоколе IPV4.) Обычно на адресата ссылаются по DNS-имени. Компрометация отображения DNS-имен в IP-адреса будет иметь тот же самый эффект, как если бы оказалось взломано соответствие между приятелем читателя и его телефонным номером. В конце концов, читатель сможет распознать, что на другом конце линии находится не его приятель, а кто-то другой, но компьютер – нет, за исключением, пожалуй, случая использования для такой попытки подключения протокола SSL. В подобном случае нападающий, как брокер соединения, может законным образом перенаправить читателя к его фактическому адресату.

Вопрос: Достаточно ли протокол 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 и принципа межсетевого шифрования.

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

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