https://bugtraq.ru/library/books/attack/chapter07/04.html

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

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

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

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

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

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

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

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

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

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

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

[16789]