1. Контроль за созданием соединения.

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

Решение второй задачи лежит на поверхности: так как сетевая операционная система не может одновременно иметь бесконечное число открытых ВК, то в случае, если ВК простаивает в течение определенного системой тайм-аута, происходит закрытие соединения. Выбор тайм-аута очистки очереди зависит от ряда параметров (подробнее об этом см. в главе 4).

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

Основная задача, которую необходимо решить в данном случае, состоит в том, чтобы не позволить одному субъекту взаимодействия занять все виртуальные каналы системы. Напомним, что при создании ВК полученный системой запрос на создание соединения ставится в очередь запросов, и когда до него дойдет время, система выдаст ответ и отошлет его отправителю. Задача контроля за созданием соединения заключается как раз в том, чтобы определить те правила, исходя из которых, система могла бы либо поставить запрос в очередь, либо нет. Если все пришедшие запросы автоматически ставятся системой в очередь, при условии, что она не заполнена (так построены сетевые ОС, поддерживающие протокол TCP/ IP), то в случае атаки это приведет к переполнению очереди и к отказу в обслуживании всех остальных легальных запросов из-за того, что атакующий посылает в секунду столько запросов, сколько позволяет трафик (тысячи запросов в секунду), а обычный пользователь с легальным запросом на подключение может послать лишь несколько запросов в минуту. Следовательно, вероятность подключения легального пользователя в такой ситуации, при условии переполнения очереди, – в лучшем случае один к миллиону. Поэтому необходимо ввести ограничения на постановку в очередь запросов от одного объекта. Однако если в РВС любой объект системы может послать запрос от имени (с адреса) другого объекта системы, то, как отмечалось ранее, решить задачу контроля за созданием соединения нельзя. Чтобы обеспечить такую возможность, вводится правило, исходя из которого, в каждом пришедшем на объект пакете должен быть указан пройденный им маршрут, позволяющий с точностью до подсети подтвердить подлинность адреса отправителя, что даст возможность отсеять все пакеты с неверным адресом отправителя. Учитывая это, можно предложить следующее условие постановки запроса в очередь: в системе вводится ограничение на число обрабатываемых в секунду запросов из одной подсети.

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

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

В завершение – об очередном требовании защищенного взаимодействия объектов РВС.

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

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

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

Однако в РВС с неопределенным и достаточно большим числом объектов (например, Internet) спроектировать систему с отсутствием неопределенности практически нельзя. В этом случае отказаться от алгоритмов удаленного поиска не представляется возможным.

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

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