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

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

Классификация удаленных атак на распределенные вычислительные системы

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

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

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

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

Удаленное воздействие, также как и любое другое, может начать осуществляться только при определенных условиях. В распределенных ВС существуют три вида условий начала осуществления удаленной атаки:
- Атака по запросу от атакуемого объекта (класс 3.1)
В этом случае атакующий ожидает передачи от потенциальной цели атаки запроса определенного типа, который и будет условием начала осуществления воздействия. Примером подобных запросов в ОС Novell NetWare может служить SAP-запрос, а в сети Internet - DNS- и ARP-запросы. Удаленные атаки на объекты сети Internet, осуществляемые по запросу от атакуемой системы. Важно отметить, что данный тип удаленных атак наиболее характерен для распределенных ВС.
- Атака по наступлению ожидаемого события на атакуемом объекте (класс 3.2)
В этом случае атакующий осуществляет постоянное наблюдение за состоянием операционной системы удаленной цели атаки и при возникновении определенного события в этой системе начинает воздействие. Как и в предыдущем случае, инициатором осуществления начала атаки выступает сам атакуемый объект. Примером такого события может быть прерывание сеанса работы пользователя с сервером в ОС Novell NetWare без выдачи команды LOGOUT .
- Безусловная атака (класс 3.3)
В этом случае начало осуществления атаки безусловно по отношению к цели атаки, то есть атака осуществляется немедленно и безотносительно к состоянию системы и атакуемого объекта. Следовательно, в этом случае атакующий является инициатором начала осуществления атаки

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

5. По расположению субъекта атаки относительно атакуемого объекта
- внутрисегментное (класс 5.1)
- межсегментное (класс 5.2)
Рассмотрим ряд определений:
Субъект атаки (или источник атаки) - это атакующая программа или оператор, непосредственно осуществляющие воздействие.
Хост (host) - сетевой компьютер.
Маршрутизатор (router) - устройство, обеспечивающее маршрутизацию пакетов обмена в глобальной сети. Подсеть (subnetwork) (в терминологии Internet) - совокупность хостов, являющихся частью глобальной сети, для которых маршрутизатором выделен одинаковый номер подсети. Подсеть - логическое объединение хостов маршрутизатором. Хосты внутри одной подсети могут взаимодействовать между собой непосредственно, минуя маршрутизатор.Сегмент сети - физическое объединение хостов. Например, сегмент сети образуют совокупность хостов, подключенных к серверу по схеме "общая шина". При такой схеме подключения каждый хост имеет возможность подвергать анализу любой пакет в своем сегменте.С точки зрения удаленной атаки чрезвычайно важно, как по отношению друг к другу располагаются субъект и объект атаки, то есть в одном или в разных сегментах они находятся. В случае внутрисегментной атаки, как следует из названия, субъект и объект атаки находятся в одном сегменте. При межсегментной атаке субъект и объект атаки находятся в разных сегментах.
Данный классификационный признак позволяет судить о так называемой "степени удаленности" атаки. На практике межсегментную атаку осуществить значительно труднее, чем внутрисегментную. Межсегментная удаленная атака представляет гораздо большую опасность, чем внутрисегментная. Это связано с тем, что в случае межсегментной атаки объект её и непосредственно атакующий могут находиться на расстоянии многих тысяч километров друг от друга, что может существенно воспрепятствовать мерам по отражению атаки.

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.

Характеристика и механизмы реализации типовых удаленных атак

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

Анализ сетевого трафика

Как уже отмечалось, основной особенностью распределенной ВС является то, что ее объекты распределены в пространстве и связь между ними физически осуществляется по сетевым соединениям и программно - при помощи механизма сообщений. При этом все управляющие сообщения и данные, пересылаемые между объектами РВС, передаются по сетевым соединениям в виде пакетов обмена. Эта особенность привела к появлению специфичного для распределенных ВС типового удаленного воздействия, заключающегося в прослушивании канала связи. Назовем данное типовое удаленное воздействие анализом сетевого трафика (или, сокращенно, сетевым анализом).
Анализ сетевого трафика позволяет, во-первых, изучить логику работы распределенной ВС, то есть получить взаимно однозначное соответствие событий, происходящих в системе, и команд, пересылаемых друг другу ее объектами, в момент появления этих событий (если проводить дальнейшую аналогию с инструментарием хакера, то анализ трафика в этом случае заменяет и трассировщик). Это достигается путем перехвата и анализа пакетов обмена на канальном уровне. Знание логики работы распределенной ВС позволяет на практике моделировать и осуществлять типовые удаленные атаки, рассмотренные в следующих пунктах на примере конкретных распределенных ВС.
Во-вторых, анализ сетевого трафика позволяет пере-хватить поток данных, которыми обмениваются объекты распределенной ВС. Таким образом, удаленная атака данного типа заключается в получении на удаленном объекте несанкционированного доступа к информации, которой обмениваются два сетевых абонента. При этом отсутствует возможность модификации трафика и сам анализ возможен только внутри одного сегмента сети. Примером перехваченной при помощи данной типовой удаленной атаки информации могут служить имя и пароль пользователя, пересылаемые в незашифрованном виде по сети .
По характеру воздействия анализ сетевого трафика является пассивным воздействием (класс 1.1). Осуществление данной атаки без обратной связи (класс 4.2) ведет к нарушению конфиденциальности информации (класс 2.1) внутри одного сегмента сети (класс 5.1) на канальном уровне OSI (класс 6.2). При этом начало осуще-ствления атаки безусловно по отношению к цели атаки (класс 3.3).

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

Одной из проблем безопасности распределенной ВС является недостаточная идентификация и аутентификация ее удаленных друг от друга объектов. Основная трудность заключается в осуществлении однозначной идентификации сообщений, передаваемых между субъектами и объектами взаимодействия. Обычно в распределенных ВС эта проблема решается следующим образом: в процессе создания виртуального канала объекты РВС обмениваются определенной информацией, уникально идентифицирующей данный канал. Такой обмен обычно называется "рукопожатием" (handshake). Однако не всегда для связи двух удаленных объектов в РВС создается виртуальный канал. Практика показывает, что зачастую, особенно для служебных сообщений (!?) (например, от маршрутизаторов) используется передача одиночных сообщений, не требующих подтверждения.
Как известно, для адресации сообщений в распределенных ВС используется сетевой адрес, который уникален для каждого объекта системы (на канальном уровне модели OSI - это аппаратный адрес сетевого адаптера. на сетевом уровне - адрес определяется в зависимости от используемого протокола сетевого уровня (например. IP-адрес). Сетевой адрес также может использоваться для идентификации объектов распределенной ВС. Однако сетевой адрес достаточно просто подделывается и поэтому использовать его в качестве единственного сред-ства идентификации объектов недопустимо.
В том случае, когда распределенная ВС использует нестойкие алгоритмы идентификации удаленных объектов, то оказывается возможной типовая удаленная атака, заключающаяся в передаче по каналам связи сообщений от имени произвольного объекта или субъекта РВС. При этом существуют две разновидности данной типовой удаленной атаки:
- атака при установленном виртуальном канале,
- атака без установленного виртуального канала.
В случае установленного виртуального соединения атака будет заключаться в присвоении прав доверенного субъекта взаимодействия, легально подключившегося к объекту системы, что позволит атакующему вести сеанс работы с объектом распределенной системы от имени доверенного субъекта. Реализация удаленных атак данного типа обычно состоит в передаче пакетов обмена с атакующего объекта на цель атаки от имени доверенного субъекта взаимодействия (при этом переданные сообщения будут восприняты системой как корректные). Дляосуществления атаки данного типа необходимо преодолеть систему идентификации и аутентификации сообщений, которая, в принципе, может использовать контрольную сумму, вычисляемую с помощью открытого ключа, динамически выработанного при установлении канала, случайные многобитные счетчики пакетов и сетевые адре-са станций. Однако на практике, например, в ОС Novell NetWare 3.12-4.1 для идентификации пакетов обмена используются два 8-битных счетчика - номер канала и номер пакета ; в протоколе TCP для идентификации используются два 32-битных счетчика.
Как было замечено выше, для служебных сообщений в распределенных ВС часто используется передача одиночных сообщений, не требующих подтверждения, то есть не требуется создание виртуального соединения. Атака без установленного виртуального соединения заключается в передаче служебных сообщений от имени сетевых управляющих устройств, например, от имени маршрутизаторов.
Очевидно, что в этом случае для идентификации пакетов возможно лишь использование статических ключей, определенных заранее, что довольно неудобно и требует сложной системы управления ключами. Однако, при отказе от такой системы идентификация пакетов без установленного виртуального канала будет возможна лишь по сетевому адресу отправителя, который легкоподделать.
Посылка ложных управляющих сообщений может привести к серьезным нарушениям работы распределенной ВС (например, к изменению ее конфигурации).
Подмена доверенного объекта РВС является активным воздействием (класс 1.2), совершаемым с целью
нарушения конфиденциальности (класс 2.1) и целостности (класс 2.2) информации, по наступлению на атакуемом объекте определенного события (класс 3.2). Данная удаленная атака может являться как внутрисегментной (класс 5.1). так и межсегментной (класс 5.2). как с обратной связью (класс 4.1). так и без обратной связи (класс 4.2) с атакуемым объектом и осущест-вляется на сетевом (класс 6.3) и транспортном (класс 6.4) уровнях модели OSI.

Ложный объект распределенной ВС

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

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

Современные глобальные сети представляют собой совокупность сегментов сети, связанных между собой через сетевые узлы. При этом маршрутом называется последовательность узлов сети. по которой данные передаются от источника к приемнику. Каждый маршрутизатор имеет специальную таблицу, называемую таблицей маршрутизации, в которой для каждого адресата указывается оптимальный маршрут. Таблицы маршрутизации существуют не только у маршрутизаторов, но и у любых хостов в глобальной сети. Для обеспечения эффективной и оптимальной маршрутизации в распределенных ВС применяются специальные управляющие протоколы, позволяющие маршрутизаторам обмениваться информацией друг с другом (RIP (Routing Internet Protocol), OSPF (Open Shortest Path First), уведомлять хосты о новом маршруте - ICMP (Internet Control Message Protocol), удаленно управлять маршрутизаторами, SNMP (Simple Network Management Protocol). Важно отметить, что все описанные выше протоколы позволяют удаленно изменять маршрутизацию в сети Internet, то есть являются протоколами управления сетью.
Поэтому абсолютно очевидно, что маршрутизация в глобальных сетях играет важнейшую роль и, как следствие этого, может подвергаться атаке. Основная цель атаки, связанной с навязыванием ложного маршрута, состоит в том, чтобы изменить исходную маршрутизацию на объекте распределенной ВС так, чтобы новый маршрут проходил через ложный объект - хост атакующего.
Реализация данной типовой удаленной атаки состоит в несанкционированном использовании протоколов уп-равления сетью для изменения исходных таблиц маршрутизации.
Для изменения маршрутизации атакующему необходимо послать по сети определенные данными протоколами управления сетью специальные служебные сообщения от имени сетевых управляющих устройств (например, маршрутизаторов). В результате успешного изменения маршрута атакующий получит полный контроль над потоком информации, которой обмениваются два объекта распределенной ВС и атака перейдет во вторую стадию, связанную с приемом, анализом и передачей сообщений, получаемых от дезинформированных объектов РВС. .
Навязывание объекту РВС ложного маршрута - активное воздействие (класс 1.2), совершаемое с любой из целей из класса 2, безусловно по отношению к цели атаки (класс 3.3). Данная типовая удаленная атака может осуществляться как внутри одного сегмента (класс 5.1), так и межсегментно (класс 5.2), как с обратной связью (класс 4.1), так и без обратной связи с атакуемым объектом (класс 4.2) на транспортном (класс 6.3) и прикладном (класс 6.7) уровне модели OSI.
3.2.3.2. Внедрение в распределенную ВС ложного объекта путем использования недостатков алгоритмов удаленного поиска
В распределенной ВС часто оказывается, что ее удаленные объекты изначально не имеют достаточно информации, необходимой для адресации сообщений. Обычно такой информацией являются аппаратные (адрес сетевого адаптера) и логические (IP-адрес, например) адреса объектов РВС. Для получения подобной информации в распределенных ВС используются различные алгоритмы удаленного поиска, заключающиеся в передаче по сети специального вида поисковых запросов, и в ожидании ответов на запрос с искомой информацией. После получения ответа на запрос, запросивший субъект РВС обладает всеми необходимыми данными для адресации. Руководствуясь полученными из ответа сведениями об искомом объекте, запросивший субъект РВС начинает адресоваться к нему. Примером подобных запросов, на которых базируются алгоритмы удаленного поиска, могут служить SAP-запрос в ОС Novell NetWare, ARP- и DNS-запрос в сети Internet .
В случае использования распределенной ВС механизмов удаленного поиска существует возможность на атакующем объекте перехватить посланный запрос и послать на него ложный ответ, где указать данные, использование которых приведет к адресации на атакующий ложный объект. В дальнейшем весь поток информации между субъектом и объектом взаимодействия будет проходить через ложный объект РВС.
Другой вариант внедрения в РВС ложного объекта использует недостатки алгоритма удаленного поиска и состоит в периодической передаче на атакуемый объект заранее подготовленного ложного ответа без приема поисковою запроса. В самом деле. атакующему для того, чтобы послать ложный ответ, не всегда обязательно дожидаться приема запроса (он может, в принципе, не иметь подобной возможности перехвата запроса). При этом атакующий может спровоцировать атакуемый объект на передачу поискового запроса, и тогда его ложный ответ будет немедленно иметь успех. Данная типовая удаленная атака чрезвычайно характерна для глобальных сетей, когда у атакующего из-за нахождения его в другом сегменте относительно цели атаки просто нет возможности перехватить поисковый запрос.
Ложный объект РВС - активное воздействие (класс 1.2), совершаемое с целью нарушения конфиденциальности (класс 2.1) и целостности информации (класс 2.2), которое может являться атакой по запросу от атакуемого объекта (класс 3.1), а также безусловной атакой (класс 3.3). Данная удаленная атака является как внутрисегментной (класс 5.1). так и межсегментной (класс 5.2), имеет обратную связь с атакуемым объектом (класс 4.1) и осуществляется на канальном (класс 6.2) и прикладном (класс 6.7) уровнях модели OSI.

Использование ложного объекта для организации удаленной атаки на распределенную ВС

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

Селекция потока информации и сохранение ее на ложном объекте РВС

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

Модификация информации

Одной из особенностей любой системы воздействия. построенной по принципу ложного объекта, является то, что она способна модифицировать перехваченную информацию. Следует особо отметить, что это один из способов, позволяющих программно модифицировать поток информации между объектами РВС с другого объекта. Ведь для реализации перехвата информации в сети необязательно атаковать распределенную ВС по схеме "ложный объект". Эффективней будет атака, осуществляющая анализ сетевого трафика, позволяющая получать все пакеты, проходящие по каналу связи, но, в отличие от удаленной атаки по схеме "ложный объект", она не способна к модификации информации.
Рассмотрим два вида модификации информации:
- модификация передаваемых данных;
- модификация передаваемого кода.
Одной из функций, которой может обладать система воздействия, построенная по принципу "ложный объект", является модификация передаваемых данных. В результате селекции потока перехваченной информации и его анализа система может распознавать тип передаваемых файлов (исполняемый или текстовый). Соответственно, в случае обнаружения текстового файла или файла данных появляется возможность модифицировать проходящие через ложный объект данные. Особую угрозу эта функция представляет для сетей обработки конфиденциальной информации.
Другим видом модификации может быть модификация передаваемого кода. Ложный объект, проводя семантический анализ проходящей через него информации может выделять из потока данных исполняемый код. Известный принцип неймановской архитектуры гласит, что не существует различий между данными и командами. Следовательно, для того, чтобы определить. что передается по сети - код или данные, необходимо использовать определенные особенности, свойственные реализации сетевого обмена в конкретной распределенной ВС или некоторые особенности, присущие конкретным типам исполняемых файлов в данной локальной ОС.
Представляется возможным выделить два различных по цели вида модификации кода:
- внедрение РПС (разрушающих программных средств);
- изменение логики работы исполняемого файла.
В первом случае при внедрении РПС исполняемый файл модифицируется по вирусной технологии: к исполняемому файлу одним из известных способов дописывается тело РПС , а также одним из известных способов изменяется точка входа так, чтобы она указывала на начало внедренного кода РПС. Описанный способ, в принципе, ничем не отличается от стандартного заражения исполняемого файла вирусом, за исключением того, что файл оказался поражен вирусом или РПС в момент передачи его по сети! Такое возможно лишь при использова-нии системы воздействия, построенной по принципу "ложный объект". Конкретный вид РПС, его цели и задачи в данном случае не имеют значения, но можно рассмотреть, например, вариант использования ложного объекта для создания сетевого червя - наиболее сложного на практике удаленного воздействия в сетях, или в качестве РПС использовать сетевые шпионы.
Во втором случае происходит модификация исполняемого кода с целью изменения логики его работы. Данное воздействие требует предварительного исследования работы исполняемого файла и, в случае его проведения, может принести самые неожиданные результаты. Например, при запуске на сервере (например, в ОС Novell NetWare) программы идентификации пользователей распределенной базы данных ложный объект может так модифицировать код этой программы, что появится возможность беспарольного входа с наивысшими привилегиями в базу данных.

Подмена информации

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

Отказ в обслуживании

Одной из основных задач, возлагаемых на сетевую ОС, функционирующую на каждом из объектов распределенной ВС, является обеспечение надежного удаленного доступа с любого объекта сети к данному объекту. В общем случае в распределенной ВС каждый субъект системы должен иметь возможность подключиться к любому объекту РВС и получить в соответствии со своими правами удаленный доступ к его ресурсам. Обычно в вычислительных сетях возможность предос-авления удаленного доступа реализуется следующим образом: на объекте РВС в сетевой ОС запускаются на выполнение ряд программ-серверов (например, FTP-сервер, WWW-сервер и т.п.), предоставляющих удаленный доступ к ресурсам данного объекта. Данные программы-серверы входят в состав телекоммуникационных служб предоставления удаленного доступа. Задача сервера состоит в том, чтобы, находясь в памяти операционной системы объекта РВС, постоянно ожидать полу-чения запроса на подключение от удаленного объекта. В случае получения подобного запроса сервер должен по возможности передать на запросивший объект ответ, в котором либо разрешить подключение, либо нет (подключение к серверу специально описано очень схематично, так как подробности в данный момент не имеют значения). По аналогичной схеме происходит создание виртуального канала связи, по которому обычно взаимодействуют объекты РВС. В этом случае непосредственно ядро сетевой ОС обрабатывает приходящие извне запросы на создание виртуального канала (ВК) и передает их в соответствии с идентификатором запроса (порт или сокет) прикладному процессу, которым является соответствующий сервер.
Очевидно, что сетевая операционная система способна иметь только ограниченное число открытых виртуальных соединений и отвечать лишь на ограниченное число запросов. Эти ограничения зависят от различных параметров системы в целом, основными из которых являются быстродействие ЭВМ, объем оперативной памяти и пропускная способность канала связи (чем она выше, тем больше число возможных запросов в единицу времени).
Основная проблема состоит в том, что при отсутствии статической ключевой информации в РВС идентификация запроса возможна только по адресу его отправителя. Если в распределенной ВС не предусмотрено средств аутентификации адреса отправителя, то есть инфраструктура РВС позволяет с одного объекта системы передавать на другой атакуемый объект бесконечное число анонимных запросов на подключение от имени других объектов, то в этом случае будет иметь успех ти-повая удаленная атака "Отказ в обслуживании" . Результат применения этой удаленной атаки - нарушение на атакованном объекте работоспособности соответствующей службы предоставления удаленного доступа, то есть невозможность получения удаленного доступа с других объектов РВС - отказ в обслуживании!
Вторая разновидность этой типовой удаленной атаки состоит в передаче с одного адреса такого количества запросов на атакуемый объект, какое позволит трафик (направленный "шторм" запросов). В этом случае, если в системе не предусмотрены правила, ограничивающие число принимаемых запросов с одного объекта (адреса) в единицу времени, то результатом этой атаки может являться как переполнение очереди запросов и отказа одной из телекоммуникационных служб, так и полная остановка компьютера из-за невозможности системы заниматься ничем другим, кроме обработки запросов.
И последней, третьей разновидностью атаки "Отказ в обслуживании" является передача на атакуемый объект некорректного, специально подобранного запроса. В этом случае при наличии ошибок в удаленной системе возможно зацикливание процедуры обработки запроса, переполнение буфера с последующим зависанием системы .
Типовая удаленная атака "Отказ в обслуживании" является активным воздействием (класс 1.2), осуществляемым с целью нарушения работоспособности систе мы (класс 2.3), безусловно относительно цели атаки (класс 3.3). Данная УА является однонаправленным воздействием (класс 4.2), как межсегментным (класс 5.1), так и внутрисегментным (класс 5.2), осуществляемым на транспортном (класс 6.4) и прикладном (класс 6.7) уровнях модели OSI.

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

Анализ сетевого трафика сети Internet

В сети Internet основными базовыми протоколами удаленного доступа являются TELNET и FTP (File Transfer Protocol). TELNET - это протокол виртуального терминала (ВТ), позволяющий с удаленных хостов подключаться к серверам Internet в режиме ВТ. FTP - протокол, предназначенный для передачи файлов между удаленными хостами. Для получения доступа к серверу по данным протоколам пользователю необходимо пройти на нем процедуру идентификации и аутентификации. В качестве информации, идентифицирующей пользователя, выступает его идентификатор (имя), а для аутентификации используется пароль. Особенностью протоколов FTP и TELNET является то, что пароли и идентификаторы пользователей передаются по сети в открытом, незашифрованном виде. Таким образом, необходимым и достаточным условием для получения удаленного доступа к хостам по протоколам FTP и TELNET являются имя и пароль пользователя.
Одним из способов получения паролей и идентификаторов пользователей в сети Internet является анализ сетевого трафика. Сетевой анализ осуществляется с помощью специальной программы-анализатора пакетов, перехватывающей все пакеты, передаваемые по сегменту сети, и выделяющей среди них те, в которых передаются идентификатор пользователя и его пароль. Сетевой анализ протоколов FTP и TELNET показывает, что TELNET разбивает пароль на символы и пересылает их по одному, помещая каждый символ из пароля в соответствующий пакет, a FTP. напротив, пересылает пароль целиком в одном пакете.

Возникает вопрос, почему разработчики базовых прикладных протоколов Internet не предусмотрели возможностей шифрования передаваемых по сети паролей пользователей. Даже во всеми критикуемой сетевой ОС Novell NetWare 3.12 пароли пользователей никогда не передаются в открытом виде по сети (правда, этой ОС это особенно не помогает). Видимо, проблема в том, что базовые прикладные протоколы семейства TCP/IP разрабатывались очень давно - в период с конца 60-х до начала 80-х и с тех пор абсолютно не изменились. При этом точка зрения на построение глобальных сетей стала иной. Инфраструктура сети Internet и ее протоколы разрабатывались в основном из соображений надежности связи и уж никак не из соображений безопасности. Мы - пользователи сети Internet - сейчас пожинаем плоды, оставленные нам разработчиками этой морально устаревшей с точки зрения безопасности глобальной сети. Совершенно очевидно, что вычислительные системы за эти годы сделали колоссальный скачок в своем развитии. Поэтому, конечно, за эти годы подход к обеспечению информационной безопасности распределенных ВС существенно изменился. Были разработаны различные протоколы обмена, позволяющие защитить сетевое соединение и зашифровать трафик (например, протоколы SSL, SKIP и т. п.). Однако эти протоколы не сменили устаревшие и не стали стандартом для каждого пользователя (может быть, за исключением SSL). Вся проблема состоит в том, что для того, чтобы они стали стандартом, на эти протоколы должны перейти все пользователи сети, но, так как в Internet отсутствует централизованное управление сетью, то процесс перехода на эти протоколы может длиться еще многие годы. А на сегодняшний день подавляющее большинство пользователей используют стандартные протоколы семейства TCP/IP, разработанные более 15 лет назад. В результате, как показывают сообщения американских центров по компьютерной безопасности (CERT, CIAC), анализ сетевого трафика в сети Internet успешно применялся кракерами в последние годы, и, согласно материалам специального комитета при конгрессе США, с его помощью в 1993-1994 годах было перехвачено около миллиона паролей для доступа в различные информационные системы.

Ложный ARP-сервер в сети Internet

Как уже неоднократно подчеркивалось, в вычислительных сетях связь между двумя удаленными хостами осуществляется путем передачи по сети сообщений, которые заключены в пакеты обмена. В общем случае передаваемый по сети пакет независимо от используемого протокола и типа сети (Token Ring, Ethernet, X.25 и др.) состоит из заголовка пакета и поля данных. В заголовок пакета обычно заносится служебная информация, определяемая используемым протоколом обмена и необходимая для адресации пакета, его идентификации, преобразования и т. д. В поле данных помещаются либо непосредственно данные, либо другой пакет более высокого уровня OSI. Так, например, пакет транспортного уровня может быть вложен в пакет сетевого уровня, который, в свою очередь, вложен в пакет канального уровня. Спрое-цировав это утверждение на сетевую ОС, использующую протоколы TCP/IP, можно утверждать, что пакет TCP (транспортный уровень) вложен в пакет IP (сетевой уро-вень), который, в свою очередь, вложен в пакет Ethernet (канальный уровень).
Рассмотрим схему адресации пакетов в сети Internet и возникающие при этом проблемы безопасности. Как известно, базовым сетевым протоколом обмена в сети Internet является протокол IP (Internet Protocol). Протокол IP - это межсетевой протокол, позволяющий передавать IP-пакеты в любую точку глобальной сети. Для адресации на сетевом уровне (IP-уровне) в сети Internet каждый хост имеет уникальный 32-разрядный IP-адрес. Для передачи IP-пакета на хост необходимо указать в IP-заголовке пакета в поле Destination Address IP-адрес данного хоста. Однако, IP-пакет находится внутри аппаратного пакета (в случае среды передачи Ethernet IP пакет находится внутри Ethernet-пакета), поэтому каждый пакет в сетях любого типа и с любыми протоколами обмена в конечном счете адресуется на аппаратный адрес сетевого адаптера, непосредственно осуществляющего прием и передачу пакетов в сеть (в дальнейшем мы будем рассматривать только Ethernet-сети).
Из всего вышесказанного видно, что для адресации IP-пакетов в сети Internet кроме IP-адреса хоста необходим еще либо Ethernet-адрес его сетевого адаптера (в случае адресации внутри одной подсети), либо Ethernet-адрес маршрутизатора (в случае межсетевой адресации). Первоначально хост может не иметь ин-формации о Ethernet-адресах других хостов, находящихся с ним в одном сегменте, в том числе и о Ethernet-адресе маршрутизатора. Следовательно, перед хостом встает стандартная проблема, решаемая с помощью алгоритма удаленного поиска. В сети Internet для решения этой проблемы используется протокол ARP (Address Resolution Protocol). Протокол ARP позволяет получить взаимно однозначное соответствие IP и Ethernet-адресов для хостов, находящихся внутри одного сегмента. Это достигается следующим образом: при первом обращении к сетевым ресурсам хост отправляет широковещательный ARP-запрос на Ethernet-адрес FFFFFFFFFFFFh, в котором указывает IP-адрес мар-шрутизатора и просит сообщить его Ethernet-адрес (IP-адрес маршрутизатора является обязательным параметром, который всегда устанавливается вручную при настройке любой сетевой ОС в сети Internet). Этот ши-роковещательный запрос получат все станции в данном сегменте сети, в том числе и маршрутизатор. Получив данный запрос, маршрутизатор внесет запись о запросившем хосте в свою ARP-таблицу, а затем отправит на запросивший хост ARP-ответ, в котором сообщит свой Ethernet-адрес. Полученный в ARP-ответе Ethernet-адрес будет занесен в ARP-таблицу, находящуюся в памяти операционной системы на запросившем хосте и содержащую записи соответствия IP и Ethernet-адресов для хостов внутри одного сегмента.В случае адресации к хосту, расположенному в той же подсети, также используется ARP-протокол и рассмотренная выше схема полностью повторяется.
В случае использования в распределенной ВС алгоритмов удаленного поиска существует возможность осуществления в такой сети типовой удаленной атаки "Ложный объект РВС". Из анализа безопасности протокола ARP становится ясно, что, перехватив на атакующем хосте внутри данного сегмента сети широковещательный ARP-запрос, можно послать ложный ARP-ответ. в котором объявить себя искомым хостом (например, маршрутизатором), и в дальнейшем активно контролировать и воздействовать на сетевой трафик "обманутого" хоста по схеме "Ложный объект РВС".

Рассмотрим обобщенную функциональную схему ложного ARP-сервера:
- ожидание ARP-запроса;
При получении ARP-запроса передача по сети на запросивший хост ложного ARP-ответа, в котором указывается адрес сетевого адаптера атакующей станции (ложного ARP-сервера) или тот Ethernet-адрес, на котором будет принимать пакеты ложный ARP-сервер (совершенно необязательно указывать в ложном ARP-ответе свой настоящий Ethernet-адрес, так как при работе непосредственно с сетевым адаптером его можно запрограммировать на прием пакетов на любой Ethernet-адрес);
- прием, анализ, воздействие и передача пакетов обмена между взаимодействующими хостами.
Данная схема атаки требует некоторого уточнения. Зачастую даже очень квалифицированные сетевые администраторы и программисты не знают либо не понимают тонкостей работы протокола ARP. Это, наверное, связано с тем, что при обычной настройке сетевой ОС, поддерживающей протоколы TCP/IP, не требуется настройка модуля ARP (крайне редко встречаются сетевые ОС, где обязательно требовалось бы создание "вручную" ARP-таблицы). Поэтому протокол ARP остается как бы "прозрачным" для администраторов. Далее, необходимо обратить внимание на тот факт, что у маршрутизатора тоже имеется ARP-таблица, в которой содержится информация об IP и соответствующих им Ethernet-адресах всех хостов из сегмента сети, подключенного к маршрутизатору. Информация в эту ARP-таблицу на маршрутизаторе также обычно заносится не вручную, а при помощи протокола ARP. Именно поэтому так легко в одном сегменте IP-сети присвоить чужой IP-адрес: выдать команду сетевой ОС на установку нового IP-адреса, потом обратиться в сеть - сразу же будет послан широковещательный ARP-запрос, и маршрутизатор, получив этот запрос, автоматически обновит запись в своей ARP-таблице (поставит в соответствии с чужим IP-адресом Ehternet-адрес вашей сетевой карты), в результате чего обладатель данного IP-адреса потеряет связь с внешним миром (все пакеты, адресуемые на его бывший IP-адрес и приходящие на маршрутизатор, будут направляться маршрутизатором на Ethernet-адрес атакующего). Правда, некоторые ОС анализируют все передаваемые по сети широковещательные ARP-запросы. Например, ОС Windows '95 или SunOS 5.3 при получении ARP-запроса с указанным в нем IP-адресом, совпадающим с IP-адресом данной системы, выдают предупреждающее сообщение о том, что хост с таким-то Ethernet-адресом пытается присвоить себе (естественно, успешно) данный IP-адрес.

Теперь вернемся непосредственно к описанной ранее схеме атаки "ложный ARP-сервер". Из анализа механизмов адресации, описанных выше, становится ясно, что так как поисковый ARP-запрос кроме атакующего получит и маршрутизатор, то в его таблице окажется соответствующая запись об IP- и Ethernet-адресе атакуемого хоста. Следовательно, когда на маршрутизатор придет пакет, направленный на IP-адрес атакуемого хоста, то он будет передан не на ложный ARP-сервер, а непосредственно на хост. При этом схема передачи пакетов в этом случае будет следующая:
- атакованный хост передает пакеты на ложный ARP-сервер;
- ложный ARP-сервер передает принятый от атакованного хоста пакет на маршрутизатор;
- маршрутизатор, в случае получения ответа на переданный запрос, передает его непосредственно на атакованный хост, минуя ложный ARP-сервер.
В этом случае последняя фаза, связанная с "приемом, анализом, воздействием и передачей пакетов обмена" между атакованным хостом и, например, маршрутизатором (или любым другим хостом в том же сегменте) будет проходить уже не в режиме полного перехвата пакетов ложным сервером (мостовая схема), а режиме "полу перехвата" (петлевая схема). Действительно, в режиме полного перехвата маршрут всех пакетов, отправляемых как в одну, так и в другую стороны, обязательно проходит через ложный сервер-мост; а в режиме "полуперехвата" маршрут пакетов образует петлю. Необходимо обратить внимание на эту петлевую схему перехвата информации ложным сервером, так как в дальнейшем будут рассмотрены еще два варианта атаки на базе протоколов DNS и ICMP, результат которых - перехват информации по схеме "Ложный объект РВС", и там также может возникнуть петлевой маршрут.

Тем не менее довольно несложно придумать несколько способов, позволяющих функционировать ложному ARP-серверу по мостовой схеме перехвата (полный перехват). Например, можно, получив ARP-запрос, самому послать такой же запрос и присвоить себе данный IP-адрес (правда, в этом случае ложному ARP-серверу не удастся остаться незамеченным, так некоторые сетевые ОС (например Windows '95 и SunOS 5.3), как отмечалось ранее, перехватив этот запрос, выдадут предупреждение об использовании их IP-адреса). Другой, значительно более предпочтительный способ: послать ARP-запрос, указав в качестве своего IP-адреса любой свободный в данном сегменте IP-адрес, и в дальнейшем вести работу с данного IP-адреса как с маршрутизатором, так и с "обманутыми" хостами (кстати, это типичная proxy-схема).

В заключении рассказа об уязвимостях протокола ARP необходимо показать, как различные сетевые ОС используют этот протокол для изменения информации в своих ARP-таблицах. При исследовании различных сетевых ОС выяснилось, что в ОС Linux 1.2.8 при адресации к хосту, находящемуся в одной подсети с данным хостом, при отсутствии в ARP-таблице соответствующей записи о Ethernet-адресе передается ARP-запрос и при последующих обращениях к данному хосту посылки ARP-запроса не происходит. В SunOS 5.3, при каждом новом обращении к хосту происходит передача ARP-запроса и, следовательно, ARP-таблица динамически обновляется. ОС Windows '95 при обращении к хостам, с точки зрения использования протокола ARP, ведет себя так же, как и ОС Linux, за исключением того, что эта операционная система периодически (каждую минуту) посылает ARP-запрос о Ethernet-адресе маршрутизатора (видимо, программисты фирмы Microsoft считали, что маршрутизатор может постоянно менять свой Ethernet-адрес?!), и в результате в течение нескольких минут вся локальная сеть с Windows '95 с легкостью поражается с помощью ложного ARP-сервера. Что касается Windows NT 4.0. то эксперименты показали, что там также используется динамически изменяемая ARP-таблица и ARP-запросы о Ethernet-адресе маршрутизатора передаются с периодичностью около 10 минут.
Особый интерес вызвал следующий вопрос: а удастся ли осуществить данную удаленную атаку на UNIX-совместимую ОС, защищенную по классу В1 (мандатная и дискретная сетевая политики разграничения доступа плюс специальная схема функционирования SUID/SGID процессов), установленную на двухпроцессорной мини-ЭВМ. Эта система является одним из лучших в мире полнофункциональных файрволов. Так вот, в процессе анализа защищенности этого файрвола относительно удаленных воздействий, осуществляемых по каналам связи, при его тестировании выяснилось, что в случае базовой (после всех стандартных настроек) конфигурации ОС эта защищенная UNIX-система также поражается ложным ARP-сервером.
Причина успеха данной удаленной атаки кроется, не столько в Internet, сколько в широковещательной среде Ethernet и, очевидно, что эта удаленная атака является внутрисегментной и поэтому представляет для вас угрозу только в случае нахождения атакующего внутри вашего сегмента сети. Однако, как известно из статистики нарушений информационной безопасности вычислительных сетей, большинство состоявшихся взломов сетей производилось изнутри собственными сотрудникам. Причины этого понятны. Как подчеркивалось ранее, осуществить внутрисегментную удаленную атаку значительно легче, чем межсегментную. Кроме того, практически все организации имеют локальные сети (в том числе и IP-сети), хотя далеко не у всех локальные сети подключены к глобальной сети Internet. Это объясняется как соображениями безопасности, так и необходимости такого подключения для организации. И, наконец, сотрудникам самой организации, знающим тонкости своей внутренней вычислительной сети, гораздо легче осуществить взлом, чем кому бы то ни бы-ло. Поэтому администраторам безопасности нельзя недооценивать данную удаленную атаку, даже если ее источник находится внутри их локальной IP-сети.

Ложный DNS-сервер в сети Internet

Как известно, для обращения к хостам в сети Internet используются 32-разрядные IP-адреса, уникально идентифицирующие каждый сетевой компьютер в этой глобальной сети. Однако, для пользователей применение IP-адресов при обращении к хостам является не слишком удобным и далеко не самым наглядным.
В самом начале зарождения Internet для удобства пользователей было принято решение присвоить всем компьютерам в сети имена. Использование имен позволяет пользователю лучше ориентироваться в киберпространстве сети Internet - куда проще, понятней и наглядней для пользователя запомнить, например, имя www.ferrari.it, чем четырехразрядную цепочку IP-адреса. Использование в Internet мнемонически понят-ных для пользователей имен породило проблему преобразования имен в IP-адреса. Такое преобразование необходимо, так как на сетевом уровне адресация пакетов идет не по именам, а по IP-адресам, следовательно, для непосредственной адресации сообщений в Internet имена не годятся. На этапе раннего развития Internet, когда в сеть было объединено небольшое количество компьютеров, NIC (Network Information Center) для решения проблемы преобразования имен в адреса создал специальный файл (hosts file), в который вносились имена и соответствующие им IP-адреса всех хостов в сети. Данный файл регулярно обновлялся и распространялся по всей сети. Но, по мере развития Internet, число объединенных в сеть хостов увеличивалось, и данная схема становилась все менее и менее работоспособной, поэтому была создана новая система преобразования имен, позволяющая пользователю в случае отсутствия у него информации о соответствии имен и IP-адресов получить необходимые сведения от ближайшего информационно-поискового сервера (DNS-сервера). Эта система получила название доменной системы имен - DNS (Domain Name System).
Для реализации системы DNS был создан специальный сетевой протокол DNS, для обеспечения эффективной работы которого в сети создаются специальные выделенные информационно-поисковые серверы - DNS-серверы. Поясним основную задачу, решаемую службой DNS. В современной сети Internet хост при обращении к удаленному серверу обычно имеет информацию только о его имени и не знает его IP-адреса, который и необходим для непосредственной адресации. Следовательно, перед хостом возникает стандартная проблема удаленного по-иска: по имени удаленного хоста найти его IP-адрес. Ре-шением этой проблемы и занимается служба DNS на базе протокола DNS.
Рассмотрим DNS-алгоритм удаленного поиска IP-адреса по имени в сети Internet:
- хост посылает на IP-адрес ближайшего DNS-сервера (он устанавливается при настройке сетевой ОС) DNS-запрос, в котором указывает имя серве-ра, IP-адрес которого необходимо найти:
- DNS-сервер, получив запрос, просматривает свою базу имен на наличие в ней указанного в запросе имени. В случае, если имя найдено, а, следовательно, найден и соответствующий ему IP-адрес, то на запросивший хост DNS-сервер отправляет DNS-ответ, в котором указывает искомый IP-адрес. В случае, если указанное в запросе имя DNS-сервер не обнаружил в своей базе имен, то DNS-запрос отсылается DNS-сервером на один из корневых DNS-серверов, адреса которых содержатся в файле настроек DNS-сервера root.cache, и описанная в этом пункте процедура повторяется, пока имя не будет найдено (или не найдено).
Анализируя с точки зрения безопасности уязвимость этой схемы удаленного поиска с помощью протокола DNS, можно сделать вывод о возможности осуществления в сети, использующей протокол DNS, типовой удаленной атаки "Ложный объект РВС". Практические изыскания и критический анализ безопасности службы 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-запроса .
Для реализации атаки путем перехвата DNS-запроса атакующему необходимо перехватить DNS-запрос, извлечь из него номер UDP-порта отправителя запроса, двухбайтовое значение ID идентификатора DNS-запроса и искомое имя и затем послать ложный DNS-ответ на извлеченный из DNS-запроса UDP-порт, в котором указать в качестве искомого IP-адреса настоящий IP-адрес ложного DNS-сервера. Это позволит в дальнейшем полностью перехватить трафик между атакуемым хостом и сервером и активно воздействовать на него по схеме "Ложный объект РВС" .
Рассмотрим обобщенную схему работы ложного DNS-сервера:
- ожидание DNS-запроса;
- извлечение из полученного запроса необходимых сведений и передача по сети на запросивший хост ложного DNS-ответа, от имени (с IP-адреса) настоящего DNS-сервера, в котором указывается IP-адрес ложного DNS-сервера;
- в случае получения пакета от хоста, изменение в IP-заголовке пакета его IP-адреса на IP-адрес ложного DNS-сервера и передача пакета на сервер (то есть ложный DNS-сервер ведет работу с сервером от своего имени);
- в случае получения пакета от сервера, изменение в IP-заголовке пакета его IP-адреса на IP-адрес ложного DNS-сервера и передача пакета на хост (для хоста ложный DNS-сервер и есть настоящий сер-вер).
Необходимым условием осуществления данного варианта атаки является перехват DNS-запроса. Это возможно только в том случае, если атакующий находится либо на пути основного трафика, либо в сегменте настоящего DNS-сервера. Выполнение одного из этих условий местонахождения атакующего в сети делает подобную удаленную атаку трудно осуществимой на практике (попасть в сегмент DNS-сервера и, тем более, в межсегментный канал связи атакующему, скорее всего, не удастся). Однако в случае выполнения этих условий возможно осуществить межсегментную удаленную атаку на сеть Internet.
Практическая реализация данной удаленной атаки выявила ряд интересных особенностей в работе протокола FTP и в механизме идентификации TCP-пакетов. В случае, когда FTP-клиент на хосте подключался к удаленному FTP-серверу через ложный DNS-сервер, оказывалось, что каждый раз после выдачи пользователем прикладной команды FTP (например: Is, 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 ложного сервера путем создания направленного "шторма" ложных DNS-ответов на атакуемый хост

Другой вариант осуществления удаленной атаки, направленной на службу DNS, основан на второй разновидности типовой УА "Ложный объект РВС" (при использовании недостатков алгоритмов удаленного поиска). В этом случае атакующий осуществляет постоянную передачу на атакуемый хост заранее подготовленного ложного DNS-ответа от имени настоящего DNS-сервера без приема DNS-3anpoca. Другими словами, атакующий создает в сети 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).
Поэтому для осуществления данной удаленной атаки атакующему необходимо выбрать интересующий его хост (например. 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, воздействуя на перехваченную информацию по схеме "Ложный объект РВС".

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

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

В том случае, если указанное в запросе имя DNS-сервер не обнаружил в своей базе имен, то запрос отсылается сервером на один из корневых DNS-серверов, адреса которых содержатся в файле настроек сервера root.cache.
Итак, в случае, если DNS-сервер не имеет сведений о запрашиваемом хосте, то он сам, пересылая запрос далее, является инициатором удаленного DNSпоиска. Поэтому ничто не мешает атакующему перенести свой удар непосредственно на DNS-сервер. В качестве цели атаки теперь будет выступать не хост, а DNS-сервер и ложные DNS-ответы будут направляться атакующим от имени корневого DNS-сервера на атакуемый DNS-сервер.
При этом важно учитывать следующую особенность работы DNS-сервера. Для ускорения работы каждый DNS-сервер кэширует в области памяти свою таблицу соответствия имен и IP-адресов хостов. В том числе в кэш заносится динамически изменяемая информация об именах и IP-адресах хостов, найденных в процессе функционирования DNS-сервера, а именно, если DNS-сервер, получив запрос, не находит у себя в кэш-таблице соответствующей записи, он пересылает ответ на следующий сервер и, получив ответ, заносит найденные сведения в кэштаблицу в память. Таким образом, при получении следующего запроса DNS-серверу уже не требуется вести удаленный поиск, так как необходимые сведения уже находятся у него в кэш-таблице.
Из анализа только что подробно описанной схемы удаленного DNS-поиска становится очевидно, что в том случае, если в ответ на запрос от DNS-сервера атакующий направит ложный DNS-ответ (или в случае "шторма" ложных ответов будет вести их постоянную передачу), то в кэш-таблице сервера появится соответствующая запись с ложными сведениями и в дальнейшем все хосты, обратившиеся к данному DNS-серверу, будут дезинформированы, и при обращении к хосту, маршрут к которому атакующий решил изменить, связь с ним будет осуществляться через хост атакующего по схеме "Ложный объект РВС"! И, что хуже всего, с течением времени эта ложная информация, попавшая в кэш DNS-сервера будет распространяться на соседние DNS-серверы высших уровней, а, следовательно, все больше хостов в Internet будут дезинформированы и атакованы!
Очевидно, что в том случае, если атакующий не может перехватить DNS-запрос от DNS-сервера, то для реализации атаки ему необходим "шторм" ложных Dns-ответов, направленный на DNS-сервер. При этом возникает следующая проблема, отличная от проблемы под-бора портов в случае атаки, направленной на хост. Как уже отмечалось ранее, DNS-сервер, посылая запрос на другой DNS-сервер, идентифицирует этот запрос двухбайтовым значением (ID). Это значение увеличивается на единицу с каждым передаваемым запросом. Узнать атакующему это текущее значение идентификатора DNS-запроса не представляется возможным. Поэтому предложить что-либо, кроме перебора 216 возможных значений ID, достаточно сложно. Зато исчезает проблема перебора портов, так как все DNS-запросы передаются DNS-сервером на 53 порт.
Следующая проблема, являющаяся условием осуществления этой удаленной атаки на DNS-сервер при направленном "шторме" ложных DNS-ответов, состоит в том, что атака будет иметь успех только в случае, если DNS-сервер пошлет запрос на поиск имени, которое содержится в ложном DNS-ответе. DNS-сервер посылает этот столь необходимый и желанный для атакующего запрос в том и только том случае, когда на него приходит DNS-запрос от какого-либо хоста на поиск данного имени и этого имени не оказывается в кэш-таблице DNS-сервера. В принципе, этот запрос может возникнуть когда угодно, и атакующему придется ждать результатов атаки неопределенное время. Однако, ничто не мешает атакующему, не дожидаясь никого, самому послать на атакуемый DNS-сервер подобный DNS-запрос и спровоцировать DNS-сервер на поиск указанного в запросе имени! Тогда эта атака с большой вероятностью будет иметь успех практически сразу же после начала ее осуществления!
Для примера вспомним недавний скандал (28 октября 1996 года) с одним из московских провайдеров Internet - компанией РОСНЕТ, когда пользователи данного провайдера при обращении к обычному информационному WWW-серверу попадали, как было сказано в телевизионном репортаже, WWW-сервер "сомнительного" содержания (наверное www.playboy.com). В связи с абсолютным непониманием случившегося как журналистами (их можно понять - они не специалисты в этом вопросе), так и теми, кто проводил пресс-конференцию (специалистов к общению с прессой, наверное, просто не допустили) информационные сообщения о данном событии были настолько убоги, что понять, что случилось, было толком невозможно. Тем не менее, этот инцидент вполне укладывается в только что описанную схему удаленной атаки на DNS-сервер. С одним исключением: вместо адреса хоста атакующего в кэш-таблицу DNS-сервера был занесен IP-адрес хоста www.playboy.com.
Однако, видимо, большинство российских кракеров еще не доросли до столь утонченных методов сетевого взлома, как атака на DNS или любая другая атака из данной главы.Из интервью, которое якобы дал кракер, осуществивший этот взлом следовало, что атака использовала одну из известных "дыр" в WWW-сервере РОСНЕТа. Это и позволило атакующему подменить одну ссылку на другую. Осуществление атак такого типа является по сути тривиальным и не требует от взломщика практически никакой квалификации (именно осуществление; совершенно другое дело - нахождение этой "дыры"). Высокая квалификация необходима именно для поиска той самой уязвимости, используя которую можно взломать систему. Но,по всей видимости, обнаруживший уязвимость и осуществивший на ее базе взлом, скорее всего будут разными лицами, так как именно высокая квалификация специалиста, обнаружившего "дыру", не позволит ему причинить ущерб простым пользователям. (Р. Т. Моррис не был исключением. Просто его червь из-за ошибки в коде вышел из-под контроля, и поэтому пользователям сети был нанесен определенный ущерб ).
В завершение хотелось бы снова вернуться к службе DNS и сказать, что, как следует из предыдущих пунктов, использование в сети Internet службы удаленного поиска DNS позволяет атакующему организовать в Internet удаленную атаку на любой хост, пользующийся услугами данной службы, и может пробить серьезную брешь в эезопасности этой и так отнюдь не безопасной глобальной сети. Напомню, что, так указывал S. M. Bellovin в ставшей почти классической работе: "A combined attack on the domain system and the routing mechanisms can be catastrophic" ("Комбинация атаки на доменную систему и механизмы маршрутизации может привести к катастрофе").

Навязывание хосту ложного маршрута с использованием протокола ICMP с целью создания в сети Internet ложного маршрутизатора

Маршрутизация в сети Internet играет важнейшую роль для обеспечения нормального функционирования сети. Маршрутизация в Internet осуществляется на сетевом уровне (IP-уровень). Для ее обеспечения в памяти сетевой ОС каждого хоста существуют таблицы маршрутизации, содержащие данные о возможных маршрутах. Каждый сегмент сети подключен к глобальной сети Internet как минимум через один маршрутизатор, а, следовательно, все хосты в этом сегменте и маршрутизатор должны физически располагаться в одном сегменте. Поэтому все сообщения, адресованные в другие сегменты сети, направляются на маршрутизатор, который, в свою очередь, перенаправляет их далее по указанному в пакете IP-адресу, выбирая при этом оптимальный маршрут.В сети Internet для выбора оптимального маршрута используются специальные протоколы маршрутизации: RIP, OSPF и т. д.
Что же представляет из себя таблица маршрутизации хоста. В каждой строке этой таблицы содержится описание соответствующего маршрута. Это описание включает: IP-адрес конечной точки маршрута (Destination), IP-адрес соответствующего маршрутизатора (Gateway), а также ряд других параметров, характеризующих этот маршрут. Обычно в системе существует так называемый маршрут по умолчанию (поле Destination содержит значение 0.0.0.0, то есть default, а поле Gateway - IP-адрес маршрутизатора). Этот маршрут означает, что все пакеты, адресуемые на IP-адрес вне пределов данной подсети, будут направляться по указанному default-маршруту, то есть на маршрутизатор (это реализуется установкой в поле адреса назначения в Ethernet-пакете аппаратного адреса маршрутизатора).
В сети Internet существует управляющий протокол ICMP, одной из функций которого является удаленное управление маршрутизацией на хостах внутри сегмента сети. Удаленное управление маршрутизацией необходимо для предотвращения воз-можной передачи сообщений по неоптимальному маршруту. В сети Internet удаленное управление маршрутизацией реализовано в виде передачи с маршрутизатора на хост управляющего ICMP-сообщения: Redirect Message. Исследование протокола ICMP показало, что сообщение Redirect бывает двух типов. Первый тип сообщения носит название Redirect Net и уведомляет хост о необходимости смены адреса маршрутизатора, то есть default-маршрута. Второй тип - Redirect Host - ин-формирует хост о необходимости создания нового маршрута к указанной в сообщении системе и внесения ее в таблицу маршрутизации. Для этого в сообщении указывается IP-адрес хоста, для которого необходима смена маршрута (адрес будет занесен в поле Destination), и новый IP-адрес маршрутизатора, на который необходимо направлять пакеты, адресованные данному хосту (этот адрес заносится в поле Gateway). Необходимо обратить внимание на важное ограничение, накладываемое на IP-адрес нового маршрутизатора: он должен быть в пределах адресов данной подсети!
Анализ исходных текстов ОС Linux 1.2.8 показал, что ICMP-сообщение Redirect Net игнорируется данной ОС (это представляется логичным, так как динамическая смена маршрутизатора в процессе работы системы вряд ли необходима. Видимо, можно сделать вывод, что это сообщение игнорируют и другие сетевые ОС). Что касается управляющего сообщения ICMP Redirect Host, то единственным идентифицирующим его параметром является IP-адрес отправителя, который должен совпадать с IP-адресом маршрутизатора, так как это сообщение может передаваться только маршрутизатором. Особенность протокола ICMP состоит в том, что он не предусматривает никакой дополнительной аутентификации источников сообщений и при этом реализован на базе протокола UDP. Таким образом, ICMP-сообщения передаются на хост маршрутизатором од-нонаправлено, без создания виртуального соединения. Следовательно, ничто не мешает атакующему послать ложное ICMP-сообщение о смене маршрута от имени маршрутизатора.
Приведенные выше факты позволяют осуществить типовую удаленную атаку "Внедрение в распределенную ВС ложного объекта путем навязывания ложного мар-шрута".
Для осуществления этой удаленной атаки необходимо подготовить ложное ICMP Redirect Host сообщение, в котором указать конечный IP-адрес маршрута (адрес хоста, маршрут к которому будет изменен) и IP-адрес ложного маршрутизатора. Далее это сообщение передается на атакуемый хост от имени маршрутизатора. Для этого в IP-заголовке в поле адреса отправителя указывается IP-адрес маршрутизатора. В принципе, можно предложить два варианта данной удаленной атаки.
В первом случае атакующий находится в том же сегменте сети, что и цель атаки. Тогда, послав ложное ICMP-сообщение, он в качестве IP-адреса нового маршрутизатора может указать либо свой IP-адрес, либо любой из адресов данной подсети. Это даст атакующему возможность изменить маршрут передачи сообщений, направляемых атакованным хостом на определенный IP-адрес, и получить контроль над трафиков между атакуемым хостом и интересующим атакующего сервером. После этого атака перейдет во вторую стадию, связанную с приемом, анализом и передачей пакетов, получаемых от "обманутого" хоста. Рассмотрим функциональную схему осуществления этой удаленной атаки:
- передача на атакуемый хост ложного ICMP Redirect Host сообщения;
- отправление ARP-ответа в случае, если пришел ARP-запрос от атакуемого хоста;
- перенаправление пакетов от атакуемого хоста на настоящий маршрутизатор;
- перенаправление пакетов от маршрутизатора на атакуемый хост;
- при приеме пакета возможно воздействие на ин-формацию по схеме "Ложный объект РВС".
В случае осуществления второго варианта удаленной атаки атакующий находится в другом сегменте относительно цели атаки. Тогда, в случае передачи на атакуемый хост ложного ICMP Redirect сообщения, сам атакующий уже не сможет получить контроль над графиком, так как адрес нового маршрутизатора должен на-ходиться в пределах подсети атакуемого хоста (см. описанную выше в этом пункте реакцию сетевой ОС на ICMP Redirect сообщение), поэтому использование данного варианта этой удаленной атаки не позволит атакующему получить доступ к передаваемой по каналу связи информации. Однако, в этом случае атака достигает другой цели: нарушается работоспособность хоста. Атакующий с любого хоста в Internet может послать подобное сообщение на атакуемый хост и в случае, если сетевая ОС на данном хосте не проигнорирует данное собщение, то связь между данным хостом и указанным в ложном ICMP-сообщении сервером будет нарушена. Это произойдет из-за того, что все пакеты, направляемые хостом на этот сервер, будут отправлены на IP-адрес несуществующего маршрутизатора.Эксперимент показал, что оба варианта рассмотренной удаленной атаки удается осуществить (как межсегментно, так и внутрисегментно) на ОС Linux 1.2.8, ОС Windows '95 и ОС Windows NT 4.0. Остальные сетевые ОС, (Linux 2.0.0 и защищенный по классу Bl UNIX), игноруют данное ICMP Redirect сообщение (что, не правда ли, кажется вполне логичным с точки зрения обеспечения безопасности!).

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

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

Предположим, что хосту А необходимо создать TCP-соединение с хостом В. Тогда А посылает на В следующее сообщение:
1. А -> В: SYN, ISSa
Это означает, что в передаваемом А сообщении установлен бит SYN (synchronize sequence number), а в поле Sequence Number установлено начальное 32-битное значение ISSa (Initial Sequence Number).
В отвечает:
2. В -> A: SYN, ACK, ISSb, ACK(ISSa+1)
В ответ на полученный от А запрос В отвечает сообщением, в котором установлен бит SYN и установлен бит ACK; в поле Sequence Number хостом В устанавливается свое начальное значение счетчика - ISSb; поле Acknowledgment Number содержит значение ISSa, полученное в первом пакете от хоста А и увеличенное на единицу.
А, завершая рукопожатие (handshake), посылает:
3. А -> В: ACK, ISSa+1, ACK(ISSb+l)
В этом пакете установлен бит ACK; поле Sequence Number содержит ISSa + 1; поле Acknowledgment Num-ber содержит значение ISSb + 1. Посылкой этого пакета на хост В заканчивается трехступенчатый handshake, и TCP-соединение между хостами А и В считается установленным.
Теперь хост А может посылать пакеты с данными на хост В по только что созданному виртуальному ТСР-каналу:
4. А -> В: ACK, ISSa+1, ACK(ISSb+l); 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 не является тривиальной. Далее предлагается следующее решение данной проблемы.

Математическое предсказание начального значения идентификатора TCP-соединения экстраполяцией его предыдущих значений

Первый вопрос, который возникает в данном случае:
как сетевая операционная система формирует начальное значение ISSa (так называемый ISN - Initial Sequence Number?). Очевидно, что наилучшим решением с точки зрения безопасности будет генерация этого значения ISN по случайному закону с использованием программного (а лучше аппаратною) генератора псевдослучайных чисел с достаточно большим периодом. В этом случае каждое новое значение ISN не будет зависеть от его предыдущего значения, а, следовательно, у атакующего не будет даже теоретической возможности нахождения функционального закона получения ISN.
Однако оказывается, что подобные очевидные правила случайной генерации ISN как для составителей самого описания протокола TCP (RFC 793), так и для разработчиков сетевого ядра различных операционных систем являются далеко не очевидными. Об этом говорят следующие факты. В описании протокола TCP в RFC 793 рекомендуется увеличивать значение этого 32-битного счетчика на 1 каждые 4 микросекунды (?!).А как дело обстоит на практике? Поверьте, плохо! Например, в ранних Berkeley-совместимых ядрах ОС UNIX значение этого счетчика увеличивалось на 128 каждую секунду и на 64 для каждого нового соединения. Анализ исходных текстов ядра ОС Linux 1.2.8 показал, что значение ISN вычисляется данной ОС в зависимости от текущего времени по следующему, отнюдь не случайному закону:
(1) ISN = mcsec + 1000000 sec, где mcsec - время в микросекундах;
sec - текущее время в секундах, причем отсчет его идет от 1970 года.
Вы думаете, что в других сетевых ОС лучше? Ошибаетесь! В ОС Windows NT 4.0 значение ISN увеличивается на 10 примерно каждую миллисекунду, то есть для Windows NT справедлива следующая формула;
(2) ISN ~ 10 msec, где
msec - текущее время в миллисекундах.
Однако больше всего удивил защищенный по классу Bl UNIX, установленный на многопроцессорной мини-ЭВМ - полнофункциональном файрволе. Эта наиболее защищенная из всех сетевая ОС имеет также простой времязависимый алгоритм генерации начального значения идентификатора TCP-соединения. Как говорится, комментарии здесь излишни. Мало того, что в единственном базовом "защищенном" (?!) протоколе Internet - протоколе TCP - применяется простейший способ идентификации соединения, который в принципе не позволяет гарантировать надежную защиту от подмены одного из абонентов при нахождении атакующего в том же сегменте, так еще и сами разработчики сетевых ОС разрушают и без того хрупкую безопасность этого протокола, используя про-стые времязависимые алгоритмы генерации ISN!
Итак, в том случае, если в сетевой операционной системе используется времязависимый алгоритм генерации начального значения идентификатора TCP-соединения, то атакующий получает принципиальную возможность определить с той или иной степенью точности вид функции, описывающей закон получения ISN. Исходя из практических исследований сетевых ОС, а также из общих теоретических соображений, можно предложить следующий обобщенный вид функции, описывающий времязависимый закон получения ISN:
(3) ISN = F (mcsec, msec, sec),
где mcsec - время в микросекундах (обычно, в зависимости от аппаратного обеспечения компьютера, минимальной единицей измерения машинного времени является микросекунда, в обычных IBM это так). Этот параметр циклически изме-няется за секунду от 0 до 106-!;
msec - время в миллисекундах. Циклически изменяется за секунду от 0 до 999;
sec - текущее время в секундах. Постоянно увеличивается каждую секунду.
Рассматривая функцию (3) на малом промежутке времени (меньшем 1 секунды), для удобства аппрокси-мации можно считать, что
(4) ISN = F (mcsec).
Итак, мы будем считать, что значение ISN зависит только от микросекунд. Данная функция (4) в силу особенностей изменения своих аргументов обычно в сетевых ОС является или кусочнолинейной или ступенчатой. Например, зависимость (1), описывающая закон получения ISN в ОС Linux, в случае приведения ее к виду (4) является кусочнолинейной, а функциональная зависимость (2), справедливая для Windows NT, - ступенчатой.
На данном этапе мы вплотную подошли к проблеме определения вида функциональной зависимости ISN от параметра mcsec для конкретной сетевой ОС Первый способ получения этой зависимости - анализ исходных текстов ядра операционной системы. Использование данного способа на практике обычно оказывается невозможным из-за отсутствия исходных тек-стов большинства ОС. Исключение составляют ОС Linux и FreeBSD, поставляемые с исходными текстами ядра.
В связи с этим предлагается другой метод получения закона изменения ISN от параметра mcsec. В этом случае сетевая ОС рассматривается исследователем как "чёрный ящик", к которому применяется метод тестирования "запрос - ответ": на исследуемую сетевую ОС передается серия обычных запросов на создание ТСР-соединения и принимается соответствующее количество ответов с текущими значениями ISN операционной системы в каждый момент времени. При этом замеряются временные интервалы (в микросекундах) между запросом и ответом на него и время, прошедшее между запросами, В результате исследователем будет получена следующая таблица дискретных отсчетов ISN и соответствующие им моментов времени в mcsec:

ISN0 ISN1 …. ISNn
t0 t1 …. tn

где ISNn -значение ISN, полученное за время t n от
начала эксперимента (время начала эксперимента принимается за 0).
Аппроксимируя данную таблицу дискретных значений непрерывной функцией одним из известных математических методов (наименьших квадратов, например) получим непрерывную функцию, приближенно описывающую изменение ISN на данном временном промежутке (от 0 до t n), при этом чем выше точность исходных данных, тем точнее приближение:
(5) ISN(t)~F(t):
Эта формула в общем случае позволяет по предыдущему значению ISN, зная функцию изменения ISN от времени, экстраполировать следующее значение ISN. Теперь атакующий может, получив в ответ на TCP-запрос текущее значение ISN для ОС в данный момент времени, математически предсказать следующее возможное значение ISN через некоторый промежуток времени.
Хотелось бы обратить внимание на следующий важный момент: чем ближе в сети находятся исследователь и тестируемая ОС, тем выше точность получения аппроксимирующей функции, так как в противном случае, время за которое запрос дойдет до системы и будет выработан ISN, может существенно отличаться из-за задержек в канале связи от времени передачи ответа обратно. При этом погрешность исходных данных будет увеличиваться, а точность экстраполяции - падать.
Атакующему вовсе не обязательно проводить подобные исследования с интересующим его удаленным хостом. Достаточно только узнать тип операционной системы на предполагаемой цели атаки и получить в свое распоряжение подобную систему для определения формулы изменения ISN в данной ОС.
Что касается практических результатов, то применение описанной выше методики получения формулы ISN(t) на примере ОС Linux 1.2.8 и Windows NT 4.0 в случае нахождения в одном сегменте с данными ОС позволило определить это 32-битное значение (от 0 до 232-1) по его предыдущему значению для ОС Windows NT с точностью до 10, а для ОС Linux 1.2.8 - с точностью примерно до 100. В следующей таблице приведены снятые в процессе эксперимента с ОС Linux 1.2.8 значения изменения ISN (а не абсолютные значения) за соответствующие промежутки времени:
Таблица изменения значения ISN для ОС Linux 1.2.8

t,мкс 2759 5685 8560 11462 14303
DISN 65135 134234 202324 270948 338028

В общем случае, определив вид функций для вычисления ISN в операционных системах на сервере и предполагаемом клиенте, атакующий начинает следить за ОС сервера, ожидая подключения предполагаемого клиента. В тот момент времени, когда подключение произошло, атакующий может подсчитать возможный диапазон значений ISN, которыми обменялись при создании ТСР-канала данные хосты. Так как атакующий может вычислить значения ISN только приближенно, то ему не избежать подбора. Однако, если не проводить описанный выше анализ, то для перебора всех возможных значений ISSa и ISSb понадобилось бы послать 264 пакетов, что нереально. В случае использования описанного выше анализа в зависимости от полученной степени точности и удаления атакующего от хостов потребуется послать значительно меньшее число пакетов. Например, если удалось вычислить значения ISN на операционных системах с точностью до' 100, то атакующему для подмены одного из абонентов TCP-соединения достаточно послать всего 10000 пакетов.

Использование недостатков идентификации абонентов TCP-соединения для атаки на rsh-сервер

В ОС UNIX существует понятие: доверенный хост. Доверенным по отношению к данному хосту называется сетевой компьютер, доступ на который пользователю с данного хоста возможен без его аутентификации и идентификации с помощью г-службы (г - сокращение от анг. "remote" - удаленный). Обычно в ОС UNIX существует файл rhosts, в котором находится список имен и IP-адресов доверенных хостов. Для получения к ним удален-ного доступа пользователю необходимо воспользоваться программами, входящими в г-службу (например, riogin, rsh и т.д.). В этом случае при использовании г-программ с доверенного хоста пользователю для получения удаленного доступа не требуется проходить стандартную процедуру идентификации и аутентификации, заключающуюся в проверке его логического имени и пароля. Единственной аутентифицирующей пользователя информацией для г-службы является IP-адрес хоста, с которого пользователь осуществляет удаленный r-доступ. Отметим, что все программы из г-службы реализованы на базе протокола TCP. Одной из программ, входящих в r-службу, является rsh, с помощью которой возможно осуществление данной атаки. Программа rsh (remoute shell) позволяет отдавать команды shell удаленному хосту. При этом (что чрезвычайно важно в данном случае!) для того, чтобы отдать команду, достаточно послать запрос, но необязательно получать на него ответ. При атаке на г-службу вся сложность для атакующего заключается в том, что ему необходимо послать пакет от имени доверенного хоста, то есть в качестве адреса отпра-вителя необходимо указать IP-адрес доверенного хоста. Следовательно, ответный пакет будет отправлен именно на доверенный хост, а не на хост атакующего.

Пусть хост А доверяет хосту В. Хост X-Hacker - это станция атакующего.
Вначале атакующий X-Hacker открывает настоящее TCP-соединение с хостом В на любой ТСР-порт (mail, echo и т.д.). В результате X-Hacker получит текущее значение на данный момент времени ISNb. Далее, X-Hacker от имени А посылает на В TCP-запрос на открытие соединения:
1. X-Hacker ("А") -> В:SYN, ISSx.
Получив этот запрос, В анализирует IP-адрес отправителя и решает, что пакет пришел с хоста А. Следовательно, В в ответ посылает на А новое значение ISNb':
2. В -> А:SYN, ACK, ISNb, ACK(ISSx+1).
X-Hacker никогда не получит это сообщение от В, но, используя предыдущее значение ISNb и схему для получения ISNb' при помощи математического предсказания, может послать пакет на В:
3. X-Hacker ("А") -> В: АСК, ISSx+1, ACK(ISNb'+1) .
Отметим, что для того, чтобы послать этот пакет, вероятно, потребуется перебрать некоторое количество возможных значений ACK(ISSb' + 1), но не потребуется подбор ISSx + 1, так как этот параметр TCP-соединения был послан с хоста X-Hacker на В в первом пакете.
В случае осуществления данной атаки перед атакующим возникает следующая проблема. Так как X-Hacker посылает пакет (1) на В от имени А, то хост В ответит на А пакетом (2). А так как хост А не посылал на хост В никакого пакета с запросом, то А, получив ответ от В, перешлет на В пакет с битом RST - закрыть соединение. Атакующего с хоста X-Hacker это, естественно, не устраивает, поэтому одной из атак, целью которых является нарушение работоспособности системы, X-Hacker должен вывести из строя на некото-рое время хост А.
В итоге rsh-сервер на хосте В считает, что к нему подключился пользователь с доверенного хоста А, а на самом деле это атакующий с хоста X-Hacker. И хотя X-Hacker никогда не сможет получить пакеты с хоста В, но он сможет выполнять на нем команды (r-команды).
Хотелось бы привести пример реального инцидента, происшедшего в Суперкомпьютерном центре в Сан-Диего 12 декабря 1994 года, когда атакующий (небезызвестный Кевин Митник) использовал описанную выше схему удаленной атаки. Данный инцидент представляет исторический интерес и показывает, что опасности, описанные здесь, являются отнюдь не мнимыми угрозами из Internet, а той реальностью, над которой большинство пользователей просто не задумывается и которая в любой момент может пожаловать к ним в гости.
Все описанные ниже сведения взяты из письма эксперта по информационной безопасности Цутому Шимомуры (Tsutomu Shimomura) в различные эхо-конференции.
Далее приводится перевод его оригинального письма с некоторыми сокращениями и комментариями:
"From: tsutomu@ariel.sdsc.edu (Tsutomu Shimomura)
Newsgroups: comp.security.misc,сотр.protocols.tcp-ip,alt.security
Subject: Technical details of the attack
described by Markoff in NYT
Date: 25 Jan 1995 04:36:37 -0800
Organization: San Diego Supercomputer Center
Message-ID: <3g5gkl$5jloariel.sdsc.edu>
NNTP-Post ing -Host: ariel.sdsc.edu
Keywords: IP spoofing, security, session hijacking
Greetings from Lake Tahoe.
В статье Джона Маркоффа от 23.01.95 в NYT и в рекомендациях CERT CA-95:01, кажется, было достаточно много путаницы насчет того, что такое на самом деле атака с использованием подмены IP-адреса с целью подмены одного из абонентов соединения.

Имеется в виду статья в New York Times под названием "Data Network Is Found Open To New Threat". Следующая статья была опубликована 28 января 1995 года под названием "Taking a Computer Crime to Heart". Заключительная статья "A Most-Wanted Cyberthief Is Caught In His Own Web" опубликована 16 февраля того же года. Time Magazine напечатал две статьи под следующими громкими заголовками:
"KEVIN MITNICK'S DIGITAL OBSESSION" и "CRACKS IN THE NET:
America's most wanted hacker has been arrested, but the Internet is more vulnerable than ever" (Да неужели?! Куда уж более?!). Шумиха, поднятая американской прессой по этому незначительному поводу была столь велика, что остается только удивляться, насколько еще верна крылатая фраза Шекспира: "Много шума из ничего". Хотя с другой стороны, это можно объяснить тем, что во-первых, в США благодаря стараниям прессы сложился легендарный образ злобного суперхакера, этакого "монстра" киберпространства - Кевина Митника, во-вторых, это был один из редких случаев обнародования информации о случившейся удаленной атаке, в-третьих, ее осуществление удалось проследить и запротоколировать, что обычно очень не просто, и в-четвертых, это пожалуй, единственная известная, при этом довольно красивая, удаленная атака на TCP-соединение, и поэтому ей так и увлеклась пресса (истории о "тупых" атаках с перехватом пароля или попытками его подбора уже видимо, навязли на зубах у читателя).

Здесь приведены некоторые технические подробности из моей презентации 11.01.95 в CMAD 3 в Сономе, Калифорния. Надеюсь, это поможет снять всяческое непонимание природы этих атак.
Для атаки использовалось два различных механизма. Подмена IP-адреса отправителя и математическое предсказание начального значения идентификатора TCP-соединения позволили получить доступ к бездисковой рабочей станции, которая использовалась как Х-терминал.
В письмо включен log-файл, полученный с помощью программы tcpdump, с записью всех пакетов, посланных атакующим. Для краткости этот файл приводится с сокращением некоторых несущественных подробностей.
Моя конфигурация:
server = SPARC с ОС Solaris 1, обслуживающий х-terminal
х- terminal = бездисковая рабочая станция SPARC с ОС Solaris 1
target = основная цель атаки.
Атака началась в 14:09:32 25.12.94. Первые попытки зондирования начались с хоста toad.com (информация взята из log-файла).
14:09:32 toad.comft finger -1 ©target
14:10:21 toad.com# finger -1 ©server
14:10:50 toad.com# finger -1 root@server
14:11:07 toad.com# finger -1 @x-terminal
14:11:38 toad.com# showmount -e x-terminal
14:11:49 toad.com# rpcinfo -р х-terminal
14:12:05 toad.com# finger -1 root®x-terminal
Зондирование системы позволило определить, есть ли у нее другие доверенные системы для дальнейшей атаки. То, что атакующий смог запустить программы showmount и rpcinfo, означало, что он является пользователем root на хосте toad.com
Через шесть минут мы видим шторм TCP-запросов на создание соединения с адреса 130.92.6.97 на 513 порт (login) хоста server. При этом основная цель атакующего состоит в том, чтобы этими однонаправленными TCP-запросами переполнить очередь на 513 порту сервера так, чтобы он не смог отвечать на новые запросы на создание соединения. Особенно важно, чтобы сервер не смог сгенерировать TCP-пакет с битом RST в ответ на неожи-данно пришедший TCP-пакет с битами SYN и ACK.
Так как порт 513 является привилегированным пор-том, то теперь IP-адрес хоста server. login1
Шимомура здесь и далее после имени или IP-адреса хоста через точку указывает порт назначения. Поэтому запись server.login означает хост server и порт login (513). Соответственно, например, первая из распечатки log-файла запись 130.92.6.97.600 означает, что пакет передается с IP-адреса 130.92.6.97 с 600 порта может быть свободно использован атакующим для атаки с использованием подмены адреса на r-службы UNIX-систем (rsh, riogin). IP-адрес 130.92.6.97 атакующий выбрал случайным образом из неиспользуемых адресов (ему не нужно получать пакеты, передаваемые на этот адрес).
14:18:22.516699 130.92.6.97.600 > server.login: S 382726960:1382726960 (0) win 4096
14:18:22.566069 130.92.6.97.601 > server.login: S 1382726961:1382726961(0) win 4096
14:18:22.744477 130.92.6.97.602 > server.login: S 1382726962:1382726962(0) win 4096
14:18:22.830111 130.92.6.97.603 > server.login: S 1382726963:1382726963(0) win 4096
14:18:22.886128 130.92.6.97.604 > server.login: S 1382726964:1382726964(0) win 4096
14:18:22.943514 130.92.6.97.605 > server.login: S 1382726965:1382726965(0) win 4096
14:18:23.002715 130.92.6.97.606 > server.login: S 1382726966:1382726966(0) win 4096
14:18:23.103275 130.92.6.97.607 > server.login: S 1382726967:1382726967(0) win 4096
14:18:23.162781 130.92.6.97.608 > server.login: S 1382726968:1382726968(0) win 4096
14:18:23.225384 130.92.6.97.609 > server.login: S 1382726969:1382726969(0) win 4096
14:18:23.282625 130.92.6.97.610 > server.login: S 1382726970:1382726970(0) win 4096
14:18:23.342657 130.92.6.97.611 > server.login: S 1382726971:1382726971(0) win 4096
14:18:23.403083 130.92.6.97.612 > server.login: S 1382726972:1382726972(0) win 4096
14:18:23.903700 130.92.6.97.613 > server.login: S 1382726973:1382726973(0) win 4096
14:18:24.003252 130.92.6.97,614 > server.login: S 1382726974:1382726974(0) win 4096
14:18:24.084827 130.92.6.97.615 > server.login: S 1382726975:1382726975(0) win 4096
14:18:24.142774 130.92.6.97.616 > server.login: S 1382726976:1382726976(0) win 4096
14:18:24.203195 130.92.6.97.617 > server.login: S 1382726977:1382726977(0) win 4096
14:18:24.294773 130.92.6.97.618 > server.login: S 1382726978:1382726978(0) win 4096
14:18:24.382841 130.92.6.97.619 > server.login: S 1382726979:1382726979(0) win 4096
14:18:24.443309 130.92.6.97.620 > server.login: S 1382726980:1382726980(0) win 4096
14:18:24.643249 130.92.6.97.621 > server.login: S 1382726981:1382726981(0) win 4096
14:18:24.906546 130.92.6.97.622 > server.login: S 1382726982:1382726982(0) win 4096
14:18:24.963768 130.92.6.97.623 > server.login: S 1382726983:1382726983(0) win 4096
14:18:25.022853 130.92.6.97.624 > server.login: S 1382726984:1382726984(0) win 4096
14:18:25.153536 130.92.6.97.625 > server.login: S 1382726985:1382726985(0) win 4096
14:18:25.400869 130.92.6.97.626 > server.login: S 1382726986:1382726986(0) win 4096
14:18:25.483127 130.92.6.97.627 > server.login: S 1382726987:1382726987(0) win 4096
14:18:25.599582 130.92.6.97.628 > server.login: S 1382726988:1382726988(0) win 4096
14:18:25.653131 130.92.6.97.629 > server.login: S 1382726989:1382726989(0) win 4096
Хост server генерирует на первые 8 запросов соответственно 8 ответов, после чего очередь переполняется.
Хост server периодически будет посылать эти ответы но так и не дождется на них никакой реакции.
Далее мы видим 20 попыток создания соединения с хоста apollo.it.luc.edu на х-terminal, shell Основная цель этих запросов - определить закон изменения начального значения идентификатора TCP-соединения на хосте х-terminal. Так как значение ISN увеличивается на единицу с каждым вновь посылаемым запросом, то, следовательно, эти запросы генерирует не ядро сетевой ОС. При этом очередь запросов на хосте х-terminal не переполняется, так как атакующий после каждого запроса передает пакет с битом RST, что означает "закрыть соединение".
14:18:25.906002 apollo.it.luc.edu.l000 > х-terminal.shell: s 1382726990:1382726990(0) win 4096
14:18:26.094731 х-terminal.shell > apollo.it.luc.edu.1000o S 2021824000:2021824000(0) ack 1382726991 win
14:18:26.172394 apollo.it.luc.edu.1000 > x-terminal.shell: R 1382726991:1382726991(0) win 0
14:18:26.507560 apollo.it.luc.edu 999 > х-temunal.shell: S 1382726991:1382726991(0) win 4096
14:18:26.694691 х-terminal.shell > apollo.it.luc.edu.999- s 2021952000:2021952000(0) ack 1382726992 win 4096
14:18:26.775037 apollo.it.luc.edu 999 > х-terminal.shell: R 1382726992:1382726992(0) win 0
14:18:26.775395 apollo.it.luc.edu 999 > х-tenninal.shell: R 1382726992:1382726992(0) win 0
14:18;27.014050 apollo.it.luc.edu 998 > x-terminal.shell: S 1382726992:1382726992(0) win 4096
14:18:27.174846 х-terminal.shell > apollo.it.luc.edu.998: S 2022080000:2022080000(0) ack 1382726993 win4096
14:18:27.251840 apollo.it.luc.edu.998 > х-terminal.shell: R 1382726993:1382726993(0) win 0
14:18:27.544069 apollo.it.luc.edu.997 > х-terminal.shell: S 1382726993:1382726993(0)win 4096
14:18:27.714932 х-terminal.shell >apollo.it.luc.edu.997: S 2022208000:2022208000(0) ack 1382726994 win4096
14:18:27.794456 apollo.it.luc.edu.997 > х-terminal.shell: R 1382726994:1382726994(0)win 0
14:18:28.054114 apollo.it.luc.edu.996 > х-terminal.shell: S 1382726994:1382726994(0)win 4096
14:18:28.224935 х-terminal.shell >apollo.it.luc.edu.996: S2022336000:2022336000(0) ack 1382726995 win4096
14:18:28.305578 apollo.it.luc.edu.996 > х-terminal.shell: R 1382726995:1382726995(0)win 0
14:18:28.564333 apollo.it.luc.edu.995 > х-terminal.shell: S 1382726995:1382726995(0)win 4096
14:18:28.734953 х-terminal.shell >apollo.it.luc.edu.995: S2022464000:2022464000(0) ack 1382726996 win4096
14:18:28.811591 apollo.it.luc.edu.995 > х-terminal.shell: R 1382726996:1382726996(0)win 0
14:18:29.074990 apollo.it.luc.edu.994 > х-terminal.shell: S 1382726996:1382726996(0)win 4096
14:18:29.274572 х-terminal.shell > apollo.it.luc.edu.994: S 2022592000:2022592000(0) ack 1382726997 win4096
14:18:29.354139 apollo.it.luc.edu.994 > х-terminal.shell: R 1382726997:1382726997 (0)win 0
14:18:29.354616 apollo.it.luc.edu.994 > х-terminal.shell: R 1382726997:1382726997(0) win 0
14:18:29.584705 apollo.it.luc.edu.993 > х-terminal.shell: S 1382726997:1382726997(0) win 4096
14:18:29.755054 х-terminal.shell > apollo.it.luc.edu.993: S2022720000:2022720000(0) ack 1382726998 win 4096
14:18:29.840372 apollo.it.luc.edu.993 > х-terminal.shell: R 1382726998:1382726998(0) win 0
14:18:30.094299 apollo.it.luc.edu.992 > х-terminal.shell: S 1382726998:1382726998(0) win 4096
14:18:30.265684 х-terminal.shell > apollo.it.luc.edu.992: S 2022848000:2022848000(0) ack 1382726999 win 4096
14:18:30.342506 apollo.it.luc.edu.992 > х-terminal.shell: R 1382726999:1382726999(0) win 0
14:18:30.604547 apollo.it.luc.edu.991 > х-terminal.shell: S 1382726999:1382726999(0) win 4096
14:18:30.775232 х-terminal.shell > apollo.it.luc.edu.991: S 2022976000:2022976000(0) ack 1382727000 win 4096
14:18:30.852084 apollo.it.luc.edu.991 > х-terminal.shell: R 1382727000:1382727000(0) win 0
14:18:31.115036 apollo.it.luc.edu.990 > х-terminal.shell: S 1382727000:1382727000(0) win 4096
14:18:31.284694 х-terminal.shell > apollo.it.luc.edu.990: S 2023104000:2023104000(0) ack 1382727001 win4096
14:18:31.361684 apollo.it.luc.edu.990 > х-terminal.shell: R 1382727001:1382727001(0)win 0
14:18:31.627817 apollo.it.luc.edu.989 > х-terminal.shell: S 1382727001:1382727001(0)win 4096
14:18:31.795260 х-terminal.shell >apollo.it.luc.edu.989: S 2023232000:2023232000(0) ack 1382727002 win4096
14:18:31.873056 apollo.it.luc.edu.989 > х-terminal.shell: R 1382727002:1382727002(0) win 0
14:18:32.164597 apollo.it.luc.edu.988 > х-terminal.shell: S 1382727002:1382727002(0)win 4096
14:18:32.335373 х-terminal.shell >apollo.it.luc.edu.988: S 2023360000:2023360000(0) ack 1382727003 win4096
14:18:32.413041 apollo.it.luc.edu.988 > х-terminal.shell: R 1382727003:1382727003(0)win 0
14:18:32.674779 apollo.it.luc.edu.987 > х-terminal.shell: S 1382727003:1382727003(0) win 4096
14:18:32.845373 х-terminal.shell >apollo.it.luc.edu.987: S2023488000:2023488000(0) ack 1382727004 win4096
14:18:32.922158 apollo.it.luc.edu.987 > х-terminal.shell: R 1382727004:1382727004(0)win 0
14:18:33.184839 apollo.it.luc.edu.986 > х-terminal.shell: S 1382727004:1382727004(0)win 4096
14:18:33.355505 х-terminal.shell >apollo.it.luc.edu.986: S2023616000:2023616000(0) ack 1382727005 win4096
14:18:33.435221 apollo.it.luc.edu.986 > х-terminal.shell: R 1382727005:1382727005(0) win 0
14:18:33.695170 apollo.it.luc.edu.985 > x-terminal.shell: S 1382727005:1382727005(0) win 4096
14:18:33.985966 х-terminal.shell > apollo.it.luc.edu.985: S 2023744000:2023744000(0) ack 1382727006 win 4096
14:18:34.062407 apollo.it.luc.edu.985 > x-terminal.shell: R 1382727006:1382727006(0) win 0
14:18:34.204953 apollo.it.luc.edu.984 > x-terminal.shell: S 1382727006:1382727006(0) win 4096
14:18:34.375641 х-terminal.shell > apollo.it.luc.edu.984: S 2023872000:2023872000(0) ack 1382727007 win 4096
14:18:34.452830 apollo.it.luc.edu.984 > x-fcerminal.shell: R 1382727007:1382727007(0) win 0
14:18:34.714996 apollo.it.luc.edu.983 > x-terminal.shell: S 1382727007:1382727007(0) win 4096
14:18:34.885071 х-terminal.shell > apollo.it.luc.edu.983: S 2024000000:2024000000(0) ack 1382727008 win 4096
14:18:34.962030 apollo.it.luc.edu.983 > x-terminal.shell: R 1382727008:1382727008(0) win 0
14:18:35.225869 apollo.it.luc.edu.982 > x-terminal.shell: S 1382727008:1382727008(0) win 4096
14:18:35.395723 х-terminal.shell > apollo.it.luc.edu.982: S 2024128000:2024128000(0) ack 1382727009 win 4096
14:18:35.472150 apollo.it.luc.edu.982 > x-terminal.shell: R 1382727009:1382727009(0)win 0
14:18:35.735077 apollo.it.luc.edu.981 > x-terminal.shell: S 1382727009:1382727009(0)win 4096
14:18:35.905684 х-terminal.shell >apollo.it.luc.edu.981: S 2024256000:2024256000(0) ack 1382727010 win4096
14:18:35.983078 apollo.it.luc.edu.981 > x-terminal.shell: R 1382727010:1382727010(0)win 0
Видно, что каждый последующий ответный пакет SYN-ACK, посылаемый с хоста х- terminal, имеет начальное значение идентификатора TCP-соединения на 128000 больше, чем у предыдущего.

Из анализа приведенной распечатки пакетов видно, что каждое последующее начальное значение ISN на хосте х- terminal. shell отличается от предыдущего на 128000. Например. 2024256000 - 2024128000 = 128000 или 2024128000 - 2024000000 = 128000. Не правда ли простейший закон генерации ISN?!

Далее мы видим поддельный запрос на создание TCP-соединения якобы с хоста server, login на х-terminal .shell. При этом х-terminal доверяет хосту server и, следовательно, х-terminal будет выполнять все запросы, переданные с этого хоста (или с любого другого, подменившего хост server).
Х- terminal затем отвечает на хост server пакетом SYN-ACK и ожидает подтверждения этого пакета ACK'ом, что должно означать открытие соединения. Так как хост server игнорирует все пакеты, посланные на server. login, то поддельный пакет атакующего, подтвержденный ACK'ом, должен иметь успех.
Обычно значение подтверждения (ACK) берется из пакета SYN-ACK. Однако атакующий, используя предсказание закона изменения начального значения идентификатора TCP-соединения на хосте х-terminal сможет получить значение АСК без получения пакета SYN-ACK:
Используя полученную математическую зависимость для предсказания значения ISN, атакующий может послать следуюшии пакет от имени server.login со значением АСК. равным 2024384001, вычисленным по его предыдущему значению 2024256000 добавлением к нему 128000 + I. i
14:18:36.245045 server.login > х-terminal.shell: S 1382727010:1382727010(0) win 4096
14:18:36.755522 server.login > x-terminal.shell: . ack 2024384001 win 4096
Хост атакующего сейчас имеет одностороннее соединение с х-terminal, shell, который считает, что это соединение открыто с server, login. Атакующий теперь может передавать пакеты с данными, содержащими верные значения АСК, на х- terminal. Далее, он посылает следующие пакеты:
14:18:37.265404 server.login > х-terminal.shell: P 0:2(2) ack 1 win 4096
14:18:37.775872 server.login > х-terminal.shell: P 2:7(5) ack 1 win 4096
14:18:38.287404 server.login > x-terminal.shell: P 7:32(25) ack 1 win 4096
что означает выполнение следующей команды:
14:18:37 server# rsh x-terminal "echo + + "/.rhosts"
Атакующий, завершая атаку, от имени server.login посылает на х-terminal shell три пакета, что эквивалентно выполнению на хосте server следующей г-команды: rsh х- terminal "echo + + "/.rhosts". Эта команда дописывает в файл /.rhosts строчку + + и делает доверенными все станции.

Всего атака заняла менее 16 секунд. Атакующий закрывает ложное соединение:
14:18:41,347003 server.login > х-terminal.shell: . ack 2 win 4096
14:18:42.255978 server.login > х-terminal.shell: . ack 3 win 4096
14:18:43.165874 server.login > х-terminal.shell: F 32:32(0) ack 3 win 4096
14:18:52.179922 server.login > x-terminal.shell: R 1382727043:1382727043(0) win 4096
14:18:52.236452 server.login > x-terminal.shell: R 1382727044:1382727044(0) win 4096
Далее, атакующий посылает RST-пакеты и, следовательно, закрывает ранее открытые "односторонние" соединения с server.login, тем самым освобождая очередь запросов:
14:18:52.298431 130.92.6.97.600 > server.login: R 1382726960:1382726960(0) win 4096
14:18:52.363877 130.92.6.97.601 > server.login: R 1382726961:1382726961(0) win 4096
14:18:52.416916 130.92.6.97.602 > server.login: R 1382726962:1382726962(0} win 4096
14:18:52.476873 130.92.6.97.603 > server.login: R 1382726963:1382726963(0) win 4096
14:18:52.536573 130.92.6.97.604 > server.login: R 1382726964:1382726964(0) win 4096
14:18:52.600899 130.92.6.97.605 > server.login: R 1382726965:1382726965(0) win 4096
14:18:52.660231 130.92.6.97.606 > server.login: R 1382726966:1382726966(0) win 4096
14:18:52.717495 130.92.6.97.607 > server.login: R 1382726967:1382726967(0) win 4096
14:18:52.776502 130.92.6.97.608 > server.login: R 1382726968:1382726968(0) win 4096
14:18:52.836536 130.92.6.97.609 > server.login: R 1382726969:1382726969(0) win 4096
14:18:52.937317 130.92.6.97.610 > server.login: R 1382726970:1382726970(0} win 4096
14:18:52.996777 130.92.6.97.611 > server.login: R 1382726971:1382726971(0} win 4096
14:18:53.056758 130.92.6.97.612 > server.login: R 1382726972:1382726972(0} win 4096
14:18:53.116850 130.92.6.97.613 > server.login: R 1382726973:1382726973(0} win 4096
14:18:53.177515 130.92.6.97.614 > server.login: R 1382726974:1382726974(0} win 4096
14:18:53.238496 130.92.6.97.615 > server.login: R 1382726975:1382726975(0) win 4096
14:18:53.297163 130.92.6.97.616 > server.login: R 1382726976:1382726976(0) win 4096
14:18:53.365988 130.92.6.97.617 > server.login: R 1382726977:1382726977(0) win 4096
14:18:53.437287 130.92.6.97.618 > server.login: R 1382726978:1382726978(0) win 4096
14:18:53.496789 130.92.6.97.619 > server.login: R 1382726979:1382726979(0) win 4096
14:18:53.556753 130.92.6.97.620 > server.login: R 1382726980:1382726980(0} win 4096
14:18:53.616954 130.92.6.97.621 > server.login: R 1382726981:1382726981(0) win 4096
14:18:53.676828 130.92.6.97.622 > server.login: R 1382726982:1382726982(0} win 4096
14:18:53.736734 130.92.6.97.623 > server.login: R 1382726983:1382726983(0) win 4096
14:18:53.796732 130.92.6.97.624 > server.login: R 1382726984:1382726984(0) win 4096
14:18:53.867543 130.92.6.97.625 > server.login: R 1382726985:1382726985(0) win 4096
14:18:53.917466 130.92.6.97.626 > server.login: R 1382726986:1382726986(0) win 4096
14:18:53.976769 130.92.6.97.627 > server.login: R 1382726987:1382726987(0) win 4096
14:18:54.039039 130.92.6.97.628 > server.login: R 1382726988:1382726988(0} win 4096
14:18:54.097093 130.92.6.97.629 > server.login: R 1382726989:1382726989(0) win 4096
Хост server, login снова готов к приему запросов на создание соединения".
Не станем вдаваться в подробное литературное описание этого инцидента (беллетристики о Митнике более чем достаточно), а остановимся только на технических подробностях этой удаленной атаки.
Любому специалисту очевидно, что в данном случае в свят с простейшим законом генерации ISN в ОС Solaris 1. осуществленная Кевином удаленная атака является тривиальной и по сути Шимомура на нее сам напросился. Наверное, если Шимомура был бы действительно таким профессиональным специалистом по информационной безопасности, каким его описывает пресса, то он очевидно, знал о возможности осуществления подобной атаки, но он ничего не предпринимал (интересно, почему - может он именно того и хотел- чтобы его взломали? До того случая Шимомуру никто и не знал, зато теперь он один из самых известных экспертов по безопасности). Точного ответа на эти вопросы мы видимо, не узнаем.
Шимомура сказал после этого: "Проблема не в Кевине, проблема в том, что большинство систем действительно плохо защищены. То, что делал Митник, остается осуществимым и сейчас".

Нарушение работоспособности хоста в сети Internet при использовании направленного "шторма" ложных TCP-запросов на создание соединения, либо при переполнении очереди запросов

Из рассмотренной в предыдущем пункте схемы соз-дания TCP-соединения следует, что на каждый полученный TCP-запрос на создание соединения операционная система должна сгенерировать начальное значение идентификатора ISN и отослать его в ответ на запросивший хост. При этом, так как в сети Internet (стандарта IPv4) не предусмотрен контроль за IP-адресом отправителя сообщения, то невозможно отследить истинный маршрут, пройденный IP-пакетом, и, следовательно, у конечных абонентов сети нет возможности ограничить число возможных запросов, принимаемых в единицу времени от одного хоста. Поэтому возможно осуществление типовой УА "Отказ в обслуживании", которая будет заключаться в передаче на атакуемый хост как можно большего числа ложных TCP-запросов на создание соединения от имени любого хоста в сети. При этом атакуемая сетевая ОС в зависимости от вычислительной мощности компьютера либо - в худшем случае - практически зависает, либо - в лучшем случае - перестает реагировать на легальные запросы на подключение (отказ в обслуживании). Это происходит из-за того, что для всей массы полученных ложных запросов система должна, во-первых, сохранить в памяти полученную в каждом запросе информацию и во-вторых, выработать и отослать ответ на каждый запрос. Таким образом, все ресурсы системы "съедаются" ложными запросами: переполняется очередь запросов и система занимается только их обработкой. Эффективность данной удаленной атаки тем выше, чем больше пропускная способность канала между атакующим и целью атаки, и тем меньше, чем больше вычислительная мощь атакуемого компьютера (число и быстродействие процессоров, объем ОЗУ и т. д.).
Очевидность данной удаленной атаки была ясна еще лет двадцать назад, когда появилось семейство протоколов TCP/IP. Корни этой атаки находятся в самой инфраструктуре сети Internet, в ее базовых протоколах - IP и TCP. Но каково же было удивление, когда можно было увидеть на информационном WWW-сервере CERT (Computer Emergency Respone Team) первое упоминание об этой удаленной атаке, датированное только 19 сентября 1996 года! Там эта атака носила название "TCP SYN Flooding and IP Spoofing Attacks" - "наводнение" TCP-запросами с ложных IP-адресов.
Другая разновидность атаки "Отказ в обслуживании" состоит в передаче на атакуемый хост нескольких десятков (сотен) запросов на подключение к серверу, что может привести к временному (до 10 минут) переполнению очереди запросов на сервере (см. атаку К. Митника). Это происходит из-за того, что некоторые сетевые ОС устроены так, чтобы обрабатывать только первые несколько запросов на подключение, а остальные-игнорировать. То есть при получении N запросов на подключение ОС сервера ставит их в очередь и генерирует соответственно N ответов. Далее, в течение определенного промежутка времени, (тайм-аут <= 10 минут) сервер будет дождаться от предполагаемого клиента сообщения, завершающего handshake и подтверждающего создание виртуального канала с сервером. Если атакующий пришлет на сервер количество запросов на подключение, равное максимальному числу одновременно обрабатываемых запросов на сервере, то в течение тайм-аута остальные запросы на подключение будут игнорироваться и к серверу будет невозможно подключиться.
Эксперименты с данной удаленной атакой, проводимые на различных сетевых ОС в экспериментальных 10-мегабитных сегментах сети, выявили следующие интересные результаты. В случае передачи по каналу связи максимально возможного числа TCP-запросов на создание соединения и нахождении атакующего в одном сегменте с целью атаки атакуемые системы вели себя следующим образом: ОС Windows '95, установленная на 486DX2-66 с 8 Мб ОЗУ, "замирала" и переставала реагировать на всяческие внешние воздействия (нажатия на клавиатуру, например): ОС Linux 2.0.0 на 486DX4-133 с 8 Мб ОЗУ тоже практически прекращала всякую работу и обрабатывала одно нажатие на клавиатуре примерно 30 секунд. Мало того, что к этим атакованным хостам было, естественно, невозможно получить удаленный доступ, но и локальный доступ был невозможен. Наилучший результат в процессе этого теста показал двухпроцессорный файрвол: удаленное подключение к нему было также невозможно, но осуществляемая атака на локальных пользователях никак не сказывалась (все-таки два процессора).
Не менее интересным было поведение атакуемых систем после снятия воздействия. ОС Windows '95 практически сразу же после прекращения воздействия начала нормально функционировать: в ОС Linux 2.0.0 с 8 Мб ОЗУ по-видимому, переполнился буфер, и более получаса система не функционировала ни для удаленных, ни для локальных пользователей, а занималась передачей ответов на полученные ранее запросы. Двухпроцессорный файрвол сразу же после снятия воздействия стал доступен для удаленного доступа.
При нахождении с атакуемыми системами в соседних смежных сегментах выяснилось следующее: ОС Windows '95 на Pentium 100 с 16 Мб ОЗУ обрабатывала каждое нажатие на клавиатуре примерно секунду, ОС Linux 2.0.0 на Pentium 100 с 16 Мб ОЗУ практически "повисла" - одно нажатие за 30 секунд, зато после снятия воздействия у локального пользователя немедленно появилась возможность нормальной работы.
Не нужно обманываться результатами этого теста и считать, что Windows '95 показала себя с лучшей стороны. Это связано только лишь с тем, что передаваемые TCP-запросы направлялись на FTP-порт, то есть это был запрос на подключение к FTP-серверу. а так как Windows '95 - принципиально клиентская операционная система и FTP-сервера под нее нет, то, следовательно, сохранять в памяти параметры запроса и дожидаться окончания handshake ей просто не было необходимости.
В процессе эксперимента также была выявлена одна принципиальная слабость, присущая всем ОС Linux. После передачи около десятка запросов на определенный порт (FTP или TELNET) на некоторое время (до нескольких десятков минут) на атакуемом хосте отключался соответствующий данному порту сервер (каждая программа-сервер ожидает запросов на определенном зарезервированном порту), то есть в течение определенного промежутка времени у пользователей не было возможности удаленно подключиться к данному серверу и по-лучить удаленный доступ к его ресурсам. Это, как уже говорилось ранее, связано с переполнением числа одновременно обслуживаемых данным сервером клиентов.
В заключение необходимо отметить, что в существующем стандарте сети Internet IPv4 нет приемлемых способов надежно обезопасить свои системы от этой удаленной атаки. К счастью, атакующий в результате осуществления описанной атаки не сможет получить несанкционированный доступ к вашей информации. Он сможет лишь "съесть" вычислительные ресурсы вашей системы и нарушить ее связь с внешним миром. Остается надеяться, что нарушение работоспособности вашего хоста просто никому не нужно.

Мифические удаленные атаки в сети Internet

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

IP-фрагментация как способ проникновения через Firewall

Как известно из описания протокола IP (RFC 791) максимальный размер IP-пакета может достигать 2161 байт. Однако размер пакета (дейтаграммы), передаваемого непосредственно по каналу передачи, зависит от типа среды передачи. Например, в среде Ethernet максимальный размер дейтаграммы 1500 байт, в среде АТМ - 56 байт. Поэтому для того, чтобы IP-пакеты могли передаваться по сетям любых типов, в протоколе IP предусмотрена фрагментация пакетов. То есть для передачи одного большою пакета он разбивается на соответствующее количество пакетов меньших размеров (их размер обуславливается максимальным размером пакета в соответствующей среде передачи). Этот процесс разбиения IP-пакета на части называется IP-фрагментацией. Применение в сети Internet фрагментации пакетов делает ее более гибкой и инвариантной по отношению к разнообразным физическим средам передачи.
Не будем вдаваться в подробности, что означает каждое поле в IP-заголовке (RFC 791), так как в данном случае нас будут интересе вать только поля Fragment Offset и Flags. В поле Fragment Offset содержится значение, измеряемое восьмерками байт, обозначающее смещение фрагмента относительно начала дейтаграммы (именно на то, что оно измеряется в восьмерках байт, и не обратил внимание д-р F. В. Cohen в его статье "Packet Fragmentation Attacks"). Таким образом, единица в этом поле означает смещение на 8 байт от начала дейтаграммы. Поле Flags показывает фрагментирован ли пакет или нет.
Итак, каков механизм предполагаемого воздействия? Как известно, одной из основных функций всех файрволов является фильтрация проходящего через них сетевого трафика. В случае фильтрации на сетевом уровне ограничивается возможность доступа к определенным службам защищаемых хостов. Тип службы, на которую направляется пакет, определяется параметром "порт назначения" в заголовке пакета TCP или UDP. Поэтому файрвол анализирует этот параметр и проверяет его соответствие тем правилам фильтрации, которые на нем установлены. В случае соответствия правилам пакет пропускается дальше, в противном случае - отфильтровывается.
В своей статье "Packet Fragmentation Attacks" (опубликована в All.net) доктор F. В. Cohen предложил следующий сценарий предполагаемой атаки, заключающейся в прохождении фрагментированного пакета через файрвол, минуя правила фильтрации. Атакующий разбивает пакет на два фрагмента, первый из которых содержит фиктивный TCP- или UDP-заголовок с номером порта назначения, который не фильтруется правилами на файрволе (например, 25 порт - почтовый SMTP-сервер), а второй имеет такое смещение (равное 1)
С этой статьей д-р Cohen'a происходили с течением времени довольно любопытные изменения. В статье, на WWW-сервере all.net в мае 1996 года для осуществления атаки предлагалось занести в поле Fragment Offset значение, равное 1 (далее будет показано, что в этом случае подобная атака в принципе невозможна). Однако, после посещения одного из серверов уже в мае 1997 года с удивлением обнаружилась та же статья, но с одним "небольшим" исправлением: предлагалось заносить в это поле уже не 1, а О! Во всем остальном статья осталась неизменной.
В поле Fragment Offset, что перекрывает первый пакет и записывает в поле "порт назначения" истинное значение порта той службы, к которой доступ через файрвол запрещен. В этом случае правила фильтрации на файрволе пропустят этот IP-пакет, так файрвол не занимается сборкой фрагментированных IP-пакетов.
Действительно, сборкой фрагментированных IP-пакетов занимается операционная система конечного получателя пакета, и при сборке, как правило, не проверяется, не накладываются ли фрагменты пакета друг на друга. Сетевая ОС собирает фрагментированный пакет и передает его соответствующей службе, основываясь на значении в поле "порт назначения". На первый взгляд атака состоялась: фрагментированный пакет, направленный одной службе, прошел через файрвол и при сборке фрагментов передался другой службе, доступ на которую был запрещен правилами фильтрации файрвола. Однако, д-р F. В. Cohen не учел того важного факта, что значение в поле смещения согласно спецификации указывается в восьмерках байт, и даже если установить это значение в единицу и предположить, что сетевая ОС не проверяет наложение фрагментов, то после сборки фрагментов наложение произойдет только после первых восьми байт TCP- или UDP-заголовка, в которых и содержатся поля портов назначения.
Через некоторое время после опубликования статьи д-р Cohen, видимо, обнаружил описанную выше ошибку и внес в сценарий атаки одно изменение: единица в поле Fragment Offset теперь была им заменена на О! Проанализируем, насколько это изменение сделает возможным осуществление данной атаки.
Действительно, в этом случае атака может быть успешной, так как поле Flags (Об этом поле в сценарии атаки др. Cohen'a даже не упоминается!) ("индикатор фрагмен-тации") во втором пакете атакующий может заполнить нужным ему образом, а ведь именно на основании значения из этого поля сетевая ОС должна принимать решение о начале сборки фрагментов. Однако, анализ исходных текстов ядра операционных систем Linux и FreeBSD показал, что IP-пакет будет воспринят этими ОС как фрагмент только в том случае, если значение в поле Fragment Offset не равно О! Тем не менее, так как в алгоритме сборки фрагментов, описанном в RFC 791, не требуется обязательная проверка значения этого поля, то возможно, что некоторые сетевые ОС ее не производят (что маловероятно?) и, следовательно, атака может иметь успех.
Как кажется, сама идея наложения фрагментов является достаточно любопытна. Другое дело, что применение ее для проникновения пакетов атакующего через Firewall в существующем стандарте IPv4 представляется маловероятным.

Превышение максимально возможного размера 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 ссылке на WWW-сервер, где экспертами проводились подобные исследования на различных ОС, Там, собственно как и в CERT, эта атака называлась "Ping Death". На этом WWW-сервере предлагалось реализовать такую атаку следующим образом:
на рабочей станции с ОС Windows '95 или Windows NT необходимо выполнить следующую команду:
ping -1 65527 victim.destination. IP. address (поэтому - "Ping Death").
Так как обычный размер IP-заголовка составляет 20 байт, размер ICMP-заголовка - 8 байт, то подобный ICMP-накст будет превышать максимально возможный размер IP-пакета на 20 байт
(65527+20+8-65535=20).
Таким образом эти "эксперты" декларировали, что обычной командой ping якобы можно нарушить работоспособность практически любой сетевой ОС. В за-вершение на этом сервере приводилась следующая таблица тестирования различных операционных систем, на которые данная удаленная атака якобы произвела необходимый эффект.
Итак, тестирование было начато и, честно говоря, абсолютно не удивительно, когда ни одна из исследуемых операционных систем, ни IRIX, ни AIX, ни VMS, ни SunOs, ни FreeBSD, ни Linux, ни Windows NT 4.0, ни даже Windows '95 и Windows for WorkGroups 3.11, абсолютно никак не реагировали на подобный некорректный запрос и продолжали нормально функционировать! Тогда были предприняты специальные поиски ОС, которую бы действительно вывела из строя данная атака. Ею оказалась Windows 3.11с WinQVT - эта ОС действительно зависла.
На запрос, посланный этим так называемым "экспертам", которым столь доверяют CERT и CIAC, был получен ответ: в нем говорилось, что успех данной атаки зависит от многих факторов, а именно: программного и аппаратного обеспечения, установленного на компьютере и, самое главное, от фазы луны. Согласитесь, полный бред! Для полноты картины хотелось бы далее привести описание exploit'a, созданного для Windows NT 4.0, задача которого, используя ping, завесить собственный компьютер. Первым шагом предлагалось запустить Web Browser (?). На втором шаге требовалось запустить taskmgr (Task Manager) (??). В комментариях к этому шагу говорилось, что так Ping Death работает лучше (еще не хватает шаманского бубна!). И, наконец, требовалось запустить 18 ping-процессов (???) (не больше и не меньше; может быть, лучше сразу 100 - чего мелочиться!). Если вы думаете, что далее ваша ОС немедленно повиснет, то вы ошибаетесь! В комментариях к exploit'y до получения эффекта предлагалось ждать примерно 10 минут, с философским замечанием о том, что ожидание может продлиться несколько больше (интересно на сколько больше - час, месяц, год ?!) или несколько меньше.
В итоге можно сделать вывод, что шумиха, поднятая в CERT и CIAC по поводу данной атаки, является безосновательной, и ничего другого нам, видимо, не остается, как назвать эту атаку очередной программистской байкой и причислить ее к разряду практически неосуществимых.

И.Д.Медведковский П.В. Семьянов (Центр Защиты Информации СПбГТУ)

fairwind@mail.ru