Атака на Internet

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

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

Другой вариант решения – создать в заголовке пакета специальные поля, куда каждый маршрутизатор, через который проходит пакет, заносит маршрутную информацию (например, часть своего IP-адреса). При этом первый маршрутизатор, на который поступил пакет, заносит также информацию о классе сети (A, B, C), откуда пришел пакет. Тем не менее внесение в пакет адресов всех пройденных маршрутизаторов будет неоптимальным решением, так как сложно заранее определить максимальный размер заголовка пакета, и это может серьезно увеличить размер передаваемого пакета.

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

Из всего вышесказанного следует принцип защищенного взаимодействия объектов РВС.

...

В распределенной ВС на сетевом уровне необходимо обеспечить контроль за маршрутом сообщений для аутентификации адреса отправителя.

Контроль за виртуальными соединениями

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

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

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

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

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