Удаленные атаки в сети Internet.

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

ОСНОВЫ DNS

Как известно, для обращения к хостам в сети Internet используются 32-разрядные IP-адреса, однозначно идентифицирующие любой сетевой компьютер в этой глобальной сети. Однако для пользователей применение IP-адресов при обращении к хостам не слишком удобно. Поэтому в Internet принято присваивать имена всем компьютерам в Сети. Использование имен дает пользователю возможность лучше ориентироваться в киберпространстве Internet - куда проще запомнить, например, имя www.ferrari.it, чем четырехзвенную цепочку IP-адреса. Применение в Internet мнемонически понятных для пользователей имен породило проблему их преобразования в IP-адреса. Такое преобразование необходимо, так как на сетевом уровне адресация пакетов осуществляется не по именам, а по IP-адресам, следовательно, для непосредственной адресации сообщений в Internet имена не годятся. На раннем этапе развития Internet, когда в сеть (тогда она еще не называлась Сеть) было объединено небольшое количество компьютеров, Информационный центр сети (Network Information Center, NIC) для решения проблемы преобразования имен в адреса завел специальный файл (файл hosts), в который вносились имена и соответствующие им IP-адреса всех хостов в сети. Данный файл регулярно обновлялся и распространялся по всей сети. Но по мере развития Internet число хостов, объединенных в сеть, увеличивалось, и данная схема становилась все менее и менее работоспособной. Поэтому была создана новая система преобразования имен, позволяющая пользователю в случае отсутствия у него информации о соответствии имен и IP-адресов получить необходимые сведения от ближайшего информационно-поискового сервера (DNS-сервера). Эта система получила название системы имен доменов - DNS (Domain Name System). Для реализации системы DNS был создан специальный сетевой протокол DNS; кроме того, в сети создавались специальные выделенные информационно-поисковые серверы - DNS-серверы. Поясним основную задачу, решаемую службой DNS. В современной Сети хост при обращении к удаленному серверу обычно осведомлен только об его имени и не знает IP-адреса, который необходим для непосредственной адресации. Следовательно, перед хостом возникает стандартная проблема удаленного поиска: по имени удаленного хоста найти его IP-адрес. Решением этой проблемы и занимается служба DNS на базе протокола DNS. Рассмотрим DNS-алгоритм удаленного поиска IP-адреса по имени в Сети: хост посылает на IP-адрес DNS-сервера своего домена (он задается при настpойке пpотокола IP в сетевой ОС) DNS-запрос, в котором указывает имя сервера, IP-адрес которого необходимо найти; DNS-сервер, получив запрос, просматривает свою базу имен на наличие в ней содержащегося в запросе имени. В случае, если имя найдено, а следовательно, найден и соответствующий ему IP-адрес, на запросивший хост DNS-сервер отправляет DNS-ответ, в котором записан искомый IP-адрес. Если указанное в запросе имя DNS-сервер не обнаружил в своей базе имен, то DNS-запрос отсылается DNS-сервером на один из корневых DNS-серверов, адреса которых содержатся в файле настроек DNS-сервера root.cache, и описанная в этом пункте процедура повторяется, пока имя не будет найдено (или не найдено). Анализируя с точки зрения безопасности уязвимость этой схемы удаленного поиска с помощью протокола DNS, можно сделать вывод о возможности осуществления в сети, использующей протокол DNS, типовой удаленной атаки "Ложный объект РВС (распределенной вычислительной системы)". С помощью такой атаки удается внедpить пpомежуточный хост, чеpез котоpый будет идти поток инфоpмации между атакуемым объектом и сеpвеpом (напpимеp, Telnet-сеpвеpом). Практические изыскания и критический анализ безопасности службы DNS позволяют предположить, что существует три возможных варианта удаленной атаки на эту службу.

В данном случае удаленная атака связана с перехватом поискового DNS-запроса. Перед тем как рассмотреть алгоритм атаки на службу DNS, необходимо обратить внимание на некоторые тонкости в работе этой службы. Во-первых, по умолчанию служба DNS функционирует на базе протокола UDP (хотя возможно и использование протокола TCP), что, естественно, делает ее менее защищенной, так как протокол UDP, в отличие от TCP, вообще не предусматривает средств идентификации сообщений. Для того чтобы перейти от UDP к TCP, администратору DNS-сервера придется очень серьезно изучить документацию (в стандартной документации на демон named в ОС Linux нет никакого упоминания о возможном выборе протокола (UDP или TCP), с которым будет работать DNS-сервер). Кроме того, этот переход несколько снизит скорость работы системы, так как при использовании TCP требуется создание виртуального соединения, а конечные сетевые ОС вначале посылают DNS-запрос с помощью протокола UDP. В том случае, если им придет специальный ответ от DNS-сервера, сетевая ОС посылает DNS-запрос с использованием TCP. Во-вторых, необходимо обратить внимание на то, что значение поля "порт отправителя" в UDP-пакете вначале принимается равным 1023, а затем увеличивается с каждым переданным DNS-запросом. В-третьих, в случае передачи DNS-запроса с хоста значение идентификатора (ID) DNS-запроса зависит от конкретного сетевого приложения, генерирующего DNS-запрос. Автор статьи на своем опыте убедился, что в случае передачи запроса из оболочки командного интерпретатора (SHELL) операционных систем Linux и Windows 95 (например, ftp nic.funet.fi) это значение всегда равно единице. Если же DNS-запрос передается из Netscape Navigator, то браузер с каждым новым запросом увеличивает это значение на единицу. Если же запрос передается непосредственно DNS-сервером, то сервер увеличивает значение идентификатора на единицу с каждым вновь передаваемым запросом. Все эти тонкости имеют значение в случае атаки без перехвата DNS-запроса. Для реализации атаки путем перехвата DNS-запроса атакующему необходимо перехватить DNS-запрос, путем перепрограммирования сетевого адаптера для приема всех передаваемых по каналу пакетов извлечь из него номер UDP-порта отправителя запроса, двухбайтовое значение ID идентификатора DNS-запроса и искомое имя и затем послать ложный DNS-ответ на указанный в DNS-запросе UDP-порт, в котором указать в качестве искомого IP-адреса IP-адрес ложного DNS-сервера. Это позволит в дальнейшем полностью перехватить и активно воздействовать по схеме "Ложный объект РВС" на трафик между "обманутым" хостом и сервером. Простейшим вариантом атаки с использованием ложного DNS-сервера будет выдача себя за доверенный объект (сервер) с последующим присвоением прав и полномочий пользователя. Это может быть достигнуто путем передачи на клиентский хост приглашения, идентичного приглашению реального сервера. Пользователь вводит свое имя (это может быть и имя администpатоpа системы), а затем - паpоль. Ложный сервер, перехватив данную информацию, выводит какую-либо фиктивную ошибку (например, неправильный пароль) и отсоединяется. Все, "настоящий" сеpвеp уже на кpючке. Рассмотрим обобщенную схему работы ложного DNS-сервера. Функциональная схема ложного DNS-сервера:
а) фаза ожидания атакующим DNS-запроса (он находится либо на ЛС1, либо на ЛС2);
б) фаза передачи атакующим ложного DNS-ответа;
в) фаза приема, анализа, воздействия и передачи перехваченной информации на ложном сервере.ожидание DNS-запроса; при получении DNS-запроса, извлечение из него необходимых сведений и передача по сети на запросивший хост ложного DNS-ответа, от имени (якобы с IP-адреса) настоящего DNS-сервера, в котором указывается IP-адрес ложного DNS-сервера; в случае получения пакета от хоста, изменение в IP-заголовке пакета его IP-адреса на IP-адрес ложного DNS-сервера и передача пакета на сервер (т. е. ложный DNS-сервер ведет работу с сервером от имени хоста); в случае получения пакета от сервера, изменение в IP-заголовке пакета его IP-адреса на IP-адрес ложного DNS-сервера и передача пакета на хост (для хоста ложный DNS-сервер и есть настоящий сервер). В том случае, хотя это и мало вероятно, если ответ от настоящего DNS-сервера придет быстрее ложного ответа от атакующего, то атака не состоится. Необходимым условием осуществления данного варианта атаки является перехват DNS-запроса. Это возможно только в том случае, если атакующий находится либо на пути основного трафика, либо в сегменте настоящего DNS-сервера. Выполнение одного из этих условий делает подобную удаленную атаку трудно осуществимой на практике (попасть в сегмент DNS-сервера, и тем более в межсегментный канал связи, атакующему скорее всего не удастся). Однако в этом случае есть возможность осуществить межсегментную удаленную атаку на Internet. Отметим, что моделирование данной удаленной атаки выявило ряд интересных особенностей в работе протокола FTP и в механизме идентификации TCP-пакетов. В случае, если FTP-клиент на хосте подключался к удаленному FTP-серверу через ложный DNS-сервер, оказывалось, что каждый раз после выдачи пользователем прикладной команды FTP (например, ls, get, put и т. д.) FTP-клиент вырабатывал команду PORT, которая состояла в передаче на FTP-сервер в поле данных TCP-пакета номера порта и IP-адреса клиентского хоста. (Не так-то просто понять, зачем каждый раз передавать на FTP-сервер IP-адрес клиента!) Это приводило к тому, что если на ложном DNS-сервере не изменить IP-адрес, содержащийся в поле данных TCP-пакета, и этот пакет на FTP-сервер передать по обыкновенной схеме, то следующий пакет пересылается FTP-сервером на хост FTP-клиента, минуя ложный DNS-сервер, и, что самое интересное, этот пакет воспринимается как нормальный. В дальнейшем ложный DNS-сервер теряет контроль над трафиком между FTP-сервером и FTP-клиентом! Это связано с тем, что обычный FTP-сервер не предусматривает никакой дополнительной идентификации FTP-клиента, помимо начальной с использованием имени и пароля, а перекладывает все проблемы идентификации пакетов и соединения на более низкий уровень - а именно TCP (транспортный).

Другой вариант проведения удаленной атаки, направленной на службу DNS, основан на второй разновидности типовой УА "Ложный объект РВС". В этом случае атакующий осуществляет постоянную передачу на атакуемый хост заранее подготовленного ложного DNS-ответа от имени настоящего DNS-сервера без приема DNS-запроса! Другими словами, атакующий создает в сети Internet направленный "шторм" ложных DNS-ответов. Это возможно, так как обычно для передачи DNS-запроса используется протокол UDP, в котором отсутствуют средства идентификации пакетов. Критерии, предъявляемые сетевой ОС хоста к полученному от DNS-сервера ответу, - это, во-первых, совпадение IP-адреса отправителя ответа с IP-адресом DNS-сервера; во-вторых, необходимо, чтобы в DNS-ответе было указано то же имя, что и в DNS-запросе; в-третьих, DNS-ответ должен быть направлен на тот же UDP-порт, с которого был послан DNS-запрос (это первое реальное затруднение для атакующего), и, в-четвертых, в DNS-ответе поле идентификатор запроса в заголовке DNS (ID) должно содержать то же значение, что и в переданном DNS-запросе (это вторая проблема). Так как атакующий не имеет возможности перехватить DNS-запрос, основное препятствие для него представляет номер UDP-порта, с которого был послан запрос. Однако, как было отмечено ранее, номер порта отправителя принимает ограниченный набор значений (1023), и атакующему достаточно действовать простым перебором, направляя ложные ответы на соответствующий перечень портов. На первый взгляд второй проблемой может быть двухбайтовый идентификатор DNS-запроса, но, как подчеркивалось ранее, он либо равен единице, либо в случае DNS-запроса (от Netscape Navigator, например) имеет значение порядка единицы (каждый запрос ID увеличивается на 1). Поэтому для осуществления данной удаленной атаки атакующему необходимо выбрать интересующий его хост (скажем, TOP.SECRET.COM), маршрут к которому требуется изменить так, чтобы он проходил через ложный сервер (хост) атакующего. Это достигается постоянной передачей (направленным "штормом") атакующим ложных DNS-ответов на атакуемый хост от имени настоящего DNS-сервера на предполагаемые UDP-порты. В этих ложных DNS-ответах указывается в качестве IP-адреса хоста TOP.SECRET.COM IP-адрес атакующего. Далее атака развивается по следующей схеме. Как только цель атаки (атакуемый хост) обратится по имени к хосту TOP.SECRET.COM, то от данного хоста в сеть будет передан DNS-запрос. Атакующий его никогда не получит, это, однако, и не требуется, так как на хост сразу же поступит постоянно передаваемый ложный DNS-ответ, который и будет воспринят ОС атакуемого хоста как настоящий ответ от DNS-сервера. Все! Атака состоялась, и теперь атакуемый хост будет передавать все пакеты, предназначенные для TOP.SECRET.COM, на IP-адрес хоста атакующего, который, в свою очередь, станет переправлять их на TOP.SECRET.COM, воздействуя на перехваченную информацию по схеме "Ложный объект РВС". Рассмотрим функциональную схему предложенной удаленной атаки на службу DNS . Внедрение в Internet ложного сервера путем создания направленного "шторма" ложных DNS-ответов на атакуемый хост: а) атакующий создает направленный "шторм" ложных DNS-ответов на Хост 1; б) Хост 1 посылает DNS-запрос и немедленно получает ложный DNS-ответ; в) фаза приема, воздействия и передачи перехваченной информации на ложном сервере. постоянная передача атакующим ложных DNS-ответов на атакуемый хост на различные UDP-порты и, возможно, с разными ID от имени (IP-адреса) настоящего DNS-сервера с указанием имени интересующего хоста и его ложного IP-адреса, которым будет являться IP-адрес ложного сервера (хоста) атакующего; в случае получения пакета от хоста, изменение в IP-заголовке пакета его IP-адреса на IP-адрес атакующего и передача пакета на сервер (т. е. ложный сервер ведет работу с настоящим сервером от имени хоста - со своего IP-адреса); в случае получения пакета от сервера, изменение в IP-заголовке пакета его IP-адреса на IP-адрес ложного сервера и передача пакета на хост (для хоста ложный сервер и есть настоящий). Таким образом, реализация данной удаленной атаки, использующей пробелы в безопасности службы DNS, позволяет из любой точки Сети нарушить маршрутизацию между двумя заданными объектами (хостами)! Т. е. данная удаленная атака осуществляется межсегментно по отношению к цели атаки и угрожает безопасности любого хоста Internet, использующего обычную службу DNS.

Из рассмотренной ранее схемы удаленного DNS-поиска следует, что в том случае, если указанное в запросе имя DNS-сервер не обнаружил в своей базе имен, то запрос отсылается сервером на один из корневых DNS-серверов, адреса которых содержатся в файле настроек сервера root.cache. Т. е. в том случае, если DNS-сервер не имеет сведений о запрашиваемом хосте, он пересылает запрос далее - это значит, что теперь сам DNS-сервер является инициатором удаленного DNS-поиска. Поэтому ничто не мешает атакующему, действуя описанными выше методами, перенести свой удар непосредственно на DNS-сервер. Иначе говоря, в качестве цели атаки теперь будет выступать не хост, а DNS-сервер и ложные DNS-ответы будут направляться атакующим от имени корневого DNS-сервера на атакуемый DNS-сервер. При этом важно учитывать следующую особенность работы DNS-сервера. Для ускорения работы каждый DNS-сервер кэширует в области памяти свою таблицу соответствия имен и IP-адресов хостов. В том числе в кэш заносится динамически изменяемая информация об именах и IP-адресах хостов, найденных в процессе функционирования DNS-сервера. Т. е. если DNS-сервер, получив запрос, не находит у себя в кэш-таблице соответствующей записи, он пересылает ответ на следующий сервер и, получив ответ, заносит найденные сведения в кэш-таблицу. Таким образом, при получении следующего запроса DNS-серверу уже не требуется вести удаленный поиск, так как необходимая информация уже находится у него в памяти.  Внедрение в Internet ложного сервера путем перехвата DNS-запроса от DNS-сервера: а) фаза ожидания атакующим DNS-запроса от DNS-сервера (для ускорения атакующий генерирует необходимый DNS-запрос); б) фаза передачи атакующим ложного DNS-ответа на DNS-сервер 1; в) кэш-таблица DNS-сервера содержит информацию о соответствии имени TOP.SECRET.COM IP-адресу хоста атакующего. Из анализа только что описанной схемы удаленного DNS-поиска становится очевидно, что в том случае если в ответ на запрос от DNS-сервера атакующий направит ложный DNS-ответ (или в случае "шторма" ложных ответов будет вести их постоянную передачу), то в кэш-таблице сервера появится соответствующая запись с ложными сведениями, и в дальнейшем все хосты, обратившиеся к данному DNS-серверу, будут дезинформированы, и при обращении к хосту, маршрут к которому атакующий решил изменить, связь с ним будет осуществляться через хост атакующего по схеме "Ложный объект РВС"! И, что хуже всего, с течением времени эта ложная информация, попавшая в кэш DNS-сервера, будет распространяться на соседние DNS-серверы высших уровней, а следовательно, все больше хостов в Internet окажутся дезинформированы и атакованы! Очевидно, что в том случае, если атакующий не может перехватить DNS-запрос от DNS-сервера, для реализации атаки ему необходим "шторм" ложных DNS-ответов, направленный на DNS-сервер. При этом возникает следующая основная загвоздка, отличная от проблемы подбора портов в случае атаки, направленной на хост. Как уже отмечалось ранее, DNS-сервер, посылая запрос на другой DNS-сервер, идентифицирует этот запрос двухбайтовым значением (ID). Это значение увеличивается на единицу с каждым передаваемым запросом. Атакующему узнать это текущее значение идентификатора DNS-запроса не представляется возможным. Поэтому, помимо перебора 216 возможных значений ID, предложить что-либо достаточно сложно. Зато отпадает проблема перебора портов, так как все DNS-запросы передаются DNS-сервером на 53 порт.  Внедрение в Internet ложного сервера путем создания направленного "шторма" ложных DNS-ответов на атакуемый DNS-сервер: а) атакующий создает направленный "шторм" ложных DNS-ответов от имени одного из корневых DNS-серверов и при этом провоцирует атакуемый DNS-сервер, посылая DNS-запрос; б) DNS-сервер передает DNS-запрос на primary DNS-сервер и немедленно получает ложный DNS-ответ от атакующего; в) кэш-таблица DNS-сервера содержит информацию о соответствии имени TOP.SECRET.COM IP-адресу хоста атакующего. Есть еще одно условие осуществления этой удаленной атаки на DNS-сервер при направленном "шторме" ложных DNS-ответов: дело в том, что атака будет иметь успех, только если DNS-сервер пошлет запрос на поиск определенного имени (которое содержится в ложном DNS-ответе). DNS-сервер посылает этот столь необходимый и желанный для атакующего запрос в том случае, если на него придет DNS-запрос от какого-либо хоста на поиск данного имени, и этого имени не окажется в кэш-таблице DNS-сервера. В принципе этот запрос может прийти когда угодно, и атакующему вполне вероятно придется ждать результатов атаки сколь угодно долго. Однако ничто не мешает атакующему, не дожидаясь никого, самому послать на атакуемый DNS-сервер подобный DNS-запрос и спровоцировать DNS-сервер на поиск указанного в запросе имени! Тогда эта атака с большой вероятностью будет иметь успех практически сразу же после начала ее осуществления! Для примера вспомним недавний скандал (28 октября 1996 года), виновником которого оказался один из московских провайдеров Internet - компания РОСНЕТ, когда ее пользователи при обращении к обычному информационному WWW-серверу попадали, как было сказано в телевизионном репортаже, на WWW-сервер "сомнительного" содержания (наверное, www.playboy.com). Поскольку никто так толком и не понял, что же случилось - ни журналисты (их можно извинить, они не специалисты в этом вопросе), ни те, кто проводил пресс-конференцию (специалистов к общению с прессой, наверное, просто не допустили), информационные сообщения о данном событии оказались настолько убоги, что уяснить причины произошедшего оказалось практически невозможно. Однако, возможно, то, что произошло в Москве, вполне укладывается в только что описанную схему удаленной атаки на DNS-сервер. За одним исключением: вместо адреса хоста атакующего в кэш-таблицу DNS-сервера был занесен IP-адрес хоста www.playboy.com. Однако, видимо, в большинстве своем российские кракеры еще не доросли до столь утонченных методов сетевого взлома, как атака на DNS. После того как статья была написана, автору довелось ознакомится с интервью, которое якобы дал кракер, осуществивший этот взлом. Из него следовало, что атакующий использовал одну из известных "дыр" в WWW-сервере РОСНЕТа, что и позволило подменить одну ссылку на другую. Осуществление атак такого типа является по сути тривиальным и не требует от взломщика практически никакой квалификации (подчеркиваю, речь идет об осуществлении атаки, а не о поиске этой "дыры"). Высокая квалификация необходима именно для поиска той самой уязвимой точки, используя которую, можно взломать систему. Но, по глубокому убеждению автора, обнаруживают слабое место и осуществляют на его базе взлом, скорее всего, разные люди, так как именно высокая квалификация специалиста, обнаружившего "дыру", не позволит ему причинить ущерб простым пользователям. (Р. Т. Моррис не был исключением. Просто его червь из-за ошибки в коде вышел из-под контроля, вследствие чего пользователям сети был нанесен определенный ущерб.) В заключение автор хотел бы снова вернуться к службе DNS и отметить, что, как следует из предыдущих пунктов, использование в Сети службы удаленного поиска DNS позволяет атакующему организовать в Internet удаленную атаку на любой хост, пользующийся услугами данной службы, и вполне может пробить серьезную брешь в системе защиты этой и так отнюдь не безопасной глобальной сети. Напомню, что как указывал С. М. Белловин в ставшей почти классической работе "Security Problems in the TCP/IP Protocol Suite": "Комбинация атаки на доменную систему и механизмы маршрутизации могут привести к катастрофе". Хотелось бы еще добавить, что с подробным описанием механизмов реализации основных видов атак в Internet вы сможете ознакомиться в написанной мной в соавторстве с Павлом Семьяновым новой книге "Атака через Internet". Илья Медведовский - эксперт-аналитик по информационной безопасности Санкт-Петербургского Специализированного Центра Защиты Информации. С ним можно связаться по адресу: ilya@blader.com.

Перед тем как рассматривать основные механизмы реализации удаленных атак в Сети, не мешает хотя бы кратко ознакомиться с тем, что такое удаленная атака, какие бывают типы удаленных атак и каковы механизмы их реализации. Итак, удаленной атакой назовем информационное разрушающее воздействие на распределенную вычислительную систему, программно осуществляемое по каналам связи. Практические исследования и анализ информационной безопасности различных сетевых систем, проводимые автором в течение последних лет, наглядно продемонстрировали тот факт, что вне зависимости от используемых сетевых протоколов, топологии и инфраструктуры исследуемых сетей механизмы реализации удаленных воздействий на них абсолютно инвариантны по отношениям к особенностям конкретной системы. Поэтому появилась возможность ввести такое понятие, как типовая удаленная атака - удаленное информационное разрушающее воздействие, программно осуществляемое по каналам связи и характерное для любой распределенной системы. Далее кратко охарактеризуем типовые удаленные атаки и механизмы их реализации. Анализ сетевого трафика Анализ сетевого трафика (или прослушивание канала связи) позволяет, во-первых, изучить логику работы сети, т. е. получить взаимно однозначное соответствие событий, происходящих в системе, и команд, пересылаемых при этом хостами, в момент появления данных событий; во-вторых, дает возможность просто перехватить поток передаваемых данных. Подмена доверенного объекта или субъекта распределенной ВС В случае, если в сети применяются нестойкие алгоритмы идентификации/аутентификации ее объектов (хостов, пользователей и т. д.), не исключена возможность типовой удаленной атаки, которая заключается в передаче по каналам связи сообщений от имени любого объекта или субъекта распределенной системы с соответственным присвоением его прав доступа. Ложный объект распределенной ВС В том случае, если в сети недостаточно надежно решены проблемы идентификации сетевых управляющих устройств, возникающие при их взаимодействии с остальными объектами системы, сеть может подвергнуться типовой удаленной атаке, связанной с изменением маршрутов и внедрением в нее ложного объекта. Если же инфраструктура сети такова, что для взаимодействия хостов необходимо использовать алгоритмы удаленного поиска (например, SAP (NetWare), ARP и DNS (Internet)), это также позволяет внедрить в систему ложный объект. Итак, существуют две принципиально разные причины, обуславливающие появление типовой удаленной атаки "Ложный объект распределенной ВС": внедрение в распределенную систему ложного объекта путем навязывания ложного маршрута за счет использования недостатков алгоритмов маршрутизации; внедрение в распределенную систему ложного объекта путем использования недостатков алгоритмов удаленного поиска. Использование ложного объекта для организации удаленной атаки Так как описанная выше типовая удаленная атака "Ложный объект распределенной ВС" оказывается на редкость типичной для сетей различных типов (Novell NetWare, Internet) и представляет для них серьезную угрозу безопасности, то имеет смысл кратко рассмотреть возможные методы воздействия на перехваченную ложным объектом информацию. Итак, получив возможность контролировать проходящий между объектами поток информации, ложный объект может применять следующие методы воздействия на перехваченную информацию. 1. Селекция и сохранение потока информации. 2. Модификация информации: модификация передаваемых данных; модификация передаваемого кода. 3. Подмена информации. Отказ в обслуживании В случае, если в сети не предусмотрено средств аутентификации адреса отправителя, т. е. инфраструктура сети позволяет с одного хоста передавать на другой атакуемый хост бесконечное число анонимных запросов на подключение от имени других хостов, то будет иметь успех типовая удаленная атака - "Отказ в обслуживании". Результат проведения этой удаленной атаки - нарушение на атакованном хосте работоспособности соответствующей службы предоставления удаленного доступа. Вторая разновидность этой типовой удаленной атаки заключается в передаче с одного адреса такого количества запросов на подключение к атакуемому хосту, какое может "вместить" трафик (направленный "шторм" запросов). Если в системе не предусмотрены правила, ограничивающие число принимаемых запросов с одного адреса в единицу времени, результатом такой атаки может стать как переполнение очереди запросов и отказ одной из сетевых служб (как и в предыдущем случае), так и полная остановка компьютера из-за невозможности системы заниматься ничем другим, кроме обработки запросов.