Диплом: Обеспечение информационной безопасности в сетях IP

5.4 Контроль за виртуальными соединениями в распределенной ВС

В предыдущей главе было показано, что взаимодействие объектов РВС по

виртуальному каналу позволяет надежно защитить соединение от возможных

информационно-разрушающих воздействий по каналам связи. Однако взаимодействие

по ВК имеет свои минусы. К минусам относится необходимость контроля за

соединением. Если в системе связи удаленных объектов РВС не предусмотреть

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

одного типа удаленных атак на соединение ("Подмена доверенного объекта"),

можно подставить систему под другую типовую УА - "Отказ в обслуживании".

Поэтому для обеспечения надежного функционирования и работоспособности

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

контролировать процесс создания соединения. Как уже говорилось ранее, задача

контроля за ВК распадается на две подзадачи:

§ контроль за созданием соединения;

§ контроль за использованием соединения.

Решение второй задачи лежит на поверхности: так как сетевая операционная

система не может одновременно иметь бесконечное число открытых ВК, то в том

случае, если ВК простаивает в течение определенного системой тайм-аута,

происходит его закрытие.

Далее рассмотрим возможный алгоритм, позволяющий обеспечить контроль за

созданием соединения в РВС.

Основная задача, которую необходимо решить в данном случае, состоит в том,

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

каналы системы. Напомним, что при создании ВК полученный системой запрос на

создание соединения ставится в очередь запросов, и, когда до него дойдет

время, система выработает ответ на запрос и отошлет его обратно отправителю

запроса. Задача контроля за созданием соединения заключается как раз в том,

чтобы определить те правила, исходя из которых система могла бы либо

поставить запрос в очередь, либо нет. Если все пришедшие запросы

автоматически ставятся системой в очередь (так построены все сетевые ОС,

поддерживающие протокол TCP/IP), то это в случае атаки ведет к переполнению

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

происходит из-за того, что атакующий посылает в секунду столько запросов,

сколько позволит трафик (тысячи запросов в секунду), а обычный пользователь с

легальным запросом на подключение может послать лишь несколько запросов в

минуту! Следовательно, вероятность подключения втакой ситуации, при условии

переполнения очереди, один к миллиону в лучшем случае. Поэтому необходимо

ввести ограничения на постановку в очередь запросов от одного объекта.

Однако, если в РВС любой объект системы может послать запрос от имени (с

адреса) любого другого объекта системы, то, как отмечалось ранее, решить

задачу контроля не представляется возможным. Поэтому для обеспечения этой

возможности было введено Утверждение 5, исходя из которого в каждом пришедшем

на объект пакете должен быть указан пройденный им маршрут, позволяющий с

точностью до подсети подтвердить подлинность адреса отправителя. Учитывая

данный факт, позволяющий отсеять все пакеты с неверным адресом отправителя,

можно предложить следующее условие постановки запроса в очередь: в системе

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

подсети.

Это максимальное число ставящихся в очередь запросов в секунду определяется

непосредственно операционной системой и зависит от следующих параметров

сетевой ОС: быстродействия, объема виртуальной памяти, числа одновременно

обслуживаемых виртуальных каналов, длины очереди и т.д. Вводимое ограничение

не позволит атакующему переполнить очередь, так как только первые несколько

его запросов будут поставлены в очередь на обслуживание, а остальные будут

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

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

К минусам этого способа решения проблемы контроля за созданием соединения

можно отнести тот факт, что, так как адрес отправителя можно

аутентифицировать с точностью только до подсети, то атакующий может посылать

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

все остальные объекты из подсети атакующего будут лишены возможности

подключения к атакуемому объекту. Однако, так как, во-первых, атакующего по

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

и, во-вторых, не произойдет нарушения работоспособности цели атаки, то такая

атака вряд ли будет иметь смысл.

Итак, в завершение очередное требование к защищенным системам связи в

распределенных ВС.

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

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

Следствие 6.1.

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

Следствие 6.2.

тайм-ауту в случае отсутствия сообщений.

5.5 Проектирование распределенной ВС с полностью определенной

информацией о ее объектах с целью исключения алгоритмов удаленного поиска

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

информации, необходимой для доступа к ее удаленным объектам. Поэтому в РВС

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

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

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

на начальном этапе спроектировать систему так, чтобы информация о ее объектах

была изначально полностью определена. Это позволит, в свою очередь,

ликвидировать одну из причин успеха удаленных атак, связанных с

использованием в распределенной ВС алгоритмов удаленного поиска.

Однако в РВС с неопределенным и достаточно большим числом объектов (например,

Internet) спроектировать систему с отсутствием неопределенности практически

невозможно. В этом случае отказаться от алгоритмов удаленного поиска не

представляется возможным.

Существуют два типа данных алгоритмов. Первый типовой алгоритм удаленного

поиска - с использованием информационно-поискового сервера, второй - с

использованием широковещательных запросов. Применение в РВС алгоритма

удаленного поиска с использованием широковещательных запросов в принципе не

позволяет защитить систему от внедрения в нее ложного объекта, а,

следовательно, использование данного алгоритма в защищенной системе

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

использованием информационно-поискового сервера позволяет обезопасить систему

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

взаимодействие объектов системы с сервером происходит только с созданием

виртуального канала и, во-вторых, у объектов, подключенных к данному серверу,

и у сервера существует заранее определенная статическая ключевая информация,

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

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

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

Поясним последнее утверждение. В том случае, если виртуальный канал с

информационно-поисковым сервером создается с использованием только

динамически вырабатываемой ключевой информации, например, по схеме открытого

распределения ключей, то ничто не мешает атакующему - в том случае, если он

может перехватить первоначальный запрос на создание ВК с объекта системы -

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

Именно поэтому на всех объектах системы необходима начальная ключевая

информация для создания ВК с информационно-поисковым сервером.

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

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

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

алгоритмы удаленного поиска.

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

статической ключевой информации.

Следствие 8.1.

алгоритмов удаленного поиска с использованием широковещательных запросов.

Заключая эту главу, хотелось бы обратить внимание читателя на то, что, как

он, наверное, уже понял, в сети Internet в стандарте IPv4 практически ни одно

из сформулированных требований к построению безопасных систем связи между

удаленными объектами распределенных ВС не выполняется. Учтя собственные

ошибки в разработке стандарта IPv4, группы разработчиков уже завершили проект

создания нового более защищенного стандарта сети Internet - IPv6, где учтены

некоторые из вышеизложенных требований.

6. Конкретные примеры атак на TCP/IP

6.1 Пассивные атаки на уровне TCP

При данном типе атак крэкеры[16]

никаким образом не обнаруживают себя и не вступают напрямую во взаимодействие с

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

или сессиями связи.

6.1.1 Подслушивание

Атака заключаются в перехвате сетевого потока и его анализе (Англоязычные

термин - "sniffing")

Для осуществления подслушивания крэкеру необходимо иметь доступ к машине,

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

например, к маршрутизатору или PPP

[17]-серверу на базе UNIX[18].

Если крэкеру удастся получить достаточные права на этой машине, то с помощью

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

проходящий через заданные интерфейс.

Второй вариант - крэкер получает доступ к машине, которая расположена в одном

сегменте сети с системой, которой имеет доступ к сетевому потоку. Например, в

сети "тонкий ethernet" сетевая карта может быть переведена в режим, в котором

она будет получать все пакеты, циркулирующие по сети, а не только

адресованной ей конкретно. В данном случае крэкеру не требуется доступ к UNIX

- достаточно иметь PC с DOS или Windows (частая ситуация в университетских

сетях)

Поскольку TCP/IP-трафик, как правило, не шифруется (мы рассмотрим исключения

ниже), крэкер, используя соответствующий инструментарий, может перехватывать

TCP/IP-пакеты, например, telnet-сессий и извлекать из них имена пользователей

и их пароли.

Следует заметить, что данный тип атаки невозможно отследить, не обладая

доступом к системе крэкера, поскольку сетевой поток не изменяется.

Единственная надежная защита от подслушивания -- шифрование TCP/IP-потока

(например, secure shell – защищенная оболочка) или использование одноразовых

паролей (например, S/KEY)

Другое вариант решения - использование интеллектуальных свитчей и UTP, в

результате чего каждая машина получает только тот трафик, что адресован ей.

У каждой палки два конца. Естественно, подслушивание может быть и полезно.

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

администраторам в анализе работы сети (ее загруженности, работоспособности и

т.д.). Один из ярких примеров - общеизвестный tcpdump

6.2 Активные атаки на уровне TCP

При данном типе атак крэкер взаимодействует с получателем информации,

отправителем и/или промежуточными системами, возможно, модифицируя и/или

фильтруя содержимое TCP/IP-пакетов. Данные типы атак часто кажутся технически

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

реализовать соотвествующий инструментарий. К сожалению, сейчас такие

программы стали доступны широким массам пользователей (например, см. SYN-

затопление).

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

предпринимает определенные шаги для перехвата и модификации сетевого потока

или попыток "притвориться" другой системой. Во втором случае протокол TCP/IP

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

Обладая достаточными привилегиями в Unix (или попросту используя DOS или

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

формировать IP-пакеты и передавать их по сети. Естественно, поля заголовка

пакета могут быть сформированы произвольным образом. Получив такой пакет,

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

содержат пути их прохождения. Конечно, при установке обратного адреса не

совпадающим с текущим IP-адресом, крэкер никогда не получит ответ на

отосланный пакет. Однако, как мы увидим, часто это и не требуется.

Возможность формирования произвольных IP-пакетов является ключевым пунктом

для осуществления активных атак.

6.2.1 Предсказание порядкового номера TCP

Данная атака была описана еще Робертом Моррисом (Robert T. Morris) в A Weakness

in the 4.2BSD Unix TCP/IP Software. Англоязычный термин - IP-spoofing

[19]. В данном случае цель крэкера - притвориться другой системой, которой,

например, "доверяет" система-жертва (в случае использования протокола

rlogin/rsh для беспарольного входа). Метод также используется для других целей

- например, для использования SMTP жертвы для посылки поддельных писем.

Описание

Вспомним, что установка TCP-соединения происходит в три стадии (3-way

handshake): клиент выбирает и передает серверу порядковый номер (назовем его

C-SYN), в ответ на это сервер высылает клиенту пакет данных, содержащий

подтверждение (C-ACK) и собственный порядковый номер сервера (S-SYN). Теперь

уже клиент должен выслать подтверждение (S-ACK). Схематично это можно

представить так:

Рис.5. Установка TCP-соединения

После этого соединение считается установленным и начинается обмен данными.

При этом каждый пакет имеет в заголовке поле для порядкового номера и номера

подтверждения. Данные числа увеличиваются при обмене данными и позволяют

контролировать корректность передачи.

Предположим, что крэкер может предсказать, какой порядковый номер (S-SYN по

схеме) будет выслан сервером. Это возможно сделать на основе знаний о

конкретной реализации TCP/IP. Например, в 4.3BSD значение порядкового номера,

которое будет использовано при установке следующего значения, каждую секунду

увеличивается на 125000. Таким образом, послав один пакет серверу, крэкер

получит ответ и сможет (возможно, с нескольких попыткок и с поправкой на

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

Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13