Отсутствие в Internet возможности контроля за маршрутом сообщений

Невозможность контроля в сети Internet за виртуальными каналами обуславливается отсутствием в сети контроля за маршрутом сообщений, а именно, в существующем стандарте IPv4 невозможно по пришедшему на хост сообщению определить путь, через который оно прошло, следовательно, невозможно проверить подлинность адреса отправителя (п. 4.6).

Отсутствие в РВС криптозащиты сообщений

В распределенных ВС связь между объектами системы осуществляется по каналам связи. Поэтому всегда существует принципиальная возможность для атакующего прослушать канал и получить несанкционированный доступ к информации, которой обмениваются по сети ее абоненты (п. 3.2.1 и п. 4.1). В том случае, если проходящая по каналу информация не зашифрована и атакующий каким-либо образом получает доступ к каналу, то УА "Анализ сетевого трафика" является наиболее эффективным способом получения информации. Очевидна и причина, делающая эту атаку столь эффективной. Эта причина - передача по сети незашифрованной информации.

Использование криптостойких алгоритмов шифрования пакетов обмена между объектами РВС на канальном, прикладном уровнях делает анализ сетевого трафика практически бессмысленным. В случае канального шифрования, которое обычно выполняется аппаратно, по сети передаются полностью зашифрованные пакеты. В том случае, если в сети используются алгоритмы шифрования пакетов на сетевом - прикладном уровнях, то шифрация применяется только к полям данных пакетов соответствующих уровней, то есть заголовки пакетов, содержащие служебную информацию, не являются зашифрованными, поэтому атакующий имеет возможность, перехватив пакет, подвергнуть анализу данную служебную информацию.

Отсутствие в РВС полной информации о ее объектах

В распределенной системе с разветвленной структурой, состоящей из большого числа объектов, может возникнуть ситуация, когда для доступа к определенному объекту системы у субъекта взаимодействия может не оказаться необходимой информации об интересующем объекте (п. 3.2.3.2). Обычно такой недостающей информацией об объекте является его адрес. Такая ситуация характерна и вполне объяснима для сетей с разветвленной структурой.

Объясним это на простом примере. Предположим, что пользователь сети Internet решил подключиться, например, к WWW-серверу фирмы Novell. Он знает ее название, но не имеет информации об IP-адресе или имени ее сервера. В этом случае пользователь может послать широковещательный запрос всем хостам в сети с надеждой, что запрос дойдет до интересующего его сервера, и тот в ответ пришлет столь нужный для пользователя адрес. Очевидно, что в глобальной сети использование данной схемы по меньшей мере неразумно. Поэтому для подобных целей пользователь может подключиться к ближайшему известному ему поисковому серверу (Altavista, например) и послать запрос на поиск адреса интересующей его фирмы в базе данных информационного сервера.

Рассмотренный выше пример наглядно описывает возможные алгоритмы удаленного поиска (понятие удаленного поиска введено в п. 3.2.3.2), которые используют объекты РВС. В первом случае, когда поиск осуществляется внутри сегмента сети, субъект системы посылает широковещательный запрос, который получают все объекты РВС, и тот из них, для кого предназначался запрос, передает в ответ необходимую для адресации информацию. Во втором случае, когда необходимо осуществить глобальный поиск, субъект распределенной системы посылает запрос на ближайший информационно-поисковый сервер, который, просканировав свою базу данных в поисках адреса запрашиваемого ресурса, либо отошлет в ответ на запрос найденный адрес, либо обратится к следующему в системе поисково-информационному серверу. Таким образом, если в распределенной ВС существуют объекты, информация о которых не определена, то для обеспечения ее нормального функционирования необходимо использование описанных выше алгоритмов удаленного поиска.

Примером РВС с заложенной неопределенностью является сеть Internet, в которой, во-первых, у хостов, находящихся в одном сегменте, может не быть информации об аппаратных адресах друг друга (см. УА в п. 4.2), и, во-вторых, применяются непригодные для непосредственной адресации мнемонические имена хостов, используемые для удобства пользователей при обращении к удаленным системам (см. УА в п. 4.3).

На наш взгляд, очевиден тот факт, что в системе с заложенной в нее неопределенностью существуют потенциальные возможности внесения в систему ложного объекта и выдачи одного объекта системы за другой (см. УА в п. 3.2.3, 4.2, 4.3). Этот факт объясняется тем, что, являясь следствием неопределенности системы, алгоритмы удаленного поиска несут в себе потенциальную угрозу, состоящую в том, что на посланный запрос может прийти ложный ответ, в котором вместо информации о запрашиваемом объекте будет информация о ложном объекте. Вследствие этого распределенная ВС с заложенной неопределенностью является потенциально опасной системой и может подвергаться удаленным атакам.

Отсутствие в РВС возможности контроля за маршрутом сообщений

В распределенных ВС в качестве начальной идентифицирующей объект информации обычно выступает его адрес. Под адресом в РВС понимается определенная системой уникальная информация, которой он наделяется при внесении в систему. Теперь все сообщения от других объектов РВС, адресованные на этот адрес, поступят на данный объект. Путь, или, как принято говорить, маршрут сообщения определяется топологией РВС и проходит через совокупность узлов-маршрутизаторов. Следовательно, в каждом приходящем на объект РВС пакете может быть полностью отмечен его маршрут - список адресов маршрутизаторов, пройденных на пути к адресату. Этот отмеченный в пакете маршрут станет информацией, аутентифицирующей (подтверждающей) с точностью до подсети, подлинность адреса субъекта, отославшего сообщение. Другой вариант аутентификации адреса отправителя - фильтрация маршрутизатором пакетов с неверным адресом отправителя (п. 6.3).

Если в РВС не предусмотреть подобных возможностей контроля за маршрутом сообщения, то адрес отправителя сообщения оказывается ничем не подтвержден. Таким образом, в системе будет существовать возможность отправки сообщения от имени любого объекта системы, а именно путем указания в заголовке сообщения чужого адреса отправителя (см. атаки в п. 4.3-4.6). Также в подобной РВС будет невозможно определить, откуда на самом деле пришло сообщение, а, следовательно, вычислить координаты атакующего (в сети Internet невозможно доступным способом вычислить инициатора однонаправленной удаленной атаки).

Таким образом, мы убеждаемся, что отсутствие в распределенной ВС возможности контроля за маршрутом сообщений порождает, во-первых, невозможность контроля за созданием соединений, и, во-вторых, возможность анонимной отправки сообщения, следовательно является причиной успеха удаленных атак на РВС.

Отсутствие выделенного канала связи между объектами РВС

В п. 3.2.1 была рассмотрена типовая УА "Анализ сетевого трафика" . Кратко напомним, что данная атака заключается в прослушивании канала передачи сообщений в сети. Результат этой атаки во-первых, выяснение логики работы распределенной ВС и, во-вторых, перехват потока информации, которой обмениваются объекты системы. Такая атака программно возможна только в случае, если атакующий находится в сети с физически широковещательной средой передачи данных как, например, всем известная и получившая широкое распространение среда Ethernet (в отличие от Token Ring, которая не является широковещательной, но и не имеет достаточного распространения). Очевидно, что данная УА была бы программно невозможна, если бы у каждого объекта системы существовал для связи с любым другим объектом выделенный канал (вариант физического прослушивания выделенного канала не рассматривается, так как без специфических аппаратных средств подключение к выделенному каналу невозможно).

Следовательно, причина успеха данной типовой УА - наличие широковещательной среды передачи данных или отсутствие выделенного канала связи между объектами РВС.

Глобальная сеть не может быть построена по принципу прямой связи между объектами системы, то есть невозможно для каждого объекта обеспечить выделенный канал для связи с любым другим объектом системы. Поэтому в Internet связь осуществляется через цепочку маршрутизаторов, а, следовательно, сообщение, проходя через большое количество промежуточных подсетей, может быть перехвачено. Также к Internet подключено большое число локальных Ethernet-сетей, использующих топологию "общая шина" . В сетях с такой топологией несложно программно осуществлять перехват всех сообщений в сети. Однако данный недостаток присущ скорее не Internet, а Ethernet.

По цели воздействия

нарушение конфиденциальности информации либо ресурсов системы (класс 2.1)

нарушение целостности информации (класс 2.2)

нарушение работоспособности (доступности) системы (класс 2.3)

Этот классификационный признак является прямой проекцией трех основных типов угроз - раскрытия, целостности и отказа в обслуживании.

Основная цель практически любой атаки - получить несанкционированный доступ к информации. Существуют две принципиальные возможности доступа к информации: перехват и искажение. Возможность перехвата информации означает получение к ней доступа, но невозможность ее модификации. Следовательно, перехват информации ведет к нарушению ее конфиденциальности. Примером перехвата информации может служить прослушивание канала в сети (п. 3.2.1). В этом случае имеется несанкционированный доступ к информации без возможности ее искажения. Очевидно также, что нарушение конфиденциальности информации является пассивным воздействием.

Возможность искажения информации означает либо полный контроль над информационным потоком между объектами системы, либо возможность передачи сообщений от имени другого объекта. Таким образом, очевидно, что искажение информации ведет к нарушению ее целостности. Данное информационное разрушающее воздействие представляет собой яркий пример активного воздействия. Примером удаленной атаки, цель которой нарушение целостности информации, может служить типовая удаленная атака (УА) "Ложный объект РВС" (п. 3.2.3).

Принципиально другой целью атаки является нарушение работоспособности системы. В этом случае не предполагается получение атакующим несанкционированного доступа к информации. Его основная цель - добиться, чтобы операционная система на атакуемом объекте вышла из строя и для всех остальных объектов системы доступ к ресурсам атакованного объекта был бы невозможен. Примером удаленной атаки, целью которой является нарушение работоспособности системы, может служить типовая УА "Отказ в обслуживании" (п. 3.2.4).

По характеру воздействия

пассивное (класс 1.1)

активное (класс 1.2)

Пассивным воздействием на распределенную вычислительную систему назовем воздействие, которое не оказывает непосредственного влияния на работу системы, но может нарушать ее политику безопасности. Именно отсутствие непосредственного влияния на работу распределенной ВС приводит к тому, что пассивное удаленное воздействие практически невозможно обнаружить. Примером пассивного типового удаленного воздействия в РВС служит прослушивание канала связи в сети.

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

По наличию обратной связи с атакуемым объектом

с обратной связью (класс 4.1)

без обратной связи (однонаправленная атака) (класс 4.2)

Удаленная атака, осуществляемая при наличии обратной связи с атакуемым объектом, характеризуется тем, что на некоторые запросы, переданные на атакуемый объект, атакующему требуется получить ответ, а, следовательно, между атакующим и целью атаки существует обратная связь, которая позволяет атакующему адекватно реагировать на все изменения, происходящие на атакуемом объекте. Подобные удаленные атаки наиболее характерны для распределенных ВС.

В отличие от атак с обратной связью удаленным атакам без обратной связи не требуется реагировать на какие-либо изменения, происходящие на атакуемом объекте. Атаки данного вида обычно осуществляются передачей на атакуемый объект одиночных запросов, ответы на которые атакующему не нужны. Подобную УА можно называть однонаправленной удаленной атакой. Примером однонаправленных атак является типовая УА "Отказ в обслуживании" (п. 3.2.4), а также атаки, рассмотренные в п. 4.3, 4.4 и 4.6.

По расположению субъекта атаки относительно атакуемого объекта

внутрисегментное (класс 5.1)

межсегментное (класс 5.2)

Рассмотрим ряд определений:

Субъект атаки (или источник атаки) - это атакующая программа или оператор, непосредственно осуществляющие воздействие.

Хост (host) - сетевой компьютер.

Маршрутизатор (router) - устройство, обеспечивающее маршрутизацию пакетов обмена в глобальной сети.

Подсеть (subnetwork) (в терминологии Internet) - совокупность хостов, являющихся частью глобальной сети, для которых маршрутизатором выделен одинаковый номер подсети. Подсеть - логическое объединение хостов маршрутизатором. Хосты внутри одной подсети могут взаимодействовать между собой непосредственно, минуя маршрутизатор.

Сегмент сети - физическое объединение хостов. Например, сегмент сети образуют совокупность хостов, подключенных к серверу по схеме "общая шина" . При такой схеме подключения каждый хост имеет возможность подвергать анализу любой пакет в своем сегменте.

С точки зрения удаленной атаки чрезвычайно важно, как по отношению друг к другу располагаются субъект и объект атаки, то есть в одном или в разных сегментах они находятся. В случае внутрисегментной атаки, как следует из названия, субъект и объект атаки находятся в одном сегменте. Пример такой атаки приведен в п. 4.1 и 4.2. При межсегментной атаке субъект и объект атаки находятся в разных сегментах. Примеры в п. 4.3-4.6.

Данный классификационный признак позволяет судить о так называемой "степени удаленности" атаки.

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

По уровню эталонной модели ISO/OSI, на котором осуществляется воздействие

физический (класс 6.1)

канальный (класс 6.2)

сетевой (класс 6.3)

транспортный (класс 6.4)

сеансовый (класс 6.5)

представительный (класс 6.6)

прикладной (класс 6.7)

Международная Организация по Стандартизации (ISO) приняла стандарт ISO 7498, описывающий взаимодействие открытых систем (OSI). Распределенные ВС также являются открытыми системами. Любой сетевой протокол обмена, как и любую сетевую программу, можно с той или иной степенью точности спроецировать на эталонную семиуровневую модель OSI. Такая многоуровневая проекция позволит описать в терминах модели OSI функции, заложенные в сетевой протокол или программу. Удаленная атака также является сетевой программой. В связи с этим представляется логичным рассматривать удаленные атаки на распределенные ВС, проецируя их на эталонную модель ISO/OSI.

По условию начала осуществления воздействия

Удаленное воздействие, также как и любое другое, может начать осуществляться только при определенных условиях. В распределенных ВС существуют три вида условий начала осуществления удаленной атаки:

Атака по запросу от атакуемого объекта (класс 3.1)

В этом случае атакующий ожидает передачи от потенциальной цели атаки запроса определенного типа, который и будет условием начала осуществления воздействия. Примером подобных запросов в ОС Novell NetWare может служить SAP-запрос (атака описана в [9]), а в сети Internet - DNS- и ARP-запросы. Удаленные атаки на объекты сети Internet, осуществляемые по запросу от атакуемой системы, рассматриваются в п. 4.2 и 4.3. Важно отметить, что данный тип удаленных атак наиболее характерен для распределенных ВС.

Атака по наступлению ожидаемого события на атакуемом объекте (класс 3.2)

В этом случае атакующий осуществляет постоянное наблюдение за состоянием операционной системы удаленной цели атаки и при возникновении определенного события в этой системе начинает воздействие. Как и в предыдущем случае, инициатором осуществления начала атаки выступает сам атакуемый объект. Примером такого события может быть прерывание сеанса работы пользователя с сервером в ОС Novell NetWare без выдачи команды LOGOUT [9].

Безусловная атака (класс 3.3)

В этом случае начало осуществления атаки безусловно по отношению к цели атаки, то есть атака осуществляется немедленно и безотносительно к состоянию системы и атакуемого объекта. Следовательно, в этом случае атакующий является инициатором начала осуществления атаки. Пример атаки данного вида см. в пункте 4.4.

Подбор пароля

Вирус Морриса заставил по-новому взглянуть на вопросы компьютерной безопасности со всех точек зрения. Были предприняты шаги не только по закрытию тех брешей, которые он использовал, но и по поиску и классификации причин их появления в UNIX-системах. Также была выявлена необходимость создания некоторого координационного органа, в котором бы накапливалась и систематизировалась информация о различных компьютерных инцидентах, применяемых методах атак и способах защиты от них. Вскоре такой центр CERT (Computer Emergency Response Team) был создан, и первым появившимся в декабре 1988 года бюллетенем было сообщение об уязвимостях, использованных червем.

Однако и компьютерные взломщики совершенствовали свои методы. Одной из атак, ставшей наиболее популярной, была атака с подбором пароля другого пользователя. Ей активно пользовался и вирус Морриса, но, либо развив его идеи, либо развиваясь независимо, вскоре появилось множество программ, занимавшихся подбором пароля к UNIX-машине. И долгое время слова "взломать UNIX" означали запустить взломщик ( cracker ) паролей.

Как известно, в файле /etc/passwd лежит ключевая информация о всех пользователях системы, включая его входное имя, пароль, полное имя и т. п. Даже в 70-х годах, когда создавались первые версии UNIX, его разработчикам было понятно, что пароль пользователя нельзя хранить в открытом виде. Надо отдать им должное, они сумели придумать схему, благодаря которой целенаправленные атаки на то, к чему всегда стремится не очень добропорядочный пользователь, а именно - завладеть паролем другого, смогли реализоваться только спустя 15 лет. Они не пошли по простому пути шифрования пароля по какому-то секретному алгоритму, т. к. рано или поздно этот алгоритм стал бы известен очередному не в меру любопытному, но в меру грамотному программисту и он смог бы расшифровать все пароли. Они выбрали путь необратимого преобразования пароля, когда из исходного пароля путем применения к ней специальной однонаправленной функции (называемой функцией хэширования) получалось некое значение, из которого никак нельзя получить исходный пароль. Более того, разработчики взяли математически криптостойкий алгоритм DES и на основе его создали функцию crypt (), преобразующую пароль в строку, расположенную в файле /etc/passwd. Эту функцию написал, кстати, Роберт Моррис-старший.

Итак, рассмотрим немного подробнее алгоритм, применяемый UNIX для преобразования пароля пользователя. Кстати, этот алгоритм применяется до сих пор в большинстве *IX.

Из исходного пароля берутся первые восемь байт. Также выбирается некоторое 12-битное случайное число (salt), используемое для операции хэширования. Его необходимость следует из того, чтобы одинаковые пароли (возможно, у разных людей) не выглядели одинаково после хэширования. Затем к этим двум параметрам применяется специальная функция шифрования, дающая на выходе 64-битное значение. Наконец, сам salt преобразуется в два читабельных ASCII-символа, а хэш - в 11 символов. Итак, функция crypt (passwd8, salt) выдает

13-символьную строчку, которая и записывается в файл /etc/passwd.

При входе пользователя в систему вызывается та же функция crypt () с введенным паролем и salt, полученными из /etc/passwd. Если результат функции оказывается равным тому значению, что хранится в файле, то аутентификация считается состоявшейся.

После анализа этой схемы, первое, что приходит в голову потенциальному взломщику - это перебор. Берется некоторый набор символов (например, маленькие и большие буквы, цифры и специальные символы типа знаков препинания - всего получается 94 символа), а затем из них по очереди составляются все комбинации вплоть до 8-символьной длины. К каждой из них применяется crypt (), и результат сравнивается с имеющимся. Естественно, что в эти комбинации и попадет рано или поздно любой пароль пользователя.

Обрезание пароля до 8 значимых символов, конечно, резко ограничивает множество для перебора, но для тех времен это было вполне допустимо, т. к. функция crypt () была реализована заведомо неэффективно, и время одного ее выполнения доходило до одной секунды на машине класса PDP. Таким образом, в среднем злоумышленник потратил бы

секунд или около 100 миллионов лет. Если же в качестве множества символов взять маленькие латинские буквы (наиболее часто используемое множество), то время перебора составит в среднем

секунд или всего 3440 лет. Заметим, однако, что на сегодняшний день скорость оптимизированной функции crypt () на машине класса Pentium составляет почти 10000 crypt /сек, т. е. она за 20 лет повысилась в 10000 раз! Поэтому сегодня пароль из последнего примера мы сможем найти в среднем за 125 дней!

Более того, во-первых, этот процесс легко можно распараллелить, а во-вторых, существуют специальные платы, аппаратно выполняющие процесс шифрования, с помощью которых можно еще уменьшить время на несколько порядков.

Однако вернемся на несколько лет назад, когда вычислительной мощности для полного перебора всех паролей не хватало. Тем не менее, хакерами был придуман остроумный (но совершенно очевидный) метод, основанный на людской психологии. Он следует из того, что человеку нелегко запомнить длинные бессмысленные наборы символов (идеальные в качестве паролей), поэтому он каким-либо путем попробует выбрать их более-менее запоминающимися и/или осмысленными. Чаще всего им в качестве пароля выбирается существующее слово или какая-либо информация о себе или своих знакомых (имя, дата рождения и т. п.). Ну, а поскольку в любом языке не более 100000 слов, то их перебор займет весьма небольшое время, и от 40 до 80% существующих паролей может быть угадано с помощью такой простой схемы, называемой "атакой по словарю" . (Кстати, до 80% этих паролей может быть угадано с использованием словаря размером всего 1000 слов!). Как вы уже знаете, даже вирус Морриса применял такой способ, тем более что в UNIX "под рукой" часто оказывается файл-словарь, обычно используемый программами-корректорами. Что же касается "собственных" паролей, то файл /etc/passwd опять-таки может дать немало информации о пользователе: его входное имя, имя и фамилию, домашний каталог. Вирус Морриса, как вы помните, с успехом пользовался следующими предположениями:



в качестве пароля берется входное имя пользователя;

пароль представляет собой двойной повтор имени пользователя;

то же, но прочитанное справа налево;

имя или фамилия пользователя;

то же, но в нижнем регистре.

Забегая несколько вперед, остановимся на сегодняшней ситуации со вскрытием паролей. Во-первых, сегодня трудно предположить, что существует еще какой-нибудь ускользнувший от внимания хакеров способ, позволяющий удаленно выкрасть файл /etc/passwd для последующего анализа (его, безусловно, можно получить, используя сценарий 1 или 2 через изъян в демоне - но это бессмысленно, т. к. злоумышленник в этом случае и так стал суперпользователем на вашей машине). Во-вторых, в современных версиях UNIX появился механизм так называемого "затенения" ( shadowing ) файла паролей - он перемещается в другое место и становится недоступным обычным пользователям по чтению. Но это не сильно эффективное средство, что связано опять-таки с идеологией UNIX, и вызов функции getpwent () иногда позволяет получить пароли пользователей в классическом виде. В-третьих, иногда функция crypt () заменяется на другую (еще более медленную!) хэш-функцию, и запуск старых программ-вскрывателей ни к чему не приводит. Обычно это алгоритм MD5, скорость которого в 50 раз меньше, чем crypt (). Наконец, среди пользователей в последние годы проводится большая "разъяснительная работа" по выбору стойких паролей, и процент успешно подобранных паролей с помощью атаки "по словарю" пусть медленно, но падает.

Однако психологический фактор останется до тех пор, пока с компьютером работает человек, и, наверное, никогда эксперты по компьютерной безопасности не дождутся от пользователя выбора таких простых и радующих душу паролей, как 34jXs5U@bTa!6. Поэтому даже искушенный пользователь хитрит и выбирает такие пароли, как hope1, user1997, pAsSwOrD, toor, root toor, parol, gfhjkm, asxz. Видно, что все они, как правило, базируются на осмысленном слове и некотором простом правиле его преобразования: прибавить цифру, прибавить год, перевести через букву в другой регистр, записать слово наоборот, прибавить записанное наоборот слово, записать русское слово латинскими буквами, набрать русское слово на клавиатуре с латинской раскладкой, составить пароль из рядом расположенных на клавиатуре клавиш и т. п.

Поэтому не надо удивляться, если такой "хитрый" пароль будет вскрыт хакерами - они не глупее вас, и уже вставили в свои программы те правила, по которым может идти преобразование слов. В самых продвинутых программах (Crack 4.1, John The Ripper 1.3) эти правила могут быть программируемыми и задаваться с помощью специального языка самим хакером.

Приведем пример эффективности такой стратегии перебора. Во многих книгах по безопасности предлагается выбирать в качестве надежного пароля два осмысленных слова, разделенных некоторым знаком, например good!password. Подсчитаем, за сколько времени в среднем будут сломаны такие пароли, если такое правило включено в набор программы-взломщика (пусть словарь 10000 слов, разделительными знаками могут быть 10 цифр и 32 знака препинания и специальных символа, машина класса Pentium со скоростью 10000 crypt /сек): сек. или всего 2.5 дня!

Итак, из всего вышесказанного ясно, насколько важно для вашей безопасности иметь хорошие пароли, причем это не зависит от операционной системы, которую вы используете. К сожалению, рекомендации по поводу выбора таких паролей выходят за рамки этой книги.

Подмена доверенного объекта или субъекта распределенной ВС

Одной из проблем безопасности распределенной ВС является недостаточная идентификация и аутентификация ее удаленных друг от друга объектов. Основная трудность заключается в осуществлении однозначной идентификации сообщений, передаваемых между субъектами и объектами взаимодействия. Обычно в распределенных ВС эта проблема решается следующим образом: в процессе создания виртуального канала объекты РВС обмениваются определенной информацией, уникально идентифицирующей данный канал. Такой обмен обычно называется "рукопожатием" (handshake). Однако, отметим, что не всегда для связи двух удаленных объектов в РВС создается виртуальный канал. Практика показывает, что зачастую, особенно для служебных сообщений (!?) (например, от маршрутизаторов) используется передача одиночных сообщений, не требующих подтверждения.

Как известно, для адресации сообщений в распределенных ВС используется сетевой адрес, который уникален для каждого объекта системы (на канальном уровне модели OSI - это аппаратный адрес сетевого адаптера, на сетевом уровне - адрес определяется в зависимости от используемого протокола сетевого уровня (например, IP-адрес). Сетевой адрес также может использоваться для идентификации объектов распределенной ВС. Однако сетевой адрес достаточно просто подделывается и поэтому использовать его в качестве единственного средства идентификации объектов недопустимо.

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

атака при установленном виртуальном канале,

атака без установленного виртуального канала.

В случае установленного виртуального соединения атака будет заключаться в присвоении прав доверенного субъекта взаимодействия, легально подключившегося к объекту системы, что позволит атакующему вести сеанс работы с объектом распределенной системы от имени доверенного субъекта. Реализация удаленных атак данного типа обычно состоит в передаче пакетов обмена с атакующего объекта на цель атаки от имени доверенного субъекта взаимодействия (при этом переданные сообщения будут восприняты системой как корректные). Для осуществления атаки данного типа необходимо преодолеть систему идентификации и аутентификации сообщений, которая, в принципе, может использовать контрольную сумму, вычисляемую с помощью открытого ключа, динамически выработанного при установлении канала, случайные многобитные счетчики пакетов и сетевые адреса станций. Однако на практике, например, в ОС Novell NetWare 3.12-4.1 для идентификации пакетов обмена используются два 8-битных счетчика - номер канала и номер пакета [9]; в протоколе TCP для идентификации используются два 32-битных счетчика. Пример удаленной атаки на сеть Internet данного типа описан в п. 4.5.2.

Как было замечено выше, для служебных сообщений в распределенных ВС часто используется передача одиночных сообщений, не требующих подтверждения, то есть не требуется создание виртуального соединения. Атака без установленного виртуального соединения заключается в передаче служебных сообщений от имени сетевых управляющих устройств, например, от имени маршрутизаторов.

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

Посылка ложных управляющих сообщений может привести к серьезным нарушениям работы распределенной ВС (например, к изменению ее конфигурации). Рассмотренная в п. 3.2.3.1 типовая удаленная атака, использующая навязывание ложного маршрута, основана на описанной идее.

Подмена доверенного объекта РВС является активным воздействием (класс 1.2), совершаемым с целью нарушения конфиденциальности (класс 2.1) и целостности (класс 2.2) информации, по наступлению на атакуемом объекте определенного события (класс 3.2). Данная удаленная атака может являться как внутрисегментной (класс 5.1), так и межсегментной (класс 5.2), как с обратной связью (класс 4.1), так и без обратной связи (класс 4.2) с атакуемым объектом и осуществляется на сетевом (класс 6.3) и транспортном (класс 6.4) уровнях модели OSI.

Подмена одного из субъектов TCP-соединения в сети Internet (hijacking)

Протокол TCP (Transmission Control Protocol) является одним из базовых протоколов транспортного уровня сети Internet. Этот протокол позволяет исправлять ошибки, которые могут возникнуть в процессе передачи пакетов, и является протоколом с установлением логического соединения - виртуального канала. По этому каналу передаются и принимаются пакеты с регистрацией их последовательности, осуществляется управление потоком пакетов, организовывается повторная передача искаженных пакетов, а в конце сеанса канал разрывается. При этом протокол TCP является единственным базовым протоколом из семейства TCP/IP, имеющим дополнительную систему идентификации сообщений и соединения. Именно поэтому протоколы прикладного уровня FTP и TELNET, предоставляющие пользователям удаленный доступ на хосты Internet, реализованы на базе протокола TCP.

Для идентификации TCР-пакета в TCP-заголовке существуют два 32-разрядных идентификатора, которые также играют роль счетчика пакетов. Их названия - Sequence Number и Acknowledgment Number. Также нас будет интересовать поле, называемое Control Bits.

Это поле размером 6 бит может содержать следующие командные биты (слева направо):

URG: Urgent Pointer field significant

ACK: Acknowledgment field significant

PSH: Push Function

RST: Reset the connection

SYN: Synchronize sequence numbers

FIN: No more data from sender

Далее рассмотрим схему создания TCP-соединения (рис 4.9).

Предположим, что хосту А необходимо создать TCP-соединение с хостом В. Тогда А посылает на В следующее сообщение:

Рис. 4.9. Схема создания TCP-соединения.

1. A - > B: SYN, ISSa

Это означает, что в передаваемом A сообщении установлен бит SYN (synchronize sequence number), а в поле Sequence Number установлено начальное 32-битное значение ISSa (Initial Sequence Number).

В отвечает:

2. B - > A: SYN, ACK, ISSb, ACK(ISSa+1)

В ответ на полученный от А запрос В отвечает сообщением, в котором установлен бит SYN и установлен бит ACK; в поле Sequence Number хостом В устанавливается свое начальное значение счетчика - ISSb; поле Acknowledgment Number содержит значение ISSa, полученное в первом пакете от хоста А и увеличенное на единицу.

А, завершая рукопожатие (handshake), посылает:

3. A - > B: ACK, ISSa+1, ACK(ISSb+1)

В этом пакете установлен бит ACK; поле Sequence Number содержит ISSa + 1; поле Acknowledgment Num-ber содержит значение ISSb + 1. Посылкой этого пакета на хост В заканчивается трехступенчатый handshake, и TCP-соединение между хостами А и В считается установленным.

Теперь хост А может посылать пакеты с данными на хост В по только что созданному виртуальному TCP-каналу:

4. A - > B: ACK, ISSa+1, ACK(ISSb+1); DATA

Из рассмотренной выше схемы создания TCP-соеди-нения видно, что единственными идентификаторами TCP-абонентов и TCP-соединения являются два 32-бит-ных параметра Sequence Number и Acknowledgment Number. Следовательно, для формирования ложного TCP-пакета атакующему необходимо знать текущие идентификаторы для данного соединения - ISSa и ISSb. Проблема возможной подмены TCP-сообщения становится еще более важной, так как анализ протоколов FTP и TELNET, реализованных на базе протокола TCP, показал, что проблема идентификации FTP- и TELNET-пакетов целиком возлагается данными протоколами на транспортный уровень, то есть на TCP. Это означает, что атакующему достаточно, подобрав соответствующие текущие значения идентификаторов TCP-пакета для данного TCP-соединения (например, данное соединение может представлять собой FTP- или TELNET-подклю-чение), послать пакет с любого хоста в сети Internet от имени одного из участников данного соединения (например, от имени клиента), и данный пакет будет воспринят как верный! К тому же, так как FTP и TELNET не проверяют IP-адреса отправителей, от которых им приходят сообщения, то в ответ на полученный ложный пакет, FTP- или TELNET-сервер отправит ответ на указанный в ложном пакете настоящий IP-адрес атакующего, то есть атакующий начнет работу с FTP- или TELNET-сервером со своего IP-адреса, но с правами легально подключившегося пользователя, который, в свою очередь, потеряет связь с сервером из-за рассогласования счетчиков!

Итак, для осуществления описанной выше атаки необходимым и достаточным условием является знание двух текущих 32-битных параметров ISSa и ISSb, идентифицирующих TCP-соединение. Рассмотрим возможные способы их получения.

В том случае, когда атакующий находится в одном сегменте с целью атаки или через его сегмент проходит трафик предполагаемого объекта атаки, то задача получения значений ISSa и ISSb является тривиальной и решается путем анализа сетевого трафика. Следовательно, надо четко понимать, что протокол TCP позволяет, в принципе, защитить соединение только в случае невозможности перехвата атакующим сообщений, передаваемых по данному соединению, то есть в случае нахождения атакующего в других сегментах относительно абонентов TCP-соединения.

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

Подробный анализ структуры и процедур вируса

В этом параграфе вирус описывается процедура за процедурой. Взаимосвязь между процедурами показана на рис. 8.1.

Рис. 8.1. Структура вируса.

Понятие типовой удаленной атаки

Исследования и анализ информационной безопасности различных распределенных ВС, проводимые авторами в течение последних лет, наглядно продемонстрировали тот факт, что, независимо от используемых сетевых протоколов, топологии, инфраструктуры исследуемых распределенных ВС, механизмы реализации удаленных воздействий на РВС инвариантны по отношению к особенностям конкретной системы. Это объясняется тем, что распределенные ВС проектируются на основе одних и тех же принципов, а, следовательно, имеют практически одинаковые проблемы безопасности; Поэтому оказывается, что причины успеха удаленных атак на различные РВС одинаковы (глава 5). Таким образом, появляется возможность ввести понятие типовой удаленной атаки. Типовая удаленная атака- это удаленное информационное разрушающее воздействие, программно осуществляемое по каналам связи и характерное для любой распределенной ВС. Введение этого понятия в совокупности с описанием механизмов реализации типовых УА позволяет предложить методику исследования безопасности, инвариантную по отношению к виду распределенной ВС. Методика заключается в последовательном осуществлении всех типовых удаленных воздействий в соответствии с предложенным далее их описанием и характеристиками. При этом основным элементом исследования безопасности РВС является анализ сетевого трафика (п. 3.2.1). Как пояснение последнего утверждения рассмотрим следующую аналогию: отладчик - основное средство для хакера, соответственно анализатор сетевого трафика - основное средство для сетевого хакера. Анализатор сетевого трафика по своей сути является сетевым отладчиком. Итак, в качестве методики исследования информационной безопасности распределенной ВС предлагается выполнение ряда тестовых задач, оценивающих защищенность системы по отношению к типовым удаленным воздействиям.

Рассмотрим в следующих пунктах типовые удаленные атаки и механизмы их реализации.

Последние новости: проникновение с помощью innd

Как иллюстрацию того пути, по которому идут кракеры сегодня, рассмотрим самый популярный способ проникновения в UNIX-хосты начала 1997 года.

Итак, в качестве лазейки была выбрана серверная программа, отвечающая за передачу новостей USENET по протоколу NNTP, называемая InterNet News (Inn). Такой выбор для кракеров очень удачен: во-первых, эта программа "не запятнала" себя ранее (это как раз пример новаторского подхода), во-вторых, как и любой демон, она потенциально допускает проникновение по классу 1; в-третьих, сервис передачи новостей выходит на одно из первых мест в интернете, поэтому эта программа достаточно распространена и существует практически на всех платформах; наконец, уязвимости, если они найдутся в ней, не могут быть сведены на нет файрволом. Поясним последнее подробнее. Если вы у себя на машине ставите сервер, который должен отвечать за прием - передачу новостей по протоколу NNTP, то, естественно, вы должны разрешить этот протокол в своем файрволе. Но кракер, с другой стороны, также будет работать на уровне NNTP. Иначе говоря, как и в приведенной выше уязвимости в sendmail , нет возможности для файрвола отличить пакеты, содержащие "хорошие" новости, от "плохих" , которые посылает кракер - файрвол может только вообще или запретить конкретный трафик, или разрешить его.

Именно такого рода уязвимость была найдена в программе innd [22]. Среди обычных сообщений USENET встречаются так называемые управляющие, типа "newgroup" или "rmgroup" . Innd обрабатывает команды, расположенные в них, через команду оболочки "eval" . Однако некоторая информация (иначе говоря, специальным образом разработанное фальшивое управляющее сообщение) может быть передана оболочке без надлежащего контроля. Это позволит любому, кто может присылать сообщения на ваш NNTP-сервер - иногда это чуть ли ни любой пользователь USENET - исполнить любую команду, имея привилегии демона innd, - а это либо суперпользователь, либо специальный пользователь news с широкими правами. Все версии Inn, вплоть до 1.5 включительно, оказались уязвимыми.

Превышение максимально возможного размера IP-пакета или "Ping Death"

В максимальный размер IP-пакета (65535 байт) включается длина IP-заголовка и длина поля данных в IP-пакете. Так как IP-заголовок имеет минимальный размер в 20 байт (максимальный в 60), то, соответственно, размер передаваемых в одном IP-пакете данных не может превышать 65535 - 20 = 65515 байт. А что будет, если превысить этот максимальный размер IP-пакета?

Тестировать свои программы на минимальных и, самое главное, на максимальных значениях, то есть на предельных критических значениях - стандартный для любого программиста ход. Подобные тесты позволяют выявить такие неприятные ошибки, как всевозможные переполнения (буфера, стека, переменной и т. д.).

Вернемся к IP. В принципе, ничто не мешает атакующему сформировать набор фрагментов, которые после сборки превысят максимально возможный размер IP-пакета. Собственно, в этой фразе и сформулирована основная идея данной атаки.

Итак, 18 декабря 1996 года на информационном сервере CERT появились сообщения о том, что большинство сетевых ОС, поддерживающих протоколы TCP/IP, обладают следующей уязвимостью: при передаче на них IP-пакета длиной, превышающей максимально допустимое значение, в этих ОС переполняется буфер или переменная, и система зависает или перезагружается и т. п. - отказ в обслуживании! Также был приведен следующий список потенциально опасных платформ:

Berkeley Software Design, Inc. (BSDI);

Computer Associates, Intl. (products for NCR);

Cray Research;

Digital Equipment Corporation;

FreeBSD, Inc.;

Hewlett-Packard Company;

IBM Corporation;

Linux Systems;

NEC Corporation;

Open Software Foundation (OSF);

The Santa Cruz Operation, Inc. (SCO);

Sun Microsystems, Inc.

Увидев сообщение о подобной атаке и, главное, этот перечень операционных систем на различных платформах, мы с величайшим удивлением долго его перечитывали, а потом принялись за эксперименты. Наше глубочайшее изумление вызвал тот факт, что подобную элементарнейшую ошибку переполнения буфера в модуле IP ядра ОС за почти 20 лет активного функционирования протокола IP в различных ОС разработчики сегодняшних систем, да еще в таком массовом количестве, до сих пор не замечали! Поэтому мы позволили себе не поверить столь уважаемой организации, как CERT. Но прежде, чем начать эксперименты, было решено посмотреть по указанной в CERT ссылке [29] на WWW-сервер, где экспертами проводились подобные исследования на различных ОС. Там, собственно как и в CERT, эта атака называлась "Ping Death" . На этом WWW-сервере предлагалось реализовать такую атаку следующим образом: на рабочей станции с ОС Windows '95 или Windows NT необходимо выполнить следующую команду:

ping -l 65527 victim.destination.IP. address (поэтому - "Ping Death" ).

Так как обычный размер IP- заголовка составляет 20 байт, размер ICMP-заголовка - 8 байт, то подобный ICMP-пакет будет превышать максимально возможный размер IP-пакета на 20 байт

(65527 + 20 +8 - 65535 = 20).

Таким образом эти "эксперты" декларировали, что обычной командой ping якобы можно нарушить работоспособность практически любой сетевой ОС. В завершение на этом сервере приводилась следующая таблица тестирования различных операционных систем, на которые данная удаленная атака якобы произвела необходимый эффект. Далее авторы хотели бы продемонстрировать вам эту таблицу с существенными сокращениями (см. табл. 4.13).

Не правда ли, эта таблица операционных систем, обладающих такой уязвимостью, производит должное впечатление!

Итак, мы начали тестирование и, честно говоря, абсолютно не удивились, когда ни одна из исследуемых операционных систем, ни IRIX, ни AIX, ни VMS, ни SunOs, ни FreeBSD, ни Linux, ни Windows NT 4.0, ни даже Windows '95 и Windows for WorkGroups 3.11, абсолютно никак не реагировали на подобный некорректный запрос и продолжали нормально функционировать! Тогда были предприняты специальные поиски ОС, которую бы действительно вывела из строя данная атака. Ею оказалась Windows 3.11 с WinQVT - эта ОС действительно зависла.

Таблица 4.13

Уязвимые операционные системы

Operating system Version Symptoms
Solaris (x86)	2.4, 2.5, 2.5.1	Reboot
Minix	1.7.4, v2.0 and probably others	Crash
HP3000 MPE/iX	4.0, 5.0, 5.5	System abort
Convex SPP-UX	All version	Crash
Apple Mac	MacOs 7.x.x	Crash
Windows 3.11 with Trumpet Winsock	?	Mixed reports
Novell NetWare	3.x	Mixed results
Windows '95	All of 'em	Crrrash
AIX	3 and 4	Operating system dump.
Linux	? 2.0.23	Spontaneous reboot or kernel panic
DEC Unix/OSF1	2.0 and above	Kernel Panic
Open VMS for AXP	various	Mixed reports
Open VMS for VAX	v6.2, UCX v4.0 and others	Reboot
HP-UX	9.0 to 10.20	Crash, Reboot, Hang ...
Windows NT	3.5.1	Mixed results
Irix	5.3	Panic
Windows NT	4.0	Crash
SCO Openserver	4.2, 5.0.x	Vulnerable
DEC TOPS-20, TOPS-10	All	Errors
Digital Firewall	?	Vulnerable
AltaVista Firewall for UNIX	?	Vulnerable

<


На запрос, посланный этим так называемым "экспертам" , которым столь доверяют CERT и CIAC, где мы попросили прояснить возникшую ситуацию, а также сведения из таблицы 4.13, был получен ответ; в нем говорилось, что успех данной атаки зависит от многих факторов, а именно: программного и аппаратного обеспечения, установленного на компьютере и, самое главное, от фазы луны. Согласитесь, полный бред! Для полноты картины мы хотели бы далее привести описание exploit'а, созданного для Windows NT 4.0, задача которого, используя ping, завесить собственный компьютер. Первым шагом предлагалось запустить Web Browser (?). На втором шаге требовалось запустить taskmgr (Task Manager) (??). В комментариях к этому шагу говорилось, что так Ping Death работает лучше (еще не хватает шаманского бубна!). И, наконец, требовалось запустить 18 ping-процессов (???) (не больше и не меньше; может быть, лучше сразу 100 - чего мелочиться!). Если вы думаете, что далее ваша ОС немедленно повиснет, то вы ошибаетесь! В комментариях к exploit'у до получения эффекта предлагалось ждать примерно 10 минут, с философским замечанием о том, что ожидание может продлиться несколько больше (интересно на сколько больше - час, месяц, год ?!) или несколько меньше.

В итоге можно сделать вывод, что шумиха, поднятая в CERT и CIAC по поводу данной атаки, является безосновательной, и ничего другого нам, видимо, не остается, как назвать эту атаку очередной программистской байкой и причислить ее к разряду практически неосуществимых.

Причины существования уязвимостей в UNIX-системах

Рассмотрев выше достаточно много фактического материала, мы коснемся причин, по которым описанные нарушения безопасности UNIX имели место, и попытаемся их классифицировать. Сразу оговоримся, что эта классификация ни в коей мере не претендует на новизну или полноту - кому интересна эта тема, предлагаем обратиться к более серьезным научным работам [9, 23]. Здесь же мы опишем вполне понятные читателю причины, по которым, тем не менее, происходит до 90% всех случаев вскрытия UNIX-хостов.

Наличие демонов.

Механизм SUID/SGID-процессов.

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

Излишнее доверие.

Об этом уже достаточно говорилось выше. Повторим, что в UNIX достаточно много служб, использующих доверие, и они могут тем или иным способом быть обмануты.

К этим трем причинам нельзя не добавить следующую:

Человеческий фактор с весьма разнообразными способами его проявления - от легко вскрываемых паролей у обычных пользователей до ошибок у квалифицированных системных администраторов, многие из которых как раз и открывают путь для использования механизмов доверия.

Рис. 8.2. Причины уязвимости UNIX при атаках на телекоммуникационные службы.

Рассмотрим теперь более подробно причины, по которым оказываются уязвимы демоны и SUID/SGID-процессы:

возможность возникновения непредусмотренных ситуаций, связанных с ошибками или недоработками в программировании;

наличие скрытых путей взаимодействия с программой, называемых "люками" ;

возможность подмены субъектов и объектов различным образом.

К первым можно отнести классическую ситуацию с переполнением буфера или размерности массива (примеры см. п. 8.4.1.2 и 8.6.2), ведущую к затиранию области стека и записи туда специальных команд, которые будут затем исполнены. Заметим сразу, что этот способ, несмотря на свою популярность, всегда будет системозависимым и ориентирован только на конкретную платформу и версию UNIX.

Хорошим примером непредусмотренной ситуации в многозадачной операционной системе является неправильная обработка некоторого специального сигнала или прерывания. Часто хакер имеет возможность смоделировать ситуацию, в которой этот сигнал или прерывание будет послано (в UNIX'е посылка сигнала решается очень просто - командой kill - см. пример 8.6.2).

Наконец, одна из самых распространенных программистских ошибок - является неправильная обработка входных данных (это является некоторым обобщением случая переполнения буфера.) По свидетельству [24], ими в 1990 и 1995 годах были подвергнуты автоматизированному тестированию около 80 программ на 9 различных платформах UNIX - специальная программа подавала на вход строки длиной до 100000 символов. Результатом явилось то, что 25- 33% в 1990 г. и 18- 23% в 1995 г. работали некорректно - зависали, сбрасывали аварийный дамп и т. п. (Интересно, что в коммерческих версиях UNIX этот процент доходил до 43, тогда как в свободно распространяемых он был меньше 10.) Впрочем, справедливости ради надо отметить, что только 2 программы-демона вели себя таким образом в 1990 г., а через 5 лет эти ошибки были исправлены. Ну, а если программа неправильно обрабатывает случайные входные данные, то очевидно, что можно подобрать такой набор специфических входных данных, которые приведут к желаемым для хакера последствиям. Примером этого может служить innd (8.6.4).

Люком, или "черным входом" (backdoor) часто называют оставленную разработчиком недокументированную возможность взаимодействия (чаще всего входа в систему), например, известный только разработчику универсальный "пароль" . Люки оставляют в конечных программах вследствие ошибки, не убрав отладочный код или вследствие необходимости продолжения отладки уже в реальной системе в связи с ее высокой сложностью или же их корыстных интересов. Люки - это любимый путь входа в удаленную систему не только у хакеров, но и у журналистов и режиссеров вкупе с подбором "главного" пароля перебором за минуту до взрыва, но в отличие от последнего способа, люки реально существуют. Классический пример люка - это, конечно, отладочный режим в sendmail.

Наконец, вследствие многих особенностей UNIX, таких как асинхронное выполнение процессов, развитый командный язык и файловая система, злоумышленниками могут быть использованы механизмы подмены одного субъекта или объекта другим. Например, в рассмотренных выше примерах часто применялась замена имени файла, имени получателя и т. п. именем программы (см. 8.5.2.3 и 8.5.2.4.3). Аналогично может быть выполнена подмена некоторых специальных переменных. Так, для некоторых версий UNIX существует атака, связанная с подменой символа разделителя команд или опций на символ "/" . Это приводит к тому, что когда программа вызывает /bin/sh, вместо него вызывается файл bin с параметром sh в текущем каталоге. Похожая ситуация возникает при атаке на telnetd (см. 8.6.1). Наконец, очень популярным в UNIX видом подмены является создание ссылки (link) на критичный файл. После этого файл-ссылка некоторым образом получает дополнительные права доступа, и тем самым осуществляется несанкционированный доступ к исходному файлу. Аналогичная ситуация с подменой файла возникает, если путь к файлу определен не как абсолютный (/bin/sh), а относительный (../bin/sh или $(BIN)/sh). Такая ситуация имела место в рассмотренной уязвимости telnetd.

И последнее - нельзя приуменьшать роль человека при обеспечении безопасности любой системы. Возможно, он даже является слабейшим звеном. Про необходимость выбора надежных паролей уже говорилось. Неправильное администрирование - такая же актуальная проблема, а для UNIX она особенно остра, т. к. сложность администрирования UNIX-систем давно уже стала притчей во языцех и часто именно на это упирают конкуренты. Но за все надо платить, и это обратная сторона переносимости и гибкости UNIX. Более того, если говорить о слабости человека, защищенные системы обычно отказываются и еще от одной из основных идей UNIX - наличия суперпользователя, имеющего доступ ко всей информации и никому не подконтрольного. Его права могут быть распределены среди нескольких людей: администратора персонала, администратора безопасности, администратора сети и т. п., а сам он может быть удален из системы после ее инсталляции. В результате вербовка одного из администраторов не приводит к таким катастрофическим последствиям, как вербовка суперпользователя.

Настройки некоторых приложений, того же sendmail, настолько сложны, что для поддержания работоспособности системы требуется специальный человек - системный администратор, - но даже он, мы уверены, не всегда знает о всех возможностях того или иного приложения и о том, как правильно их настроить. И если хакеры смогли проникнуть в систему, то это не всегда говорит о халатности администратора, а, зачастую, о его ограниченном знании того или иного продукта.

Причины успеха удаленных атак на распределенные вычислительные системы и сеть Internet

"То, что изобретено одним человеком,

может быть понято другим,"- сказал Холмс.

А.Конан-Дойл.

Пляшущие человечки.

В двух предыдущих главах было показано, что общие принципы построения распределенных ВС позволяют выделить в отдельный класс угрозы, характеризующие только распределенные системы. Было введено такое понятие, как типовая удаленная атака, и были предложены механизмы реализации удаленных атак (УА) всех типов. Понятие типовой УА позволило классифицировать угрозы безопасности распределенным ВС вообще, поскольку типовые УА инвариантны по отношению к конкретному типу РВС. Инвариантность типовых УА основана на том, что они направлены на основополагающие принципы построения, заложенные в инфраструктуру любой распределенной системы.

Предложенные в этой книге описание, характеристика и классификация основных типов УА позволяют говорить о практической методике исследования безопасности РВС. Основой этой методики является последовательное осуществление УА всех типов; при этом основным средством анализа безопасности сетевого взаимодействия объектов распределенной системы будет являться описанный в 3 главе сетевой анализ (анализ сетевого трафика).

Итак, в данной главе будут подробно рассмотрены основные причины, из-за которых возможны удаленные атаки. Наша цель состоит в том, чтобы сформулировать те принципы и требования, которые ликвидировали бы причины успеха УА и, руководствуясь которыми, было бы возможно построение распределенной ВС с защищенным сетевым взаимодействием ее удаленных компонентов.

Основные вопросы, на которые попытается дать ответы данная глава, это: "почему возможны удаленные атаки" и "в чем причины их успеха" ? Анализ механизмов реализации типовых УА (глава 3) и их практическое осуществление на примере сети Internet (глава 4) позволили сформулировать причины, по которым данные удаленные атаки оказались возможными. Особо отметим, что рассматриваемые ниже причины основываются на базовых принципах построения сетевого взаимодействия объектов распределенной ВС.

В этой главе мы разберем только причины успеха УА на инфраструктуру и базовые протоколы сети (глава 4), а не УА на телекоммуникационные службы, причины успеха которых будут рассмотрены в главе 8. Для устранения причин атак первого типа зачастую необходимо либо отказаться от определенных служб (DNS, например, см. п. 4.3), либо изменить конфигурацию системы (наличие широковещательной среды приводит к возможности прослушивания канала, осуществляемого программным образом (п. 4.1 и 3.2.1)), либо изменить систему в целом (см. направленный "шторм" TCP-запросов в. п. 4.6). Все дело в том, что причины успеха удаленных атак данного типа кроются в инфраструктуре распределенной ВС, поэтому создание таксономии причин их успеха представляется весьма важной задачей, решение которой позволит выработать принципы построения защищенного взаимодействия в РВС.

Итак, рассмотрим возможные причины успеха УА на инфраструктуру и базовые протоколы распределенных ВС.

Причины успеха удаленных атак на сеть Internet

Сеть Internet представляет собой распределенную вычислительную систему, инфраструктура которой общеизвестна и хорошо описана в различной литературе, например [12]. Поэтому рассмотренные в п. 5.1 причины успеха удаленных атак на распределенные ВС можно спроецировать на сеть Internet и сделать вывод о существовании в данной сети серьезных пробелов в обеспечении безопасности, на которых базируются причины. Внимательный читатель, изучая предыдущие разделы, уже, наверное, мысленно осуществил проекцию и обратил внимание на то, как недостатки, присущие абстрактной распределенной ВС, легко обнаруживаются в реальной РВС - Internet.

Перечень информационных ресурсов Internet, посвященных

Перечень информационных ресурсов Internet, посвященных вопросам информационной безопасности
Зарубежные сайты

First (Forum of Incident Response and Security Teams)
CERT (Computer Emergensy Response Team)
CIAC (Computer Incident Advisory Capability)
NASIRC (NASA Automated Systems Incident Response Capability)
DoD Information Analysys Center (IAC)
NSA (National Security Agency)
FBI Computer crime information
COAST (Computer Operations, Audit, and Security Technology )

Отечественные сайты

СЦЗИ (Специализированный Центр Защиты Информации при СПбГТУ)
Spy Market Pro
РЕГИОНэксперт
Zhurnal.ru
ИКСИ (Институт криптографии, связи и информатики)

Специализированный Центр Защиты Информации и Кафедра Информационной Безопасности Компьютерных Систем Санкт-Петербургского Государственного Технического университета
предлагает:
анализ безопасности прикладного и системного программного обеспечения и подготовку материалов для сертификации;
разработку безопасных информационных систем;
разработку безопасных сетевых решений для корпоративных сетей, в т. ч. подключение к Internet;
оказание консультаций в области защиты информации, современных программных средств и современных сетевых решений;
обучение по специальности 22.07 "Организация и технология защиты информации" (квалификация: инженер, бакалавр, магистр);
краткосрочные курсы повышения квалификации администраторов безопасности;
книги и учебные пособия по информационной безопасности.
оказывает услуги:
восстановление работоспособности локальных сетей
Novell Netwarc, UNIX и Windows NT в случае утери пароля;
восстановление информации, утерянной в результате компьютерных вирусов или сбоев;
обнаружение и отражение удаленных атак в сетях Internet и Novell Netware.
Наш адрес: 195251, Санкт-Петербург,

Политехническая ул., д. 29, главное здание, ауд. 166,

Тел./факс (812) 552-64-89

E-mail:

WWW:

|

Принципы создания защищенных систем связи в распределенных вычислительных системах

План, что и говорить, был превосходный:

простой и ясный, лучше не придумаешь.

Недостаток у него был только один:

было совершенно неизвестно,

как привести его в исполнение.

Л. Кэрролл.

Приключения Алисы в стране чудес.

В предыдущей главе были рассмотрены основные причины нарушения информационной безопасности распределенных вычислительных систем по каналам связи. Описанные выше причины успеха удаленных атак на распределенные системы наглядно продемонстрировали, что несоблюдение требований безопасности к защищенным системам связи удаленных объектов РВС приводит к нарушению безопасности системы в целом. Поэтому данная глава и будет посвящена выработке требований защищенного взаимодействия в распределенной ВС. Основной вопрос, на который мы постараемся здесь ответить, это - из каких принципов необходимо исходить при построении защищенной системы связи удаленных объектов распределенной ВС. Итак, далее речь пойдет о технологии создания защищенных систем связи объектов в РВС.

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

Проектирование распределенной

Одной из особенностей распределенной ВС является возможное отсутствие информации, необходимой для доступа к ее удаленным объектам. Поэтому в РВС возникает необходимость использования потенциально опасных с точки зрения безопасности алгоритмов удаленного поиска (п. 3.2.3.2 и 5.1.5). Следовательно, для того, чтобы в РВС не возникало необходимости в использовании данных алгоритмов, требуется на начальном этапе спроектировать систему так, чтобы информация о ее объектах была изначально полностью определена. Это позволит, в свою очередь, ликвидировать одну из причин успеха удаленных атак, связанных с использованием в распределенной ВС алгоритмов удаленного поиска.

Однако в РВС с неопределенным и достаточно большим числом объектов (например, Internet) спроектировать систему с отсутствием неопределенности практически невозможно. В этом случае отказаться от алгоритмов удаленного поиска не представляется возможным.

Существуют два типа данных алгоритмов. Первый типовой алгоритм удаленного поиска - с использованием информационно-поискового сервера, второй - с использованием широковещательных запросов (п. 5.1.5). Применение в РВС алгоритма удаленного поиска с использованием широковещательных запросов в принципе не позволяет защитить систему от внедрения в нее ложного объекта (п. 3.2.3), а, следовательно, использование данного алгоритма в защищенной системе недопустимо. Применение в распределенной ВС алгоритма удаленного поиска с использованием информационно-поискового сервера позволяет обезопасить систему от внедрения в нее ложного объекта только в том случае, если, во-первых, взаимодействие объектов системы с сервером происходит только с созданием виртуального канала и, во-вторых, у объектов, подключенных к данному серверу, и у сервера существует заранее определенная статическая ключевая информация, используемая при создании виртуального канала. Выполнение этих условий сделает невозможным в распределенной ВС передачу в ответ на запрос с объекта ложного ответа и, следовательно, внедрения в систему ложного объекта.

Поясним последнее утверждение. В том случае, если виртуальный канал с информационно-поисковым сервером создается с использованием только динамически вырабатываемой ключевой информации, например, по схеме открытого распределения ключей, то ничто не мешает атакующему - в том случае, если он может перехватить первоначальный запрос на создание ВК с объекта системы - послать ложный ответ и создать виртуальный канал от имени настоящего сервера (п. 3.2.3.2). Именно поэтому на всех объектах системы необходима начальная ключевая информация для создания ВК с информационно-поисковым сервером.

В заключение предлагаются следующие требования, которыми необходимо руководствоваться при создании защищенных систем связи в распределенных ВС.

Утверждение 7.

Наиболее безопасной распределенной ВС является та система, в которой информация о ее объектах изначально полностью определена и в которой не используются алгоритмы удаленного поиска.

Утверждение 8.

В том случае, если выполненить требование 7 невозможно, необходимо в распределенной ВС использовать только алгоритм удаленного поиска с выделенным информационно-поисковым сервером, и при этом взаимодействие объектов системы с данным сервером должно осуществляться только по виртуальному каналу с применением надежных алгоритмов защиты соединения с обязательным использованием статической ключевой информации.

Следствие 8.1.

В распределенной ВС для обеспечения безопасности необходимо отказаться от алгоритмов удаленного поиска с использованием широковещательных запросов.

Заключая эту главу, хотелось бы обратить внимание читателя на то, что, как он, наверное, уже понял, в сети Internet в стандарте IPv4 практически ни одно из сформулированных требований к построению безопасных систем связи между удаленными объектами распределенных ВС не выполняется. Поэтому авторы позволили себе привести свои требования, по которым должна строиться распределенная ВС. Кстати, учтя собственные ошибки в разработке стандарта IPv4, группы разработчиков уже заканчивают проект создания нового более защищенного стандарта сети Internet - IPv6, где будут, по-видимому, учтены некоторые из вышеизложенных требований. Однако разговор о том, насколько будет безопасна сеть Internet в новом стандарте, несколько преждевременен, и его необходимо отложить до окончательного выхода стандарта в свет.

Программа SATAN

После общего введения мы посчитали невозможным не ознакомить читателя в общих чертах с таким нашумевшим средством, как SATAN, которое иногда считается чуть ли ни самой опасной программой из когда бы то ни было написанных, начиная от своего зловещего названия до возможности влезть чуть ли не в самый защищенный компьютер. Насчет названия сразу подчеркнем, что в момент инсталляции с помощью специальной процедуры вы можете поменять его на SANTA (Security Analysis Network Tool for Administrator), а заодно и зловещего сатану на симпатичного Деда Мороза. А что касается влезания в компьютер (не любой, конечно) - если подобная программа и имеется у хакеров или спецслужб, то она никогда не стала бы свободно распространяться по интернету, как это происходит с SATAN.

Рис. 8.3. SATAN.

Рис. 8.4. SANTA (видимо, Claus).

На самом деле SATAN - это добротно сделанная, с современным интерфейсом, программа для поиска брешей в вашей подсети (Intranet, как модно говорить в последнее время), написанная на машинно-независимых языках Perl и С, поэтому она в некоторой мере преодолевает первый из вышеописанных недостатков. Она даже допускает возможность для расширения и вставки новых модулей. К сожалению, во всем остальном ей присущи указанные недостатки, в т.ч. и самый главный - она уже устарела, и не может сейчас серьезно использоваться ни администраторами, ни хакерами. Поэтому непонятен мистический страх перед всемогуществом SATAN'а. Авторы, готовя материал для данной книги, сами столкнулись с таким отношением и были немало этим удивлены.

Однако на момент выхода это была достаточно актуальная программа. Она содержала в себе поиск большинства уязвимостей, описанных нами в п. 8.5.2 и была построена на статье [16] (или эта статья вылилась из работы над SATAN'ом). В частности, программа ищет уязвимости в:

FTP и TFTP;

NFS и NIS;

rexd;

sendmail;

r-службах;

X-Window.

Существуют также более поздние версии SATAN'а, в которые включен поиск и других уязвимостей.

Для этого она сначала всевозможным образом собирает информацию о вашей системе, причем уровень этого конфигурируется пользователем и может быть: легкий, нормальный и жесткий. Легкий уровень, по утверждению авторов программы, не может быть никак обнаружен атакуемой стороной (по крайней мере, такая активность программы никак не может быть принята за враждебную) и включает в себя DNS-запросы для выяснения версии операционной системы и другой подобной информации, которая может быть легально получена с использованием DNS. Далее она посылает запрос на службу RPC (remote procedure call) для выяснения, какие rpc-сервисы работают. Нормальный уровень разведки включает в себя все эти запросы, а также дополняет их посылкой запросов (сканированием) некоторых строго определенных портов, таких как FTP, telnet, SMTP, NNTP, UUCP и др. для определения установленных служб. Наконец, жесткий уровень включает в себя все предыдущие уровни, а также дополняется полным сканированием всех (возможных) UDP- и TCP-портов для обнаружения нестандартных служб или служб на нестандартных портах. Авторы предостерегают, что такое сканирование может быть легко зафиксировано даже без специальных программ - например, на консоли могут появляться сообщения от вашего файрвола.

Другой важной опцией, задаваемой при настройке SATAN'a, является глубина просмотра подсетей (proximity). Значение 0 означает только один хост, 1 - подсеть, в которую он входит, 2 - все подсети, в которые входит подсеть данного хоста, и т. д. Авторы подчеркивают, что ни при каких обстоятельствах это число не должно быть более 2, иначе SATAN выйдет из-под контроля и просканирует слишком много внешних подсетей.

Собственно, ничем более страшным, кроме как сканированием портов и обнаружением работающих служб и их конфигурации, SATAN не занимается. При этом, если находятся потенциальные уязвимости, он сообщает об этом. Как пишут сами авторы, фаза проникновения в удаленную систему не была реализована.

Авторы SATAN'а используют очень современный интерфейс - все сообщения программы оформляются в виде HTML-страниц. Поэтому работа с SATAN'ом мало чем отличается от плавания (surf) по интернету в своем любимом броузере (SATAN поддерживает любой из них, будь то lynx, Mosaic или Netscape). Пользователь может отсортировать найденные уязвимости (по типу, серьезности и т. п.) и тут же получить развернутую информацию по каждой из них. Для поддержки броузеров в SATAN входит собственный http-сервер, выполняющий ограниченное число запросов, а связь с этим сервером осуществляется c использованием случайного 32-битного числа (magic cookie), которое служит для дополнительной аутентификации http-клиента. Иначе говоря, оно служит для предотвращения перехвата конфиденциальной информации броузером, отличным от запущенного SATAN'ом, а также вообще против любого взаимодействия с http-сервером SATAN'а. Любопытно, что в версиях до 1.1.1 в этой схеме аутентификации тоже была ошибка, которая даже попала в один из бюллетеней CERT.

Итак, типичный сценарий работы с SATAN заключается в следующем:

настроить желаемые параметры, в том числе глубину сканирования;

задать адрес цели и уровень сканирования;

просмотреть полученные результаты и получить по ним более подробную информацию;

устранить найденные уязвимости.

Администратору безопасности рекомендуется просканировать на жестком уровне все свои хосты, а также все доверенные хосты, обязательно спросив на это разрешение у их администраторов. Это рекомендуется сделать даже сегодня, несмотря на то, что SATAN устарел - вы сможете быстро получить список используемых сетевых служб и их версий и проверить, нет ли среди них уязвимых, воспользовавшись материалами CERT или CIAC.

Программно-аппаратные методы защиты от удаленных атак в сети Internet

К программно-аппаратным средствам обеспечения информационной безопасности средств связи в вычислительных сетях относятся:

аппаратные шифраторы сетевого трафика;

методика Firewall, реализуемая на базе программно-аппаратных средств;

защищенные сетевые криптопротоколы;

программно-аппаратные анализаторы сетевого трафика;

защищенные сетевые ОС.

Существует огромное количество литературы, посвященной этим средствам защиты, предназначенным для использования в сети Internet (за последние два года практически в каждом номере любого компьютерного журнала можно найти статьи на эту тему).

Далее мы, по возможности кратко, чтобы не повторять всем хорошо известную информацию, опишем данные средства защиты, применяемые в Internet. При этом мы преследуем следующие цели: во-первых, еще раз вернемся к мифу об "абсолютной защите" , которую якобы обеспечивают системы Firewall, очевидно, благодаря стараниям их продавцов; во-вторых, сравним существующие версии криптопротоколов, применяемых в Internet, и дадим оценку, по сути, критическому положению в этой области; и, в-третьих, ознакомим читателей с возможностью защиты с помощью сетевого монитора безопасности, предназначенного для осуществления динамического контроля за возникающими в защищаемом сегменте IP-сети ситуациями, свидетельствующими об осуществлении на данный сегмент одной из описанных в 4 главе удаленных атак.

Программные методы защиты, применяемые в сети Internet

К программным методам защиты в сети Internet можно отнести прежде всего защищенные криптопротоколы, с использованием которых появляется возможность надежной защиты соединения. В следующем пункте пойдет речь о существующих на сегодняшний день в Internet подходах и основных, уже разработанных, криптопротоколах.

К иному классу программных методов защиты от удаленных атак относятся существующие на сегодняшний день программы, основная цель которых - анализ сетевого трафика на предмет наличия одного из известных активных удаленных воздействий. Об этом пункт 7.2.2.2.

Протоколы

Протоколами называют распределенные алгоритмы, определяющие, каким образом осуществляется обмен данными между физическими устройствами или логическим объектами (процессами). Под семейством протоколов TCP/IP в широком смысле обычно понимают весь набор реализаций стандартов RFC (Requests For Comments), а именно:

Internet Protocol (IP);

Address Resolution Protocol (ARP);

Internеt Control Message Protocol (ICMP);

User Datagram Protocol (UDP);

Transport Control Protocol (TCP);

Routing Information Protocol (RIP);

Telnet;

Simple Mail Transfer Protocol (SMTP);

Domain Name System (DNS) и другие.

Общим и основополагающим элементом этого семейства является IP протокол. Все протоколы Internet являются открытыми и доступными. Большинство спецификаций протоколов доступно из RFC, например, по адресу ftp.internic.net.

Необходимо отметить, что в конце 80-х годов наблюдался подлинный бум, вызванный разработкой Международной организацией по стандартизации коммуникационных протоколов - ISO (International Standard Organization). Разработанная ISO спецификация, названная моделью взаимодействия открытых систем (OSI - Open Systems Interconnection), заполонила научные публикации. Казалось, что эта модель займет первое место и оттеснит широко распространившийся TCP/IP. Но этого не произошло. Одной из причин этого явилась тщательная проработка протоколов TCP/IP, их функциональность и открытость к наращиванию функциональных возможностей, хотя к настоящему времени достаточно очевидно, что они имеют и множество недостатков.

Приведем сравнительную схему уровневых моделей протоколов министерства обороны США (DoD - Department of Defense), OSI и TCP/IP (рис. 2.1).

Рис. 2.1. Уровневые модели протоколов.

Каждый уровень моделей использует определенный формат сообщений. При переходе сообщения с высшего уровня на низший оно форматируется по правилам низшего уровня и снабжается заголовком (говорят, что сообщение закладывается в конверт).

Физический и канальный уровень модели TCP/IP аналогичны соответствующим уровням OSI:

на физическом уровне осуществляется физическое соединение между компьютерной системой и фи-зической средой передачи. Он определяет распо-ложение кабельных контактов, напряжение пита-ния и т.п. Единицей данных на этом уровне является бит;

на канальном уровне осуществляется пакетиро-вание данных для передачи и распакетирование для приема. Единица данных на этом уровне называется фреймом;

на сетевом уровне осуществляется маршрутизация данных в сети. Единицей данных этого уровня является датаграмма.

Служба имен доменов Internet

Во времена, когда ARPANET состояла из довольно небольшого числа хостов, все они были перечислены в одном файле (HOSTS.TXT). Этот файл хранился в сетевом информационном центре Станфордского исследовательского института (SRI-NIC - Stanford Research Institute Network Information Center). Каждый администратор сайта посылал в SRI-NIC дополнения и изменения, происшедшие в конфигурации его системы. Периодически администраторы переписывали этот файл из SRI-NIC в свои системы, где из него генерировали файл /etc/hosts. С ростом ARPANET это стало чрезвычайно затруднительным. С переходом на TCP/IP совершенствование этого механизма стало необходимостью, поскольку, например, какой-то администратор мог присвоить новой машине имя уже существующей. Решением этой проблемы явилось создание доменов, или локальных полномочий, в которых администратор мог присваивать имена своим машинам и управлять данными адресации в своем домене.

Служба имен доменов - DNS (Domain Name Service) получает и предоставляет информацию про хосты сети. Под доменом понимается множество машин, которые администрируются и поддерживаются как одно целое. Можно сказать, что все машины локальной сети состав-ляют домен в большей сети, хотя можно и разделить машины локальной сети на несколько доменов. При подключении к Internet домен должен быть поименован в соответствии с соглашению об именах Internet. Internet организован как иерархия доменов. Каждый уровень иерархии является ветвью уровня root. На каждом уровне Internet находится сервер имен - машина, которая содержит информацию о машинах низшего уровня и соответствии их имен IP-адресам. Схема построения иерархии доменов приведена на рис. 2.3.

Рис. 2.3. Структура имен доменов.

Домен корневого уровня формируется NIC.

Домены верхнего уровня имеют следующие ветви: gov (любые правительственные учреждения),edu (образовательные учреждения), arpa (ARPANET), com (коммерческие предприятия), mil (военные организа-ции), org (другие организации, не попадающие в пре-дыдущие). Начиная с весны 1997 IAHC добавил еще

7 доменов: firm (фирмы и направления их деятель-ности), store (торговые фирмы), web (объекты, связан-ные с WWW), arts (объекты, связанные с культурой и искусством), rec (развлечения и отдых), info (инфор-мационные услуги) и nom (прочие). Эти имена соответствуют типам сетей, которые составляют данные домены.

Члены организаций на втором уровне управляют своими серверами имен.

Домены локального уровня администрируются орга-низациями. Локальные домены могут состоять из одного хоста или включать не только множество хостов, но и свои поддомены.

Каждый узел дерева есть домен, который выбран как метка. Имя домена образуется конкатенацией ("склеи-ванием" ) всех меток доменов от корневого до текущего, перечисленных справа налево и разделенных точками. Например, в имени kernel.generic.edu :

edu - соответствует верхнему уровню,

generic - показывает поддомен edu,

kernel - является именем хоста.

Необходимо отметить, что число уровней доменов не ограничено.

Имена доменов являются другим средством дости-жения целевого хоста. В Internet можно встретить имена типа netcom.com или spry.com. Эти имена являются именами доменов, и они зарегистрированы подобным же образом.

Снова sendmail

Здесь мы приведем две уязвимости в программе sendmail (самых последних версий) [20, 21], одна из которых позволяет локальному пользователю стать суперпользователем и относится, таким образом, к сценарию 3. Вторая уязвимость очень серьезна и в некотором роде уникальна: мало того, что она воздействует на sendmail до самой последней версии 8.8, ее использование позволит хакеру выполнить любую команду от имени суперпользователя на вашей машине несмотря на все системы защиты, включая файрволы (firewall). Поэтому она является примером возможности осуществить атаки класса 1 и в наши дни.

Как очевидно, одна из основных функций sendmail - это SMTP-демон, отвечающий на входящие письма. Только суперпользователь может запустить ее в таком режиме, и это проверяется специальной процедурой самой sendmail . Однако из-за ошибки в кодировании sendmail может быть запущена в режиме демона так, что эта проверка будет пропущена, и, таким образом, любой пользователь может это сделать. Более того, начиная с версии 8.7, sendmail перезапустит сам себя, если получит сигнал SIGHUP с помощью системного вызова exec(2), после чего она уже будет исполняться с привилегиями суперпользователя. В этот момент, с помощью манипуляций с переменными sendmail , злоумышленник может заставить ее выполнить любую команду, естественно, с привилегиями суперпользователя. Как стандартный вариант, используется копирование оболочки /bin/sh в /tmp/sh и установкой на него SUID root .

Вторая уязвимость, как уже говорилось, присутствует всегда при наличии sendmail версий до 8.8.4 включительно в своей конфигурации по умолчанию, независимо от присутствия других сервисов и средств защиты типа файрвол. Раз sendmail работает на вашем компьютере, значит, он отправляет и принимает электронную почту. Как оказывается, ничего другого в данном случае кракеру не надо: как в старые добрые времена, "бомба" к вам может попасть в обычном письме стандартного формата, которое, естественно, без всяких подозрений будет пропущено любым файрволом или другим фильтром. Это письмо, однако, будет иметь более чем специфическое содержание в MIME-кодировке, при обработке которого у sendmail банально переполнится буфер, данные попадут в стек и смогут быть интерпретированы как код. Естественно, он выполнится от имени суперпользователя.

Эта ошибочная функция вызывается, кстати, только в том случае, если в конфигурации sendmail стоит недокументированный флаг "-9" .

Какие можно сделать выводы из этого примечательной ситуации? Во-первых, видимо, это один из случаев, когда ошибка в исходном коде была найдена раньше хакерами, а не кракерами. Во-вторых, с другой стороны, как обычно, пройдет много времени, прежде чем все уязвимые версии sendmail будут заменены на новые, а кракеры между тем , уже зная конкретно об этой ошибке, смогут ее максимально использовать. Более того, своей масштабностью она прямо может подтолкнуть их к написанию нового глобального червя. В-третьих, это еще раз доказывает, что любые программы в процессе своего совершенствования могут приобретать новые ошибки, в том числе и такие катастрофичные. В-четвертых, не может не удивлять позиция автора sendmail , который, несмотря на репутацию автора программы, насчитывающей такое же количество ошибок в плане безопасности, что все другие UNIX-программы, вместе взятые" , продолжает свою традицию оставлять недокументированные команды или ключи. Вообще, мы бы не рекомендовали ставить программу sendmail на любой хост, который более или менее критичен к угрозам извне, т. к. ошибки в ней продолжают находиться с пугающей регулярностью.

Современная ситуация

В этом пункте мы наконец перейдем к рассмотрению ситуации с безопасностью UNIX в наши дни. Забегая вперед, сразу скажем, что принципиально ничего не изменилось. Возможно, ошибок в старых версиях UNIX стало меньше, зато появились и появляются новые версии UNIX и, что более важно, другие операционные системы выходят на рынок интернета. Возможно, пользователи стали уделять больше внимания своим паролям, но вычислительная мощность персональных компьютеров удваивается чуть ли не каждый год и программы-вскрыватели становятся все более изощренными. Видимо также, что сегодня хакер уже не будет искать какую-нибудь уязвимость в демонах типа telnetd или ftpd, он возьмет любой из малоизученных - типа httpd.

Далее мы, в большинстве случаев не станем приводить конкретные примеры (exploit) их использования по вполне понятным причинам (тем более что, к счастью, далеко не все уязвимости оглашались после того, как были замечены атаки, их использующие - иногда анализ исходного кода позволяет найти ошибку раньше, чем она начнет "работать" ).

Средства автоматизированного контроля безопасности

Мы уже говорили о полезности средства автоматизированного контроля безопасности отдельного компьютера, а также всей подсети, за которую он отвечает, для системного администратора. Естественно, что такие средства уже появлялись, и чаще других встречаются названия ISS (Internet Security Scaner), COPS (Computer Oracle and Password System) и, конечно, SATAN (Security Administrator Tool for Analizyng Networks). К сожалению, им обычно присущи следующие недостатки:

системозависимость - обычно они рассчитаны на вполне конкретную ОС или даже ее версию;

ненадежность и неадекватность - если эти программы сообщают, что все "О'key" , это совсем не значит, что так на самом деле и есть; и наоборот - некая "уязвимость" , с их точки зрения, может оказаться специальным вариантом конфигурации системы;

малое время жизни - т. к. с момента обнаружения уязвимости до ее искоренения проходит не очень большое время (порядка года), программа быстро устаревает;

неактуальность - более того, с момента выхода программы в свет все новые (поэтому самые опасные) уязвимости оказываются неизвестными для нее, и ее ценность быстро сводится к нулю. Этот недостаток является самым серьезным;

наконец, это возможность их использования с прямо противоположными целями - для поиска изъянов в вашей системе.

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

Стратегии, используемые вирусом

Для проникновения в компьютеры вирус использовал как алгоритмы подбора пароля (это подробнее будет описано в п. 8.4.4), так и "дыры" в различных коммуникационных программах, которые позволяли ему получать доступ без предъявления пароля. Рассмотрим подробнее эти "дыры" .

Типичные атаки

Далее мы рассмотрим типичные атаки на UNIX-хосты, которые осуществлялись в недалеком прошлом, и попытаемся классифицировать их по предложенным типовым сценариям. Почти все атаки даются с подробными листингами, т. к. потенциальный кракер все равно найдет их в том же интернете [16], а главное, что на сегодняшний день они являются достаточно устаревшими и представляют больше теоретический интерес.

Удаленное получение имени и пароля пользователя в Windows NT

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

Этой атаке подвержена и самая современная версия ОС Windows NT 4.0 в сочетании опять-таки с последними версиями броузеров (browser) интернета Microsoft Internet Explorer 3.0x-4.0b или Netscape Navigator 3.x-4.0b2. Вот список уязвимых систем:

Windows 97 Beta (memphis),

Windows NT 3.51 Workstation (видимо, и Server, но это не упоминается в оригинале),

Windows NT 4.0 Server вплоть до Service Pack 2,

Windows NT 4.0 Workstation вплоть до Service Pack 2,

Windows 95, включая Service Pack 1 и OSR2.

Для реализации этой атаки злоумышленником создается специальная HTML-страница "капкан" , которая, помимо всего прочего, содержит ссылку следующего вида: file://\\server\share\image.gif. Это ссылка на ресурсы в формате CIFS ( Common Internet File System ), находящиеся на другом хосте. CIFS -интернет-версия протокола SMB ( Server Message Block ), который используется Microsoft для разделения ресурсов в своих локальных сетях. Естественно, злоумышленнику нет никакой надобности использовать второй хост, он может сделать ссылку на себя.

Для того, чтобы пользователь смог обратиться к этим ресурсам (в нашем случае - скачать картинки), он должен зарегистрироваться на предложенном ему SMB-сервере (типа Lanman ). Windows NT позволяет сделать это, даже не спрашивая пользователя о подтверждении: она просто передает имя и хэшированный пароль пользователя на сервер Lanman ! Ну, а этот сервер, т. к. мы предполагаем, что он кракерский, запоминает имя и пароль пользователя для дальнейших криптоатак, самой успешной из которых, как обычно, будет по словарю.

Таким образом, то, о чем так давно не могли уже мечтать UNIX-хакеры, свершилось! Можно удаленно стянуть имя и зашифрованный пароль пользователя, за исключением того, правда, что эта атака пассивна - незадачливый "клиент" сам заходит на враждебный сайт, а не наоборот. Заметим, кстати, что скорость перебора NT-паролей достигает 2500 паролей/сек на современном Pentium. Но поскольку схема хэширования в NT несколько упрощена тем, что отсутствует понятие salt (см. п. 8.5.1), можно поднять ее на несколько порядков, если предварительно схэшировать весь файл паролей, а затем сравнивать результат с захваченным значением.

Представитель Microsoft Mike Nash, отвечающий за маркетинг Windows NT, узнав об этой уязвимости, заявил: "Хорошо, что люди тестируют наши продукты, и лучшее, что мы можем сделать - повысить осведомленность наших покупателей в вопросах безопасности" [15]. Что ж, позиция Microsoft в отношении безопасности своих продуктов, мягко говоря, всегда оставляла желать лучшего.

Удаленные атаки на хосты Internet

Многое

Наша Земля повидала,

Но не видала

Такого скандала!

Б.Заходер. География всмятку.

Удаленные атаки на распределенные вычислительные системы

Непостижимо все, что в мире есть,

К тому ж изъянов в том, что есть, не счесть.

О.Хайам. Рубайи.

Как уже отмечалось ранее, основной особенностью любой распределенной системы является то, что ее компоненты распределены в пространстве и связь между ними физически осуществляется при помощи сетевых соединений и программно при помощи механизма сообщений. При этом все управляющие сообщения и данные, пересылаемые между объектами распределенной ВС, передаются по сетевым соединениям в виде пакетов обмена. Эта особенность и является основной для рассматриваемых в этой главе удаленных атак на инфраструктуру и протоколы распределенных ВС.

Удаленные атаки на телекоммуникационные службы

Извечной и зловещей мечтой вирусов является абсолютное мировое

господство, и, как ни ужасны методы, коими они в настоящее время

пользуются, им нельзя отказать в настойчивости, изобретательности и

способности к самопожертвованию во имя великой цели.

А.Стругацкий, Б.Стругацкий.

Сказка о тройке.

Уязвимости в wu-ftpd

FTP-демон wu-ftpd, написанный в вашингтонском университете, является значительным расширением стандартного ftpd. Как обычно, это приводит и к расширению, содержащимся в нем ошибок.

Самой известной из них является ошибка, позволяющая всего-навсего выполнить любую команду от имени суперпользователя, причем для удобства кракера в wu-ftp для этого есть специальная команда, которая так и называется "site exec" (выполнить на сайте) [26]. Эта атака интересна тем, что не подходит ни под один из сценариев: в принципе, она проходит аналогично типовым атакам по сценарию 1 или 2, взаимодействуя с удаленным демоном, но для ее успешности необходимы полномочия обычного пользователя: evil#rootftp victim.com

220 victim FTP server (Version wu-2.4(1) Sun Jul 31 21:15:56 CDT 1994) ready. Name (victim: root ): good

331 Password required for good. Password: ***** 230 User good logged in. Remote system type is UNIX. Using binary mode to transfer files. ftp> quote "site exec bash -c id"

200-bash -c id 200-uid=0( root ) gid=0( root ) euid=505(statik) egid=100(users) groups=100(users) 200 (end of 'bash -c id')

Видно, что в последней строчке на удаленном хосте выполнилась команда id от имени суперпользователя - это означает, что хост уязвим.

Другая уязвимость, которой подвержены версии wu-ftpd, вплоть до самых последних, состоит в том, что при определенных условиях можно переполнить список аргументов команды, что приведет к сбросу демоном аварийного дампа памяти. Для этого нужны минимальные полномочия анонимного пользователя ftp. Что самое интересное, этот дамп будет иметь владельцем не root , как обычно бывает, а anonymous и будет сбрасываться в его домашний каталог. Отсюда прямо следует, что он может быть позже прочитан удаленно. Ну, а чтение аварийного дампа равносильно копанию в корзине для бумаг на секретном объекте - среди мусора могут быть найдены очень любопытные вещи, например, сброшенные кэшированные пароли. Так что злоумышленнику останется только запустить взломщик паролей поновее.

Виртуальный канал как средство

В предыдущем пункте рассматривались возможные наиболее безопасные варианты физического построения сети: как в РВС необходимо соединять объекты для обеспечения наиболее безопасного взаимодействия. Однако, для создания защищенного взаимодействия удаленных объектов подобных мер явно недостаточно, так как, во-первых, на практике обеспечить взаимодействие всех объектов по выделенному каналу достаточно сложно и, во-вторых, нельзя не предусмотреть вариант физического подключения к каналу. Следовательно, разработчик защищенной системы связи в распределенной ВС должен исходить из следующего принципа:

Утверждение 2.

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

Таким образом, данное утверждение накладывает на разработчика следующие требования: необходимость введения дополнительных средств идентификации объектов в распределенной ВС и криптозащита передаваемых по каналу связи сообщений.

В п. 5.1.2 доказывалось, что идентификация объектов РВС, в отсутствие статической ключевой информации, возможна только при взаимодействии объектов с использованием виртуального канала (заметим, что в дальнейшем рассматривается только распределенная ВС, у объектов которой отсутствует ключевая информация для связи друг с другом - в подобной системе решить задачу безопасного взаимодействия несколько сложнее). Следовательно, для того, чтобы ликвидировать причину успеха удаленных атак, описанную в п. 5.1.2.1, а также, исходя из Утверждения 2, необходимо руководствоваться следующим правилом:

Утверждение 3.

Любое взаимодействие двух объектов в распределенной ВС должно проходить по виртуальному каналу связи.

Рассмотрим, как в распределенной ВС виртуальный канал (ВК) связи может использоваться для надежной, независимой от топологии и физической организации системы, идентификации ее удаленных объектов.

Для этого при создании ВК могут использоваться криптоалгоритмы с открытым ключом (например, недавно в Internet принят подобный стандарт защиты ВК, называемый Secret Socket Layer - SSL). Данные криптоалгоритмы основаны на результатах исследований, полученных в 70-х годах У. Диффи. Он ввел понятие односторонней функции с потайным входом. Это не просто вычисляемая в одну сторону функция, обращение которой невозможно, она содержит потайной вход (trapdoor), который позволяет вычислять обратную функцию лицу, знающему секретный ключ. Сущность криптографии с открытым ключом (или двухключевой криптографии) в том, что ключи, имеющиеся в криптосистеме, входят в нее парами и каждая пара удовлетворяет следующим двум свойствам:

текст, зашифрованный на одном ключе, может быть дешифрован на другом;

знание одного ключа не позволяет вычислить другой.

Поэтому один из ключей может быть опубликован. При опубликованном (открытом) ключе шифрования и секретном ключе дешифрования получается система шифрования с открытым ключом. Каждый пользователь сети связи может зашифровать сообщение при помощи открытого ключа, а расшифровать его сможет только владелец секретного ключа. При опубликовании ключа дешифрования получается система цифровой подписи. Здесь только владелец секретного ключа создания подписи может правильно зашифровать текст (т.е. подписать его), а проверить подпись (дешифровать текст) может любой на основании опубликованного ключа проверки подписи.

В 1976 г. У. Диффи и М. Хеллман предложили следующий метод открытого распределения ключей. Пусть два объекта A и B условились о выборе в качестве общей начальной информации большого простого числа p и примитивного корня степени p - 1 из 1 в поле вычетов по модулю p. Тогда эти пользователи действуют в соответствии с протоколом (рис. 6.4):

A вырабатывает случайное число x, вычисляет число ax (mod p) и посылает его B;

B вырабатывает случайное число y, вычисляет число ay (mod p) и посылает его A;

затем A и B возводят полученное число в степень со своим показателем и получают число axy (mod p).

Рис. 6.4. Алгоритм У. Диффи и М. Хеллмана открытого распределения ключей

Это число и является сеансовым ключом для одноключевого алгоритма, например, DES. Для раскрытия этого ключа криптоаналитику необходимо по известным ax (mod p), ay (mod p) найти axy (mod p) , т.е. найти x или y. Нахождение числа x по его экспоненте ax (mod p) называется задачей дискретного логарифмирования в простом поле. Эта задача является труднорешаемой, и поэтому полученный ключ, в принципе, может быть стойким [11].

Особенность данного криптоалгоритма состоит в том, что перехват по каналу связи пересылаемых в процессе создания виртуального канала сообщений ax (mod p) и ay (mod p) не позволит атакующему получить конечный ключ шифрования axy (mod p). Этот ключ далее должен использоваться, во-первых, для цифровой подписи сообщений и, во-вторых, для их криптозащиты. Цифровая подпись сообщений позволяет надежно идентифицировать объект распределенной ВС и виртуальный канал. Шифрование сообщений необходимо для соблюдения Утверждения 2. В заключении к данному пункту сформулируем следующее требование к созданию защищенных систем связи в распределенных ВС и два следствия из него:

Утверждение 4.

Для обеспечения надежной идентификации объектов распределенной ВС при создании виртуального канала необходимо использовать криптоалгоритмы с открытым ключом.

Следствие 4.1.

Необходимо обеспечить цифровую подпись сообщений.

Следствие 4.2.

Необходимо обеспечить возможность шифрования сообщений.

Вместо введения

Но сначала нам надо с тобой
договориться, как именно мы определим,
о чем мы советуемся, дабы не выходило,
что я разумею одно, ты же - другое...
Платон. Диалоги.

В последние полтора-два года книжные прилавки стали заполняться всевозможными книгами и журналами, в названии которых присутствует слово "Internet" . Эти книги являются отражением того, что Internet пришел в Россию. Появились пользователи и провайдеры, с каждым днем растет количество всевозможных сайтов, начали формироваться свои службы, да и престиж заставляет некоторых подключаться к Internet. Появился и спрос на литературу об Internet.

Даже поверхностный анализ этой литературы показывает, что практически в каждой такой книге имеется материал, посвященный безопасности. Это может быть или глава, или раздел, или параграф. Анализ этого материала показывает, что в нем не дается ответ на главный вопрос: безопасна ли Internet и как обезопасить свой компьютер, подключенный к Internet?

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

Внедрение в сеть Internet ложного

Другой вариант осуществления удаленной атаки, направленной на службу DNS, основан на второй разновидности типовой УА "Ложный объект РВС" (при использовании недостатков алгоритмов удаленного поиска - п. 3.2.3.2). В этом случае атакующий осуществляет постоянную передачу на атакуемый хост заранее подготовленного ложного DNS-ответа от имени настоящего DNS-сервера без приема DNS-запроса! Другими словами, атакующий создает в сети Internet направленный "шторм" ложных DNS-ответов. Это возможно, так как обычно для передачи DNS-запроса используется протокол UDP, в котором отсутствуют средства идентификации пакетов. Единственными критериями, предъявляемыми сетевой ОС хоста к полученному от DNS-сервера ответу, является, во-первых, совпадение IP-адреса отправителя ответа с IP-адресом DNS-серве-ра; во-вторых, чтобы в DNS-ответе было указано то же имя, что и в DNS-запросе, в-третьих, DNS-ответ должен быть направлен на тот же UDP-порт, с которого был послан DNS-запрос (в данном случае это первая проблема для атакующего), и, в-четвертых, в DNS-ответе поле идентификатора запроса в заголовке DNS (ID) должно содержать то же значение, что и в переданном DNS-запросе (а это вторая проблема).

В данном случае, так как атакующий не имеет возможности перехватить DNS-запрос, то основную проблему для него представляет номер UDP-порта, с которого был послан запрос. Однако, как было отмечено ранее, номер порта отправителя принимает ограниченный набор значений (>= 1023), поэтому атакующему достаточно действовать простым перебором, направляя ложные ответы на соответствующий перечень портов. На первый взгляд, второй проблемой может быть двухбайтовый идентификатор DNS-запроса, но, как подчеркивалось ранее, в данном случае он либо равен единице, либо в случае DNS-запроса от Netscape Navigator (например) имеет значение близкое к нулю (один запрос - ID увеличивается на 1).

Рис. 4.5. Внедрение в Internet ложного сервера путем создания направленного "шторма" ложных DNS-ответов на атакуемый хост.

Рис. 4.5.1. Атакующий создает направленный "шторм" ложных DNS-ответов на Хост 1.

Рис. 4.5.2. Хост 1 посылает DNS-запрос и немедленно получает ложный DNS-ответ.

Рис. 4.5.3. Фаза приема, анализа, воздействия и передачи перехваченной информации на ложном сервере.

Поэтому для осуществления данной удаленной атаки атакующему необходимо выбрать интересующий его хост (например, top.secret.com), маршрут к которому требуется изменить так, чтобы он проходил через ложный сервер - хост атакующего. Это достигается постоянной передачей (направленным "штормом" ) атакующим ложных DNS-ответов на атакуемый хост от имени настоящего DNS-сервера на соответствующие UDP-порты. В этих ложных DNS-ответах указывается в качестве IP-адреса хоста top.secret.com IP-адрес атакующего. Далее атака развивается по следующей схеме. Как только цель атаки (атакуемый хост) обратится по имени к хосту top.secret.com, то от данного хоста в сеть будет передан DNS-запрос, который атакующий никогда не получит, но этого ему и не требуется, так как на хост сразу же поступит постоянно передаваемый ложный DNS-ответ, что и будет воспринят ОС атакуемого хоста как настоящий ответ от DNS-сервера. Все! Атака состоялась, и теперь атакуемый хост будет передавать все пакеты, предназначенные для top.secret.com, на IP-адрес хоста атакующего, который, в свою очередь, будет переправлять их на top.secret.com, воздействуя на перехваченную информацию по схеме "Ложный объект РВС" (п. 3.2.3.3).

Рассмотрим функциональную схему предложенной удаленной атаки на службу DNS (рис. 4.5):

постоянная передача атакующим ложных DNS-ответов на атакуемый хост на различные UDP-порты и, возможно, с различными ID, от имени (с IP-адреса) настоящего DNS-сервера с указанием имени интересующего хоста и его ложного IP-адреса, которым будет являться IP-адрес ложного сервера - хоста атакующего;

в случае получения пакета от хоста, изменение в IP-заголовке пакета его IP-адреса на IP-адрес атакующего и передача пакета на сервер (то есть ложный сервер ведет работу с сервером от своего имени - со своего IP-адреса);

в случае получения пакета от сервера, изменение в IP-заголовке пакета его IP-адреса на IP-адрес ложного сервера и передача пакета на хост (для хоста ложный сервер и есть настоящий сервер).

Таким образом, реализация данной удаленной атаки, использующей пробелы в безопасности службы DNS, позволяет из любой точки сети Internet нарушить маршрутизацию между двумя заданными объектами (хос-тами)! Данная удаленная атака осуществляется межсегментно по отношению к цели атаки и угрожает безопасности любого хоста Internet, использующего обычную службу DNS.

Внедрение в сеть Internet ложного DNS-сервера путем перехвата DNS-запроса

В данном случае это удаленная атака на базе стандартной типовой УА, связанной с ожиданием поискового DNS-запроса. Перед тем, как рассмотреть алгоритм атаки на службу DNS, необходимо обратить внимание на следующие тонкости в работе этой службы.

Во-первых, по умолчанию служба DNS функционирует на базе протокола UDP (хотя возможно и использование протокола TCP) что, естественно, делает ее менее защищенной, так как протокол UDP в отличие от TCP вообще не предусматривает средств идентификации сообщений. Для того, чтобы перейти от UDP к TCP, администратору DNS-сервера придется очень серьезно изучить документацию (в стандартной документации на домен named в ОС Linux нет никакого упоминания о возможном выборе протокола (UDP или TCP), на котором будет работать DNS-сервер). Кроме того, этот переход несколько замедлит систему, так как при использовании TCP требуется создание виртуального соединения, и, кроме того, конечная сетевая ОС вначале посылает DNS-запрос с использованием протокола UDP. И только в том случае, если ей придет специальный ответ от DNS-сервера, сетевая ОС пошлет DNS-запрос с использованием TCP.

Во-вторых, следующая тонкость, на которую требуется обратить внимание, состоит в том, что значение поля "порт отправителя" в UDP-пакете вначале принимает значение ? 1023 и увеличивается с каждым переданным DNS-запросом.

В-третьих, значение идентификатора (ID) DNS-запроса ведет себя следующим образом. В случае передачи DNS-запроса с хоста это значение зависит от конкретного сетевого приложения, вырабатывающего DNS-запрос. Эксперименты показали, что в случае передачи запроса из оболочки командного интерпретатора (SHELL) операционных систем Linux и Windows '95 (например, ftp nic.funet.fi) это значение всегда равняется единице. В том случае, если DNS-запрос передается из Netscape Navigator, то с каждым новым запросом сам броузер увеличивает это значение на единицу. В том случае, если запрос передается непосредственно DNS-сервером, то сервер увеличивает это значение идентификатора на единицу с каждым вновь передаваемым запросом. Все эти тонкости имеют значение в случае атаки без перехвата DNS-запроса (п. 4.3.2 и 4.3.3).

Для реализации атаки путем перехвата DNS-запроса атакующему необходимо перехватить DNS-запрос, извлечь из него номер UDP-порта отправителя запроса, двухбайтовое значение ID идентификатора DNS-запроса и искомое имя и затем послать ложный DNS-ответ на извлеченный из DNS-запроса UDP-порт, в котором указать в качестве искомого IP-адреса настоящий IP-адрес ложного DNS-сервера. Это позволит в дальнейшем полностью перехватить трафик между атакуемым хостом и сервером и активно воздействовать на него по схеме "Ложный объект РВС" (п. 3.2.3.3).

Рассмотрим обобщенную схему работы ложного DNS-сервера (рис. 4.4):

ожидание DNS-запроса;

извлечение из полученного запроса необходимых сведений и передача по сети на запросивший хост ложного DNS-ответа, от имени (с IP-адреса) настоящего DNS-сервера, в котором указывается IP-адрес ложного DNS-сервера;

в случае получения пакета от хоста, изменение в IP-заголовке пакета его IP-адреса на IP-адрес ложного DNS-сервера и передача пакета на сервер (то есть ложный DNS-сервер ведет работу с сервером от своего имени);

в случае получения пакета от сервера, изменение в IP-заголовке пакета его IP-адреса на IP-адрес ложного DNS-сервера и передача пакета на хост (для хоста ложный DNS-сервер и есть настоящий сервер).

Рис. 4.4. Функциональная схема ложного DNS-сервера.

Рис. 4.4.1. Фаза ожидания атакующим DNS-запроса (он находится на ХА1, либо на ХА2).

Рис. 4.4.2. Фаза передачи атакующим ложного DNS-ответа.

Рис. 4.4.3. Фаза приема, анализа, воздействия и передачи перехваченной информации на ложном сервере.

Необходимым условием осуществления данного варианта атаки является перехват DNS-запроса. Это возможно только в том случае, если атакующий находится либо на пути основного трафика, либо в сегменте настоящего DNS-сервера. Выполнение одного из этих условий местонахождения атакующего в сети делает подобную удаленную атаку трудно осуществимой на практике (попасть в сегмент DNS-сервера и, тем более, в межсегментный канал связи атакующему, скорее всего, не удастся). Однако в случае выполнения этих условий возможно осуществить межсегментную удаленную атаку на сеть Internet.

Отметим, что практическая реализация данной удаленной атаки выявила ряд интересных особенностей в работе протокола FTP и в механизме идентификации TCP-пакетов (подробнее см. п. 4.5). В случае, когда FTP-клиент на хосте подключался к удаленному FTP-серверу через ложный DNS-сервер, оказывалось, что каждый раз после выдачи пользователем прикладной команды FTP (например, ls, get, put и т. д.) FTP-клиент вырабатывал команду PORT, которая состояла в передаче на FTP-сервер в поле данных TCP-пакета номера порта и IP-адреса клиентского хоста (особый смысл в этих действиях трудно найти - зачем каждый раз передавать на FTP-сервер IP-адрес клиента)! Это приводило к тому, что, если на ложном DNS-сервере не изменить передаваемый IP-адрес в поле данных TCP-пакета и передать этот пакет на FTP-сервер по обыкновенной схеме, то следующий пакет будет передан FTP-сервером на хост FTP-клиента, минуя ложный DNS-сервер и, что самое интересное, этот пакет будет воспринят как нормальный пакет (п. 4.5), и, в дальнейшем, ложный DNS-сервер потеряет контроль над трафиком между FTP-сервером и FTP-клиентом! Это связано с тем, что обычный FTP-сервер не предусматривает никакой дополнительной идентификации FTP-клиента, а перекладывает все проблемы идентификации пакетов и соединения на более низкий уровень - уровень TCP (транспортный).

Всемогущество хакеров

Глубокое непонимание большинством обывателей проблем, связанных с информационной безопасностью в вычислительных системах, с течением времени сформировало определенный миф о всемогуществе хакеров и повсеместной беззащитности компьютерных систем. Да, отчасти этот миф является реальностью. Действительно, современные вычислительные системы и сети общего назначения имеют серьезнейшие проблемы с безопасностью. Но, подчеркнем, именно вычислительные системы общего назначения. Там же, где требуется обработка критической информации и обеспечение высшего уровня защиты и секретности (например, в военной области, в атомной энергетике и т. п.), используются специализированные защищенные ВС, которые (и это чрезвычайно важно!) в основном изолированы от сетей общего назначения (от сети Internet, например). Поэтому необходимо развеять первый миф, который очень популярен в художественной литературе, кино, а также в средствах массовой информации: кракер не может проникнуть извне в вычислительную систему стратегического назначения (например, в ВС атомной станции или пункта управления стратегическими вооружениями). Однако, речь идет о невозможности получения несанкционированного удаленного доступа именно "извне" . В том случае, если кракер из состава персонала защищенной ВС вознамерится нанести ущерб данной системе, то сложно абстрактно судить о том, насколько успешны будут его попытки.

В качестве примера напомним случай на Игналинской АЭС, когда местный системный программист внедрил в вычислительную систему программную закладку ("троянского коня" ), которая чуть не привела к аварии станции. Однако, как утверждает статистика, нарушения безопасности ВС собственным персоналом составляют около 90 процентов от общего числа нарушений. Подводя итог, мы не утверждаем, что критические вычислительные системы неуязвимы, практически невозможно лишь реализовать на них успешную удаленную атаку.

Прочитав этот пункт, недоверчивый читатель может заметить, что он лично встречал заметки о том, как "кракеры проникли в компьютер Пентагона или

НАСА" . Все дело в том, что, как и любая другая уважающая себя организация, будь то ЦРУ, АНБ или НАСА, они имеют свои WWW- или ftp-сервера, находящиеся в открытой сети и доступные всем. И кракеры в этом случае проникали именно в них (а ни в коем случае не в секретные или закрытые), используя, может быть, один из механизмов, описанных в этой книге.

Такое утверждение оказывается не совсем

Интернет - это сеть UNIX-машин. Такое утверждение оказывается не совсем справедливым в наше время (когда успех и конкурентоспособность операционной системы напрямую зависит от того, насколько легко они интегрируются в Сеть), однако Internet и его прадед - ARPANET возникли именно из необходимости связать между собой UNIX-компьютеры, которые были самыми распространенными и прогрессивными в то время. UNIX-идеология наложила свой отпечаток и на все основные сетевые протоколы, которые, казалось бы, должны быть операционно-независимыми.
Поэтому большинством всех проблем, которые возникают сегодня в Сети, - и особенно проблемами безопасности - мы должны быть "благодарны" UNIX. Мы ни в коем случае не хотим принизить значение принципов его построения для развития операционных систем, но общеизвестно, что у UNIX в ее классическом варианте слишком много проблем с безопасностью, причем эти проблемы настолько глубоки, что корректное и надежное их искоренение приведет к перерождению UNIX как таковой - это будет новая операционная система. Много пролито слез по этому поводу: "Ах, если бы разработчики UNIX уделили больше внимания безопасности" , - но не следует забывать, что все концепции UNIX прорабатывались в конце 60-х годов, когда еще практически не было никакой теории компьютерной безопасности, а раз работчики и вовсе делали ее "под себя" , не подозревая, насколько через несколько лет компьютерный мир станет теснее (появятся сети) и опаснее (появятся кракеры).
Поэтому естественно, что современные операционные системы (Novell Netware, Windows NT) оказываются в заведомо более выгодном положении - они разрабатывались, во-первых, с учетом ошибок UNIX, а во-вторых, они придерживаются четкой концепции клиент-сервер (не будем сейчас дискутировать об ее достоинствах и недостатках). Однако теория безопасности гласит, что безопасность системы определяется безопасностью ее слабейшего звена, и поэтому далее мы будем рассматривать безопасность интернета именно как безопасность UNIX-систем, которых и на сегодняшней день в интернете, видимо, 70- 80%. Это не означает, кстати, что остальные 20- 30% хорошо защищены и атаки на них невозможны - просто эти системы на сегодняшний день гораздо меньше изучены, и совсем не исключено, что в них найдутся такие же серьезные бреши в безопасности, как в UNIX, особенно учитывая, что и фирма Novell, и Microsoft далеко не безгрешны в этом отношении [9, 15].
Более того, самые последние события конца 1996 - начала 1997 года позволяют предположить, что не UNIX-совместимые ОС, несмотря на печальный опыт своей предшественницы, начинают проходить тот же самый путь и совершать те же самые ошибки в обеспечении безопасности (на другом витке спирали, естественно). Так уже несбыточная сегодня мечта всех кракеров удаленно утянуть файл /etc/passwd оказывается вполне реальной даже в такой более-менее защищенной ОС, как Windows NT (см. п. 8.6.5)

Выделенный канал связи между объектами распределенной ВС

Все объекты распределенной ВС взаимодействуют между собой по каналам связи. В п. 5.1.1 рассматривалась причина успеха УА, состоящая в использовании в РВС для связи между объектами широковещательной среды передачи которое означает, что все объекты распределенной ВС подключаются к одной общей шине (топология сети - "общая шина" , рис. 6.1). Это приводит к тому, что сообщение, предназначенное (адресованное) только одному объекту системы, будет получено всеми ее объектами. Однако только объект, адрес которого указан в заголовке сообщения как адрес назначения, будет считаться тем объектом, кому это сообщение непосредственно направлялось. Очевидно, что в РВС с топологией "общая шина" необходимо использовать специальные методы идентификации объектов (п. 6.2), так как идентификация на канальном уровне возможна только в случае использования сетевых криптокарт.

Также очевидно, что идеальной с точки зрения безопасности будет взаимодействие объектов распределенной ВС по выделенным каналам. Существуют два возможных способа организации топологии распределенной ВС с выделенными каналами. В первом случае каждый объект связывается физическими линиями связи со всеми объектами системы (рис. 6.2). Во втором случае в системе может использоваться сетевой концентратор, через который осуществляется связь между объектами (топология "звезда" - рис. 6.3).

Следует заметить, что в этом случае нарушается один из принципов, на которых строилась сеть Internet: сеть должна функционировать при выходе из строя любой ее части.

Рис. 6.1. Сетевая топология "общая шина".

Рис. 6.2 . Сетевая топология "N-объектов - N-каналов".

Рис. 6.3. Сетевая топология "звезда".

Плюсы распределенной ВС с выделенными каналами связи между объектами состоят в следующем:

передача сообщений осуществляется напрямую между источником и приемником, минуя остальные объекты системы. В такой системе в случае отсутствия доступа к объектам, через которые осуществляется передача сообщения, не существует программной возможности для анализа сетевого трафика;

имеется возможность идентифицировать объекты распределенной системы на канальном уровне по их адресам без использования специальных криптоалгоритмов шифрования трафика. Это оказывается, поскольку система построена так, что по данному выделенному каналу осуществима связь только с одним определенным объектом. Появление в такой распределенной системе ложного объекта невозможно без аппаратного вмешательства (подключение дополнительного устройства к каналу связи);

система с выделенными каналами связи - это система, в которой отсутствует неопределенность с информацией о ее объектах (п. 5.1.5). Каждый объект в такой системе изначально однозначно идентифицируется и обладает полной информацией о других объектах системы.

К минусам РВС с выделенными каналами относятся:

сложность реализации и высокие затраты на создание системы;

ограниченное число объектов системы (зависит от числа входов у концентратора);

сложность внесения в систему нового объекта.

Очевидно также, что создание глобальной РВС с выделенными каналами потребует колоссальных затрат и возможно на сегодняшний день.

Анализируя все плюсы и минусы использования выделенных каналов для построения защищенных систем связи между объектами РВС, можно сделать вывод, что создание распределенных систем только с использованием широковещательной среды передачи или только с выделенными каналами неэффективно. Поэтому представляется правильным при построении распределенных вычислительных систем с разветвленной топологией и большим числом объектов использовать комбинированные варианты соединений объектов. Для обеспечения связи между объектами большой степени значимости можно использовать выделенный канал. Связь менее значимых объектов системы может осуществляться с использованием комбинации общая шина-выделенный канал.

В данном пункте были рассмотрены варианты сетевых топологий с выделенными каналами связи. При этом рассматривались только физические каналы связи и предлагались более или менее безопасные способы взаимодействия объектов системы по этим каналам. Однако выбор безопасной топологии РВС является необходимым, но отнюдь не достаточным условием для создания защищенных систем связи между объектами распределенных ВС.

Итак, в завершение данного пункта сформулируем первый принцип создания защищенных средств связи объектов в РВС:

Утверждение 1.

Наилучшее с точки зрения безопасности взаимодействие объектов в распределенной ВС возможно только по физически выделенному каналу.

Заканчивая чтение предложенного материала об

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

---

---