Коллектив авторов - Защита от хакеров корпоративных сетей
Вопрос: Какие инструментальные средства спуфинга доступны? Ответ: Большинство инструментальных средств спуфинга относятся к сфере сетевых средств. Например, в главе 11 рассказано об использовании инструментальных средств, которые могут как фальсифицировать, так и перехватывать (похищать) сессии, решая задачи активного спуфинга. Другие инструментальные средства спуфинга предназначены для работы с DNS, IP, SMTP и многим другим.
Вопрос: Существуют ли способы проверки получения фальсифицированных пакетов? Ответ: Как правило, фальсифицированные пакеты посылаются вслепую, поэтому «хост отправителя» будет вести себя подозрительно, будто он и вправду не получает никаких ответов на свои пакеты. Забавно, не правда ли? Но только что был обнаружен блестящий способ простого и в разумной степени надежного определения, является ли пакет, полученный от другого отправителя, фальсифицированным. Принцип работы программы Despoof, разработанной печально известным Simple Nomad, основан на следующем простом предположении: нападающий не знает числа сетевых «прыжков» (ближайших маршрутизаторов, находящихся на расстоянии одного «прыжка»), которые нужно совершить хосту для передачи пакета адресату. Поскольку в большинстве случаев маршрутизация в Интернете симметрична, то число «прыжков» к выбранному хосту дает адекватную оценку числа «прыжков», необходимых для ответного сообщения. (Ошибочно полагать, что при простом прозванивании хоста утилитой ping и контроле числа вычитаний единицы из значения счетчика предписанного времени жизни пакета TTL во время обратного путешествия пакета будет получено верное значение числа «прыжков» до хоста адресата. На самом деле будет возвращено число «прыжков», далекое от истинного значения.) Вот что интересно. Злоумышленник не сможет проверить сеть между хостом читателя и фальсифицируемым им узлом. Сравнивая число «прыжков» во время путешествия тестирующего пакета с установленным числом фактически сделанных «прыжков», можно определить, что пакет передавался от отправителя до адресата по неправильному маршруту, и поэтому вполне возможно, что он фальсифицирован. Число «прыжков» во время путешествия тестирующего пакета можно определить по значению ORIGINAL_TTL-TTL_OF_PACKET, которое обычно равно двум в степени некоторого смещения минус число между единицей и двенадцатью. Достаточно интересно, что таким образом можно что-то узнать о фальсификаторе, потому что число пройденных «прыжков» характеризует его сетевой путь. Конечно, фальсификатор вполне может фальсифицировать исходную величину счетчика предписанного времени жизни пакета TTL, для того чтобы защитить себя от такого сетевого мониторинга. Но пока злоумышленник не знает о возможности подобных действий, он так делать и не будет. Если не будут выполнены какие-либо отвлекающие действия, то можно определить, что злоумышленный трафик начинается с середины маршрута, как будто это сетевая атака. Конечно, это вопрос выбора рисков читателя. Программу Despoof можно найти по адресу http://razor.bindview.com/tools/desc/despoof_readme.html. Это действительно интересное инструментальное средство.
Вопрос: Каким образом атакующий сможет перенаправить сетевой трафик так, чтобы он казался пришедшим от других хостов? Ответ: Простейшие и наиболее эффективные способы захвата хоста одной и той же физической подсети описаны в главе 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, отражая потребности обслуживаемых сетей.
