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

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

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

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

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

 Напомним, что при создании ВК полученный системой запрос на создание соединения ставится в очередь запросов, и, когда до него дойдет время, система выработает ответ на запрос и отошлет его обратно отправителю запроса. Задача контроля за созданием соединения заключается как раз в том, чтобы определить те правила, исходя из которых система могла бы либо поставить запрос в очередь, либо нет.

  Если все пришедшие запросы автоматически ставятся системой в очередь (так построены все сетевые ОС, поддерживающие протокол TCP/IP), то это в случае атаки ведет к переполнению очереди и к отказу в обслуживании всех остальных легальных запросов.

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

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

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

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

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

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

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

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

 Итак, в завершение очередное требование к защищенным системам связи в распределенных ВС.