Использование нестойких алгоритмов идентификации объектов при создании виртуального канала
Взаимодействие объектов без установления виртуального канала
Одним из важнейших вопросов, на который необходимо ответить, говоря об идентификации/аутентификации объектов/субъектов РВС, является вопрос о видах взаимодействия между субъектами и объектами в распределенной ВС. Как отмечалось в п. 3.2.2, взаимодействие между субъектами и объектами РВС бывает двух видов:
· с использованием виртуального канала,
· без использования виртуального канала.
Практика показывает, что 99% взаимодействия между объектами в сети Internet проходит с установлением ВК (при любом FTP-, TELNET-, HTTP- и т. п. подключении используется протокол TCP, а, следовательно, создается ВК). Это происходит из-за того, что взаимодействие по виртуальному каналу является единственным динамическим способом защиты сетевого соединения объектов РВС. Дело в том, что в процессе создания ВК объекты РВС обмениваются динамически вырабатываемой ключевой информацией, позволяющей уникально идентифицировать канал.
|
|
Но ошибочно считать распределенную вычислительную систему безопасной, даже если все взаимодействие объектов происходит с созданием ВК.
Ошибочно считать взаимодействие объектов по виртуальному каналу в распределенной ВС панацеей от всех проблем, связанных с идентификацией объектов РВС. ВК является необходимым, но не достаточным условием безопасного взаимодействия. Чрезвычайно важным в данном случае становится выбор алгоритма идентификации при создании ВК. Основное требование, которое следует предъявлять к данным алгоритмам, состоит в следующем: перехват ключевой информации, которой обмениваются объекты РВС при создании ВК не должен позволить атакующему получить итоговые идентификаторы канала и объектов. Создание виртуального канала с использованием нестойкого алгоритма идентификации не позволяет надежно обезопасить РВС от подмены объектов взаимодействия и выступает одной из причин успеха удаленных атак на распределенные вычислительные системы.
Объекты распределенной ВС, взаимодействующие по виртуальным каналам, могут подвергаться типовой УА "Отказ в обслуживании". Особенность этой атаки состоит в том, что, действуя абсолютно легальными средствами системы, можно удаленно добиться нарушения ее работоспособности. Напомним, что, данная УА реализуется передачей множественных запросов на создание соединения (виртуального канала), в результате чего либо переполняется число возможных соединений, либо система, занятая обработкой ответов на запросы, вообще перестает функционировать. В чем причина успеха данной УА? В предыдущем пункте было показано, что взаимодействие объектов РВС по виртуальным каналам позволяет единственным способом обеспечить защиту соединения в глобальной сети. Однако в использовании ВК есть как несомненные плюсы, так и очевидные минусы. К минусам относится необходимость контроля над соединением. При этом задача контроля распадается на две подзадачи:
|
|
· контроль за созданием соединения;
· контроль за использованием соединения.
Если вторая задача решается довольно просто (обычно соединение разрывается по тайм-ауту, определенному системой - так сделано во всех известных сетевых ОС), то решение задачи контроля за созданием соединения представляется нетривиальным. Именно отсутствие приемлемого решения этой задачи является основной причиной успеха типовой УА "Отказ в обслуживании". Сложность контроля над созданием ВК состоит в том, что в системе, в которой отсутствует статическая ключевая информация о всех ее объектах, невозможно отделить ложные запросы на создание соединения от настоящих. Очевидно также, что если один субъект сетевого взаимодействия будет иметь возможность анонимно занимать неограниченное число каналов связи с удаленным объектом, то подобная система может быть полностью парализована данным субъектом. Поэтому, если любой объект в распределенной системе может анонимно послать сообщение от имени любого другого объекта (например, в Internet маршрутизаторы не проверяют IP-адрес источника отправления), то в подобной распределенной ВС в принципе невозможен контроль за созданием виртуальных соединений. Поэтому основная причина, по которой возможна типовая УА "Отказ в обслуживании" и ей подобные - это отсутствие в РВС возможности контроля за маршрутом сообщений.