5. По расположению субъекта атаки относительно атакуемого объекта

· внутрисегментное (класс 5.1)

· межсегментное (класс 5.2)

Рассмотрим ряд определений:

Субъект атаки (или источник атаки) - это атакующая программа или оператор, непосредственно осуществляющие воздействие.

Хост (host) - сетевой компьютер.

Маршрутизатор (router) - устройство, обеспечивающее маршрутизацию пакетов обмена в глобальной сети.

Подсеть (subnetwork) (в терминологии Internet) - совокупность хостов, являющихся частью глобальной сети, для которых маршрутизатором выделен одинаковый номер подсети. Подсеть - логическое объединение хостов маршрутизатором. Хосты внутри одной подсети могут взаимодействовать между собой непосредственно, минуя маршрутизатор.

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

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

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

6. По уровню эталонной модели ISO/OSI, на котором осуществляется воздействие

· физический (класс 6.1)

· канальный (класс 6.2)

· сетевой (класс 6.3)

· транспортный (класс 6.4)

· сеансовый (класс 6.5)

· представительный (класс 6.6)

· прикладной (класс 6.7)

Международная Организация по Стандартизации (ISO) приняла стандарт ISO 7498, описывающий взаимодействие открытых систем (OSI). Распределенные ВС также являются открытыми системами. Любой сетевой протокол обмена, как и любую сетевую программу, можно с той или иной степенью точности спроецировать на эталонную семиуровневую модель OSI. Такая многоуровневая проекция позволит описать в терминах модели OSI функции, заложенные в сетевой протокол или программу. Удаленная атака также является сетевой программой. В связи с этим представляется логичным рассматривать удаленные атаки на распределенные ВС, проецируя их на эталонную модель ISO/OSI.

Методы защиты от атак из сети

Как защититься от ложного ARP-сервера?

В том случае, если у сетевой ОС отсутствует информация о соответствии IP- и Ethernet-адресов хостов внутри одного сегмента IP-сети, данный протокол позволяет посылать широковещательный ARP-запрос на поиск необходимого Ethernet-адреса, на который атакующий может прислать ложный ответ, и, в дальнейшем, весь трафик на канальном уровне окажется перехваченным атакующим и пройдет через ложный ARP-сервер. Очевидно, что для ликвидации данной атаки необходимо устранить причину, по которой возможно ее осуществление. Основная причина успеха данной удаленной атаки - отсутствие необходимой информации у ОС каждого хоста о соответствующих IP- и Ethernet-адресах всех остальных хостов внутри данного сегмента сети. Таким образом, самым простым решением будет создание сетевым администратором статической ARP-таблицы в виде файла (в ОС UNIX обычно /etc/ethers), куда необходимо внести соответствующую информацию об адресах. Данный файл устанавливается на каждый хост внутри сегмента, и, следовательно, у сетевой ОС отпадает необходимость в использовании удаленного ARP-поиска. Правда, отметим, что ОС Windows '95 это не помогает.

Как защититься от ложного DNS-сервера?

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

Как администратору сети защититься от ложного DNS-сервера?

Если отвечать на этот вопрос коротко, то никак. Ни административно, ни программно нельзя защититься от атаки на существующую версию службы DNS. Оптимальным с точки зрения безопасности решением будет вообще отказаться от использования службы DNS в вашем защищенном сегменте! Конечно, совсем отказаться от использования имен при обращении к хостам для пользователей будет очень не удобно. Поэтому можно предложить следующее компромиссное решение: использовать имена, но отказаться от механизма удаленного DNS-поиска. Вы правильно догадались, что это возвращение к схеме, использовавшейся до появления службы DNS с выделенными DNS-серверами. Тогда на каждой машине в сети существовал hosts файл, в котором находилась информация о соответствующих именах и IP-адресах всех хостов в сети. Очевидно, что на сегодняшний день администратору можно внести в подобный файл информацию о лишь наиболее часто посещаемых пользователями данного сегмента серверах сети. Поэтому использование на практике данного решения чрезвычайно затруднено и, видимо, нереально (что, например, делать с броузерами, которые используют URL с именами?). Для затруднения осуществления данной удаленной атаки можно предложить администраторам использовать для службы DNS вместо протокола UDP, который устанавливается по умолчанию, протокол TCP (хотя из документации далеко не очевидно, как его сменить). Это существенно затруднит для атакующего передачу на хост ложного DNS-ответа без приема DNS-запроса.

Общий неутешительный вывод таков: в сети Internet при использовании существующей версии службы DNS не существует приемлемого решения для защиты от ложного DNS-сервера (и не откажешься, как в случае с ARP, и использовать опасно)!

Как администратору DNS-сервера защититься от ложного DNS-сервера?

Если отвечать на этот вопрос коротко, то, опять же, никак. Единственным способом затруднить осуществление данной удаленной атаки, это использовать для общения с хостами и с другими DNS-серверами только протокол TCP, а не UDP. Тем не менее, это только затруднит выполнение атаки - не забывайте как про возможный перехват DNS-запроса, так и про возможность математического предсказания начального значения TCP-идентификатора ISN.

В заключение можно порекомендовать для всей сети Internet поскорее перейти либо к новой более защищенной версии службы DNS, либо принять единый стандарт на защищенный протокол. Сделать этот переход, несмотря на все колоссальные расходы, просто необходимо, иначе сеть Internet может быть просто поставлена на колени перед всевозрастающими успешными попытками нарушения ее безопасности при помощи данной службы!