Несанкционированный доступ к терминалам серверов с операционными системами семейства UNIX. На примере octopus.stu.lipetsk.ru
Страница 6

(здесь она приводит­ся в сокращении), на которые данная удаленная атака якобы произвела необходимый эффект. Итак, мы начали тестирование и, честно говоря, абсолютно не удивились, когда исследуемые ОС - IRIX, AIX, VMS, SunOs, FreeBSD, Linux, Windows NT 4.0, даже Windows 95 и Windows for WorkGroups 3.11- абсолютно не реагировали на подобный некоррект­ный запрос, продолжая нормально функционировать. Тогда были пред­приняты специальные поиски операционной системы, которую бы дей­ствительно вывела из строя данная атака. Ей оказалась Windows 3.11 с WinQVT - эта ОС действительно «зависла».

Этим «экспертам», которым столь доверяют CERT и С1АС, мы послали запрос, где попросили прояснить возникшую ситуацию, а также уточнить сведения из вышеприведенной таблицы. В полученном нами ответе гово­рилось, что успех данной атаки зависит от многих факторов, а именно: программного и аппаратного обеспечения, установленного на компьюте­ре, и, самое главное, от фазы Луны. Как говорится, без комментариев. Для полноты картины мы хотели бы привести описание exploit, созданного для Windows NT 4.0, задача которого, используя ping, «завесить» собственный компьютер (!). Сначала предлагалось запустить Web Browser, затем-taskmgr (Task Manager): так Ping Death якобы лучше работает (еще не хва­тает шаманского бубна!). И наконец, требовалось запустить 18 ping-про­цессов (почему не 100?). Если вы думаете, что после всего этого ваша ОС немедленно «повиснет», то ошибаетесь! В комментариях к exploit до по­лучения эффекта предлагалось ждать примерно 10 минут, а может быть, несколько больше или несколько меньше.

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

причины усПЕХА УДАЛЕННЫХ АТАК

«То, что изобретено одним человеком,

может быть понято другим», - сказал Холме.

А. Конан Доил. Пляшущие человечки

· Использование нестойких алгоритмов идентификации

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

· Отсутствие контроля за виртуальными каналами связи

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

• контроль за созданием соединения;

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

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

Страницы: 1 2 3 4 5 6 7 8 9 10 11