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

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

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

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

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

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

5.1.2. Недостаточная идентификация и аутентификация объектов и субъектов РВС

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

• выдача себя за определенный объект или субъект с присвоением его прав и полномочий для доступа в систему (например, см. п. 3.2.2 - типовая УА "Подмена доверенного субъекта или объекта РВС" );
• внедрение в систему ложного объекта, выдающего себя за доверенный объект системы (например, см. п. 3.2.3 - типовая УА "Ложный объект РВС" ).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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