BugTraq.Ru
Русский BugTraq
https://bugtraq.ru/library/books/attack/chapter06/01.html

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

Причины успеха угроз безопасности РВС

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

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

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

Отсутствие выделенного канала связи

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

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

Недостаточные идентификация и аутентификация

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

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

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

Практика показывает, что 99% взаимодействий между объектами в сети Internet проходит с установлением такого канала (при любом FTP-, TELNET-, HTTP- и т. п. подключении используется протокол TCP, а следовательно, создается ВК). Это происходит потому, что взаимодействие по виртуальному каналу является единственным динамическим способом защиты сетевого соединения объектов РВС: в процессе создания ВК объекты РВС обмениваются динамически вырабатываемой ключевой информацией, позволяющей уникально идентифицировать канал. В противном случае для распознавания объектов распределенной системы пришлось бы использовать массив статической идентификационной информации, уникальный для каждого объекта. А это означает, что мы получаем стандартную проблему статического распределения ключей (матрица NxN), которая решается только на ограниченном подмножестве объектов, но не в Internet.

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

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

Использование нестойких алгоритмов идентификации

К сожалению, взаимодействие объектов по виртуальному каналу в распределенной ВС не является панацеей от всех проблем, связанных с идентификацией объектов РВС. ВК - необходимое, но не достаточное условие безопасного взаимодействия. Чрезвычайно важным в данном случае становится выбор алгоритма идентификации при создании виртуального канала. Основное требование, предъявляемое к этим алгоритмам, состоит в следующем: перехват ключевой информации, которой обмениваются объекты РВС при создании ВК, не должен позволить атакующему получить итоговые идентификаторы канала и объектов (см. раздел "Причины успеха удаленных атак в сети Internet"). Однако в базовых алгоритмах идентификации, используемых при создании ВК в большинстве существующих сетевых ОС, это требование практически не учитывается. Так, например, в ОС Novell NetWare 3.12-4.1 идентификатор канала - число в диапазоне O-FFh, идентификатор объекта (рабочей станции или файл-сервера) - также число от 0 до FFh; в протоколе TCP идентификаторами канала и объектов являются два 32-битных числа, формируемых в процессе создания ТСР-сосдинения (см. раздел "Подмена одного из субъектов TCP-соединения в сети Internet").

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

Отсутствие контроля за виртуальными каналами связи

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[19922]



  Copyright © 2001-2024 Dmitry Leonov Design: Vadim Derkach